A screen reader is an important accessibility tool for people with no or limited vision. People who are blind or those with low vision can use a screen reader to navigate the computer. Screen readers will read contents on the screen and explain to the user what is on the page. Screen readers allow people to use the computer for daily tasks.
There are many screen reader software available for people through their operating system or through open source projects.
A 2021 research by WebAim found that from 1568 responders, more than 53.7 percent of people surveyed used JAWS on Windows, more than 30.7 percent of people used NVDA on Windows and little over 6.5 percent of people used VoiceOver on macOS.
JAWS and NVDA for Windows and VoiceOver for macOS are the most popular screen readers people use.
First, I should clarify that this article will be written from my point of view. To give background, I have been a front-end developer at a non-profit for people with learning differences for over three years. I, along with my colleagues, seek to make our projects more accessible every day. I am not visually impaired and do not use these tools on a regular basis. For work, I have a Mac machine and test accessibility using VoiceOver.
Here is my planned testing methodology:
- Navigate the page by heading, until “Accessibility APIs” section.
- Reason for this step: A 2016 survey by Heydon Pickering found that most people who use screen readers navigate new pages by headings
- In the “Accessibility APIs” section, read the content and the unordered list inside.
TABto hear focusable items in the unordered list.
- Jump to the Search field.
TABto hear a few items in the navigation section
To find similarities and differences between them, I decided to test a set of steps with each screen reader on a Wikipedia page about screen readers. I will browse the web with Chrome for my tests. Testing all screen readers on the same page and browser will reduce the amount of variables and keep the tests consistent.
JAWS is an acronym for Job Access With Speech and is the most widely used screen reader in the world. It is only available on Windows. Depending on the plan and features, JAWS can be purchased anywhere from $90 yearly license all the way to $1605 for perpetual license.
JAWS has predefined keyboard commands to navigate the web. Full list of keyboard commands can be found on their website.
In the beginning of the demo, I am clicking on
H key on my keyboard to go to the next heading. JAWS is moving down the page, reading me the headings along with their level.
Later in the video, I am clicking on number
2 and number
3 on my keyboard to have JAWS read Heading Levels 2s then later Heading Levels 3s. This is a great feature because we can move down the page and sections by heading level and get a better sense of the page layout.
When I reach the “Accessible APIs” section, I press the
DOWN ARROW key until the third item in the unordered list.
Later in the demo, I am clicking on the
TAB key for JAWS to read to me the next focusable item on the page, which is inside this list. I click
TAB until I reach a focusable element in another section.
Then I press
F key to focus on the search field, which JAWS reads to me.
Then I click on
TAB and JAWS focuses on the navigation elements that are on the side of the page.
Pros & Cons
- JAWS is more customizable than other screen readers.
- There are more options to navigate through the page.
- JAWS is industry standard.
- Widely used, which means there are lots of user to user support.
- JAWS is more complicated to use than NVDA or VoiceOver.
- Some commands are not intuitive.
- There are a lot more commands for the user to learn.
- More learning curve for users.
- JAWS is also not available on the Mac, which limits its users.
- Costs anywhere between $90 – $1605 for the user.
- JAWS has different key commands for desktop and laptop which may make it harder for users to transfer knowledge and may cause confusion.
NVDA, or NonVisual Digital Access, is available on Windows only. Users need to download the software from NVDA’s website, NVAccess. This software is free to download but does not come already installed on Windows machines. NVDA is the second most popular screen reader in the world according to WebAim’s 2021 survey.
Like other screen readers, NVDA has defined keyboard commands to navigate the web. NVDA’s full keyboard commands can be found on their website.
In the demo I am clicking on
H key on the keyboard to go to the next heading. First, NVDA reads me Heading Level 1, which is “Screen reader”. Then NVDA goes to read Heading Level 2s and 3s.
When I reach “References” I begin to click on
TAB on my keyboard for NVDA to focus on next focusable items.
After focusing on a few items on the list, I click
ENTER and go to the New York Times page.
Pros & Cons
- Overall, I found NVDA was able to provide me with information on the screen.
- The out-of-the-box keyboard commands were easy to use and easy to learn.
- NVDA is open source, which means the community can update and fix.
- NVDA is free, which makes it an affordable option to Windows users.
- NVDA is not available on the Mac, which limits its users.
VoiceOver is the screen reader used in Mac. VoiceOver is only available on Mac not available in Windows. VoiceOver is free and is already installed on the computer, which removes barriers because this is part of the computer setup and the user does not have to download or purchase any additional software.
VoiceOver has defined keyboard commands to navigate the web. VoiceOver’s full keyboard commands can be found on their website.
In the demo, I am on a Wikipedia page and I am clicking on the VoiceOver Command (which is
Control+Option) along with
Command+H to navigate through the headings. VoiceOver reads the headings in order, starting from Heading Level 1, “Screen Reader”, to Heading Level 2, “Contents”, to Heading Level 3, and so on.
When I reach the “Accessibility APIs” section, I click on VoiceOver Command plus the
RIGHT ARROW, to tell VoiceOver that I want it to read this section. Later I am clicking on the VoiceOver Command plus the
RIGHT ARROW on my keyboard, to navigate the section.
When I get on to the third item on the unordered list, I press
TAB on my keyboard to focus on the next focusable element.
TAB a few times, then I press VoiceOver Command plus
U, to open the Form Control Menu. In the menu, I press
DOWN ARROW until I hear the “Search Wikipedia” option. When I hear it, I click
ENTER and the screen reader focuses on the form field. In the form field, I press
TAB to navigate to the navigation section.
Pros & Cons
- VoiceOver is easy to use and learn.
- VoiceOver’s commands are intuitive.
- Free tool that comes installed in every macOS device.
- VoiceOver is also not available on Windows, which limits its users.
- VoiceOver is not an app and can only be updated when Apple releases macOS update.
A screen reader is an important accessibility tool for people with no or limited vision. Screen readers allow people to use the computer for daily tasks.
There are many screen reader softwares available. In this article I compared JAWS, NVDA, and VoiceOver.
Here is a comparison chart overview of the three screen readers:
|Price||$90 – $1695||Free||Free|
|# of users||50%||30%||6%|
|Ease of Use (subjective)||Hard||Easy||Easy|
I found that for basic screen reader testing, most screen readers follow a similar keystroke pattern and knowledge from one screen reader can be used for others.
All screen readers have their pros and cons. Ultimately, it’s up to user preference and also the operating system they use to determine which screen reader software is best for them.
Previously: “Small Tweaks That Can Make a Huge Impact on Your Website’s Accessibility” (2018), and “Why, How, and When to Use Semantic HTML and ARIA” (2019), “15 Things to Improve Your Website Accessibility” (2020), “5 Accessibility Quick Wins You Can Implement Today” (2022).
“Not free” and “Hard to use” really feels like it should be a deal-breaker for JAWS…
Yeah that price is eye-watering.
Really like the description of your methodology, I think this is a good way of thinking when approaching work on accessibility.
I object to some of your assertions. I question the need for a screenreader to be supported across operating systems. Comparing Windows to iOS is like comparing apples to oranges. Each operating system has a good screenreader solution and there isn’t a need to reinvent the wheel by making screenreaders work across operating systems. If someone wants to use one computer for both Apple and Windows operating systems they can run Windows from a mac and use any Windows screenreader they want. Claiming that JAWS is hard to learn is misleading. All screenreaders have many commands and blind people tend to memorize the commands they use the most and look up other commands when they need them. NVDA doesn’t have all of the features of JAWS but it does have a learning curve and many commands. Memorizing keyboard commands is one of the only ways a blind user can interact with an operating system. They can use a track pad in IOS or touch gestures in Windows but there is a learning curve. Fortunately, there is good documentation and training avaialble for JAWS, NVDA, and VoiceOver. Much of the training is free.
Your test cases are incomplete. I haven’t used a mac but I can document what other testing you should do in Windows. First, keep in mind that a screenreader will announce some text differently in forms mode than browse ode. Ideally screenreaders should announce everything in tab order but this is not always the case. There is the assumption that the user will interact with editable items from browse mode. They will have already reviewed the page content before filling out a form. I would add additional testing for page structure and form elements. Before navigating the headings read the page title using the JAWS or NVDA modifier keys with the letter ‘t’ to read the page title. Page titles need to reference the site and be meaningful. I would navigate the page in browse mode to test if the screenrreaderr can move focus to an actionable element like a button, drop-down menu, checkbox, list item, landmarkr, region, form field, and edit field. The commands vary slightly between JAWS and NVDA but both screenreaders have lists of keyboard commands. I would also interact with the page by filling out a form or perforrming a search. When filling out a form does the screenreader announce the role, state, and value of the control I.E. which butrton or drop-down menu item was selected or is a checkbox checked or unchecked. When filling out the form determine if there are meaningful field lables. See what the screenreaders announce as you move in tab order. Determine if the screeenreadeer provides spoken feedbakc for errors. Ideally errors should be announced as a user navigates a form, or after the user submits it. If you submit a for, determine if the screenreader announced any error o validdation message, announced the number of errors, and moved focus to the first error. Test expandable menus. Doess the screenreader announce ‘collapsed’ or expanded’ when you interact with the menu. Test a search function. After you submit the search, does the screenreader announce the number of search results and does the page move focus to the first search results. Test a search function with auto-complete. Does the screenreader announce search results as they are populated on the page.
This list is not exhaustive. Here are some general comments. Stating that a screenreader is difficult to learn is misleading. Every blind person has a different approach to using a computer. Some people find one screenreader or operating system easier to learn and it meets their needs. Others have ddifficulty with computer concepts and any screenreader. You ddidn’t state which browsers you use. Screenreaders will respond differently on a given webiste or browser. Some screenreaders work better with specific browsers. Screenreadeer compatability changes from time to time so do your research to determine which browsers to use. You didnt’ mention which versions of perating systems you use, or which specific computer types and models. This may make a difference. A current computer whether Windows or mac will perform better due to a faster processor speed and the amount of RAM the machines have. Ideally the morre RAM, the better the screenreader will perform.
Using price as a selection criteria is not adequate. Some people are required to use JAWS because their employer or school wasnts a secure solution. In those cases the employer or school may provide JAWS tot he end user. I do agree that NVDA is more cost-effective but there are cases where a user needs to use JAWS. You didn’t mention the price of computers which is also a factor. Apple computers tend to be more expensive than Windows. keep in mind that most blind people make informed decisions about which screenreadeer and computer to use. Your assertions won’t change anyone’s mind. The person will have done their homework and made the best decision which works for them. You ddidn’t mention testing on mobile devices. This is crucial as mmore blind people are using mobile devices of kinds. I am not familair with the Apple environment but do use JAWS and NVDA. Each screenrreader has its strengths and weaknesses but I need both of them.
I suggest before you do another round of testing that you talk to blind people first. Find out what their needs and use cases are. Do your homework before you start testing and writing a blog entry. That will help you make a more informed report.
As someone who read this article for the purposes of understanding the way screen readers function in order to better make web pages (not because I’d need them for myself) I must disagree with your disagreements. (the article also read like it was meant for web developers, not the soon-to-need-visual-assistance)
1: “I question the need for a screenreader to be supported across operating systems.”: A little hard to support software if one needs to buy multiple computers to do it with (or at least be bound to using overpriced macs and then dual-boot into one’s preferred operating system) (and no a hackingtosh is not a legitimate solution to this)
2:”Using price as a selection criteria is not adequate.”: price is always worth considering, If there is a cheaper version with the same bugs/problems/idiosyncrasies then it is an adequate substitute for testing.
3:”Some people are required to use JAWS ” regrettable, given the price I won’t be testing with it though, not unless working in an office that already has it installed for someone else.
4:”You didn’t mention the price of computers which is also a factor.”: Ouch, lets just casually double the cost of a workstation (or do you think the overlap between very high compute needs and screen reader needs in more than minuscule?) but seriously see the comment I made about you dismissing multi-platform support and add the costs up for all that.
5:”You didn’t mention testing on mobile devices.”:again; multi-platform support would be a nice to have.
Thanks for the valid criticism here. I think some of the contention here may have stemmed from the title that gave the suggestion that there would be a comprehensive comparison versus an introduction for folks unfamiliar with these tools. We’ve changed the title to better reflect this.
We also would greatly encourage and appreciate anyone that uses these tools on a regular basis to share their experience by submitting a guest writing proposal!
The table flips the % of users of JAWS and NVDA should be JAWS 50% NVDA 30%
Also think the “ease of use” metric is totally subjective.
Thank you. That was probably on my end when converting formatting. Corrected.
Added a note about “subjective” for clarity.
Is the number “of users” in the chart a typo? JAWS seems to have more users than NVDA according to WebAIM.
Thank you. I think this was due to a formatting error. Corrected.
Thanks for the comparison, Ilknur. Just a small comment about testing in Chrome. VoiceOver is not supported in Chrome. Always use Safari.
Note that those numbers are specifically for “primary desktop/laptop” screen reader, not “only” screen reader or even “preferred” screen reader.
The overwhelming majority of people reported using VoiceOver as their mobile device screen reader (72%), and disabled users were reported as being much more likely to be using their mobile device than others (91.6% to 71.4%).
Just all to say — those “primary desktop” numbers are often misquoted as saying desktop JAWS is the standard…but the rest of the survey reveals that fewer disabled users rely on desktop JAWS than mobile VoiceOver.
I would be curious to hear the author’s opinion on Narrator, the screen reader built in to Windows, and how it compares to the others.
Thank you Ilknur for the screen reader demo videos! These are very difficult to find, and I’ve already spent significant time searching on Google and YouTube.
I worked a past contract job where I tested the Microsoft Office website (now called Microsoft 365 at https://www.microsoft.com/en-us/microsoft-365) for accessibility issues and made code fixes.
I had to use real devices, such as VoiceOver on an iPhone, to ensure my fixes worked.
Fortunately, some people have already brought my concerns. Sorry to admit, but this article is highly subjective and in many points misleading. Disclaimer: I’m blind from birth, worked in the accessibility field and have been using screen readers for decades.
1. JAWS is hard to learn, NVDA is easy. For whom? I’m a JAWS user since 1998, and still cannot get used to NVDA. JAWS has an extensive corpus of training materials in text, audio and video forms to get you started. Of course, if you need an Internet-connected typewriter, JAWS is an overkill for you. To me and other people like me it gives enormous flexibility and ability to work in a professional environment.
2. VoiceOver commands are intuitive, JAWS ones are not. This particular paragraph actually killed my laziness to write a proper long comment to the article. I mean, WAT? Again, I’m a Windows user since 1998, and I tried Mac for a couple months in 2020 (fortunately my employer agreed that it is not the environment for me to work on). If you are an Apple user, well, maybe you run VoiceOver and everything is great and sweet for you. but for me, a Windows guy, it is not the case: the fact that arrow keys don’t work normally on web pages unless you enter a specific quick navigation mode just drove me nuts (otherwise you always have to hold those infamous VoiceOver keys, Ctrl+Option). The fact that I personally couldn’t find commands for very basic stuff like telling time is also very “intuitive”, yes. And yeah, Braille support on Mac is awful (you don’t mention Braille at all, right?). to be honest, Chrome on Mac is actually accessible, allbeit not really as it should be, but still.
3. JAWS keyboard commands are hard, NVDA commands are easy. But come on, JAWS keyboard commands are the standard, and NVDA simply took them for the most part, and even Narrator (under the pressure of users like me) adopted those commands like Insert+UpArrow for reading line, Insert+T for reating window title and so on. that has been around in JAWS since the times of yore.
4. JAWS has desktop and laptop layouts, which is complicated. Again, WAT? That was made for convenience. JAWS is a very mature product, and when it all began, laptops were not common at all, so we use the number pad for many things. Then, when the laptops without the number pad came, people at Freedom Scientific decided to add a layout, and not to change everything to satisfy laptop users by depriving the full-keyboard desktop users of their usual commands, that’s it. Today the tendence is to teach new people the laptop layout, because guess what? It works even with desktop computers and full-fledged keyboards, and most of the desktop commands are available in the laptop layout. So it’s rather an extension than a complication.
5. Conclusion. The fact that most of the frontend developers, even aware of accessibility, work and test solely on Mac, is very unfortunate and very often lead to extremely annoying accessibility issues on Windows. Windows is the non-mobile operating system blind and partially sighted users use the most, so not considering it, not testing on it is a very bad decision from the point of accessibility.