UI/UX Atlas
Accessibility Intermediate

WCAG 3.0 Status & the Scoring Model Shift

A deep look at where WCAG 3.0 stands in 2026, why its bronze/silver/gold scoring model is a seismic shift from binary pass/fail, and what practitioners should do right now.

9 min read

The full lesson

For over two decades, accessibility conformance has worked like a light switch: a criterion either passes or fails, and a product either claims WCAG 2.x compliance or it does not. WCAG 3.0 — still in development as of 2026 — proposes to replace that binary model with a graduated scoring system. This better reflects how accessibility actually works in the real world.

Understanding where the spec stands, what is really changing, and what the common misconceptions are is essential for any practitioner advising clients or building products today.

Why WCAG 2.x’s Binary Model Has Friction

WCAG 2.2 (published October 2023) is the current legal and practical baseline, and it is genuinely good. Its POUR structure (Perceivable, Operable, Understandable, Robust) gives a coherent framework. Its conformance levels — A, AA, and AAA — let regulators set enforceable targets. Most jurisdictions and legal standards (the EU Accessibility Act, ADA technical guidance, Section 508) reference WCAG 2.1 AA or 2.2 AA.

But the binary model has long frustrated practitioners. Here is why:

  • A product with 300 passing criteria and 1 minor failure is legally “non-conformant” — the same verdict as a product that ignores accessibility entirely.
  • Some Success Criteria were written around the technical limits of a specific moment. The now-removed 4.1.1 Parsing criterion, for example, was largely about XML parsing quirks in early 2000s browsers.
  • Binary pass/fail cannot express quality. A 3:1 contrast ratio technically passes for large text at AA. A 7:1 ratio for the same element is meaningfully better. The standard has no way to say that.
  • Outcomes for actual users get lost. A product could pass every WCAG 2.2 criterion mechanically while still being functionally unusable for screen reader users. The standard evaluates implementations, not user outcomes.

WCAG 3.0 (officially called “W3C Accessibility Guidelines 3.0,” to widen its scope beyond web content) is the W3C’s multi-year effort to fix these structural problems.

Where WCAG 3.0 Actually Stands in 2026

The timeline has been long. The W3C Accessibility Guidelines Working Group (AG WG) published the first public Working Draft in January 2021. Multiple revised drafts have followed, but significant portions of the spec remain unresolved — particularly the conformance model and the scoring methodology.

Here is where things stand at mid-2026:

MilestoneStatus (mid-2026)
First Public Working DraftPublished January 2021
Revised Working DraftsMultiple published 2021–2025
Candidate RecommendationNot yet reached
Proposed RecommendationNot yet reached
W3C Recommendation (final)No target date confirmed

The AG WG has been clear that WCAG 3.0 is not intended to replace WCAG 2.x immediately. The two are expected to coexist for an extended period — similar to how WCAG 2.0 and 2.1 overlap today. Once finalized, most jurisdictions will need a multi-year transition window before legal adoption.

The Scoring Model: From Binary to Graduated

The most consequential proposal in WCAG 3.0 is the shift from pass/fail criteria to a bronze/silver/gold conformance model, combined with per-outcome scoring at the guideline and outcome levels.

Guidelines and Outcomes Replace Success Criteria

WCAG 3.0 restructures the testable units. Instead of Success Criteria, it proposes three layers:

  • Guidelines — high-level accessibility goals (similar to WCAG 2.x’s principles and guidelines)
  • Outcomes — specific, testable results within each guideline. These are similar to Success Criteria, but authored around what the user can accomplish, not what the technology must implement.
  • Methods — technique-level documentation explaining how to achieve each outcome in specific technologies

This is a meaningful shift in framing. An outcome like “Users can perceive all text content” focuses on the user experience. A Success Criterion like “1.4.3 Contrast (Minimum): Text must have a contrast ratio of at least 4.5:1” focuses on a technical measurement. Outcome-based framing makes it harder to “pass” technically while failing practically.

The Bronze/Silver/Gold Levels

The proposed conformance model works like this:

  • Bronze — the accessibility floor. Roughly equivalent in scope to WCAG 2.x AA. A product reaches Bronze by meeting the foundational set of outcomes at a threshold score. This is the level expected to be cited in legal standards when WCAG 3.0 is eventually adopted.
  • Silver — a more comprehensive threshold. Silver requires meeting a wider set of outcomes, including some with no direct WCAG 2.x equivalent — particularly around cognitive accessibility, plain language, and user testing with people with disabilities.
  • Gold — the aspirational standard. Gold adds requirements for organizational processes: documented accessibility testing programs, user research with disabled participants, and ongoing monitoring. Gold is not just about the product — it is about the practice behind it.

Scoring Within Levels

Within each level, the model proposes aggregating scores across outcomes. An outcome might be scored on a quality scale, not just pass/fail. Different outcomes carry different weights based on their impact on users.

This is the most technically unsettled part of WCAG 3.0. The specific weighting methodology — and how scores aggregate across different disability categories — has been actively debated in every working draft.

APCA and the Contrast Rethink

One of the most discussed technical proposals in WCAG 3.0 is the Advanced Perceptual Contrast Algorithm (APCA), developed by Myndex Research. APCA replaces the WCAG 2.x contrast ratio formula (based on a 1988 ANSI standard for CRT monitors) with a perceptually accurate model. It accounts for text size, font weight, and the spatial frequency of letter strokes.

