Compliance is not enough: Why passing an audit is only the beginning
Think about the last accessibility audit you were involved in. Did it tell you whether the experience was good? Or just whether it passed?
We spend an enormous amount of energy testing whether products can be used. We spend far less time asking whether they should have to be used that way. That gap between technical access and genuine human experience is what I want everyone to start considering.
Before we dive into frameworks, standards, audits, and metrics, I want you to sit with a question that doesn't get asked enough:
What does it actually feel like to use the things we build?
Think about the last accessibility audit you were involved in. Did it tell you whether the experience was good? Or just whether it passed?
The starting gate, not the finish line
Standards exist for a reason. They give us a shared language, a defensible baseline, and a way to measure progress. WCAG has done extraordinary work in defining what technical accessibility looks like. But standards were never designed to be the finish line. They were designed to be the starting gate.
The problem is that somewhere along the way, "does it pass?" became the question we forgot to go further than. And when that happens, we stop asking the more important question:
is this actually good for people?
A screen reader user can technically navigate a form that takes them 40 steps to complete, but that is not an accessible experience by any meaningful human measure. We need to separate technical conformance and lived experience. They overlap, but they are not the same.
Why "WCAG compliant" is always a judgement call
WCAG and similar standards were designed as minimum baselines, not as quality benchmarks or equity frameworks. They answer floor questions, not ceiling questions. Standards tell you whether a door exists and whether it can technically be opened. They don't tell you whether anyone can comfortably move through it.
Even within standards, interpretation matters enormously. Two organisations can audit the same product against the same criteria and reach very different conclusions. Under pressure, time, budget, delivery, interpretations tend to drift toward the minimum.
That drift is not malicious. It’s structural.
The compliance mindset versus lived experience
The compliance mindset asks one question: can this be used? It describes the possibility of access, not the experience of access. When the compliance mindset dominates, teams celebrate a passed audit the way they'd celebrate shipping a product. The work is done. The boxes are checked. Move on.
But the user hasn't moved on.
They're still there, trying to complete a task.
The lived experience question is a different one entirely:
What is it like to use this?
You can’t answer it with an automated tool.
You can’t fully answer it with a manual audit alone.
You answer it by watching real people use real products and taking what you see seriously.
The Gap That Audits Can’t See
Between "possible to use" and "practical to use" lives most of the accessibility problems that never get fixed.
The gap shows up as:
- A screen reader user who can technically access a data table but has to navigate 200 cells to find the one piece of information they need
- A motor-impaired user who can technically use keyboard navigation but has to tab through 60 interactive elements to reach the main content
- A cognitive accessibility issue where a form is technically valid but uses jargon that makes it incomprehensible
These are real, meaningful barriers. They just don't show up in a conformance report.
Six dimensions of genuine accessibility
Real accessibility experience has multiple dimensions - grounded in accessibility research and years of usability testing with people with a wide range of disabilities.
But they go beyond what standard audits capture.
1: Access
The baseline — can someone technically reach and operate the product? Necessary, but never sufficient on its own.
2: Equity
Does the system distribute effort evenly? If a sighted user takes 30s and a screen reader user takes 8 minutes, that's not equitable.
3: Quality
Does the product do what it promises, clearly and reliably, for everyone? Quality failures hide in the gap between passing and genuinely working.
4: Usability
Can someone complete meaningful tasks — without confusion, friction, harm, or exhaustion? This requires usability testing, not code review.
5: Interface
Every interface decision is an inclusion decision. The words, the error message, the focus order — this is where inclusion happens in practice.
6: Standardisation
Structure, defensibility, repeatability. A baseline is a beginning, not a destination.
The invisible ceiling
Once a product "passes," something very predictable happens; attention moves on. Work feels complete. Risk feels resolved. But usability gaps remain, invisible, because the mechanism we used to detect accessibility problems has already declared success. The audit finds what audits can find. Everything above that ceiling is simply not seen.
Breaking through the invisible ceiling requires different tools: user research, ongoing feedback channels, and a commitment to treating accessibility as a continuous practice rather than a point-in-time test.
Dimensions we consistently under-resource
Human safety. Real people experience real harm from poorly designed digital interfaces. Flashing content can trigger seizures. Confusing medical forms can lead to errors in critical health information. Inaccessible authentication flows can lock people out of essential services. Safety is not an edge case.
Cognitive equity. Cognitive accessibility is consistently under-resourced. It doesn't show up cleanly in automated tools. But cognitive inaccessibility is one of the most common forms of digital exclusion. Plain language is not dumbing down. It is designing for the full range of human cognition.
Sensory access. Sensory access is broader than screen readers and captions. Users with sensory processing differences who are overwhelmed by animation, background video, or high-contrast visual noise are also excluded. Sensory access asks: can someone engage with this content regardless of how they perceive the world?
Motor autonomy. Generous touch targets, no time limits, full keyboard operability, logical focus order and testing with actual assistive technologies. The only way to know if your product works with a screen reader or voice control software is to use those tools and see.
Technical integrity. An accessible design that breaks in certain browsers or fails with certain screen reader versions is not meaningfully accessible. This requires real cross-device, cross-AT testing not just desktop Chrome with NVDA.
WCAG AAA and the dignity threshold
WCAG's AAA level is described in compliance frameworks as "aspirational", meaning you don't have to meet it to claim conformance.
But some AAA criteria aren't luxuries. They're dignity thresholds.
- Sign language for pre-recorded audio.
- Extended audio description.
- No timing requirements.
- Reading level support.
These aren't edge cases for edge users.
When we frame AAA as aspirational, we implicitly accept that some people will be excluded. That is a values statement, not a technical one.
The shift I'm asking you to make
Not "does this meet the requirement?" but "what is the lived experience of this design?"
These questions look similar. They are fundamentally different. The first is closed: it has a yes/no answer. The second is open: it requires observation, curiosity, and ongoing engagement with the people you're designing for. The first ends with an audit report. The second ends with a practice.
So what gets missed when we stop at compliance?
Almost everything that makes an experience genuinely good for people with disabilities. The effort differential. The dignity threshold. The cognitive load. The sensory experience. The accumulated friction. The small decisions that determine whether someone feels included or merely tolerated.
Standards matter. But they were never designed to carry the full weight of inclusion. Real accessibility requires real human engagement with the people who use our products, and with the question of what kind of experience we want to create for them. That's what Global Accessibility Awareness Day is for: reminding us that behind every standard is a person. And our job is to design for the person.
Take the next step
If this resonated with you, start with one question in your next sprint: not "does it pass?" but "what is it like?" Bring a disabled user into the conversation. Watch what happens. The Testing Consultancy can help you build the practice - not just pass the audit.