The Product Owner's guide to accessibility debt: Just-in-time training

I've had plenty of attempts to provide teams with accessibility training. I've mostly missed the mark.

The problem was that I've structured it like a college course, with plenty of theory and plenty of practice. But none of that practice was focused on their actual code base. These people don't need to memorise the WCAG. They need to recognise and fix the issues in front of them right now.

Here’s how I started to make that happen without adding meetings to overloaded calendars.

Long workshops check compliance boxes and rarely change behavior. A developer will sit through an hour of ARIA examples, then return to their code and still misuse landmarks because the training wasn't tied to their actual work. And designers learn about contrast ratios in theory and skip checking them in Figma because "the specs don't make it clear how."

So I started encouraging everyone to weave it into the work they're already doing.

I call that "just-in-time" training.

Let me give you an example.

I recently dealt with an inaccessible modal dialog. The focus wasn't trapped inside it and the user could just tab along the rest of the page with the modal open. But the modal was obscuring the page content. Instead of pointing them to articles about focus traps, I sat down with the developer and explained how and why it's important, how to test for it and how to implement it right in their code.

Yes, it took more time from my day. But the developer will remember better because they're learning in a context they care about.

Over time, I'll get a clear picture of the most common accessibility issues in the team. And I can come up with some cheat sheets that solve real problems.

For example:

• If a form field fails validation, use aria-describedby to link the error message.
• Icons without labels? Add aria-hidden="true" if decorative or an aria-labelledby if actionable.

But let's get back to the most common pushback I get: No time!

It's real. And the answer isn't more hours. I can't fabricate time. The answer is smarter minutes.

What takes hours to fix after you release can take just minutes to fix right now.

A single skipped form control label might take a few minutes to add during development, but well over a few hours to debug after QA catches it and you can deploy the fix.

If you commit to one tiny improvement per sprint, you'll get ahead faster.

Just-in-time accessibility training is about fixing real issues in real time.

Traditional workshops overwhelm teams with abstract standards they'll never retain, while accessibility debt keeps growing. Instead, just-in-time training embeds practical skills where they matter. During code reviews. During design handoffs. During sprint planning.

This approach stops debt before it balloons. When you can spot and solve common issues like missing labels or broken focus traps on the spot, you prevent the compounding costs of post-launch fixes.