How many of your user stories or tickets have accessibility as part of their acceptance criteria? Have a look, I'll wait.
What? All? Sweet! You can stop reading then.
If you're still with me, then you're like most of us. Not that many, if any, have any sort of mention of accessibility as part of acceptance.
When you make accessibility part of acceptance criteria, you're starting to prioritise and consider accessibility at the feature level, not just as an afterthought or separate initiative. You're making accessibility a shared responsibility across the team and preventing accessibility debt from piling up. Without debt piling up, there's no need for costly rework that will block feature development.
I found that having accessibility acceptance criteria on every ticket also helps the developer handling the ticket understand specific requirements for what they're building. And it helps testers verify compliance when they're checking the work.
How do you track this metric
Easy. For each sprint, take a look at the user stories and count how many have accessibility well defined as part of the acceptance criteria. Aim for 100% coverage. Some tickets won't make sense to have accessibility attached to them. That's okay. Disregard them from your count.
The one pitfall I found is vague acceptance criteria, like "The form should be accessible."
Good accessibility criteria should be specific, measurable and aligned with WCAG. Here's an example from a ticket I recently worked on:
The user story read: As a user, I want to fill in a form with my username and password to log in.
The acceptance criteria included a section specific for accessibility:
- The form fields are visibly labeled and each label is programmatically associated with its input
- The login form is usable with only a keyboard
- The error messages are clear and descriptive
- A screen reader can read aloud both the form fields and the error messages
- The login button has a colour contrast of 4.5:1.
This makes it easy for both the developer and the tester to complete their work without having to think too much about what accessibility rules they should apply.