Use the arrow keys to navigate between menu items.

Reduce the cost of reworking feature because of accessibility

3 minutes read

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.

Did you enjoy this bite-sized message?

I send out short emails like this every day to help you gain a fresh perspective on accessibility and understand it without the jargon, so you can build more robust products that everyone can use, including people with disabilities.

You can unsubscribe in one click and I will never share your email address.