WCAG 2.x vs WCAG 3.0 – Key Differences and What to Do Now

WCAG 2.x has been the backbone of web accessibility for over a decade. But with the WCAG 3.0 working draft now actively being developed, many developers and organizations are asking: what is actually changing, and do I need to do anything about it now?

This article breaks down the key differences between WCAG 2.x and WCAG 3.0, explaining what those changes mean for WCAG compliance in practice. It also gives you a clear picture of what to do right now as the W3C continues to shape the next generation of web accessibility standards.

What is WCAG 3.0?

WCAG 3.0 will be the next major version of the Web Content Accessibility Guidelines, developed by the World Wide Web Consortium (W3C).

It is a successor to WCAG 2.2 and previous versions, but it does not deprecate them. WCAG 2.x remains valid and in use. Most legislation and compliance frameworks today reference WCAG 2.1 Level AA as the standard target, though some are beginning to adopt WCAG 2.2.

It is worth noting that WCAG 3.0 is still under active development. The structure, guidelines, and conformance model are all in draft, and the Working Group welcomes public comments on the proposed approach.

Why WCAG 3.0?

WCAG 2.x provided a model that stayed relevant for over 10 years. But changing technology and the changing needs of people with disabilities now require a new model to address content accessibility more comprehensively.

The internet has shifted from mostly static websites on desktop computers to mobile apps, voice assistants, smart TVs, and virtual reality. WCAG 3.0 is designed to ensure that digital accessibility keeps pace with the technology people actually use.

A quick recap of WCAG 2.x

WCAG 2.x is the current version of the Web Content Accessibility Guidelines.

It covers three releases: WCAG 2.0 (2008), WCAG 2.1 (2018), and WCAG 2.2 (2023), each building on the last by adding new requirements and closing gaps the previous version missed.

At its core, WCAG 2.x is built around four principles, known as the WCAG POUR principles:

• Perceivable: people can see or hear the content.
• Operable: people can navigate and interact with it.
• Understandable: people can make sense of it.
• Robust: it works across different devices and assistive technologies like screen readers.

Under each principle sit guidelines, which are broad goals.

For example, under Perceivable, one guideline is “provide text alternatives for non-text content.”

Guidelines are then broken down into success criteria, which are the specific, testable rules that content must meet.

For example, success criterion 1.1.1 requires that every image has a text alternative. These are the actual checkpoints that developers and testers work against.

The standard uses three conformance levels to indicate how accessible something is:

• Level A: the bare minimum
• Level AA: what most organisations aim for and what most accessibility laws reference
• Level AAA: the most stringent level, rarely required in full due to how difficult it is to achieve across an entire product

WCAG 2.x remains the legal benchmark in most countries today. However, it was designed primarily with traditional websites in mind. Its testing model is binary: you either meet a requirement or you do not. This leaves little room for nuance.

As digital products have grown more complex, these limitations have become harder to ignore, which is exactly what set the stage for WCAG 3.0.

WCAG 2.x vs WCAG 3.0 – Key differences

The key differences between WCAG 2.x and WCAG 3.0 come down to four fundamental changes:

1. Success criteria are replaced by plain language outcome statements with a layered structure.
2. Conformance levels A/AA/AAA are replaced by Bronze/Silver/Gold.
3. Testing goes beyond pass or fail with distinct quantifiable and qualitative test types.
4. The scope expands significantly to cover more disability needs, emerging technologies, and user-generated content.

Here’s a closer look at each.

#1. Success criteria are replaced by outcomes

In WCAG 2.x, accessibility is defined through Success Criteria: specific, testable statements that content must meet. Each criterion is written as a precise technical rule with a clear pass or fail result.

WCAG 3.0 replaces these with a layered structure. It separates two types of guidance:

• Normative: required for conformance
• Informative: supports implementation but does not affect conformance

At the top are Guidelines, written as plain language outcome statements describing what the user should be able to do or experience. Guidelines are normative. Underneath each Guideline sit:

• Core Requirements: normative, must be met for base level conformance.
• Supplemental Requirements: normative, but selectable depending on the conformance level being targeted.
• Methods: informative, technology-specific guidance on how to meet the requirements.
• Best practices: informative, additional guidance that improves accessibility but does not affect conformance.

