How to Conduct Accessibility Testing with Screen Readers

This article is your guide to screen reader testing—a practical, essential step in building accessible websites. Whether you’re a developer, designer, or project manager, you’ll learn how to integrate screen reader testing into your workflow and create experiences that work for all users, with no exceptions.

Imagine filling out a critical form online—submitting a job application or scheduling a medical appointment—only to hit “Next” and encounter… nothing. No error message, no feedback, no way forward. This frustrating dead-end is what millions of users experience daily when they interact with inaccessible websites. For a technical team, these moments highlight why accessibility cannot be an afterthought.

But here’s the problem: accessibility isn’t automatic and doesn’t happen by accident—it must be intentional. While automated tools like WAVE or Lighthouse identify around 30% of accessibility issues, they miss the human side of usability. A button might meet technical accessibility standards, but does its label make sense when read aloud? Screen reader testing uncovers these gaps, allowing you to fix problems before they impact real users.

So, who’s responsible for screen reader testing? Everyone. Creating accessible websites is a team effort. Developers must ensure semantic code and proper ARIA roles. Designers must think beyond visuals, focusing on clear navigation and intuitive layouts. QA teams must integrate screen reader checks into their workflows, validating forms, navigation, and dynamic content. Even project managers and stakeholders play a role by prioritizing accessibility from the start.

Getting Started: Choosing a Screen Reader

Screen reader testing begins with choosing the right tool for the job. However, not all screen readers are the same—each behaves differently depending on the operating system, browser, and assistive technology integrations. Here are some of the most popular options available: 

JAWS (Job Access With Speech)

Platform: Windows

Cost: Commercial (subscription or perpetual license)

Why it’s popular: JAWS is the gold standard for screen readers, especially among professionals who use assistive technology daily. It offers advanced scripting options for custom workflow and excels at handling complex web apps, making it particularly useful for enterprise-level testing. However, its cost can be a barrier for smaller teams.

NVDA (NonVisual Desktop Access)

Platform: Windows

Cost: Free, open-source

Why it’s popular: NVDA is highly developer-friendly and works well with popular browsers like Chrome, Edge, and Firefox. Despite being free, it offers robust functionality and a low learning curve for new testers, making it a great choice if your team has a tight budget.

VoiceOver

Platform: macOS/iOS

Cost: Free (built into Apple devices)

Why it’s popular: VoiceOver is fully integrated into Apple’s ecosystem, with deep optimization for Safari and native macOS/iOS apps. Its support for touch gestures on iOS devices adds a unique dimension to mobile accessibility testing. However, VoiceOver’s behavior differs from Windows-based screen readers, making it a critical tool for testing websites and apps targeting Apple users.

TalkBack

Platform: Android

Cost: Free (built into Android devices)

Why it’s popular: TalkBack is Google’s default screen reader for Android devices, making it great for testing touch interfaces, gestures, modals, and notifications of mobile apps and websites accessed via Android.

ChromeVox

Platform: ChromeOS, Windows, macOS, Linux (via Chrome browser)

Cost: Free

Why it’s popular: ChromeVox is built for Chrome, making it a perfect fit for web developers working with Google services (like Docs and Sheets) or Chromebook environments. While less commonly used by everyday screen reader users, its integration with Chrome Developer Tools makes it a valuable asset for debugging accessibility issues in real time.

Considerations for Choosing a Screen Reader

The best screen reader for testing depends on several factors, including your audience, platform compatibility, and available resources. Here are key factors to guide your choice:

Target Audience 

The first thing to consider is “Who am I developing/designing for?” If your audience includes users in professional environments, I’d recommend prioritizing testing with JAWS, as it remains the dominant choice among workplace users.

On the other hand, general users tend to lean toward NVDA since it is free and relatively easier to use. Similarly, VoiceOver is integrated into Apple devices, making it a natural choice for Mac and iPhone users.

Platform Compatibility 

Each screen reader is optimized for specific operating systems and browsers. A comprehensive accessibility testing strategy should include:

• NVDA or JAWS for Windows environments (Chrome, Firefox, and Edge).
• VoiceOver for macOS/iOS to account for Safari and Apple-native behaviors.
• TalkBack for Android, particularly for mobile app development and testing.
• ChromeVox for browser-specific testing in Chrome.

Budget

Let’s be real—not every team has a big budget for accessibility testing. Thankfully, you don’t need one to get started. Free tools like NVDA, VoiceOver, and ChromeVox offer excellent starting points and in my experience have proven to be effective for most teams. If you have the resources, invest in JAWS, especially for advanced testing features. But, if your team can’t afford JAWS, pairing NVDA with other free options can provide strong coverage for most accessibility scenarios.  

In summary, here’s my advice for choosing a screen reader for accessibility testing: start small,  then expand.

Don’t try to test with every screen reader at once. Instead, begin with NVDA and VoiceOver if you’re testing for general users across Windows and Apple devices. Once your team grows more confident, expand your testing to include JAWS, TalkBack, or ChromeVox for a more comprehensive approach.

How to Prepare for Screen Reader Testing 

Screen readers are controlled entirely with the keyboard. Before testing, familiarize yourself with basic keyboard commands like:

