Skip to content
Let’s be honest, you ran another accessibility audit, delivered the report, and flagged the issues. You even tagged the right teams in Jira.
And… not much changed.
Sure, a few fixes were made, eventually. However, 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 accessibility testing and inspection and the need for a process that builds inclusion from the start so teams can be accessibility compliant.
What is an Accessibility Audit?
An accessibility audit is a structured inspection of your digital product or services. It identifies where your site, app, or service falls short of accessibility standards and guidelines.
Audits are incredibly valuable for providing a detailed list of issues. They can highlight key issues such as:
-
Missing labels
-
Poor colour contrast
-
Inaccessible navigation patterns
They highlight the gap between what you build and what an inclusive digital experience should look like.
However, the challenge is that audits happen after the work is done. It measures the end result rather than shaping how a product is designed and built. Accessibility audits are a powerful tool for diagnosis but limited for driving long-term culture change.
What are the Limitations of Accessibility Audits?
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. Each is uniquely designed, built with evolving frameworks, and maintained by teams that change over time.
Here is how accessibility audits show their limits:
-
Reactive, not proactive – audits measure the final product, not how it’s built.
-
In the moment – audits and web accessibility testing capture issues at one moment and quickly become outdated.
-
Do not prevent repetition – the same mistakes reappear in future features because process and culture haven’t changed.
-
Resource-heavy – they often require time, specialist expertise, and effort, but the fixes don’t often scale.
-
Depend on context – audits can flag issues but rarely provide an explanation as to why they happen or how to stop them at the source.
In short, audits and accessibility testing, when used only as inspection, reveal problems, but they don’t prevent teams from making them again.
Software is Not an Assembly Line
Every new piece of software, every feature, screen, and interaction is different. Designed by different people, written under different constraints, and built using ever-evolving frameworks and patterns that constantly evolve.
That means accessibility isn’t something you can retroactively bolt on. An accessibility audit or even web accessibility testing may reveal where something has gone wrong, but inspection alone does not create lasting quality.
What drives real change is the accessibility process itself. When accessibility is built into design reviews, development workflows, and testing practices from the start, it becomes a core part of the product is made, rather than an afterthought.
Or, as the legendary quality expert W. Edwards Deming put it:
“Quality cannot be inspected into a product. It must be built into it.”
What is Accessibility Debt?
Here’s where the disconnect happens and accessibility debt is created.
Accessibility debt is the build-up of issues that occur when teams fix problems after release instead of building accessibility into the process from the start.
Many organisations expect an audit to help their teams learn. That one time a developer saw how they missed a label, they’d never forget to add one again.
However, the reality is often very different. 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.
That continuous cycle is what grows accessibility debt. Audits might clean up yesterday’s mess, but they don’t future-proof tomorrow’s code. Unless accessibility is embedded into everyday workflows, teams will encounter more issues than they resolve, and the debt keeps growing.
Why are Accessibility Audits Important?
Now, let’s not throw audits out with the bathwater. They are still useful for providing perspective on how accessible a product is at any given point in time. Although they do not transform culture on their own, they still offer valuable insights, such as:
-
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.
It is important to remember that audits aren’t a learning tool. They don’t teach inclusive design. They don’t instil empathy, and they won’t magically create an accessibility culture within your teams.
How do you Reduce Accessibility Debt?
Accessibility debt shrinks when accessibility becomes part of the delivery process instead of an afterthought. Lasting impact comes from embedding inclusion into everyday practices. That means:
-
Add an accessibility acceptance criteria on every story
-
Run design reviews that include inclusive patterns
-
Write test cases that reflect real user diversity
-
Provide continuous training, not just one-off workshops
-
Involve people with disabilities in inclusive user testing
Yes, this approach does take more planning upfront, but the payoff is significant, saving teams far more time and effort later while strengthening the accessibility process for the long term.
The Audit Trap: Why We Keep Going Back
Let’s be real: audits feel safer, more familiar, and tangible.
They give us spreadsheets, reports, and dashboards. We can show stakeholders a list of “closed bugs.” It looks like progress, but it’s more like a treadmill, and we keep running in place.
Worse still, 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?”
The answer usually points back to culture, and without changing how teams think about accessibility, the cycle will continue to repeat.
Breaking the cycle with Shift Left Accessibility
Shift-left accessibility means moving accessibility earlier in the development process. Instead of checking for issues after release, teams design and build with inclusion from the start.
The path forward is not flashy. It is operational, strategic, and often slow at first. Integrating accessibility into the foundations turns “fix it later” into “bake it in.”
The result is something more powerful than compliance; it is a genuine accessibility culture. Once that culture takes hold, accessibility begins to scale.
Final Thoughts
Audits will always have their place. Use them to measure, not to teach. Use them to prioritise, not to replace, for inclusive design. Above all, use them as a mirror to reflect back whether your systems are truly evolving.
The real question isn’t whether your teams can fix issues after an accessibility audit or a round of accessibility testing; it is whether they are learning how to avoid creating those issues in the first place.
For more practical guidance, explore our role-based training service, designed to build lasting skills across teams, or learn more about the benefits of digital accessibility for your organisation.