"Let's just wait for WCAG 3.0."
That line showed up in a product team's Slack channel this spring, right after the news broke that the W3C had published a fresh WCAG 3.0 Working Draft. The logic sounded reasonable enough: a whole new standard, with a different scoring model and broader scope, was apparently on the way. Why sink a quarter of engineering time into remediating against version 2.2 if version 3.0 is about to make the current rulebook obsolete?
It is a comfortable thing to believe, and it is also the wrong question. If your 2026 roadmap treats WCAG 3.0 as close enough to plan around, you are planning around a standard that will not be legally referenced anywhere for years, possibly not until the next decade.
Here is what actually changed between 2.1 and 2.2, what 3.0 is trying to do differently, the real timeline behind it, and the roadmap we would build if we were sitting in that Slack channel with you.
The Stat: The W3C published an updated WCAG 3.0 Working Draft in March 2026; a Candidate Recommendation isn't expected before roughly Q4 2027, and a final Recommendation is not expected before 2028. (Source: W3C, WCAG 3 Working Draft, March 2026)
Why "wait for 3.0" is the wrong question
Every conformance obligation your legal team currently cares about, whether it comes up in ADA-related litigation, in a VPAT a procurement officer is scrutinizing, or in the European Accessibility Act, points back to WCAG 2.x. Not 3.0. Nothing in force today asks for it, and nothing will until it clears a Candidate Recommendation stage that is not expected until around Q4 2027, followed by a final Recommendation that is not expected before 2028.
Put plainly: a product team that "waits for 3.0" is not deferring a decision, it is opting out of accessibility work for at least two more product cycles, on the hope that a standard still being drafted will somehow retroactively make that gap acceptable. It will not. If your product ships to users, gets procured by an enterprise buyer, or operates in a regulated market between now and 2028, WCAG 2.2 is the yardstick you are measured against, full stop.
If you want the fuller picture of how WCAG fits alongside the ADA, the EAA, and EN 301 549, our acronym decoder for founders walks through how those pieces connect, and it pairs naturally with the version history below.
A quick refresher: how we got from 2.0 to 2.2
WCAG 2.0 shipped in 2008 and set the pattern still in use today: four principles (perceivable, operable, understandable, robust), organized into success criteria at levels A, AA, and AAA. WCAG 2.1, published in 2018, layered in criteria aimed at mobile interactions, low vision, and cognitive and learning disabilities, without touching the underlying structure. It is still, in many jurisdictions, the exact version named in law and regulation, which is why we call it the current legal baseline in the timeline above.
WCAG 2.2 followed in October 2023. It is not a rewrite. It is an incremental, backward-compatible update, and it is the version any serious product team should be building against right now.
What actually changed in WCAG 2.2
Two things happened in this release, and both matter for how you scope a remediation project:
- Nine new success criteria were added, covering things like keyboard focus visibility (Focus Not Obscured, at both a minimum and enhanced level, plus Focus Appearance), interactions that rely on dragging (Dragging Movements), minimum tap target sizing (Target Size, Minimum), consistency of help mechanisms across a site (Consistent Help), not making users re-enter information they already gave you (Redundant Entry), and accessible authentication that does not depend purely on a cognitive test like solving a puzzle or transcribing a code (Accessible Authentication, at minimum and enhanced levels).
- One older success criterion was removed. Success Criterion 4.1.1 Parsing, which dealt with malformed HTML markup, was dropped because modern browsers and assistive technology are robust enough that the criterion had become largely redundant with other robustness checks.
None of that is exotic. It is mostly the kind of thing a competent front-end team can fix once it is flagged: focus rings that do not get hidden behind sticky headers, tap targets that are not too small on mobile, login flows that offer an alternative to a pure memory-and-transcription challenge. The gap between "WCAG 2.1 compliant" and "WCAG 2.2 compliant" is real but narrow, which is exactly why it makes no sense to sit on your hands and hold out for 3.0 instead of closing it.
What WCAG 3.0 is actually trying to fix
WCAG 3.0 (developed for years under the project name Silver before adopting its current number) is not an incremental update like 2.1 or 2.2 were. It is a structural rework of how conformance itself gets measured. The long-standing complaint about the 2.x series is that a single binary pass or fail per success criterion does not capture how usable something actually is for a disabled person, and does not scale well to newer surfaces like native apps, voice interfaces, or complex interactive tools. WCAG 3.0's draft direction leans toward a broader, outcomes-based model, wider coverage of cognitive and low-vision needs, and testing methods that combine automated checks with structured human judgment rather than relying on a single automated scan.
That is a genuinely bigger undertaking than anything the 2.x series attempted, which is a large part of why it is taking years rather than months to work through the W3C's standards process. The W3C's own announcement of the March 2026 update is worth reading directly if you want the primary source rather than secondhand summaries, because a Working Draft is explicitly a working document, not a stable target to build a compliance program against.
The realistic timeline, mapped against your product calendar
Here is what the dates in the diagram above actually mean for planning purposes. A Working Draft, which is where WCAG 3.0 sits as of March 2026, is a snapshot of ongoing work that the W3C expects to keep changing, sometimes substantially, as public and member feedback comes in. A Candidate Recommendation, the next major milestone, is not expected before roughly the fourth quarter of 2027, and that stage exists specifically to test whether the guidelines are actually implementable at scale, which historically triggers further revision. Only after that does a final Recommendation get published, and the W3C is not projecting that before 2028.
If you are planning a product roadmap in September 2026, that means WCAG 3.0 will not be a stable, citable, adoptable standard for at least two more full product years, and likely longer once you account for how long it typically takes regulators and procurement frameworks to reference a brand-new W3C Recommendation after it ships. WCAG 2.2 will still be the operative standard through all of that.
A practical 2026 roadmap for product teams
Given all of that, here is the roadmap we would actually recommend, in order:
- Set WCAG 2.2 Level AA as your baseline today, not as an aspirational future state. If your current target documentation still says "2.1," that is the first thing to update.
- Prioritize the nine new WCAG 2.2 criteria in your next sprint planning cycle. Focus visibility, target sizing, and authentication flows are usually the fastest wins because they tend to live in a small number of shared components (buttons, form fields, the login screen) rather than being scattered across every page.
- Build accessibility checks into your CI pipeline and design review process, not just into a once-a-year audit. Standards keep incrementing; a one-time fix decays as new features ship.
- Assign a named owner for accessibility conformance, even if that is a fractional responsibility layered onto an existing product or engineering lead. Standards without owners do not get maintained.
- Treat WCAG 3.0 as a watch item, not a work item, until it reaches Candidate Recommendation. Read the drafts if you are curious, but do not restructure your compliance program around a moving target.
- Get an independent read on where you actually stand against 2.2 right now. Most teams are surprised by how much of the gap is concentrated in a handful of components. A free WCAG audit is the fastest way to find out exactly where those gaps are before they show up in a legal complaint or a lost enterprise deal.
For the primary spec text itself, the current WCAG 2.2 Recommendation is publicly available on the W3C's site, and the WAI's standards and guidelines overview is the best single page for understanding how the whole family of guidelines, from 2.0 through the 3.0 drafts, fits together.
The bottom line
WCAG 3.0 is real, it is being worked on seriously, and it will eventually matter. But "eventually" here means 2028 at the earliest for a final Recommendation, with adoption into law and procurement standards taking longer still. WCAG 2.2 is not a placeholder you can skip past. It is the standard your users, your auditors, and your legal exposure are measured against right now, in 2026, and it will remain so for the rest of this roadmap cycle and probably the next one too.
If your team is having the same Slack debate we described at the top of this piece, the fastest way to end it is with data instead of speculation. Email experts@wcag.world to talk to a person on our team, or start with a free WCAG audit and get a concrete list of what actually needs fixing under the standard that applies to you today.