Conventional wisdom suggests you should start preparing for WCAG 3.0 now. Get ahead of the curve. Build transcripts. Add audio descriptions. Spell out every acronym on first use. The W3C published a new working draft in September 2026, and the advice flooding accessibility channels is to treat it like the next compliance deadline you can't afford to miss.
Here's the problem: WCAG 3.0 isn't a deadline. It's not even a standard yet. Treating it like your next regulatory obligation pulls resources away from the compliance work that actually matters today.
Why We Disagree
The September 2026 working draft is years away from finalization. The W3C has been clear that the requirements will change: items will be added, combined, and cut before anything becomes enforceable. You're being asked to build to a moving target that has no legal force and won't for years.
Meanwhile, if you're a Title II public entity under the ADA, your enforceable standard is WCAG 2.1 Level AA, with compliance deadlines of April 26, 2027, for entities serving 50,000 people or more, and April 26, 2028, for smaller entities and special districts. That's the regulatory obligation you're accountable for. That's where your audit risk lives.
The draft introduces a new structure: core requirements (mandatory), supplemental requirements (beyond baseline), and assertions (documented policies or processes). It moves several provisions that were WCAG 2.x AAA-only into the core tier. Transcripts for audio and video content, not just captions. Audio descriptions covering what a video shows but never says. A plain-language explanation the first time an abbreviation appears. A findable summary near the top of any long article.
None of that Web Accessibility Specialist required to meet WCAG 2.1 AA. In this draft, it reads as the floor. But you're being asked to build to a floor that doesn't exist yet in any enforceable form.
The Evidence
WCAG 2.0 shipped with 61 success criteria in 2008. WCAG 2.1 brought that to 78 in 2018. WCAG 2.2 reached 86 in 2023. Each version has asked for more than the last, and the working group has been direct that this draft's list will still change. The W3C expects finalization to take several more years and has said it won't deprecate WCAG 2.x when 3.0 eventually ships.
That means you'll be maintaining conformance to two standards simultaneously. Your legal obligation will remain tied to WCAG 2.1 or 2.2 for years after 3.0 becomes available. No procurement contract references WCAG 3.0 today. No Accessibility Conformance Report template includes it. No Section 508 refresh mentions it.
If you're diverting budget to build transcripts and audio descriptions for every video asset while your current content still fails color contrast checks or lacks proper heading structure, you're solving for a future compliance scenario while failing the present one.
What to Do Instead
Meet your current obligations first. If you're under the DOJ Final Rule (2024), your deadline is WCAG 2.1 Level AA conformance by April 2027 or April 2028, depending on your entity size. That's the audit you'll face. That's the complaint risk you carry.
Run conformance testing against WCAG 2.1 AA. Fix missing alternative text. Repair keyboard navigation failures. Address color contrast violations. Ensure form labels are properly associated. Make sure your error messages are programmatically identifiable. These are the requirements that carry enforcement weight today.
If you've already achieved stable WCAG 2.1 AA conformance across your digital properties, then consider WCAG 2.2. It adds nine success criteria, including focus appearance, dragging movements, and accessible authentication. Those provisions are already referenced in some procurement requirements and European Accessibility Act implementations.
Only after you've addressed WCAG 2.1 AA and evaluated WCAG 2.2 should you look Assistive Technology what the 3.0 draft might mean for your long-term strategy. And even then, don't build to it. Track it. Monitor the working group's GitHub repository. Submit comments if you have implementation concerns. But don't commit development resources to requirements that may not survive the next draft revision.
Document what you're already doing that happens to align with the draft's direction. If you're already providing transcripts for some video content, note that. If you're already spelling out acronyms on first use in your style guide, document it. That's not building to WCAG 3.0. That's capturing current practices that may become relevant later.
When Early Preparation Makes Sense
There's one scenario where early preparation makes sense: if you're already Assistive Technology WCAG 2.2 Level AA conformance and maintaining it without ongoing remediation backlogs. If your conformance testing shows stable results quarter after quarter. If your development pipeline includes accessibility review Assistive Technology every stage and your content management system enforces baseline requirements before publication.
In that case, you have the organizational maturity to experiment with what comes next. You can pilot transcripts for a subset of video content. You can test whether audio descriptions improve engagement metrics. You can evaluate whether summary blocks Assistive Technology the top of long articles reduce bounce rates.
But that's not most organizations. Most are still working through WCAG 2.1 AA backlogs. Most are still training content authors to write meaningful alternative text. Most are still figuring out how to test dynamic content for keyboard accessibility.
For them, WCAG 3.0 preparation isn't forward-thinking. It's a distraction from the compliance work that actually carries legal weight today. The draft is public and open for comment through GitHub or by email to the working group. That's how you engage with it now: as a standards development process you monitor, not a compliance deadline you build to.
Your audit next year won't ask whether you've prepared for WCAG 3.0. It'll ask whether you meet WCAG 2.1 Level AA. Answer that question first.
