Testing Accessibility
AdvancedAutomated tools catch roughly a third of issues. The rest need a keyboard, a screen reader and about ten minutes — which is still far cheaper than the alternative.
Overview
The temptation is to run Lighthouse, see a score of 100 and consider the work done. Automated tools test what can be tested mechanically — a missing alt attribute, an insufficient contrast ratio, a duplicate id — and they cannot tell whether alt text is meaningful, whether the tab order makes sense, or whether a modal traps focus. Consistent research puts automated coverage at roughly a third of real issues. The manual half is a short checklist, and running it during development is dramatically cheaper than retrofitting after a complaint.
Automated Testing
Fast, cheap, and worth wiring into CI — with a clear sense of what it misses.
# In the browser
axe DevTools extension # the most thorough, best explanations
Lighthouse -> Accessibility # a quick score, fewer checks
WAVE # visual overlay of issues
# In tests
npm i -D @axe-core/playwright
const results = await new AxeBuilder({ page }).analyze()
expect(results.violations).toEqual([])
# Component tests
import { axe } from 'jest-axe'
expect(await axe(container)).toHaveNoViolations()
# Linting, at authoring time
eslint-plugin-jsx-a11y # catches missing alt, invalid ARIA,
# click handlers without key handlers
/* What they DO catch: missing alt, low contrast, missing labels,
invalid ARIA, duplicate ids, missing lang, empty links.
What they CANNOT catch: alt="image" on a chart, a tab order that
makes no sense, a modal that does not trap focus, a "Submit"
button that deletes an account, motion that causes nausea, or
heading levels chosen for their size. */The Manual Checklist
Ten minutes, and it finds what the tools cannot.
/* 1. KEYBOARD. Put the mouse away.
- Tab through the whole page: can you reach everything?
- Is focus always visible?
- Does the order match the visual layout?
- Open a modal: is focus trapped? Does Escape close it?
Does focus return to the trigger?
- Can you complete the main task start to finish? */
/* 2. ZOOM to 200% and read the page. Anything cut off or
overlapping? Any horizontal scrolling? */
/* 3. FONT SIZE: set the browser default to 24px. Does the layout
hold, or does the text overflow its containers? */
/* 4. TURN OFF CSS (DevTools, or reader mode). The page should still
read in a sensible order — that order is what a screen reader
follows. */
/* 5. IMAGES OFF, or read the alt text aloud. Does it convey the
same information? */
/* 6. SCREEN READER, even briefly:
Windows NVDA (free) Insert+Down reads, H jumps headings
macOS VoiceOver Cmd+F5, Ctrl+Option+arrows
Android TalkBack iOS VoiceOver
Ten minutes with one teaches more than any article. */Making It Stick
Process, and the standards a client or employer will name.
/* Standards you will be asked about:
WCAG 2.2 — levels A, AA, AAA. AA is the practical target and
what nearly every legal requirement references.
Four principles: Perceivable, Operable, Understandable, Robust
India: the RPwD Act 2016 requires accessible government sites,
and GIGW is the national guideline. */
/* Process that actually works:
- eslint-plugin-jsx-a11y in the editor, so issues surface while
typing rather than in review
- axe in CI, failing the build on new violations
- the manual checklist on any new interactive component
- an accessibility line in the PR template */
/* Cheapest of all: build with the right element from the start.
A native button needs no audit. Most remediation work is undoing
a div that should have been a button. */
/* Where to get authoritative answers:
MDN accessibility docs
WAI-ARIA Authoring Practices Guide — the reference patterns
WebAIM's annual million-site survey */Key Points to Remember
- 1Automated tools catch roughly a third of issues — a Lighthouse score of 100 does not mean an accessible page
- 2axe in CI and eslint-plugin-jsx-a11y while authoring catch mechanical problems early and cheaply
- 3The manual checklist is keyboard, 200% zoom, larger default font, CSS off, images off, and a few minutes with a screen reader
- 4WCAG 2.2 level AA is the practical target that most legal requirements reference
- 5Building with the correct native element from the start removes most of what remediation work consists of
Interview Questions
Sign in to ask AriaWhy is a perfect Lighthouse accessibility score not proof of an accessible page?
What would you check manually that no automated tool can?
What is WCAG AA and why is it the usual target?
Ask Aria about Testing Accessibility
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.