A customer said they could not check out.
One complaint is usually the visible end of a pattern. We take the journey they described, reproduce it with the keyboard and a screen reader, and check the states around it before anything is changed.
Built to WCAG 2.2, checked in the states that matter
Accessibility
An accessible store is one every customer can finish buying from. We audit storefronts and operational tools against WCAG 2.2 Level AA with several rules engines and a person at the keyboard, fix what we find on a preview, and give you a statement you can stand behind.
Automated checks catch the defects that are cheap to find: missing names, poor contrast, broken heading order. The defects that stop a customer are usually inside an interaction: a menu that traps focus, a size selector that only works with a mouse, a dialog whose close button has no name, a filter drawer a screen reader cannot see. Those need the page opened, operated and checked in each state.
We test the way a customer uses the store, on a phone and a desktop, with the keyboard, with enlarged text and increased spacing, with reduced motion and forced colours, and with the assistive technology people actually use. Then we fix the findings in the theme or the application, recheck on a preview, and report what was tested, what changed and what remains.
Sounds familiar?
Three reasons people call us
A store address and a journey are enough to start.
Someone asked for a WCAG statement.
A procurement question, a partner requirement or your own policy. We audit against WCAG 2.2 Level AA, fix what we can in scope, and write a statement that says what was tested and what remains, in plain language.
The theme was never checked with a keyboard.
Most themes are built and tested with a mouse. Menus, search, filters, size selection, quick add and dialogs are where keyboard and screen reader use breaks, and where we look first.
What you get
Findings, fixes and a statement
A report against WCAG 2.2.
Every finding names the page, the element, the success criterion and the rules engine or manual check that found it, ranked by the effect on customers. axe-core, IBM Equal Access, pa11y and the Nu Html Checker run on every page and state, on mobile and desktop viewports.
Fixes on a preview.
Where the store or tool is one we maintain, findings are fixed on a preview theme and rechecked with the same tools before release. Focus order, names, roles, states, contrast and target sizes are corrected in the theme itself.
Manual checks a machine cannot make.
Keyboard passes through every interactive state, screen reader passes with VoiceOver and NVDA on the key journeys, real browser zoom to 200% and 400%, increased text spacing, reduced motion and forced colours.
A statement you can publish.
An accessibility statement in the form of the one on this site: the target, the checks completed, the known gaps and how to report a problem. No conformance claim without the scope and manual testing to support it.
How it goes
Automated first. Then by hand
No conformance claim without the scope and the manual testing to support it.
Run the engines.
axe-core with the WCAG 2.0, 2.1 and 2.2 A and AA rule sets, IBM Equal Access with its WCAG 2.2 policy, pa11y and the Nu Html Checker, across the routes and viewports that matter, with menus, drawers and dialogs opened so the states inside a page are checked too.
Operate it by hand.
Keyboard and screen reader passes on the journeys that matter most, contrast and target size checks on the real palette and components, and scripted Playwright checks for the things that regress: focus rings above open menus, labelled close buttons, search and size selection.
Fix, recheck, state.
Findings fixed on a preview and rechecked with the same tools, released when you say so, and written up as a statement that says what was done, in the order a customer would notice.
Accessibility in practice
Checked the same way as this site
This site is audited with the same toolkit; its accessibility statement says what was checked and what remains.
2XU · Theme architecture and performance
Same design, 40% less JavaScript
Native scrolling, search results that render as product data arrives, and checked releases to every regional store: interactions that stay responsive.
Common questions
Before we start
Do you certify WCAG conformance?
No. We report the checks completed and the improvements made against WCAG 2.2 AA, and we write the statement to match. A conformance claim needs a defined scope, manual testing with assistive technology and someone to stand behind it; we can scope that review with you.
Which tools do you use?
axe-core, IBM Equal Access, pa11y and the Nu Html Checker for automated checks; Playwright for scripted keyboard and state checks; VoiceOver and NVDA for screen reader passes; Lighthouse for its accessibility audit. Component code is linted with eslint-plugin-jsx-a11y before it renders.
Can we just add an accessibility widget?
Overlay widgets change how a page is presented; they do not fix missing names, focus order or the markup a screen reader reads, which is where most failures live, and they add a script to every page. We fix the theme itself.
Does Australian law require this?
The Disability Discrimination Act 1992 covers services provided online, and the Australian Human Rights Commission's guidance points to WCAG. We are not lawyers, and an audit report is the starting point for any advice you take, not a substitute for it.
What will you need from us?
A preview theme or a test environment, the journeys that matter most to you, and any previous audit or complaint so we can check those first.
Work directly with Chris
Let's check the journey
The store address, the journey that matters most, and any complaint or previous audit you have.