Automated checkers catch the obvious problems—missing alt attributes, low contrast, malformed ARIA—but they cannot tell you whether a button announces its purpose, whether focus lands somewhere sensible, or whether a custom dropdown is operable at all. For those answers you need screen reader testing: actually listening to your interface the way a blind or low-vision user would.
The good news is that you do not need to be a daily screen reader user to find most defects. With a handful of commands, a clear sense of what to listen for, and a repeatable routine, developers and QA can catch the majority of issues before release. This guide covers the two readers worth starting with—VoiceOver on macOS and NVDA on Windows—and gives you a routine you can run in roughly fifteen minutes.
Why screen reader testing belongs in your workflow
A screen reader converts the rendered page into speech, driven by the browser's accessibility tree—the structured representation built from your HTML semantics and ARIA. When that tree is wrong, the experience breaks in ways a sighted developer never sees: an icon-only button announced as just "button," a modal that does not trap focus, a form error no one is told about. These map directly to WCAG 2.2 success criteria such as 1.3.1 Info and Relationships, 2.4.3 Focus Order, and 4.1.2 Name, Role, Value.
This matters legally as well as ethically. The European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025 and sets its baseline at WCAG 2.2 Level A and AA, referenced through EN 301 549. Several of those criteria simply cannot be verified by looking at the screen—you have to listen. Manual screen reader checks are how you confirm the accessibility tree your code produces is the one users actually receive.
Setting up: VoiceOver and NVDA
Pick the reader that matches your platform, and remember that each screen reader is tuned to work best with a specific browser. Testing the wrong pairing produces misleading results.
- VoiceOver (macOS): built in, no install. Toggle it with Cmd + F5. Pair it with Safari, its native browser. On iOS, enable it under Settings > Accessibility > VoiceOver.
- NVDA (Windows): free and open source, and one of the most widely used readers, alongside JAWS. Download it, then pair it with Chrome or Firefox. The Insert key is its default modifier (the "NVDA key").
- Headphones help you concentrate on the speech, and slowing the speech rate while you learn makes commands far easier to follow.
A note on muscle memory: VoiceOver commands use the VO modifier (Control + Option), while NVDA uses Insert. The concepts are identical even though the keystrokes differ, so once you learn the routine on one reader, the other comes quickly.
Basic commands worth memorizing
You can do effective screen reader testing with a small command set. Start here and expand later.
VoiceOver (with Safari)
- VO = Control + Option (hold both as the modifier).
- VO + A: read continuously from the cursor.
- VO + Right Arrow / Left Arrow: move through elements one at a time.
- Control: stop speech instantly.
- VO + U: open the rotor, then arrow through headings, links, form controls, and landmarks.
- Tab: move between focusable controls, exactly as a keyboard user would.
NVDA (with Chrome or Firefox)
- NVDA key = Insert.
- Down Arrow: read the next line; NVDA + Down Arrow reads continuously.
- H: jump to the next heading (Shift + H for previous). Numbers 1–6 jump by heading level.
- F: next form field. B: next button. K: next link. D: next landmark.
- Insert + F7: open the Elements List to scan all headings, links, or landmarks at once.
- Tab: move through focusable controls.
The single most useful habit is navigating by heading and by landmark. If you can press H (NVDA) or use the rotor (VoiceOver) and hear a sensible outline of the page, your document structure is probably sound. If headings are missing, out of order, or there are none at all, that is your first bug—and it affects how every screen reader user orients themselves.
What to listen for
Knowing the commands is half the job; the other half is knowing what counts as a defect. Listen specifically for these:
- Name: does every control announce a meaningful label? An icon button that says only "button" fails. A link that says "click here" out of context is weak. This is the most common defect in screen reader testing.
- Role: is the element announced as what it is—button, link, checkbox, heading? A clickable <div> with no role is announced as plain text and cannot be operated, a frequent failure in custom components.
- State: do toggles, expanded menus, checked boxes, and selected tabs announce their current state? Listen for "expanded," "collapsed," "selected," "checked."
- Focus order: as you Tab through the page, does focus move in a logical sequence and stay visible? Watch for focus jumping off-screen or getting trapped. WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum, AA), so also check that focused elements are not hidden behind sticky headers.
- Announcements: when content changes—an error appears, a result loads, a toast shows—is it announced via a live region, or does it pass silently? Silent dynamic updates are a classic, invisible bug.
- Images and media: is meaningful imagery described, and is decorative imagery silent (empty alt)? Judge each image by what the surrounding context already conveys.
Two patterns deserve extra attention. Forms are where users get stuck most often: every input needs a programmatically associated label, and errors must be announced, not just shown in red. Custom widgets—comboboxes, modals, tab panels, date pickers—are where ARIA goes wrong; they should follow established authoring patterns rather than ad-hoc roles.
A simple, repeatable test routine
Run this same sequence every time so results are comparable across builds. On a typical page it takes ten to fifteen minutes.
- 1. Listen to the page top to bottom. Use VO + A or NVDA + Down Arrow and just listen once. Note anything confusing, skipped, or repeated.
- 2. Navigate by heading. Press H (NVDA) or use the rotor (VoiceOver). Confirm a logical outline with no skipped levels and no missing headings.
- 3. Navigate by landmark and link. Jump through regions (D in NVDA) and pull up the links list. Check that link text makes sense out of context.
- 4. Tab through every interactive element. Confirm each has a name, the correct role, an announced state, a visible focus indicator, and logical order. Keyboard and screen reader testing reinforce each other here.
- 5. Exercise the key flow. Complete the page's main task—submit the form, open and close the modal, trigger an error. Confirm validation messages and status changes are spoken.
- 6. Log defects by criterion. Record what you heard, what you expected, and the relevant WCAG reference so the fix is unambiguous.
Sequence your tools for efficiency. Run an automated scan first to clear the mechanical issues, then spend your manual screen reader time on the judgment calls a scanner cannot make. A free pass with AccessScan at our scanner flags missing labels, contrast failures, and ARIA mistakes in seconds, leaving you free to focus on whether the experience actually makes sense. For where automation stops and manual testing begins, see automated vs manual accessibility testing.
Build the routine into your process: a quick smoke test (steps 1, 4, and 5) on every UI pull request, and the full six-step pass before release. To see how these checks ladder up into the wider standard, the WCAG reference breaks down each criterion, and the accessibility checklist turns them into pass/fail items your team can track.