How to Test a Website with a Screen Reader

Why Screen Reader Testing Matters

Approximately 7.6 million people in the United States alone use screen readers to navigate the web. These users rely entirely on the text that assistive technology announces. If your button says nothing, if your form field has no label, or if your navigation structure is invisible to the accessibility tree, these users cannot complete their tasks.

Automated rule checkers (like axe-core) catch technical violations: missing alt text, invalid ARIA attributes, insufficient color contrast. But they cannot tell you what the experience sounds like. A button might pass every automated rule and still announce as "button" with no name. A navigation might have perfect ARIA markup but announce items in a confusing order.

Testing with a screen reader answers the question: "Can someone who cannot see the screen understand and use this interface?" There is no substitute for hearing it yourself.

Step-by-Step Manual Testing

Each screen reader has different keyboard shortcuts and navigation modes. Below are step-by-step instructions for the four major screen readers. You do not need to test with all four every time, but testing with at least two (typically VoiceOver and NVDA) gives good coverage of platform-specific differences.

Testing with VoiceOver (macOS)

VoiceOver is built into every Mac. No installation required.

1. Press Cmd + F5 to toggle VoiceOver on.
2. Open your page in Safari (VoiceOver works best with Safari on macOS).
3. Press VO + Right Arrow (VO is Ctrl + Option) to move to the next element.
4. Press VO + Left Arrow to move to the previous element.
5. Press VO + U to open the Rotor (headings, links, landmarks, form controls).
6. Press VO + Space to activate (click) the current element.
7. Use VO + Cmd + H to jump between headings.

What to listen for: Does each interactive element announce its name and role? Do form fields announce their labels? Is the heading structure logical? Can you reach all interactive elements with the keyboard?

Testing with NVDA (Windows)

NVDA is free, open-source, and the most widely used screen reader on Windows. Download it from nvaccess.org.

1. Launch NVDA (it will start speaking immediately).
2. Open your page in Chrome or Firefox.
3. Press Down Arrow to move through elements in browse mode.
4. Press Tab to move between interactive elements (focus mode).
5. Press H to jump to the next heading.
6. Press D to jump to the next landmark.
7. Press Enter or Space to activate elements.
8. Press Insert + F7 to open the Elements List (all links, headings, landmarks).

NVDA uses "browse mode" by default, reading the page as if it were a document. When you enter a form field or interactive widget, it switches to "focus mode" where keystrokes go to the page instead of being intercepted as navigation commands.

Testing with JAWS (Windows)

JAWS is a commercial screen reader widely used in enterprise environments. It offers a 40-minute trial mode that restarts after reboot.

1. Launch JAWS and open your page in Chrome, Firefox, or Edge.
2. Press Down Arrow to read the next line.
3. Press Tab to move between form controls and links.
4. Press H to jump to headings, T for tables, F for form fields.
5. Press Insert + F6 to see the heading list.
6. Press Insert + F5 to see all form fields.

JAWS tends to be more verbose than NVDA. It provides additional context from parent containers and sometimes reads table coordinates. If your component sounds too wordy in JAWS, that often indicates redundant ARIA attributes.

Testing with Narrator (Windows)

Narrator is built into Windows 10 and 11. It works best with Microsoft Edge.

1. Press Win + Ctrl + Enter to toggle Narrator on.
2. Press Caps Lock + Right Arrow to move to the next item.
3. Press Caps Lock + Down Arrow to interact with groups.
4. Press H in scan mode to jump between headings.
5. Press Tab to move between interactive elements.

Narrator is less commonly used by daily screen reader users, but testing with it reveals how Microsoft's accessibility APIs interpret your markup. It often provides interaction hints (like "to activate, press Enter") that other readers omit.

Common Issues to Listen For

When testing with any screen reader, pay attention to these categories of problems:

