Last week, I wrote about how to track the number of new accessibility issues your latest release introduced and why this metric is important for your team.
Today, I want to have a look at another one of my favourite leading indicators.
The cost of reworking a feature because an accessibility issue has been identified
Products aren't these static things that once you launch them, they're done. You're constantly working to improve them. You do this in one of three ways. You can remove features. You can fix and add to existing features. And you can add new features entirely.
This involves your team sitting down and coming up with a plan to get them from your minds to the customers' hands. It will mean you have some sort of process, usually with some degree of design, development and testing involved.
Once you've released the feature, the last thing you want is some critical thing you overlooked force you to go back to the drawing board.
Unfortunately, this is exactly what happens when you're forced to address accessibility issues once features have been deployed. Reworking these inaccessible features is often significantly more expensive and time-consuming than building accessibility in from the start.
So reducing this cost will have a significant impact on your bottom line.
This metric highlights the importance of considering accessibility early in the development process. When you track and aim to reduce rework costs, your team is incentivised to adopt more proactive and accessibility-focused development practices. When they adopt a proactive process, fewer accessibility issues show up after you release features.
So how do you track this?
You could measure the cost of reworking features in various ways. I like to look at man-hours spent post-release to fix the issues, the additional people required and the time delay until the issue is resolved. You could go one step further and look at the cost to delaying other features as well, since the people fixing a current release are essentially blocked from working on the new release.
With this in mind, start keeping track of:
- the time spent identifying and fixing accessibility issues post-deployment
- the number of team members involved in the rework
- what roles are involved in the rework (e.g., designer, developer)
- the total delays in feature releases or updates due to accessibility fixes
Compare these costs across different features and releases to identify trends and areas for improvement.
When you start reducing the cost of accessibility rework, you'll start to notice more efficient development cycles. As you start to consider accessibility from the beginning, your features are more likely to work well for all users from the initial release.
Strategies to reduce the cost
- Integrate accessibility testing early through accessibility checks at every stage of development.
- Educate the team through accessibility training for designers, developers and QA testers.
- Have accessibility-focused code reviews to catch issues before they make it to production.
- Establish clear accessibility guidelines and ensure all team members are working towards the same goals.
- Integrate automated accessibility checks into your continuous integration and deployment processes.
I've noticed that teams improve collaboration between designers and developers as a result of reducing this rework cost. So these improvements benefit not just accessibility, but also the overall quality and efficiency of your development process.