Take text readability as an example (note: this is illustrative only; the actual WCAG 3.0 guidelines are still in draft and may differ):

• WCAG 2.x: “Text has a contrast ratio of at least 4.5:1” — a precise rule with a measurable threshold
• WCAG 3.0: the Guideline (outcome) says “Users can read the text.” Underneath:
  • Core Requirement: text must meet a minimum contrast ratio.
  • Supplemental Requirement: text must also meet minimum size and spacing thresholds.
  • Method: how to measure contrast in HTML, or in a mobile app, or in a PDF.
  • Best practice: avoid text overlaid on complex background images, even if the contrast ratio technically passes.

This shift matters because it makes the guidelines more approachable for non-technical audiences like managers and policy makers, while still providing the technical detail that developers need through the layers underneath.

#2. A, AA, and AAA are replaced with bronze, silver, and gold

WCAG 2.x uses three conformance levels: A (minimum), AA (standard target for most organizations), and AAA (highest). Each level is additive, meaning AA requires meeting all A criteria, and AAA requires meeting all AA criteria.

WCAG 3.0 replaces this with Bronze, Silver, and Gold. The structure works differently:

• Bronze: meets all Core Requirements, the non-negotiable foundations that cover a similar but not identical set of needs as WCAG 2.x Level AA.
• Silver: meets all Core Requirements plus a larger portion of Supplemental Requirements, which build on the core set with stricter or higher levels of accessibility.
• Gold: meets all Core Requirements plus an even larger portion of Supplemental Requirements than Silver, including requirements that may involve documented processes and testing with real users.

Take video content as an example:

• Bronze: the video has captions that accurately represent the spoken dialogue.
• Silver: the video also includes an audio description track, narrating visual content that is not conveyed through dialogue alone, such as on-screen text or important actions.
• Gold: the video additionally provides a signed language interpretation, making the content fully accessible to users for whom signed language is their primary language.

WCAG 2.x	WCAG 3.0	Description
Level A	–	No direct equivalent. Bronze covers a broader baseline.
Level AA	Bronze	The minimum conformance level in WCAG 3.0
Level AAA	Silver / Gold	Higher levels requiring supplemental requirements and assertions

#3. Testing goes beyond pass/fail

In WCAG 2.x, testing is essentially binary: a criterion is either met, or it isn’t. Pass or fail.

While simple, this model misses a lot. A page could technically pass a check (the alt attribute exists) while still being inaccessible in practice (the alt text says "img_23847.jpg").

WCAG 3.0 addresses this by introducing two distinct types of tests.

Quantifiable tests are consistent, reliable, and often automatable. Different testers will always get the same result because the answer is measurable. They produce consistent results across different tools and testers. To illustrate, here are two quantifiable WCAG 2.x success criteria:

• 1.1.1 “Image has non-empty accessible name”: either the accessible name exists, or it doesn’t.
• 1.4.3 “Text has minimum contrast”: the ratio either meets the threshold or it doesn’t.

Qualitative tests rely on human judgment, and results can vary between testers. WCAG 3.0 formally acknowledges that this variation is expected, and provides structured guidance to reduce it. Here are examples of qualitative tests, also drawn from WCAG 2.x criteria:

• 1.1.1 “Image accessible name is descriptive”: a tester must judge whether it actually communicates the image’s meaning.
• 2.4.6 “Form field label is descriptive”: “First name” clearly passes, but “Name” requires a judgment call.

The difference from WCAG 2.x isn’t in the content being checked.

WCAG 2.x already tested for contrast ratios and descriptive labels, but it didn’t formally distinguish how those tests work. A pass/fail result was a pass/fail result, regardless of whether it came from a measurement or a judgment call.

WCAG 3.0 separates the two explicitly, which matters because it allows the guidelines to provide the right kind of guidance for each: precise thresholds and automatable rules for quantifiable tests, and structured criteria to align human judgment for qualitative ones.

Finally, WCAG 3.0 introduces a clearer definition of what gets tested. Rather than testing pages in isolation as WCAG 2.x did, it breaks the scope into four levels:

