Automated accessibility checkers find many errors, but they do not tell you what it is really like to use a page without seeing it. To understand that, you have to listen to it. A screen reader is a program that reads aloud, or sends to a braille display, the content and structure of an interface. Learning the basics takes an afternoon and changes the way you look at your own work.
One thing should be said straight away: a sighted person trying a screen reader for the first time does not become an expert user. People who use one every day go much faster, set the voice to very high speeds and know advanced shortcuts. The test is for finding obvious defects, not for simulating the real experience.
Which screen reader to use
| System | Screen reader | Notes |
|---|---|---|
| Windows | NVDA | Free and open source, widely used |
| Windows | JAWS | Commercial, used mainly in workplaces |
| Windows | Narrator | Built into the system |
| macOS and iOS | VoiceOver | Built into the system |
| Android | TalkBack | Built into the system |
To get started on a computer, NVDA with Firefox or Chrome on Windows, or VoiceOver with Safari on a Mac, are sensible combinations. On mobile it is worth trying both VoiceOver on iPhone and TalkBack on Android, because they behave differently.
The essential commands
In NVDA, the default modifier key is Insert (or Caps Lock, if configured). Some useful commands in browse mode on web pages:
- Down / Up arrow: reads the next or previous line;
- H / Shift + H: jumps to the next or previous heading;
- 1, 2, 3…: jumps to a heading of that level;
- K: next link; F: next form field; T: next table; D: next landmark (such as the header or main content);
- Insert + F7: opens the list of headings, links and landmarks;
- Ctrl: stops speech.
On a Mac, VoiceOver is turned on with Cmd + F5 and uses Ctrl + Option as its modifier. The rotor, opened with Ctrl + Option + U, shows lists of headings, links and fields. On iPhone and Android you navigate by swiping right or left with one finger and activate an element with a double tap.
What to listen for
During the test it helps to focus on a few concrete questions.
Does the structure make sense?
Opening the list of headings is the quickest way to see whether the page is well organised. Many screen reader users navigate exactly like this, jumping from one heading to the next. If the list is empty, or the headings are bold text without markup, the page is a single block that is hard to explore.
Does every element say what it is and what it does?
A button should be announced as «Add to cart, button», not just «button», nor as plain text. A field should state its label: «Email, edit text». A checkbox should say whether it is checked or not.
Do links make sense out of context?
In the list of links, ten entries reading «Read more» or «Click here» are indistinguishable. The link text should say where it leads.
Are changes announced?
When a product is added to the cart, an error appears in a form or a filter updates the results, people who cannot see need to know. If the screen reader stays silent, the user has no way of noticing that something happened.
Do images have sensible alternatives?
Listening to how images are read out quickly reveals file names, useless descriptions or missing information.
Problems that come up often
- headings used for visual styling rather than structure, with levels skipped or chosen at random;
- icon-only buttons announced as «button» with no name;
- forms where the error message only appears in red, without being read out;
- modal dialogs from which the screen reader escapes and reads the page underneath;
- duplicated content, for example the same text read twice because it is in both the image and the caption;
- tables used for layout, read out as meaningless data grids.
Running a test session
A simple method that works:
- Choose two or three realistic tasks, such as finding a piece of information, filling in a form, completing a purchase.
- Turn off the screen, or at least do not look at it, so you do not compensate with your eyes.
- Carry out each task, noting where you get stuck, what you do not understand and what is read out strangely.
- Repeat the test on at least one mobile combination.
- Rank the problems by severity: first those that prevent the task from being completed.
When the budget allows, the next step is to involve people who really use a screen reader every day. Their feedback is on another level and often reveals problems a sighted person would not notice.
In short
- Listening to a page reveals defects that automated tools do not see.
- NVDA, VoiceOver and TalkBack are free or built in: there is no excuse not to try them.
- The list of headings and the list of links are the first things to check.
- Every control must announce its name, role and state; dynamic changes must be communicated.
- A sighted person's test does not replace feedback from real screen reader users.
