What's New in WCAG 2.2: The 9 New Success Criteria Explained

Web accessibility standards do not stand still. As browsing habits shift toward mobile, more people rely on keyboard and voice navigation, and the gaps in older guidelines become clearer, the rules for building accessible websites are updated to keep pace. The most recent of those updates is WCAG 2.2(opens in a new tab).

One important distinction to make: WCAG 2.2 does not replace WCAG 2.0 or 2.1 — all three remain active standards. But the World Wide Web Consortium (W3C) recommends working towards the newest version, because it builds on everything before it. 

For most organizations, the question is “what changed in WCAG 2.2, and what do I have to do about it” rather than “what is WCAG 2.2”. If you already conform to WCAG 2.1 Level AA, you are most of the way there: WCAG 2.2 adds nine new success criteria and retires one, so the gap is small, but specific. 

Below, we’ll break down all nine new criteria, explain what changed from WCAG 2.1, and show how to check where your site falls short. 

The Evolution of the Web Content Accessibility Guidelines

WCAG has evolved steadily since the W3C published the first version in 1999. WCAG 2.0 (created in 2008) introduced the four principles of web accessibility and extended the guidelines to all digital content; WCAG 2.1 (created in 2018) added criteria for mobile and a wider range of disabilities; and WCAG 2.2, released in October 2023, adds the nine new success criteria covered below, focused on users with low vision, cognitive or learning disabilities, and limited motor skills.

WCAG 2.2: What’s New and Why It Matters

The nine additions sort into three conformance levels: A, AA, and AAA, which signal how far a site needs to go to conform, with most legal and organizational targets landing at Level AA. The breakdown below covers each new criterion: what it requires, who it helps, and why it matters in practice. 

WCAG 2.4.11: Focus Not Obscured (Minimum) (Level AA)

WCAG 2.4.11(opens in a new tab) requires that, when an element receives keyboard focus, at least part of it remains visible and isn’t completely hidden by other content, such as sticky headers or pop-ups. For sighted users who rely on a keyboard to browse websites, knowing the current focus is critical to navigating pages. However, focused elements can occasionally be obscured by other web elements. 

Adding a visible focus element can help improve focus and navigation for users with cognitive or visual impairments; however, the more visible the focus indicator is, the easier it is for users to follow as they navigate web pages.

WCAG 2.4.12: Focus Not Obscured (Enhanced) (Level AAA)

WCAG 2.4.12(opens in a new tab) goes further than 2.4.11, requiring that a keyboard-focused element be fully visible, with no part of it hidden by other content on the page. This ensures that the item being focused on is fully visible to the user, which improves navigation for those with limited or low vision. Users with attention limitations (such as short-term memory limitations) can also focus more easily when the entire focus is visible.

WCAG 2.4.13: Focus Appearance (Level AAA)

WCAG 2.4.13(opens in a new tab) requires focus indicators to be large enough and to have at least 3:1 color contrast between the focused and unfocused states, so users can clearly see which element is in focus. For example, when a link receives focus, an outline appears around it. The color of this outline should have sufficient contrast with the background color of the page.

Ensuring focus indicators have sufficient color contrast ensures users can easily see small changes in visual appearance. This is especially beneficial for older people or keyboard users, as they can easily track their position on a page while navigating.

WCAG 2.5.7: Dragging Movements (Level AA)

WCAG 2.5.7(opens in a new tab) requires that any action performed by dragging also have a single-pointer alternative, such as a tap or on-screen button, unless dragging is essential. For example, a website could enable the keyboard to use the up/down/left/right arrow keys or provide on-screen buttons that a user could press to move a slider or sort a list. This ensures that users who struggle with or cannot perform dragging movements can still operate within the drag-and-drop interface.

WCAG 2.5.8: Target Size (Minimum) (Level AA)

WCAG 2.5.8(opens in a new tab) requires clickable targets to be at least 24x24 CSS pixels in size, or to have sufficient spacing around them to prevent accidental activation. When buttons and other clickable elements are small, it’s difficult for people with hand tremors and other fine motor impairments to activate them without accidentally activating another element. 

This new capability allows individuals with fine-motor limitations to click buttons easily. It also enhances the mobile experience as users have enough spacing to select smaller buttons.

WCAG 3.2.6: Consistent Help (Level A)

WCAG 3.2.6(opens in a new tab) requires that help mechanisms, such as contact details or a chat option, appear in the same relative order on every page where they’re offered. For example, if a website has a ‘Chat’ option, it should appear in the lower right-hand corner of every page. Or contact details, including a phone number, hours of operation, or email address, are listed in the footer of each page.

By consistently listing helpful information in the same place, people who may have difficulty locating help or remembering where information is listed can find it more easily.

