WCAG 3.0 Will Create a Governance Problem Most Organizations Aren't Ready For

When WCAG 3.0 eventually becomes a W3C Recommendation, many executives will assume their accessibility program has to change right away. The more likely truth is that it can keep running as it is, while something subtler shifts underneath it.

What changes is the bookkeeping. For the first time, many organizations will have to manage two accessibility standards at once, because the newest standard will not be the one they are legally required to follow. The gap between those two realities is where the confusion starts.

When WCAG 3.0 is published, almost every regulation, contract, procurement rule, and legal obligation around the world will still point at WCAG 2.x. That leaves the people who run accessibility programs with a question that has nothing to do with testing: how do you manage accessibility when the direction of the field and the required standard stop being the same thing? Very few organizations are ready to answer it.

Why this version is different

The last few WCAG updates were easy to absorb. Going from 2.0 to 2.1, and again from 2.1 to 2.2, added new success criteria to a familiar structure. The conformance model stayed the same. Teams could update their testing without rethinking how they evaluated anything.

WCAG 3.0 is a bigger change. The March 2026 working draft replaces the pass/fail success criteria with roughly 174 requirements written as outcome statements, scored on a graded model that rolls up into Bronze, Silver, and Gold instead of A, AA, and AAA. Bronze is meant to land close to today’s 2.2 AA. The scope widens too, reaching past web pages to apps, components, and immersive environments, which is why the acronym now stands for W3C Accessibility Guidelines rather than Web Content Accessibility Guidelines.

The structural change is not the hard part, though. Accessibility programs are built out of policies, contracts, procurement language, reporting, risk practices, and legal obligations, and all of that has spent more than twenty years inside the 2.x model. Learning the new standard is straightforward. The real job is operational: carrying an organization through the years when both standards are in play at once.

The two-timeline problem

Many people assume standards and regulations move together. They don’t. A W3C Recommendation becomes official when the W3C finishes its process. Regulations change when governments and regulators finish theirs. Those clocks are almost never in sync.

You can already see the divergence today. In the United States, Section 508 still references WCAG 2.0 A and AA. The Department of Justice’s Title II rule requires WCAG 2.1 AA for state and local government. In Europe, the Accessibility Act relies on EN 301 549, which is also built on WCAG 2.1, while newer standards are beginning to reference WCAG 2.2. Different regulations already point at different versions, and none of them will move to WCAG 3.0 on their own when it becomes a Recommendation.

The likely path is a transition measured in years. Candidate Recommendation for 3.0 is currently projected for late 2027, a final Recommendation is not expected before 2028. Plenty of knowledgeable people in the field expect it much later than that. Regulatory adoption trails by years more. WCAG 2 will stay in force for a long stretch after 3.0 is done. Through that whole period, anyone running a program has to hold two answers at once: what represents the current direction of the field, and what the organization is actually required to meet. For most of the last twenty years those answers matched. They are about to come apart, and the teams that miss the distinction will set the wrong expectations and spend against the wrong priorities.

The real risk is internal confusion

Picture a familiar conversation. A senior leader reads that WCAG 3.0 has been published and asks whether the organization complies with it. The accessibility team says it complies with whatever the applicable regulations reference. Then why aren’t we on the newest standard? Because regulators haven’t adopted it yet. So are we behind?

None of those are bad questions. They are just hard to answer cleanly if the organization has never drawn the line between meeting a legal requirement and tracking where the field is heading. The teams that come through this well will have settled their position before the conversation happens. They’ll be able to say plainly which standards they are required to meet, which ones they are watching or adopting voluntarily, how they evaluate a new standard, and what would trigger a change to their internal requirements. Without that, every vendor pitch, conference talk, and industry article becomes one more thing to argue about.

Vendor claims get harder to read

Some vendors are already getting ready for 3.0. Before long you’ll hear that a platform is “WCAG 3.0 ready,” “supports Bronze,” or “assesses against 3.0.” Some of those claims will be meaningful. Plenty others will be pure marketing. Almost none of them speak to the thing you need answered: does this help us meet the obligations we have right now?

Buying a product because it advertises “WCAG 3.0 readiness” can increase your risk if your legal obligations are still tied to WCAG 2.x.

A product can line up with parts of 3.0 and still miss requirements tied to 2.x, and the reverse happens too. Accessibility maturity and regulatory compliance are related, but they are not the same thing, and treating them as interchangeable is how teams talk themselves into risk.

Procurement teams face the same challenge. Once 3.0 exists alongside regulations still built on 2.x, different buyers will start asking vendors for inconsistent evidence and evaluating products against different targets unless the organization has clear guidance. That consistency has to come from policy, not from whoever happens to be reviewing the contract that week.

Why assertions are worth watching

One part of 3.0 deserves attention from anyone who owns this work. Alongside technical requirements, the draft includes assertions: claims about how an organization works rather than how a given page tests. They look at whether staff are trained, whether accessibility is built into development from the start, and whether issues get tracked with any consistency. Mostly they ask whether anyone owns the work at all.

Those are governance questions. Most organizations still treat accessibility as an audit: test now and then, fix what breaks, file a report. Assertions point somewhere else, toward showing that accessibility is part of how the work gets done rather than something measured after the fact. The exact shape of this in the final standard may shift, but the direction is clear, and teams that build those habits now benefit no matter when regulators catch up.

What to do now

There is no need to rebuild anything around 3.0 today. It is still a draft, the details will move, and adoption is years out. What is worth doing now is quieter, and it lives in your own policies rather than in the standard.

Make sure leadership knows a transition period is coming and understands the difference between meeting a legal requirement and following where the field is going. Look at how your policies, contracts, procurement processes, and governance documents define accessibility, and whether they pin it to a version in a way that will age badly. Check whether accessibility is written down anywhere as an organizational practice or only ever measured as a technical result. And get your program ready to explain its decisions, not just hand over test results.

The organizations that handle this well will be the ones that can say, without hesitating, which standards they are required to meet, which ones they are only watching, and what would make them change their mind. That clarity is the whole advantage.