Use the arrow keys to navigate between menu items.

The Product Owner's guide to accessibility debt: Creating your decision making process

3 minutes read

Last time, we talked about how to balance business priorities and accessibility and I introduced the The Tradeoff framework and how to communicate to the different stakeholders.

Let's not forget what spurred this entire series of emails. Accessibility debt and how to tackle it. A lot of times, that feels like playing whack-a-mole. You fix one issue, three more pop up and you feel like you'll never be done.

What if you had:

  • A clear system to decide what to fix first
  • Buy-in from everyone
  • Proof that you're moving the needle

And without bureaucracy or perfectionism. Just a lightweight process that you can start in your next 30-minute backlog review.

It all starts with involving your team.

Get the right people involved

Keep the team lean and effective. You only need three people every time you groom your backlog.

  • The product owner for final prioritisation
  • The lead dev for technical feasibility
  • The UX designer for the user impact perspective

Occasionally, you'll want to hear from your support team for the top user pain points and legal for any compliance red flags.

What to track and how

Good documentation shouldn't slow you down. It should speed up decisions. Here's my practical solution for what to track and how to do it.

For each accessibility issue, I write down:

  1. How severe it is:
  • WCAG Level (A/AA/AAA).
  • User impact. High impact blocks users from accomplishing their tasks. Medium impact issues frustrates them. And Low impact is just cosmetic.
  1. How feasible is it:
  • Think the effort required across design, development and testing. A lot of effort gives you a lower score.
  • Are there other blockers, like a third-party integration? Again, blockers give you a lower score.
  1. How it affects the business:
  • Which business goal does this support?
  • Is there any risk if you ignored the issue?

Rank each on a 1 - 5 score basis. For example, a keyboard trap on your checkout page might score:

  • Severity: 5 (blocks purchases)
  • Feasibility: 4 (known fix and one day of work with no blockers)
  • Business: 5 (direct revenue risk)

That's a score of 14 out of 15.

As for how to track the issues, the best advice I have is to use tools that don't suck your time.

Are you already using Google sheets or Excel? That's fine. Are you a JIRA shop already? Perfect.

The only rule is to document publicly just enough that:

  • anyone can pick up the thread
  • you avoid rehashing old debates
  • stakeholders see progress

Is this the perfect process?

Wrong question! This isn't about perfection. It's about progress you can sustain.

This is just my process. Yours might be different. And it should!

The best process is the one your team actually uses.

The most important is that you start small. Here's how:

  1. Pick one framework like the scoring system I had or one of the other ones from my list
  2. Run a 30-minute trial the next time you do a backlog review
  3. Cut what doesn't serve you. If it takes you more than five minutes per issue, the system you have is too complex or you're overthinking it.

And if you're curious how to properly communicate progress and KPIs to stakeholders, you'll want to read next Thursday's email.

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.