How to Choose a Screen Reader for Testing Your Site

January 9, 2023

What are screen readers?

Whether your organization is looking to mature its accessibility program or “shift left” to incorporate accessibility as you build, screen readers are a very important piece of the puzzle. Screen readers are a form of assistive technology used primarily by users with vision impairments. They work by converting visual screen elements like text, buttons, links, form fields into speech (or braille).

There are a number of widely used screen reader products. In some cases, like on ATMs or other kiosks, screen reader software is provided as is. But on users’ own devices, they have the option to select or install their own screen readers based on factors such as convenience, price, or personal preference. Some of the most common screen readers include:

Subscribe to our Newsletter

This field is for validation purposes and should be left unchanged.

If you have to pick, which screen reader should you test with?

Screen reader testing is like browser compatibility testing

If you have done browser compatibility testing before, you know that sites mostly work the same on any OS or browser but that there are occasional browser-specific bugs. The same is true of screen readers. If your site works well with one screen reader, it will likely work well with others. But the best way to remove accessibility bugs is to introduce cross-testing with multiple screen readers.

Don’t let perfect be the enemy of good

For sighted designers, developers, and users, it takes a bit of practice to get comfortable using a screen reader. Even within organizations that try to design and code with accessibility in mind, screen reader testing is pretty rare. If the most comprehensive approach is hiring experts to test across all possible screen readers, that doesn’t mean you can’t accomplish a lot without going that far. Testing with any screen reader, even on your own, is going to help you dramatically improve your accessibility. It’s certainly better than getting overwhelmed, throwing up your hands, and doing nothing.

The comprehensive testing solution

Some organizations have a lower tolerance for accessibility bugs. This may be because they want to highly optimize e-commerce funnels, have already been sued, are bound by a settlement, or simply want to avoid any negative publicity. These companies or agencies are incentivized to be as comprehensive as possible. But even in this case, you’ll have to make some choices.

There are 5 major screen readers (Voiceover for iOS and MacOS, JAWS, NVDA, and Talkback) used across 4 major browsers (Chrome, Safari, Firefox, and Edge), 2 desktop operating systems (Windows and MacOS), and 2 mobile operating systems (Android and iOS). If you were to test across every possible combination here, you would end up with 11 testing combinations. While there may be limited scenarios where that is appropriate, 11 testing combinations is excessive.

WebAim pairing recommendation

WebAIM, a widely respected nonprofit accessibility provider, recommends these specific browser, OS, and screen reader pairings:

  • Windows Firefox with NVDA
  • Windows Chrome with JAWS
  • Safari (MacOS) with Voiceover
  • Windows Edge with Narrator

Our comprehensive recommendation

Our recommendation builds on WebAim’s pairing recommendations while balancing maximum coverage against overlapping functionality. In our experience, as Edge browser is built on the Chromium engine, it is usually unnecessary to test it separately from Chrome. Similarly, the Narrator screen reader has very low market share and can generally be skipped when screen reader testing. Our comprehensive recommendations instead aim to test all major screen readers per operating system (including mobile) in one browser each. 

  • Android Chrome with Talkback
  • Safari (iOS) with Voiceover
  • Windows Firefox with NVDA
  • Windows Chrome with JAWS
  • Safari (MacOS) with Voiceover

Maximizing impact with limited resources

This is all well and good when you have the institutional know-how, time, and budget to test comprehensively. But many organizations are working with limited resources, capacity, and budget. Which screen readers should these teams test with their limited resources to make the biggest accessibility impact?

Remember your web team’s experiences are not typical

Web professionals use the web very differently from most people. Aside from being generally more knowledgeable, they also use very different tools and software on average. More specifically, they tend to use Macs and Linux at a much higher rate than the general population. They also often have second (or even third) monitors and their screens are larger and higher resolution.

I can’t count the number of times that I have seen websites that are designed, built, and tested at 2500 pixel widths without any serious consideration or testing of how the site looks and behaves on a smaller laptop screen. Even when web teams incorporate screen reader testing into their flows, it’s very common for them to test exclusively on MacOS Voiceover out of convenience. While that’s better than nothing, it’s probably not where we’d recommend prioritizing if you were to test on just one screen reader.

And even before you get to screen reader testing, make sure you test your site on a Windows device that is smaller, lower resolution, and less powerful than what you typically use.

Follow screen reader market share

WebAIM’s most recent screen reader survey showed that JAWS is the most commonly used desktop screen reader and Voiceover is the most commonly used mobile screen reader. If you had to set minimal screen reader coverage, JAWS and Voiceover (iOS) would support nearly 70% of both desktop and mobile users. From there, if you had additional time or resources, you could smoke test key templates and page regions such as the homepage, header, and footer on other screen readers.

But if you find that a JAWS professional license (currently $1285) is out of range, you would still benefit from testing on NVDA, which is open source and free to install. Even if you only have a Mac, testing in Voiceover can help you uncover accessibility bugs and build confidence that your site is usable on screen readers. (However, as we noted above, you may miss other usability and accessibility concerns.)

It is also worth noting that JAWS does offer a “40 minute mode” that is available for users without a license. While not suitable for intensive use, it does allow you to do screen reader testing (albeit in 40 minute increments with a requirement to restart your computer between uses).

Know your own market

Your site analytics will not help you understand how assistive technology users navigate your site. For example, most MacOS visitors might use Chrome to visit your site, but the subset of screen reader users may prefer to browse with Safari. But you can still exercise some common sense in narrowing down your testing plans. If your website somehow still gets significant Internet Explorer traffic, you’ll want to make sure you devote some screen reader testing time on IE. Similarly, if your iOS app analytics show very little usage on a specific iOS version, you probably don’t need to cross-test for accessibility on that version.

Context is key

Your team likely tests more thoroughly when launching a brand new website or feature and less formally when publishing a new blog post. The more complex or important, the greater the need for testing. Our recommendations are meant to help you create a structure for your accessibility testing plans, but you may find that some situations call for more cross-testing than others.

How to get started responsibly

If you put in the time to learn how, screen readers are not difficult to use. But it can take some time to get a feel for what is expected behavior and what constitutes an accessibility bug or barrier. The last thing you want to do is overcorrect and degrade the screen reader experience when you’re trying to help. Access Armada offers screen reader coaching for development and QA teams to help them understand how screen readers interpret websites and best practices for addressing common screen reader issues.

Share this post: