Accessibility as a Strategic Capability

From Compliance Checks to Organisational Practice

The Company was evolving rapidly: new eCommerce platforms, a shift to composable architecture, a global design system rollout, and increasing regulatory pressure across markets. Yet accessibility quality remained inconsistent. Issues accumulated across templates, UI components, and content practices, creating friction not only for users with accessibility needs but for anyone navigating the site under real-world constraints.

Teams were committed to delivering high-quality experiences, but with competing priorities and fragmented ownership, accessibility was often treated as a corrective task—reviewed late, fixed locally, and rarely scaled.
Without intervention, teams would have continued shipping components and templates with accessibility gaps unresolved until post-release audits, relying on local patch fixes rather than addressing systemic issues at the design-system or architectural level.

As Senior UX Researcher and accessibility lead, I established a structured, organisation-wide approach that positioned accessibility as a driver of product quality, risk reduction, and user trust rather than a compliance checkbox.

Challenge

The accessibility challenge was structural, not symptomatic. Several constraints shaped the work.

Legacy and Migration Overlap

Legacy SAP Commerce Cloud pages coexisted with new headless components, creating inconsistent patterns and uneven accessibility quality.

Design System Gaps

The design system lacked WCAG-aligned guidance and governance. Fixes applied in one area rarely propagated to others, allowing regressions to spread quietly across platforms.

Distributed Ownership

Responsibility for accessibility was unclear. Designers, developers, content authors, and QA teams operated independently, unsure who owned accessibility decisions or escalation paths. This lack of ownership created the greatest early resistance to change.

Delivery Pressure

Teams shipped quickly. Reviews happened late, accessibility debt accumulated, and fixes became increasingly costly.
The core challenge was not identifying accessibility issues, but building the structures, processes, and shared understanding required to prevent them.

Strategy

The accessibility program was built on four parallel pillars designed to embed accessibility into everyday decisions rather than post-release correction.

Accessibility Governance & Foundations
I authored and introduced an accessibility roadmap aligned with WCAG 2.2 AA and tailored to the Company’s platforms and component libraries. It defined responsibility boundaries, acceptance criteria, mandatory checkpoints, and escalation paths.

Before this framework, the absence of clear acceptance criteria meant teams repeatedly rebuilt or modified UI patterns without verifying semantic structure, focus behaviour, or contrast requirements. The roadmap transformed accessibility from ad-hoc remediation into a governed, repeatable process.

Embedding Accessibility in the Design System
Working with design and engineering leads, I integrated accessibility requirements directly into component specifications, including semantic structure, contrast constraints, keyboard behaviour, error handling, and inclusive copy guidance.

Accordion and tab components benefited most from this approach. Previously inconsistent across markets and devices, they became reliable once semantics and keyboard behaviour were standardised, producing immediate cross-platform improvements.

By moving requirements upstream, downstream QA and development became more predictable, reducing regressions across releases and regions.

Continuous Audits & Behavioural Validation
I established an audit program combining automated scanning (axe), manual WCAG reviews, and user-centred observation using screen reader workflows.

Beyond compliance gaps, this surfaced experiential friction: missing context for assistive technologies, non-linear reading orders, focus traps, and dynamic elements that failed to announce state changes correctly.

One issue proved disproportionately disruptive: incorrect or missing focus management on dynamic elements. Though initially perceived as a minor technical detail, it repeatedly broke task continuity for keyboard and screen reader users.

These insights helped teams prioritise issues based on user impact rather than severity labels alone.

Cross-Functional Enablement
I supported teams with training and lightweight tooling that enabled early risk detection, including accessibility office hours, pattern libraries with dos and don’ts, sprint-level checklists, and pre-release smoke tests.
Front-end development teams showed the fastest behavioural shift.

Once specifications and concrete examples were available, they quickly adopted new component patterns and embedded accessibility checks into daily workflows.

Over time, accessibility shifted from a specialist dependency to a shared language for quality.

Execution Highlights

Transforming the Checkout Experience
Checkout was prioritised due to its complexity and revenue sensitivity. I supported the redesign by mapping the screen reader journey, standardising form structures, aligning validation logic, and ensuring dynamic steps were announced and focus-managed.

The most confusing interaction before standardisation was the transition between checkout steps. Users—especially those using screen readers—received no announcement of context change and often did not realise the page had advanced. Resolving this significantly reduced ambiguity and cognitive load for all users.

Component-Level Accessibility Fixes
Several components required systemic intervention, including accordions, tabs, filters, product carousels, and heading structures.

Addressing these issues at the design-system level ensured fixes scaled consistently across global markets rather than being reintroduced through local variations.

Accessibility Monitoring & Dashboards
To support prioritisation, I introduced a structured approach to tracking automated scan trends, issue recurrence, component regressions, and accessibility debt over time.

Recurring regressions in design-system components proved most effective in shifting stakeholder prioritisation. They clearly demonstrated that the cost of inaction multiplied across markets and releases, prompting leadership to prioritise systemic fixes over page-level patches.

Redefining Content Practices
Accessibility extended beyond UI components. I worked with content and marketing teams to evolve alt-text practices, heading usage, link naming, and inclusive copywriting standards.

These changes improved clarity for assistive technologies and reduced cognitive load more broadly, a shift reflected in user feedback:
“I like that it’s a clean presentation. There’s a lot of information here on this page, but at no point does it feel like too much information. Nothing feels crowded.”
The quote was used internally as validation that structural clarity, not content reduction, was the primary driver of improved readability.

Outcome

The accessibility program reshaped how the organisation approached digital quality.

Strategic Impact
Accessibility became part of the standard definition of done. Platform migrations launched with stronger foundations, fewer regressions, and a reduced backlog of accessibility debt.

User Impact
Screen reader journeys became more predictable. Form-heavy flows such as checkout, account creation, and repairs showed reduced friction and clearer progression.

Organisational Impact
Design system teams adopted accessibility-first component governance. Development teams integrated checks into CI/CD workflows. Content and marketing teams embedded inclusive writing practices as standard.

The clearest signal of change was the integration of accessibility criteria directly into the design system’s component acceptance process: no new component or update could ship without meeting accessibility requirements.

Accessibility moved from specialist review to shared expectation.