When you’re designing and developing for accessibility, performing manual testing using a screen reader is important to catch and fix accessibility and usability issues that cannot be caught by automated accessibility checkers. You can catch the majority of issues by performing testing using the screen readers that your users rely on the most.
If you haven’t already, you want to set up a screen reader testing environment on your computer, and invest a little learning time to get acquainted with the most relevant screen reader commands and shortcuts that you will need to perfom basic manual testing with a screen reader on a day-to-day basis.
In this chapter, we will walk through setting up a screen reader testing environment on your computer. We will discuss software options you have to do that (both free and premium), and what screen reader and browser combinations to test with. We will also go through enabling accessibility testing on a Mac (which requires a little manual work to do). And finally, we will learn about a few useful features and cheasheets that make testing a little friendlier when you’re just getting started.
macOS vs Windows screen readers
Both Windows and macOS come with screen readers built into them that are available for free. The built-in Windows screen reader is called Narrator. The macOS built-in screen reader is VoiceOver.
According to WebAIM’s screen reader user survey, more than 90% of screen reader users reported being on Windows. And according to the same survey, the two most popular screen readers are JAWS (Job Access With Speech) and NVDA (NonVisual Desktop Access) (which are both Windows screen readers), followed by VoiceOver.
If you’re already on Windows or if you own a Windows machine, you’re already halfway through setting up your screen reader-testing environment.
If you’re on a macOS computer, you shouldn’t test solely with VoiceOver. It is more opinionated and does not always reflect what the majority of screen reader users experiences.
If you’re on macOS and you have no access to a Windows machine (whether an actual machine or a virtual one), you can test your work with Windows screen readers using any modern browser instead. We’ll get back to this in another section.
Setting up Windows screen readers
JAWS is the most popular and feature-rich screen reader. a JAWS license isn’t free and is faily expensive. But you can still use it to perform testing for your work. JAWS will run in full in demo mode for 40 minutes at a time, until it is activated on your computer. While this is a limitation for longer testing sessions, the 40 minutes are usually more than enough to perform basic testing.
NVDA is a feature-rich, free alternative to JAWS. We will install and set up NVDA in the following sections.
Download NVDA screen reader on Windows
NVDA is available for free, but a donation is strongly encouraged.
Click the Download button. Wait for NVDA to download. And go through the installation wizard when it’s done.
Visualize NVDA’s current focus target with Visual Highlight
To make testing with NVDA more convenient (especially if you’re new to screen reader testing), I recommend enabling NVDA’s Visual Highlight feature.
To enable it, go to Preferences > Settings > Vision > Visual Highlight, and check the Enable Highlighting option.
What this does is it shows a focus highlight around the element that NVDA is currently focused on — whether it’s in a webpage or anywhere on your system. This feature is useful for partially-sighted screen reader users who want to track the location of the NVDA navigator object and the currently-focused element. Seeing where the screen reader’s current focus is at is also helpful for you when you’re performing testing, especially if you’re recording your screen for an educational video, for example. ^^
Enable NVDA speech viewer
Another helpful feature you can enable is the NVDA Speech Viewer log window.
Click the NVDA icon in your taskbar (on the bottom right of your screen by default), and go to NVDA > Tools and enable Speech Viewer. You also have the option to open the speech viewer log window by default on NVDA startup.
The speech viewer log window contains the text that NVDA speaks, which can be helpful when you’re just getting started with screen reader testing. Just keep in mind that its usefulness of sometimes limited because the log often does not fully represent what is announced.
Setup keyboard layout for testing with NVDA on a Mac
If you’re on a Mac, go to NVDA > Preferences > Settings > Keyboard and Choose “Laptop” Keyboard layout instead of the default Desktop option. The desktop layout relies on many keys which do not exist on some Mac keyboards. You can also set this preference in NVDA’s start popup menu.
Map the Insert key to another key on Mac
The insert key is the default modifier key used by most screen readers on Windows. If you don’t own an external keyboard that has an insert key, you might need to use a software work-around to make up for the lack of the insert key on your keyboard.
NVDA settings include an option to set the caps lock key as the NVDA modifier key. You can do that if you prefer. I personally prefer to not do that because it interferes with typing when the caps lock is On.
Alternatively, you can use a software program to map one of your less-used keyboard keys to the missing insert key. I use Karabiner Elements.
Setting up Karabiner Elements on macOS
Karabiner is a free app. To use it:
- Download the app from the Karabiner Elements Website. You want to download it on your Mac, not in your virtual machine.
- Run through the setup, and make sure to enable access in your System Preferences settings if it is blocked by macOS (which it probably will be by default).
- Once it is installed and your keyboard is recognized, go to Simple Modifications.
- Choose the device(s) you want to create a mapping for, and then click Add Item to map an unused key to the insert key.
In my Karabiner, I mapped the right option key to the Windows insert key. And I also mapped the right cmd key to the print screen key, which can be used in combination with other keys to quickly turn Windows High Contrast mode On and Off (which is a shortcut that will come in handy in another chapter).
That’s it. Now if you open your VM and fire up a screen reader, you can use the right option key (or the key of your choice) as a modifier key in place of the insert key.
Virtual accessibility testing in your browser
If you’re on macOS and you have no access to a Windows machine, you can test your work with Windows screen readers using any modern browser instead. You can do that using a service called AssistivLabs.
AssistivLabs is to screen reader testing what BrowserStack is to cross-browser testing. It remotely connects you to real assistive technologies (like NVDA, JAWS, and Windows High Contrast Mode) using any modern web browser.
AssitivLabs currently only offers testing with Windows screen readers and assistive technologies (like Windows High Contrast Mode and Windows Magnifier) for most accounts; testing using macOS assistive technologies will be available in the future.
AssitivLabs is a paid service — it’s not available for free by default. But it is very helpful for when and if getting access to a Windows machine is otherwise not possible.
Enable keyboard accessibility on a Mac
To complement your screen reader, you should enable keyboard accessibility on your Mac.
Keyboard accessibility is not enabled by default on macOS. If you’ve ever tried to tab your way through interactive and focusable elements on webpages and couldn’t, that’s why. (Frustrating, I know.)
You need to manually enable keyboard accessibility on macOS by going to System Preferences > Keyboard, and enabling the “Use keyboard navigation to move focus between controls” option in the Shortcuts tab.
On macOS 13+, you’ll go to System Preferences > Keyboard, and then enable the Keyboard Navigation (Use keyboard navigation to move focus between controls. Press the Tab key to move focus forwards and Shift Tab to move focus backwards) option.
Once you’ve enabled system-wide keyboard accessibility, you want to also enable keyboard tabbing in Safari.
In Safari, go to Preferences > Advanced. And enable the “Press tab to highlight each item on a webpage” option.
Now you can tab your way through webpages as you should.
Which browser and screen reader pairings should you test on?
Screen readers work best when they are paired with the browsers they are the most compatible with. When performing testing, you can catch most accessibility issues (sometimes even all of them) by pairing each screen reader with the browser it is most commonly used with.
VoiceOver works best with (and should, therefore, be paired with) Safari. If you use VoiceOver with Chrome or Firefox, for example, you might get unexpected results because VoiceOver is optimized to work with Safari not with other browsers.
Narrator works best with Edge, and has difficulty interfacing with other browsers. But Narrator isn’t most users’ first choice.
JAWS — the most popular of all screen readers on Windows — works best with Chrome and Firefox. When perfoming testing, pair it with Chrome.
NVDA works best and is commonly paired with Firefox.
Mobile screen readers
Throughout this course, we will focus mainly on desktop screen reader testing. But you should test your work using mobile screen readers as well.
In WebAIM’s ninth screen reader user survey, 90% of respondents reported using a screen reader on a mobile device. According to WebAIM, this number has increased over the last 12 years. WebAIM also notes that participants with disabilities (91.6%) are more likely to use a mobile screen reader compared to individuals surveyed without disabilities (71.4%). So it is very important that you test your work on mobile to ensure that it works for a large group of screen reader users.
VoiceOver on iOS/iPadOS is the most popular mobile screen reader. VoiceOver comes bundled with iOS/iPadOS. Like its desktop version, you want to use it in conjunction with mobile Safari.
On Android, Talkback (the built-in screen reader) is best paired with Chrome.
Guides to browsing and navigating content with a screen reader
Make some time to learn how to navigate and browse web content with each screen reader. It might take some time and feel like a steep learning curve at first, but by doing that you will gain an invaluable skill for your accessibility work.
Here is a list of official user guides that are helpful for getting started:
- NVDA User guide. Most read-only webpages are browsed in NVDA using Browse mode.
- JAWS documentation (Shortcut to JAWS Hotkeys)
- Complete guide to Narrator (Shortcut to Narrator keyboard commands and touch gestures)
- VoiceOver Guide
- Talkback user guides
- Turn on and practice VoiceOver on iPhone
And to get a high-level (yet practical) overview of how someone using a screen reader browses the Web, I recommend watching the Browsing with assistive technologies video series by Tetralogical:
Screen reader keyboard shortcut cheatsheets
When you’re just getting started with screen reader testing, and you want to test with at least three screen readers across different platforms and devices, it can be difficult to remember all the keyboard shortcuts for each screen reader right away.
Deque University provides useful screen reader keyboard shortcuts and gestures cheatsheets, that you can either reference on your computer, or print out and have them handy during your testing.
- Desktop Screen Readers Survival Guide - Basic Keyboard Shortcuts
- Desktop Screen Readers Forms Guide
- NVDA keyboard shortcuts
- JAWS keyboard shortcuts
- Narrator keyboard shortcuts
- VoiceOver keyboard shortcuts
Resources and recommended reading
- Efficiency in Accessibility Testing or, Why Usability Testing Should be Last
- Checking Windows High Contrast mode on a Mac for free (inculdes instructions to download and set-up VirtualBox)
- Using Windows Screen Readers on a Mac
- The WebAIM screen reader user survey
- No, tabbing is not broken. Yes, I was confused too.
- Browser keyboard navigation in macOS
- The Importance Of Manual Accessibility Testing
- Your Accessibility Claims Are Wrong, Unless…
- Relevant combinations of screen readers and browsers