Screen reader testing basics
You do not need to be an expert to catch the worst problems. Twenty minutes with a screen reader is enough to start.
Why test with a screen reader
Automated checkers and keyboard testing catch many accessibility problems, but some only become obvious when you hear your page read aloud: buttons announced as "button" with no name, headings that do not form a sensible outline, live updates that are never announced, and images described by their file names.
Pick a pairing
Screen readers behave differently across browsers. Common combinations:
- VoiceOver with Safari on macOS and iOS, built in.
- NVDA with Firefox or Chrome on Windows, free.
- TalkBack with Chrome on Android, built in.
Start with whichever is built into a device you already have.
Learn five commands
You do not need to master a screen reader to test with it. Learn how to:
- Start and stop it.
- Read the next item.
- Jump between headings.
- Jump between links and form controls.
- Activate the focused item.
That is enough to evaluate most pages.
What to listen for
Headings
List the headings. They should form a logical outline of the page, with one top-level heading and nested levels that make sense. Visual headings that are not marked up as headings will be missing.
Names
Every interactive element needs an accessible name. Icon-only buttons are the usual offenders. A close button announced simply as "button" leaves the listener guessing.
Landmarks
Main content, navigation and footer regions should be marked up so listeners can jump between them.
Forms
Each field should announce its label, whether it is required, and any error message associated with it.
Dynamic changes
When content updates without a page load, such as a cart count changing or a message appearing, the change should be announced if it matters. Live regions handle this, but they need to exist before the content changes.
Test real tasks
Rather than reading every element, try to accomplish something: find an article and read it, add an item to the cart, submit a contact form. Task-based testing reveals problems that matter, in the order a real user would encounter them.
Fix the structure first
Most screen reader problems trace back to markup: the wrong element, a missing label, a heading that is just bold text. Fixing the structure usually resolves several issues at once and benefits search engines and keyboard users too.