After a recent talk on Accessibility, I was asked during the Q&A about what Assistive Technologies (AT) I test with while I’m developing. Such a good question! I hadn’t ever thought about what I actually test with and as I rambled on I thought it might help to write it down.

1. Keyboard

Your keyboard is probably the first line of defense for testing your code for accessibility.

  1. Can you Tab through the page without getting lost?
  2. Do all focusable elements have focus states?
  3. Do you have a skip navigation link?
  4. When you encounter form controls, do the arrow keys work as expected?
  5. Can you operate tabs, accordions, quick search results, etc with just your keyboard?

The answers might surprise you!

2. Screen Reader

I’ve learned to operate a few different screen readers over the years. I am by no means proficient, but here they are:

  1. VoiceOver (macOS) - Probably the best screen reader on the market as well as the default screen reader for macOS. It has a pretty decent UI that can help sighted users understand VoiceOver’s mechanics.
  2. Narrator (Windows) - Narrator is a nice screen reader built-in to Windows 10. Only one problem, it’s not very popular, so it’s results can be misleading.
  3. NVDA (Windows) - NVDA is free and created by two non-sighted developers. It’s relatively popular as far as screen readers go and while it doesn’t have all the latest bells and whistles, it’s what I use to test with and I feel it gives an accurate picture of the screen reader landscape.
  4. Chrome Vox (Chrome & ChromeOS) - Chrome Vox is an in-browser screen reader that can be installed as a Chrome extension. It has the best on-boarding tutorial of any screen reader and the most obvious focus overlay for sighted users.

The A11Y Project has tutorials on NVDA and VoiceOver. For a more in-depth look, I recommend Sue Lockwood’s posts on “Using NVDA on Windows” and “Getting Started with VoiceOver”. And I highly recommend configuring your Mac to sound like Chris Hemsworth.

One screen reader I haven’t used but is very common is JAWS (Windows). But it costs ~$900 so.. that’s not fun.

It would be a dream of mine for every designer and developer to be fluent in at least one screen reader. But it’s important to recognize that the way you (a novice) use a screen reader and the way a non-sighted person (an expert) uses a screen reader will be totally different. Be sure to test with actual users.

But if learning a screen reader is too daunting for you, Chrome’s Developer Tools has started attempting to show hints on how the elements will be announced out by the AT.

3. VoiceOver for iOS

VoiceOver for iOS is an amazing accessibility tool to have in your pocket. And I literally mean your pocket. I often send a link to myself in Slack and open it up on my phone and perform a “pocket check” using VoiceOver for iOS.

  1. Tap Home Button (or Power Button in iPhone X) 3 times to turn on/off.
  2. Two-finger swipe down to read the page.
  3. Swipe left or right to go to previous and next readable element.

There’s more to it than this of course, but what’s relevant about mobile screen reader testing is that the disabled community depend on their phones quite a bit. Make it good here and you’ve improved a lot of lives.

4. Set Brightness to Low

While not technically a piece of Assistive Technology, one of my favorite checks is to turn your phone or laptop screen’s brightness all the way down. Now go out in the sun. Can still read text and discern elements? If yes, you probably have decent contrast. If no, then you got work to do. This is another great little “pocket check” technique that can be done quickly and cheaply.

5. 200% Zoom

Another tool I use is to Zoom my browser to 200% and see what breaks. This is important and accounts for low-vision users, people who might be technically blind, but not actually blind, so they scale up their browser or use a screen magnifier to browse. If you practice good RWD, you should be okay in most cases, but watch out for absolute and fixed positioned elements.

6. High Contrast Mode on Windows

High Contrast Mode on Windows isn’t very well known, but often times low-vision users will use high contrast mode (in addition to magnification). There are some quirks with websites and High Contrast Mode (no background images, no custom colors, some elements like buttons need borders, etc) so it’s a good tool to learn how to test with and easy to enable/disable in Windows 10.

I am not an expert…

The more I learn about accessibility, the more I realize how much I’ve messed up. So take these testing tips with a grain of salt. But I think it’s important that all designers and developers know and understand how to do baseline accessibility checks themselves. Doing spot checks early and often can produce great results. There’s other utilities I use like Color Oracle to simulate color blindness, but a utility roundup is another post for another day.