Testing Accessibility
Automated tools catch roughly half of accessibility issues — the rest require keyboard testing and a screen reader, because tools can't judge intent.
- Run an automated accessibility audit with axe DevTools or Lighthouse and interpret the results
- Execute a keyboard-only test of a web page
- Navigate a page with VoiceOver or NVDA and identify what screen reader users experience
- Describe what automated tools cannot catch and why manual testing is required
Automated accessibility testing feels reassuring. Run the scanner, fix the red items, see a green score. The problem is that automated tools can detect roughly 30–50% of WCAG issues. The rest require a human to judge whether the experience actually works — whether that alt text is meaningful, whether focus management in the modal makes sense, whether the error message is clear enough.
A complete accessibility test uses three layers: automated scanning, keyboard testing, and screen reader testing. This lesson covers all three.
Layer 1: automated scanning
Automated tools parse the DOM, check known rules, and flag violations they can determine programmatically. They are fast and consistent — ideal for catching the easy, unambiguous problems.
axe DevTools is the most widely used. Install the browser extension (axe DevTools for Chrome or Firefox), open DevTools, navigate to the axe tab, and click "Scan all of my page." The results are grouped by impact (Critical, Serious, Moderate, Minor) and each item links to the affected element and explains the fix.
Lighthouse is built into Chrome DevTools. Open the Lighthouse tab, check the Accessibility box, and click Analyse. It uses axe under the hood and produces a 0–100 score alongside individual failures.
WAVE (web accessibility evaluation tool, from WebAIM) adds visual overlays directly on the page, marking landmarks, headings, and errors in place. Useful for seeing the structure of a page as a whole.
What automated tools catch reliably:
- Missing alt attributes on images
- Form inputs without associated labels
- Colour contrast failures (below the minimum ratio)
- Missing document language declaration (
<html lang="en">) - Duplicate
idattributes - Empty links and buttons (no accessible name)
- Invalid ARIA attribute values
A Lighthouse score of 100 does not mean the page is fully accessible. It means the tool found no automatable violations. A page with a decorative image that has no alt text fails; a page with a decorative image that has wrong alt text (say, the filename) can pass automated scanning but still fail the human experience. Always combine automated scanning with manual testing.
Layer 2: keyboard testing
The keyboard test requires nothing but a browser and discipline. Put the mouse away and navigate using only the keyboard.
The core keys:
| Key | Action |
|---|---|
| Tab | Move to next focusable element |
| Shift + Tab | Move to previous focusable element |
| Enter | Activate a link or button |
| Space | Activate a button, toggle a checkbox |
| Arrow keys | Move within a component (radio group, select, tab strip, menu) |
| Escape | Close a dialog or dismiss a dropdown |
What to verify on each page:
- Press Tab from the top of the page. Does focus start on the skip link or the first interactive element?
- Tab through every interactive element. Is every one reachable? Is any element skipped or unreachable?
- Is the focus indicator visible at all times? Does it ever disappear or become invisible against the background?
- Can you activate every action — open dropdowns, submit forms, trigger modals, close dialogs — without a mouse?
- After opening a modal or dropdown, can you close it with Escape? After closing, does focus return to the element that opened it?
- If there is a skip link, does pressing Tab on page load reveal it? Does activating it move focus to the main content?
A session that takes two minutes per page will surface the majority of keyboard navigation failures.
Layer 3: screen reader testing
A screen reader converts the accessibility tree into speech or Braille. Testing with one reveals what keyboard testing alone cannot: whether the announced labels are meaningful, whether element roles are correct, whether dynamic content updates are announced.
Which screen reader to use:
- VoiceOver (macOS/iOS) — built into the operating system, free, no install required. On Mac: Command + F5 to toggle. Pair with Safari for best compatibility.
- NVDA (Windows) — free, open source, widely used. Download from
nvaccess.org. Pair with Chrome or Firefox. - TalkBack (Android) — built into Android, useful for mobile testing.
Basic VoiceOver navigation for testing:
VO key = Control + Option (held together)
VO + Right arrow — read next element
VO + Left arrow — read previous element
VO + U — open the rotor (navigate by heading, link, landmark)
VO + Space — activate the focused element
Tab — move to next interactive elementWhat to listen for:
- Headings — open the rotor and navigate by heading. Does the structure match what a sighted user sees? Are there h1 → h2 → h3 progressions with no gaps?
- Images — does the screen reader announce meaningful alt text? Does it skip
decorative images (those with
alt="")? - Forms — when you focus an input, does the screen reader announce the label and any hint text?
- Dynamic content — after a form submission, a search, or a status update, does the screen reader announce the new content? Does it do so without the user having to navigate to it?
- Modals — when a dialog opens, does focus move into it? When it closes, does focus return to the trigger?
Screen reader testing has a learning curve. Spend fifteen minutes on a known accessible page first (gov.uk and apple.com have high-quality implementations) to calibrate what "correct" sounds like before testing your own page.
What to check manually beyond screen readers
Some accessibility issues require human judgment that neither an automated scanner nor a screen reader test will surface:
Alt text quality — an automated tool confirms an alt attribute exists.
Only a human can judge whether alt="img_final_v3.jpg" is useful.
Reading level — WCAG 3.1.5 (AAA) recommends readable language. Tools cannot assess whether your error messages are plain and clear.
Cognitive load — does the page structure make sense? Are there unexpected changes of context? These require user testing with real people.
Touch target size — WCAG 2.5.5 recommends a minimum 44×44px touch target. DevTools can inspect size, but verifying that adjacent targets are also separated enough for accurate tapping requires physical device testing.
Accessibility in CI/CD
axe-core (the open-source engine behind axe DevTools) runs in Node.js and integrates with test frameworks:
// Example using @axe-core/playwright
import { checkA11y } from 'axe-playwright';
test('home page has no accessibility violations', async ({ page }) => {
await page.goto('/');
await checkA11y(page);
});Playwright, Cypress, and Jest all have axe integrations that can run on every pull request. This catches regressions before they reach production. It does not replace manual testing — but it does prevent the regressions that are easily automated.
Where to go next
You now have a complete testing workflow: automated scan, keyboard test, screen reader pass, and CI integration. The final step in this module is the lab: Lab — Accessibility Audit, where you apply all three layers to a broken page and fix what you find.
Color and Contrast
Color contrast is a mathematical ratio between foreground and background — WCAG sets minimum ratios that ensure text is readable for users with low vision.
Lab — Accessibility Audit
Run an automated audit on a provided broken page, then complete a keyboard and screen-reader test and fix the identified issues.