WCAG 2.2 Deep Dive: What Changed, What Is New, and How to Comply

WCAG 2.2 became an official W3C Recommendation in October 2023, and it is the standard that organizations are now expected to meet for digital accessibility compliance. If you have been working toward WCAG 2.1 compliance, the good news is that WCAG 2.2 is an evolution, not a revolution. It builds directly on 2.1 and adds nine new success criteria while removing one outdated criterion.

But that does not mean you can ignore it. The new criteria in WCAG 2.2 address real problems that affect real users every day. They focus on people who use keyboards, people who have motor impairments, people with cognitive disabilities, and people who struggle with authentication. In this deep dive, we will walk through every change in WCAG 2.2, explain what each new criterion means, and give you practical implementation guidance so you can bring your site up to the current standard.

For background on how we got here, see our comparison of WCAG 2.0 and WCAG 2.1.

What Is WCAG 2.2?

WCAG 2.2 is the latest published version of the Web Content Accessibility Guidelines, maintained by the W3C Web Accessibility Initiative (WAI). It is designed to be “backwards compatible” with WCAG 2.1, which means that if you already comply with WCAG 2.1, you only need to address the new criteria to reach 2.2 compliance. All of the existing 2.0 and 2.1 success criteria still apply.

The key areas of focus in WCAG 2.2 are:

• Focus visibility and appearance: Ensuring keyboard focus is visible and not hidden by other content.
• Target size: Making clickable elements large enough for people with motor impairments.
• Dragging movements: Providing alternatives to drag and drop interactions.
• Consistent help: Keeping help mechanisms in predictable locations.
• Redundant entry: Not asking users to re enter information they already provided.
• Accessible authentication: Making login processes usable without cognitive function tests.

These additions reflect years of research and feedback from users with disabilities, accessibility professionals, and organizations working to implement accessibility.

What Was Removed From WCAG 2.2

One success criterion was removed: 4.1.1 Parsing (Level A). This criterion required that HTML be parsed without errors, and it was originally added in WCAG 2.0 to address browser parsing inconsistencies. In practice, modern browsers handle HTML parsing consistently, and the criterion had become redundant with other requirements around valid HTML. The W3C determined that it was no longer providing meaningful accessibility benefits and removed it in 2.2.

If you were relying on 4.1.1 as part of your compliance baseline, you should replace it with robust HTML validation practices and testing. The removal does not mean valid HTML is unimportant. It means the W3C decided that other criteria and general good practice already cover the concerns 4.1.1 was meant to address.

The Nine New Success Criteria in WCAG 2.2

Let us walk through each new criterion, organized by the conformance level.

2.4.11 Focus Not Obscured (Minimum) - Level AA

What it requires: When a keyboard focus indicator is visible on a user interface component, some part of the focus indicator must remain visible while the element has focus. This means that if a sticky header, cookie banner, or floating widget covers part of the page, the focused element must not be entirely hidden.

Why it matters: Keyboard users navigate by moving focus from element to element. If a sticky element covers the focused element, the keyboard user loses their place on the page. They cannot see where they are, which makes navigation confusing and frustrating.

How to implement:

1. Make sure sticky headers, footers, and banners do not cover the focused element. Add scroll padding to your page so that focused elements have enough room below sticky elements.

2. Use the CSS scroll-padding property to account for sticky element heights:

html {
  scroll-padding-top: 80px;
}

3. When a user focuses an element, scroll it into view with enough margin that it is not hidden behind a sticky header or footer. You can use JavaScript with element.scrollIntoView() and the block: 'nearest' option.

4. Test by tabbing through your entire page with a sticky header visible. Make sure every focused element is at least partially visible.

2.4.12 Focus Not Obscured (Enhanced) - Level AAA

What it requires: The entire focus indicator must remain visible while the element has focus. This is a stricter version of 2.4.11 for organizations pursuing AAA conformance.

Why it matters: Even a partially obscured focus indicator can be hard to see. AAA compliance aims for the highest level of accessibility, so the focus indicator must be fully visible at all times.

How to implement: Follow the same steps as 2.4.11, but ensure that the full focus indicator (not just part of it) is visible. This may require more generous scroll padding or rethinking sticky elements that overlap content areas.

2.4.13 Focus Appearance - Level AAA

What it requires: The focus indicator must have a minimum size and contrast. Specifically, the focus indicator must be at least 2 CSS pixels thick and have at least a 3:1 contrast ratio against adjacent colors.

Why it matters: A thin, low contrast focus indicator is hard to see, especially for users with low vision. This criterion ensures the focus indicator is thick enough and contrasty enough to be clearly visible.

How to implement:

