Use the arrow keys to navigate between menu items.

The Product Owner's guide to accessibility debt: Building team accountability

2 minutes read

Let me tell you a quick story.

Some years ago, I was working on a new product feature. I had been working with this client for a while now and I assumed I had drilled into them the importance of accessibility. I thought the team had a good grip on things already so I didn't pay much attention to the wireframes. The designer assumed the devs would know how to handle focus order. The devs trusted QA to flag any issues. And QA relied on the product owner to prioritise the fixes.

Weeks passed and the feature was released in a rush. Then, an accessibility audit revealed dozens of WCAG failures. Broken forms, missing alt text, trapped focus. We scrambled, working nights to retrofit those fixes.

Accessibility isn't one person's job. When no one owns it, debt piles up until it becomes a crisis.

Building team accountability is crucial when addressing web accessibility debt because accessibility is a shared responsibility that requires consistent effort across the entire team.

Accountability prevents the mentality of "it's someone else's problem." When everyone is accountable, accessibility becomes part of each team member's role. It doesn't matter if your job title says designer, developer, tester or product owner. Team accountability means accessibility is considered in every decision.

The biggest problem when there's a lack of accountability is that the debt piles up and you'll scramble to implement last minute fixes. Rush jobs are costly and are bound to lead to more bugs than before. When you've done your job and you hold everyone responsible for it, you'll catch issues earlier and reduce the amount of rework.

The goal however is to create better user experiences for everyone. That can only happen when you prioritise accessibility as a core value. Not a compliance checkbox.

So how do you build accountability for accessibility debt?

  • Assign clear roles by answering some critical questions. For example, who's responsible for reviewing code pull requests for accessibility violations?
  • Set measurable goals. For example, fix five critical WCAG violations per sprint.
  • Include accessibility in Definition of Done. Never consider the feature complete without accessibility checks.
  • Regular audits to track your progress, share findings and celebrate successes.

I think each of these are important to dig into.

I'll start with assigning clear roles and how to do that easily 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.