Your compliance team is making decisions about WCAG 3 right now, whether you realize it or not. Every time someone asks, "Should we wait for WCAG 3?" or "Does this mean WCAG 2.2 is obsolete?", you're shaping your accessibility roadmap based on assumptions about what's coming.
The problem: most of those assumptions are wrong.
The W3C Accessibility Guidelines Working Group draft introduces a fundamentally different conformance model. But misconceptions about what WCAG 3 actually changes have already taken root in compliance planning discussions. Here's what you need to know before your next budget cycle.
Myth 1: WCAG 3 Replaces WCAG 2.2 Success Criteria
Reality: WCAG 3's core requirements build directly on WCAG 2.2 Level A and AA success criteria. The draft doesn't discard the success criteria framework. It consolidates Level A and AA into a single conformance level called "core requirements" and adds structured ways to go beyond that baseline.
If you're treating WCAG 2.2 conformance work as throwaway effort, you're wasting budget. Every success criterion you address now carries forward. The shift isn't about rewriting your accessibility program from scratch. It's about how conformance gets measured and reported.
For compliance officers, this means your current WCAG 2.2 implementation work remains valid. The core requirements establish a baseline that policymakers can reference in regulations. What changes is the structure around that baseline: supplemental requirements, assertions, and practices that address areas difficult to measure objectively.
Myth 2: WCAG 3 Makes Compliance Easier by Lowering the Bar
Reality: WCAG 3 introduces reporting tiers designed to encourage accessibility beyond minimum conformance. The new model doesn't reduce requirements. It creates a clearer separation between what's measurable enough to enforce and what requires context-specific judgment.
Consider sign language interpretation. Some users need sign language more than text. But requiring sign language for all content isn't practical: it's expensive, signers are limited, and multiple sign languages exist even within English-speaking regions. WCAG 3 addresses this by including sign language as a supplemental requirement rather than a core conformance criterion, while maintaining the requirement that all auditory information be available as text.
This distinction matters for your risk assessment. Core requirements give you an enforceable floor. Supplemental requirements, assertions, and practices give you a framework for exceeding that floor where it matters most to your user base. If you're planning to do the minimum, WCAG 3 won't make your job easier. It will make your gaps more visible.
Myth 3: The New Tag System Is Just for Regulators
Reality: Tags serve two distinct functions. Yes, regulators can use tags to define policies that include or exclude specific requirements for different situations. But organizations can also use tags to report progress toward conformance and demonstrate accessibility beyond core requirements.
This dual purpose creates strategic opportunities your team should map now. Tags let you differentiate your accessibility posture in ways WCAG 2.x conformance claims don't support. You can report that you meet core requirements plus specific supplemental requirements relevant to your sector or user base.
For procurement teams, this changes how you evaluate vendor accessibility claims. A supplier reporting WCAG 3 core conformance plus tags for supplemental requirements in authentication and error handling tells you more than a binary "WCAG 2.2 AA conformant" statement. Your Accessibility Conformance Reports will need to account for this granularity.
The tag system also gives policymakers flexibility to calibrate requirements. Essential government services might require more tags than a small business website. If you operate across multiple jurisdictions, expect different tag combinations in different regulations. Your compliance matrix just got more complex, not simpler.
Myth 4: WCAG 3 Solves the Context Problem
Reality: WCAG 3 acknowledges context matters but doesn't eliminate the need for judgment. The Working Group spent years exploring ways to address context-dependent accessibility needs within a standard that regulators can enforce. The draft addresses this by moving context-heavy requirements out of core conformance and into supplemental categories.
But you still need to evaluate context. An accessibility barrier in a form for paying community chorus dues carries different risk than the same barrier in a medical treatment application form. WCAG 3 doesn't automate that risk assessment for you.
What WCAG 3 does provide is structure for documenting how you address context-specific needs. Assertions let you state your accessibility approach in areas that can't be objectively measured. Practices give you a framework for going beyond enforceable requirements. But your compliance team still owns the analysis of which supplemental requirements and practices apply to your digital properties.
Myth 5: You Should Wait for WCAG 3 to Finalize Before Planning
Reality: The fundamentals are clear enough to inform your roadmap now. WCAG 3 will build on WCAG 2.2 Level A and AA. It will provide a single core conformance level. It will offer structured ways to exceed that baseline. The details will evolve, but those structural decisions are stable.
Waiting for final publication means you're not preparing for the reporting tier model. You're not mapping which supplemental requirements align with your user needs. You're not evaluating how tags might affect your multi-jurisdiction compliance strategy.
The Working Group continues refining the approach, and they want constructive input. But the draft represents a fundamental shift in conformance philosophy. If your accessibility governance program doesn't account for reporting beyond binary conformance, you're already behind.
What to Do Instead
Stop treating WCAG 3 as a distant future problem. Map your current WCAG 2.2 Level A and AA gaps. That work carries forward as core requirements. Identify which supplemental requirements from the draft align with your user base and risk profile. Evaluate your Accessibility Conformance Report template: does it support reporting tiers and tags?
Most importantly, recognize that WCAG 3 reinforces a principle your team should already follow: meeting minimum conformance requirements isn't the goal. Accessible user experiences are the goal. WCAG is the measurement tool, not the destination.
The draft gives you a framework for documenting progress toward that goal and demonstrating accessibility beyond enforceable minimums. Use it.
