How Screen Readers Work

What is a Screen Reader?

A screen reader is a software application that translates on-screen content into synthesized speech or braille output, enabling people who are blind or have severe visual impairments to use computers and smartphones. Screen readers don’t simply read text — they interpret the entire user interface, describing the type of each element, its current state, and its relationships to other elements.

Screen reader usage spans a wide demographic. While blind users are the most common group, screen readers are also used by people with low vision, cognitive disabilities, learning differences like dyslexia, and sighted developers who want to verify their accessibility implementations.

WebAIM Screen Reader User Survey #10 (2024) asked 1,539 respondents to identify their primary desktop/laptop screen reader. The answers below describe that self-selected survey population, not global market share and not mobile usage:

JAWS is a commercial Windows screen reader from Freedom Scientific. NVDA is a free, open-source Windows screen reader. VoiceOver is built into Apple platforms, TalkBack is commonly used on Android, and Narrator is built into Windows. Usage and behavior depend on platform, browser, task, settings, language, and user preference. This site’s interactive tool predicts selected semantics from a small HTML example; it does not model or replace any real screen reader.

Browse Mode vs. Focus Mode

One of the most important concepts for developers to understand is that screen readers operate in at least two distinct modes, and the mode determines how keyboard input is interpreted.

Browse Mode (also called Reading Mode or Virtual Cursor Mode)

When a screen reader user arrives at a web page, they are typically in browse mode. In this mode, the screen reader creates an internal representation of the page — called the virtual buffer — and the user navigates through it using a special cursor that the screen reader controls, not the browser.

In browse mode, many desktop screen-reader and browser combinations use single letters as navigation shortcuts. For example, H may move to a heading and B to a button. Whether a key reaches the page depends on the screen reader, browser, current mode, settings, and focused control.

This variability is one reason single-character shortcuts need a way to be turned off, remapped, or active only while a relevant control has focus under WCAG 2.1.4 Character Key Shortcuts . Modifier keys reduce some conflicts, but no shortcut is universally safe without testing.

Focus Mode (also called Forms Mode or Application Mode)

When a user enters an editable control or operates a composite widget, many desktop screen readers switch to an interaction mode in which relevant keys reach the focused control. Mode names, automatic switching, sounds, and Escape behavior differ among products and settings.

Mode switching also happens in reverse: pressing Escape from a text field typically returns to browse mode.

Why This Matters for Developers

• Provide the WCAG-required control for character-key shortcuts, and do not make a shortcut the only route to functionality
• Start with native controls. When a custom composite is necessary, follow its WAI-ARIA Authoring Practices pattern and keyboard model. role="application" is exceptional and is not a general fix for custom widgets
• Live-region delivery is affected by timing, browser, screen reader, settings, and whether the update is relevant; it is not guaranteed in every context
• Rotor and element lists give users an overview of the page structure without needing to read everything

How Users Actually Navigate

Most developers assume that screen reader users read pages top-to-bottom, word by word, like listening to a long audiobook. In reality, this is the exception, not the rule.

In WebAIM Survey #10, 71.6% of respondents chose headings as the first way they would try to find information on a lengthy web page. That makes headings a high-value navigation structure, while still reflecting one question answered by a self-selected survey population.

The most common navigation strategies, in rough order of frequency:

1. Headings — Used to scan page structure and jump to relevant sections. Heading levels should represent a coherent hierarchy; moving from a subsection <h3> back to the next sibling <h2> is logical.
2. Landmarks — HTML5 landmark elements (<main>, <nav>, <header>, <footer>, <aside>, <form>) and their ARIA equivalents create named regions. Users can pull up a list of all landmarks and jump directly to any of them. A page without landmarks forces users to read from the top every time.
3. Links — Users frequently pull up a list of all links on a page to find what they’re looking for. Link text that says “click here” or “read more” is useless in this context — every link must be distinguishable by its text alone.
4. Form fields — On pages with forms, users navigate directly to form controls.
5. Tab key — The Tab key only moves between focusable interactive elements (links, buttons, inputs, etc.). It does not move through all content. Many developers believe that testing keyboard accessibility means only pressing Tab — this misses the majority of how screen reader users actually navigate.
6. Linear reading — Used on short content or when skimming hasn’t found what the user needs. Arrow keys move through the virtual buffer element by element.

The Accessibility Tree

Web browsers maintain two parallel representations of a page: the DOM tree (the full HTML structure) and the accessibility tree (a filtered, semantically enriched version built from the DOM).

The accessibility tree is what screen readers actually read. Browsers construct it by:

1. Taking the DOM
2. Filtering out elements that are not semantically meaningful (like generic <div> and <span> elements with no role or accessible name)
3. Adding computed properties for each node: role, name, state, description, and relationships

Semantic HTML vs. Div Soup

When you write <button>Save</button>, the accessibility tree node for this element has:

• Role: button
• Name: “Save”
• State: (focusable, not pressed, not disabled)

When you write <div class="btn" onclick="save()">Save</div>, the accessibility tree node has:

• Role: (none — generic container)
• Name: (none)

The screen reader announces the button as “Save button” and the user knows they can press Enter or Space to activate it. The <div> is announced as nothing meaningful — or ignored entirely — and the user has no idea it’s interactive.

What CSS Cannot Do

A common mistake is thinking that styling conveys meaning. If an element is visually styled to look like a heading, it is not a heading unless it uses <h1>–<h6> or role="heading" with aria-level. If text is styled red to indicate an error, screen reader users won’t know it’s an error unless there’s also a text label or ARIA state.

The accessibility tree is built from HTML semantics and ARIA attributes, not CSS. Visual presentation is invisible to assistive technology.

Inspecting the Accessibility Tree

