( Development )
How screen readers navigate your website
Screen reader users don't read pages top to bottom — they jump by headings, landmarks, links and controls. Understanding that changes how you build.
A screen reader converts your page into speech or braille — but its users rarely listen from the top. They jump: heading to heading, landmark to landmark, link to link, using rotor menus and shortcut keys the way sighted users’ eyes dart around a layout. Whether your site is usable this way is decided entirely by your markup’s structure, because the screen reader can only navigate what your semantics expose.
The accessibility tree: what the screen reader actually sees
Screen readers don’t read your pixels. The browser builds an accessibility tree from your DOM — for each element: a role (button, heading, link), a name (“Submit order”), a state (expanded, checked, disabled). Assistive technology consumes that tree.
This explains almost everything about accessible development:
<button>Save</button>→ role button, name Save, keyboard support free.<div class="btn" onclick="save()">Save</div>→ role generic, no keyboard support. In the tree, it’s furniture.
Same pixels, completely different machine reality. (It’s also the reality AI crawlers see — no coincidence.)
How users actually move around
Watch an experienced screen reader user and the tape is fast. The core moves:
Jumping by heading
The single most common navigation strategy. Users pull up the heading list (NVDA’s elements list, VoiceOver’s rotor) or press H to hop heading to heading, skimming your outline like a table of contents. A page with one h1 and descriptive h2s skims beautifully; a page with no headings — or h1 → h4 jumps — is a wall.
Jumping by landmark
Semantic regions — <nav>, <main>, <header>, <footer>, <form> — become landmarks users hop between. “Skip to main” isn’t a courtesy link; landmarks make the whole page layout addressable.
Pulling up the links list
Users scan an alphabetical list of every link on the page, out of context. This is where “click here”, “learn more” and “read more” collapse — a list of eleven “learn more”s says nothing. Link text should describe the destination.
Tabbing through controls
Forms are navigated control to control. Each field announces its label, role and state as it’s reached — which is why an unlabelled input announces as just “edit text”, a mystery box mid-form.
Reading tables by cell
Real <table> markup with <th> headers lets users move cell to cell hearing “Column: Price, Row: Pro plan, $29”. Divs styled into a grid read as disconnected fragments.
Where builds break the experience
The recurring failures, all catchable before ship:
- Missing or broken heading outline — kills the primary navigation strategy (the fix).
- Unlabelled controls and icon buttons — “button” announced with no name.
- Div-and-span interactivity — invisible to the tab order and the tree.
- Focus mismanagement — dialogs that open without moving focus, or delete-the-element updates that dump focus to the top of the page.
- Unannounced dynamic updates — content that changes silently; live regions (
aria-live) exist for exactly this. - Images without alt text — filename soup, or silence where information was.
Test it yourself in ten minutes
You don’t need to be an expert user to catch the big failures:
- Turn one on. VoiceOver ships with every Mac (
Cmd+F5); NVDA is a free download on Windows. - Pull up the headings list. Does the outline describe the page? Could you find the section you want?
- Pull up the links list. Does every link make sense out of context?
- Tab through your main form. Does each field announce a sensible label? Do errors get announced?
- Open your dialogs. Does focus move in, stay in and come back out?
Screen reader output makes structural failures visceral in a way audit reports never do — most developers who try this once fix things the same afternoon.
The takeaway
Screen readers navigate structure, and structure is the part of your site you control completely. Semantic HTML gives you most of it for free; automated scanning catches the structural failures continuously; a ten-minute manual pass covers the judgement calls. Build the tree right, and the fastest users on your site might be the ones who never see it.
Frequently asked questions
How do screen reader users actually read a web page?
Mostly by jumping, not by listening top to bottom. Users pull up lists of headings, landmarks, links or form controls and navigate directly to what they need — the same way sighted users visually scan. A page's usability depends on how well its structure supports that jumping.
What is the accessibility tree?
A parallel structure the browser builds from your DOM containing each element's role, name, state and properties. Screen readers work from this tree, not from your pixels — so an element styled like a button but built from a div appears in the tree as nothing useful.
Do I need ARIA to make my site work with screen readers?
Far less than most teams think. Native HTML elements — button, a, nav, label, details — come with roles, names and keyboard behaviour built in. ARIA is for the gaps native HTML can't express, and incorrect ARIA is routinely worse than none. The first rule of ARIA is don't use ARIA when HTML suffices.
Which screen readers should I test with?
The majors are NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. For most teams, a free pass with NVDA plus VoiceOver on one Apple device covers the large majority of real usage.