Screen readers are the most common assistive technology for blind and low-vision users, translating the accessibility tree into speech or braille. Understanding how they navigate is the difference between accessible markup and markup that merely looks compliant.
2The Accessible Name Computation
The 'accessible name' is the single string a screen reader speaks to identify a control. Browsers compute it via a strict priority order defined by the W3C: aria-labelledby wins first, then aria-label, then an associated <label for>, then, for some elements, visible text content or placeholder as a last resort.
This ordering matters because it's a common source of silent, hard-to-detect bugs: a developer updates the visible label text during a redesign but forgets a stale aria-label still overrides it, so sighted QA sees the correct new text while screen reader users hear the outdated one.
3A Fast, Repeatable Manual Test
You don't need to master a screen reader's full command set to catch most bugs. A five-minute pass covers the highest-value checks: turn the screen off (or trust your eyes-closed discipline), tab through the entire interactive surface of the page, and confirm every control announces a role, a name, and, where relevant, a state.
On macOS, Cmd+F5 toggles VoiceOver. On Windows, NVDA is free and open source. Both ship keyboard shortcuts for jumping by heading (H), landmark (D or R), and form field (F), which map directly to the structural navigation model from the first section.
4Step-by-Step Breakdown
Hearing Your HTML. A screen reader converts the accessibility tree into synthesized speech or braille output, letting users navigate by headings, landmarks, and form controls instead of scanning visually. Testing with one, even briefly, is the single fastest way to understand real accessibility gaps.
Screen Readers Navigate By Structure, Not Position. Sighted users scan a page spatially. Screen reader users typically jump between landmarks and headings using single keystrokes, essentially treating your document outline as a table of contents. A page with no heading hierarchy forces them to read linearly through everything.
Structural Navigation. A screen reader user presses 'H' repeatedly to skim a page. What are they actually navigating between?
- →Every paragraph on the page
- →Heading elements (h1-h6), in document order
- →Every hyperlink, regardless of heading level
The Accessible Name Is What Gets Spoken. Every interactive element has one computed 'accessible name' the screen reader announces. It comes from an algorithm called the accessible name computation, which checks, in priority order, aria-labelledby, aria-label, associated label text, then visible text content.
Accessible Name Computation. An <input> has both a visible <label> and an aria-label attribute with different text. Which one does the screen reader announce?
- →The visible <label> text
- →The aria-label attribute
- →Both, concatenated together
Testing With A Real Screen Reader. macOS ships VoiceOver (Cmd+F5), Windows has the free NVDA, and mobile platforms include TalkBack and VoiceOver for iOS. A five-minute pass, tabbing through your page with the display off, catches issues that visual review and linters both miss entirely.
Manual Testing. Why is testing with the monitor physically off a useful accessibility exercise, even briefly?
- →It's just a party trick with no real diagnostic value
- →It forces total reliance on the screen reader, surfacing gaps visual review hides
- →It makes the screen reader run measurably faster
Screen Reader Fluency. You now understand how screen readers convert structure into navigable speech, how the accessible name computation decides what gets announced, and how to run a real five-minute manual test — the most direct feedback loop in accessibility engineering.
Add Screen-Reader-Only Text. The common .sr-only pattern hides text visually while keeping it available to screen readers.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Structural Navigation Is The Primary Screen-Reader Workflow
Most users jump by heading, landmark, and form-field shortcuts rather than reading linearly, which is why a correct heading hierarchy is one of the highest-leverage accessibility fixes available.
2The Accessible Name Computation Has A Strict, Learnable Priority Order
aria-labelledby beats aria-label, which beats an associated <label>, which beats visible text content — understanding this order prevents silent naming bugs during redesigns.
SEO Implications
- 1
Heading Hierarchy Doubles As An SEO Signal
Search engines use heading structure to understand topical hierarchy on a page, the same structure that drives screen-reader H-key navigation — fixing one improves the other.
- 2
Descriptive Accessible Names Improve Voice Search Matching
Voice assistants and search snippets increasingly rely on the same accessible-name and label text that screen readers consume, making accurate labeling a dual-purpose investment.
Best Practices
Run A Five-Minute Screen-Reader Pass Before Every Major Feature Ships
It catches structural and naming bugs that automated linters and visual QA both miss, and takes less time than a typical code review round-trip.
Never Let aria-label Silently Diverge From Visible Text
If a visible label exists, prefer letting it be the accessible name rather than duplicating (and risking desynchronizing) it in an aria-label attribute.
Frequent Bugs
A button's visible text was updated in a redesign, but screen readers still announce the old wording.
A stale aria-label is overriding the accessible name computation. Remove the aria-label so the current visible text is used, or update it to match exactly.
A screen reader user reports 'everything sounds the same, I can't find the search box.'
The page lacks heading and landmark structure, forcing linear reading. Add a proper heading hierarchy and semantic landmarks (`<nav>`, `<main>`, `<search>`).
Real-World Examples
Landmark-Driven Page Skeleton
A dashboard restructured so screen reader users can jump directly to the main content region with a single keystroke.
<header>...</header>
<nav aria-label="Main">...</nav>
<main>
<h1>Dashboard</h1>
</main>
<footer>...</footer>