Introduction
Let’s be honest. You ran another accessibility audit. You delivered the report. You flagged the issues. You even tagged the right teams in Jira.
And… not much changed.
Sure, a few fixes were made — eventually. But when the next audit rolled around, the same patterns emerged. Different features, same mistakes. The accessibility debt didn’t shrink. In fact, it might’ve grown.
Sound familiar?
If so, you’re not alone. The issue isn’t with your effort or intentions. The problem is more fundamental. It’s about the limits of inspection — and the need to reframe how we build for accessibility from the ground up.
The myth of audit-driven transformation
Audits are often treated as the holy grail of accessibility work. They give us a detailed snapshot of the issues and feel like a major milestone.
But let’s pause and ask: what are audits, really?
Audits are a form of inspection. And inspection comes from industrial-era thinking — you build the same product repeatedly, and then you check to make sure it conforms to a defined standard.
That works well if you’re running a bottling plant or assembling toasters.
But modern digital products aren’t widgets.
Software is not an assembly Line
Every new piece of software — every feature, screen, interaction — is different. Designed by different people, written under different constraints, and built using ever-evolving frameworks and patterns.
That means accessibility isn’t something you can retroactively bolt on. You can’t audit your way into excellence. You have to build it in from day one.
Or, as the legendary quality expert W. Edwards Deming put it:
“Quality cannot be inspected into a product. It must be built into it.”
Why remediation isn’t enough
Here’s where the disconnect happens.
You thought the audit would help your team learn. You expected that once a developer saw how they missed a label, they’d never forget to add one again.
But the reality? That same developer may be on a different project now — or replaced by someone brand new. Meanwhile, the next team repeats the same accessibility sins because the process hasn’t changed.
Audits might clean up yesterday’s mess, but they don’t future-proof tomorrow’s code.
What audits are actually good for
Let’s not throw audits out with the bathwater. They’re still useful — just not in the way we might hope. Audits can:
- Gauge maturity: They reveal how your teams respond to accessibility after release.
- Spot systemic gaps: Are issues recurring in a specific component, framework, or handoff?
- Identify process breakdowns: A once-accessible feature might degrade over time due to poor ownership or team churn.
- Offer perspective: When done periodically, they help track trends — not just individual bugs.
But audits aren’t a learning tool. They don’t teach inclusive design. They don’t instil empathy. And they won’t magically make accessibility a team habit.
So what’s the alternative?
If we want lasting impact, we need to stop relying solely on inspection and start embedding inclusion into delivery. That means:
- Accessibility acceptance criteria on every story
- Design reviews that include inclusive patterns
- Test cases that reflect real user diversity
- Continuous training, not just one-off workshops
- Involving people with disabilities in user testing
And yes, that takes more planning. But it saves ten times the time and effort later.
The audit trap: why we keep going back
Let’s be real: audits feel safe. Familiar. Tangible.
They give us spreadsheets, reports, dashboards. We can show stakeholders a list of “closed bugs.” It looks like progress. But it’s a treadmill — and we keep running in place.
Worse, some accessibility professionals cling to audits because audits generate rework. And rework generates hours. And hours mean job security… right?
Until the day leadership asks: “Why do we keep fixing the same things over and over?”
Breaking the cycle
The path forward isn’t flashy. It’s operational. Strategic. Slow, at first.
But when you embed accessibility into the foundations — when you shift from “fix it later” to “bake it in” — you get something better than compliance.
You get culture change.
And that’s when things start to scale.
In summary
Audits have their place. Use them to measure, not to teach. Use them to prioritise, not to substitute for inclusive design. And above all, use them as a mirror — to reflect back whether your systems are truly evolving.
Because the real question isn’t whether your teams are fixing issues.
It’s whether they’re learning how not to create them in the first place.
Want more practical guidance like this?
Keep an eye on Arc Inclusion’s upcoming playbooks and how-to guides. We’re building a better accessibility practice — one that empowers teams, not just corrects them.