Postponing accessibility is probably a bad idea

2 minutes read

Here's an example of a bad idea some might consider a good idea. But it's still a bad idea.

Customers want feature X. You scope feature X. Your team estimates the time needed to ship feature X. You prioritise and allocate time for feature X.

Then you consider accessibility and decide it will block ongoing work and delay shipping. You ask the team if there's another way. Nobody has a better idea. So you all agree it's a good idea to postpone that work.

Sound familiar?

I'm sure there are variations of this workflow, but they all start with a need and not enough time to do it right.

It's easy to stand up and say you don't have time for accessibility right now. But the truth is you could definitely find the time. If only you had the motivation.

Finding the motivation is your problem.

How do you find the motivation?

Start by reframing what accessibility is. You'll quickly realise it's not a nice-to-have feature. It's a fundamental part of building software that works for more people. Every time you postpone accessibility, you're making a deliberate choice about who gets to use your product. You're drawing a line and saying some people matter less than your deadline.

That's not a time problem anymore.

How could you have included accessibility in feature X without blocking shipping?

The answer is dead simple. Just not easy to accept. Build it in from the start. That sounds like more work, but bear with me.

When you scoped feature X, you could have included accessibility requirements in that scope. When your designer created those mockups, they could have designed with keyboard navigation and screen readers in mind. When your developer built the feature, they could have used semantic HTML, saving them tons of work.

All this doesn't slow you down. It actually speeds you up because you don't have to redo that work later.

Feature X isn't done until it's accessible. Not "done except for accessibility" or "done pending accessibility review." Just done. This way you don't need a separate accessibility sprint.

Doing it right the first time is always faster than doing it twice.

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.