What’s New in WCAG 2.2: Changes and Updates from WCAG 2.1

The Web Content Accessibility Guidelines(opens in a new tab) (WCAG) provide a framework for creating digital content that’s accessible to all users and compliant with key accessibility laws. Following WCAG helps ensure everyone can use your digital content, expands your audience reach, and reduces legal risk. 

As the accessibility industry and technology continue to evolve, so do WCAG guidelines. The latest version, released in October 2023, furthers digital accessibility standards. Below, we break down what’s new in WCAG 2.2 and how to apply these updates to your digital content.

A series of four accessibility symbols fading into the distance, against a rainbow gradient background.

What is WCAG 2.2?

Published by the World Wide Web Consortium(opens in a new tab) (W3C), WCAG are international standards that explain how to make websites and digital content accessible to people with disabilities. The W3C originally published WCAG standards on May 5, 1999. As digital experiences evolve and become more sophisticated, the W3C updates the guidelines based on rigorous reviews, numerous rounds of revisions, and feedback from the public(opens in a new tab). Since being published, the W3C has announced three versions of the guidelines, each building on the previous version.

Each version of WCAG contains success criteria that are organized into three conformance levels:

• Level A: The minimum level of conformance, Level A contains basic success criteria for removing serious accessibility barriers that affect a wide range of users. 

• Level AA: Level AA success criterion removes additional barriers and establishes a level of accessibility that works for most users with disabilities and assistive technologies, including screen readers. 

• Level AAA: The most strict level of conformance, Level AAA contains additional success criteria to establish the highest possible level of accessibility. Claiming conformance to Level AAA means your site meets all WCAG success criteria.

Accessibility icon with the label 2.1 next to an accessibility icon with the label 2.2

What’s the Difference Between WCAG 2.1 and 2.2?

The key difference between WCAG 2.1 and WCAG 2.2 is focus. As of October 2025, WCAG 2.2 is the current W3C accessibility standard(opens in a new tab), and it places greater emphasis on usability — especially for keyboard navigation, touch interactions, and cognitive accessibility — while retaining existing WCAG 2.1 requirements.

The new WCAG 2.2 success criteria address common barriers users still encounter in real-world digital experiences, including obscured focus indicators, drag-only interactions, small touch targets, inconsistent help placement, and inaccessible authentication flows.

These updates improve accessibility across websites, mobile apps, online documents, and other digital content, while continuing to align with WCAG’s four principles: content must be perceivable, operable, understandable, and robust. 

It’s also important to note that WCAG 2.2 does not replace earlier versions of the guidelines. All success criteria from WCAG 2.1 (and WCAG 2.0) remain unchanged and fully applicable, with WCAG 2.2 simply building on that foundation.

New WCAG 2.2 Success Criteria Explained

With a better understanding of how WCAG 2.2 differs from previous versions, let’s examine the new criteria in WCAG 2.2(opens in a new tab).

2.4.11 Focus Not Obscured (Minimum)

This criterion(opens in a new tab) ensures that a visual keyboard focus indicator (like a border or highlight) is partially visible to users. Adding a focus indicator ensures that users can locate and interact with the focused component, such as buttons or links. 

When designing with fixed headers, sticky elements, or modals, ensure that keyboard focus does not fall behind obstructing UI. Developers can use JavaScript to scroll elements into view using ‘.scrollIntoView({block:”nearest”})’ or similar methods. CSS should also avoid fixed layouts that cover interactive elements without dynamically repositioning them. 

2.4.12 Focus Not Obscured (Enhanced)

Building on the minimum requirement, the enhanced criterion(opens in a new tab) calls for even more robust visual indicators for focus states. It requires the entire focus element to be completely visible without being obscured in any way. This encourages designers to use elements that stand out significantly, improving the visibility and clarity of focused items. 

To meet this requirement, developers should create interfaces that always scroll the focused item fully into view. Avoid partial visibility or overlapping UI components. Use JavaScript such as ‘.scrollIntoView({block:”center”})’ or implement custom scroll logic that ensures a fully visible focused target in all viewport sizes and orientations.

2.4.13 Focus Appearance

The 2.4.13 criterion(opens in a new tab) requires the visible indicator for any user interface component to meet minimum size and contrast requirements. Indicators must be at least as large as a 2-pixel-thick border around the component and must contrast with adjacent colors at a 3:1 ratio. 

When building focus indicators, use visible focus styles that do not rely solely on subtle outlines or box shadows. For example, a 2-pixel solid outline with sufficient color contrast or a background highlight satisfies conformance standards. Additionally, avoid removing focus indicator outlines via ‘outline: none’ unless a more accessible alternative is applied. 

2.5.7 Dragging Movements

The 2.5.7 criterion(opens in a new tab) requires that dragging actions completed by users be made accessible. For example, when a user drags an item to reorder it or interacts with a slider, alternative methods (such as buttons) should be available for those who are unable to perform the action. 

