Use the arrow keys to navigate between menu items.

Accessibility isn't a technical problem

2 minutes read

This email is part of a larger series on believing six impossible things before breakfast.

Yesterday, we talked about how accessibility isn't a feature. Today, we'll tackle the next impossible thing on our list.

Accessibility isn't a technical problem

I've read the WCAG and it's a lot to take in. It's a lengthy piece of writing that's hard to follow and reads like a legal document. It makes accessibility look like it's a technical problem. It's on the developers to follow the guidelines, read the examples and implement those techniques into code.

This is why the teams I've worked with often wait until later in the software development process to think about accessibility.

The problem is, it's too late. Any issue you need to fix then will prove to be costly and time consuming. And then you run the risk of not fixing it and postponing it for a later sprint.

If we say that accessibility is only a technical issue, it suggests that it can only be solved with technical fixes. While many accessibility problems do need technical solutions, not all do.

But why solve problems that you created when you can avoid creating them altogether? We can prevent most issues when we consider accessibility earlier in the process.

Accessibility is deeply intertwined with your entire development process. Treating accessibility as solely the developers' responsibility is shortsighted and leads to costly fixes and delays. So why wait until issues arise when being proactive can prevent them altogether?

This means that besides developers, the other people in the team must feel a sense of responsibility. I'm talking about product owners, designers, marketing, testers and business stakeholders. If you're involved in the SDLC, accessibility is likely your responsibility too.

Accessibility then becomes a process problem.

When everyone gets involved, we make it a collective responsibility. We create a culture where accessibility is integrated from the outset, not tackled as a feature or a bug. We turn accessibility from a coding challenge to a process-driven approach that benefits everyone involved.

I know what you're thinking...oh my, that's going to slow down product development and increase costs.

Accessibility isn't time-consuming and expensive.

We'll talk about that tomorrow. See you then!

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.