Screen reader

A screen reader is software that converts screen content into speech synthesis or braille. It traverses the browser's accessibility tree, not the design, to convey page structure to blind or low-vision users.

Experienced screen reader users navigate at 300 words per minute. If your page is poorly structured, they don't slow down. They leave.

#How a screen reader reads your page

The screen reader sees no colors, layout, or typeface. It queries the accessibility tree that the browser builds from HTML. Each element appears with a role, a name, and a state.

A <button> appears as "button, Save". A <div onclick="save()"> appears as… nothing. The screen reader ignores it.

The three most-used screen readers, according to the WebAIM survey (1,568 respondents):

  • NVDA — free, open source, Windows
  • JAWS — paid, Windows, widely used in enterprise
  • VoiceOver — built into macOS and iOS, no installation required

The user doesn't read the page top to bottom like an eye. They jump between headings, landmarks, links, and form fields. Semantic HTML provides these signposts. Without it, navigating is like searching for information in a 10,000-word plain text file.

#What developers often confuse

Screen reader ≠ speech synthesis. Speech synthesis turns text into sound, period. The screen reader interprets document structure — headings, lists, landmarks, component states — and uses speech synthesis as an output channel. Without semantic HTML, the screen reader has nothing to interpret.

Testing with one screen reader isn't enough. NVDA and JAWS don't convey the same content in the same way. An aria-describedby will be read automatically by one, ignored until a specific action by the other. WebAIM recommends testing with at least two screen readers on two different browsers.

Hiding visually ≠ hiding from screen readers. display: none and visibility: hidden remove the element from the accessibility tree. To hide text visually while keeping it accessible, use a CSS class like sr-only:

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

#In summary

A screen reader reads your code, not your design. Semantic HTML (<nav>, <main>, <h1>–<h6>, <button>) gives it structure. ARIA fills in what native HTML doesn't cover. Test with at least two screen readers — NVDA and VoiceOver are free.

Back to glossary
Share this article

Learn more

Assistive Technologies

Assistive technologies are the software and hardware that people with disabilities use to navigate the web: screen readers, magnifiers, voice commands, braille displays, switches. They depend entirely on the quality of the HTML code to function correctly.

Accessible Name

The accessible name is the text that assistive technologies use to identify an interface element. The browser calculates it according to a W3C algorithm by consulting multiple sources in a strict priority order: aria-labelledby, aria-label, HTML <label>, text content, and finally the title attribute as a last resort.

ARIA

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that describe interface components to assistive technologies. A custom button, a tabbed system, a dynamic notification: when semantic HTML is not enough, ARIA adds the missing information. But an ARIA attribute without the corresponding behavior does more harm than good.