Screen Reader Testing: Complete Guide to Testing Tools & Methods

You can test your website's accessibility using a screen reader testing tool by downloading NVDA or using your device's built-in screen reader, then navigating your site with keyboard shortcuts to verify that all content is properly announced. Screen reader testing is the process of using assistive technology software to evaluate how well your website works for visually impaired users.

After reading this guide, you'll know how to set up the most popular screen readers, understand essential testing workflows, and identify common accessibility issues before your users encounter them.

Prerequisites and Context

You need basic knowledge of HTML structure and keyboard navigation. JAWS, NVDA, and VoiceOver account for nearly 88% of all screen reader usage, making these your priority testing tools.

Automated tools catch 30-40% of accessibility issues, but can't evaluate whether alt text is useful or if keyboard navigation flows naturally. This is why manual screen reader testing is essential for complete accessibility validation.

Essential Screen Reader Testing Tools

Screen reader software refers to assistive technology that converts digital text and interface elements into synthesized speech or braille output. Here are the tools you need:

NVDA (Windows)

Download NVDA free from nvaccess.org. Install with default settings for testing purposes.

JAWS (Windows)

JAWS offers a 40-minute demo mode that resets after each restart. Download from freedomscientific.com. JAWS Inspect is a tool that can be used to find accessibility issues without requiring technical expertise.

VoiceOver (Mac/iOS)

VoiceOver comes pre-installed on all Apple devices. Enable it through System Preferences > Accessibility > VoiceOver.

Windows Narrator

Narrator is the primary screen reader for only 0.7% of respondents, but is commonly used by 37.3% of respondents. Access it by pressing Windows + Ctrl + Enter.

Step 1: Set Up Your Testing Environment

Close all unnecessary applications to avoid audio interference. Set your screen reader to moderate speech speed for testing. Disable visual enhancements that might affect focus indicators.

Why this matters: A clean testing environment helps you focus on accessibility issues rather than technical distractions.

Common mistake: Testing with multiple audio sources running, making it hard to hear screen reader announcements clearly.

Step 2: Learn Essential Keyboard Shortcuts

Master these core navigation commands before testing:

NVDA Shortcuts

• NVDA + Space: Toggle browse/focus mode
• H: Navigate by headings
• F: Navigate by form fields
• G: Navigate by graphics
• T: Navigate by tables

JAWS Shortcuts

• Insert + F7: List all headings
• Insert + F5: List all form fields
• Insert + F3: Virtual HTML features menu
• Insert + F6: List all headings by level

VoiceOver Shortcuts

• VO + A: Start reading
• VO + Command + H: Navigate by headings
• VO + Command + J: Navigate by form controls
• VO + Command + G: Navigate by graphics

Why this matters: Efficient navigation shortcuts mirror how real users interact with your content.

Common mistake: Using only Tab key navigation instead of semantic navigation commands.

Step 3: Test Page Structure and Navigation

Start testing with your site's main navigation and heading structure. Use heading navigation (H key in NVDA/JAWS) to jump between page sections.

1. Navigate to your homepage
2. Press H to move through all headings
3. Verify heading levels follow logical order (H1, H2, H3)
4. Check that heading text describes the content accurately
5. Test skip links by pressing Tab immediately after page load

Why this matters: Heading structure provides the primary navigation method for screen reader users, like a table of contents.

Common mistake: Testing only with mouse clicks instead of keyboard-only navigation patterns.

Step 4: Verify Form Accessibility

Forms require specific testing because they're interaction-heavy elements. Navigate to any form on your site using the F key (NVDA) or Insert+F5 (JAWS).

1. Tab to each form field
2. Verify the screen reader announces the field label
3. Check that required fields are clearly identified
4. Test error messages by submitting incomplete forms
5. Confirm that fieldset legends are announced for grouped fields

Why this matters: Forms are critical conversion points where accessibility failures directly impact user success.

Common mistake: Relying on placeholder text instead of proper labels for form fields.

Step 5: Test Images and Media Content

Navigate to images using the G key. Listen for alt text announcements and verify they provide meaningful descriptions.

1. Navigate to each image using graphics navigation
2. Verify decorative images are properly hidden (empty alt="")
3. Check that informative images have descriptive alt text
4. Test complex images for long descriptions
5. Verify that image links announce their destination

Why this matters: Images without proper alt text create information gaps for screen reader users.

Common mistake: Writing alt text that repeats nearby caption text instead of describing image content.

Step 6: Verify Table Structure

