WCAG 2.2 vs 2.1: Complete Comparison of New Success Criteria

WCAG 2.2, published by the W3C in October 2023, represents the current version of the Web Content Accessibility Guidelines. Organizations targeting WCAG compliance need to understand what changed from WCAG 2.1 and how these changes affect their accessibility requirements.

This guide provides a comprehensive comparison of WCAG 2.2 and WCAG 2.1: the new success criteria added, the one criterion removed, and practical guidance for updating compliance programs to the current standard.

Understanding WCAG Version Progression

The Web Content Accessibility Guidelines have evolved through several versions:

WCAG 2.0 (2008): Original version with 61 success criteria across four principles (POUR: Perceivable, Operable, Understandable, Robust).

WCAG 2.1 (2018): Added 17 new success criteria, primarily addressing mobile accessibility, low vision, and cognitive disabilities. Total: 78 success criteria.

WCAG 2.2 (2023): Added 9 new success criteria, removed 1, focusing on cognitive accessibility and improved user authentication. Total: 86 success criteria.

Each version builds on the previous—WCAG 2.2 includes all of WCAG 2.1, which includes all of WCAG 2.0. Conformance to WCAG 2.2 automatically means conformance to earlier versions.

For a complete overview of WCAG fundamentals, see our What is WCAG 2.2 guide.

Summary of Changes: 2.1 to 2.2

New Success Criteria in WCAG 2.2

WCAG 2.2 introduces 9 new success criteria:

| Criterion                                  | Level | Focus Area              |
|--------------------------------------------|-------|-------------------------|
| 2.4.11 Focus Not Obscured (Minimum)        | AA    | Keyboard navigation     |
| 2.4.12 Focus Not Obscured (Enhanced)       | AAA   | Keyboard navigation     |
| 2.4.13 Focus Appearance                    | AAA   | Focus visibility        |
| 2.5.7 Dragging Movements                   | AA    | Motor accessibility     |
| 2.5.8 Target Size (Minimum)                | AA    | Motor accessibility     |
| 3.2.6 Consistent Help                      | A     | Cognitive accessibility |
| 3.3.7 Redundant Entry                      | A     | Cognitive accessibility |
| 3.3.8 Accessible Authentication (Minimum)  | AA    | Cognitive accessibility |
| 3.3.9 Accessible Authentication (Enhanced) | AAA   | Cognitive accessibility |

Removed Success Criterion

4.1.1 Parsing (removed): This criterion required valid HTML markup. It was removed because:

• Modern browsers are highly tolerant of markup errors
• Assistive technologies no longer rely on parsing validity
• Related issues are covered by other criteria (4.1.2 Name, Role, Value)

Net Impact for Level AA Compliance

Organizations targeting Level AA conformance see the following changes:

• Added: 5 new AA-level criteria
• Added: 2 new A-level criteria (included in AA conformance)
• Removed: 1 AA-level criterion (4.1.1 Parsing)

Net change: 6 additional requirements for Level AA conformance.

New WCAG 2.2 Success Criteria: Detailed Analysis

2.4.11 Focus Not Obscured (Minimum) — Level AA

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

What This Means: When users navigate via keyboard, the focused element must remain at least partially visible. Sticky headers, chat widgets, cookie banners, and other fixed-position elements cannot completely cover the currently focused item.

Common Violations:

• Sticky navigation bars covering focused content as users scroll
• Cookie consent banners overlaying page content
• Chat widgets positioned over interactive elements
• Floating "back to top" buttons covering form fields

Implementation:

• Ensure fixed-position elements don't cover focused content
• Use scroll-padding or scroll-margin to account for sticky headers
• Position overlays to avoid interactive content areas
• Test keyboard navigation with all persistent UI elements visible

Code Example:

/* Account for sticky header when focusing elements */
html {
  scroll-padding-top: 80px; /* Height of sticky header */
}

/* Or use scroll-margin on focusable elements */
:focus {
  scroll-margin-top: 80px;
}

2.4.12 Focus Not Obscured (Enhanced) — Level AAA

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

Difference from 2.4.11: The minimum (AA) requirement allows partial visibility—the enhanced (AAA) requirement demands complete visibility of the focused element.

2.4.13 Focus Appearance — Level AAA

Requirement: When the keyboard focus indicator is visible, the focus indicator area is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component, and has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.

What This Means: Focus indicators must be sufficiently visible—meeting minimum size and contrast requirements. This ensures keyboard users can clearly see which element has focus.

Note: This is Level AAA, not required for standard compliance but recommended for optimal accessibility.

2.5.7 Dragging Movements — Level AA

Requirement: All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential.

What This Means: If users can drag something (drag-and-drop, sliders, sortable lists), they must also be able to accomplish the same task without dragging—through clicking, tapping, or other single-pointer actions.

Common Violations:

• Drag-and-drop file uploads with no click alternative
• Sortable lists requiring drag to reorder
• Sliders with no increment/decrement buttons
• Map panning with no alternative navigation

