WCAG 2.2: A Guide to the Latest Web Accessibility Standard

WCAG 2.2 became a W3C Recommendation in October 2023 and added 9 new success criteria to the previous version. While the changes may seem incremental, they represent an important step forward in making websites and digital experiences more accessible for people with disabilities.

For organizations that design, develop, or manage websites, WCAG 2.2 is more than a technical update. It is now the benchmark referenced by many accessibility laws, regulations, and legal decisions worldwide, including ADA-related case law in the United States, the European Accessibility Act (EAA), and AODA Phase 2 requirements in Canada. 

This guide explains what WCAG 2.2 is, explores the new success criteria, and outlines the practical steps needed to achieve and maintain compliance.

What is WCAG 2.2?

TL;DR: WCAG 2.2 is the latest version of the Web Content Accessibility Guidelines published by the W3C. Released as a W3C Recommendation on 5 October 2023, it adds nine new Success Criteria while remaining fully backward-compatible with WCAG 2.1 and WCAG 2.0. 

WCAG 2.2 (Web Content Accessibility Guidelines) is the latest version of the internationally recognised standards for web accessibility, published by the World Wide Web Consortium (W3C). 

The guidelines provide a framework for making websites, applications, and other digital content accessible to people with disabilities, including those with visual, auditory, cognitive, speech, and motor impairments.

WCAG 2.2 became an official W3C Recommendation on 5 October 2023. It builds on the previous versions, WCAG 2.1 and WCAG 2.0, by introducing nine new Success Criteria designed to address accessibility challenges that were not fully covered in earlier standards.

One of the key advantages of WCAG 2.2 is that it is fully backward-compatible with WCAG 2.1 and 2.0. This means organizations that already comply with earlier versions do not need to start over. Instead, they can focus on meeting the additional requirements introduced in WCAG 2.2.

WCAG 2.2 Conformance Levels (A, AA, AAA)

WCAG 2.2 is organised into three conformance levels: A, AA, and AAA. Each level builds on the previous one, with additional requirements designed to improve accessibility for a wider range of users.

Level A: Minimum Accessibility Requirements

Level A represents the most basic level of accessibility. It addresses barriers that could make a website impossible or extremely difficult for some people with disabilities to use. Failure to meet Level A requirements can prevent users from accessing content altogether.

Examples include providing text alternatives for non-text content, ensuring keyboard accessibility, and avoiding content that may trigger seizures.

Level AA: The Industry Standard

Level AA includes all Level A requirements plus additional criteria that improve usability and accessibility for a broader audience. These requirements address issues such as color contrast, text resizing, consistent navigation, error identification, and focus visibility.

For most organisations, WCAG 2.2 Level AA is the most important target because it is the level referenced by the majority of accessibility laws, regulations, procurement requirements, and legal settlements. 

When legislation, policies, or contracts require “WCAG compliance,” they almost always mean WCAG 2.2 AA unless otherwise specified.

Level AAA: Enhanced Accessibility

Level AAA is the highest level of conformance and includes all Level A and AA requirements plus additional criteria that provide an even more accessible experience. Examples include stricter contrast requirements, enhanced support for users with cognitive disabilities, and additional alternatives for content.

While AAA can be a valuable goal for specific content or user groups, it is rarely required by law and is generally not expected across an entire website. The W3C itself notes that it is not possible for many types of content to satisfy every AAA Success Criterion.

What’s New in WCAG 2.2? (The 9 New Success Criteria)

Most of the WCAG 2.2 additions focus on making websites easier to navigate, interact with, and authenticate without unnecessary barriers.

2.4.11 Focus Not Obscured (Minimum) — Level AA

When users navigate a website using a keyboard, the element that currently has focus must not be completely hidden by other content.

For example, if a user tabs through a form and a sticky header covers the selected field, they may not know where they are on the page. Under this criterion, the focused element must remain at least partially visible so users can continue navigating confidently.

2.4.12 Focus Not Obscured (Enhanced) — Level AAA