• Silent buttons: The screen reader says "button" with no name. This means the button has no accessible name (no text content, no aria-label, no aria-labelledby).
• Unlabeled form fields: You hear "edit" or "text field" without knowing what to type. The input lacks an associated label element or aria-label.
• Missing headings: You cannot jump between sections because the page has no heading structure, or headings skip levels (H1 to H3).
• Invisible landmarks: There is no "navigation", "main", or "banner" region, so keyboard users cannot jump between major page areas.
• Redundant announcements: The screen reader says "navigation link, Home, link" because ARIA roles and native semantics overlap unnecessarily.
• State not communicated: A toggle looks pressed on screen but the screen reader never says "pressed" or "expanded" because aria-pressed or aria-expanded is missing.
• Focus order confusion: Tab order does not match visual order, making the interface unpredictable when navigated by keyboard.
• Trapped focus: You enter a modal or dropdown and cannot Tab out of it.

Each of these issues creates a different failure mode for screen reader users. Some are complete blockers (cannot complete a task) while others are confusing but navigable.

Automating the Repetitive Parts

Manual screen reader testing is essential for understanding the full user experience, but it is slow and platform-specific. Much of what you listen for during manual testing (accessible names, role announcements, state communication) can be predicted from the HTML alone. This is where Speakable fits in.

Using Speakable to Preview Output Before Manual Testing

Before spending time with a real screen reader, run Speakable to get a quick preview of what each reader will likely say:

# Preview what all four screen readers will announce
npx @reticular/speakable login-form.html -f text -s all

# Output:
# === NVDA ===
# Email address, edit, required
# Password, edit, required
# Remember me, check box, not checked
# Sign in, button
#
# === VoiceOver ===
# Email address, required, text field
# Password, required, secure text field
# Remember me, unchecked, checkbox
# Sign in, button
#
# === JAWS ===
# Email address, edit, required
# Password, edit, required
# Remember me, check box, not checked
# Sign in, button
#
# === Narrator ===
# Email address, edit, required, to edit text press Enter
# Password, edit, required, to edit text press Enter
# Remember me, check box, not checked
# Sign in, button, to activate press Enter

If this output looks wrong (a field missing its label, a button with no name), you can fix the issue immediately without even launching VoiceOver or NVDA. This saves minutes per component during development.

Setting Up Regression Guards

Once you have verified the screen reader output manually, save the expected output as a baseline. Speakable can then diff against that baseline on every pull request, catching regressions automatically. See the regression testing guide for detailed setup instructions.

A Combined Testing Workflow

The most effective approach combines predictive and manual testing at different stages of development:

1. During development: Run Speakable locally to preview announcements as you write markup. Fix obvious issues (missing names, broken hierarchy) immediately.
2. In CI: Run Speakable in audit mode on every pull request. Fail the build if critical issues are found (no-name buttons, missing landmarks).
3. Before release: Schedule a manual testing session with VoiceOver and NVDA. Focus on interaction patterns, timing, and overall navigation flow.
4. After launch: Test the production site with a screen reader to catch server-rendered or hydration-related issues that do not appear in static HTML.

This workflow catches markup-level issues early (where they are cheapest to fix) and reserves expensive manual testing for the things only a human can evaluate: whether the flow makes sense, whether timing is appropriate, and whether the experience is comfortable for extended use.

Resources and Next Steps

Learning to test with screen readers is a skill that improves with practice. Here are some resources to continue building your expertise:

• The Screen Reader Testing Checklist provides a structured list of items to verify during each session.
• The Screen Reader Comparison page details how NVDA, JAWS, VoiceOver, and Narrator differ in their handling of common patterns.
• WebAIM's screen reader survey publishes annual data on which screen readers are most used and with which browsers.
• The ARIA Authoring Practices Guide (APG) provides expected keyboard interactions for every common widget pattern.
• Deque University offers free courses on screen reader testing methodology.

Start with one screen reader. VoiceOver on macOS is a good first choice because it requires no installation and works well with Safari. Test a single page, fix the issues you find, and then expand to a second reader. Over time, the keyboard shortcuts become muscle memory and testing goes faster.