Glossary
Screen reader
A screen reader is software that converts an interface into synthesised speech or braille and lets a user navigate it with the keyboard. On the web it does not read the page top to bottom: it reads the accessibility tree the browser builds, and users move through it by heading, by landmark, by link or by form control. That is why structure, names and roles decide whether a page is usable, and why visual layout is largely irrelevant to it.
The ones in use
NVDA, free and open source on Windows, and JAWS, commercial on Windows. Together they account for the large majority of desktop use.
VoiceOver, built into macOS and iOS, which is the dominant screen reader on mobile alongside TalkBack on Android.
Narrator on Windows and Orca on Linux.
They differ in behaviour, keyboard commands and in how they interpret some ARIA. Content that works in one may not work identically in another, which is why testing in more than one is worthwhile for anything complex.
How a user actually navigates
By heading, pulling up a list of the page's headings and jumping to one. This is the most common way to explore an unfamiliar page, and it is why heading hierarchy matters.
By landmark, jumping between banner, navigation, main and footer.
By link or form control, pulling up a list of each — which is why generic link text is so costly, since a list of ten identical entries conveys nothing.
Linearly, reading through, which is the slowest and the least used on a page with structure.
Tables, lists and headings all announce their structure, so correct markup does not merely help; it is what makes the content navigable at all.
What it reads from
The accessibility tree, a parallel structure the browser derives from the DOM with computed roles, names, states and relationships.
That tree is affected by CSS: `display: none` and `visibility: hidden` remove an element from it, while off-screen positioning does not — which is the mechanism behind visually hidden text.
It is affected by ARIA, which is why incorrect attributes mislead confidently.
It reflects the rendered DOM rather than the served HTML, so content built by scripts is included once it exists.
Testing with one
Turn it on and complete a real task with the screen off, or with eyes closed. The experience is different from reading the output of a checker.
Learn four commands: start and stop reading, move by heading, move by landmark, list links. That is enough for a useful test.
Mobile is worth testing separately, since VoiceOver and TalkBack use gestures and reveal different problems.
The objective is not to become a proficient user. It is to notice the unnamed button, the heading that lies, and the form error nobody announces.
Frequently asked questions
- Do screen readers read a page from top to bottom?
- Rarely. Users navigate by heading, landmark, link or form control, which is why structure matters more than reading order alone.
- Does a screen reader see content added by JavaScript?
- Yes. It reads the accessibility tree derived from the rendered DOM, so content exists for it once it exists in the page.
- Which screen reader should I test with?
- NVDA on Windows and VoiceOver on macOS and iOS cover most real use. Testing in more than one is worthwhile for complex widgets.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website