Modern browsers let you inspect the accessibility tree directly:

• Chrome DevTools: Elements panel → Accessibility tab
• Firefox DevTools: Accessibility panel (Inspector → Accessibility)
• Safari Web Inspector: Accessibility tab in the Node panel

Use these tools to verify what screen readers will actually see when they encounter your components.

Accessible Name Computation

Every interactive element needs a suitable accessible name. Browsers compute names using the Accessible Name and Description Computation specification together with host-language rules. The applicable naming sources and precedence depend on the element and role; the following list is a practical orientation, not a universal priority ladder:

1. aria-labelledby — References the text content of one or more other elements by ID. Takes highest priority because it explicitly points to labeling content that may already be visible on screen.
2. aria-label — A direct string attribute on the element. Used when there’s no visible label text, such as icon-only buttons.
3. Native HTML <label> — For form controls, a <label> element associated via for/id or wrapping the control.
4. alt attribute — For <img> elements.
5. Element text content — For buttons, links, and headings, the visible text content becomes the accessible name.
6. title attribute — Fallback of last resort. Creates a tooltip visually but is unreliable for accessible names across screen readers. Avoid relying on it.
7. placeholder attribute — Also a poor fallback. Disappears when the user types, so it’s not a substitute for a real label.

Practical Examples

<!-- Name composed from two referenced text nodes -->
<h2 id="section-title">User Profile</h2>
<span id="edit-label">Edit</span>
<button aria-labelledby="edit-label section-title">Edit</button>
<!-- Computed name: "Edit User Profile" -->
 
<!-- Name from aria-label -->
<button aria-label="Close dialog">✕</button>
<!-- Announced as: "Close dialog, button" -->
 
<!-- Name from label element -->
<label for="email">Email address</label>
<input type="email" id="email">
<!-- Announced as: "Email address, edit text" -->
 
<!-- Name from text content -->
<button>Submit form</button>
<!-- Announced as: "Submit form, button" -->
 
<!-- No accessible name — BAD -->
<button><img src="search-icon.png"></button>
<!-- Announced as: "button" — user has no idea what it does -->

Common Misconceptions

”Tab key navigates all content” — FALSE

The Tab key only moves focus between interactive elements: links, buttons, form inputs, and elements with tabindex. It skips all non-interactive content like headings, paragraphs, and images. Screen reader users access non-interactive content through browse mode navigation (arrow keys and letter shortcuts), not Tab.

This is why “keyboard accessibility” testing that only uses Tab is insufficient — it never exercises the majority of how screen reader users actually move around a page.

”Screen reader users can’t use a mouse” — MOSTLY TRUE (but nuanced)

Most blind users don’t use a mouse, but “screen reader user” doesn’t exclusively mean blind. Some users with motor impairments use both screen readers and pointing devices. Some low-vision users combine magnification software with a screen reader and still use a mouse to orient themselves spatially.

For web accessibility purposes, the safe assumption is: any functionality available via mouse must also be available via keyboard. If you build an interaction that requires hover, drag, or precision pointing, you need a keyboard-accessible equivalent.

”ARIA fixes everything” — NO

ARIA (Accessible Rich Internet Applications) attributes can add and modify semantics, but they cannot compensate for poor fundamental structure. Common mistakes:

• Adding role="button" to a <div> makes the screen reader announce it as a button, but doesn’t automatically make it focusable or respond to keyboard events — you still need tabindex="0" and keyboard event handlers.
• Adding aria-label to an image doesn’t make a broken layout navigable.
• The first rule of ARIA is: if a native HTML element or attribute exists that does what you need, use it instead of ARIA.

”If it works with a keyboard, it’s accessible” — NECESSARY BUT NOT SUFFICIENT

Keyboard accessibility is a prerequisite, not the definition of accessibility. A page can be fully keyboard-operable and still fail for screen reader users if:

• Interactive elements have no accessible names
• Dynamic content changes aren’t announced via live regions
• Focus order doesn’t match visual order and creates confusion
• Error messages appear visually but aren’t programmatically associated with their inputs
• Custom widgets don’t communicate state changes (expanded/collapsed, selected, checked)

Deaf vs. Blind Accessibility

Accessibility is not monolithic. The needs of users who are Deaf or hard of hearing are substantially different from the needs of users who are blind or have low vision, and both differ from users with motor impairments or cognitive disabilities.

Users who are Deaf primarily need:

• Captions and transcripts for audio and video content
• Visual alternatives to audio alerts and notifications
• Clear, simple language (many Deaf users have English as a second language, with American Sign Language as their first)

Users who are blind primarily need:

• Screen reader-compatible markup (the focus of this site)
• Keyboard accessibility
• Text alternatives for images and non-text content
• Logical, navigable document structure

DeafBlind users may use screen readers with refreshable braille displays, hardware that renders text as raised braille dots. Displays present a limited number of cells at once, so concise, distinguishing names and descriptions reduce repeated reading. Interactions that depend only on animation or spatial manipulation still need text-based, operable alternatives.

This site focuses on the blind/low-vision screen reader experience, since that’s the set of requirements most directly tied to HTML semantics and ARIA. The patterns demonstrated here also benefit keyboard-only users, users with cognitive disabilities who benefit from clear structure, and users on slow connections who may rely on text content when images fail to load.

For comprehensive accessibility coverage, always consult the Web Content Accessibility Guidelines (WCAG)  and consider testing with representative users from different disability groups.

Sources and testing note

• WebAIM Screen Reader User Survey #10 
• Accessible Name and Description Computation 1.2 
• WAI-ARIA Authoring Practices Guide 

Examples on this site describe programmatic semantics and expected interaction. Exact speech, braille presentation, commands, and mode changes must be verified with real screen-reader and browser combinations.