Implementation:

• Provide click/tap alternatives for all drag operations
• Add arrow buttons or input fields for slider controls
• Include "move up/down" buttons for sortable lists
• Offer keyboard controls for map navigation

Example Solutions:

For a slider:

<!-- Bad: Drag-only slider -->
<input type="range" min="0" max="100">

<!-- Good: Slider with increment/decrement buttons -->
<button aria-label="Decrease value">−</button>
<input type="range" min="0" max="100">
<button aria-label="Increase value">+</button>

For sortable lists:

<!-- Good: Reorder buttons alongside drag-and-drop -->
<li>
  <span>Item 1</span>
  <button aria-label="Move up">↑</button>
  <button aria-label="Move down">↓</button>
</li>

2.5.8 Target Size (Minimum) — Level AA

Requirement: The size of the target for pointer inputs is at least 24 by 24 CSS pixels, with specific exceptions.

What This Means: Interactive elements (buttons, links, form controls) must be at least 24×24 pixels to accommodate users with motor impairments who may have difficulty targeting small elements.

Exceptions:

• Spacing: Targets smaller than 24×24 are acceptable if the spacing around them ensures no overlap with other targets within 24px
• Equivalent: Another control achieving the same function meets the size requirement
• Inline: Target is within a sentence or text block (links in paragraphs)
• User agent control: Size is determined by the browser, not the author
• Essential: Particular presentation is essential (like a map pin)

Common Violations:

• Small icon buttons (especially social media icons)
• Tiny close buttons on modals
• Compact navigation with small tap targets
• Dense data tables with interactive elements

Implementation:

/* Ensure minimum target size */
button,
a,
input[type="checkbox"],
input[type="radio"] {
  min-width: 24px;
  min-height: 24px;
}

/* For icon buttons, ensure clickable area is sufficient */
.icon-button {
  padding: 8px; /* Adds to total clickable area */
}

3.2.6 Consistent Help — Level A

Requirement: If a web page contains help mechanisms (contact information, human contact, self-help options, automated contact), they occur in the same relative order on each page within a set of web pages.

What This Means: Help features should appear in consistent locations across your site. If your contact link is in the footer on one page, it should be in the footer on all pages.

Help Mechanisms Include:

• Contact phone numbers
• Contact email addresses
• Contact forms
• Live chat
• FAQ links
• Help documentation links

Implementation:

• Establish standard locations for help features
• Use consistent ordering (e.g., FAQ, then Chat, then Contact)
• Maintain consistency across all pages in the site
• Document help placement in design systems

3.3.7 Redundant Entry — Level A

Requirement: Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated, or available for the user to select.

What This Means: If users enter information once in a process (like their name on step 1 of checkout), they shouldn't have to re-enter it later in the same process (on step 3). Either auto-fill it or let them select from previously entered values.

Exceptions:

• Re-entering for security (password confirmation)
• Previously entered information is no longer valid
• Essential to the purpose (like a memory test)

Common Violations:

• Multi-step forms requiring repeated address entry
• Checkout asking for billing address after shipping address was entered
• Account creation flows asking for email multiple times
• Registration forms not preserving data when returning after errors

Implementation:

• Auto-populate fields from earlier steps
• Provide "same as billing" checkboxes for addresses
• Remember entered data throughout multi-step processes
• Preserve form data when users navigate back

3.3.8 Accessible Authentication (Minimum) — Level AA

Requirement: A cognitive function test is not required for any step in an authentication process unless that step provides at least one of: an alternative method, a mechanism to assist the user, or object recognition/personal content.

What This Means: Authentication cannot require users to remember or transcribe information (passwords, codes) without providing assistance mechanisms.

Cognitive Function Tests Include:

• Remembering usernames and passwords
• Transcribing characters or codes
• Solving puzzles (some CAPTCHAs)
• Performing calculations

Acceptable Alternatives:

• Password managers (copy/paste support)
• Email/SMS authentication links
• Biometric authentication
• OAuth/social login
• Security questions with personal content (what's your pet's name)
• Object recognition (click all images containing cats)

Implementation:

