Technology Will Not Solve Our Accessibility Issues

Tags: [[benrobertson.io/accessibility]] Drafts

As much as we might hate to admit it, technology alone is often unable to completely solve our problems. You might have the best tools on the planet, but if your team doesn't use them, it won't make a difference.

That's where culture comes in. In my opinion, code quality is 90% a culture challenge, and only 10% a technical challenge. In order for any of the tools I mentioned above to be useful, you've got to create a culture that's supportive of accessibility. I think there are three key considerations to make on the culture front to help teams deliver accessible websites.

People who value accessibility

In order for a team to deliver excellent accessible websites, you need people of all different roles who value accessibility. If you have a developer who values accessibility, but a designer who doesn't, it will be really difficult to deliver a truly accessible experience. The same is true if you have a project manager who values accessibility, but a developer who doesn't know how to build accessible websites. If the team isn't on the same page, you'll face significant obstacles to building an accessible website.

There are more than just the technical obstacles as well. On a team, we all have different responsibilities, and maybe even different definitions of success. There are numerous factors at play in any given project beyond individual ability: budget, deadlines, visual aesthetic, technical complexity and client relationships to name a few.

If accessibility isn't a value of the entire team, it will be all too easy for the team to ignore accessibility issues when a tough conversation about budget comes up. When accessibility is a value of everybody on the team however, it will be one of the many factors at play in the decision-making process throughout a project. This helps a team make balanced decisions on a project and increases the likelihood of an accessible website.

People who want to improve

You might not have a team full of people who already value accessibility, but you know what the next best thing is? A team of people who want to improve.

People who want to improve are open to feedback, constructive criticism, and new ideas. In my experience, the majority of developers who build inaccessible websites don't do so out of spite, but out of ignorance. I remember the first time a client asked a team I was on about accessibility and I had no idea what they were talking about. It became a great professional development opportunity for myself to explore a part of our discipline that I had never encountered before.

If you've got a team of people who like to get better at what they do, you're in a great spot. As you're working with them, find ways to gently introduce them to accessibility principles. Telling someone their work is terrible because it isn't accessible is not the way to go here. Explaining that their excellent work could be even more excellent if they added keyboard support for the complex interactive component they built is better.

Even better, have conversations before work begins on a component about what kind of accessibility considerations need to be made from the beginning. The more you do this, the less the conversations will be necessary as your team improves.

If you're hiring new team members or just assembling a project team for a new project, look for people who want to improve and are coachable. These are the ones that will be open to learning about accessibility, and eventually will be excited to help others improve their accessibility skills.

Code Reviews

The last cultural pillar for accessibility is developing a culture of code reviews. You might think of code review as a primarily technical concern, but while the content of code review is technical, the environment needed to sustain beneficial code review is primarily cultural.

You need a few things to make it happen.

One that I've already mentioned is people who want to improve. People who want to improve will value feedback, criticism, and encouragement from their fellow developers if it's given in good spirit.

Additionally, everybody on the team needs to know how to effectively give and receive feedback. As I mentioned earlier, people will not listen to you if you are constantly telling them that their work is bad. Every pull request is the result of hours of someone else's hard work, and the work and the person should be treated with respect. Being respectful during the code review process is crucial for the process to be valuable to everyone.

Another factor at play is time. Code reviews do take time, and you've got to have time in your process to account for review. If your team is constantly fighting fires and running from deadline to deadline, code reviews are going to end up being purely perfunctory or non-existent.

And lastly, from an accessibility perspective, you want people with accessibility experience reviewing code with accessibility in mind. If your team is less experienced, it may take time to develop this, but code reviews can uncover issues that weren't picked up by a linter and can be an excellent time to educate developers on best practices.

I will say that code review is one of the things I love about working at Mediacurrent. Having so many people with all different kinds of experience and perspectives reviewing my code, and me reviewing theirs helps me learn new things all the time. [//begin]: # "Autogenerated link references for markdown compatibility" [Accessibility]: accessibility "Accessibility" [Drafts]: drafts "Drafts" [//end]: # "Autogenerated link references"