Sharvari Desai

Manual accessibility testing

Note: This was originally posted on the Zapier internal engineering blog. I'm grateful to my Zapier coworkers who provided initial feedback on this guide.

As a frontend engineer, finding and fixing accessibility issues is an essential part of the job. In the hope that someone may learn something from it, I want to share how I personally go about manually testing frontends for accessibility.

Why do manual accessibility testing?

There are some great tools available today to complete automated accessibility testing, and I'll discuss some of those at the end of this post. However, manual testing still has its benefits because automated testing doesn’t catch everything. Testing manually also helps build empathy for our users who may use the interfaces we build differently from how we do.

A step-by-step guide

When I’m completing manual accessibility testing, I will usually refer to this checklist of items to check for, but it can be overwhelming to figure out where to start. So let’s take it step by step! If you're an engineer, feel free to open a web page that you’re responsible for and follow along.

1. Start by just looking at the page.

If you’re building interfaces, you’ve probably already looked at the visual output, but this time, let’s go through the following questions:

2. Keep hitting that tab key.

When you load the page, start hitting the Tab key on your keyboard and ask yourself the following questions:

3. Fire up that screen reader.

Screen readers are programs that read on-screen content aloud. If you’re on a Mac, you’re lucky enough to already have a screen reader ready for you to use! Just head to System Preferences -> Accessibility -> VoiceOver and check the Enable VoiceOver checkbox to turn it on. Once you hit the checkbox, it will immediately start reading what’s on your screen, so I recommend turning your sound down or even off before doing so. You can learn more about VoiceOver here.

Not on a Mac? No problem, Windows has its own Narrator screen reader and there are several other screen reader options available for download.

The guide below includes keyboard shortcuts default to VoiceOver, but there should be equivalents for all screen readers.

4. Use testing tools.

Finally, I like to run some testing tools on my page to catch anything I missed in previous steps, especially issues like color contrast which may not be immediately discernible to my eyes. One such testing tool, Lighthouse, is built into the Chrome browser. Open the developer console and click the Lighthouse tab to generate an accessibility report:

generate a Lighthouse accessibility report

The axe DevTools extension can also be useful for doing a full accessibility scan of your page, but the more in-depth scans will require a Pro subscription.

And that’s it! This is by no means an exhaustive guide to manual accessibility testing, but it’s a great start. It doesn’t hurt to go through this accessibility checklist again at the end to make sure you’ve considered everything.

At this point, you’ve hopefully made your little corner of the internet more accessible and gained some empathy for your users along the way! However, keep in mind that you’ll never be “done” with accessibility. Your product is likely always changing, adding new features, and fixing bugs, and every change has the opportunity to make the product more or less accessible. Therefore, it’s important to test for accessibility often and advocate for it in all aspects of the build and testing process.