Frontend Beauty
ESC

Type to search the knowledge base.

Screen Reader Testing Basics

Get started with VoiceOver, NVDA, and TalkBack — what to listen for, a smoke-test script, and how SR testing pairs with the a11y tree.

intermediate3 min read
  • accessibility
  • screen-reader

Automated tools don’t hear your UI. Screen reader (SR) testing is how you validate names, roles, states, live regions, and reading order. You don’t need to be a daily SR user to run a valuable smoke test on critical flows.

Docs: WebAIM NVDA, WebAIM VoiceOver, Accessibility tree.

Pick a stack

OS SR Browser often used
macOS VoiceOver Safari (primary), Chrome
Windows NVDA (free) Firefox or Chrome
Android TalkBack Chrome
iOS VoiceOver Safari

Test on one desktop SR thoroughly for engineering QA; expand before major releases.

VoiceOver quick start (macOS)

  • Toggle: Cmd+F5
  • VO keys: Control+Option (called VO)
  • Next item: VO+Right
  • Rotor: VO+U (headings, landmarks, links)
  • Click/activate: VO+Space

NVDA quick start (Windows)

  • Install from nvaccess.org
  • Browse mode vs focus mode for forms
  • Insert/NVDA key combinations for lists of headings/links

Smoke-test script (15 minutes)

  1. Load the page — hear page title?
  2. Landmarks: find main, nav.
  3. Headings list: outline make sense?
  4. Tab through primary actions — names clear?
  5. Complete the critical form — errors announced?
  6. Open modal — focus trapped; Escape works; restore?
  7. Dynamic toast — announced once?

Write bugs with: SR + browser + OS + steps + what was heard vs expected.

What “good” sounds like

  • “Button, Submit” not “Button” empty
  • “Checked, Remember me, checkbox”
  • Dialog name read on open
  • No endless “clickable” unlabeled divs

What to not over-index

Different SRs announce differently. Aim for correct roles/names/states in the accessibility tree rather than pixel-identical speech strings across all combos.

Pair with DevTools

Inspect Name / Role / Value in the Accessibility pane when speech is confusing. Fix the tree, retest SR.

Footguns

  1. Testing only with mouse + SR mouse tracking — use keyboard.
  2. Chrome-only VoiceOver on macOS for shipping Safari-critical apps.
  3. Fixing for one verbose SR setting and breaking others.
  4. No retest after “small” CSS changes that affect visibility to AT.

Interview out-loud answer

“I smoke-test critical journeys with VoiceOver or NVDA using keyboard, check landmarks/headings/names, and verify dialogs and live regions. I debug with the accessibility tree. Automation plus one SR pass catches different classes of bugs.”

Forms mode gotchas

NVDA and JAWS switch modes on form fields. If arrows stop working as you expect, you may be in focus mode. That’s expected for inputs — use Tab between fields. Document this for teammates new to SR testing so they don’t file false bugs.

Extra practice

Write a minimal demo in a scratch file or the playground: one happy path, one failure path, and one boundary input. If you cannot exhibit a bug that the pattern prevents, you do not own the concept yet — re-read the primary docs linked below and tighten the example until the failure is obvious.

Notes from real codebases

Teams that succeed here keep the rules mechanical: lint where possible, CI for the rest, and a short human checklist for what automation cannot see. Document exceptions with an owner name and a removal date so “temporary” escapes do not become permanent architecture.

Further reading

Related guides