Running audits

2 minutes read

Can you ship accessible products when you rely on a 50-page audit?

Serious question. Asking for a "friend."

That same "friend" had this story to share. Totally didn't happen, by the way. Here it is. Remember, it didn't happen.

A few years after launching the product, the team got some questions from customers like "but is it accessible?" They didn't have an answer and before they just said hell-to-the-yeah, it was suggested that they do an audit. Brilliant.

They ran the audit. It took about two weeks.

That resulted in a 46-page PDF with 150-something issues. Everything was colour-coded for severity, ranked, prioritised. All ready to go.

And go it went. Straight into the backlog. Someone created a Confluence page and a Jira epic. There was some presentation of sorts that fired everyone up about the accessible future on the horizon.

Four months later, the next release came round the corner. Someone asked about accessibility again. No answer, so it was suggested, again, they do an audit.

It was a surprise, surprisingly, that the PDF got larger and the issue count increased. Shock!

No matter. They're sure to fix it next release. Close the old epic and create a new one.

Here's the thing.

You can't ship accessible products by running more audits.

Every sprint, you're shipping new features, new components, new user flows, new everything. Yet all you do every time is layer new problems on top of old ones and run audits to "check" how you're doing for accessibility.

Are you really fixing accessibility? Or are you just documenting how broken everything is?

At least it won't stay broken for long. Only until next release.

Sent on

Did you enjoy this bite-sized message?

I send out short emails like this every day to help you gain a fresh perspective on accessibility and understand it without the jargon, so you can build more robust products that everyone can use, including people with disabilities.

You can unsubscribe in one click and I will never share your email address.