WCAG 3.0's March 2026 Draft: What Changed, and Why You Should Still Build to 2.2 AA

On March 3, 2026, the W3C published a new Working Draft of WCAG 3.0. It is the most substantial revision since the guidelines were first drafted, and it has produced a predictable wave of "WCAG 3.0 is coming, are you ready?" content.

Here is the honest version: WCAG 3.0 is still a Working Draft, it is years from being a Recommendation, no law references it, and nothing in the March 2026 draft should change what your team builds this quarter. What it should change is how you think about where the standard is heading.

What Actually Changed in the March 2026 Draft

Three things are worth knowing.

"Outcomes" are now "requirements." Earlier drafts used "outcomes" to describe the testable units that replace WCAG 2.x success criteria. The March 2026 draft renames them requirements. This is not cosmetic — it signals that the working group has settled on these as the normative, testable core of the specification rather than aspirational statements.

There are roughly 174 of them. WCAG 2.2 has 87 success criteria across three levels. The March 2026 draft describes about 174 requirements. That is not because the web got twice as inaccessible; it is because WCAG 3.0 decomposes broad criteria into narrower, more specifically testable units, and because it covers ground WCAG 2.x barely touches — particularly cognitive accessibility and low vision.

The structure is settling. The architectural argument — how conformance is scored, how requirements are grouped, how assertions work — is largely resolved in this draft. Earlier WCAG 3.0 drafts were genuinely unstable; this one reads like a specification converging on a shape.

Bronze, Silver, and Gold: The Conformance Model

The biggest conceptual break from WCAG 2.x is that conformance is no longer strictly pass/fail against a checklist.

WCAG 2.2 conformance is binary and unforgiving: to claim Level AA, you must satisfy every Level A and AA success criterion on every page in the conformance scope. A single unlabeled form field on a single page breaks the claim for that page.

WCAG 3.0 proposes three tiers:

• Bronze — foundational accessibility, broadly comparable in ambition to WCAG 2.2 Level AA. This is the baseline tier.
• Silver — a higher score, representing accessibility that is genuinely good rather than merely conformant.
• Gold — aspirational, covering thorough support for complex cognitive and low-vision needs.

The consequential detail is that scoring is threshold-based rather than absolute. A site can reach Bronze while still having some individual failures, provided the overall accessibility experience clears the threshold. This is a deliberate response to a real criticism of WCAG 2.x: that binary conformance rewards technically-compliant-but-unusable interfaces and punishes genuinely good ones with one stray defect.

It also introduces a real risk. A scoring model is easier to game than a checklist, and "we scored Bronze" is a weaker statement than "we meet every AA criterion." The working group is aware of this; how it gets resolved in the normative text is one of the open questions.

The Contrast Algorithm Is Still Undecided

If you have read that WCAG 3.0 replaces the 4.5:1 contrast ratio with APCA, that claim is ahead of the specification.

APCA — the Advanced Perceptual Contrast Algorithm — was developed to address genuine deficiencies in the WCAG 2.x contrast formula, which is known to misjudge certain color pairs, particularly in dark mode and at the extremes of the lightness range. It was explored as part of WCAG 3.0.

But the visual contrast work was moved out of the WCAG 3 Working Draft in July 2023 for further evaluation, and the current draft states plainly that the WCAG 3 contrast algorithm is yet to be determined. APCA is exploratory. It is not normative. It may or may not be what ships.

What to do: Keep testing contrast against WCAG 2.x ratios — 4.5:1 for normal text, 3:1 for large text and non-text UI components. If you want to be conservative, you can check APCA scores alongside as a second signal, but do not remediate away from a passing 2.x ratio because APCA disagrees. You would be rebuilding against a specification that does not exist yet.

Contrast is worth the attention regardless. It is the single most common accessibility failure on the web by a wide margin, and unlike most WCAG issues it is fully detectable by automated tooling.

The Timeline

W3C specifications move through Working Draft, Candidate Recommendation, Proposed Recommendation, and finally Recommendation. WCAG 3.0 is at the first of those stages.

A Candidate Recommendation is not anticipated before roughly late 2027. A final Recommendation is unlikely before 2028, and estimates extending toward the end of the decade are not unreasonable given the history — WCAG 3.0 work began in 2016.

Then the regulatory lag begins. Laws do not reference a standard the moment it publishes. ADA Title II references WCAG 2.1 Level AA. The HHS Section 504 rule references WCAG 2.1 Level AA. EN 301 549, which the European Accessibility Act relies on, references WCAG 2.1 Level AA. WCAG 2.2 became a Recommendation in October 2023 and is still not the baseline in most binding regulation nearly three years later.

Realistically, WCAG 3.0 will not be a compliance obligation for anyone reading this before the 2030s.

What This Means for Your Team

Build to WCAG 2.2 AA. It is the current stable standard, it is a superset of the WCAG 2.1 AA that every relevant law actually requires, and the work is not wasted — the WCAG 3.0 requirements are largely a reorganization and expansion of the same underlying accessibility principles, not a repudiation of them. A codebase that genuinely meets 2.2 AA will start from a strong position under any WCAG 3.0 scoring model.

Do not restructure your accessibility program around Bronze/Silver/Gold. The tiers are not final, the scoring math is not final, and no auditor or regulator will accept a Bronze claim in place of a 2.2 AA conformance statement today.

Pay attention to the cognitive and low-vision requirements. This is where WCAG 3.0 genuinely expands coverage, and it is the area where automated tooling helps least. Plain language, consistent interaction patterns, generous timing, predictable navigation, and reflow at high zoom are all cheaper to design in than to retrofit. They are also the areas where users report the most friction and where WCAG 2.x has the thinnest coverage.

Treat any vendor selling "WCAG 3.0 compliance" with skepticism. There is no such thing. You cannot be compliant with a Working Draft that has an undecided contrast algorithm. A vendor making that claim in 2026 is telling you something useful about their relationship with accuracy.

Where Automation Fits

The practical way to stay current across standards revisions is to make conformance continuous rather than periodic. Most teams discover accessibility debt through an annual audit, remediate in a panic, and drift for another eleven months.

Reachablr scans deployed URLs against WCAG 2.1 and 2.2 rules, analyzes component code in your repository, and gates pull requests on net-new violations. When the baseline standard shifts — as it will when 2.2 AA becomes the regulatory floor, and eventually when WCAG 3.0 arrives — the rule set updates underneath a pipeline that is already running, rather than triggering another remediation project.

The teams that will have the easiest time with WCAG 3.0 are not the ones tracking its drafts. They are the ones who already meet 2.2 AA today and have the tooling in place to keep meeting it.