On this page4 sections
ReferenceIntermediate4-6 min reference

Screen Reader Testing

Automated tools can't tell you whether a screen reader announces a control sensibly — only listening can. You don't need to be an expert: learn one reader, the handful of navigation keys, and what "good" sounds like. This sheet covers that; for the markup behind it see the ARIA Roles sheet linked below.

Which reader, which platform

ReaderPlatformPair withCost
NVDAWindowsFirefox / ChromeFree
JAWSWindowsChrome / EdgePaid (most common in enterprise)
VoiceOvermacOS / iOSSafariBuilt in
TalkBackAndroidChromeBuilt in
NarratorWindowsEdgeBuilt in

Test the reader + browser pairing real users use — behaviour differs across combinations.

Core navigation

ActionNVDA / JAWSVoiceOver (Mac)
Toggle readerCtrl+Alt+N (NVDA)Cmd+F5
Read next/prev item / VO+→ /
Next headingHVO+Cmd+H
Next landmark/regionD (NVDA)VO+U (rotor)
Next form fieldFrotor → Form Controls
List elements (rotor)Ins+F7VO+U

What to listen for

  • Each control announces a name, role, and state ("Submit, button" / "Remember me, checkbox, not checked").
  • Images convey their alt meaning; decorative images are silent.
  • Headings form a logical outline you can jump through.
  • Errors are announced (not conveyed by colour alone).
  • Dynamic updates (toasts, validation) are announced via live regions.

Common mistakes

  • Testing with one reader and assuming the rest behave identically.
  • Icon buttons that announce nothing ("button" with no name).
  • Reading visual order while the DOM/focus order differs.
  • Live updates that never get announced.

// Related resources

Tools & Utilities