WCAG 3.0 Changed How Accessibility Gets Scored. No Tool Can Test It Yet

Ask most product teams how they know their site is accessible and you'll get the same answer: the CI pipeline runs axe-core on every pull request, and if it comes back green, accessibility is handled. That answer has been quietly load-bearing for years — a binary pass/fail check standing in for the actual, harder question of whether a disabled person can use the product. WCAG 3.0 is about to make that stand-in stop working, and almost nobody outside standards circles has clocked what that means operationally.

The standard got more honest. Your pipeline didn't get smarter

The core change in WCAG 3.0's March 2026 working draft is a real improvement, and it's worth saying that plainly before getting to the problem: the old model — a page either meets a success criterion or it doesn't, roll every criterion up into a single AA/AAA verdict — never matched how accessibility actually works in practice. Almost no real production site is 100% compliant. Almost none is completely unusable either. The binary checklist forced a lie in both directions.

WCAG 3.0 replaces that with roughly 174 outcome-based requirements and a graded scoring system: Bronze, broadly equivalent to the old WCAG 2.2 AA bar, and Silver, a meaningfully higher threshold representing genuinely good accessibility. A site can hit Bronze with some individual failures present, as long as the overall experience clears the threshold — a conformance model that finally reflects the graded reality every accessibility auditor already knew existed but had no framework to score.

Here's the part that isn't getting covered with the same enthusiasm: as of today, no major testing tool — not axe-core, not WAVE, not Lighthouse, not the commercial platforms teams pay for — has any WCAG 3.0 support. Every automated accessibility gate currently running in production CI/CD pipelines is evaluating against a standard the field is actively moving away from, with no announced timeline from any major vendor for catching up.

The automation ceiling was always there. WCAG 3.0 just admits it

This is the detail that should change how teams plan, and it comes straight from W3C's own documentation, not a vendor's marketing copy: only an estimated 25 to 40% of WCAG 3.0's outcome-based requirements are automatable at all. The rest require human judgment — a person actually assessing whether an outcome is met, not a script checking for the presence or absence of an ARIA attribute.

That's not a temporary tooling gap that a vendor update fixes next quarter. It's a structural feature of the new conformance model. WCAG 3.0 explicitly declines to designate "automated-testable" as a conformance tier of its own; the working group frames automation as an on-ramp, not a destination, and has issued an open invitation to test-tool makers to document what they can and can't check as coverage evolves. Translated out of standards-speak: the era of "green checkmark means compliant" is ending by design, not by accident, and the field is telling you so directly.

For teams that built their entire accessibility practice around a CI gate — no automated failure, no reviewer flag, ship it — this is a genuine operational cliff, not a documentation update to skim. A pipeline that can only see 25-40% of what the standard now requires isn't a slightly outdated pipeline. It's a pipeline that will confidently report "accessible" on work nobody has actually evaluated on the majority of the criteria that now count.

Standards don't wait for your roadmap, but this one especially won't

WCAG 3.0 isn't finished — it's a Working Draft, with a Candidate Recommendation targeted for roughly Q4 2027 and full W3C Recommendation status not expected until around late 2029. That distance is exactly why most teams are shelving this as a someday problem, and that's the mistake. Standards bodies publish drafts years ahead of ratification specifically so implementers can build toward them gradually, and the organizations that treat the multi-year runway as "not yet relevant" are the same ones who'll be scrambling in 2029 with a conformance model they've never actually practiced scoring against.

The gap this creates isn't really about tooling vendors being slow — vendors will eventually ship WCAG 3.0 support, because that's a sellable feature. The gap is about organizational muscle. A team that has spent five years outsourcing its accessibility judgment to a green checkmark has not built the internal skill of evaluating an outcome, because the old model never asked it to. That skill — actual human assessment of whether a real outcome is met, done consistently, at scale, by people who know what they're grading — is not something you install with a tool update. It's something you build over the years the draft period is explicitly giving you, or you don't have it when Bronze and Silver become the thing regulators and enterprise procurement start asking for by name.

I've made a version of this argument before about accessibility debt accumulating silently between audits — the pattern where teams discover problems that were baked in months earlier, because nothing was watching in between. WCAG 3.0 is that same blind spot, arriving at standards-body scale: a multi-year window where the thing that will eventually be graded isn't being watched by anything automated, and the organizations paying attention now are the only ones who won't be caught flat when it counts.

So actually, the honest 2026 accessibility roadmap item isn't "wait for the tools to catch up." It's "start training humans to score outcomes the way WCAG 3.0 will require, on a standard that won't be enforceable for years" — which is a much less satisfying line item to put in a sprint plan than "add axe-core to CI," and exactly why almost no one's doing it yet.