Data tables need proper markup for screen reader comprehension. Navigate to tables using the T key.

1. Navigate to data tables
2. Verify table headers are properly announced
3. Check that complex tables have caption elements
4. Test table navigation using Ctrl+Alt+Arrow keys
5. Confirm row and column headers are associated with data cells

Why this matters: Table markup helps screen readers maintain context as users navigate between cells.

Common mistake: Using tables for layout instead of CSS, creating confusing navigation patterns.

Step 7: Test Focus Management

Focus management ensures users always know their current location on the page. Test interactive elements like modals, dropdowns, and dynamic content.

1. Open modal dialogs and verify focus moves to the modal
2. Check that focus returns to the trigger element when closing modals
3. Test dropdown menus with arrow key navigation
4. Verify that dynamically added content receives focus appropriately
5. Confirm focus indicators are visible for sighted keyboard users

Why this matters: Poor focus management can trap users or cause them to lose their place on the page.

Common mistake: Not testing focus behavior when content changes dynamically.

Common Issues and Fixes

Missing or Poor Alt Text

Problem: Images announced as "graphic" or "image" without description. Fix: Add descriptive alt attributes or alt="" for decorative images.

Unlabeled Form Fields

Problem: Form fields announced only by their input type. Fix: Associate labels using for/id attributes or aria-labelledby.

Poor Heading Structure

Problem: Headings skip levels (H1 to H3) or don't describe content. Fix: Use sequential heading levels and descriptive text.

Keyboard Traps

Problem: Focus gets stuck in a component without escape method. Fix: Implement proper keyboard event handling and focus management.

Missing Link Context

Problem: Links announced as "click here" or "read more." Fix: Use descriptive link text or add context with aria-label.

Documenting Your Testing Results

Create a testing checklist to track your progress:

• Page navigation: Can users navigate by headings effectively?
• Form completion: Are all form fields properly labeled and accessible?
• Image content: Do images have appropriate alternative text?
• Interactive elements: Do buttons and links have clear purposes?
• Error handling: Are error messages clearly announced?

Document issues with specific reproduction steps and suggested fixes. Include the screen reader and browser combination used for testing.

The most effective screen reader testing combines multiple tools and real user feedback. No single tool catches every accessibility issue.

Troubleshooting Common Problems

Screen reader not announcing content: Check if you're in the correct mode (browse vs. focus mode). Try refreshing the page.

Navigation shortcuts not working: Verify the screen reader is active and you're using the correct modifier keys for your software.

Content sounds repetitive: Look for redundant alt text, repeated link text, or unnecessary aria-labels.

Focus disappears: Check for CSS that hides focus indicators or JavaScript that interferes with focus management.

Forms difficult to complete: Verify label associations, fieldset usage, and error message implementation.

Key Takeaways

• NVDA, JAWS, and VoiceOver cover nearly 88% of screen reader usage and should be your primary testing tools
• Automated tools only catch 30-40% of accessibility issues, making manual testing essential
• Master heading navigation, form field navigation, and graphics navigation shortcuts for efficient testing
• Test page structure, forms, images, tables, and focus management in every testing session
• Document issues with specific reproduction steps and screen reader combinations used
• Focus on semantic HTML structure and proper labeling to prevent most accessibility issues

Frequently Asked Questions

Question: Which screen reader should I start with if I'm new to accessibility testing?

Start with NVDA if you're on Windows or VoiceOver if you're on Mac. Both are free and widely used.

Question: How often should I perform screen reader testing?

Test with screen readers during development for new features and before major releases. Include basic screen reader checks in your regular QA process for critical user flows.

Question: Can I rely on automated accessibility tools instead of manual screen reader testing?

No, automated tools only catch 30-40% of accessibility issues. They can't evaluate whether alt text is meaningful or if navigation flows logically for screen reader users.

Question: What's the difference between browse mode and focus mode in screen readers?

Browse mode lets you navigate page content with shortcuts like H for headings. Focus mode is for interacting with form fields and interactive elements using standard keyboard controls.

Question: How do I know if my heading structure is accessible?

Use the H key to navigate through headings. They should follow logical order (H1, H2, H3) and accurately describe the content that follows. Each page should have one H1.

Question: Should I test on mobile screen readers too?

Yes, test VoiceOver on iOS and TalkBack on Android for mobile experiences. Mobile screen readers use different gesture-based navigation that can reveal unique issues.

Start your screen reader testing today by downloading NVDA or enabling VoiceOver, then work through your site's main user flows using only keyboard navigation and screen reader feedback.