Accessibility testing: What gets left behind

2 minutes read

Last time I said that you need to make deliberate choices as to what you leave behind. I imagine that stirred some things in most of you.

How can he advise us to decide to leave something behind!?

Easy. I know you can't test everything. And I know that the deliberate triage is what will separates teams that ship accessible products from teams that burn out chasing perfect coverage without ever achieving it.

So what do you leave behind?

I bet you have a lot of edge cases in your product that almost nobody uses. Or you have a settings page that gets accessed maybe once a year. And I've yet to see a product without at least one legacy feature planned for retirement.

These aren't critical paths. If a screen reader user hits friction there, it's not ideal, but it's not blocking them from using your core product.

Here's what this looks like in practice.

For an e-commerce site, you might forego accessibility testing on archived blog posts from 2018. You might skip testing on admin-only features that three people you know use in your SaaS app.

These are conscious trade-offs. You're always weighing impact against effort. And you write tests scenarios accordingly.

Good testing cultures are comfortable admiting what doesn't need rigorous accessibility testing right now. They're not paralysed by perfectionism. They ship accessible products because they know what accessible means for their users.

That's the deliberate triage that helps you ship accessible products. It lets you be strategic instead of exhausted.

Don't think of it as ignoring accessibility or as a compromise.

Think of it as strategy.

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.