Accessibility audit and testing
A full manual audit and accessibility testing pass over your product against WCAG 2.2, on real devices with real assistive technology, with every issue rated and mapped to a fix.
| Keyboard | Every task without a mouse, visible focus throughout |
|---|---|
| Screen readers | NVDA, JAWS, VoiceOver and TalkBack on key flows |
| Contrast and text | Colour contrast, resize to 200%, reflow at 320px |
| Forms and errors | Labels, instructions, error recovery |
| Structure | Headings, landmarks, links, tables |
| Motion and timing | Pauses, no flashing, enough time |
| Cognition | Redundant entry, consistent help, error recovery |
| Audit report | Every issue with severity, criterion, steps and fix |
|---|---|
| Manager summary | Risk and priorities in plain words |
| VPAT and ACR | Completed conformance report on request |
| Retest | Written confirmation that each fix works |
Where we test
Accessibility testing runs across the platforms your product ships on, on real devices, with the assistive technology people actually use.
| Websites and web apps | Desktop and mobile browsers, keyboard, NVDA, JAWS, VoiceOver |
|---|---|
| iOS apps | VoiceOver, Xcode Accessibility Inspector, dynamic type sizes |
| Android apps | TalkBack, Android Accessibility Scanner, font and display sizes |
| Components and design systems | Each component in isolation and inside real pages |
| Blockers | Tasks some users cannot complete at all |
|---|---|
| Friction | Tasks that cost extra steps or guesswork |
| Breakage | What a recent change broke, and where |
| Fixes | A fix for each finding, ready for your backlog |
Automated testing in your pipeline
Automated accessibility testing is a floor you keep swept, not a replacement for the audit.
Automated accessibility testing means a rule engine reading the rendered code: axe DevTools, Lighthouse, or the accessibility scanner in Xcode and on Android. It is fast, it repeats without judgement, and it catches the faults that do not need a person. The value is in the timing, because a defect is cheapest to fix on the pull request that created it rather than in an audit six months later.
It also cannot see most of what matters. Contrast over an image, focus that escapes a modal, an error message that never reaches a screen reader, a heading that names nothing: none of that is in the markup for a rule to read. Every automated result we hand back has been confirmed by hand first, which is why our reports order findings by severity rather than by rule name.
Checks that run with your tests
Where a team already runs end-to-end tests, the same rules can run inside them. Cypress accessibility testing means adding axe-core to a Cypress spec, so the page is checked as it renders in the test rather than in isolation. Playwright and Jest can carry the same axe-core engine, and either route can fail a build on a new violation instead of filing a ticket.
A setup that holds has three parts: the rule engine inside the test suite, a short list of rules the team has agreed to fail on, and a manual pass before release. Teams that drop the third part watch the automated count fall while the product stays hard to use. Our test case creation service writes the manual half of that plan down, so it survives the people who wrote it.
Mobile accessibility testing
Mobile accessibility testing needs its own passes and its own devices: VoiceOver on iOS and TalkBack on Android, switch control, large and bold text, and screen magnification at the top sizes the platform offers. Our guide to mobile app accessibility testing sets out what changes when the platform changes, and every audit that covers an app runs those passes.
Want one page checked by hand before you commit to any of it? The free one-page audit takes a page and returns the findings with a scope. Our ADA compliance checker does the automated half of that for free, in your own browser.
Audit and testing questions
What do you need from us to start?
Access to the product, ideally a staging build, plus a contact who can answer questions. We agree the pages, flows and standard before testing starts.
Which standard do you audit against?
WCAG 2.2 by default, the Web Content Accessibility Guidelines. We also cover ADA, Section 508, the European Accessibility Act, EN 301 549 and India's RPwD Act on request.
Should we audit or test first?
An audit comes first when you need the full picture. Testing fits a single platform or release. The free one-page audit shows which fits you.
Do you test as well as audit?
Yes. An audit includes a manual accessibility testing pass with assistive technology on the platforms you ship. Repeating that pass release after release is regression testing, and we run that too.
Book your free call
Tell us about your product in 30 minutes. We tell you what to test next.