• Tab: Move between interactive elements like links, buttons, and form fields.
• Arrow Keys: Navigate text, menus, or lists.
• Enter/Spacebar: Activate buttons, links, or checkboxes.
• Escape (Esc): Exit forms or focus mode when stuck.
• Screen reader-specific keys: NVDA uses the Insert key for commands, while VoiceOver uses Control + Option.

Tip: Turn off your monitor during testing to replicate the experience of a screen reader user. This forces you to rely on auditory output instead of visual cues.

If you’re using a laptop, you can replicate this by dimming the screen brightness to the lowest setting. This reduces visual distractions and creates a similar experience to having the monitor off, ensuring you focus only on what the screen reader announces.

Key Areas to Focus on During Screen Reader Testing

Screen reader testing goes beyond verifying how content is announced. It evaluates how users can navigate, interact, and complete tasks effectively. Focus on these areas to identify and address potential accessibility issues:

1. Navigation structure

What to test: 

• Ensure a logical heading hierarchy (e.g., H1 for main titles, H2, H3, H4… for sections and subsections) to help users navigate content easily by heading levels.  
• Check that the site has proper semantic landmarks (e.g., <header>, <nav>, <main>) to define key page regions and help users jump to specific sections.
• Verify content is announced in a natural, logical sequence from top to bottom.
• Confirm that there’s a “Skip to Main Content” link at the top of the page to bypass repetitive sections and ensure that it is keyboard-accessible and visible on focus.
• Check that there are unique, descriptive titles for each page that are correctly announced when the page loads.

2. Interactive elements

What to test: 

• Test if links have clear and meaningful text (e.g., “View Details” instead of “Click Here”).
• Verify that button labels clearly describe their function, such as “Submit” or “Add to Cart.”
• As you navigate with the Tab key, verify that the active element is highlighted visually (e.g., with a border or background color) and that the focus moves logically without skipping or trapping elements.
• Ensure that tooltips and other hover-triggered content are accessible via keyboard focus and announced by screen readers.

3. Forms and Input fields

What to test: 

• Every input field must have an accurate, visible label that matches what the screen reader announces.
• When errors occur, ensure screen readers announce them clearly and guide users on how to fix them, using proper live regions and ARIA alerts..
• Confirm that you can interact with all fields, checkboxes, and dropdowns using only the keyboard.

4. Images and Media

What to test: 

• Ensure all images have descriptive alt attributes. Decorative images should use empty alt text (alt=””).
• Verify that audio and video players are fully operable with screen readers and provide captions or transcripts.

5. Dynamic content and alerts

What to test: 

• Ensure that ARIA roles like role=”alert” are properly used to notify users of significant updates, such as new messages or pop-ups.
• When modals or pop-ups appear, ensure that the focus is kept within the modal until you close it.
• Ensure announcements don’t interrupt ongoing navigation unless absolutely necessary.

6. Tables and Data presentation

What to test: 

• Verify the use of <th> elements or ARIA attributes to define row and column headers. Ensure they are announced with their corresponding data cells.
• Confirm that screen readers announce data cells in a logical sequence that matches with their corresponding headers.

7. Accessibility of Error Messages

What to test: 

• Error messages should be descriptive and located near the problematic field.
• Ensure live regions are used to notify users of errors dynamically.

8. Hidden and Offscreen Content

What to test: 

• Use aria-hidden=”true” or display: none to ensure irrelevant content is excluded from announcements.
• Ensure offscreen content intended for screen readers, like skip links, is fully functional.

9. Mobile-specific considerations

What to test: 

• Test screen reader gestures like swiping and double-tapping with TalkBack (Android) and VoiceOver (iOS).
• Verify that accessibility features remain intact across different screen sizes and orientations.

Best Practices for Effective Screen Reader Testing

• Test with at least two major screen readers to help you catch accessibility issues across diverse environments and ensure your site works for as many users as possible.
• Involve real screen reader users in your testing process. They can provide unique insights into usability challenges that automated testing alone may miss. 
• Make screen reader testing a standard part of your process at every stage—during design, before development, and post-development. Build accessibility checks into sprints and QA to ensure consistent progress.
• Focus on real-world scenarios by testing tasks that reflect how users interact with your site, like completing forms, navigating menus, or reading dynamic content. This helps ensure the site works intuitively for all users.
• Create detailed reports for each issue you find, including a description, the affected component, steps to reproduce it, the expected behavior, and what actually happens. Share these with developers and stakeholders to streamline resolution and prevent regressions.
• Regularly review updates to WCAG guidelines, screen reader technologies, and browser capabilities. This ensures your testing stays relevant and effective.

Beyond Compliance: Building Empathy Through Screen Reader Testing

Technical teams often focus on compliance, but compliance isn’t enough. A button labeled “Click here” might technically pass a test, but what does it mean to the user? Testing with a screen reader forces you to go beyond the rules and ensure the interface makes sense in context. It’s not just about meeting standards; it’s about usability.

Ultimately, empathy grows when the whole team participates. Developers, designers, and QA specialists can all gain insights by using screen readers. These insights often lead to better design decisions, cleaner code, and systems that work for everyone—not just those who rely on assistive technology.