Testing Guides
Screen Reader Testing Guide
Screen readers convert page content to synthesized speech or braille output. Testing with a screen reader is the closest you can get to experiencing your site the way a blind or low-vision user does. Automated tools like SweepHound catch structural issues (missing alt text, broken ARIA) but can't evaluate whether your site actually makes sense when read aloud.
Popular screen readers
| Screen reader | Platform | Cost |
|---|---|---|
| VoiceOver | macOS, iOS | Free (built-in) |
| NVDA | Windows | Free (open source) |
| JAWS | Windows | Paid ($95/yr or $1,000 perpetual) |
| TalkBack | Android | Free (built-in) |
For web testing, start with VoiceOver (if you're on a Mac) or NVDA (if you're on Windows). Both are free and cover the majority of real-world screen reader usage on desktop.
VoiceOver quick start (macOS)
- Toggle on/off:
Cmd + F5 - Next element:
VO + Right Arrow(VO = Ctrl + Option) - Previous element:
VO + Left Arrow - Activate:
VO + Space - Read all:
VO + A - Open rotor (landmarks, headings):
VO + U
NVDA quick start (Windows)
- Toggle on:
Ctrl + Alt + N - Next element:
TaborDown Arrow - List headings:
NVDA + F7(NVDA = Insert or Caps Lock) - Next heading:
H - Next landmark:
D - Read all:
NVDA + Down Arrow
What to test
Focus your screen reader testing on these areas:
- Heading structure — can you navigate by headings and understand the page hierarchy?
- Link text — does each link make sense out of context? "Click here" and "Read more" are meaningless to a screen reader user scanning a list of links.
- Form labels — does every input announce its label? Are error messages associated with inputs?
- Image alt text — do informative images convey their content? Are decorative images skipped?
- ARIA landmarks — can you jump to the main content, navigation, and footer?
- Dynamic content — are notifications, loading states, and live updates announced?
Semantic HTML over ARIA
The first rule of ARIA is: don't use ARIA if you can use native HTML. Screen readers understand semantic elements out of the box:
<button>instead of<div onclick><nav>instead of<div role="navigation"><main>instead of<div role="main"><h1>–<h6>for logical heading hierarchy
Use ARIA only when native HTML doesn't cover your use case — custom comboboxes, tab panels, tree views. Even then, follow the ARIA Authoring Practices Guide patterns exactly.
ARIA landmarks
Landmarks let screen reader users jump directly to major page sections. Every page should have these:
| HTML element | ARIA role | Purpose |
|---|---|---|
<header> | banner | Site header (logo, primary nav) |
<nav> | navigation | Navigation links |
<main> | main | Primary page content |
<footer> | contentinfo | Site footer (legal, secondary nav) |
Common screen reader issues
- "Click here" links — screen reader users often navigate by listing all links on a page. "Click here" repeated 12 times is useless.
- Unlabeled icon buttons — a hamburger menu icon announced as "button" tells the user nothing. Add
aria-label="Open menu". - Missing heading hierarchy — jumping from h1 to h4 makes the page structure incomprehensible when navigating by heading.
- Unannounced dynamic content — toast notifications, loading spinners, and live search results need
aria-liveregions to be announced.
SweepHound's dual-engine scanner catches many of these structural issues automatically — missing landmarks, broken heading hierarchy, unlabeled buttons, and missing alt text. Try a free scan to flag common structural issues that affect screen reader users on scanned pages.