Somewhere along the way, a lot of teams started treating accessibility like a test with a 100% score waiting at the end of it. A leadership dashboard gets built. A number gets put on it. Everyone quietly agrees that number should hit 100, and every sprint that it doesn't feels like failure.
WCAG was never built that way. There is no master percentage hiding inside the standard, no finish line where a site becomes officially "done." Chasing a number that does not exist is a real, common cause of accessibility burnout among developers, QA teams, and the one person who got handed the "accessibility owner" title in a meeting they weren't even in. And it is entirely avoidable, once you understand what the standard actually measures.
The Stat: Deque's own published research puts automated accessibility scanning at catching roughly 57.38% of WCAG issues on its own - even the measurement tools built to gauge "how compliant are we" only see part of the picture. (Source: Deque)
The score that doesn't exist
WCAG itself is organized into three conformance levels: A, AA, and AAA. That's it. There is no fourth level called "100%," and there is no formula anywhere in the standard that converts a list of passed and failed success criteria into a single percentage you can put on a slide.
More pointedly, the W3C's own WCAG conformance requirements explicitly state that AAA, the highest level, is not recommended as a general policy for entire sites, because it is not always possible to satisfy every AAA criterion for certain kinds of content. Read that again: the organization that wrote the standard is telling you, in its own documentation, not to aim for "everything, at the highest level, everywhere." That is the opposite of a 100% mandate.
So where does the number come from? Usually from somewhere outside WCAG entirely: a scanning tool's dashboard, a vendor's compliance score, or a well-meaning internal tracker that turned "issues found vs. issues fixed" into a percentage because percentages feel satisfying to report upward. None of that is wrong to track. It becomes a problem the moment "100%" gets treated as the actual target, instead of a rough, partial signal.
The burnout loop, and why it never resolves
Here's the pattern we see over and over in real programs. A scan runs. It finds a batch of issues. The team fixes the loud, obvious ones. The dashboard ticks up toward "compliant." Then a new page ships, or a new component gets built, or someone runs a deeper manual pass, and new issues appear that the scanner never could have caught on its own.
That's not a bug in the process. It's baked into what automated scanning actually is. If a tool built specifically to measure this only catches roughly 57.38% of issues, as Deque's research shows, then any team treating "the scan came back clean" as "we're done" is working from a number that was never designed to be a finish line. The other issues, the ones that need a real screen reader, a keyboard-only pass, or a person navigating with cognitive load in mind, are still out there. They just aren't on the dashboard yet.
Teams that don't know this keep chasing the missing percentage points, assume they're failing, and burn out trying to close a gap that automated tooling was never going to fully reveal in the first place. Teams that do know this stop treating the score as the goal and start treating it as one input among several.
What actually happens when "100%" is the goal
- Every sprint planning meeting turns into a negotiation over which fixes count toward "the number," instead of which fixes matter most to real users.
- Engineers start gaming scanner output (dismissing flagged issues, narrowing scan scope) because the score is being reported to leadership as a KPI.
- New, more serious issues found through manual testing get deprioritized because they weren't part of "the original 100%," so fixing them makes the score look worse before it looks better.
- The person responsible for the number quietly starts dreading every audit, because there is always another gap, and the gap is framed as personal failure rather than expected, ongoing work.
- Actual users with disabilities keep hitting real barriers on the pages that already "passed," because passing was never the same thing as accessible.
What to track instead
Trade the single vanity score for a small set of honest, trackable signals. None of these require inventing new tooling, and all of them are more useful to leadership than a number that was never real to begin with.
| Instead of tracking... | Track this |
|---|---|
| One overall "% compliant" score | Trend line of open critical/serious issues over time |
| Whether the scan came back clean | Ratio of automated findings to manually-found findings per audit |
| A single pass/fail per page | Time-to-fix by severity (critical issues fixed in days, not quarters) |
| A finished/unfinished binary | New issues introduced per release, so regressions get caught early |
| "We hit AAA everywhere" | Which AA criteria matter most for this specific product, prioritized by real user impact |
That last row matters more than it looks. Because AAA isn't recommended as a blanket target, the better question isn't "how do we hit the highest level everywhere," it's "which failures, at whatever level, are actually stopping someone from completing a task right now." That's a prioritization question, not a scoring question, and we've read why shipping real fixes beats chasing a perfect score on this exact point before, because it's the natural follow-on to giving up the 100% myth.
A checklist for a program that won't burn people out
- Stop reporting a single "% compliant" number to leadership; report a trend instead
- Pair every automated scan with a recurring manual and assistive-technology pass
- Rank open issues by real user impact, not by how they affect the dashboard score
- Set a time-to-fix target for critical issues, separate from any overall completion metric
- Revisit AAA criteria selectively, only where the content genuinely calls for it
- Give whoever owns accessibility a realistic mandate: steady progress, not perfection
A different kind of finish line
The teams who stay sane about this work aren't the ones with the highest score. They're the ones who stopped expecting a score to exist at all, and replaced it with a trend they can actually see moving in the right direction. Open issues going down, time-to-fix going down, new regressions getting caught earlier. That's a program that's working. A frozen "100%" on a dashboard never told anyone that.
If your team is stuck chasing a number that was never real, the fix isn't more scanning, it's a clearer starting point. You can get a real, prioritized baseline audit instead and see exactly which issues actually matter for your users, ranked the way real people experience your site rather than the way a scanner tallies a score. That's the same idea behind our offer to get a real, prioritized baseline instead of chasing an impossible score: real progress you can point to, not a percentage you'll never quite reach. If you'd rather talk it through first, our team is reachable directly at experts@wcag.world.