Skip to content Skip to navigation

Screen Reader Testing

Overview

When many people think of web accessibility, they primarily imagine screen reader users. However, as the SOAP site demonstrates extensively, these are not the only users who have accessibility needs when using the web or online applications. In fact, though statistics regarding screen reader use (not to mention specific screen readers used) are difficult to come by, those who use screen readers are a relatively small population. Note, by the way, that not all screen reader users are blind; others with print-reading disabilities may also find screen readers useful.

Despite limited information about this audience, keep in mind that code does make a significant difference to screen reading software. For example, it is ideal to use the button element, rather than a link that looks like a button. And, as another example, it is best to code lists correctly, instead of implementing incorrect markup (such as perhaps a span or div), and then including images of bullets to create the appearance of a list.

Whenever possible, it will be faster, and easier, for you to use visual tools to check for as many accessibility issues as you can. But there will be instances, especially when you need to implement WAI-ARIA that testing your code will be necessary. You will receive the most return on your time investment if you test with a screen reader when your code is the best you can make it. By that point, for example, you will know that you've included all necessary alt attributes on images, and you can spare yourself from having to listen to a screen reader speak gibberish-sounding filenames for missing alt text. In most cases, testing with a screen reader should be a "double check" of your work.

It is ideal to observe frequent users of screen readers since someone who starts a screen reader for the first time (and who doesn't need to use one) will not be familiar with approaches that typical screen reader users employ. While there are many screen reader demonstrations to be found online, this Introduction to Screen Readers (YouTube) offers a basic overview.

Once you become familiar with the screen reader, and have learned the general keyboard commands you need, too, try turning off your monitor and putting away your mouse.

A Developers' Responsibility

Developers are responsible for making their code the best it can be. It may be particularly important to pay attention to the code generated by a framework; you may need to make modifications when a framework developer has not taken accessibility into account.

Two areas that developers who begin to work with screen readers are not responsible for are:

  • Screen reader pronunciation
  • Screen reader detection

Screen reader users are responsible for knowing how to use their software and dealing with its pronunciation idiosyncrasies (based on which voice they choose to use). A strange pronunciation that may bother you is unlikely to be of concern to a daily screen reader user. On the other hand, developers should provide clean and accurate code which, in turn, helps assistive technologies and browser APIs communicate successfully with one another.

Often, developers immediately think: "Let us cater a 'special' experience for screen reader users. We can do that if we can detect that screen reader software is running." While it is out of scope to discuss this issue in detail, please check the resources section of this page for an article that summarizes these issues fully. In short, detecting a screen reader raises privacy concerns, as well as the spector of "text-only" ghettoized sites which are difficult to maintain, lack functionality, and serve no one well. If you deploy standards-compliant code, then you will have fulfilled your part of the web accessibility "contract."

How Do Screen Readers Work?

Before you begin to test with specific screen reader and browser combinations, you will want to have a basic understanding of how screen readers work. Generally, they access the DOM (Document Object Model), and they use browser APIs (Application Programming Interfaces) to get the information they need. In this way, a screen reader knows what to say when a set of list items begins and ends, and it typically announces, in advance, how many items are in the list. Or, as another example, a screen reader is able to traverse a page, using heading navigation, and speak the heading level. For those who are interested, here are some resources with more detail:

Recommended Screen Reader and Browser Combinations

Different screen readers tend to be optimized to work with different browsers. Though it is possible that this information may change, at this time, the following combinations work best together:

  • Windows: Internet Explorer and JAWS for Windows (JFW)
  • Windows: Firefox and NVDA
  • Mac: Safari and VoiceOver
  • Mac and Windows: Chrome and ChromeVox

Keep in mind that:

  • According to the most recent Screen reader User Survey via WebAIM, not many blind people use Chrome and ChromeVox, so while testing with the Accessibility Developer Tools can be useful, ChromeVox is rarely used (at least at this time)
  • The free combinations that are easiest to test with and are quite standards-compliant are NVDA and Firefox (on Windows) and VoiceOver and Safari (on Mac)

Testing with NVDA for Windows

Testing with VoiceOver for the Mac

Remember that VoiceOver for IOS and VoiceOver for the Mac are somewhat different, though in many cases, similar concepts apply. Here, the focus is on VoiceOver for the Mac. To learn more about testing mobile sites and applications with VoiceOver for IOS (as well as TalkBack for Android), please visit the Mobile page on the SOAP site. Take a look at the following posts to help you get started using VoiceOver on the Mac:

Testing with JFW

Freedom Scientific prefers that developers not use their 40-minute demo version for testing. If you wish to test with JFW, please Contact Us to make a request.

Target Audience: 
Developer
Last modified: 
August 1, 2016