WCAG 3.3.7: Redundant Entry (Level A)

WCAG 3.3.7(opens in a new tab) requires that information a user has already entered in a process be auto-populated or available to select rather than asked for again. This saves users from repeatedly entering information, reduces the likelihood of mistakes, and reduces the need for text entry.

WCAG 3.3.8: Accessible Authentication (Minimum) (Level AA)

WCAG 3.3.8(opens in a new tab) requires that logins not depend on a cognitive function test(opens in a new tab), such as memorizing a password or solving a puzzle, unless an alternative method or assistance is available. This simplifies the authentication process for people with cognitive disabilities and allows them to authenticate in ways that suit their individual needs. One mechanism that can help with this is using password managers. These can help to reduce memory needs and the burden of re-typing information.

WCAG 3.3.9: Accessible Authentication (Enhanced) (Level AAA)

WCAG 3.3.9(opens in a new tab) applies the same rule as 3.3.8 but more strictly, disallowing object recognition or user-provided content (like an uploaded image) as authentication models. This ensures that users with cognitive issues related to memory, reading (dyslexia, for example), numbers, or perceptual-processing limitations can log on or authenticate easily.

What was Removed: 4.1.1 Parsing

WCAG 2.2 removed one criterion, 4.1.1 Parsing, marking the first time a success criterion has been retired from the guidelines. The criterion originally required clean, well-formed HTML markup, but W3C determined it was obsolete because modern browsers and assistive technologies now handle the markup errors it covered without issue. 

Removing it does not mean that valid HTML stopped mattering; well-structured markup still benefits accessibility and remains good practice. The practical effect is narrow: if your automated testing previously flagged parsing errors as a WCAG failure, those specific failures no longer count against 2.2 conformance.

WCAG 2.2 vs. WCAG 2.1: What Actually Changed

WCAG 2.2 is a superset of WCAG 2.1: it keeps every 2.1 success criterion except the retired 4.1.1 Parsing, then adds nine new ones. The practical consequence is the part worth knowing: meeting WCAG 2.2 also means you meet 2.1, so there's no trade-off in targeting the newer version. If you already conform to WCAG 2.1 Level AA, the real gap is just the six new Level A and AA criteria; the three Level AAA additions are optional. In short, moving from 2.1 to 2.2 isn't a rebuild — it's a short, defined punch list.

WCAG 2.2 Checklist (Level AA)

If you already meet WCAG 2.1 Level AA, these are the six new criteria to work through to reach WCAG 2.2 Level AA. The three Level AAA additions (2.4.12, 2.4.13, and 3.3.9) are optional.

• Keyboard focus stays visible (2.4.11): Tab through every page and confirm the focused element is never fully hidden behind sticky headers, cookie banners, or pop-ups.

• Dragging has an alternative (2.5.7): For any drag-and-drop action (sliders, reordering, map controls), provide a single-pointer option, such as tapping or on-screen buttons.

• Targets are big enough (2.5.8): Make sure clickable elements are at least 24×24 CSS pixels, or have enough spacing that adjacent targets aren't easy to hit by accident.

• Help is consistent (3.2.6): Place help mechanisms (e.g., contact links, chat, support info, etc.) in the same relative location on every page that offers them.

• Don't ask for the same info twice (3.3.7): Auto-populate or let users reuse information they've already entered earlier in the same process, unless re-entry is essential.

• Logins don't rely on memory or puzzles (3.3.8): Offer an accessible alternative wherever authentication requires a cognitive function test, such as remembering a password or solving a CAPTCHA.

Several of these, focus visibility, consistent help, and accessible authentication in particular, can't be fully verified by automated tools. A free accessibility scan is a fast way to surface where your site stands today.

How AudioEye Simplifies WCAG 2.2 Conformance

WCAG 2.2 sharpened accessibility rather than reinventing it, adding nine focused criteria that close real gaps for users navigating with a keyboard, managing logins, or working on mobile devices. The challenge for most organizations is verifying that their site actually meets it and keeping it there as standards keep evolving. 

That’s where the right approach matters: several WCAG 2.2 criteria, including focus visibility, consistent help, and accessible authentication, can’t be confirmed by automation alone.   

The AudioEye platform is built for exactly that pairing. AudioEye helps organizations meet WCAG 2.2 Level AA by pairing automated fixes at scale with certified expert and disability-community testing to verify the criteria automation can't confirm on its own. And with continuous monitoring, your site is checked as it changes, and issues get fixed faster, keeping pace with WCAG as it evolves rather than just where it stands today.

Ready to see where your site stands against WCAG 2.2? Use the free Website Accessibility Checker to find out. Or schedule a demo, and we’ll show you how AudioEye helps you meet accessibility standards and maintain them over time.