Screen reader testing

Why this matters

A screen reader is the most demanding test of your markup. It exposes every missing label, vague link, skipped heading and silent update. You do not need to become an expert user, but every front-end developer and product designer should be able to do a basic pass: navigate by headings and landmarks, tab through controls, fill in a form and listen to what is announced. It takes about fifteen minutes to learn the basics and finds problems no automated tool can.

Remember that experienced screen reader users are much faster than you, and use settings and habits you will not. Your test checks that the page can be used; it is not a substitute for testing with disabled people, which good teams also do.

Pick a pairing

Screen readers are tested with the browser their users most often pair them with:

WebAIM's screen reader user survey consistently shows NVDA, JAWS and VoiceOver as the most used. If you have a Mac, start with VoiceOver; on Windows, install NVDA.

Two modes

Screen readers on the desktop have two ways of moving:

• Browse (or virtual cursor) mode: the arrow keys read the page line by line, and single letters jump by element type. This is how people read.
• Focus (or forms) mode: keys go straight to the focused control so you can type in a field. NVDA switches automatically when you tab into an input; you can toggle with NVDA+Space.

Essential keys

NVDA (the NVDA key is Insert, or Caps Lock if you choose the laptop layout):

• Start/stop: Ctrl+Alt+N to start; NVDA+Q to quit. Ctrl silences speech.
• Down Arrow: next line. NVDA+Down Arrow: read from here.
• H / Shift+H: next / previous heading. 1 to 6: heading at that level.
• D: next landmark. K: next link. F: next form field. B: next button. T: next table.
• Tab: next focusable element.
• NVDA+F7: Elements List (all links, headings, landmarks, form fields).

VoiceOver on macOS (VO = Control+Option):

• Start/stop: Cmd+F5 (or hold Cmd and triple-press Touch ID).
• VO+Right/Left Arrow: next / previous item. VO+A: read from here.
• VO+Cmd+H: next heading. VO+U: open the rotor, then Left/Right Arrow to pick headings, links, landmarks or form controls.
• Tab: next focusable element. VO+Space: activate.
• Turn on "Press Tab to highlight each item on a webpage" in Safari settings, Advanced, so Tab reaches links.

Keep the official guides open the first time: NVDA User Guide and Apple's VoiceOver User Guide.

A repeatable test script

Run the same checks on every page so results are comparable:

1. Page load. Is the page <title> announced and does it say where you are?
2. Headings. Press H (or use the rotor) through every heading. Do they form a sensible outline, with one h1 and no skipped levels? Could you understand the page from the headings alone?
3. Landmarks. Press D (or use the rotor). Are there banner, navigation, main and contentinfo regions? Are multiple navs labelled ("Main", "Footer")?
4. Links. Open the Elements List or rotor of links. Does each make sense out of context? "Read more" ten times does not.
5. Images. Arrow through: are informative images described and decorative ones silent?
6. Forms. Tab through a form. Does each field announce its label, whether it is required, and its hint? Submit with errors: are the errors announced, and can you get to them?
7. Widgets. Open a menu, accordion or dialog. Is its state announced ("collapsed", "expanded", "dialog")? Does focus move into a dialog and back out when it closes?
8. Updates. Add to cart or save something. Is the status ("Added to cart") announced without your focus moving?

Writing up what you hear

Write down what the screen reader said, not what you expected: "Tabbing to the search button announces 'button' with no name". Pair it with the criterion (4.1.2) and the fix (aria-label="Search"). Recording the screen with audio, with permission and no personal data on screen, makes bugs much easier to reproduce.

Worked example: a sign-up form

Testing a sign-up page with NVDA and Firefox: H finds "Create your account" (h1) and then "Already registered?" as an h4, a skipped level. F moves to the first field and NVDA says "edit, blank": the field has only a placeholder and no label. The password hint is never read because it is not linked with aria-describedby. Submitting with errors changes the border colour, but nothing is announced. Four findings, all fixable with HTML from Module 1, none caught as clearly by an automated scan.

Common mistakes

• Testing with the mouse while the screen reader runs. Users navigate with the keyboard (or touch gestures on mobile).
• Testing VoiceOver in Chrome or NVDA in Safari-like pairings users rarely use.
• Assuming one screen reader's behaviour is universal; they differ, so test with at least two over a project.
• Fixing for one screen reader with hacks instead of fixing the underlying HTML.
• Turning speech so slow that you lose patience; it is fine to speed it up as you get used to it.

Quick recap

• NVDA with Firefox/Chrome on Windows, VoiceOver with Safari on macOS are the starting pairs.
• Learn browse vs focus mode and the heading, landmark, link and form shortcuts.
• Use the same eight-step script on every page and write down exactly what you hear.
• See also: W3C WAI: Involving Users in Evaluating Web Accessibility.

Try it

Open the Do tab and test a page with a screen reader using the script above.