WCAG 2.2 New Success Criteria: Complete Implementation Guide

WCAG 2.2 new success criteria address usability gaps that WCAG 2.1 left unresolved—particularly for users with cognitive disabilities, low vision, and motor impairments. Released in October 2023, WCAG 2.2 adds nine new success criteria across Levels A, AA, and AAA, while removing one criterion from 2.1.

For organizations targeting WCAG 2.2 AA compliance, this means implementing six new requirements beyond WCAG 2.1 AA. Understanding these changes is essential for comprehensive accessibility—and for staying ahead of legal standards likely to adopt WCAG 2.2.

Q: What's new in WCAG 2.2?

A: WCAG 2.2 adds nine success criteria: Focus Not Obscured (Minimum and Enhanced), Focus Appearance, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry, and Accessible Authentication (Minimum and Enhanced). It removes 4.1.1 Parsing from 2.1.

WCAG 2.2 Overview

What Changed from WCAG 2.1

WCAG 2.2 is backward compatible—everything in WCAG 2.1 remains (except 4.1.1 Parsing). The additions address:

Cognitive accessibility: Reducing memory burden, providing consistent help, preventing redundant data entry

Motor accessibility: Easier touch targets, alternatives to dragging gestures

Low vision accessibility: Better focus visibility for keyboard navigation

Level Distribution

Level A additions (2):

• 2.4.11 Focus Not Obscured (Minimum)
• 3.3.7 Redundant Entry

Level AA additions (4):

• 2.4.12 Focus Not Obscured (Enhanced)
• 2.4.13 Focus Appearance
• 2.5.7 Dragging Movements
• 2.5.8 Target Size (Minimum)

Level AAA additions (3):

• 3.2.6 Consistent Help
• 3.3.8 Accessible Authentication (Minimum)
• 3.3.9 Accessible Authentication (Enhanced)

New Level A Criteria

2.4.11 Focus Not Obscured (Minimum)

Requirement: When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

What this means: Sticky headers, chat widgets, cookie banners, and other overlapping content can't completely hide focused elements. Users must be able to see at least part of what has focus.

Common violations:

• Fixed navigation covering focused links
• Chat widgets overlapping form fields
• Cookie consent banners hiding footer links
• Sticky CTAs covering interactive elements

Implementation:

/* Ensure sticky headers don't cover focused content */
.sticky-header {
  /* Account for header height in scroll padding */
}

html {
  scroll-padding-top: 80px; /* Height of sticky header */
}

/* Ensure focused elements scroll into view */
:focus {
  scroll-margin-top: 100px;
}

Testing: Tab through all interactive elements. Verify focused element is never completely hidden by sticky/fixed elements.

3.3.7 Redundant Entry

Requirement: Information previously entered by or provided to the user that is required to be entered again must be auto-populated or available for selection—unless re-entering is essential, the information is security-sensitive, or previously entered information is no longer valid.

What this means: Don't make users enter the same information twice in a process.

Common violations:

• Checkout requiring re-entry of shipping address for billing
• Multi-step forms asking for name/email on multiple pages
• Confirmation screens requiring re-entry of previously provided data
• Account creation flows repeating information requests

Implementation:

<!-- Auto-populate billing from shipping -->
<input type="checkbox" id="same-address">
<label for="same-address">Billing address same as shipping</label>

<!-- Pre-fill from previous step -->
<input type="email" value="${previouslyEnteredEmail}"
       aria-describedby="email-note">
<span id="email-note">Pre-filled from previous step</span>

E-commerce context: Checkout flows are primary concern. TestParty identifies redundant entry issues and provides fixes for Shopify and other e-commerce platforms.

New Level AA Criteria

2.4.12 Focus Not Obscured (Enhanced)

Requirement: When a component receives keyboard focus, no part of the component is hidden by author-created content.

Difference from Minimum: The minimum allows partial obscuring; enhanced requires the entire focused element to be visible.

Implementation: Same techniques as 2.4.11, but with stricter requirements. Focused elements must be completely visible, not just partially.

2.4.13 Focus Appearance

Requirement: When keyboard focus indicators are visible, they must meet specific size and contrast requirements:

