WCAG 3: what the working draft means for current sites

Image description: A printed WCAG 3 working draft with colored sticky-tab bookmarks on a desk beside a WCAG 2.2 document — the visual marker for the WCAG 3 preview primer.

Reading Time: 12 minutes

WCAG 3 — the next-generation accessibility guideline the W3C has been drafting under the working name Silver since 2017 — is still, in mid-2026, a W3C Working Draft. That single fact is the most important thing to know about it. It is not a Recommendation, it is not a Candidate Recommendation, and nothing in it can yet be cited by a regulator, a court, or a procurement officer with legal force. WCAG 2.2 remains the standard the world is currently auditing against, and EN 301 549, U.S. Section 508, and the national implementations of the Web Accessibility Directive all reference WCAG 2.x. What WCAG 3 represents is a deliberate architectural rewrite of how accessibility conformance is measured — and a glimpse of what the next ten years of regulator adoption will look like once it stabilises.

This primer covers what WCAG 3 is, what it changes structurally, how its proposed bronze/silver/gold conformance tiers work, when Candidate Recommendation might realistically appear, the political tension with WCAG 2.2 (which national regulators are still in the middle of adopting), and what teams running on 2.x today should actually do about it now. The short version: read the working draft, do not refactor for it, and treat any vendor promising “WCAG 3 conformance” today as either confused or selling something.

What WCAG 3 actually is — and what it is not

WCAG 3 is the working title of a new Recommendation track at the W3C’s Accessibility Guidelines Working Group (AG WG), distinct from the WCAG 2.x line. The project started in 2017 under the project name Silver (the chemical symbol Ag, an in-joke on “Accessibility Guidelines”) and the first public Working Draft was published in January 2021. The most recent Working Draft is the version readers will find at the w3.org/TR/wcag-3.0/ URL — and the W3C dates that draft, like every draft before it, with a prominent header banner reading “This document is a Working Draft. It is not stable and should not be referenced or used as a basis for implementation.”

That banner is doing real work. Inside the W3C process, a document moves through five maturity levels: Working Draft, Candidate Recommendation (CR), Proposed Recommendation (PR), Recommendation (REC), and finally Superseded Recommendation. WCAG 2.0 reached REC in December 2008. WCAG 2.1 reached REC in June 2018. WCAG 2.2 reached REC in October 2023. WCAG 3 has not yet entered CR — and the W3C has been explicit that several substantive design questions still need to be resolved before it can. The current state, as of the most recent published draft, is that of a research-and-design document with workable sections and clearly-flagged open issues, not a stable specification.

What WCAG 3 is not: it is not a replacement for WCAG 2.2. The W3C has stated that WCAG 2.2 and WCAG 3 will likely coexist for an extended transition period after WCAG 3 reaches Recommendation. WCAG 3 is also not “WCAG 2.3” — its content model, conformance model, and editorial structure are different enough that re-numbering inside the 2.x line was rejected early in the design process.

Purpose and scope: why a new line at all

Three structural problems with WCAG 2.x drove the decision to start a new line rather than continue incrementing the 2.x numbering.

First, scope. WCAG 2.x is, technically, the Web Content Accessibility Guidelines — it targets web content rendered in a user agent. The Working Group’s mandate, however, has expanded over a decade to cover the full surface of digital accessibility: native mobile applications, kiosks, voice interfaces, virtual and augmented reality, AAC (augmentative and alternative communication) tooling, conversational AI surfaces. WCAG 3 is being designed from the outset to be content-and-platform-agnostic, with the same guideline applying to a web page, a native app screen, a voice flow, and a kiosk dialog without forcing teams to write three different conformance statements against a guideline whose name still says “Web.”

Second, conformance model. WCAG 2.x conformance is binary: every applicable success criterion either passes or fails, and a single failure on a single AA criterion sinks the page’s conformance claim. This works for crisp interface-level criteria like “use semantic headings” — it works less well for criteria where the underlying barrier is graded rather than categorical, such as language complexity, cognitive load, or how clearly an error message communicates what went wrong. WCAG 3 introduces scored outcomes so that a page can have a measurably better result on, say, “clear language” without forcing the binary call that 2.x demands.