1. Use a clear, visible focus style. Do not rely on the browser default alone, since defaults vary across browsers.

2. Set a minimum focus outline thickness:

*:focus-visible {
  outline: 2px solid #000;
  outline-offset: 2px;
}

3. Choose a focus color that has at least 3:1 contrast against the adjacent background. Test with a contrast checker.

4. Do not set outline: none without providing an alternative visible focus style. Removing the outline without a replacement is one of the most common accessibility errors.

For more on keyboard navigation and focus, see our guide on keyboard accessibility.

2.5.7 Dragging Movements - Level AA

What it requires: If a user interface uses dragging (such as drag and drop, sliders that require dragging, or reordering lists by dragging), there must be an alternative that does not require dragging. The alternative can be a single click, a tap, a keyboard shortcut, or another method that works for users who cannot perform a dragging gesture.

Why it matters: Many users with motor impairments cannot perform dragging movements. A drag and drop interface that has no alternative effectively locks these users out. People using voice control, switch devices, or keyboards all need alternatives to dragging.

How to implement:

1. For drag and drop reordering, provide up and down buttons next to each item. The user can click or activate these buttons to move items instead of dragging.

2. For slider controls, provide a text input field where users can type a value directly.

3. For any custom drag interaction, add a keyboard accessible alternative. For example, if you have a Kanban board where users drag cards between columns, add a menu or button on each card that lets the user select a target column.

4. Test by navigating your interface entirely without dragging. Can you accomplish every task using only clicks, taps, or keyboard input?

2.5.8 Target Size (Minimum) - Level AA

What it requires: Clickable targets must be at least 24 by 24 CSS pixels, unless the target is inline text, is within a block of text, or meets an exception. There is also an exception for targets that have an equivalent target nearby that meets the size requirement.

Why it matters: Small clickable targets are hard for people with motor impairments to hit accurately. They are also difficult for anyone using a touchscreen, especially on mobile devices. A 24 by 24 pixel minimum ensures targets are large enough for most users.

How to implement:

1. Make sure buttons, links, icons, and other interactive elements have a clickable area of at least 24 by 24 CSS pixels. This does not mean the visible element must be 24px, but the clickable area should be.

2. Use padding to increase the clickable area without changing the visual size. For example:

.button {
  padding: 8px 16px;
  min-height: 24px;
  min-width: 24px;
}

3. For icon buttons, wrap the icon in a container that is at least 24 by 24 pixels. Add padding to the container if the icon itself is smaller.

4. Pay attention to closely spaced small targets, like pagination links or social media icons. These are common problem areas.

Note that WCAG 2.1 had a Level AAA criterion (2.5.5 Target Size) that required 44 by 44 CSS pixels. WCAG 2.2 introduced this Level AA version with a smaller minimum (24 by 24) to make it achievable for more organizations.

3.2.6 Consistent Help - Level A

What it requires: Help mechanisms (such as a contact link, email address, phone number, chat bot, or help page) must be presented in the same relative order on each page where they appear. This does not mean every page must have help, but where help is available on multiple pages, it must be in a consistent location.

Why it matters: Users with cognitive disabilities benefit from predictability. If the help link is in the top navigation on one page and buried in the footer on another, the user may struggle to find it when they need it. Consistent placement reduces cognitive load and makes the site easier to use.

How to implement:

1. Choose a consistent location for your help mechanism. Common locations are the top navigation, the footer, or a floating help button.

2. Use the same location on every page. If you have a “Contact Us” link in the header, keep it there on every page that has a header.

3. Do not rearrange help links depending on the page content. The help link should be in the same place whether the user is on the home page, a product page, or the about page.

4. Test by navigating to several pages and confirming that help links appear in the same relative location each time.

3.3.7 Redundant Entry - Level A

What it requires: Information that has already been entered or is available to the system must not be required to be entered again in the same process, unless it is for a specific security purpose or the information is needed for a different function.

Why it matters: Asking users to re enter information they already provided creates unnecessary cognitive load and effort. This is especially difficult for users with cognitive disabilities, users with motor impairments, and users on mobile devices where typing is slower. It also increases the chance of errors.

How to implement:

1. In multi step forms, carry forward previously entered data. If a user enters their shipping address in step 1, do not ask them to type it again in step 3. Instead, show it as pre filled or offer a checkbox to copy it from the shipping address.

2. Do not ask for the same information in multiple fields. For example, if a user already entered their email address during account creation, do not ask for it again on the next page.

3. Exceptions are allowed for security purposes. Requiring password confirmation during account creation is acceptable because it serves a security function. But asking for a name twice in a checkout process with no security justification is a violation.

