What is a screen reader and how does it read your site?

What is a screen reader?

A screen reader is software that converts what is on a screen into synthesised speech or refreshable braille, so someone who cannot see the display can still operate the machine. On the web that means it reads your page aloud, announces what each element is, and lets the user move around with the keyboard.

The ones in real use are NVDA and JAWS on Windows, VoiceOver built into macOS and iOS, and TalkBack on Android. NVDA and VoiceOver are free, which matters for the testing advice further down. They are not browser extensions or accessibility widgets bolted onto a site; they are part of the user’s operating system, and they were running long before the visitor reached your page.

The important part for anyone building a website is what the screen reader is actually reading, because it is not what you see.

What does a screen reader actually read?

Not your pixels. The browser builds an accessibility tree from your DOM, recording a role (button, heading, link), a name (“Submit order”) and a state (expanded, checked, disabled) for every element. The screen reader reads that tree, so anything your markup fails to express simply is not there.

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, which is no coincidence.)

How do screen reader users navigate a page?

By jumping, not by listening from the top. Users pull up lists of headings, landmarks, links or form controls and move directly to what they need, which is why your structure decides whether the page is usable rather than merely readable.

Watch an experienced screen reader user and the tape is fast. The core moves:

Jumping by heading

The single most common navigation strategy, and the data backs that up: in WebAIM’s tenth screen reader user survey, 88.8% of 1,539 respondents said heading levels were very or somewhat useful for navigation, rising to 78% actual usage among advanced users. 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 like <nav>, <main>, <header>, <footer> and <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.

What breaks screen reader navigation?

Six failures account for most of it, and every one is catchable before you ship: a missing heading outline, unlabelled controls, div-and-span interactivity, focus mismanagement, unannounced dynamic updates and images without alt text.

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.

How can I test my site with a screen reader?

Turn one on and spend ten minutes. VoiceOver ships with every Mac and NVDA is a free Windows download, and five checks (headings list, links list, a form, your dialogs, and Escape behaviour) will surface the large majority of structural failures.

You don’t need to be an expert user to catch the big failures:

1. Turn one on. VoiceOver ships with every Mac (Cmd+F5); NVDA is a free download on Windows.
2. Pull up the headings list. Does the outline describe the page? Could you find the section you want?
3. Pull up the links list. Does every link make sense out of context?
4. Tab through your main form. Does each field announce a sensible label? Do errors get announced?
5. 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

What is a screen reader?

Software that converts on-screen content into synthesised speech or refreshable braille, so people who cannot see the display can operate a computer. On the web it reads the accessibility tree the browser builds from your markup, which is why an element that only looks like a button is announced as nothing useful. The common ones are NVDA and JAWS on Windows, VoiceOver on Apple devices and TalkBack on Android.

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 such as button, a, nav, label and 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.