WCAG 2.2 Demo SuiteTesting for accessibility
Accessibility testing is three activities, not one. Automated scanning finds a narrow band of machine-checkable defects. Manual testing with a keyboard and assistive technology finds most of the rest. Testing with disabled users finds the problems that conform to the standard and still do not work.
The number you should remember
Run npm run test:a11y in this repository and read the summary it prints.
Of the 86 WCAG 2.2 success criteria, 31 have any automated rule mapped to them at
all. The other 55 have none. And even the 31 are only partly covered — a scanner
can see that an alt attribute is missing; it can never see that the alt text
is wrong.
This is not a criticism of the tools. It is the reason the rest of this section exists.
The three layers
-
1. Automated testing
axe, pa11y and Lighthouse. Fast, repeatable, and useful in CI. Catches missing labels, missing alt attributes, contrast failures on solid backgrounds, and invalid ARIA.
Finds: roughly a third of criteria, partially.
-
2. Keyboard testing
The highest-value manual test there is, and it needs no software. If you only ever do one thing, unplug the mouse and press Tab.
Finds: keyboard traps, invisible focus, broken focus order, controls that cannot be reached at all.
-
3. Screen reader testing
NVDA, JAWS, VoiceOver and TalkBack. Reveals what your markup actually communicates, as opposed to what you intended it to.
Finds: wrong names and roles, unannounced updates, meaningless link lists, structure that exists only visually.
-
Visual and zoom testing
Contrast measurement, 200% and 400% zoom, 320 px reflow, and the text-spacing overrides.
Finds: clipped content, layouts that break under magnification, unreadable colour pairs.
-
Cognitive and content testing
Reading level, error recovery, timing pressure, consistency, and whether instructions make sense to someone who has not seen the page before.
Finds: the criteria no tool touches and most audits skim.
-
Testing with disabled people
Nothing on this page substitutes for it. A page can satisfy all 86 criteria and still be confusing, slow, or exhausting to use. Conformance is the floor, not the goal.
The order to test in
Cheapest and broadest first, so the expensive human time is spent on things only humans can find.
| Step | What you do | Time | What it catches |
|---|---|---|---|
| 1 | Run axe on the page, in every important state | 1 min | Machine-checkable defects |
| 2 | Tab through the whole page, mouse unplugged | 5 min | 2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11 |
| 3 | Zoom to 200%, then set the viewport to 320 px | 5 min | 1.4.4, 1.4.10, 1.3.4 |
| 4 | Apply the text-spacing overrides | 2 min | 1.4.12 |
| 5 | Read the page with a screen reader | 15 min | 1.1.1, 1.3.1, 2.4.4, 4.1.2, 4.1.3 |
| 6 | Trigger every error, every status message, every dialog | 10 min | 3.3.1, 3.3.3, 4.1.3, 2.4.3 |
| 7 | Read the content critically for jargon, instructions and timing | 10 min | 1.3.3, 2.2.1, 3.1.x, 3.3.2 |
Testing a whole site
The sequence above is for one page. Auditing a site means choosing which pages to apply it to, and that choice determines whether your audit is worth anything. That is what WCAG-EM is for.