Accessibility best practices for screenreader testing

Things accessibility/product owners should be doing to decide what screen readers to test and how to test them.

WebAIM 2019 screen reader survey #9. Complicated chart, explained in text
Chart from WebAIM survey #8
  • NVDA started in the low single digits in 2009 and just passed JAWS at 40.6% last fall when this survey was performed.
  • VoiceOver market share very slightly increased over the past five years.

Best Practice #1: Test at least one screen reader per OS supported by your product

  • If you officially support Linux, you have to test Orca even though it only has .6 % of the overall market because it is the most common screen reader for the Linux platform.
  • If you officially support Apple, you must test using VoiceOver.
  • If you officially support Windows, that’s where it gets messy. There are multiple screen readers to chose from. You may not have time to test them all. More analysis below.

Best Practice #2: If you are testing with multiple screen readers, you will get more complete results if you mix in other factors

Some bugs are browser-specific. What might work on NVDA on Firefox might not work with NVDA on Chrome (or vice versa). There are numerous browser-specific screen reader bugs on IE/Edge that Microsoft has not fixed.

  • Think about doing the remainder of your bug validation using a different screen reader/browser such as JAWS on Chrome or Narrator on Edge.

Best Practice #3: You should test on multiple hardware platforms

Unless you support only one single hardware environment, some people with disabilities stick with ONE platform.

  • People with disabilities who have highly customized assistive technology setups struggle to move from one environment to another, and may not have a second environment to move to.

Best Practice #4: You need to test on older hardware platforms and screen reader versions

People with disabilities don’t upgrade quickly (either hardware or software)

  1. I don’t know a blind user who hasn’t gotten bitten in the behind at least once by upgrading one piece of their environment (OS, browser, JAVA, etc.) and having the whole assistive tech stack crater as a result. That makes PwDs hesitant to upgrade even if when it is free.

Best Practice #5 — On PCs, if you can only test on one screen reader, test using NVDA

There are MANY screen readers available for Windows environments. The two leaders are JAWS and NVDA.

  1. It’s rare (but not impossible) to see the situation where something works on NVDA and fails on JAWS.
  2. Not every blind user can afford JAWS, especially those outside of the US who reside in countries that don’t have vocational rehabilitation departments willing to buy it for them.

Best Practice #6: Test what your users use

This best practice is where analytics (and especially analytics about assistive technology use) plus what you know about your customers really can play a significant role in your decision making.

Best Practice #7: Simulating screen readers is not sufficient

There is are a couple of screen readers that have “simulation” modes where you can visually read what the screen reader auditory output would have been. Sorry, not good enough.

  • You may not find any new bugs.
  • What new bugs you do find are likely to be specific to that screen reader.

Blogger, disability advocate, nerd. Bringing the fire on ableism. A11y Architect @ VMware. Wheelchair user w/ a deaf daughter. CS, Law, and Business background

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store