WCAG 3 September 2026 Draft: What Development Teams Need to Know Now

The draft dropped on September 10th. The review window is open. And somewhere in a Slack channel right now, a developer is asking the question that every accessibility-conscious team is wrestling with: Do we start building for WCAG 3, or do we keep our heads down with 2.2?

That's the right question. The answer requires thinking carefully through four dimensions — what your users actually need, what your team can realistically build, what your legal exposure looks like today, and where leadership is willing to invest. The September 2026 WCAG 3 Working Draft (opens in new window) doesn't resolve that question, but it does sharpen it considerably.

What the September Draft Actually Is

The W3C's Working Draft update is a checkpoint, not a finish line. The WCAG 3 Introduction (opens in new window) frames it clearly: this is an in-progress document with active review questions specifically around the conformance model — the mechanism that determines how organizations demonstrate compliance. That's the part that matters most operationally.

WCAG 3 represents a fundamental architectural shift from WCAG 2.x. Instead of binary pass/fail criteria, the draft moves toward a scoring-based model with outcomes, methods, and functional needs. The Status: In-progress drafts (opens in new window) page lists the specific changes and the review questions the W3C is asking the public to weigh in on. Those questions deserve careful attention from anyone building digital products at scale.

The W3C is explicitly soliciting feedback via wai@w3.org and GitHub (opens in new window). This is a genuine invitation. Development teams that participate now shape what gets finalized later.

The Conformance Model Is the Real Story

Here's what makes the September draft significant: the conformance model revision is where WCAG 3 either becomes practically useful or operationally unworkable for most development teams.

WCAG 2.x conformance is binary. A page either passes Success Criterion 1.4.3 (Contrast Minimum) or it doesn't. That clarity has real value — it maps cleanly to automated testing pipelines, legal settlements, and procurement checklists. The tradeoff is that binary pass/fail misses nuance. A page can pass every criterion and still be functionally unusable for someone with cognitive disabilities.

WCAG 3's outcome-based model attempts to capture that nuance. But "nuance" in a conformance model creates operational complexity that development teams need to plan for. Our research on automated testing methodology shows that even against the current binary WCAG 2.x standard, automated tools detect at most 37% of accessibility barriers. A scoring-based model doesn't make that problem easier — it potentially makes it harder, because the evaluation surface becomes larger and more context-dependent.

This is where the CORS framework becomes useful as an analytical lens. Four questions cut through the noise:

Community: Which users benefit from WCAG 3's expanded scope, and are those the users your organization is currently failing? WCAG 3 places stronger emphasis on cognitive accessibility and functional needs — areas where 2.x has well-documented gaps. If your user research shows significant barriers for users with cognitive disabilities, WCAG 3's direction is aligned with real community need.

Operational: What does your team's testing infrastructure actually support? If you're running automated CI/CD pipelines calibrated to WCAG 2.2 success criteria, a move toward outcome-based evaluation requires rethinking your toolchain, not just updating a checklist. That's a non-trivial investment.

Risk/Legal: What standard do current legal obligations reference? 28 CFR Part 35 (opens in new window) (Title II) and 28 CFR Part 36 (opens in new window) (Title III) DOJ regulations currently reference WCAG 2.1 AA as the technical standard. WCAG 3 has no legal force yet. Building toward it is strategic positioning, not current legal obligation.

Strategic: Where is your organization's leadership in terms of accessibility maturity? The compliance framework paradox is real — organizations already navigating WCAG 2.1, Section 508, and EN 301 549 simultaneously face genuine capacity strain. Adding a fourth standard in transition creates paralysis risk unless leadership is actively invested.

What Development Teams Should Actually Do Right Now

The W3C is moving deliberately, and the public review process is functioning as intended. That's genuine progress toward a standard that could meaningfully improve accessibility for people with cognitive disabilities, low vision, and other functional needs that WCAG 2.x underserves.

But "moving deliberately" means the timeline is still uncertain. The practical guidance for development teams breaks into three tiers:

Participate in the Review (Now, Before the Window Closes)

If your team builds at scale, your feedback on the conformance model questions is valuable — and the W3C has explicitly asked for it. Focus your comments on operational feasibility: How would your team demonstrate conformance under the proposed model? What tooling gaps exist? What would make the standard testable in a CI/CD context? This isn't abstract advocacy — it's shaping the standard you'll eventually implement.

Build WCAG 2.2 AA Compliance as the Stable Foundation

The legal standard today is WCAG 2.1 AA (per current DOJ regulations), with WCAG 2.2 representing best practice. Build to 2.2 AA now. The success criteria at w3.org (opens in new window) are stable, legally defensible, and provide genuine access improvements. WCAG 3 is designed to be largely backward-compatible in intent — organizations doing solid 2.2 work won't be starting over.

Map Your Testing Gaps Against WCAG 3's Direction

The areas where WCAG 3 expands most significantly — cognitive accessibility, user needs-based evaluation, functional outcomes — are precisely the areas where automated testing falls shortest. Our research on hybrid testing methodologies suggests that teams investing in manual evaluation capacity now are building skills that WCAG 3 will require at scale. That investment has dual ROI: it closes 2.x gaps that automation misses, and it positions teams for 3.0's more nuanced evaluation model.

The Standards Transition Reality

Every major standards transition creates a period of uncertainty that organizations navigate imperfectly. The fragmented standards landscape already strains organizational capacity — WCAG 2.1, 2.2, Section 508, EN 301 549, and emerging state regulations don't always align cleanly. WCAG 3's arrival adds a transition layer on top of existing complexity.

The data point that matters most: the W3C is asking specific public review questions about the conformance model in this September draft. That's a signal that the model isn't locked. Development teams that engage now — through GitHub issues or email to wai@w3.org — are participating in a process that's genuinely open to technical feedback.

Equal access for disabled people is what this standard exists to advance. WCAG 3's expanded scope, if the conformance model lands well, could meaningfully extend that access to populations currently underserved by binary pass/fail evaluation. The September draft suggests the W3C is taking that goal seriously.

The next concrete step: read the review questions on the conformance model (opens in new window), assess them against your team's operational reality, and submit feedback before the window closes. That's where development teams have actual leverage right now.