Screen Reader

Accessibilityintermediate

// Definition

Assistive technology software that converts on-screen content into synthesised speech or Braille output, enabling users who are blind or have low vision to navigate and interact with digital interfaces. Common screen readers include NVDA and JAWS (Windows), VoiceOver (macOS and iOS), and TalkBack (Android). QA testers use screen readers to verify that interactive elements have meaningful names, heading and landmark structure is navigable, dynamic content changes are announced, and no information is conveyed visually only.

// Why it matters

A screen reader narrates the page to blind/low-vision users via the accessibility tree. QA cares because it's the ground truth no automated tool replaces: axe can flag a missing label, but only a screen-reader pass tells you whether the page is usable — whether focus order makes sense, announcements fire, and dynamic updates are heard.

// How to test

This is a manual, tool-assisted procedure (NVDA/JAWS on Windows, VoiceOver on Mac):
  • Tab through the whole flow eyes-closed — does the narration make sense?
  • Confirm every control announces a name, role, and state
  • Trigger dynamic changes (toasts, validation) — are they announced via live regions?
  • Check focus order matches visual order; no keyboard traps
Automated tests assert prerequisites (labels, roles); they cannot judge the experience.

// Common mistakes

  • Assuming an axe pass means screen-reader-usable (it doesn't)
  • Dynamic content (errors, toasts) that updates silently with no live region
  • Testing one screen reader and assuming the rest behave identically

// Related terms