Nobody owns accessibility.
Everybody cares about it, sure. But everybody also assumes it's someone else's responsibility more.
Product assumes design has it covered. Design assumes engineering will implement the details. Engineering assumes QA will catch anything important. QA discovers problems shortly before release. And things blow up because nobody owns the decision.
That's how accessibility becomes late rework.
But these problems rarely start in QA.
A keyboard trap is not created when QA reports it.
It starts a lot earlier than that. By the time someone finds the problem, fixing it usually means changing the design, rewriting the component or delaying the release.
And then it's already a delivery problem.
The answer is rarely another review meeting, spreadsheet or policy document. Those things can help, but I've never seen them fix unclear ownership. They often make accessibility feel like work that happens somewhere else, handled by someone with specialist knowledge.
What does work is putting a few accessibility decisions inside the work you already do.
Product managers can ask which users could struggle with this journey. Designers can include keyboard focus, error messages and usable interaction states before handoff. Engineers can use accessible components instead of rebuilding common patterns from scratch. QA can test the highest-risk user journeys before release, rather than discovering every problem at the end.
In this scenario, nobody needs to become an accessibility specialist. Each role needs to make better decisions at the moment those decisions belong to them.
But everyone owns accessibility, you say! Sure, that sounds collaborative, but in practice, it often means nobody is accountable.
Instead, for each feature, make ownership explicit:
- Product owns the user need and risk trade-offs.
- Design owns interaction decisions.
- Engineering owns implementation quality.
- QA owns agreed checks and release evidence.
And the team owns the result together.
This doesn't mean one person becomes responsible for every accessibility issue. It does mean however that issues have a clear place to be raised, discussed and resolved.
Couple that with a shared definition of quality and you have a winner.
Here's the thing.
You cannot fix every possible issue at once. Pretending otherwise creates confusion, not quality.
You could start with one recurring failure instead of launching a company-wide accessibility initiative.
Take a look at your last few releases and find one accessibility issue that caused avoidable rework. Maybe users couldn't complete checkout with a keyboard. Maybe error messages were invisible to screen reader users. Maybe a custom control behaved differently across teams.
Trace that backwards.
Where should the team have caught it? Which decision was missing? Which role should have owned that decision? What small change would make the next team more likely to get it right?
Then add that change to an existing product ritual. That's your design review, refinement session, component checklist or definition of done.
Guess what? You're now making accessibility part of your operating system through better decisions, made earlier, by the people already building the product.