WCAG 3.0: What It Is and What It Means for Your WCAG 2.2 Compliance

Accessibility standards have changed as the web has changed. For years, the WCAG 2 series has acted as a guide for organisations to make their websites and digital content accessible to people with disabilities. 

The WCAG 2.1 AA standard became a widely used benchmark, followed by WCAG 2.2, which added new success criteria around areas like focus appearance, dragging movements, target size and accessible authentication. But digital experiences are no longer limited to static web pages. 

Websites now behave more like applications. Content is delivered across multiple devices, and technologies like voice interfaces, immersive experiences and AI are changing how people interact with digital content. This is where WCAG 3.0 comes in. 

The current WCAG 3.0 draft, published by the World Wide Web Consortium (W3C) on March 3, 2026, proposes a broader scope, a different structure and a new approach to measuring accessibility. 

This article looks at what it actually changes compared to WCAG 2.1, why it matters, and how you can prepare your organisation for it.

The WCAG POUR Principle

Before we take a deep dive into WCAG 3.0, it is important to understand the foundation on which modern accessibility guidance is built. 

The WCAG web content accessibility guidelines are organised around four principles, commonly known as POUR.

Perceivable: Content and information should be available in ways users can perceive, such as text alternatives for images and captions for video. 

Operable: Users should be able to navigate and interact with a website using different input methods, including a keyboard. 

Understandable: Content, navigation and interactions should be clear, predictable and easy to follow. 

Robust: Websites should work reliably across browsers, devices and assistive technologies.

What Is WCAG 3.0?

WCAG 3.0 is the proposed next generation of accessibility guidance from the W3C. 

Unlike WCAG 2, it is called W3C Accessibility Guidelines because its scope goes beyond web content, a shift first outlined in the original 2021 working draft. The current WCAG 3.0 draft applies to web content, apps, tools, publishing and emerging technologies. 

It also considers different types of content and experiences. This includes dynamic and interactive content, audiovisual media, mobile and wearable devices, and virtual and augmented reality. The proposed model is still evolving. 

The standard is still years away from finalisation, and there is no confirmed WCAG 3.0 release date yet. Until then, WCAG 2.2 remains the current W3C recommendation for web accessibility.

What the WCAG 3.0 Guidelines Cover Compared to WCAG 2.1

The WCAG 3.0 guidelines are not simply a longer checklist of accessibility requirements. They change how accessibility is understood, measured and maintained compared to WCAG 2.1.

1. A broader range of user needs

WCAG 2.x has been highly effective, but some accessibility needs do not fit neatly into a simple pass/fail success criterion. The WCAG 3.0 draft gives particular attention to cognitive accessibility and low vision. It explores ways to assess accessibility through different forms of evidence rather than relying only on binary tests.

2. A new approach to conformance

WCAG 2.1 AA and the version that followed it use the familiar A, AA and AAA levels. WCAG 3.0 is exploring a different model. The current draft describes Bronze, Silver and Gold levels, built around core requirements alongside supplemental requirements and assertions. The intention is to provide a more flexible way to represent different degrees and types of accessibility work.

3. More ways to measure accessibility

This draft also explores measurements beyond traditional pass/fail testing. These can include rubrics, sliding scales, task completion and user research with people with disabilities where appropriate. This could be particularly relevant for complex Drupal applications where accessibility cannot always be represented accurately by checking isolated HTML elements.

4. More flexibility as technology changes

One of the stated goals of WCAG 3 is easier maintenance and extensibility. Instead of creating a standard that becomes increasingly difficult to update as technology changes, the draft is designed to accommodate new methods, requirements and guidelines over time.

Why Is WCAG 3.0 Necessary?

WCAG 2.1 and its later revisions remain established standards. In fact, W3C currently recommends using the latest WCAG 2 version, with WCAG 2.2 adding nine new success criteria while maintaining backward compatibility. 

So why introduce WCAG 3.0?

1. Digital experiences have become more complex

Websites are no longer simple collections of pages. They include interactive applications, personalisation, dynamic interfaces, video, AI-powered features and increasingly complex user journeys. Accessibility guidance needs to account for those experiences.

2. Passing individual checks does not always mean an experience is accessible

