WCAG 3.0: what the new draft changes for testing

W3C published a fresh WCAG 3 Working Draft this week, which means another round of posts announcing that accessibility testing is about to change completely. Before anyone rewrites a test plan: WCAG 3.0 is still a Working Draft, Candidate Recommendation isn't expected until late 2027, and a finished Recommendation looks unlikely before 2028.

Nothing you are legally required to meet has changed. WCAG 2.1 AA is what the European Accessibility Act points at, and that's the bar being enforced right now. Keep testing against it.

The draft is still worth reading, because the direction it sets changes what "accessibility testing" means in a way that has practical consequences well before any of it becomes normative.

From pass/fail to scoring

The biggest structural change is the conformance model. WCAG 2.x gives you success criteria at levels A, AA, and AAA, and each one is a binary. You meet it or you don't. Conformance means meeting all of them at your target level.

WCAG 3 replaces that with outcomes and a scoring model. The March 2026 draft reorganized guidance into a much larger set of outcome-based requirements, reported at around 174, and grades against levels named Bronze and Silver rather than A through AAA. Bronze is roughly positioned where WCAG 2.2 AA sits today. Silver is a meaningfully higher one.

There's a real argument behind the change. Under a binary model, a site with one minor failure on one page is non-conformant, exactly like a site that's unusable with a screen reader. Those are not the same situation and treating them identically has made formal conformance claims less useful than they should be.

The tradeoff is that a score is harder to enforce against and easier to argue about. Binary criteria make bad law but clear tests. That tension is a lot of why this draft has been in progress for years.

Outcomes are written for users, not for parsers

The second shift matters more for day-to-day testing. WCAG 2.x criteria are written to be checkable, often against markup. WCAG 3 outcomes are written in terms of what a user can accomplish.

Take a criterion like "non-text content has a text alternative." A tool can check that. An outcome framed as whether a user relying on a screen reader can understand the information an image conveys cannot be checked by a tool at all, because the question is about whether the alternative is any good.

Which is honest, and it's also where the friction lands. If the standard moves toward outcomes that automation can't evaluate, the gap between what your CI job checks and what conformance requires gets wider, not narrower.

The automation ceiling doesn't move

Automated scanning catches somewhere around a quarter to a third of real WCAG issues today. Nothing in the WCAG 3 direction improves that number. If anything, outcome-based requirements shift more of the standard into the part tools can't reach.

So the practical consequence is the opposite of "buy a new tool." It's that manual testing with assistive technology, and ideally testing with people who use it daily, becomes a larger share of what conformance actually requires. Teams treating accessibility as a CI job with a green checkmark are going to find that position gets less defensible over time, not more.

What to do now

Very little, deliberately:

1. Keep testing against WCAG 2.1 AA. It's the legal requirement and it will remain the legal requirement for years. Work done here is not wasted, because Bronze is positioned close to where 2.2 AA already sits.
2. Build the manual testing habit now. A quarterly screen reader pass on core journeys is useful today and will be non-optional later. The capability takes time to develop and it doesn't appear the quarter you need it.
3. Record what you tested and how. Under a scoring model, a conformance claim becomes an evidence exercise rather than a binary statement. Which outcomes were evaluated, by what method, when. Teams already keeping that record will find the transition administrative. Teams that aren't will find it a project.

Read the WCAG 3 explainer if you want the reasoning in full. It's shorter than the draft and clearer about intent.

The part worth internalizing

Standards moving toward outcomes and away from checkable criteria is not unique to accessibility. It's the same shape as the shift in AI regulation, where the obligations are increasingly about demonstrating that a system behaves acceptably rather than passing a fixed checklist.

Both push in the same direction for QA: away from "the scan was clean" and toward a continuous, documented record of what was verified and how. The tooling for checkable criteria is mature. The practice of keeping evidence about outcomes is the thing most teams still have to build.

qtrl runs tests in real browsers and records what each run checked, which is the evidence layer these standards are converging on. Keyboard paths, focus behavior, and journey-level checks live alongside your functional coverage rather than in a separate accessibility silo.

Manual sessions can be logged against the same cases, so a conformance claim has both the automated and the human evidence behind it in one place instead of two. See how it works.