Technique · assistive technology · practice
Screen readers and the rest of assistive technology
The act requires “compatibility” — working with assistive tools (art. 5(12)). Those tools are not an abstraction: they are a dozen specific programs, several of them free and already installed on the system you are using. This page describes what they do, what they need from your code, and how to check your own service before a consumer does it for you with a complaint under art. 37.
What they are
Screen readers
They turn an interface into speech or braille. NVDA (Windows, free, open source), JAWS (Windows, paid, the standard in many companies and public bodies), VoiceOver (built into macOS and iOS), TalkBack (Android), Narrator (Windows). They do not read the screen — they read the accessibility tree.
Magnification and contrast
Screen magnifiers (ZoomText, the system magnifier), browser zoom to 200–400 %, high contrast mode, a user’s own stylesheet. All of them need a layout that reflows — which is what criteria 1.4.4 and 1.4.10 are for.
Voice control
Dragon, Voice Control on macOS/iOS, Voice Access on Android. The user says “click Buy now” — and that only works when the visible label of the button matches its accessible name (WCAG 2.5.3, most often broken by an aria-label written in another language).
Keyboard, switches, braille
The keyboard alone, alternative keyboards, single-switch access, eye tracking, refreshable braille displays. They all speak to a page in the same language: Tab, Shift+Tab, Enter, space, arrows, Esc. If the keyboard works, most of them work.
How a screen reader sees a page
Not the way you do. A screen reader user rarely reads a page top to bottom — they navigate it like a document: H jumps between headings, D or R between landmarks (header, navigation, main, footer), F between form fields, K or Tab between links. They also open a list of every heading or every link and pick from it, the way you skim a table of contents.
So three things decide whether a page is usable, long before anyone thinks about ARIA:
- Headings describe sections and do not skip levels. The heading list is the table of contents; “Heading 3, Heading 3, Heading 3” is a table of contents with no contents.
- Link names make sense out of context. In a list of links, “read more” appears twelve times and means nothing.
- Landmarks exist —
<header>,<nav>,<main>,<footer>. Without<main>there is no way to skip the menu on every single page.
Which pairs to test
| Reader | System | Browser to test with | Note |
|---|---|---|---|
| NVDA | Windows | Firefox or Chrome | free — start here |
| JAWS | Windows | Chrome | paid; the demo runs 40 minutes per session |
| VoiceOver | macOS | Safari | built in: Cmd+F5 |
| VoiceOver | iOS | Safari | Settings → Accessibility; gestures instead of keys |
| TalkBack | Android | Chrome | the most common pairing on a phone |
A reader and a browser are one unit — the same page can behave differently in NVDA+Firefox and in NVDA+Chrome. You do not have to test every combination. One pair on the desktop and one on a phone will catch most of what no automated tool can see.
Twenty minutes worth spending
Put the mouse away
Walk the home page and the whole purchase path with Tab alone. Can you see where you are? Can you reach every button? Does Esc close the menu and the modal? After a dialog closes, does focus return where it came from?
Turn a reader on and the screen off
NVDA on Windows or Cmd+F5 on a Mac. Try to buy your own product. This is not about learning the shortcuts — the first three minutes will teach you more than a report.
Move through the headings
H in NVDA, the rotor in VoiceOver. Does the heading list alone tell the story of the page?
Submit a form with an error
Leave a field empty and send it. Did the reader say what is wrong and in which field? Did focus move there? A red border with no text is invisible to three groups at once: blind users, colour-blind users and anyone in monochrome mode.
Zoom to 200 % and narrow to 320 px
Text zoom only, not page zoom. Does anything disappear, overlap, or force scrolling in two directions?
What these tools will not fix
- “Accessibility widget” overlays. A script bolted onto a page does not know its structure; typically it duplicates the reader’s own functions, gets in its way, and removes no non-conformity at all. An enforcement body looks at the page’s code, not at the widget.
- Automatic alt text and automatic captions without review. A generated description is sometimes right; it is also sometimes confident and wrong, and on a product photo that difference is the price of the mistake.
- A separate “version for the blind” as a poorer parallel site. The act requires one accessible service, not two — a good one and one for “them”.
Where to find testers
One session with a real screen reader user is worth more than our entire report, because it answers “can this be bought”, not “is this criterion met”. Such tests are run by organisations of blind and partially sighted people and by audit firms that employ testers with disabilities. The market rate for a session is lower than one fine under art. 73 divided by a hundred. Our analyzer does the layer underneath: it checks roles, names, states, focus and contrast, so that a session with a person does not start with the things a machine can see on its own.