Use the arrow keys to navigate between menu items.

Real talk: Does accessibility slow down development

2 minutes read

Yes.

Just as much as considering performance or security does.

Or you know how you want your homepage to look good? And your customers' payments to go through? All these must-haves before you can call your product viable.

Yeah, like that.

Sure you'd be able to move faster if you didn't really need all that security around user authentication, if you could ditch your user permissions for authorisation, or if you could live with a few seconds more of waiting around a blank page every time you click a link.

Not doing the work is faster.

But you can't not do the work. You need all that so you build them in from the start, don't you?

Why?

I think it's because you know you need to build a solid foundation. It's because you know that foundation is much harder to change later on. It's not impossible, but it will take more time. Time you don't have. And that will surely slow down development.

So you could cut corners, ignore best practices and end up with a product that’s fundamentally broken for a significant portion of your users.

But you already know what I'm going to say, don't you?

Retrofitting accessibility into your product after you've built it is going to be a drag.

Not so much if you prioritise it early and integrate it into your development process.

I'm not saying you need to choose between performance, security and accessibility.

You kinda need to do it all. And how you prioritise is where the risk is. And also where all the profit comes from.

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.