This is a repost of an old article on the Tenon blog. Since that’s being sunsetted, I’m reposting it below.
There are many ways to perform testing for accessibility, each one with their own strengths and weaknesses. Testing with assistive technologies is a great way to get a clear understanding of how your system behaves for real users – assuming that the tester is able to effectively use the assistive technologies they’re testing with. As a kickoff point, here are some valuable tips and tricks we’ve discovered during our own testing experiences.
Know when it’s time to test
Our first tip is to avoid testing with assistive technologies if you’re not ready to do so. At a minimum, you should ensure you’re passing automated accessibility testing before firing up a screen reader.
Software Assistive Technologies, like all software, have bugs. It can sometimes be difficult to track down where in the technology stack an issue exists. Is it in the Accessibility API? Is it in the browser? Is it in the assistive technology? Or is it in your website? For clarity’s sake, make sure you’ve tackled the things an automated tool like Tenon can tell you before beginning any AT testing.
Test with a purpose in mind
It rarely makes sense to just turn on a screen reader and start tabbing around the page. This practice does not accurately represent the experience of real users who visit your site with a screen reader. Additionally, it isn’t a very efficient way to find accessibility problems. Therefore, you need to test with a specific purpose in mind.
For instance, using assistive technologies when performing a scripted use case test is great. Using a screen reader to find out whether images have text alternatives is not so great, because an automated tool like Tenon is a faster way to get that information.
Checking for bugs
If you’ve done your part in making sure you’ve followed good semantic markup practices and are passing automated tests in Tenon, but testing with AT still doesn’t work out right, it could be an AT or browser bug. If you suspect this is the case, you’ll want to address and report it properly.
Digital A11Y provides links to various issue trackers for assistive technologies and browsers. In any instance where something isn’t right and you think it should be, it doesn’t hurt to check and see if you’re experiencing a bug elsewhere in the technology stack.
Specifics with screen readers
Screen readers can be difficult to please, especially because they don’t have any way of understanding context. There is only so much you can do to appease the way a screen reader is going to translate written text. Understand that mispronunciations on the screen reader’s part are not violations of accessibility.
As such, you don’t have to get hung up on correcting how a screen reader pronounces something. For instance, the first three digits of the Tenon phone number (443-489-6549) might get announced as “four-hundred-forty-three”, and that’s OK. Other things that might sound like they’re getting read aloud wrong are abbreviations, acronyms, and homonyms.
If your goal is to check that your visible content is going to be read out (separate from any speech viewer they have), turn on any highlighting options that the screen reader offers. VoiceOver on macOS and Narrator do this by default; NVDA features a highlight setting that can be enabled based on a user’s preferences.
Understand your assistive technology
Learn about the assistive technology you’re using before doing any real testing. For instance, try to fill out forms or completely navigate a discrete task with Dragon Speech Recognition Software. After going through enough practice forms to be comfortable with how to use Dragon and after your Dragon has had time to learn from you, you will be able to test more effectively.
You don’t need to test in every browser with every screen reader. In fact, some combinations work better than others, and some combinations don’t work at all.
Just because you can access an actionable element with a keyboard AND a screen reader doesn’t always mean that it is keyboard accessible. Sometimes, a screen reader might detect a click handler bound to an element and automatically fire that same handler when you press the Enter key. This is a feature that works for the benefit of screen reader users. However, with the screen reader off this workaround isn’t available and, as a result, won’t be available for those users who need keyboard accessibility but don’t use a screen reader.