Accessibility is everyone's responsibility.
Another maxim that sounds reasonable but does more harm than good. And while I do agree with it, I also want to know who's going to do what on what we're building right now.
Without that detail, people can care about accessibility all day long and still wait for someone else to act. Designers will assume the engineers will handle the interaction, while they will think QA will flag anything wrong anyway, so why bother. Meanwhile, QA usually finds these problem days before the release.
Nobody deliberately ignored it, but each thought another part of the team had it covered.
I don't think the answer is to give one person all the accessibility work. Naming someone won't solve a skills gap or create time during a sprint where everyone is overworked anyway. And we'd be back to the bottleneck problem before you know it.
I'd rather make the handovers clearer.
The best way I found to do that is to answer a few questions like who defines how the interaction should work, who checks that it does and, if something excludes people, who makes sure the fix gets planned.
Each team will have its own answers to these questions and that's okay. It's expected. What matters more is that people agree to these answers before the work starts.
If you're wondering how you can get started with defining these handover moments, try this blueprint:
- Pick one ticket from your sprint and follow it through delivery.
- Along the way, ask each person what they expect to handle and what they expect someone else to do.
- Write those answers down and see how well they hold up till the end.
The gap between what people thought and what happened is the best place to start.