4. Review your forms and look for any place where a user might be asked to type the same information twice. Remove the redundancy.

3.3.8 Accessible Authentication (Minimum) - Level AA

What it requires: Authentication processes must not rely on cognitive function tests. A cognitive function test is one that requires the user to remember, transcribe, or manipulate a sequence of characters or solve a puzzle. This includes memorizing a password, transcribing a distorted string of characters (CAPTCHA), or solving a math problem.

The criterion provides exceptions: the test can be used if it provides an alternative method that does not rely on cognitive function, or if the test involves recognizing objects or images rather than recalling them, or if the test is for recognizing non text content.

Why it matters: Traditional password entry is a cognitive function test. The user must remember a string of characters and type it accurately. For users with cognitive disabilities, this can be a significant barrier. CAPTCHAs that require transcribing distorted text are even worse.

How to implement:

1. Offer passwordless authentication. WebAuthn, passkeys, biometric authentication, and magic links via email or SMS all provide alternatives to password entry that do not rely on cognitive function tests.

2. If you must use passwords, allow password managers to work. Do not disable paste in password fields. Do not block autofill. Password managers reduce the cognitive burden by storing and entering credentials for the user.

3. Replace text based CAPTCHAs with alternatives. Consider invisible CAPTCHA (like reCAPTCHA v3 or Cloudflare Turnstile), which evaluates user behavior without requiring interaction. If a challenge is needed, use image based challenges (select all images with a traffic light) rather than text transcription.

4. Provide alternative authentication methods. If your primary method uses a cognitive test, offer at least one alternative that does not.

3.3.9 Accessible Authentication (Enhanced) - Level AAA

What it requires: This is the AAA version of accessible authentication. It goes further than 3.3.8 by removing more of the exceptions. Under this criterion, even object recognition tests are not allowed as the only method of authentication. An alternative that does not rely on cognitive function must be provided.

Why it matters: Some users cannot complete any type of challenge, even image based ones. AAA authentication requires a non cognitive alternative for everyone.

How to implement: Provide at least one authentication method that requires no cognitive test at all. This typically means passwordless authentication like passkeys or biometric login. The user authenticates through a device credential (like Face ID, Touch ID, or a security key) without needing to remember or recognize anything.

What Changed From WCAG 2.1 to 2.2: Summary

Here is a quick summary of the differences:

How to Prepare for WCAG 2.2 Compliance

Moving from WCAG 2.1 to 2.2 compliance is manageable if you approach it systematically. Here is a step by step plan.

Step 1: Audit Your Current State

Run an accessibility audit against WCAG 2.2 criteria. Start with an automated scan to identify obvious issues, then follow up with manual testing. Pay special attention to:

• Focus visibility on pages with sticky elements
• Clickable target sizes on interactive elements
• Drag and drop interactions that lack keyboard alternatives
• Help link consistency across pages
• Form fields that ask for redundant information
• Authentication methods

Step 2: Fix Focus Related Issues

Focus issues are the most common gap between 2.1 and 2.2 compliance. Check every page with sticky headers, sidebars, or floating elements. Tab through each page and confirm that the focused element is always visible.

Step 3: Enlarge Clickable Targets

Review your interactive elements. Anything smaller than 24 by 24 CSS pixels needs to be enlarged. Pay attention to icon buttons, close buttons, pagination links, and social media icons. Use padding to increase the clickable area without changing the visual design.

Step 4: Add Dragging Alternatives

If your site uses drag and drop, sliders, or other dragging interactions, add keyboard and click accessible alternatives. This is especially important for complex interfaces like Kanban boards, sortable lists, and interactive maps.

Step 5: Review Forms for Redundant Entry

Walk through your forms end to end. Look for any place where a user is asked to enter information they already provided. Remove the redundancy or offer a way to reuse previously entered data.

Step 6: Improve Authentication

If your login process relies on passwords and CAPTCHAs, add at least one alternative method. Passkeys and WebAuthn are the best options because they provide strong security without cognitive burden.

Step 7: Test With Real Users

Automated testing catches many issues, but manual testing with real users (including users with disabilities) catches the problems that tools miss. Test with keyboard only navigation, test with screen readers, and test on mobile devices.

For a comprehensive testing approach, see our guide on how to test the accessibility of your website.

Testing for WCAG 2.2

Testing for the new WCAG 2.2 criteria requires both automated and manual approaches. Here is what to test for each criterion.

Automated Testing

Automated accessibility tools can detect some WCAG 2.2 issues:

• Target size: Some tools can flag interactive elements that are smaller than 24 by 24 CSS pixels.
• Focus visibility: Some tools can detect when outline: none is set without a replacement focus style.
• Redundant entry: Tools may flag repeated form fields across multi step forms.