In practice, APCA produces results that can feel counterintuitive compared to WCAG 2.x:

  • A 400-weight body font at 16px needs a different contrast threshold than a 700-weight heading at 24px. APCA accounts for this; the 2.x formula does not.
  • Some combinations that “fail” WCAG 2.x — medium contrast for large, heavy type — are judged readable by APCA. Some that “pass” WCAG 2.x — very thin hairline fonts at mid-contrast — are judged unreadable.

The critical caution for practitioners: APCA is not a current requirement. It is a research direction being evaluated for WCAG 3.0. As of 2026, treat it as a supplementary perceptual-quality lens. It is useful for understanding why a particular text combination may feel hard to read despite technically passing WCAG 2.x contrast. But it does not replace the WCAG 2.2 AA 4.5:1 requirement, which remains the legal standard.

Do

  • Target WCAG 2.2 AA for all production work and legal compliance today.
  • Use APCA as a supplementary tool to understand perceptual quality — especially when evaluating large, heavy display text or very thin body text.
  • Stay informed on WCAG 3.0 Working Drafts; track changes in the conformance model so you can plan ahead.
  • Discuss WCAG 3.0’s direction with clients as a forward-looking roadmap, not a current requirement.
  • When evaluating contrast for thin or large text, layer WCAG 2.2 results with APCA’s Lc value as a richer design signal.

Don't

  • Claim WCAG 3.0 compliance in audits, legal filings, or client reports — it is not an adopted standard.
  • Treat APCA as a replacement for WCAG 2.2 contrast requirements and use it to justify failing combinations.
  • Target WCAG 2.0 instead of 2.2 — the newer criteria (focus not obscured, target size, accessible auth) are legally relevant in growing jurisdictions.
  • Tell clients that WCAG 3.0 “will fix” the limitations of 2.x on a near-term timeline — no adoption date is set.
  • Remove the WCAG 2.2 4.1.1 Parsing criterion from checklists without noting it only applies to WCAG 2.2 (it was removed there, not in 2.1 or 2.0).

What Is Actually Different About WCAG 3.0’s Scope

Beyond the scoring model, WCAG 3.0 proposes meaningful expansions in what the standard covers.

Cognitive Accessibility Gets First-Class Treatment

WCAG 2.x’s coverage of cognitive accessibility has been widely criticized as sparse. Most of the cognitively relevant criteria sit in Level AAA — the “aspirational” tier that most products never target. WCAG 3.0 incorporates substantial input from the W3C Cognitive Accessibility (COGA) Task Force and promotes cognitive outcomes into the foundational layer.

Practical examples of what COGA has pushed into early WCAG 3.0 drafts: content must be available in plain language, navigation must be predictable, and authentication flows must not rely on cognitive function tests (memory, transcription, puzzle-solving) as the only path. That last point already appears in WCAG 2.2’s new 3.3.8 criterion — a direct example of WCAG 3.0 research influencing 2.x before 3.0 is even finalized.

User Testing as a Conformance Signal

Gold-level conformance in the proposed model requires evidence from actual testing with users with disabilities — not just automated checks or expert audits. This is a philosophical shift from “does the code satisfy the rule” to “can the people the standard is written for actually use this.”

It also creates new organizational challenges. Recruiting, compensating, and building ongoing relationships with disabled testers requires institutional commitment, not just engineering effort.

Platform-Neutral Framing

WCAG 2.x was written for web content. WCAG 3.0 explicitly aims to cover mobile apps, native software, voice interfaces, and emerging platforms (XR, conversational AI). This has complicated the spec’s authoring — technology-specific guidance that works for HTML forms may be nonsensical for a voice interface.

Practical Implications for Teams Working Today

WCAG 3.0 is not adopted and has no firm adoption timeline. So what should practitioners actually do right now?

  1. Maintain WCAG 2.2 AA as your non-negotiable baseline. This is the current legal standard in the EU (the EAA mandated compliance by June 2025), the US (ADA and Section 508 guidance), and most other jurisdictions. Do not let WCAG 3.0 discussions create a false impression that the current standard is “about to be replaced” and therefore less urgent.

  2. Use WCAG 3.0 vocabulary to guide design intent. The outcome-oriented framing — “can this user accomplish this task?” — is a better design test than binary criteria-checking. Run informal outcome-based evaluations alongside formal WCAG 2.2 audits.

  3. Invest in cognitive accessibility now. COGA outcomes are likely to become baseline requirements when WCAG 3.0 is adopted. Plain language, predictable navigation, and authentication flows that don’t require memory are improvements that cost little and benefit users broadly.

  4. Build user testing programs with disabled participants. Whatever score-weighting the final standard adopts, the direction toward outcome-based validation is clear. Teams with established relationships with disabled testers will be better positioned than those who rely entirely on automated tools. Automated tools catch roughly 30–40% of WCAG issues — the rest require human judgment.

  5. Watch the Working Drafts, particularly the conformance model sections. The AG WG posts updates publicly. The most unstable parts of the spec are the scoring and weighting methodology and the Gold-level organizational requirements. These will shape what legal adoption looks like when it arrives.

Reading the Spec Critically

WCAG 3.0 Working Drafts are published at w3.org/TR/wcag-3.0/. When reading them, keep a few things in mind:

  • Sections marked “Note” or “Issue” reflect unresolved editorial decisions — not settled guidance.
  • The draft is structured in layers: normative requirements (what products must do), informative notes (context and explanation), and methods (technique-level how-to). Only normative text creates actual conformance obligations.
  • The working group actively solicits feedback. If a draft contains a direction that would create real-world implementation problems, the GitHub issues tracker for the AG WG is the right place to comment.
  • W3C Recommendations take many years from first public draft to legal adoption. The WCAG 2.0-to-2.1 transition took a decade to fully propagate into legal standards. Plan accordingly.