Screen reader

A screen reader is software that converts on-screen content into synthesized speech or refreshable braille. It is the primary assistive technology used by blind and severely low-vision computer users — and the user agent that the entire ARIA + semantic-HTML stack is ultimately designed to serve.

What a screen reader does

Screen readers work by walking the operating-system or browser accessibility tree — an internal data structure that exposes elements, their roles, names, states, and relationships. The screen reader serialises this tree into speech (or braille) and routes keyboard input back into the application.

A user navigating the web with a screen reader can:

• Read sequentially by pressing Down Arrow or a “read next” key.
• Jump by heading (H key in many readers) to skim long pages.
• Jump between landmarks (<nav>, <main>, <aside>) to move between page regions.
• Open a list of links to scan navigation choices in isolation.
• Open a list of form fields for fast form completion.
• Read continuously via “say all” / “read all” commands.

This is why heading structure, landmarks, and accurate link text matter so much. A screen reader user doesn’t tab through every element on a page — they navigate by structure. Pages with no headings or nondescript (“Click here”) links are unbrowsable.

The major desktop screen readers

• JAWS (Job Access With Speech) — commercial, Windows, from Freedom Scientific. Historical market leader in enterprise; commonly paired with Chrome or Edge.
• NVDA (NonVisual Desktop Access) — free and open-source, Windows. Close to JAWS in market share and the screen reader most accessibility professionals test against by default.
• VoiceOver — built into macOS and iOS. Apple’s reference screen reader for all of its platforms.
• Narrator — built into Windows, traditionally a fallback but increasingly capable on Windows 11.
• Orca — free, GNOME/Linux. Smaller user base, but the default for the open-source desktop.

The major mobile screen readers

• VoiceOver (iOS) — the assumed reference for mobile web a11y testing.
• TalkBack (Android) — Google’s mobile screen reader, ships with Pixel devices and most OEM Android skins.

What testing actually looks like

The WebAIM Screen Reader User Survey (published roughly biannually) gives the only widely-cited usage data. JAWS and NVDA dominate desktop; VoiceOver-on-iOS dominates mobile. Real-world QA programs typically test in at least three pairings:

• NVDA + Firefox (Windows)
• JAWS + Chrome (Windows)
• VoiceOver + Safari (macOS and iOS)

Each pairing exposes different bugs — ARIA support depth, focus behaviour, and live-region handling diverge in non-trivial ways between them. Cross-screen-reader testing isn’t optional once the budget allows.

Things that consistently break screen-reader UX

• Custom widgets without correct ARIA roles.
• Dynamic content changes with no aria-live region (or, just as bad, aria-live="assertive" on every minor update — the screen reader interrupts the user constantly).
• Focus that doesn’t follow visible context (modal opens, focus stays on the trigger somewhere offscreen).
• Images with empty alt when they actually convey content.
• Visually-hidden text that contradicts visible text.