For years, web accessibility compliance felt like a binary judgment: your site passed WCAG 2.x or it didn't. Attorneys and auditors treated it that way. So did most automated checkers. WCAG 3.0 is about to change that fundamentally — and not everyone in the accessibility world is happy about it. The W3C's Web Accessibility Guidelines 3.0 (officially called W3C Accessibility Guidelines, dropping the "Web Content" scope entirely) has been in development since 2021. As of 2026, it remains in Working Draft status, but the architectural decisions are largely settled. If your organization invests in accessibility compliance, you need to understand what's coming — even if WCAG 2.2 is still the legal standard today.
Why WCAG 3.0 is a bigger shift than 2.0 to 2.2
The jump from WCAG 2.0 to 2.1 to 2.2 was incremental — new success criteria added to the same structure, the same A/AA/AAA tier system, the same pass/fail approach. WCAG 3.0 isn't incremental. It's a different model entirely.
Think about what the current system actually does: you either meet a criterion or you don't. Contrast ratio below 4.5:1? Fail. Missing alt text? Fail. It's a litigation-friendly framework, which is partly why the U.S. legal community latched onto it so firmly. But it's also a framework that treats a barely-passing 4.51:1 contrast ratio the same as a crisp 10:1 — which is obviously not what serves users with visual impairments.
WCAG 3.0 replaces this with a graduated scoring system. Outcomes are rated Bronze, Silver, and Gold. A site can achieve a Bronze rating even with some failures, as long as the overall accessibility experience reaches a threshold. This is more representative of reality — almost no real website is 100% compliant, and almost no real website is completely inaccessible. But it introduces complexity that WCAG 2.x deliberately avoided.
Whether this is better depends on what you're optimizing for. For users with disabilities? Almost certainly yes. For legal clarity? It's genuinely messier. Expect the transition period to be turbulent for organizations doing accessibility primarily for compliance rather than genuine user experience. Check the current state of ADA website compliance in 2026 to understand the legal landscape you're navigating in parallel.
The new scoring model: Bronze, Silver, Gold
Here's the structure as it currently stands in the Working Draft:
Bronze is the baseline — roughly equivalent to what WCAG 2.x Level AA was trying to achieve. To reach Bronze, you must meet a set of "critical" outcomes (hard requirements with no scoring flexibility) plus achieve a minimum average score across other guidelines.
Silver requires a higher average score and conformance with more guidelines. It represents genuinely good accessibility, not minimum-bar compliance.
Gold is aspirational — thorough accessibility across all guidelines, including ones targeting cognitive disabilities, low vision, and complex interaction patterns. Few commercial websites will achieve Gold immediately, and that's by design.
The critical outcomes — the ones that must be met regardless of score — currently include things like: keyboard accessibility for all functionality, no content that causes seizures, text alternatives for all non-text content, and captions for pre-recorded video. These aren't new requirements; they're the things WCAG 2.x already required at level A. The continuity is intentional.
For teams currently doing WCAG 2.2 compliance work, the critical outcomes will feel familiar. The work you've already done isn't wasted — it's the foundation.
APCA: the most controversial change
The Advanced Perceptual Contrast Algorithm (APCA) is replacing the existing contrast ratio formula, and it's worth understanding why — because the current formula is genuinely flawed in ways that matter to users.
The current WCAG 2.x contrast ratio calculation (based on relative luminance) treats all color combinations as perceptually equivalent if they hit the same numerical ratio. It doesn't account for font weight, font size, or the specific way human vision processes different color combinations. A light gray text on white and a dark navy on white might have the same calculated contrast ratio but produce dramatically different legibility experiences for someone with low contrast sensitivity.
APCA measures contrast in terms of perceived lightness difference, weighted by font size and weight. A larger, bolder font needs less contrast to be readable than small body text. This matches how typography actually works.
The controversy: APCA scores aren't backwards-compatible with WCAG 2.x numbers. A color combination that passes today might fail APCA, and vice versa. For organizations that have carefully audited their color systems against WCAG 2.x thresholds, this means re-auditing. Our detailed color contrast guide covers both the current 4.5:1 standard and how APCA calculates differently — worth reading if you're doing design system work.
Practically: don't panic and start changing your color palette immediately. WCAG 2.2 remains the current standard. But if you're doing a major design system refresh in 2026, consider testing against APCA now. The accessibility checker tool can help you evaluate your current color combinations against both standards.
New guidelines covering cognitive accessibility
WCAG 2.x was primarily built around sensory and motor disabilities: blindness, low vision, deafness, mobility impairment. It did relatively little for users with cognitive disabilities — ADHD, dyslexia, memory impairments, anxiety disorders. These represent a large and often-overlooked user population.
WCAG 3.0 adds substantive guidelines in this area:
- Clear language — guidance on reading level, plain language requirements, and terminology consistency. The draft references Flesch-Kincaid readability scores as one indicator.
- Findable help — documentation and help resources must be consistently located and labeled.
- Redundant entry prevention — forms shouldn't ask users to re-enter information they've already provided in the same session (this one is already in WCAG 2.2 as SC 3.3.7).
- Consistent navigation and identification — elements that appear on multiple pages must look and behave consistently. Already in WCAG 2.x as success criteria; WCAG 3.0 expands the scope.
- Error prevention and recovery — extended guidance beyond WCAG 2.x's existing criteria, with particular attention to financial and legal transactions.
These cognitive accessibility requirements are where WCAG 3.0 will require genuine new work for most organizations. If you haven't considered cognitive load in your UX design process, now's the time to start. The comprehensive accessibility audit guide covers how to assess cognitive accessibility alongside the technical criteria.
What stays the same (more than you might think)
All the core principles from WCAG 2.x — Perceivable, Operable, Understandable, Robust — carry forward. The specific techniques don't disappear. Alt text, keyboard navigation, ARIA roles and labels, captions — all of these remain requirements. The technical work isn't being discarded.
ARIA implementation guidance gets more specific in WCAG 3.0, not looser. If you've been doing ARIA label best practices correctly under WCAG 2.x, you'll be in a strong position.
Mobile accessibility, which WCAG 2.1 addressed with new criteria (1.3.4 Orientation, 2.5.1-2.5.4), continues to be a focus area. WCAG 3.0 doesn't reduce mobile requirements.
Section 508 compliance for federal agencies and contractors is a separate question — the Revised Section 508 Standards reference WCAG 2.0 Level AA, and any update to reference WCAG 3.0 would require a separate rulemaking process. Organizations doing Section 508 compliance shouldn't assume WCAG 3.0 timelines align with federal procurement requirements.
Timeline and legal status: what to actually expect
WCAG 3.0 is still a Working Draft in 2026. The W3C process for finalizing a standard — particularly one this significant — is long. Realistically:
- 2026–2027: WCAG 3.0 reaches Candidate Recommendation. Still not finalized, but stable enough for early adoption work.
- 2027–2028: Proposed Recommendation and final W3C Recommendation. This is when you'd expect WCAG 3.0 to be considered "official."
- 2028–2030: Regulatory adoption begins. EU's European Accessibility Act (enforcement from 2025) currently references EN 301 549 / WCAG 2.1. Updating to WCAG 3.0 would require updated technical standards — a 2–4 year process after finalization.
- ADA litigation: U.S. courts will continue to use WCAG 2.x as the benchmark for years after WCAG 3.0 is finalized. Legal standards lag technical standards by design.
The practical implication: WCAG 2.2 Level AA remains your compliance target today. WCAG 3.0 is where you invest forward-looking design decisions and accessibility strategy.
How to prepare right now
You don't need to rebuild your site for WCAG 3.0 today. But there are concrete steps that move you in the right direction without wasting effort:
- Achieve solid WCAG 2.2 AA conformance — this is still the legal standard and forms the foundation for everything in WCAG 3.0. Run a thorough audit using the free accessibility checker tool to identify current gaps.
- Document your color system against APCA — not to change it immediately, but to understand the delta between your current palette and APCA thresholds. This informs your next design system iteration.
- Start cognitive accessibility testing — recruit users with cognitive disabilities for usability testing. This is the area where most organizations have no baseline, and WCAG 3.0 will require real evidence of effectiveness.
- Review your ARIA implementation — WCAG 3.0 increases specificity on interactive components. Audit your custom components against the ARIA Authoring Practices Guide now.
- Build an accessibility roadmap — organizations that treat accessibility as a quarterly initiative rather than a compliance checkbox will be much better positioned when WCAG 3.0 becomes enforceable.
The teams who will struggle most with WCAG 3.0 are those doing the bare minimum to avoid litigation under WCAG 2.x. The teams who will adapt easily are those who've already internalized accessibility as a design value rather than a legal obligation.