Third, users not yet well served. WCAG 2.x has well-documented gaps for users with cognitive disabilities, users with low literacy, users relying on AAC devices, users of voice interfaces, deafblind users navigating with refreshable braille, and emerging assistive-technology modalities such as eye-gaze and brain-computer interfaces. The 2.x success criteria can be applied to these users — but they were drafted with screen-reader, magnifier, keyboard-only, and low-vision users primarily in mind. WCAG 3’s guideline architecture explicitly invites contributions for cognitive, voice, AAC, and emerging-AT modalities as first-class guideline targets.

Key changes: outcomes, not success criteria

The most consequential change in WCAG 3 — the one every other change descends from — is the move from success criteria to outcomes.

A WCAG 2.x success criterion is a binary, testable statement. 1.4.3 Contrast (Minimum) states: text and images of text have a contrast ratio of at least 4.5:1, with two specific exceptions. A page either meets the criterion or it does not. That is excellent for repeatable testing and adversarial use (litigation, audit, procurement) but punishing for criteria where the underlying user need does not partition cleanly into pass/fail.

A WCAG 3 outcome, in the current draft, is a testable statement attached to one or more methods that describe how to verify the outcome and how to score the result. Outcomes can be binary where binary is the right shape (a form field either has a label or it does not) but they can also be scored on a numeric scale where the underlying user need is graded (how readable is this paragraph; how recoverable is this error state; how predictable is this navigation). The conformance result for a product is then computed across outcomes rather than gated on every-criterion-pass.

Several other architectural changes follow:

• Guidelines as the organising unit. WCAG 3 groups outcomes under guidelines (which roughly correspond to the principles-and-guidelines layer of WCAG 2.x, but are written more declaratively).
• Methods, not techniques. WCAG 2.x has informative techniques that suggest how to satisfy a success criterion. WCAG 3 has normative methods that describe how an outcome is verified. The shift from “informative” to “normative” matters: it means the testing procedure travels with the guideline rather than being a separate, debatable accompaniment.
• Atomic and holistic tests. Some outcomes are tested at the atomic level (one element, one rule) and some are tested holistically across an entire view or task flow. Cognitive-load and clear-language outcomes are inherently holistic; contrast and labelling outcomes are inherently atomic. WCAG 3 makes that distinction explicit in the method.
• Functional needs categories. The draft introduces functional needs — vision, hearing, cognition, speech, mobility, multi-sensory — as a cross-cutting axis. Each outcome is mapped to the functional needs it addresses, so a tester or regulator can ask “show me everything that affects users with cognitive needs” without re-reading the entire document.

Conformance tiers: bronze, silver, gold

Where WCAG 2.x has three conformance levels — A, AA, AAA — WCAG 3 proposes three conformance tiers: Bronze, Silver, and Gold. The labels are deliberately not letters and deliberately not cumulative-by-rule; they signal that the higher tiers reflect a meaningfully better experience for users, not “the same product with more boxes ticked.”

Bronze is the minimum conformance tier. It is intended to correspond, roughly, to “WCAG 2.x AA-equivalent” — that is, a Bronze-conforming product should not be substantially worse than today’s AA-conforming product. Bronze conformance requires passing all critical errors (outcomes flagged in the draft as fundamental barriers — for example, missing alternative text on informative images), and achieving a defined threshold across the outcome score across the product. The draft proposes that critical errors remain binary even within the scored model: any critical error blocks Bronze conformance regardless of how well the product scores elsewhere.

Silver is the intermediate tier and is intended to correspond, roughly, to a strong AA-plus product — better than the WCAG 2.x AA bar but not yet at AAA. Silver typically requires a higher threshold across the same scored outcomes, plus passing additional outcomes that are not required at Bronze. The specific thresholds are still under consultation in the working draft.

