How Do I Test with a Screen Reader? Practical Testing Guide

Automated accessibility tools are valuable, but they catch only about 30-40% of accessibility issues. The rest requires human testing—and screen reader testing is the gold standard for understanding how assistive technology users experience your site.

Many developers avoid screen reader testing because it feels unfamiliar. But basic screen reader testing isn't as hard as you think, and the insights it provides are irreplaceable. You'll find issues no automated tool catches and truly understand what accessibility means for real users.

This guide will get you started with practical screen reader testing.

Q: How do I test with a screen reader?

A: Install a screen reader (NVDA is free for Windows, VoiceOver is built into Mac), learn basic navigation commands (Tab to move between links/buttons, arrow keys to read content, H for headings), then navigate your site by listening without looking at the screen. Test key user flows: can you understand the page, find content, and complete tasks using only what the screen reader announces?

Choosing a Screen Reader

NVDA (Windows) - Recommended for Testing

NVDA (NonVisual Desktop Access) is free, open-source, and widely used. It's the best choice for developers starting screen reader testing on Windows.

To install:

1. Download from nvaccess.org
2. Run installer
3. Choose "Install on this computer" for regular testing

Key advantages:

• Free and actively maintained
• Large user base
• Good browser compatibility
• Portable version available

VoiceOver (Mac/iOS) - Built In

VoiceOver comes with every Mac and iOS device—no installation needed.

To enable on Mac:

• Command + F5 to toggle
• Or: System Settings → Accessibility → VoiceOver

To enable on iOS:

• Settings → Accessibility → VoiceOver
• Or: Ask Siri "Turn on VoiceOver"

Key advantages:

• Already installed
• Essential for testing iOS accessibility
• Integrated with macOS

JAWS (Windows) - Professional Standard

JAWS (Job Access With Speech) is the most widely used commercial screen reader, dominant in professional settings.

Considerations:

• Paid software (subscription or perpetual)
• 40-minute trial mode available
• Often used in enterprise environments
• Some behaviors differ from NVDA

For testing purposes, NVDA is usually sufficient. Test with JAWS if your users specifically report issues or if targeting enterprise users who likely use JAWS.

Narrator (Windows) - Quick Checks

Narrator is built into Windows 10/11. Toggle with Windows + Ctrl + Enter.

Good for:

• Quick checks when NVDA isn't installed
• Testing Microsoft-specific implementations

Limitations:

• Less comprehensive than NVDA/JAWS
• Smaller user base

Essential Commands to Learn

NVDA Commands

Navigation:

| Command             | Action                     |
|---------------------|----------------------------|
| Insert + Down Arrow | Read from current position |
| Ctrl                | Stop reading               |
| Tab                 | Next focusable element     |
| Shift + Tab         | Previous focusable element |
| H                   | Next heading               |
| Shift + H           | Previous heading           |
| K                   | Next link                  |
| D                   | Next landmark              |
| F                   | Next form field            |
| B                   | Next button                |
| Insert + F7         | List of links              |
| Insert + F6         | List of headings           |

Interaction:

| Command        | Action                                      |
|----------------|---------------------------------------------|
| Enter          | Activate link/button                        |
| Space          | Activate button, toggle checkbox            |
| Arrow keys     | Read by character/line, navigate in widgets |
| Insert + Space | Toggle focus/browse mode                    |

VoiceOver Commands (Mac)

Navigation:

| Command          | Action                                             |
|------------------|----------------------------------------------------|
| VO + A           | Read from current position (VO = Control + Option) |
| Ctrl             | Stop reading                                       |
| VO + Right Arrow | Next element                                       |
| VO + Left Arrow  | Previous element                                   |
| VO + Command + H | Next heading                                       |
| VO + Command + L | Next link                                          |
| VO + Command + J | Next form control                                  |

Interaction:

| Command           | Action                 |
|-------------------|------------------------|
| VO + Space        | Activate element       |
| VO + Shift + Down | Interact with element  |
| VO + Shift + Up   | Stop interacting       |
| Tab               | Next focusable element |

Rotor (quick navigation):

| Command           | Action                   |
|-------------------|--------------------------|
| VO + U            | Open rotor               |
| Left/Right arrows | Switch rotor categories  |
| Up/Down arrows    | Navigate within category |

Learning Mode

NVDA: Press Insert + 1 to toggle keyboard help mode. Press any key to hear what it does.

VoiceOver: Press VO + K to toggle keyboard help.

Setting Up for Testing

Browser Considerations

Best browser pairings:

• NVDA + Firefox or Chrome
• JAWS + Chrome
• VoiceOver + Safari

Test with combinations your users actually use. The WebAIM Screen Reader Survey shows which pairings are most common.

Environment Setup

Turn off other audio. You need to hear the screen reader clearly.

Consider headphones. Useful if testing in shared spaces; also helps you focus on audio output.

Have the page open. Load the page you're testing before starting the screen reader.

Start simply. Begin with simple pages before testing complex applications.

Practical Testing Process

Step 1: First Impression Test

Open the page and let the screen reader start reading automatically.

Listen for:

• Is the page title announced? (should be descriptive)
• Do you understand what the page is about?
• Is a language announced? (indicates lang attribute)

Step 2: Structure Exploration

Use heading navigation (H key in NVDA) to understand page structure.

Check:

• Are there headings?
• Do heading levels make sense (H1, then H2, not jumping to H4)?
• Do headings describe content sections?
• Can you build a mental map of the page?

Use landmark navigation (D key in NVDA) to find major regions.

Look for:

