How to do an accessibility audit

If you're reading this, I am hoping that you have good sense of what accessibility is. You know some of the things your website doesn't do so well, and some basic fixes for them. If you're looking for some accessibility basics, check out The a11y project.

Chances are, you're trying to push your company or project to be more accessible. They're on board, great! But you're working alone and you have all these things you want to fix and don't know where to get started.

At uSwitch there are lots of applications with accessibility issues I can improve. It can be overwhelming because I want to fix everything now. But, each app is different, and it is hard to know where to start.

Due to the nature of my role, I get to explore a new teams applications every few months. I can begin to fix things but leave them with a sense of what they can do themselves when I move to the next team.

Because I'll be doing this for so many different applications, before I even got started, I created an accessibility audit guide. Here is that guide!

What do you want to achieve?

First, what do you want to achieve for the thing you're auditing? "Make everything really accessible" is not a reasonable goal. Try "have the application meet at least AA standards".

I'm not saying you should ignore glaring inaccessibilities in your application if the problem is an AAA standard! Instead I'm saying set a reachable goal, so you have something to focus on. For the things I am auditing at uSwitch, my goal is to "reach AA standards, and give each team an idea of how to meet this".

Find a tool that works for you

There are many tools out there that automate or semi-automate accessibility testing. These tools are much faster than you and can find things you forgot/never considered!

Don't rely on one tool, though. A team at GDS discovered that Chrome's Accessibility Tools discovered only 19% of issues. Tenon (a paid option), found 37% of them.

I am using three tools at uSwitch. tota11y to get a quick overview, aXe to get a much more in-depth insight, and pa11y to do the same but also track changes in accessibility over time.

No tool is a good substitute for manual testing

Try navigating your pages with a keyboard. Can you tab to inputs in an ordered manner, is anything unreachable? Do you ever lose track of focus because a hidden element has stolen it?

Learn the basics of a screenreader like NVDA or VoiceOver (or, both!). Use it to read and navigate your site. Can you get to where you need to go? Do you have images that when read out, just don't make sense?

There is no substitute (currently) for manual testing. Do not skip it.

Write some basic instructions

It's easy to get lost when you're doing an audit, so write a little list of instructions for yourself.

Here's mine:

Grab some post it notes, write every bug you find on an individual note

Use tota11y, to get an overview of big pain points

Use the aXe chrome extensions

Set up a pa11y dashboard, or refer to one you’ve already set up

Run through the site with a keyboard

Run through the site with VoiceOver

I like to test main components of a website, so I can break things down. But it's also important to test the site as a whole, as a real user would.

Share your findings

An audit is fruitless unless you share your findings. Write a summary document that can every member of the team can understand (i.e. no need for technicals).

An extract from my most recent audit:

There are many instances where we fail colour contrast checks (meaning it is hard to see text against its background). This is due to the reliance on the light blue colour that we use across uSwitch. We can reduce our reliance on this colour and use alternatives that uStyle provides.

I presented these findings and answered questions in my next meeting with the team.

Decide on next steps

You know the problems, you have an idea of the solutions. What next? This very much depends on your team. The Car Insurance team (whom I last audited) has a "technical debt" Trello board, so I added an "accessibility" column. Each card is a bug, with a screenshot (where necessary) of it in action, and a suggested solution.

Make the problems visible to your team, but present them in an approachable way. This is a great opportunity to introduce people to accessibility, and get help fixing things.

Good luck!

A special thanks to Léonie Watson for taking the time to talk with me.