a11y teacher edition W3C WCAG 2.2 & WCAG 3.0 draft reference
codea11y.dev
Plain English Accessibility Hub

Translating W3C Standards for Designers, Developers, QA & Product teams

Audit Calculator W3C Official

Key Paradigm Shift: Universal Primary Conformance

WCAG 3 moves from page-by-page conformance to conformance claimed for a defined scope, which can be pages or views, processes, paths or components, with reporting tiers on top. Some WCAG 2.2 mechanisms, such as conforming alternate versions, are not in the draft yet and are still being discussed. "Not in the draft" means undecided, not removed.

Not in the current draft · undecided

Conforming Alternate Versions & Equivalents

Allowed in WCAG 2.2:

WCAG 2.2 Conformance Requirement 5.2.1 lets a non-conforming page count toward conformance if a 'conforming alternate version' exists: a version that meets the requirements, provides all the same information and functionality, is as up to date, and can be reached from the non-conforming page in an accessible way. W3C describes it as a fallback, not a goal.

WCAG 3 Plain English Reality:

The current WCAG 3 draft does not mention conforming alternate versions at all, so it neither keeps nor removes them. The working group is discussing how to bring alternate versions and the 'equivalents' exceptions scattered across individual provisions together into one mechanism. Until that lands, treat alternate versions as an open question, not as something WCAG 3 has dropped.

W3C Working Group Debate & Consensus

Discussion #623 (opened 23 March 2026) asks which requirements use an equivalents exception and how a single, global exception or conforming alternate version would work. Views differ: some members want WCAG 2's approach kept as a last-resort fallback; others note that desktop and mobile versions can both be 'primary', that it is content rather than requirements that has equivalents, and that regulators find the CAV term confusing. Issue #682 separately asks for a requirement that every variation of a page (e.g. responsive breakpoints) must conform.

💬 GitHub Issues & Working Group Discussion Threads:

Role Impact

