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.
- Dos and don'ts on designing for accessibility
- Understanding WCAG 2.1
- Web Content Accessibility Guidelines (WCAG) 2.1
- Content design: planning, writing and managing content
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.
- How do automated accessibility checkers compare?
- Improving accessibility with accessibility acceptance criteria
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.
Make it visible - I linked to the excellent home office accessibility posters earlier, the more you can do in your team space to make the problem visible the better. Start putting accessibility design challenges on the wall, calling out accessibility issues (be it bugs or usability) as bugs, tech debt, or features all the starts to put it at the front of people's mind.
Tell the story - taking the team out on user research with people with access needs is a good way to raise awareness, get buy-in and highlight issues.
Run a workshop - workshops are another great way to build empathy, either using assistive technology (like a screen reader) to navigate your service or you could get a set of vine sim specs to help simulate issues
Make it part of the process - as developers, we already have parts of our process like unit testing, there is no reason we can't include accessible acceptance criteria.Get audits - reaching out to other teams in your company or even outside to review your service is another way to get great feedback
Make it open - sharing the issues you are having and how you've fixed them is another great way to make it more visible as a team and company and to help other people learn - Bulb did a great open accessibility audit.
Top comments (0)