A screen reader is assistive software that converts an interface into speech or braille, reading out its content and controls, allowing people who are blind, have low vision or have certain reading disabilities to use computers, phones and websites. In accessibility, the screen reader is the reference point for whether an interface exposes its structure, names, roles and states in a machine-readable way.
A screen reader does not read pixels. It reads the accessibility tree that the operating system and browser build from the interface, so a design that looks clear on screen can still be confusing or unusable when it is spoken aloud.
How a screen reader interprets an interface
The screen reader works through a chain of translations. The browser parses HTML and CSS into the DOM, derives an accessibility tree from it, and exposes that tree through a platform accessibility API. The screen reader queries the API and presents each object as speech or braille.
| Layer | What it provides | Where problems appear |
|---|---|---|
| Markup and ARIA | Elements, labels, roles and states | Missing labels, wrong roles |
| Browser accessibility tree | Simplified tree of meaningful objects | Hidden or duplicated content |
| Platform accessibility API | Standard interface such as UI Automation, AX API or AT-SPI | Inconsistent support across browsers |
| Screen reader | Navigation commands, speech and braille output | Verbosity and announcement settings |
| Output device | Speech synthesizer or braille display | Pronunciation and contraction rules |
Each object in the tree is announced as a combination of accessible name, role, state and value, for example “Subscribe, checkbox, not checked”. If any of these four parts is missing, the user receives an incomplete or misleading description.
Screen reader navigation modes
Screen reader users rarely listen to a page from top to bottom. They navigate by structure, jumping between headings, landmarks, links and form fields, which is why semantic structure matters as much as visual layout.
Desktop screen readers on the web usually switch between a browse mode, also called virtual cursor or reading mode, where single letter keys jump between elements, and a focus mode, where keystrokes go directly to the focused control. Mobile screen readers rely on swipe gestures and a rotor or reading-control menu instead.
| Method | What it relies on | Design implication |
|---|---|---|
| Heading navigation | Correct heading levels | Use one logical hierarchy without skipped levels |
| Landmark navigation | Header, nav, main, footer regions | Mark up page regions semantically |
| Link and button lists | Unique, descriptive names | Avoid repeated labels such as “Read more” |
| Form field navigation | Programmatic labels | Associate every input with a visible label |
| Table navigation | Header cells and scope | Use real table markup for data tables |
Surveys of screen reader users have consistently found that headings are the most common way to explore a long page. A missing or chaotic heading structure therefore costs more time than almost any other single defect.
Major screen readers and their platforms
Several screen readers dominate in practice, and behavior differs between them. Testing with more than one combination of screen reader and browser is the only way to catch platform-specific issues.
| Screen reader | Platform | Typical pairing | Notes |
|---|---|---|---|
| JAWS | Windows | Chrome, Edge | Commercial, common in workplaces |
| NVDA | Windows | Chrome, Firefox | Free and open source |
| Narrator | Windows | Edge | Built into the operating system |
| VoiceOver | macOS, iOS, iPadOS | Safari | Built in, dominant on mobile Apple devices |
| TalkBack | Android | Chrome | Built in, gesture driven |
A practical baseline for web projects is NVDA with Chrome or Firefox, VoiceOver with Safari on iOS, and TalkBack with Chrome on Android, extended with JAWS when the audience includes enterprise or government users.
Designing for screen reader users
Most screen reader accessibility comes from native semantic HTML used correctly. The success criteria of WCAG on name, role and value, information and relationships, and meaningful sequence describe exactly what a screen reader needs from an interface.
- Use native elements first: a real button announces its role and responds to Enter and Space without extra code.
- Give every control an accessible name through visible labels, and use ARIA only when native semantics are insufficient.
- Write meaningful alternative text for informative images and empty alt text for decorative ones.
- Announce dynamic changes with live regions, for example form errors or cart updates.
- Keep reading order equal to visual order so the spoken sequence makes sense.
- Support keyboard navigation fully, because desktop screen reader users rely on the keyboard.
A known rule among practitioners is that no ARIA is better than bad ARIA. An incorrect role or state actively misinforms the user, whereas plain HTML at least behaves predictably.
Common screen reader failures
Automated checkers detect only part of the problems that affect screen reader users. Manual testing with a real screen reader reveals the failures below, which are among the most frequent in audits.
| What the user hears | Cause | Fix |
|---|---|---|
| “Button” with no name | Icon-only button without a label | Add visually hidden text or aria-label |
| Nothing after an action | Status change not announced | Use a polite live region |
| “Clickable” on a div | Generic element used as a control | Replace with a native button or link |
| Content behind a dialog | Focus not contained in the modal | Use a modal dialog with managed focus |
| Long file names for images | Missing alt text | Write concise, purposeful alternatives |
Another common misconception is that screen readers are used only by blind people. People with low vision, dyslexia or cognitive disabilities also use them, often in combination with magnification, so text alternatives and clear structure benefit a broad audience.
Put simply
A screen reader is a program that reads the screen aloud or shows it on a braille display. It lets people who cannot see the screen use a phone or computer by listening and using keyboard shortcuts or gestures.
It does not see the page the way sighted people do. It relies on hidden labels and structure in the code, much like a librarian who finds books by their catalog entries rather than by the color of their covers. If those entries are missing, the content is effectively lost.
In practice
A public library redesigns its online catalog. Before launch, an accessibility specialist tests the search flow with NVDA and Firefox on Windows and VoiceOver on an iPhone.
The tests show that the filter buttons are announced only as “button”, that search results load without any announcement, and that the results list has no heading. The team adds accessible names to the filters, a live region that announces the number of results and a proper heading above the list.
A blind library patron who participates in the follow-up test completes a search and reservation in under three minutes, a task that had been impossible in the earlier version.