• Focus indicator area at least as large as 2px thick perimeter of unfocused component
• Contrast ratio at least 3:1 between focused and unfocused states

What this means: Focus indicators must be clearly visible—thin dotted outlines often fail.

Common violations:

• Removing default focus outlines without replacement
• Low-contrast custom focus styles
• Focus indicators too thin to perceive
• Inconsistent focus styling across elements

Implementation:

/* WCAG 2.2 compliant focus indicator */
:focus {
  outline: 3px solid #005fcc; /* High contrast color */
  outline-offset: 2px;
}

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

/* Ensure visibility on dark backgrounds */
.dark-section :focus {
  outline-color: #ffffff;
  box-shadow: 0 0 0 3px #005fcc;
}

Never do this:

/* DON'T remove focus indicators */
:focus {
  outline: none; /* Accessibility failure */
}

2.5.7 Dragging Movements

Requirement: All functionality that uses dragging movements can be achieved with a single pointer without dragging, unless dragging is essential.

What this means: Drag-and-drop must have alternatives. Users with motor impairments may not be able to perform drag gestures.

Common violations:

• Sortable lists requiring drag-and-drop
• Image cropping interfaces
• Sliders without keyboard/touch alternatives
• File upload drop zones without click alternative
• Kanban boards with drag-only card movement

Implementation:

<!-- Sortable list with button alternatives -->
<ul role="list" aria-label="Sortable items">
  <li>
    <span>Item 1</span>
    <button aria-label="Move Item 1 up">↑</button>
    <button aria-label="Move Item 1 down">↓</button>
  </li>
</ul>

<!-- Slider with increment buttons -->
<div role="group" aria-label="Price range">
  <button aria-label="Decrease minimum price">−</button>
  <input type="range" aria-label="Minimum price">
  <button aria-label="Increase minimum price">+</button>
</div>

E-commerce context: Product image reordering, wishlist management, and cart quantity adjustments often use drag interfaces. TestParty identifies these and provides accessible alternatives.

2.5.8 Target Size (Minimum)

Requirement: Interactive targets must be at least 24×24 CSS pixels, with exceptions for:

• Inline targets (links within text)
• User agent controlled elements
• Essential presentations where size is legally/informationally required
• Spacing (target plus spacing equals 24px)

What this means: Buttons, links, and controls need adequate touch/click target size.

Common violations:

• Small icon buttons without adequate padding
• Tightly packed navigation links
• Tiny checkbox and radio inputs
• Close buttons on modals
• Social media icon links

Implementation:

/* Ensure minimum target size */
button,
a:not(.inline-link),
[role="button"] {
  min-width: 24px;
  min-height: 24px;
}

