Two ways to approach accessibility.
Either you wait until someone else discovers the issues on your production site. Or you integrate accessibility into your software development lifecycle (SDLC), from the early stages.
We call the first being reactive and the second proactive (you might have heard the term "shifting left").
Most of the times, organisations start by being reactive. They usually respond to an outside trigger. Either a client demands an Accessibility Conformance Report (ACR), or, in the extreme case, they face a demand letter from a law firm. Or, as will be the case in Europe next year, new legislation goes into effect demanding digital accessibility.
By definition, in all these cases, you are reactive. And you'll have been told that's a bad thing.
But it's not the end of the world.
Our default stance is being reactive. When you receive a customer complain, you are by definition reactive. We don't all have to be proactive all the time.
In fact, being reactive is inevitable.
You just have to think of the times when you:
- didn't know about some ARIA pattern, a new browser feature or some assistive technology someone used
- discovered accessibility issues during user testing or feedback sessions
- realised a third-party component wasn't accessible until after implementation
- addressed accessibility because the standards and guidelines were updated
All these things are beyond your control. And your job is to react to them.
Unless you become passive, you're doing fine.