🎨 Designer: Design the main experience to be accessible. If an alternative view exists, make sure it is reachable accessibly and kept in step with the original.
💻 Developer: Don't plan on an alternate accessible version being an accepted route under WCAG 3 yet, and don't assume it has been banned either. Each responsive variation may need to meet requirements on its own (#682).
🧪 QA / Tester: Under WCAG 2.2, check that any alternate version is complete, current and reachable. For WCAG 3, record which variations you tested; the rules are not settled.
📋 Product Manager: Budget for accessibility in the primary product. Treat alternate versions as a WCAG 2 fallback whose WCAG 3 status is still undecided.

🔗 Supporting W3C Specifications & Documentation

W3C WCAG 2.2 Official Definition: Conforming Alternate Version W3C WAI Guidance: Understanding Conformance & Alternate Versions
Replaced by Defined Conformance Scope (with Alternative Scoring Proposal)

Page-by-Page Binary Pass/Fail Conformance

Allowed in WCAG 2.2:

WCAG 2.2 evaluates accessibility on a strict page-by-page basis (either a whole URL passes 100% of SCs at Level AA or the entire page fails).

WCAG 3 Plain English Reality:

WCAG 2.2 evaluated conformance on a strict page-by-page basis. WCAG 3 replaces single-page reliance with a defined 'conformance scope' (which may span entire products, complete processes, paths, views, or components) where all core requirements must be satisfied. A scoring-based alternative is described in the Explainer, which says it is not included in the WCAG 3 draft.

W3C Working Group Debate & Consensus

Discussions focus on defining clear boundaries for limited scopes (like components and user processes) so that critical tasks cannot be blocked by severe friction, while exploring whether progress is better captured through reporting tiers or percentage scoring.

💬 GitHub Issues & Working Group Discussion Threads:

Role Impact

🎨 Designer: Think about which processes and paths you would put in a conformance scope, not only individual screens.
💻 Developer: Expect every core requirement to apply across whatever scope is claimed: pages or views, processes, paths or components.
🧪 QA / Tester: Record the scope you tested (pages or views, processes, paths or components) alongside the results.
📋 Product Manager: Decide early which conformance scope boundaries you could defend; that is a product and legal question as much as a technical one.

🔗 Supporting W3C Specifications & Documentation

W3C WCAG 3.0 Editors' Draft: Defined Conformance Scope W3C WCAG 2.2 Official Spec: Conformance Requirements
Replaced by Single Core Conformance Bar & 6 Reporting Tiers

Strict A / AA / AAA Conformance Levels

Allowed in WCAG 2.2:

WCAG 2.2 categorizes all criteria into rigid buckets: Level A (minimum), Level AA (the level most laws and policies reference), and Level AAA (enhanced).

WCAG 3 Plain English Reality:

The traditional A/AA/AAA tier structure from WCAG 2.x is omitted in WCAG 3. Instead, WCAG 3 defines a single conformance threshold (Tier 3: Conformance) requiring all core requirements to be satisfied, framed by six reporting tiers that express progress toward conformance (Tiers 1–2) and achievements beyond it (Tiers 4–6: Bronze, Silver, Gold).

W3C Working Group Debate & Consensus

The working group moved leveling from conformance to reporting in the August–September 2026 editor's drafts (PRs #826, #834) and published that model in the 10 September 2026 Working Draft, making Bronze an achievement tier above conformance rather than a baseline. That draft also describes an alternative proposal, scoring toward conformance followed by Bronze/Silver/Gold awards, and invites public comment on which to keep.

💬 GitHub Issues & Working Group Discussion Threads:

Role Impact

🎨 Designer: Design to meet every core requirement first. Supplemental requirements and assertions count toward the reporting tiers above conformance.
💻 Developer: Treat the core requirements as the conformance bar. Supplemental requirements count toward reporting tiers above it.
🧪 QA / Tester: Test core requirements for conformance. Assertions need evidence, such as review and usability-testing records, rather than a pass/fail test.
📋 Product Manager: Plan for one conformance bar (all core requirements) with optional tiers above it; the tier details are still undecided.

🔗 Supporting W3C Specifications & Documentation

W3C WCAG 3.0 Editors' Draft: Conformance Requirements W3C WCAG 3.0 Explainer: Conformance Models & Reporting Tiers
Standardized into Defined Accessibility Support Sets

Page-Level 'Accessibility Supported' Reliance

Allowed in WCAG 2.2:

WCAG 2.2 allowed authors to rely on specific user agent/assistive technology combinations defined in an author-specified 'accessibility supported' baseline.

WCAG 3 Plain English Reality:

In WCAG 2.2, authors relied on subjective, author-defined 'accessibility supported' baselines. WCAG 3 standardizes this by defining two explicit Accessibility Support Sets: a Default set (common browsers/AT supporting English content) and Alternative sets (for other languages, regions, or closed environments), which must be explicitly declared in conformance claims.

W3C Working Group Debate & Consensus

The AG Working Group commits to ensuring core requirements have at least one method working with the default accessibility support set at publication time. Current discussions address defining the default set, guidance for creating alternative sets, and handling long-standing AT/UA bugs.

💬 GitHub Issues & Working Group Discussion Threads:

Role Impact

🎨 Designer: Design for cross-platform assistive technology compatibility.
💻 Developer: Use standard ARIA and HTML specs that work across VoiceOver, NVDA, JAWS, and TalkBack.
🧪 QA / Tester: Test across multiple browser/screen reader combinations.
📋 Product Manager: Ensure multi-device and multi-AT support in platform support matrix.

🔗 Supporting W3C Specifications & Documentation

W3C WCAG 3.0 Editors' Draft: Accessibility Support Sets W3C WCAG 2.2 Official Definition: Accessibility Supported

Looking for the hottest debates?

That list now lives on the Discussions page, generated directly from W3C GitHub issue threads instead of hand-maintained — currently 36 provisions summarized, with positions, agreements, and open questions attributed to named participants.

View W3C Working Group Discussions →