Gold is the top tier. It is intended to represent a product that has been designed and tested for the full range of functional needs the guideline covers, not only the ones the existing 2.x AA criteria mostly addressed. Gold is the tier where the cognitive, voice, AAC and emerging-AT outcomes carry the most weight, because those are the user groups where 2.x conformance does not currently produce a comparable result.

Two important properties of the tier model worth noting. First, scope is per-view or per-flow, not per-page: a product can carry different conformance tiers on different surfaces, which is more honest than WCAG 2.x’s per-page model for complex applications. Second, the conformance claim travels with the methods used to verify it — so a Silver claim under WCAG 3 should be reproducible by another tester following the same methods, in a way that WCAG 2.x AA claims (which rely heavily on tester judgement at the edges) often are not.

Emerging assistive-technology modalities

A major editorial commitment of the WCAG 3 project is first-class support for assistive-technology modalities that WCAG 2.x has historically addressed only obliquely.

Cognitive accessibility is the largest of those expansions. The current draft incorporates outcome work that was previously developed in the W3C’s separate Cognitive Accessibility Task Force output (the Making Content Usable for People with Cognitive and Learning Disabilities document). Outcomes in this area cover clarity of language, predictability of navigation, support for orientation and wayfinding, error prevention and recovery, and minimisation of unnecessary cognitive load. Many of these outcomes are scored rather than binary — there is no clean pass/fail for “is this sentence readable enough” — and that is the case the scored conformance model was built to handle.

Voice and conversational interfaces are explicitly in scope. Outcomes address the recognisability of voice prompts, the discoverability of voice commands, the recovery path when voice misrecognition occurs, and the equivalence between voice and visual interaction in dual-modality interfaces. This is the part of the draft where the platform-agnostic guideline architecture matters most: a voice-only flow on a smart speaker cannot meaningfully be tested against WCAG 2.x’s “web content” success criteria, but it can be tested against WCAG 3 outcomes drafted to be modality-neutral.

AAC (augmentative and alternative communication) users — people who communicate primarily through symbol boards, picture exchange systems, or speech-generating devices — are explicitly addressed in the draft’s user-research targets. Outcomes here relate to symbol consistency, support for AAC input as a first-class interaction mode, and the cognitive predictability of dialog states that an AAC user needs to navigate.

Emerging AT — eye-gaze, switch interfaces, brain-computer interfaces, head-tracking, and the assistive surfaces of mixed-reality devices — is named in the draft’s roadmap. The Working Group’s working position is that the guideline architecture should accommodate these modalities without requiring the document to enumerate every possible AT; the functional-needs axis is one mechanism for that.

Timeline: when Candidate Recommendation might land

The honest answer is that no one outside the AG WG can give a confident date, and no one inside it has published one. The W3C’s process is consensus-driven, and the design questions still open in WCAG 3 — the precise scoring methodology, the exact thresholds for Bronze/Silver/Gold, the conformance-statement format, the testability of the cognitive outcomes, the relationship to WCAG 2.2 during the transition — are non-trivial. Working Drafts in any standards lineage can sit at that maturity for years.

What can be said with reasonable confidence is the shape of the path. Candidate Recommendation is the next maturity step after the current Working Draft, and CR cannot be entered until the Working Group resolves the open issues currently flagged in the draft and demonstrates that the proposed outcomes are testable (a process the W3C calls “feature-at-risk” review and that takes substantial implementation experience to clear). Several public statements from W3C staff during 2025 indicated that CR for WCAG 3 was still some way off and that the project should be treated as years rather than months from a stable specification.

Once CR is entered, the standard timeline calls for at least one implementation period of several months during which the working group gathers evidence that the outcomes have been verified against real products. PR follows. REC follows that. After REC, the slow process of regulator adoption begins — and that has historically been measured in years, not months. EAA-style citation of WCAG 3 through a revised EN 301 549 (a V5 or later) is, on any realistic reading, a late-2020s prospect rather than an immediate one.

The tension with WCAG 2.2