This enhanced version goes a step further by requiring that the focused element is not hidden at all by author-created content.

For example, a keyboard user tabbing through a navigation menu should always be able to see the entire focused link or button, even when floating banners, chat widgets, or sticky navigation bars are present.

2.4.13 Focus Appearance — Level AAA

Keyboard focus indicators must be clearly visible and easy to identify.

Many websites rely on faint outlines or subtle color changes that can be difficult to see. WCAG 2.2 requires a more prominent visual indicator, such as a thick border or high-contrast highlight, so users can quickly identify which element is currently selected.

2.5.7 Dragging Movements — Level AA

Any action that requires dragging must also be achievable through a simpler method that does not rely on drag-and-drop functionality.

For example, if users can rearrange items in a task management app by dragging them, they should also be able to move items using buttons, menus, or keyboard controls. This helps users with mobility impairments or those using assistive technology.

2.5.8 Target Size (Minimum) — Level AA

Interactive controls must have a minimum target size of 24 × 24 CSS pixels, unless a specific exception applies.

Small buttons and links can be difficult to activate accurately, especially for users with limited dexterity or those using touchscreens. Increasing target sizes reduces accidental clicks and makes interfaces easier to use across devices.

3.2.6 Consistent Help — Level A

If a website provides help mechanisms, they must appear in a consistent location across pages where they are available.

For example, if customer support, live chat, or contact information appears in the bottom-right corner on one page, it should remain in the same location throughout the site. Consistency makes it easier for users to find assistance when needed.

3.3.7 Redundant Entry — Level A

Users should not be required to enter the same information multiple times during a process unless doing so is essential.

For example, if a user enters their shipping address during checkout, the website should automatically offer that information for billing purposes instead of requiring it to be typed again. This reduces cognitive load and user frustration.

3.3.8 Accessible Authentication (Minimum) — Level AA

Authentication processes must not rely solely on cognitive function tests unless an accessible alternative is provided.

For example, users should not be required to memorize complex passwords, solve puzzles, or transcribe distorted characters from memory without another accessible option. Password managers, copy-and-paste functionality, and biometric authentication can help satisfy this requirement.

3.3.9 Accessible Authentication (Enhanced) — Level AAA

The enhanced version further reduces reliance on memory, problem-solving, and other cognitive tasks during authentication.

For example, users should be able to log in using methods such as password managers, passkeys, biometrics, magic links, or one-time codes without needing to complete complex cognitive challenges. This creates a more inclusive experience for users with cognitive disabilities.

A Note About 4.1.1 Parsing

While WCAG 2.2 adds nine new Success Criteria, it also removes one existing criterion: 4.1.1 Parsing.

This criterion previously required content to be free of major HTML parsing errors that could interfere with assistive technologies. 

It was removed because modern browsers and accessibility tools have become far more robust at handling markup issues, and the requirement was considered largely redundant. Its removal does not mean developers should ignore code quality, though. Valid, semantic HTML remains an accessibility best practice.

WCAG 2.2 vs WCAG 2.1: What Changed?

The core principles of accessibility remain unchanged. Websites must still be perceivable, operable, understandable, and robust (the POUR principles). The main difference is that WCAG 2.2 places greater emphasis on usability for people with cognitive disabilities, limited mobility, and low vision.

WCAG 2.1 vs WCAG 2.2 at a Glance

If You’re Already WCAG 2.1 AA Compliant, What Needs to Change?

The good news is that a website that genuinely meets WCAG 2.1 Level AA is already very close to WCAG 2.2 Level AA compliance.

To upgrade from WCAG 2.1 AA to WCAG 2.2 AA, you’ll primarily need to address the six new Level A and Level AA requirements:

• 2.4.11 Focus Not Obscured (Minimum)
• 2.5.7 Dragging Movements
• 2.5.8 Target Size (Minimum)
• 3.2.6 Consistent Help
• 3.3.7 Redundant Entry
• 3.3.8 Accessible Authentication (Minimum)