However, many of the new criteria require manual judgment. Automated tools cannot determine whether a dragging alternative exists or whether help links are consistently placed.

Manual Testing

For each new criterion, perform the following manual tests:

1. Focus Not Obscured: Tab through every page with sticky elements. Confirm that the focused element is never entirely hidden.
2. Focus Appearance: Visually inspect focus indicators. Confirm they are at least 2 CSS pixels thick with at least 3:1 contrast.
3. Dragging Movements: Attempt to use every drag interaction without dragging. Confirm that an alternative exists.
4. Target Size: Measure clickable areas on interactive elements. Confirm they are at least 24 by 24 CSS pixels.
5. Consistent Help: Navigate to multiple pages and confirm help links appear in the same relative location.
6. Redundant Entry: Walk through multi step forms. Confirm you are not asked to re enter information.
7. Accessible Authentication: Attempt to log in without typing a password or completing a CAPTCHA. Confirm an alternative exists.

Screen Reader Testing

Test with NVDA, JAWS, or VoiceOver to confirm that:

• Focus indicators and announcements work correctly with sticky elements
• Dragging alternatives are keyboard accessible and announced properly
• Authentication alternatives are announced and usable

For more on screen reader testing, see our guide on screen reader accessibility.

WCAG 2.2 Compliance Checklist

Use this checklist to verify your site meets WCAG 2.2:

• No interactive element has a clickable area smaller than 24 by 24 CSS pixels (2.5.8)
• Drag and drop interactions have keyboard or click alternatives (2.5.7)
• Focus indicators are visible and not entirely hidden by sticky elements (2.4.11)
• Focus indicators are fully visible on every page (2.4.12, AAA)
• Focus indicators are at least 2 CSS pixels thick with 3:1 contrast (2.4.13, AAA)
• Help links appear in the same relative location on every page (3.2.6)
• Forms do not require re entry of previously provided information (3.3.7)
• Authentication does not rely solely on cognitive function tests (3.3.8)
• A non cognitive authentication alternative is available (3.3.9, AAA)
• HTML is valid and well formed (good practice, 4.1.1 removed)
• Passwords can be pasted and password managers work without restrictions
• Text CAPTCHAs have been replaced with accessible alternatives
• All previous WCAG 2.0 and 2.1 criteria are still met

Common WCAG 2.2 Mistakes to Avoid

Here are the most common mistakes organizations make when implementing WCAG 2.2:

1. Assuming 2.1 compliance means 2.2 compliance. It does not. You still need to address the nine new criteria.

2. Removing focus outlines without replacements. Setting outline: none and not providing an alternative focus style violates multiple new criteria.

3. Tiny close buttons. Close buttons on modals, banners, and popups are often smaller than 24 by 24 pixels. Enlarge them with padding.

4. Drag only interactions. Sortable lists, Kanban boards, and sliders that only work with dragging lock out keyboard and motor impaired users.

5. Inconsistent help placement. Moving help links around between pages creates confusion for users with cognitive disabilities.

6. Asking for the same information twice. Multi step forms that require re entry of addresses, names, or other data violate 3.3.7.

7. Blocking password manager autofill. Disabling paste or autofill in password fields makes authentication harder and may violate 3.3.8.

8. Using text based CAPTCHAs. Distorted text CAPTCHAs are a cognitive function test and should be replaced with accessible alternatives.

9. Sticky headers that cover focused content. A common problem on long pages where the header overlaps content after scrolling.

10. Forgetting mobile testing. Several new criteria (target size, dragging movements) are especially relevant on touch devices. Test on real phones and tablets.

The Bottom Line

WCAG 2.2 is the current accessibility standard, and organizations should be working toward compliance with it. The nine new criteria address real user needs that were not fully covered by previous versions: better focus visibility, larger clickable targets, alternatives to dragging, consistent help, less redundant data entry, and more accessible authentication.

The path from 2.1 to 2.2 compliance is not overwhelming if you approach it systematically. Audit your site, fix focus issues, enlarge targets, add dragging alternatives, streamline forms, and improve authentication. Test with real tools and real users. These steps will make your site more accessible to the people who need it most.

For a broader view of where accessibility is heading this year, see our article on what is changing in web accessibility in 2026.

Ready to find out if your site meets WCAG 2.2? Do not guess when you can get a clear answer. Run a free accessibility scan with Accessible Metrics and get a detailed report that checks your website against the latest WCAG standards, including all the new 2.2 criteria. You will see exactly where your site stands, what needs fixing, and how to prioritize your accessibility work. Sign up for Accessible Metrics today and make your website work for everyone.