Automated testing is useful, but accessibility is ultimately about whether people can use a digital product effectively. A website might have correctly labelled buttons and still make a checkout process confusing. WCAG 3.0's focus on tasks and outcomes could help address this gap. 

Our own industry-wise Drupal audit data shows this gap in practice. Several sectors show WCAG AA failure rates well above 70%, often on pages that pass individual automated checks.

3. Cognitive accessibility needs more attention

Clear language, predictable navigation, understandable instructions and effective error handling can significantly affect how people interact with digital services. The current draft gives these areas greater visibility.

4. Standards need to keep pace with technology

New interfaces and devices create accessibility questions that older standards were not designed to address. WCAG 3.0 is intended to be easier to maintain as these technologies develop.

How to Prepare for WCAG 3.0

The WCAG 3.0 guidelines are still being developed, so there is no reason to redesign a website around requirements that may change. The better approach is to strengthen the accessibility practices already in place and address gaps that could become harder to fix later.

1. Start with WCAG 2.2

If your website still follows WCAG 2.1 AA, WCAG 2.2 is the more appropriate baseline to work towards today. It builds on WCAG 2.1 and adds requirements for areas such as focus visibility, target size, accessible authentication and redundant entry, all detailed in the official W3C specification. 

If your accessibility policy or development standards still refer to the WCAG 2.1 AA standard, review them against the newer requirements it has since introduced.

2. Look beyond individual pages

Accessibility problems often come from shared elements rather than individual pages. A template, component or form pattern with an accessibility issue can affect large sections of a website. 

A thorough audit should therefore examine: Templates and reusable components Navigation and forms Content structures Custom and third-party functionality Themes and modules This gives teams a clearer view of where accessibility problems originate and which fixes can have the widest impact.

3. Test how people actually use the website

Automated testing is useful for identifying technical issues, but it cannot tell you whether users can complete important tasks without difficulty.

Test common journeys such as finding information, submitting a form, creating an account or accessing a service. Where relevant, include keyboard-only testing, screen readers and other assistive technologies.

This type of testing becomes increasingly important as accessibility guidance puts greater emphasis on user experience and outcomes.

4. Bring accessibility into the development process

Accessibility should not begin with an audit after a website goes live. It should be considered as new components, features and content are created.

For development teams, this means including accessibility checks in:

• Design and component reviews
• Code reviews
• Content publishing workflows
• Pre-release testing

This makes accessibility part of the development cycle rather than a separate compliance exercise

5. Keep testing after the initial audit

A website can become less accessible after an audit because the website itself keeps changing. New content, design updates, module changes and custom development can introduce problems that were not present during the original assessment.

Regular testing and monitoring can help teams identify these changes early, track recurring issues and maintain progress against wcag 2.2 while WCAG 3.0 continues to take shape.

Make Your Website WCAG Compliant

There is no confirmed WCAG 3.0 release date, and organisations should not wait for the final standard to address accessibility gaps. 

For most teams, the only way is to work towards WCAG 2.2, test accessibility across the full website, evaluate important user journeys, and make accessibility part of ongoing development and maintenance. 

The Web Content Accessibility Guidelines (WCAG) will continue to evolve, but the goal remains the same: creating websites that work for everyone. If you manage a Drupal website, DrupalFit can help you see where your site currently stands. 

Enter your website URL, run an audit, and review the Accessibility section to see accessibility errors and warnings across your pages. You can also assess your website against WCAG A, AA, or AAA and use the findings to work through the gaps.

Audit your Drupal website with DrupalFit!

FAQs

Is WCAG 3.0 released yet?

No. It's still a W3C Working Draft, last updated March 2026, with no confirmed release date.

Is WCAG 2.1 AA a legal requirement?

It depends on your jurisdiction and sector, but most current regulations, including the ADA and the European Accessibility Act, reference WCAG 2.1 AA or WCAG 2.2 specifically.

Which version of WCAG should I use, 2.1 or 2.2?

WCAG 2.2, since it includes everything in 2.1 plus nine additional success criteria. There's no reason to build to the older version specifically.

How many success criteria does WCAG 2.2 have?

87 in total, including the nine new ones added on top of WCAG 2.1.