Good News About WCAG 3.0: What’s New in the Latest Draft, and Why We Like Where It’s Headed

I wrote about WCAG 3.0 in December 2024, when it still felt more like a rumor than a real document. The W3C just put out a fresh working draft on September 10, and there’s enough new in it that I think it’s worth a real update instead of a “still cooking” postscript.

Quick disclaimer before I get into it. This is still a working draft. That means it still is NOT a finished standard, and nothing in here changes what you’re legally on the hook for right now. If you’re a public agency working toward ADA Title II, your target is still WCAG 2.1 AA. Keep that Handbook open on your desk. WCAG 3.0 is the horizon, not the deadline. More on that at the end.

Okay, with that out of the way, let’s get into what’s new.

A quick refresher, for anyone who skipped 2024

WCAG 3.0 is the next generation of the W3C’s accessibility guidelines, and it’s such a departure from what came before that the acronym itself changed meaning. WCAG used to stand for Web Content Accessibility Guidelines. Now it stands for W3C Accessibility Guidelines, because the scope isn’t just web pages anymore. It’s meant to cover mobile apps, PDFs and other documents, software, and newer stuff like AR and VR interfaces too.

If you want the full basics on what WCAG is and how the current 2.x version works, I’ve got that covered in an earlier explainer. This post assumes you already know roughly what WCAG is and just want to know what’s changing.

This is especially meaningful because we have often told clients that WCAG 2.1 isn’t perfect. It’s geared more towards websites than PDFs and does not address cognitive limitations or color contrast well. It’s nice to see these being addressed in WCAG 3.0.

What’s actually in the September draft

The working group did two things in this release. First, they moved a batch of guidelines and requirements further along in the development process, from early exploratory ideas into what they call “Developing” status, meaning they’re stable enough to be worth public comment. Second, and this is the bigger one, they published a more developed version of the proposed conformance model and are asking the public directly what they think of it.

That second part matters because conformance is where WCAG 3.0 breaks most sharply from the version most of us grew up on.

The real shift: how you’ll measure conformance

Under WCAG 2.x, there are success criteria; each one gets a pass or fail, and you land at Level A, AA, or AAA depending on how many you clear. It’s a clean system. It’s also a rigid one, and it’s part of why AAA has turned into the tier almost nobody actually reaches, even organizations that genuinely care about this stuff. 2.x also limited our ability to include AAA levels into VPAT/ACRs.

WCAG 3.0 throws that model out and replaces it with something layered:

Guidelines are outcome statements, phrased around a real user need rather than a specific technical fix. Under each guideline sit Requirements, which are the testable parts, split into Core (the baseline, expected of any conformance claim) and Supplemental (additional practices beyond the baseline). Alongside those are Assertions, which let an organization document a practice or process rather than pass or fail a test, things like running usability testing with people who use assistive technology, or maintaining a caption style guide. And under all of that sit Methods, which work a lot like the current Techniques documents: the concrete, technology-specific “here’s how you actually do this” guidance.

The working group is also floating a system of tags for each requirement, categorizing it by the kind of harm it prevents: physical harm, risk, barrier, or friction. Instead of the old three-tier ladder, the current proposal is a single conformance level, with additional reporting tiers below and above it. And the W3C is openly asking for feedback on whether that’s actually better than an alternative scoring approach. That question hasn’t been settled. If you have opinions on how conformance reporting should work, this is an unusually direct chance to shape a standard while it’s still wet. Comments go through the public wai@w3.org list or as GitHub issues on the draft itself.

Why We like the direction this is heading

A few reasons, and none of them are “because it’s new.”

It stops treating good practices as extra credit nobody does. WCAG 2.x AAA has always been sort of aspirational, a wish list most teams glance at and move past. By restructuring around Core and Supplemental requirements instead of a strict A/AA/AAA ladder, the working group has more room to put genuinely important practices where teams will actually encounter them, instead of parking them in a tier that functions as the honor roll nobody joins.

Assertions match how I already tell clients to think about this stuff. I’ve written before about why a VPAT claiming perfect support across the board is a red flag, not a good sign, and why “Partially Supports” is an honest and legitimate answer on a conformance report. WCAG 3.0’s assertion model is doing something similar at the standards level. It’s making room for an organization to document what it actually does, not just what a specific page technically passes. That’s a more honest picture of where accessibility maturity actually lives, which is in process and people, not just in code that happens to pass a scan.

The scope finally matches how people actually use technology. WCAG 2.x was written for web pages in an era when web pages were most of the internet. A lot of what actually locks people out today lives in PDFs, in native apps, in software that never touches a browser. Widening the standard to cover that instead of forcing everyone to squint and apply web guidance to a mobile app by analogy is overdue.

Cognitive and language-related needs get more direct attention. This has been one of the harder gaps in WCAG 2.x, and it’s one of the areas the working group has repeatedly said it’s trying to close in WCAG 3.0.

It’s still fundamentally about human testing, not automated shortcuts. Nothing about this new structure hands the job to a scanner. If anything, requirements and assertions built around real practice make it harder to fake conformance with a tool that just checks for missing alt attributes. That’s consistent with something I say a lot: automated tools are useful the way a spell-checker is useful. They’ll catch a misspelled word. They won’t tell you if the essay makes sense.

What this means for you today

Nothing changes your deadline. The W3C has been explicit that WCAG 3.0 is not currently a replacement for WCAG 2.2, and it isn’t expected to become a finished, adoptable standard for a few more years yet. WCAG 2.x isn’t going anywhere either. Once WCAG 3.0 does stabilize, expect a long overlap period with transition guidance, not a hard cutover.

So if you’re a city, county, school district, or business working through ADA Title II or general accessibility compliance right now, keep doing exactly what you’re doing. WCAG 2.1 AA is the standard that matters today. If you haven’t started, or you’re not sure where you stand, that’s what the ADA Title II Digital Compliance Handbook walks you through, phase by phase, without a six-figure invoice attached to it.

What WCAG 3.0 is worth doing right now is watching, and maybe weighing in if you’ve got the bandwidth. The conformance model is genuinely still being decided, and the people writing it are asking real practitioners what works. That’s a rarer opportunity than it sounds.

I’ll keep tracking this one the way I did the last draft. If you want the deeper background on how WCAG 3.0 got here, including the Silver Task Force work that started this whole thing, my original WCAG 3.0 piece from 2024 still holds up as the origin story. And if the assertion model got you curious about how conformance reporting works in practice today, my breakdown of VPATs is a good next read.

Questions about where WCAG 3.0 fits into your own accessibility roadmap, or what to actually prioritize between now and whenever it lands? Email me at jeff@accessiblu.com. Happy to talk it through.