In practice, this involves reviewing:

• Sticky headers, pop-ups, cookie banners, and chat widgets that may hide keyboard focus.
• Drag-and-drop interfaces that lack alternative controls.
• Small buttons, icons, and touch targets.
• The consistency of help and support features across the website.
• Forms that repeatedly ask users to enter the same information.
• Login and authentication processes that rely heavily on memory, puzzles, or manual transcription.

Authentication systems and interactive user interfaces usually require the most attention. Standard content pages, blog posts, and informational pages often need few or no changes if they already comply with WCAG 2.1 AA.

Is WCAG 2.2 Legally Required?

WCAG 2.2 itself is not a law. It is a technical standard published by the W3C that provides guidance on how to make digital content accessible. 

However, many accessibility laws, regulations, and legal frameworks around the world, particularly the ADA, either directly reference WCAG or use it as the benchmark for demonstrating compliance.

United States: ADA Title III

The Americans with Disabilities Act (ADA) does not explicitly name a specific WCAG version. However, courts, settlements, and the Department of Justice guidance mostly rely on WCAG as the accepted standard for web accessibility. 

As organizations update their accessibility programmes, WCAG 2.2 is becoming the preferred benchmark for demonstrating compliance with ADA expectations.

European Union: European Accessibility Act (EAA)

The European Accessibility Act (EAA), which became enforceable in June 2025, requires many digital products and services to be accessible. Compliance is generally assessed through EN 301 549, the European accessibility standard, which has been updated to align with WCAG 2.2 requirements.

United States Federal Government: Section 508

Section 508 applies to U.S. federal agencies and certain government contractors. While accessibility requirements continue to evolve, the current Section 508 standards still reference WCAG 2.0 Level AA rather than WCAG 2.2. This reflects the slower pace at which government regulations are updated.

Canada: AODA

Ontario’s Accessibility for Ontarians with Disabilities Act (AODA) has historically referenced WCAG 2.0. However, accessibility standards are being reviewed and updated, with WCAG 2.2 expected to become the future benchmark for digital accessibility compliance.

How to Test Your Site for WCAG 2.2 Compliance

The best way to achieve WCAG 2.2 compliance is to combine automated and manual testing. 

Start with Automated Testing

ACE™ Scanner can quickly identify problems such as missing alternative text, color contrast failures, empty links, form errors, and certain coding issues.

Automated testing is an excellent first step because it helps uncover issues across large numbers of pages efficiently.

Perform Manual Accessibility Testing

Many WCAG 2.2 requirements cannot be reliably evaluated by automated tools alone, which is where manual testing comes in. 

At a minimum, test your website by:

• Navigating every page using only a keyboard (without a mouse).
• Verifying that focus indicators are clearly visible.
• Checking that interactive elements are easy to select and operate.
• Testing forms, checkout processes, and login workflows.
• Using screen readers to ensure content is announced correctly and navigation makes sense.

Include Real Users Where Possible

The most effective accessibility testing includes feedback from people who use assistive technologies in their daily lives. Real-world testing often reveals usability issues that neither automated tools nor technical audits identify.

Conclusion

WCAG 2.2 builds on the foundation established by WCAG 2.0 and 2.1, introducing nine new Success Criteria that make digital experiences more accessible for people with cognitive disabilities, low vision, and mobility impairments. 

While the changes are relatively focused, they reflect the growing expectation that websites and applications should be usable by everyone, regardless of ability.

For organizations already meeting WCAG 2.1 AA, the transition to WCAG 2.2 AA is often a matter of addressing a handful of new requirements rather than undertaking a complete accessibility overhaul. 

Most importantly, WCAG 2.2 is rapidly becoming the accessibility benchmark referenced by regulators, courts, procurement standards, and industry best practices worldwide. By adopting WCAG 2.2 AA now, you can reduce legal risk, improve user experience, and demonstrate a genuine commitment to digital inclusion.

FAQs