The W3C published an updated Working Draft of WCAG 3.0 on September 4, 2025, and I’ve spent considerable time pulling it apart. The accessibility community has been tracking this specification since the first public working draft dropped in January 2021, and after years of watching the sausage get made this latest draft finally feels like it has a spine.
First, it is important to keep in mind that WCAG 3.0 is still very much an incomplete working draft. The conformance model isn’t finalized, specification tables have empty cells, and the timeline to W3C Recommendation stretches to 2028 at the earliest. It is not ready for production and you should not do anything with it other than follow how it develops.
But the direction is right, and in several places, it’s better than right — it’s the kind of thinking that could genuinely move the needle on digital accessibility in ways that WCAG 2.x never could. Here’s what I like.
The Guidelines Actually Read Like Goals Now
WCAG 2.x success criteria are written for specification lawyers and accessibility nerds. “Non-text content that is presented to the user has a text alternative that serves the equivalent purpose” is precise, but it’s not the kind of sentence that helps a product manager understand what they’re building toward. WCAG 2.x has always required translation in order to be considered at all actionable. This even goes for knowing what the heck “Level” means.
WCAG 3.0 rewrites guidelines as outcome statements: “Users have equivalent alternatives for images.” That’s the kind of sentence you can put in a product requirement document without an asterisk leading to three paragraphs of clarification.
More importantly, the draft includes decision trees that walk you through which specific requirements apply to a given piece of content. The Image Alternatives guideline, for example, starts with “Would removing the image impact how people understand the page?” and branches from there into decorative image handling, programmatic determinability, and text alternative requirements. Seeing that workflow formalized in the standard itself is a meaningful improvement.
Assertions Recognize That Process Matters
This is the single most interesting idea in WCAG 3.0, and also the most controversial. Assertions are formal, attributable, documented claims that your organization followed specific accessibility processes. Did you conduct usability testing with people with disabilities? Do you maintain a captioning style guide? Have content authors reviewed media alternatives?
Under WCAG 2.x, none of this matters for conformance. You could have zero accessibility process, stumble into a compliant product by accident, and claim Level AA. Conversely, you could run a world-class accessibility program, conduct extensive user research, invest in training, and still fail conformance because of a single missing label on a form field buried in a settings page because in WCAG 2.x conformance is all or nothing.
Assertions change the equation. They acknowledge what every accessibility practitioner already knows: organizations that embed accessibility into their development processes produce more accessible products over time than organizations that treat it as a punch list at the end. The draft includes assertion examples like maintaining a media alternatives style guide (with specific documentation requirements for what the guide should cover), conducting user testing with documented participant demographics, disability types, dates, and issues fixed, and having content reviewed by the people who created it.
The documentation requirements are specific enough to be meaningful without being so rigid that they become performative. The media alternatives user testing assertion, for example, asks for types of disabilities each user had, number of users per disability type, date of testing, and examples of fixed issues. That’s a reasonable evidence trail that demonstrates real engagement with real users and may offer a layer of defensibility against predatory ADA trolls.
There is an important counterargument that can be made that assertions can be gamed. Someone can document a process that was superficial, check the box, and move on. While I agree, it is also true that the current system can also be gamed by automated overlay tools claiming to deliver WCAG 2.x compliance through JavaScript injection without addressing underlying structural problems. VPATs are routinely filled out with generous interpretations of “Supports” and “Partially Supports.” No compliance system is immune to bad faith actors. The question is whether the system incentivizes the right behavior for good faith actors, and assertions clearly do.
For organizations already preparing for the European Accessibility Act, which emphasizes embedding accessibility into organizational culture and processes, assertions are a natural fit. The EAA and WCAG 3.0 are converging on the same insight: compliance as a snapshot of product state is less valuable than compliance as evidence of organizational commitment.
Cognitive Accessibility Gets Real Coverage
WCAG 2.x has always underserved cognitive and learning disabilities. The standard added some improvements in 2.2 but these were incremental patches on a framework that was primarily designed around sensory and motor disabilities.
WCAG 3.0 treats cognitive accessibility as a first-class concern. The Clear Language guideline alone includes requirements for no unnecessary words, no nested clauses, common words used in preference to jargon, abbreviations explained, non-literal language avoided, visual aids provided, and summaries included. It goes further with assertions for clear language style guides, training policies, and plain language review processes.
The Avoid Deception guideline is equally significant. It addresses changes in agreements, misleading wording, artificial pressure, hidden preselections, and misdirection. This essentially codifies anti-dark-pattern principles into an accessibility standard. This matters because dark patterns disproportionately harm people with cognitive disabilities, who may have greater difficulty recognizing manipulative interface patterns. Treating deceptive design as an accessibility barrier, rather than just a consumer protection issue, is an interesting inclusion that I hope makes it through to the final product.
The Process and Task Completion guideline covers avoiding exclusionary cognitive tasks, providing adequate time, eliminating unnecessary steps, and retaining information across sessions. These requirements address the reality that many digital experiences are unnecessarily complex not because of technical constraints but because of design choices that assume a narrow range of cognitive processing styles.
None of this was achievable within WCAG 2.x’s framework. Success criteria need to be testable, and cognitive accessibility requirements are inherently harder to reduce to binary pass/fail checks. WCAG 3.0’s layered model – with assertions supplementing requirements – creates the structural space to address cognitive needs without forcing everything through the same testing paradigm.
The Scope Matches How People Actually Use Technology
WCAG 2.x is a web content standard. The title says it. Mobile accessibility is handled through interpretive guidance and EN 301 549 mappings. Wearables, IoT devices, virtual reality, augmented reality, and voice interfaces exist outside the specification’s conceptual boundary.
WCAG 3.0 explicitly covers desktops, laptops, tablets, mobile devices, wearable devices, and other Web of Things devices. It addresses static, dynamic, interactive, and streaming content; audiovisual media; virtual and augmented reality; and alternative access presentation and control. It also folds in territory previously covered by the User Agent Accessibility Guidelines (UAAG 2.0) and Authoring Tool Accessibility Guidelines (ATAG 2.0).
This matters because the artificial boundary between “web content” and “everything else” has been eroding for years. A company shipping a React web app, a React Native mobile app, a voice skill, and a smartwatch companion is building one product across multiple surfaces. Having separate accessibility standards (or no standard at all) for each surface creates gaps, inconsistencies, and an excuse to deprioritize non-web experiences.
The 360-degree environment requirements are a good example of forward-looking scope. The draft requires that captions remain directly in front of the user in 360-degree digital environments and that visual indicators show the direction of sound or speech heard from outside the current view. VR and AR accessibility is a genuinely hard problem, and having the working group establish normative expectations while the technology is still maturing is far better than trying to retrofit requirements after an entire ecosystem has been built without them.
Graduated Conformance Reflects Reality
Under WCAG 2.2, conformance is binary. You meet all requirements for the stated level, or you don’t. A single failure on any success criterion, on any page in scope, technically breaks your conformance claim. Everyone in the industry knows this doesn’t reflect how accessibility actually works at scale. Large applications have hundreds of views, content is constantly changing, third-party components introduce issues outside your direct control, and remediation timelines are measured in sprints, not days.
The result is that WCAG 2.x conformance claims are either aspirational (we’re working toward AA), lawyered (conformance is claimed for a defined subset of pages tested on a specific date), or fictional. The all-or-nothing model doesn’t reward incremental progress, doesn’t differentiate between an organization with three outstanding issues and one with three hundred, and doesn’t incentivize going beyond the minimum.
WCAG 3.0’s proposed Bronze/Silver/Gold model changes this dynamic. Bronze – meeting all Foundational Requirements – is designed to be roughly comparable to WCAG 2.2 AA. Silver and Gold levels require additional Supplemental Requirements and Assertions, creating a pathway for organizations to demonstrate progressive commitment. The working group is exploring scoring mechanics that would allow conformance claims to reflect the degree to which requirements are met, not just whether a single failure exists.
This is better for everyone. Organizations get a conformance model that acknowledges the messy reality of large-scale software. Procurement teams get more useful information on the product and its vendor. And people with disabilities benefit because the incentive structure rewards continuous improvement rather than minimum-viable compliance.
The Modular Update Architecture Is Overdue
WCAG 2.0 was published in 2008. WCAG 2.1 arrived in 2018. WCAG 2.2 in 2023. That’s a 15-year lifecycle with two incremental updates — during a period in which the web went from jQuery plugins to single-page applications, responsive design, web components, progressive web apps, server-side rendering frameworks, and AI-generated content.
The slow update cadence isn’t because the working group is lazy. It’s structural. Under WCAG 2.x, Techniques are tightly coupled to the normative specification. Adding a new Sufficient Technique requires careful consideration of whether it changes the interpretation of a success criterion. New success criteria require a full version revision. The result is a standard that can’t keep pace with the technology it’s trying to govern.
WCAG 3.0 separates Methods (technology-specific implementation guidance) from normative Requirements. Methods can be added, updated, or retired without revising the standard itself. A new method for accessible React components, or for handling accessibility in a new AR framework, can be published as soon as it’s validated without waiting for the next major WCAG version.
This is the right architecture for a technology landscape that changes faster than any standards body can publish. Enterprise teams benefit because implementation guidance stays current with their actual tech stack, and because new techniques don’t require re-evaluating their entire conformance posture.
Functional Needs Tagging Prevents Cherry-Picking
One of the under-discussed features of WCAG 3.0 is the functional needs tagging system. Every requirement and assertion is tagged with the functional needs it addresses, like vision, hearing, motor, cognitive, sensory, and so on. The proposed conformance model requires that a minimum number of supplemental requirements be met within each functional need category to achieve Bronze.
This is a direct response to a real problem: organizations often invest heavily in visual accessibility (because automated tools catch it and most lawsuits are by non-visual plaintiffs) while neglecting cognitive, motor, or auditory needs. Under WCAG 2.x, you can technically achieve Level AA by treating all success criteria equally, but in practice, organizations prioritize the criteria that are easiest to test and most visible to automated scanners.
Functional needs tagging makes equity a structural requirement, not a cultural aspiration. You can’t claim Bronze by acing all the visual requirements while ignoring cognitive accessibility. This is the kind of systemic design choice that has more impact than any individual requirement.
What’s Still Missing (And It’s a Lot)
I genuinely like the direction of WCAG 3.0. But liking the direction and being able to use the thing are different conversations, and intellectual honesty requires itemizing how much work remains. This is not a criticism of the working group. Standards development is brutally hard, consensus-driven work performed largely by volunteers with far more patience than I have
The conformance model is a sketch, not a specification. Bronze, Silver, and Gold are described conceptually, but the mechanics that make them real, such as how scores aggregate, what thresholds define each tier, how functional need categories are weighted, whether a critical error at any level voids conformance entirely are all undecided. The working group has published slides and discussion notes exploring points-based, percentage-based, and module-based approaches, but none have been selected. You cannot build a compliance program against a conformance model that doesn’t have numbers in it yet.
Specification tables are empty. The Text Appearance guideline includes tables meant to define concrete values for readable text like line height, line length, font size, justification, letter spacing across five languages. Nearly every cell is blank. The draft itself says “the metrics in the following table are still to be determined.” These aren’t edge-case details. They’re the values that automated testing tools would check against, that developers would code to, and that auditors would measure. Without them, the requirements are directional aspirations, not testable criteria.
Assertion verifiability is unresolved. The draft explicitly states that “the results of the process stated in an assertion cannot be tested” and that “conforming to WCAG does not require testing supporting documentation.” I understand the reasoning: you can’t independently reproduce the outcome of a usability study the way you can re-test a color contrast ratio. But this creates a real accountability gap. If I assert that my team conducted user testing with eight participants with disabilities, what stops a bad actor from fabricating that claim? The draft doesn’t say. Third-party auditors, procurement officers, and regulators will all need an answer to this question before assertions can carry meaningful weight.
The foundational vs. supplemental classification is unfinished. Which requirements end up in the foundational set (required for Bronze) versus the supplemental set (required for higher tiers) will determine whether WCAG 3.0 raises or lowers the practical bar compared to WCAG 2.2 AA. The working group is actively debating this, including whether any assertions should be foundational. Until those classifications are made, no one can assess whether Bronze is stricter, equivalent to, or looser than current AA expectations.
Automated testing coverage will shrink. This is a consequence of covering the right things. Clear language quality, deception avoidance, algorithm fairness, process assertions, and cognitive task complexity are important accessibility concerns that resist automation. But enterprise programs that currently scan thousands of pages nightly and route failures into Jira need to understand that the testing model is about to get significantly more labor-intensive. The tooling ecosystem for WCAG 3.0 doesn’t exist yet, and building it will require fundamentally new approaches beyond DOM inspection and contrast calculation. Despite the fact that I’m quite bullish on AI, I don’t foresee this gap being closed by AI for at least a few more years.
The timeline is optimistic. The working group targets a Candidate Recommendation in Q4 2027 and a full Recommendation no earlier than 2028. Given the volume of open questions I’d plan for 2029 at the earliest for a finished standard, with regulatory adoption (updates to Section 508, EN 301 549, national legislation) trailing by another one to three years after that.
No migration guidance exists yet. The working group has committed to providing transition support materials, potentially including mappings between WCAG 2.2 criteria and WCAG 3.0 requirements. These don’t exist in the current draft. Organizations that have invested years in WCAG 2.x compliance programs — training, tooling, documentation, VPATs — need a clear bridge to understand what carries over, what changes, and what’s net new. Until that mapping is published, migration planning is guesswork.
So Where Does That Leave Us?
In a good place, actually.
The structural decisions in this draft such as outcome-oriented guidelines, process-based assertions, graduated conformance, expanded device and content scope, modular updatability, functional needs equity are the right foundations for the next generation of accessibility standards. Every one of these ideas addresses a real limitation that practitioners have bumped against for years working under WCAG 2.x. The working group is solving the right problems.
The fact that the solutions aren’t finished yet is not a reason to ignore them. It’s a reason to engage. The working group is explicitly asking for public feedback on the conformance model, on which requirements should be foundational, on whether assertions belong in the Bronze tier, and on gaps in the guideline coverage. If you have opinions about how accessibility standards should work now is the window to shape them.
In the meantime, the smartest thing any organization can do is invest in the practices that will serve them under both standards. Document your accessibility processes. Conduct user testing with people with disabilities and keep records. Build a clear language style guide. Train your teams. Improve your cognitive accessibility posture. These investments pay dividends under WCAG 2.2 today, they’ll count toward WCAG 3.0 assertions tomorrow, and they’ll make your products better for everyone regardless of which specification the lawyers are pointing at.
WCAG 2.2 AA is the standard you comply with today. WCAG 3.0 is the standard you start preparing for now. And despite everything that’s still missing, I’m genuinely encouraged by where it’s headed.
