Screen Reader Testing

Screen reader testing reveals problems automated tooling often misses — test through real interaction.

01 — Purpose

Hear what assistive technology hears

Screen reader testing reveals accessibility problems automated tooling often misses — interfaces should be tested through real interaction.

Valid HTML does not guarantee a good screen reader experience. Names can be wrong, live regions silent, landmarks missing, and dynamic updates invisible. Testing with NVDA, VoiceOver, or JAWS surfaces what users actually hear.

See screen reader announcements and manual testing workflows.

02 — Principles

Accessibility confidence requires real testing

Test common journeys — not only isolated components.

  • test common journeys — sign-in, search, form submit, modal open/close
  • verify announcements — errors, success, loading, and async updates
  • check landmark structure — header, nav, main, footer present and sensible
  • validate dynamic updates — see live regions

03 — Practice

Tools and technique

NVDA (Windows), VoiceOver (macOS/iOS), and JAWS (Windows enterprise) — pick what matches your users.

  • learn basic navigation — headings list, landmarks, forms mode, browse vs focus
  • test with keyboard only — screen reader follows focus; pointer-only UI fails here
  • listen for redundant or missing names — buttons, links, and icon-only controls
  • trigger validation and async actions — confirm users hear what changed
  • compare against semantic HTML — fix structure before adding ARIA

04 — Avoid

False confidence

Assuming semantic correctness without listening is how issues ship.

  • relying only on automation — no tool speaks your UI aloud
  • testing only visually — “I can see the label” ≠ announced name
  • assuming semantic correctness — valid markup, wrong experience
  • one quick demo — no retest after JS or copy changes
  • testing only with one engine — behaviour differs between NVDA and VoiceOver

05 — Close

Listen on every major change

Five minutes with a screen reader beats fifty automated rules on dynamic UI.

Add screen reader smoke tests to your release checklist for flows with overlays, async data, or custom widgets. File bugs with what was expected vs what was announced.

See live regions, ARIA usage, and accessibility QA checklist.