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.
Popular Browsers
- Internet Explorer (Windows OS)
- Firefox (Windows OS and Android)
- Chrome (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. But according to WebAIM screen reader survey7 conducted in 2017, Firefox stands first followed by internet Explorer & in 3rd place is Chrome. Definitely assistive technology users prefer Firefox over Chrome for their day to day activities. When it comes to IOS & OSx Safari is the most popular browser & on Android Chrome & Firefox both hold a good position.
| Browser | # of Respondents | % of Respondents |
|---|---|---|
| Firefox | 719 | 41.0% |
| Internet Explorer 11 | 408 | 23.3% |
| Chrome | 271 | 15.5% |
| Safari | 184 | 10.5% |
| Internet Explorer 6, 7, or 8 | 71 | 4.1% |
| Internet Explorer 9 or 10 | 70 | 4.0% |
| Microsoft Edge | 8 | 0.5% |
| Other | 22 | 1.3% |
According to WebAIM Screen reader survey we can clearly see from the below table that JAWS works great on Internet Explorer followed by NVDA with Firefox. I personally prefer JAWS with Internet Explorer & JAWS with Chrome as the new version of Firefox doesn’t work with JAWS yet. During my day to day accessibility testing I use NVDA with Firefox & sometimes I also use NVDA with Chrome 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 Internet Explorer | 424 | 24.7% |
| NVDA with Firefox | 405 | 23.6% |
| JAWS with Firefox | 260 | 15.1% |
| VoiceOver with Safari | 172 | 10.0% |
| JAWS with Chrome | 112 | 6.5% |
| NVDA with Chrome | 102 | 5.9% |
| NVDA with IE | 40 | 2.3% |
| VoiceOver with Chrome | 24 | 1.4% |
| Other combinations | 180 | 10.5% |
At my work place we follow testing on Firefox 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. Even according to NVAccess, creators of NVDA the best browser that NVDA supports is Firefox.
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:
- Voiceover with Safari on IOS & OSx
- Talkback with Chrome on Android
- NVDA with Firefox on Windows
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.
Jaws is used by approx. half of all blind people, so why would you leave it out completely?
Hi Randy,
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
Hello Anu,
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.
Hello Randy,
I tested the website with multiple screen readers & browsers… I am able to reply & post comments without problems.
Hi Ragh,
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?
Hello Ranjita,
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.
HI Peri
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?
Hello sujatha,
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.
Hi Peri,
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.
Hello Kritika,
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.
Hello Garry,
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.