Accessibility Testing
Accessibility testing checks whether people with disabilities — blind and low-vision users, keyboard and switch users, people with hearing, cognitive, or motor impairments — can actually use a product. The usual target is WCAG 2.2 Level AA, the standard referenced by most accessibility laws and procurement requirements, but conformance is a means, not the goal. The goal is that every user can complete the tasks the product exists for.
No single technique is enough. Automated scanners are fast and catch many common errors, but they cannot tell whether alt text is meaningful, whether focus moves sensibly, or whether a screen reader user can understand a complex widget. Effective accessibility testing layers automation in CI, structured manual checks during development, and periodic testing with assistive technology users.
TL;DR
- Combine automated scans (axe-core, Lighthouse) with manual testing; automation finds only a portion of real issues.
- Test keyboard-only use on every flow: everything reachable, focus visible, order logical, no traps.
- Test with screen readers on the platforms your users have — NVDA or JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android.
- Check zoom to 200% and reflow at 400%, contrast, reduced motion, and forced-colors modes.
- Run automated checks in CI on components and key pages, so regressions are caught like failing unit tests.
- Test with disabled users for important journeys; they find problems no checklist anticipates.
Quick Example
Automated and keyboard checks for a checkout page with Playwright and @axe-core/playwright.
The first test catches mechanical problems such as missing labels and low contrast; the second encodes a manual check — keyboard flow and announced errors — so it cannot silently regress.
Core Concepts
WCAG and Conformance Levels
The Web Content Accessibility Guidelines organize success criteria under four principles — perceivable, operable, understandable, robust (POUR) — at levels A, AA, and AAA. Level AA is the common legal and contractual target. WCAG 2.2, published in 2023, added criteria such as focus not being obscured, minimum target sizes, and accessible authentication. See Accessibility.
What Automation Can and Cannot Find
Automated tools are excellent regression guards for the left column and cannot assess the right one.
Assistive Technology Coverage
Screen readers interpret the same markup differently. Test the combinations your users rely on, at minimum one desktop and one mobile pairing.
Manual Testing Checklist
Keyboard
- Every interactive element is reachable with Tab and Shift+Tab, and operable with Enter, Space, and arrow keys as appropriate.
- Focus is always visible and never hidden behind sticky headers.
- Focus order follows the visual and logical order.
- Dialogs move focus inside when opened, keep it there, and return it on close. See Keyboard Navigation and Focus Management.
- There are no keyboard traps and no actions that require a mouse.
Screen Reader
- Page titles, landmarks, and headings allow quick navigation.
- Images have appropriate alternatives; decorative images are hidden.
- Form fields announce their labels, requirements, and errors. See Accessible Forms and Error Recovery.
- Dynamic updates — toasts, validation, loading states — are announced through live regions.
- Custom widgets announce their role, state, and value correctly.
Visual and Motion
- Text remains usable at 200% zoom, and content reflows to a single column at 400% (320 CSS pixels wide) without horizontal scrolling.
- Contrast meets 4.5:1 for normal text and 3:1 for large text and essential UI components.
- Information is never conveyed by color alone.
- Animations respect
prefers-reduced-motion; nothing flashes more than three times per second. - The interface remains usable in Windows forced-colors (high contrast) mode.
Building Accessibility Testing Into Delivery
In Components
Test accessibility where components are built. Storybook's accessibility addon runs axe on every story, and unit tests with jest-axe or vitest-axe check rendered components. Fixing a shared component once fixes every screen that uses it.
In CI
Run axe scans against key pages and flows in end-to-end tests (Playwright, Cypress), and fail the build on new violations. For existing products with a backlog of issues, record a baseline and fail only on new violations while the backlog is paid down.
In Definition of Done
Add keyboard and basic screen reader checks to the definition of done for UI work, with accessibility acceptance criteria on stories. See Quality Attributes and Nonfunctional Requirements.
With Real Users
Periodically test important journeys with people who use assistive technology daily. Expert users reveal problems that checklist testing misses — and show which issues actually block them.
Best Practices
Start With Semantic HTML
Native elements — button, a, label, select, headings, and landmarks — come with keyboard behavior and screen reader semantics built in. Most accessibility failures start with a div pretending to be something else.
Test Early and in Small Pieces
Test each component and flow as it is built. Retrofitting accessibility across a finished product costs far more than building it in.
Prioritize by Task Impact
Fix issues that block core tasks — signing up, paying, completing the main workflow — before cosmetic issues on secondary pages.
Document Conformance Honestly
When customers ask for an accessibility conformance report (often a VPAT-based ACR), base it on real testing and list known issues with remediation plans.
Common Mistakes
Treating a Perfect Lighthouse Score as Proof
ARIA Instead of Native Elements
Testing With One Screen Reader Only
FAQ
Can automated tools guarantee WCAG compliance?
No. Automated tools reliably detect only a subset of WCAG failures — missing labels, contrast problems, invalid ARIA — and cannot judge meaning, focus order, or the usability of complex widgets. Combine them with manual keyboard, screen reader, and visual testing.
Which screen reader should we test with?
The ones your users use. For broad coverage, test NVDA with Chrome or Firefox on Windows, VoiceOver with Safari on macOS and iOS, and TalkBack with Chrome on Android. JAWS remains common in enterprise and government settings.
How often should we test accessibility?
Automated checks on every change in CI, manual keyboard and screen reader checks as part of developing each UI feature, and a deeper audit or user testing for major releases and redesigns.
What is a VPAT or ACR?
A Voluntary Product Accessibility Template is a standard document format; once completed for a product it is an Accessibility Conformance Report describing how well the product meets standards such as WCAG and Section 508. Enterprise and public-sector buyers often require one.
How do I test focus order?
Load the page, put the mouse aside, and press Tab repeatedly. Focus should move through interactive elements in a logical, visual order, always be visible, and never jump unexpectedly or get stuck. Repeat after opening dialogs, menus, and other dynamic content.
Related Topics
- Screen Readers and Accessible Semantics — Use native controls and meaningful structure, then verify complete tasks with actual browser and assistive-technology combinations.
- Testing & Quality Assurance — Accessibility within the wider test strategy
- Accessibility — Building accessible interfaces
- Keyboard Navigation and Focus Management — Focus patterns to test
- Accessible Forms and Error Recovery — Labels, validation, and error messages
- Playwright — Running automated accessibility checks end to end
- Storybook — Testing accessibility at the component level
- Responsible Technology and Accessibility Governance — Governance around accessibility testing