• Items: the smallest testable unit, such as a button, a link, an image, or an error message.
• Views: all content available without a significant change, similar to a web page in WCAG 2.x, but broader, covering mobile screens and modal dialogs too.
• Task flows: a series of views that support a specific user activity, such as logging in, completing a purchase, or submitting a form. Only the parts relevant to that activity are included in the test.
• Product: the combination of all items, views, and task flows that make up the full website or app.

This layered scope means testing in WCAG 3.0 can be more targeted and realistic, focused on what a user actually does rather than just individual pages in isolation.

#4. It covers more ground

WCAG 2.x has held up well, but it wasn’t built with modern needs in mind. WCAG 3.0 expands coverage in three key areas:

• More disability needs: WCAG 2.x success criteria are largely true/false statements, which work well for visual, auditory, and motor disabilities but fall short for cognitive disabilities, learning disabilities, and low vision, where accessibility is harder to measure in a simple pass/fail way. WCAG 3.0 is designed to accommodate these more nuanced needs.
• Emerging technologies: platforms like extended reality (XR) — including augmented, virtual, and mixed reality — and voice assistants didn’t exist when WCAG 2.x was written. WCAG 3.0 is built with these in mind from the start.
• User-generated content: when users post inaccessible content, such as images without alt text or videos without captions, WCAG 2.x offers little guidance on publisher responsibility. WCAG 3.0 addresses this directly.

Also, WCAG 3.0 provides advisory guidance across the full accessibility technology stack, including authoring tools, browsers, video and audio media players, screen readers, mobile apps, and operating systems.

This is informational rather than normative. WCAG 3.0 does not write separate specifications or requirements for these technologies, but offers guidance that they can choose to adopt to better support accessibility.

When will WCAG 3.0 be ready?

WCAG 3.0 has been in development since 2016, when the W3C’s Silver Task Force began researching requirements for the next major version of the guidelines. The current timeline suggests it will not be published anytime before 2028.

The W3C standards process moves through four stages before a standard is officially published (note: this is a simplified overview of the full W3C process):

1. First working draft: published January 2021.
2. Revised working draft: currently at this stage, most recently updated in March 2026. Further revisions are expected before moving to the next stage.
3. Candidate recommendation: estimated for Q4 2027, based on the current working timeline.
4. W3C recommendation: the final, officially endorsed specification, likely not expected before 2028 at the earliest.

Even reaching stage 3 does not mean the standard is settled. There may still be significant changes at the candidate recommendation stage before it becomes an official W3C recommendation.

As for legal adoption, the timeline is even longer.

WCAG 2.1 took several years after its 2018 publication before most legislation formally referenced it. WCAG 2.2, published in 2023, has not yet been widely codified into legislation, with most countries still referencing WCAG 2.1 Level AA as the legal standard. Given that WCAG 3.0 represents a far more significant shift, legislative adoption is realistically well beyond 2028.

How to prepare your website for WCAG 3.0

Given that WCAG 3.0 is still several years away from being published, and legal adoption will take even longer, there is no need to panic. The best preparation is to build good accessibility habits now that will carry forward into WCAG 3.0 naturally.

Start with WCAG 2.1 Level AA

WCAG 3.0 is designed to build on WCAG 2.x, not replace it. Organizations that already meet WCAG 2.1 Level AA will have a solid foundation to work from. If you are not there yet, that is the right place to start.

Understand the shift from rules to outcomes

WCAG 3.0 moves away from specific technical rules toward broader outcome statements. Start thinking about accessibility in terms of user experience rather than just checkboxes. Ask not just “does this pass the rule?” but “can this person actually use this?”

Go beyond automated testing

WCAG 3.0 places greater emphasis on qualitative testing, which requires human judgment. Start building human review into your accessibility testing process now, alongside automated tools. Better still, test with real users with disabilities.

Think in task flows, not just pages

WCAG 3.0 introduces task flows as a unit of testing: a series of steps a user takes to complete a specific activity, such as signing up, checking out, or submitting a form. Start evaluating accessibility across these complete user journeys rather than testing individual pages in isolation.

Stay informed

WCAG 3.0 is still being shaped. Following the working drafts and understanding the direction of travel means you will not be caught off guard when it is eventually published.

FAQs