Screen Readers and Browsers! Which is the Best Combination for Accessibility Testing?
Whenever I say that I make web & mobile Apps accessible for the disability groups, the first question some of the educated developers who understand accessibility ask me is, what browsers you test your APP’s on & which screen readers do you use? This is a very interesting question because, there are a wide variety of browsers & screen readers that are available in the market. Testing with every screen reader on every browser is not feasible if not impossible.
- Chrome (Windows OS and Android)
- Firefox (Windows OS and Android)
- Safari (OSx and IOS)
Popular Screen Readers
- JAWS (Job Access with Speech)
- NVDA (Non-Visual Desktop Access)
- Voiceover (OSx and IOS)
- Talkback (Android)
According to Wikipedia, Chrome holds the majority share for the browser market followed by Safari. These stats are true for both desktop & mobile. According to WebAIM screen reader survey9 conducted in 2021, Chrome stands first followed by Microsoft Edge & in 3rd place is Firefox. Definitely assistive technology users prefer Chrome and Edge over Firefox for their day to day activities. When it comes to IOS & OSx Safari is the most popular browser and on Android, Chrome holds a good position.
|Browser||# of Respondents||% of Respondents|
According to WebAIM Screen reader survey we can clearly see from the below table that JAWS works great on Chrome followed by NVDA with Chrome. I personally prefer JAWS with Chrome and JAWS with Firefox. During my day to day accessibility testing I use NVDA with Chrome & sometimes I also use NVDA with Firefox to see if any ARIA or HTML5 attribute is not being supported by the browser or the screen reader.
|Screen Reader & Browser||# of Respondents||% of Respondents|
|JAWS with Chrome||500||32.5%|
|NVDA with Chrome||246||16.0%|
|JAWS with Edge||194||12.6%|
|NVDA with Firefox||149||9.7%|
|JAWS with Firefox||74||4.8%|
|VoiceOver with Safari||72||4.7%|
|NVDA with Edge||55||3.6%|
|ZoomText/Fusion with Chrome||33||2.1%|
|JAWS with Internet Explorer||30||1.9%|
|VoiceOver with Chrome||24||1.6%|
|ZoomText/Fusion with Edge||18||1.2%|
At my work place we follow testing on Chrome with NVDA screen reader & if we encounter any bugs related to either screen reader or the browser, we immediately raise the bugs with the vendor.
Besides, there are other factors too that attribute to the AT testing conundrum. Firstly, the support for HTML attributes and ARIA attributes by the browser vendors vary a lot. The same is true when we talk of the screen readers too. Not every attribute is supported by all the screen readers.
Secondly, testing with all browsers VS screen readers is a costly affair as it consumes a lot of resources, time and money too.
So let’s answer the question, which screen reader should I use for accessibility testing? In my opinion & my experience, this is the matrix that I have come up with and now for your view:
- NVDA and Jaws with Chrome on Windows
- Voiceover with Safari on IOS & OSx
- Talkback with Chrome on Android
If you have written a clean code that is semantic & follows all W3C Standards then testing on these platforms will suffice. Most of the HTML5 & WAI-ARIA attributes are supported on all these platforms. If something doesn’t work, then cross testing on a different browser/platform can determine if it is a browser or screen reader bug.
Hope this is helpful! Any views & opinions can be shared in comments section.
Note: This article has been updated in 2023 to include the latest results from the WebAIM Screen Reader Survey. Internet Explorer has been phased out and Edge browser has taken its place.
Jaws is used by approx. half of all blind people, so why would you leave it out completely?
If you read the article I haven’t left out JAWS completely… I gave my opinion that JAWS works with internet explorer & chrome browser’s nicely…. I know that a lot of blind people in English speaking countries use JAWS but blind people who cannot buy JAWS license use NVDA.
Hi, Thanks for the detailed statistics. Which browser/screen reader combination is the best has been a topic for debate among several Accessibility experts. @ my workplace we only accommodate JAWS for our accessibility testing. But should we continue to test it with IE 11 or switch to chrome or firefox has been very perplexing. If you were to accommodate only one browser with your testing efforts with JAWS which browser would you recommend? IE 11 or chrome or firefox? Thanks much
I would go with JAWS+Chrome. Even the makers of JAWS screen reader say that it works well with Chrome…. Since web is evolving & IE is not being updated regularly it might not support complex widgets built with WAI-ARIA. I personally use JAWS+Chrome & I have no issues with it. At my work place for testing we use NVDA+Firefox & it also provides reliable testing results.
I think this post needs bit of updating & will do it once WebAIM 8th screen reader survey comes out.
Using Jaws 2019 and Chrome this page wont let me reply to a comment. It ignores any form of mouse click on the reply to comment link.
I tested the website with multiple screen readers & browsers… I am able to reply & post comments without problems.
I am working in a Australia based company. In my company we are using Jaws 2019 +IE 11 for web accessibility. But now we found that Chrome is most used as compare to IE.
So is it useful to start accessibility testing in Chrome and leave IE browser completely?
Yes JAWS+Chrome will be a good combination. I would suggest you go with NVDA+Chrome or NVDA+Firefox for more accurate results. Sometimes JAWS gives false positives & if you are not a power user you might not spot these issues.
As you know the Federal government has IE 11. How well does it support ARIA and what
are the primary browsers we should test for public facing .gov websites.
IE and Jaws
Chrome and NVDA?
Also many blind users have told me sometimes ARIA can be over kill and redundant.
What are your thoughts on it?
It’s time IE retires or upgrades like other browsers. Yes it’s true that all ARIA widgets doesn’t work as expected with IE….. I would suggest NVDA+FF, NVDA+Chrome & if you are using JAWS then JAWS+Chrome
Yes ARIA is an over kill if you ask… use native HTML first & for dynamic widgets use WAI-ARIA.
Is NVDA a correct screen reader to be used with IE11? I’m facing issues with error identification with form fields when I use NVDA+IE11.
NVDA+IE are not a great combination to get accurate results. If you are writing the code according to specification & screen reader is not giving the right output then it’s a useragent bug… I suggest use NVDA+FF to get accurate results. Just relying on screen reader testing results is not enough, one needs to learn to inspect code & see what’s wrong.
Thanks for your reply, Peri.
NVDA+FF is giving expected results and I have followed WCAG documentation to fix the issues I’m facing.
Thanks again for your time.
While incredibly useful, does this article include all assistive technology that’s likely to be used or does it, however unintentionally, give the false impression that only blind and partially sighted persons need to be taken into account? what about those who are dexterity impaired and user speech recognition programs (such as Dragon NaturallySpeaking)? just because a website or software application works with ScreenReaders, there is no knowledge or indication that it will work for other disabilities or assistive technology.
I find this limited view very dangerous and, while better than before, still all too common – i.e., “if it works with JAWS, it’ll work with Dragon” – which I’ve heard from webmasters and accessibility ‘managers’ all too often.
I am a person with visual disability & also an A11Y specialist… so with this experience I can say that a site built with right code works across all assistive technologies. HTML comes accessible by default, it’s just need support from user-agents & assistive technologies… if we are building any custom controls using ARIA then right set of roles, states & properties need to be implemented. While all this is done to perfection from the code end, all these widgets work with assistive technologies like dragon naturally speaking.
Dragon naturally speaking relies on elements name & role most of the time… you can command it to open button, click link or tell the name of the element where it moves the focus. So I think testing with screen readers is the cost effective way to perform accessibility testing as it gives most of the A11Y bugs & from there we can work on fixes.
I am a accessibility tester but confused every time which combination i preferred. In one of my project JAWS+FF combination required but during testing i found that it’s not working well. On few interactive element it’s not giving response and even navigation issue occur using arrow keys.
Can you help me out what will be the best combination in terms of priority? As i got different results on different website. Can give me the exact answer.
Use JAWS+Chrome & NVDA+FF combination. Internet explorer is not being supported by lot of websites lately & its waste to test on it. A lot of ARIA widgets also do not work as expected on IE.
I’ve long been testing our web app in JAWS+IE and NVDA+FF but lately as we upgrade our application IE has been a continuing trouble spot–and not just with a screen reader in play. The new Edge seems to be working well with JAWS (it is based on chromium so not surprising), I’m trying to figure out if it is still worth trying to get the application working in IE with Jaws or if we should let our clients know we don’t support IE with screen readers and there may be issues (our clients are companies that embed our web app in their websites, their end users would be the end users using screen readers).
ARIA widgets do not work consistently in IE & the browser is almost dead…. I am asking people to use Chrome & FF for both testing & using the rich web applications.
I am active in many blind lists and FF is not use very much anymore. Most use Chrome, Edge and other Chromium based browsers.