• Support password managers (don't block paste in password fields)
• Offer magic link authentication
• Provide OAuth options (Sign in with Google/Apple)
• If using CAPTCHA, offer accessible alternatives

Code Example:

<!-- Bad: Blocking paste prevents password managers -->
<input type="password" onpaste="return false;">

<!-- Good: Allow paste for password manager support -->
<input type="password" autocomplete="current-password">

3.3.9 Accessible Authentication (Enhanced) — Level AAA

Requirement: A cognitive function test is not required for any step in an authentication process unless that step provides at least one of: an alternative method or a mechanism to assist the user.

Difference from 3.3.8: The enhanced version removes the exceptions for object recognition and personal content. Authentication must not require any cognitive function test without providing a complete alternative or assistance mechanism.

What Was Removed: 4.1.1 Parsing

Previous Requirement (WCAG 2.0/2.1): In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique.

Why It Was Removed:

• Modern browsers handle markup errors gracefully
• The HTML5 specification defines how browsers should parse malformed markup
• Assistive technologies have evolved to work with browser-parsed DOM rather than raw markup
• Most issues this criterion addressed are now caught by 4.1.2 (Name, Role, Value) or don't affect accessibility

Practical Impact: Organizations can remove 4.1.1 from compliance checklists. However, valid markup remains a development best practice and can prevent other accessibility issues.

Migration Guide: 2.1 to 2.2

Assessment Steps

1. Audit Current Compliance: If you're currently WCAG 2.1 compliant, assess your site against the new 2.2 criteria specifically.

2. Prioritize New Requirements: Focus first on Level A and AA criteria that apply to most content:

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

3. Technical Inventory: Identify where these criteria apply on your site:

• Fixed-position elements (Focus Not Obscured)
• Drag-and-drop interfaces (Dragging Movements)
• Small interactive elements (Target Size)
• Help features (Consistent Help)
• Multi-step forms (Redundant Entry)
• Login/authentication (Accessible Authentication)

Common Remediation Tasks

Focus Not Obscured:

• Add scroll-padding to account for sticky headers
• Reposition persistent UI elements away from likely focus areas
• Test keyboard navigation with all overlays visible

Dragging Movements:

• Add button alternatives to sliders
• Implement keyboard controls for sortable interfaces
• Provide click-based alternatives for drag-and-drop

Target Size:

• Audit interactive element sizes
• Increase padding on small buttons and links
• Ensure touch targets meet 24×24 minimum

Consistent Help:

• Document help feature locations
• Standardize placement across all pages
• Update design system with help placement guidelines

Redundant Entry:

• Implement form data persistence across steps
• Add "same as" options for repeated fields
• Preserve data on validation errors

Accessible Authentication:

• Enable paste in password fields
• Add OAuth/magic link options
• Provide accessible CAPTCHA alternatives

Q&A: WCAG 2.2 Transition

Q: Do I need to update my accessibility statement from WCAG 2.1 to 2.2?

A: If you're claiming conformance to a specific WCAG version, update your statement when you achieve 2.2 compliance. You can also state "targeting WCAG 2.2" while working toward full conformance. Until you've addressed the new criteria, claiming 2.1 conformance remains accurate.

Q: Are the new criteria retroactive—do I need to fix existing content?

A: WCAG criteria apply to all web content. Existing content should be updated to meet new criteria, prioritized by user impact and business criticality. New content and updates should meet WCAG 2.2 from implementation.

Q: How do courts view WCAG 2.2 vs 2.1 in litigation?

A: Courts generally reference WCAG as the technical standard without specifying versions. Organizations meeting WCAG 2.1 AA have strong legal positions; meeting 2.2 is even stronger. The DOJ's 2024 guidance references WCAG 2.1, though courts may begin referencing 2.2 as it becomes established.

Q: Should I skip WCAG 2.1 and go directly to 2.2?

A: Yes. WCAG 2.2 is backward-compatible—meeting 2.2 means you meet 2.1 and 2.0 as well. There's no reason to target an older version.

Implementation Priority Matrix

For organizations updating from WCAG 2.1 to 2.2:

| Criterion                       | Level | Implementation Effort | User Impact | Priority |
|---------------------------------|-------|-----------------------|-------------|----------|
| 3.3.8 Accessible Authentication | AA    | Medium                | High        | Critical |
| 2.5.8 Target Size               | AA    | Low-Medium            | High        | Critical |
| 2.4.11 Focus Not Obscured       | AA    | Low                   | Medium      | High     |
| 3.3.7 Redundant Entry           | A     | Medium                | Medium      | High     |
| 3.2.6 Consistent Help           | A     | Low                   | Medium      | High     |
| 2.5.7 Dragging Movements        | AA    | Medium                | Medium      | Medium   |

Level AAA criteria (2.4.12, 2.4.13, 3.3.9) are recommended but not required for standard conformance.

Tools for WCAG 2.2 Testing

Testing tools are updating to cover WCAG 2.2 criteria. When evaluating tools, verify they test for:

• All new 2.2 success criteria
• Updated rules removing 4.1.1 false positives
• Target size calculation
• Focus visibility assessment

Automated tools can check many 2.2 criteria (target size, consistent help location), though some require manual verification (authentication accessibility, redundant entry evaluation).

Next Steps

WCAG 2.2 represents the current accessibility standard. Organizations should:

1. Update target version from WCAG 2.1 to WCAG 2.2 in accessibility policies
2. Assess current state against new criteria
3. Remediate gaps prioritized by level and user impact
4. Update testing to include 2.2 criteria
5. Monitor continuously for new issues and regressions

Schedule a TestParty demo and get a 14-day compliance implementation plan.

Related Resources

• What is WCAG 2.2: Complete Guide
• Keyboard Navigation Tutorial
• Form Accessibility Checklist
• Color Contrast Requirements