This module focuses on using assistive technology (AT) for accessibility testing. A person with disabilities can use AT to help increase, maintain, or improve the capabilities of performing a task.
In the digital space, ATs can be:
- No or low-tech: head and mouth sticks, hand-held magnifiers, devices with large buttons
- High-tech: voice-activated devices, eye-tracking devices, adaptive keyboards and mice
- Hardware: switch buttons, ergonomic keyboards, auto-refreshing Braille device
- Software: text-to-speech programs, live captions, screen readers
We encourage you to use multiple types of ATs in your overall testing workflow.
Screen reader testing basics
In this module, we focus on one of the most popular digital ATs, screen readers. A screen reader is a piece of software that reads the underlying code of a website or app. It then converts that information into speech or Braille output for the user.
Screen readers are essential for people who are blind and deafblind, but they can also benefit people with low vision, reading disorders, and cognitive disabilities.
Browser compatibility
There are multiple screen reader options available. The most popular screen readers are JAWS, NVDA, and VoiceOver for desktop computers and VoiceOver and Talkback for mobile devices.
Depending on your operating system (OS), favorite browser, and the device that you use, one screen reader may stand out as the best option. Most screen readers are built with specific hardware and web browsers in mind. When you use a screen reader with a browser it was not calibrated for, you may encounter more "bugs" or unexpected behavior. Screen readers work best when used in the following combinations.
| Screen reader | OS | Browser compatibility |
|---|---|---|
| Job Access With Speech (JAWS) | Windows | Chrome, Firefox, Edge |
| Non-Visual Desktop Access (NVDA) | Windows | Chrome and Firefox |
| Narrator | Windows | Edge |
| VoiceOver | macOS | Safari |
| Orca | Linux | Firefox |
| TalkBack | Android | Chrome and Firefox |
| VoiceOver (for mobile) | iOS | Safari |
| ChromeVox | ChromeOS | Chrome |
Screen reader commands
Once you have the proper set-up for your screen reader software for your desktop or mobile device, you should look at the screen reader documentation (linked in the preceding table) and run through some essential screen reader commands to familiarize yourself with the technology. If you have used a screen reader before, consider trying out a new one!
When using a screen reader for accessibility testing, your goal is to detect problems in your code that interfere with the usage of your website or app, not to emulate the experience of a screen reader user. As such, there is a lot you can do with some foundational knowledge, a few screen reader commands, and a bit (or a lot) of practice.
If you need to further understand the user experience of people using screen readers and other ATs, you can engage with many organizations and individuals to gain this valuable insight. Remember that using an AT to test code against a set of rules and asking users about their experience often yields different results. Both are important aspects to create fully inclusive products.
Key commands for desktop screen readers
| Element | NVDA (Windows) | VoiceOver (macOS) |
|---|---|---|
| General command keys | Insert | Control+Option |
| Stop audio | Control | Control |
| Read next/prev | ↓ or ↑ | Control+Option+→ or ← |
| Start reading | Insert↓ | Control+Option+A |
| Element List/Rotor | NVDA + F7 | Control+Option+U |
| Landmarks | D | Control+Option+U |
| Headings | H | Control+Option+Command+H |
| Links | K | Control+Option+Command+L |
| Form controls | F | Control+Option+Command+J |
| Tables | T | Control+OptionCommand+T |
| Within Tables | InsertAlt + ↓ ↑ ← → | Control+Option+↓ ↑ ← → |
Key commands for mobile screen readers
| Element | TalkBack (Android) | VoiceOver (iOS) |
|---|---|---|
| Explore | Drag one finger around the screen | Drag one finger around the screen |
| Select or activate | Double tap | Double tap |
| Move up or down | Swipe up or down with two fingers | Swipe up or down with three fingers |
| Change pages | Swipe left or right with two fingers | Swipe left or right with three fingers |
| Next/previous | Swipe left or right with one finger | Swipe left or right with one finger |
Screen reader testing demo
To test our demo, we used a Safari on a laptop running macOS and capture sound. You can walk through these steps using any screen reader, but the way you encounter some errors may be different from how it's described in this module.
Step 1
Visit the updated CodePen, which has all the automated and manual accessibility updates applied.
View it in debug mode to proceed with the
next tests. This is important, as it removes the <iframe> which surrounds the
demo web page, which may interfere with some testing tools. Learn more about
CodePen's debug mode.
Step 2
Activate the screen reader of your choice and go to the demo page. You may consider navigating through the entire page from top to bottom before focusing on specific issues.
We've recorded the our screen reader for each issue, before and after the fixes are applied to the demo. We encourage you to run through the demo with your own screen reader.
Issue 1: Content structure
Headings and landmarks are one of the primary ways people navigate using screen readers. If these aren't present, a screen reader user has to read the entire page to understand the context. This can take a lot of time and cause frustration.
If you try to navigate by either element in the demo, you'll quickly discover that they don't exist.
- Landmark example:
<div class="main">...</div> - Heading example:
<p class="h1">Join the Club</p>
If you have updated everything correctly, there shouldn't be any visual changes, but your screen reader experience will have dramatically improved.
Let's fix it.
Some inaccessible elements can't be observed by just looking at the site. You
may remember the importance of heading levels and semantic HTML from the
Content structure module. A piece of content
may look like a heading, but the content is actually wrapped in a stylized <div>.
To fix the issue with headings and landmarks, you must first identify each element that should be marked up as such and update the related HTML. Be sure to update the related CSS as well.
- Landmark example:
<main>...</main> - Heading example:
<h1>Join the Club</h1>
If you have updated everything correctly, there shouldn't be any visual changes, but your screen reader experience will have dramatically improved.
Issue 2: Link context
It's important to give content to screen reader users about the purpose of a link and if the link is redirecting them to a new location outside of the website or app.
In our demo, we fixed most of the links when we updated the active image alternative text, but there are a few additional links about the various rare diseases that could benefit from additional context—especially since they redirect to a new location.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>