Developers should ensure these motions support alternative input methods like keyboard interaction (e.g., arrow keys or buttons for moving items) or typed input. For example, users can click arrows to move a list item up or down instead of requiring click-and-drag. This supports users with limited motor control who may struggle with precise pointer movements. 

2.5.8 Target Size (Minimum)

Interactive elements, such as buttons and links, must have a minimum target size(opens in a new tab) to ensure they can be easily tapped or clicked. Larger targets reduce the likelihood of errors and enhance the experience for assistive technology users. The success criterion recommends that interactive targets be at least 24 by 24 CSS pixels unless there is sufficient spacing around them or specific exceptions apply. 

To meet this requirement, ensure that tap-and-click targets meet the minimum size requirement either directly or through padding. If targets are smaller, ensure a minimum spacing of 24 pixels between them to reduce accidental activation. Use media queries and CSS to adapt target sizing for mobile and touch interfaces without disrupting the layout. 

3.2.6 Consistent Help

Consistent help(opens in a new tab) refers to the need for assistance and guidance features, like help mechanisms or FAQ sections, to appear in predictable locations across your website (unless the user initiates a change). That consistency helps users to quickly find help options and navigate your site more easily — something that particularly benefits individuals with cognitive disabilities. 

To conform, ensure help mechanisms like live chat buttons, support contact links, or FAQ access points are placed consistently on all applicable pages — visually and programmatically. The order and location should remain static within navigation regions unless the user customizes or rearranges them. Consistency in labeling and positioning enables users, particularly those with cognitive impairments, to anticipate where help is available. 

3.3.7 Redundant Entry

If users are required to input information in multiple fields, the 3.3.7 success criterion(opens in a new tab) requires multiple mechanisms to minimize redundancy. For example, information previously entered by the user should not need to be re-entered in the same session unless it is essential for security, the re-entry is user-initiated, or the information is no longer valid. 

To comply, techniques such as session storage or client-side memory must be implemented to preserve user input throughout a multi-step process. For example, if a user enters their address on one screen of a checkout form, the same data should auto-populate on subsequent screens if needed. This reduces unnecessary repetition, which can be especially burdensome for users with memory or mobility impairments.

3.3.8 Accessible Authentication (Minimum)

Accessible authentication(opens in a new tab) standards require that any forms of user authentication (such as login fields) be designed to accommodate users with disabilities. This may include providing options for different input methods, clear error messaging, authentication processes, and assistance for password recovery, ensuring users can access their accounts without any barriers. 

Meeting this requirement involves creating authentication methods that reduce cognitive load, such as allowing copy-and-paste functionality in password fields, integrating password managers, and offering passwordless login options (e.g., email-based one-time passcodes). If CAPTCHA is used, ensure that an alternative verification method is available that does not require solving a challenge that relies on memory, pattern recognition, or interpretation. 

3.3.9 Accessible Authentication (Enhanced)

The enhanced accessible authentication standard(opens in a new tab) builds on the basic requirements by requiring no cognitive function test for any step of authentication, unless a mechanism is available that does not require cognitive skills. 

To fully meet this requirement, eliminate reliance on traditional passwords and security questions where possible. Instead, provide alternatives such as biometric logins, secure authentication links sent via email or SMS, or trusted device recognition. This ensures users with cognitive disabilities can authenticate independently without the barrier of recalling or deciphering information.

Scale of justice holding WCAG 2.2 and WCAG 2.1 icons

Which WCAG Version Should You Follow?

As of the time of this writing, organizations should conform to the standards outlined in WCAG 2.2 Level AA to be compliant with laws like the Americans with Disabilities Act(opens in a new tab) (ADA), Section 508, or the Accessibility for Ontarians with Disabilities Act(opens in a new tab) (AODA). These guidelines address many of the most frustrating accessibility barriers, including:

• Missing alternative text (or alt text) on images or other non-text content, which impacts individuals with visual impairments such as blindness or low vision. 

• Missing video captions, audio descriptions, or transcripts, which may impact people with auditory disabilities, learning disabilities, and neurocognitive conditions. 

• Missing headings, subheadings, and title tags, which can make browsing more difficult for people who use screen readers. 

• “Keyboard traps,” which may make content unusable for people who don’t use a mouse to navigate web content.

Adhering to WCAG 2.2 standards enables you to stay compliant with key accessibility laws and prepare for future versions of WCAG, including WCAG 3.0. 

The First to WCAG Conformance: Test Your Content

As accessibility standards evolve, taking action early helps reduce risk and create better experiences for everyone. Following the guidance mentioned above puts you in a great position to meet WCAG 2.2 standards. 

AudioEye helps simplify what comes next. Our Accessibility Platform expertly combines automated testing with Expert Audits to find and fix accessibility issues, helping you create a more accessible, compliant online experience. The process starts with our free Web Accessibility Checker, which checks for 32 WCAG violations (more than any other tool on the market). These issues are automatically fixed via our Automated Fixes, streamlining your path to a more accessible experience.

Ready to take the next step? Scan your content now or schedule a demo to see how AudioEye supports WCAG conformance more quickly and efficiently.