Take a look at your calendar. Do you have any meetings with "accessibility" in the title? What about the most recent sprint planning sessions? Did someone bring up accessibility? What about onboarding new people on your team? Is there a person responsible for introducing new hires to accessibility processes in your organisation?
If you're mostly shaking your head, you might have an accessibility problem.
There is no sustained effort devoted to advancing accessibility awareness and adoption within your organisation. This may be because there's no dedicated accessibility expert or champion ready to take up the mantle.
The role of an accessibility advocate isn't being the "accessibility person." An advocate is that persistent voice that keeps accessibility in focus when competing priorities threaten to push it aside. They ask the uncomfortable questions in design reviews. They reject PRs because there's been no consideration for accessibility. They remind everyone they need to test their work with various devices. They push for user testing with people with disabilities.
They are passionate and want to make sure accessibility is not an afterthought tacked on at the end of projects.
It may feel like it's a solo mission. In the beginning it sure is. But it cannot be that for the long term.
Through sustained effort, accessibility advocates need to build networks of allies across teams. They find the designers who care deeply about inclusive design. They need to work with the developers who get excited about semantic HTML. They build up the product owners to understand the business value of accessibility.
They are persistent and patient. They connect the dots.
Like cultural safety, accessibility advocacy as a metric is also hard to quantify. You could look at things like:
- Meeting agendas and project kickoffs include accessibility considerations
- Team members proactively share accessibility resources or articles
- Developers and designers include accessibility in their initial solutions rather than waiting for review feedback
- Sprint planning sessions incorporate accessibility tasks not as special items
- Other teams reach out for accessibility guidance before making decisions
- Job postings across different roles include accessibility knowledge as a desired skill or responsibility
You can't measure the success by how many people you convert overnight. You need to look at the small wins.
Notice the developer who starts asking about keyboard navigation unprompted. Celebrate the designer who includes alt text in their mock-ups without being reminded. Praise the product owner who builds accessibility testing into the sprint schedule.
The goal is to make accessibility everyone's responsibility. To do that, you can start tracking:
- Engagement metrics. Look at the number of accessibility-focused meetings, workshops and training sessions, as well as who initiates these conversations.
- Knowledge spread. Document how accessibility knowledge spreads through the organisation.
- Process integration. Does accessibility show up in documentation, design systems and development workflows?
- Resource allocation. Monitor budget allocation for accessibility tools, training and testing. Look at the time allocated to accessibility work during sprint planning.
You won't get it right overnight. It will be uncomfortable at first. All important problems are.