How to have more impact as a web accessibility advocate

Stop fixing inaccessible websites and start teaching others how to do it. Sustainable web accessibility happens with widespread accessibility knowledge. We need to scale up big time. Start thinking about product designers and developers and how you can teach them to fit accessibility into their daily work.

I started my career in web accessibility in 2001, spending years learning about it, designing and building for it, championing it and then teaching it. I recently got certified through IAAP as a Web Accessibility Specialist. This article outlines what I’ve learned about impact and scaling web accessibility over the last 20 years.

The biggest impact I’ve made in my career wasn’t the accessible websites I started out designing and building, the teams I later led to create accessible sites, but rather the people that I inspired to consider accessibility a priority. I can honestly say there are hundreds of people out there who know about and think about accessibility because of me. That’s impact.

Me on my way to the Guelph Accessibility Conference to teach people how to use Ontario’s Inclusive Design Toolkit.

If you spend your days writing accessible code, designing accessible sites, auditing for accessibility, that’s great. But, what has more impact is teaching other people how to write accessible code, design accessible sites, and test for accessibility. That’s how you build an army of people that work on web accessibility.

The goal shouldn’t be to teach everyone everything about accessibility. That level of knowledge is hard to attain for anyone except a full-time specialist. The goal should be to teach people what they need to know in order to include accessibility in their own work and implement processes and tools that they can use while doing their job.

We don’t need everyone in an organization to know all the Web Content Accessibility Guidelines (WCAG) and success criteria. In fact, we don’t need most people to know anything about WCAG at all. What we do need are:

• Researchers who include people with disabilities in their research
• Designers who choose easy to read fonts, use color contrast checking tools and create links and buttons with visible focus states
• Front-end developers who understand tab order, landmark regions and use logically nested heading levels
• Application developers who can use ARIA correctly and validate it with a browser extension and screen reader
• Mobile developers who add accessibility attributes to UI elements
• QA testers who use accessibility testing tools and do keyboard testing

Any one person on a team needs to know only enough about accessibility as it applies to the job that they do so that their own work can be made accessible. Accessibility is a team sport and when everyone plays their part, the team wins at accessibility.

It’s also really important that accessibility is part of day-to-day work. If an accessibility specialist is reviewing other people’s work for accessibility after it’s done, it’s already too late. At that point any issues you find will result in more time and money to fix and it’s likely you’ll get pushback.

Everyone with deep accessibility knowledge needs to start teaching and enabling others if we want to make a difference.

Wouldn’t it be awesome if you could clone yourself to make more accessibility specialists? Good news — you can, through teaching. These are product designers and QA testers that I coached at Canada Post.

In order to do this well, you’ll have to let go of perfection and have a bias for action. If you set a bar of full WCAG compliance for everything, right from the start, you’re going to fail. It’s a lot easier to convince someone to do something if you make it easy for them to do.

Imagine this scenario. One of your product teams has a new feature release and they’ve asked for an accessibility review. You take a look at it and document all the WCAG failures and what they need to do to fix them. You hand them a document listing the failures and recommended fixes. Launch date is two weeks from now. Do you think it is going to get fixed, tested and approved in time for launch?

Here’s an alternate scenario. You know a product team is working on a new feature release. You book time with the product designer to review their mockups for contrast. You show them the free tool you use to check contrast and review the mockup for contrast together. The designer takes their own notes and has the tool if they need to check again to confirm.

Similarly, you meet with the front-end developer to review an early working version of the feature. You show them how to use a screen reader to listen to the interactive component that they’ve built and demonstrate how no feedback is announced. You pair program together to implement the appropriate ARIA roles and live regions.

Photo by Lagos Techie on Unsplash

In this scenario, you’ve taught two people about accessibility and tackled two specific problems. There are a whole bunch of accessibility problems you didn’t tackle, but you’ve got two folks who shouldn’t create the same problems again because they understand how to test and fix those specific issues. Next time you tackle different issues. Eventually you build a team of people who are aware of accessibility issues and have knowledge that they can share with others.

Accessibility is a journey and you have to be willing to accept the fact that people will not be great at it initially. They will need to practice in order to get better. Don’t discourage their efforts by pointing out all the individual failures, instead support and encourage them. Focus on a handful of improvements to start and expand the scope over time. Think about the learner’s perspective and how best to teach a new skill, not just the end goal of accessibility.

I know it seems counterintuitive, but sometimes the best way to achieve something is to focus on the journey and not the destination. Focus on moving forward, with small steps in the right direction and you’ll get to where you want to go.