WCAG 3 Is Being Built in Public. That's the Point.

The W3C WAI Director's blog post on WCAG 3 development contains a small but telling detail: the primary call to action is an email address. Not a survey. Not a structured feedback portal. An email list — wai@w3.org — and a GitHub repository.

For anyone who has watched accessibility standards development over the past two decades, this is either reassuring or alarming, depending on your vantage point. It's reassuring because public participation in standards-making is genuinely valuable. It's alarming because email lists and GitHub issues are participation mechanisms that systematically favor certain voices over others — developers, academics, large organizations with dedicated accessibility staff — and systematically exclude the disabled people whose lives these standards are meant to improve.

That tension is the real story of WCAG 3. And it's worth examining carefully, because what gets built into this standard will shape digital accessibility for the next decade.

Why WCAG 3 Exists at All

WCAG 2.1 (opens in new window) and its successor WCAG 2.2 (opens in new window) have done substantial work. They gave the field a shared technical vocabulary. They made Section 508 (opens in new window) enforcement tractable. They enabled the DOJ's web accessibility guidance (opens in new window) to point at something concrete when explaining what "effective communication" requires under the ADA.

But the 2.x series was built around a specific model of the web that no longer reflects how most people actually use it. Mobile interfaces, voice assistants, augmented reality, AI-generated content — none of these map cleanly onto success criteria designed for desktop HTML. The binary pass/fail structure creates situations where a page technically passes every criterion and remains genuinely unusable for people with cognitive disabilities. That's not a minor gap. That's a structural problem.

WCAG 3 is attempting to fix this by rethinking the scoring model, broadening the scope of what counts as "accessible," and — critically — building in more explicit attention to functional outcomes rather than technical checkboxes.

This is the right direction. The question is whether the process will produce a standard that actually reflects the needs of disabled people, or one that reflects the needs of organizations trying to demonstrate compliance.

The Participation Problem

Standards bodies have a documented participation bias. The organizations with the resources to send representatives to working groups, monitor mailing lists, and submit detailed technical comments are overwhelmingly large technology companies, government agencies, and academic institutions. Disabled individuals and small disability-led organizations participate far less — not because they have less at stake, but because participation is expensive in time, technical literacy, and access to the process itself.

This isn't a new observation. Our research on the compliance framework paradox documents how standards fragmentation already creates organizational paralysis — organizations struggling to reconcile WCAG 2.1, Section 508, EN 301 549, and emerging state regulations simultaneously. WCAG 3 could either resolve this fragmentation or deepen it, depending on how carefully the working group manages backward compatibility and transition guidance.

The email-and-GitHub participation model doesn't solve the underlying problem. GitHub issues require technical familiarity. Public mailing lists can be hostile environments for people raising lived-experience concerns rather than technical objections. If the W3C wants WCAG 3 to actually serve disabled people, the participation infrastructure needs to match that ambition.

This is where Shawn Lawton Henry's framing matters. The WAI Director's post frames this as an open invitation — and that openness is real. But openness and accessibility are not the same thing.

What the New Scoring Model Actually Changes

The most consequential structural change in WCAG 3 is the move away from binary conformance levels (A, AA, AAA) toward a more graduated scoring approach. This has practical implications that practitioners need to understand now, before the standard finalizes.

Under the current model, a single failure at the AA level means non-conformance — full stop. This creates perverse incentives. Organizations optimize for passing automated checks rather than improving actual usability, because a single missed alt text can invalidate an otherwise well-executed implementation. Our research on automated versus manual testing methodology shows that automated tools catch at most 37% of real accessibility barriers — meaning the current compliance model rewards the 37% that's easily measurable while leaving the harder 63% largely unaddressed.

A graduated scoring model could change this calculus. If organizations receive credit for partial progress rather than facing binary pass/fail, the incentive structure shifts toward genuine improvement. The risk is the opposite: that a scoring system becomes a way to claim "good enough" while leaving significant barriers in place.

The WCAG 3 Working Draft (opens in new window) is explicit that this tension is unresolved. The working group is still determining how scores translate to legal conformance claims — which is the question that actually matters for Title II and Title III enforcement.

What Practitioners Should Do Right Now

WCAG 3 will not replace WCAG 2.x overnight. The transition timeline is measured in years, not months. But the decisions being made now will shape what practitioners are working with in 2028 and beyond.

Action	Timeline	Why It Matters
Review the WCAG 3 Working Draft	Now	Understand structural changes before they finalize
Submit comments via wai@w3.org or GitHub	Ongoing	Shape the standard, not just comply with it
Audit current WCAG 2.2 gaps	30–60 days	Baseline before transition requirements emerge
Engage disabled users in testing	Ongoing	Build the feedback loops WCAG 3 assumes organizations have
Monitor DOJ guidance updates	Quarterly	Legal obligations track standards adoption

The standards framework crisis our research documents is real — organizations are already struggling with overlapping requirements. WCAG 3 could simplify this landscape or complicate it further. The outcome depends partly on what practitioners tell the working group now.

The Deeper Argument

Accessibility standards exist because digital spaces are, for many disabled people, the primary way they access employment, healthcare, education, and civic participation. When those spaces fail, the failure isn't abstract — it's a person who can't file their taxes independently, or access their medical records, or complete a job application.

WCAG 3 is being built in public because the W3C understands, at least in principle, that standards this consequential shouldn't be built behind closed doors. That's the right instinct. The follow-through requires more than an email address.

If you work in accessibility — as a practitioner, an attorney, a procurement officer, or a disabled person who uses these systems — the participation window is open. The Northeast ADA Center (opens in new window) and regional ADA centers have historically provided guidance on how standards changes affect compliance obligations; monitoring their analysis as WCAG 3 develops is worth building into your workflow.

The standard being written now will determine what "accessible" means for the next generation of digital infrastructure. That's worth a GitHub issue.