Use the arrow keys to navigate between menu items.

The Product Owner's guide to accessibility debt: Balancing business priorities and accessibility

4 minutes read

Last time, we talked about the technical considerations we need to take into account to help you make strategic decisions and fix issues that block critical tasks.

You might not want to hear it, but "fewer bugs" is not a business priority. So fixing them is not what you want to lead with when you're pitching accessibility to business stakeholders.

What is then?

You're probably struggling to juggle quite a few things already. New features, tight deadlines, team demands. Who has time to pitch accessibility to stakeholders on top of all that? The end result is that accessibility work gets pushed to "later."

But what if you could align accessibility fixes with business goals in a way that satisfies both?

Waking this tight rope without sacrificing what matters most is what this email is about.

The first step is to stop treating accessibility as a separate concern and reframe it as a business enabler. You can do this by talking in terms that the business understands.

You're not fixing accessibility bugs. You are:

  • Increasing revenue. 1 in 5 potential customers may face barriers on the website. Fixing checkout flow for example can directly recover lost sales.
  • Mitigating risk. If you're working in a regulated industry like finance or healthcare, accessibility failures mean legal exposure.
  • Increasing efficiency. The cost to fix accessibility issues grows exponentially after you launch.

Here are four examples of metrics that make business ears prick up:

  • If we fix these 3 form errors, we will improve conversions by 5%.
  • If we improve keyboard navigation, we'll reduce support tickets by 20%.
  • If we add proper alt text to product images, we'll improve our Google Image traffic by 25%.
  • If we take care of these component issues now, we avoid 40 hours of rework when we update the product next release.

To drive the point home, I use an anchoring. For example, I say something along the lines of "fixing all checkout accessibility issues now costs less than your monthly office coffee budget."

Yes, you will need to do some research for this. Some stats are easier to find than others. Whatever you do, don't lie on your stats!

The Tradeoff framework

Sometimes, you might think business and accessibility goals seem at odds. When that happens, use the Tradeoff framework.

  1. Map business objectives to accessibility outcomes. For example, in order to increase sign-ups, we need to fix email input errors for screen readers.
  2. Negotiate with Yes, ifs. Stakeholders will often ask to delay some accessibility work. Instead of shouting an outright "no," create some contingencies. For example, "Yes, we can delay fixing the email input errors for screen readers, if we document it in our public roadmap." Use the "if" to create accountability that you're not forgetting about it, but are really just delaying it.
  3. Use the impact/urgency matrix. Similar to the Impact vs Effort Matrix, create a Business impact vs Accessibility urgency matrix. For example, if increasing sign-ups has a high business impact and fixing the screen reader errors is a blocker, this issue jumps to the top.

Communication is key

The worst thing you can do is call for a meeting with business stakeholders and start throwing accessibility jargon and lawsuit threats around. They won't understand what you're talking about and you'll just alienate them further.

Not if you speak their language. You need to tailor your pitch to your audience.

These 5 form accessibility fixes address 80% of our legal risk while protecting €X in potential revenue.

Works great for executives, but falls flat on its face with developers. Here's the same thing reworded:

Making sure the form fields are labeled properly now will prevent 3 hours of debugging and rework later.

Now you're talking dev-speak.

The best thing you can do is to pick one business goal (for example, increase user conversion rate), link accessibility issues to it (for example, sign-up form bugs) and present it as such to both the business and your development team.

There's no one-size fits all solution.

How can you build a clear, collaborative process for prioritising and addressing accessibility debt?

We'll talk about that next Thursday.

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.