There’s no question that building a product with accessibility from the beginning is best. It’s cheaper, and you get a better result. Plus it’s more fun.
Trying to make an app accessible later is hard. I’ve been faced with a backlog of a thousand1 accessibility bugs. How do you even make progress on that?2
In an ideal world, you build with accessibility from the beginning. No retrofit needed.
But we don’t live in an ideal world. The real world is messy. Also, people don’t usually call us in because things are going great. If you work in accessibility, sometimes retrofit will be necessary.
Look, I don’t have a grand strategy or wise words for dealing with this. Just that it’s worth thinking about how to help teams where they are, instead of where you wish they were.
Here’s a couple ideas, though:
Make sure new development is accessible, so you stop making new issues. AKA, stop the bleeding.
Educate the team and provide resources. I like checklists.
Focus on a subset of accessibility problems3, so there’s less things to think about until the team is more comfortable with the work.
What have you tried?
Or something like that. I forget the exact number, but it was way more than the team could be expected to resolve.
Obviously prioritize the tickets, and work on them in priority order. The only problem with this is they tend to be burrowed deep and a pain to deal with. Plus the issues go out of date quickly. And you’re liable to produce new accessibility bugs.
This is hard because it means being somewhat inaccessible for a while. Not great. But it might be effective.