WCAG 3 sits in real political tension with WCAG 2.2, and that tension is the subtext of every WCAG 3 discussion inside the industry. WCAG 2.2 reached Recommendation in October 2023 — a published, stable, citable standard that national regulators are still in the middle of adopting. Some have adopted it already. Some have not. The forthcoming V4 of EN 301 549 will incorporate WCAG 2.2; U.S. Section 508 is in the middle of a refresh that points to WCAG 2.x; private-litigation defence in the United States cites WCAG 2.x by default.

The tension is not really about which document is “better.” It is about whether regulators can adopt a standard that is still moving — and whether teams that have just invested in WCAG 2.2 conformance should believe a different framework is around the corner. The Working Group’s stated position is that the two lines are not zero-sum: WCAG 2.2 remains the operative standard for regulator adoption, and WCAG 3 is the next generation that will, in time, succeed it. Both documents will be maintained at the W3C side by side once WCAG 3 reaches Recommendation, and the W3C has signalled that the transition will be deliberately long enough that teams do not face a forced migration.

In practice this means three things. WCAG 2.2 audit work is not wasted — the underlying access barriers it identifies do not disappear under WCAG 3, they are reorganised into outcomes. Regulators that are mid-adoption of WCAG 2.2 are not making a mistake — they are doing the work that needs doing this decade. And vendors marketing “WCAG 3 conformance” against a working draft are misrepresenting the standard’s maturity; no conformance claim against an unstable Working Draft is meaningful.

WCAG 2.2 vs WCAG 3: dimensions compared

Implications for 2.x sites today

The practical question for any team running a site, app, or product on WCAG 2.x today is: should we do anything differently because WCAG 3 is coming? The answer breaks into three pieces.

Audit and remediate against WCAG 2.2 AA. This is the standard that regulators are adopting, that EN 301 549 V4 will incorporate, and that courts in jurisdictions with private rights of action cite. A 2.2 AA audit done well in 2026 is not throwaway work — the underlying barriers will still be barriers under WCAG 3, and the remediation effort to fix them is the same. Teams that postponed 2.2 work in the hope of “doing WCAG 3 instead” are choosing a worse outcome on a longer timeline.

Read the WCAG 3 Working Draft, do not refactor for it. The draft is a useful window into where the standard is heading and which user needs the next decade will foreground. Teams should read it (it is freely available at the W3C TR site), share it inside design and engineering, and use it to prime conversations about cognitive accessibility, voice interfaces, and AAC. They should not, however, start writing conformance statements against it, drafting procurement clauses against it, or restructuring audit programmes to anticipate it. The draft is not stable enough for any of those activities.

Invest in the user-research and design-research capacity that WCAG 3 will require. The scored, holistic, modality-agnostic outcomes that WCAG 3 introduces cannot be verified by automated scanning tools alone. They need design research with users who have cognitive disabilities, with AAC users, with voice-interface users. The teams that will be ready when WCAG 3 reaches Recommendation are not the ones with the most sophisticated automated tooling — they are the ones with established user-research relationships across the full range of functional needs. Building those relationships now is investment that pays off under either standard.

WCAG 3 in the standards graph you already know

If you have followed the accessibility-standards arc — from Section 508 through EN 301 549, from the W3C’s WCAG 2.0 through 2.1 and into 2.2 — WCAG 3 is the next generation of that arc, currently mid-design. It is the document that the standards community is building because the limitations of WCAG 2.x’s binary, web-only, success-criterion model have become hard to ignore as digital accessibility has expanded into mobile, voice, AAC and cognitive interfaces. It is also, today, an unstable Working Draft that no regulator can yet cite and no responsible vendor can yet claim conformance against.

For practitioners scoping the remainder of this decade: WCAG 2.2 is the standard to audit against, EN 301 549 V4 is the procurement instrument to align with, and WCAG 3 is the document to read on a Friday afternoon to understand where the work is heading. The right posture is informed patience — keep WCAG 3 in peripheral vision, do the WCAG 2.2 work in front of you, and build the user-research capacity that will matter regardless of which document the auditors cite five years from now. For the next instalment in this primer series, see the WCAG 2.2 adoption-rate survey tracking which national regulators have already crossed the line.