WCAG 3 Is Coming, but WCAG 2.2 Is the Work Now

Organizations sometimes delay accessibility work because a new standard is on the horizon. WCAG 3 is being developed to address a wider range of technologies and user needs, but it remains a working draft. Waiting for it would leave current customers facing barriers that established guidance already helps teams prevent and fix.

The practical position in August 2026 is straightforward: use WCAG 2.2 as the current technical reference, meet applicable legal and contractual obligations, and follow WCAG 3 as future-facing work. Accessibility is an operating capability, not a migration that begins only when a version number changes.

Understand the status of each standard

W3C describes WCAG 2.2 as a stable Recommendation and encourages use of the latest WCAG 2 version. It is also approved as ISO/IEC 40500:2025. WCAG 3, by contrast, has a March 2026 Working Draft and is expected to continue evolving.

The W3C Web Accessibility Initiative is the appropriate source for current status. Avoid treating summaries, vendor scorecards, or draft commentary as substitutes for the published standards and requirements that apply to your organization.

Use WCAG 2.2 to improve real tasks

Start with journeys that affect participation and revenue: navigation, forms, authentication, checkout, booking, account management, video, documents, and support. Test the success criteria in the context of these tasks rather than chasing an isolated automated score.

WCAG 2.2 additions include concerns such as focus visibility, target size, dragging alternatives, consistent help, redundant entry, and accessible authentication. Translate each relevant criterion into design-system rules, component tests, and content practices.

Do not confuse conformance with completion

Conformance provides a shared technical target; it does not guarantee that every person can use every experience comfortably. Include people with disabilities in research and testing when possible. Consider cognitive load, plain language, captions, error recovery, and support options beyond the minimum criterion.

Automated scanners can find some issues quickly, but they cannot judge every label, reading order, instruction, or task outcome. Pair automation with keyboard testing, screen-reader checks, zoom and reflow review, and human evaluation.

Watch WCAG 3 for direction

WCAG 3 is intended to cover a broader range of web content, applications, tools, emerging technologies, and diverse disability needs. Its structure and conformance model may differ from WCAG 2. Use the drafts to understand direction and contribute feedback, not to invent future compliance claims.

Teams building design systems can prepare by recording user needs, test evidence, severity, and task impact rather than storing only pass-or-fail checkpoints. Better evidence will remain useful under any future model.

Build an accessibility operating rhythm

Assign an accountable owner, define a standard, train each role, test reusable components, include accessibility in acceptance criteria, and maintain a prioritized remediation backlog. Recheck after releases and content changes. Procurement should also evaluate third-party tools that become part of the customer journey.

• Publish the current accessibility target internally.
• Test the five most important user journeys.
• Fix blockers before lower-impact polish.
• Document exceptions with owners and dates.
• Review W3C updates on a planned cadence.

Act on today’s barriers while preparing for tomorrow

Do not market draft WCAG 3 alignment as if it were a settled certification. Do not assume a WCAG 2.2 checklist eliminates legal risk; requirements differ by jurisdiction and context, and qualified legal advice may be necessary.

Choose one critical journey this month and evaluate it against WCAG 2.2 with manual testing. Turn the findings into reusable design and engineering rules. That work helps customers now and gives the organization a stronger foundation for whatever the next standard ultimately requires.

Keep legal compliance and product quality connected but distinct. Counsel can advise which laws, standards, contracts, and timelines apply; accessibility practitioners and people with disabilities can show how the product behaves. Neither a legal statement nor a scan replaces direct evaluation of the experience.

Budget remediation alongside feature work. Give teams time to fix shared components, update content, and retest rather than treating every issue as emergency work after an audit. Sustainable accessibility requires capacity as well as intent.

Prepare procurement and content workflows too

Accessibility barriers often enter through purchased widgets, booking systems, payment tools, document generators, video platforms, and campaign templates. Add accessibility requirements, evidence requests, remediation expectations, and exit options to procurement. A third-party badge does not remove the organization’s responsibility for the customer journey it assembles.

Give content authors rules they can apply without reading the full standard: descriptive links, meaningful headings, useful alternative text, captions, plain instructions, accessible tables, and careful use of color. Provide CMS patterns that make the correct choice easier and prevent known failures where possible.

Track training, component coverage, tested journeys, unresolved blockers, and supplier risks alongside criterion-level findings. This broader view helps leadership fund the system that prevents barriers, not only the project that fixes them. WCAG 3’s future direction reinforces the value of understanding user needs, but the organization can build that habit now.

Photo by Jakub Pabis on Pexels.