• Navigation landmark
• Main content landmark
• Footer/contentinfo landmark
• Search landmark (if applicable)

Step 3: Navigation Test

Tab through all interactive elements on the page.

Verify:

• Every link and button is reachable
• Focus order makes logical sense
• Focus indicator is visible (look at screen for this)
• No keyboard traps (you can Tab away from everything)
• Skip link works (if present)

Step 4: Content Test

Read through actual content using arrow keys.

Check:

• Images have alt text that makes sense
• Lists are announced as lists
• Tables have headers announced
• Content makes sense without visual context
• Reading order matches logical order

Step 5: Interactive Feature Test

Test specific interactive components:

Forms:

• Are field labels announced?
• Is required status indicated?
• Are error messages announced?
• Can you complete the form?

Menus:

• Can you open the menu?
• Can you navigate options?
• Can you close the menu?
• Does focus return appropriately?

Modals/Dialogs:

• Is focus moved to modal?
• Can you navigate within modal?
• Can you close with Escape?
• Does focus return to trigger?

Step 6: Task Completion Test

Attempt realistic user tasks:

• Find specific information
• Complete a form submission
• Make a purchase (if applicable)
• Navigate to a specific page

The question isn't "does it technically work?" but "could a real user accomplish this task?"

What to Look For

Common Issues You'll Find

Missing alt text: Images announced as "graphic" or filename only

Unlabeled form fields: Fields announced without indication of what to enter

Inaccessible custom widgets: Dropdowns, carousels, tabs that don't respond to keyboard or announce state

Missing headings: No way to scan page structure

Confusing reading order: Content announced in illogical sequence

Link text issues: "Click here" or "Read more" without context

State changes not announced: Toggling something without audio feedback

Severity Assessment

Critical: Can't access content or complete essential tasks

Serious: Significant difficulty or confusion, but workaround possible

Moderate: Inconvenient but functional

Minor: Suboptimal but minimal impact

Documenting Issues

What to Record

For each issue found:

1. Location: URL and element/component
2. Description: What's wrong
3. Screen reader used: NVDA, VoiceOver, etc.
4. Browser: Chrome, Firefox, Safari, etc.
5. Expected behavior: What should happen
6. Actual behavior: What does happen
7. Severity: How much impact

Example Documentation

Issue: Form field lacks accessible name
Location: /contact-us - Email field
Screen reader: NVDA 2024.1
Browser: Chrome 120
Expected: "Email address, edit text, required"
Actual: "Edit text"
Severity: Serious - Users don't know what to enter

Issue: Modal doesn't trap focus
Location: /products - Quick View modal
Screen reader: VoiceOver
Browser: Safari 17
Expected: Tab should cycle within modal
Actual: Tab moves to elements behind modal
Severity: Serious - Users may not realize modal is open

Tips for Effective Testing

For Beginners

Start with simple sites. Test a simple blog before testing complex applications.

Learn in chunks. Master basic navigation before learning all commands.

Refer to reference sheets. Keep command lists handy during testing.

Test your own work first. You'll understand issues better when you know the code.

Use visual display initially. Looking at the screen while listening helps you learn, even though real users don't.

For Better Insights

Close your eyes sometimes. Experience the page as blind users do—audio only.

Listen to speed. Experienced screen reader users often use 2-3x speed. Try increasing speed to understand the experience.

Test with default settings. Don't customize screen reader extensively—test how most users experience it.

Note confusion. If you're confused, users will be too.

Common Mistakes

Testing only with automated tools. Automated tools miss most issues screen readers reveal.

Testing only one screen reader. Test at least NVDA and VoiceOver for coverage.

Not testing actual user flows. Isolated component testing misses context issues.

Over-relying on visual verification. Looking at the screen tells you what's visible, not what's announced.

FAQ Section

Q: How long does it take to learn screen reader testing?

A: Basic testing competency takes 2-4 hours of practice. Learning enough commands to test thoroughly takes a few days of use. You don't need to become an expert—basic navigation commands cover most testing needs.

Q: Do I need to test with multiple screen readers?

A: Testing with at least two different screen readers (NVDA and VoiceOver) catches issues specific to each. If resources are limited, NVDA + Chrome covers the largest user segment based on WebAIM survey data.

Q: How often should I do screen reader testing?

A: Test when building new features, when making significant changes, and periodically for regression checking. Integrate quick screen reader checks into development workflow rather than saving all testing for the end.

Q: Can I automate screen reader testing?

A: Some automated tools simulate screen reader output, but they can't verify actual user experience. Automated accessibility testing complements but doesn't replace manual screen reader testing.

Q: Should I hire screen reader users for testing?

A: Testing with actual screen reader users provides invaluable insights that developers can't replicate. If possible, include users with disabilities in usability testing. However, developers should also learn basic screen reader testing for regular use.

Making Screen Reader Testing Routine

Screen reader testing shouldn't be a one-time event. Integrate it into your development process:

• Quick checks during development
• Thorough testing before releases
• Periodic audits of existing content
• Testing when users report issues

The more you test with screen readers, the more intuitive accessible development becomes. You'll start anticipating issues before they happen, building accessibility in from the start.

Ready to complement manual testing with automated scanning? Get a free accessibility scan to identify issues that automated tools can catch, so you can focus manual testing on what requires human judgment.

Related Articles:

• How Do Screen Readers Work?
• How Do I Test My Website for Accessibility for Free?
• What is Keyboard Accessibility?

This content was created with AI collaboration and human editorial review. For accessibility compliance guidance tailored to your business, consult with experts.