Back to articles

On a team who is responsible for accessibility?

There is always a slightly weird moment on most teams I’ve worked on where a conversation happens about who is responsible for accessibility.

The truth is no one person is responsible for accessibility, we as a team are responsible. It should be a principle of the services we deliver that they are by default accessible. This will become part of UK law later in the year for Government services.

For me as a front-end developer, I can build something that is semantically accessible, this doesn’t make it useable.

Everyone on the team needs to advocate for accessibility, we need to understand what our roles are responsible for, and how they fit together to create accessible services.

It is worth having this conversation as a team, so you can get a better understanding of it.

User Researchers

We should be doing research with a wide range of people who use our service. I’m never overly keen on persona but it is a great way to raise awareness on a team of the different types of challenges a user will face.

Another important thing is making sure we regularly test with people who will use our service, who use assistive technology. This sometimes can be quite difficult to find, so we can do usability testing with people who use the tools.

This will give us some context that our service is usable, but might not help us understand if the person’s user need is met by the service.

Content and Interaction Designers

There are lots of things a designer (both content and interaction) needs to take into account when designing a service, such as making sure we have thought about focus state, colour contrasts and clear language. As designers we need to understand WCAG 2.1 and the core parts of it, so we can influence how we design.

Developers and Testers

For me, as a developer, it is a given that I use the right mark-up for a website, regardless of the technology used.

We also need to build testing tools into our process, I know they won’t catch all the things (see link below), but building them into pipelines is a way to catch big problems early.

We can also sanity check things like is it keyboard accessible? and we can build these into our definition of done.

We can also sanity check our services with tools, we need to appreciate that we will not use the tools in the same way as an actual user.

Product Owners

Like everyone product owners need to understand the types of users that might be affected by issues. They also need to make sure the team has the time and space to do the testing and deal with the outcome.

They need to be an advocate of the work that is going on and make sure stakeholders understand what work is going on, and why it is important. Building a digital product doesn’t make the other support channels accessible, but we can use this to highlight issues.

What if this isn’t happening?

Most of the time, I’ve found starting to have the conversation about what accessibility needs we have for our users is enough to kick start better conversations around it, if it still doesn’t happen, here are some things you can try to get it going.

A lot of these activities will hopefully help to get people to understand more about accessibility and start to build empathy with people who have disabilities that we need to think about when designing and building services.

orginally published on dev.to