/* Icon buttons need explicit sizing */
.icon-button {
  width: 44px; /* Recommended for touch */
  height: 44px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

/* Spacing alternative */
.compact-nav a {
  padding: 12px; /* Creates 24px+ effective target */
}

Testing: Use browser developer tools to measure target sizes. Check touch targets on mobile devices.

New Level AAA Criteria

3.2.6 Consistent Help

Requirement: If help mechanisms (contact info, self-help, human contact) are provided on multiple pages, they must appear in the same relative order.

What this means: Help options should be predictably located across your site.

Implementation: Ensure footer help links, chat widgets, and support options maintain consistent positioning across all pages.

3.3.8 Accessible Authentication (Minimum)

Requirement: Cognitive function tests (remembering passwords, solving puzzles, recognizing objects) aren't required for authentication—unless alternatives exist:

• Alternative authentication method available
• Mechanism to assist user (password manager support)
• Object recognition uses personal objects

What this means: Don't rely solely on memory or cognitive tests for login.

Common violations:

• CAPTCHA without audio or alternative
• Security questions requiring recall
• Pattern-based authentication without alternative
• Image-based verification without accessible option

Implementation:

<!-- Support password managers -->
<input type="email"
       autocomplete="username email"
       aria-label="Email address">

<input type="password"
       autocomplete="current-password"
       aria-label="Password">

<!-- Provide CAPTCHA alternatives -->
<div role="group" aria-label="Verification">
  <p>Please complete one verification method:</p>
  <button>Audio CAPTCHA</button>
  <button>Email verification code</button>
</div>

3.3.9 Accessible Authentication (Enhanced)

Requirement: No cognitive function test required for any step of authentication, period. Object recognition and personal content recognition are not allowed even as alternatives.

Implementation: Use passwordless authentication, email magic links, or biometric alternatives where possible.

Removed Criterion: 4.1.1 Parsing

What was removed: 4.1.1 Parsing required valid HTML to ensure assistive technology compatibility.

Why removed: Modern browsers and assistive technologies handle parsing robustly. Validation errors rarely cause accessibility failures in practice.

What this means: You don't need perfect HTML validation for WCAG 2.2 compliance. Focus on semantic correctness and ARIA usage instead.

Implementation Priority

For WCAG 2.2 AA Compliance

Address these six criteria:

1. Focus Not Obscured (Minimum) - Quick wins adjusting sticky elements
2. Redundant Entry - Audit multi-step forms for repeated fields
3. Focus Appearance - Review and enhance focus indicators
4. Target Size - Audit button and link sizes
5. Dragging Movements - Add alternatives to drag interactions
6. Focus Not Obscured (Enhanced) - Complete the focus visibility work

Testing Approach

Automated detection: TestParty's scanning identifies many WCAG 2.2 violations—target size issues, missing focus indicators, problematic overlapping elements.

Manual verification: Some criteria require human testing—cognitive function tests, drag alternative adequacy, help mechanism consistency.

User testing: Actual users with disabilities provide the most accurate assessment of cognitive accessibility and usability improvements.

FAQ Section

Q: When will WCAG 2.2 be legally required?

A: The DOJ's 2024 rule specifies WCAG 2.1 AA. However, WCAG 2.2 AA provides better accessibility and will likely become the expected standard as regulations update. Implementing 2.2 now provides stronger compliance posture.

Q: Does WCAG 2.2 replace 2.1?

A: WCAG 2.2 is a superset of 2.1 (minus 4.1.1 Parsing). Meeting WCAG 2.2 means you meet 2.1. They're not competing standards—2.2 extends 2.1.

Q: Which new criteria have the biggest impact?

A: Target Size and Redundant Entry affect the most users on typical websites. Focus Appearance dramatically improves keyboard navigation. Dragging Movements impacts specific interface patterns.

Q: How do I test for WCAG 2.2?

A: TestParty's scanning includes WCAG 2.2 criteria. Supplement automated testing with keyboard navigation testing (focus criteria), mobile testing (target size), and form flow review (redundant entry).

Q: What about the removed 4.1.1 Parsing?

A: Its removal doesn't mean HTML quality is irrelevant—semantic markup and proper ARIA usage remain important. But minor validation errors no longer constitute WCAG failures.

Key Takeaways

• WCAG 2.2 adds nine criteria addressing cognitive, motor, and low vision accessibility gaps.

• Six criteria affect Level AA compliance—the standard most organizations target.

• Focus visibility improvements help keyboard users navigate confidently.

• Target size requirements improve touch and click usability for everyone.

• Redundant entry prohibition reduces friction in forms and checkout flows.

• Drag alternatives ensure motor-impaired users can access all functionality.

• 4.1.1 Parsing removal acknowledges modern browser robustness.

Conclusion

WCAG 2.2's new success criteria address real accessibility gaps—issues that users with disabilities encounter daily but previous guidelines didn't explicitly require fixing.

For e-commerce sites, the implications are significant. Checkout flows need redundant entry fixes. Touch targets need adequate sizing. Drag-based interfaces need alternatives. Focus indicators need enhancement.

TestParty's platform includes WCAG 2.2 AA scanning and generates specific code fixes for these new requirements. E-commerce sites get implementable changes. Development teams get CI/CD integration that catches 2.2 violations before deployment.

Ready for WCAG 2.2 compliance? Get a free accessibility scan to see how your site measures against the latest standards.

Related Articles:

• WCAG 2.2 vs 2.1: What Changed and Why It Matters
• Mobile Accessibility: Touch Target Requirements Guide

Written with AI assistance and reviewed by our accessibility team. Not legal advice—consult professionals for your specific compliance needs.