Last week, I wrote about reducing the number of customer accessibility complaints and how that will lead to broader improvements in your development process and stronger connections with your user base.
Today, I want to explore another metric that's closely connected to that.
How long an accessibility issue has been in the backlog
Tracking and reducing the time accessibility issues spend in the backlog is an all time favourite of mine. I consider it a crucial metric for maintaining an inclusive digital product. To my mind, the sooner an accessibility issue is moved from the backlog to the current sprint and is marked as done, the better. A quick turnaround ensures that accessibility isn't treated as an afterthought, but as an integral part of the development process.
On the other hand, the longer accessibility issues sit in the backlog, the longer customers who rely on those features are stuck. It also opens you up to legal risk and losing face with your customers.
In developer speak, it's also technical debt.
All these unsolved accessibility issues will make future development that much more challenging. Issues tend to get more complex over time, the longer you ignore them. So fixing them sooner rather than later will be faster and require less of an effort.
How can you track this
Most issue trackers will do this for you out of the box. Once an issue is identified and added to your backlog, it's time stamped. When you mark it as done, that also gets a timestamp. So all you need to do is tally up all the issues labelled with "accessibility" and get the average resolution time. (You are labeling your issues, right? Right?!)
Most people like to measure the average time it takes to resolve accessibility issues once work begins. But it's this "once work begins" that troubles me. Because technical debt is made up of stuff you ignore, not stuff you started to work on.
As always, the goal is to track this number and see it go down over time.
If you want to dig a bit deeper, you can also track two more metrics:
- Backlog growth rate - how quickly you add new accessibility issues compared to resolution rates.
- Sprint inclusion rate - how often you include accessibility issues in sprint planning.
How you can help your team solve issues sooner
- Balanced prioritisation. Make sure you treat accessibility issues the same as any other issue in your backlog.
- Definition of Done. Include accessibility criteria in the "Definition of Done" for all features, so you can prevent new issues from piling up.
- Regular backlog grooming. You can conduct frequent accessibility-focused backlog review sessions and keep issues from stagnating.
- Time-boxing. This is a favourite tactic of mine. Set maximum time limits for how long accessibility issues can remain in the backlog before mandatory action.
- User impact stories. If you have them, attach real user impact stories to accessibility issues to emphasize their importance to the team.
- Accessibility sprints. If you want to pay down some technical debt faster, you can dedicate an entire sprint to just fixing accessibility issues.
This metric encourages a more proactive approach to accessibility, where issues are seen as integral to product quality rather than optional enhancements.
When you work on reducing your accessibility backlog, you get better at prioritising work, estimating effort and balancing different types of tasks. This skill often translates to better handling of all types of backlog items, not just accessibility-related issues.
This ongoing engagement with accessibility issues often leads to improved design and development practices that naturally incorporate accessibility, reducing the number of issues that make it to the backlog in the first place.