How people use assistive technology
Screen reader navigation modes, magnifiers and zoom, voice control, switch and keyboard-only use, captioning, and how to test with real users.
Screen readers are not one behaviour
A screen reader reads the accessibility tree, not the pixels. It has two modes: a browse mode that moves element by element through headings, links, landmarks and text, and a forms mode that passes keystrokes straight to a focused control. Most confusing screen reader behaviour is the user switching between those modes.
| Technique | What it does | Why your markup matters |
|---|---|---|
| Headings list | Lists every heading with its level | A skipped level makes the outline wrong |
| Landmark navigation | Jumps between header, nav, main, footer | Generic divs give no landmarks at all |
| Links list | Lists links by their accessible name | Link text is read out of context, so "read more" is useless |
| Form field list | Lists inputs and their labels | An unlabelled input appears as "edit text" |
| Table mode | Navigates cells with header context | Header cells must be real th elements |
| Tab through controls | Moves between focusable elements | Focus order must follow the visual order |
<!-- what a screen reader announces depends entirely on this markup -->
<nav aria-label="Breadcrumb">
<ol>
<li><a href="/guides">Guides</a></li>
<li><a href="/guides/dns" aria-current="page">DNS</a></li>
</ol>
</nav>
<!-- without a label, this is announced as an unnamed navigation region -->
<nav>...</nav>- Reading speed varies enormously between users. A screen reader at 400 words per minute is not unusual, which is why verbose announcements are a real cost.
- Users often listen while doing something else, so a page that requires visual scanning to make sense of is a page that cannot be skimmed by ear.
- Announcements are linear. A layout where the visual order and the DOM order disagree produces a spoken page that reads as nonsense.
Magnification, voice, switches and captions
| Assistive technology | How it is used | What breaks it |
|---|---|---|
| Screen magnifier | A region magnified to fill the screen | Content that only appears on hover, fixed headers over the focused field |
| Browser zoom | Everything enlarged, reflow expected | Horizontal scrolling at 400 percent, clipped fixed-width containers |
| Voice control | Speak a visible label to click it | Labels that do not match the visible text, icon-only buttons |
| Switch access | One or two switches scanning through controls | Excessive focusable elements, no visible focus |
| Keyboard only | Tab, arrow keys, Enter, Space, Escape | Div-based controls with no key handling |
| Captions | Deaf and hard of hearing users | Auto-generated captions with no review |
| Transcripts | Deafblind users, anyone without audio | Video with no text alternative |
<!-- voice control matches the visible text - keep them identical -->
<button type="submit">Save changes</button>
<!-- this button cannot be activated by voice, because the label is a picture -->
<button type="submit" aria-label="Save changes"><svg aria-hidden="true">...</svg></button>
<!-- captions need a real track, not an auto-generated guess -->
<video controls>
<source src="/talk.mp4" type="video/mp4" />
<track kind="captions" src="/talk.en.vtt" srclang="en" label="English" default />
<track kind="descriptions" src="/talk.descriptions.en.vtt" srclang="en" label="Audio description" />
</video>aria-labeloverrides the visible text for everyone, including voice control. When a visible label exists, use it as the name rather than replacing it.- Magnifier users see a small area at a time. A control that appears far from the thing that triggered it is effectively invisible.
- Switch users scan through every focusable element. Reducing tab stops is an accessibility improvement, not a regression.
Testing with real users
- Do the automated pass first, so the session is not spent on mechanical defects a scanner would have found.
- Recruit people who actually use the technology daily. Someone borrowing a screen reader for an hour finds different things from someone who has used one for a decade.
- Give them a task, not a checklist. "Find the invoice for March and download it" reveals the barriers a list of criteria does not.
- Watch where they slow down or repeat an action. Hesitation is a finding even when the task completes.
- Pay them, and pay them properly. Accessibility testing is skilled work, not a favour.
- Fix and re-test with the same people. A fix that does not help the user who reported the problem is not a fix.
When there is no budget for a study
install a screen reader and complete your primary task with the screen off
complete the same task using only the keyboard
zoom the browser to 200 percent and then 400 percent
turn on the operating system's reduced motion setting
use voice control for one form on your phone
Five sessions of an hour each find more than any scanner.💡
Assistive technology users are not a small edge case to be accommodated at the end. Every technique above also makes the interface work better for someone with a temporary injury, a bright screen, a noisy room or a slow connection - which is a large share of your users on any given day.
FAQ
Which screen readers should I test with?
At minimum one with each major browser and platform combination you support. Exact combinations change over time, so test with the pairings your users actually report rather than a list from an old article.
Is automated testing enough?
No. Scanners catch roughly a third of issues, and mostly the mechanical ones. Nothing automated can tell you whether a heading describes the section or whether an error message is understandable.
Related
Focus management, ARIA and testing Auditing, remediation and compliance reporting
Last refreshed 2026-09-18.