What Is the Difference Between WCAG 2.2 and WCAG 2.1?

The Web Content Accessibility Guidelines version 2.2, published by the W3C in October 2023, represents the most significant update to accessibility standards since WCAG 2.1's release in 2018. WCAG 2.2 vs 2.1 differences include 9 new success criteria focused on cognitive accessibility and mobile usability, while removing 1 outdated criterion. With over 96% of homepages failing WCAG requirements according to WebAIM's 2024 accessibility analysis, understanding these changes is essential for achieving compliance.

Key Takeaways

This comparison covers every difference between WCAG 2.2 and 2.1 with practical migration guidance.

• WCAG 2.2 adds 9 new success criteria: 3 at Level A, 5 at Level AA, and 1 at Level AAA
• WCAG 2.2 removes 1 criterion (4.1.1 Parsing) because modern browsers handle parsing errors gracefully
• Total criteria count changed from 78 in WCAG 2.1 to 87 in WCAG 2.2
• New criteria primarily address cognitive disabilities, mobile users, and keyboard navigation
• WCAG 2.2 is backward compatible—sites conforming to 2.2 also conform to 2.1 and 2.0

Overview of Changes

WCAG 2.2 maintains the same foundational structure as its predecessors—four POUR principles (Perceivable, Operable, Understandable, Robust) with 13 guidelines. The changes focus on specific success criteria additions and one removal.

Summary Table

+--------------------+---------------+------------------+-------------+
|       Aspect       |    WCAG 2.1   |     WCAG 2.2     |    Change   |
+--------------------+---------------+------------------+-------------+
|   Total Criteria   |       78      |        87        |    +9 net   |
+--------------------+---------------+------------------+-------------+
|      Level A       |       30      |        32        |      +2     |
+--------------------+---------------+------------------+-------------+
|      Level AA      |       20      |        24        |      +4     |
+--------------------+---------------+------------------+-------------+
|     Level AAA      |       28      |        31        |      +3     |
+--------------------+---------------+------------------+-------------+
|    Release Date    |   June 2018   |   October 2023   |   5 years   |
+--------------------+---------------+------------------+-------------+

Why Update Now?

WCAG 2.2 addresses gaps identified through years of real-world implementation:

1. Cognitive accessibility: Users with cognitive disabilities were underserved by previous versions
2. Mobile and touch: Touch-based interactions needed clearer requirements
3. Authentication barriers: Login processes created unnecessary obstacles
4. Focus visibility: Existing focus requirements were too vague to enforce

New Criteria in WCAG 2.2

Nine new success criteria were added, each addressing specific accessibility barriers identified since WCAG 2.1.

Level A Additions (3 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.

Why it matters: Sticky headers, cookie banners, and chat widgets often cover the currently focused element, making keyboard navigation impossible.

Implementation: ```css / Ensure focused elements scroll above sticky elements / :focus { scroll-margin-top: 100px; / Height of sticky header / }

/ Or manage z-index to ensure focus is visible / .sticky-header { z-index: 100; }

*:focus { position: relative; z-index: 101; } ```

3.2.6 Consistent Help

Requirement: If a web page contains help mechanisms (contact information, chat, FAQ links), they appear in the same relative order across pages.

Why it matters: Users with cognitive disabilities rely on consistent patterns. Moving help mechanisms between pages creates confusion and increases cognitive load.

Implementation:

• Place help links in consistent header/footer locations
• Use consistent labeling ("Help," "Contact Us," "Support")
• Maintain the same order when multiple help options exist

3.3.7 Redundant Entry

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

Why it matters: Re-entering information is frustrating for everyone and creates significant barriers for users with memory difficulties, motor disabilities, or those using assistive technologies.

Implementation: ```html <!-- Use autocomplete for common fields --> <input type="text" name="shipping-street" autocomplete="shipping street-address">

<!-- Pre-fill from previous steps --> <input type="text" name="billing-street" value="123 Main St" aria-label="Billing street address (same as shipping)">

<!-- Provide copy/same-as options --> <label> <input type="checkbox" id="same-as-shipping"> Billing address same as shipping </label> ```

Level AA Additions (5 Criteria)

2.4.12 Focus Not Obscured (Enhanced)

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

Note: This is the enhanced version of 2.4.11. At Level AA, partial obscuring is now also prohibited.

Implementation:

• Audit all sticky/fixed positioned elements
• Implement scroll-margin-top on focusable elements
• Use focus management to scroll focused elements into full view

2.4.13 Focus Appearance

Requirement: Focus indicators must meet specific size and contrast requirements (at least 2 CSS pixels thick and 3:1 contrast ratio).

Why it matters: WCAG 2.4.7 Focus Visible only required focus to be "visible" without defining what that meant. This criterion provides testable requirements.

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

2.5.7 Dragging Movements

Requirement: Functionality that uses dragging can be operated with a single pointer without dragging.

Why it matters: Users with motor disabilities, those using mouth sticks or head pointers, and mobile users with limited dexterity cannot perform drag operations.

Implementation: ```html <!-- Sortable list with both drag and button alternatives --> <li draggable="true" id="item-1"> Item 1 <button aria-label="Move Item 1 up">Up</button> <button aria-label="Move Item 1 down">Down</button> </li> ```

2.5.8 Target Size (Minimum)

Requirement: Touch/click targets must be at least 24x24 CSS pixels, with specific exceptions.

Why it matters: Small targets are difficult for users with motor impairments, older adults, and mobile users. WCAG 2.1's 2.5.5 Target Size was Level AAA (44x44px); this brings a smaller but still useful requirement to Level AA.

Implementation: ```css button, a, input[type="checkbox"], input[type="radio"] { min-width: 24px; min-height: 24px; }

/ For inline links, ensure adequate spacing / a { padding: 4px 0; margin: 4px 0; } ```

Exceptions:

• Inline text links (within sentences)
• Size determined by user agent (native controls)
• Essential sizing (legally required appearance)
• Equivalent alternative exists

3.3.8 Accessible Authentication (Minimum)

Requirement: Cognitive function tests (remembering passwords, solving puzzles, transcribing text) are not required for authentication unless an alternative is provided.

Why it matters: Traditional authentication creates barriers for users with cognitive disabilities, memory impairments, and learning disabilities.

Compliant alternatives:

• Password managers (autocomplete supported)
• Email/SMS authentication codes (copy-paste enabled)
• Biometric authentication
• Physical security keys
• OAuth/third-party authentication

Implementation: ```html <!-- Allow password manager autofill --> <input type="password" autocomplete="current-password" name="password">

<!-- Allow pasting in verification fields --> <input type="text" inputmode="numeric" autocomplete="one-time-code" aria-label="6-digit verification code"> ```

Level AAA Addition (1 Criterion)

3.3.9 Accessible Authentication (Enhanced)

Requirement: No cognitive function test for any step of authentication, with no exceptions for object recognition or personal content.

Why it matters: Even "easy" tests like identifying objects in images or recognizing personal photos create barriers for some users.

Note: This extends 3.3.8 by removing the object recognition exception. Most organizations won't target this Level AAA criterion, but it guides best practices.

Removed Criterion: 4.1.1 Parsing

WCAG 2.2 removes Success Criterion 4.1.1 Parsing, which previously required HTML to be well-formed with complete start/end tags, proper nesting, and no duplicate attributes.

Why It Was Removed

The W3C determined that 4.1.1 is obsolete because:

1. Modern browsers are forgiving: All major browsers handle parsing errors gracefully
2. Assistive technologies adapted: Screen readers and other AT work with browser DOMs, not raw HTML
3. Original intent is met: The goal—ensuring AT can access content—is now achieved by browser standards
4. Reduces false positives: Automated tools flagged many parsing "errors" that caused no actual accessibility barriers

What This Means

• No action required: You don't need to do anything about this removal
• Valid HTML still matters: While not a WCAG requirement, valid HTML remains a best practice
• Automation impact: If your automated testing flagged parsing errors, these are no longer WCAG failures
• Backward compatibility maintained: Removing 4.1.1 doesn't break 2.0/2.1 conformance

Migration Guide: WCAG 2.1 to 2.2

Follow this systematic approach to update from WCAG 2.1 to 2.2 compliance.

Phase 1: Assessment (2-4 Weeks)

Step 1: Audit new criteria

Evaluate your current implementation against each new criterion:

+-------------------------------------+--------------+-----------------------------------+
|              Criterion              |   Priority   |           Common Issues           |
+-------------------------------------+--------------+-----------------------------------+
|      2.4.11 Focus Not Obscured      |     High     |   Sticky headers covering focus   |
+-------------------------------------+--------------+-----------------------------------+
|       2.4.13 Focus Appearance       |     High     |   Thin/low-contrast focus rings   |
+-------------------------------------+--------------+-----------------------------------+
|       2.5.7 Dragging Movements      |    Medium    |        Drag-only interfaces       |
+-------------------------------------+--------------+-----------------------------------+
|          2.5.8 Target Size          |    Medium    |        Small buttons/links        |
+-------------------------------------+--------------+-----------------------------------+
|        3.2.6 Consistent Help        |     Low      |    Inconsistent help placement    |
+-------------------------------------+--------------+-----------------------------------+
|        3.3.7 Redundant Entry        |    Medium    |          Multi-step forms         |
+-------------------------------------+--------------+-----------------------------------+
|   3.3.8 Accessible Authentication   |     High     |        CAPTCHA, no autofill       |
+-------------------------------------+--------------+-----------------------------------+

Step 2: Prioritize by impact and legal risk

Level AA criteria (2.4.11, 2.4.12, 2.4.13, 2.5.7, 2.5.8, 3.3.8) typically have legal implications. Prioritize these for immediate remediation.

Step 3: Document current state

Create a baseline audit documenting:

• Which new criteria you already meet
• Which require development work
• Estimated effort for each

Phase 2: Implementation (4-12 Weeks)

Focus Indicators (2.4.11, 2.4.12, 2.4.13)

1. Create design system focus tokens
2. Implement custom focus-visible styles globally
3. Add scroll-margin-top to account for sticky elements
4. Test all interactive elements with keyboard navigation

/* Global focus system */
:root {
  --focus-color: #005fcc;
  --focus-width: 3px;
  --focus-offset: 2px;
}

*:focus-visible {
  outline: var(--focus-width) solid var(--focus-color);
  outline-offset: var(--focus-offset);
  scroll-margin-top: 100px;
}

Dragging Alternatives (2.5.7)

1. Inventory all drag functionality
2. Design single-pointer alternatives (buttons, dropdowns)
3. Implement alternatives alongside drag
4. Ensure alternatives are discoverable

Target Size (2.5.8)

1. Audit all interactive elements
2. Identify elements under 24x24px
3. Increase padding/size or add spacing
4. Document any elements using exceptions

Authentication (3.3.8)

1. Ensure password fields support autocomplete
2. Remove paste-blocking from verification inputs
3. Evaluate CAPTCHA alternatives (hCaptcha accessibility mode, WebAuthn)
4. Consider passwordless authentication options

Consistent Help (3.2.6)

1. Audit help mechanism placement across pages
2. Standardize positions in templates
3. Document pattern for development teams

Redundant Entry (3.3.7)

1. Map all multi-step forms and processes
2. Identify information requested multiple times
3. Implement autocomplete attributes
4. Add "same as" options where appropriate

Phase 3: Testing and Validation (2-4 Weeks)

Manual testing checklist:

• [ ] Tab through all pages, verify focus visibility
• [ ] Check no focus is obscured by sticky elements
• [ ] Verify all drag functions have alternatives
• [ ] Measure target sizes (DevTools)
• [ ] Test authentication with password manager
• [ ] Verify help consistency across pages
• [ ] Complete multi-step forms, check for redundant entry

Automated testing:

• Run axe, WAVE, or Lighthouse
• Note: Automated tools may not fully cover new 2.2 criteria yet
• Verify tool versions support WCAG 2.2

User testing:

• Include keyboard-only users
• Include users with cognitive disabilities
• Test authentication flows with password managers

Phase 4: Documentation and Maintenance

Update accessibility statement:

• Change conformance claim to WCAG 2.2
• Document any exceptions with rationale
• Provide contact for accessibility issues

Train development team:

• Document new requirements in design system
• Add to code review checklists
• Update component library

Ongoing monitoring:

• Add 2.2 criteria to regression testing
• Monitor for sticky element issues in new features
• Review authentication changes for compliance

Backward Compatibility

WCAG versions maintain strict backward compatibility:

• Sites conforming to WCAG 2.2 automatically conform to 2.1 and 2.0
• WCAG 2.2 builds upon (doesn't replace) previous criteria
• You cannot "skip" 2.1 and only implement 2.2 additions
• All 78 criteria from 2.1 remain (minus 4.1.1)

This means your WCAG 2.1 work remains valid—2.2 is additive.

Legal and Regulatory Context

Most accessibility regulations reference WCAG 2.1 Level AA, but updates are expected:

+----------------------+-----------------------+---------------------------+
|      Regulation      |   Current Reference   |      Expected Update      |
+----------------------+-----------------------+---------------------------+
|       ADA (US)       |      WCAG 2.1 AA      |     DOJ monitoring 2.2    |
+----------------------+-----------------------+---------------------------+
|   Section 508 (US)   |      WCAG 2.0 AA      |     Revision underway     |
+----------------------+-----------------------+---------------------------+
|   EN 301 549 (EU)    |      WCAG 2.1 AA      |   2.2 adoption expected   |
+----------------------+-----------------------+---------------------------+
|    AODA (Canada)     |      WCAG 2.0 AA      |        Under review       |
+----------------------+-----------------------+---------------------------+

Recommendation: Implement WCAG 2.2 proactively rather than waiting for regulatory mandates.

Frequently Asked Questions

Is WCAG 2.2 legally required now?

WCAG 2.2 is not yet mandated by most regulations, which still reference WCAG 2.0 or 2.1. However, regulations are expected to update, and implementing 2.2 now positions organizations ahead of requirements. WCAG 2.2 also reflects current best practices for accessibility.

Do I need to redo my WCAG 2.1 audit for 2.2?

You don't need to re-audit existing 2.1 compliance. WCAG 2.2 is additive—if you conform to 2.1, you only need to assess the 9 new criteria (6 at Level AA for most organizations). Your previous audit work remains valid.

What happened to WCAG 2.2 criterion 4.1.1 Parsing?

WCAG 2.2 removes 4.1.1 Parsing because modern browsers handle HTML parsing errors gracefully. Assistive technologies work with the browser's corrected DOM rather than raw HTML. This doesn't mean valid HTML is unimportant—it's still best practice—but parsing errors are no longer WCAG failures.

How is WCAG 2.2 different from WCAG 3.0?

WCAG 2.2 is an incremental update maintaining the same structure as 2.0 and 2.1. WCAG 3.0 (W3C Accessibility Guidelines, still in development) will be a major restructuring with new testing methodology, scoring systems, and scope expansion. WCAG 3.0 is years from completion; organizations should implement 2.2 now.

Which new WCAG 2.2 criteria should I prioritize?

For most organizations targeting Level AA, prioritize: 2.4.11/2.4.12 Focus Not Obscured (common failures), 2.4.13 Focus Appearance (addresses widespread issues), 2.5.8 Target Size (mobile impact), and 3.3.8 Accessible Authentication (affects all users). These have the highest user impact and legal relevance.

Do overlays and widgets help with WCAG 2.2 compliance?

Accessibility overlays cannot address most WCAG 2.2 requirements. New criteria like Focus Not Obscured, Dragging Movements, and Accessible Authentication require source code changes—not surface-level modifications. The W3C, accessibility experts, and disability advocates consistently recommend against overlay-based approaches.

Related Resources

• WCAG 2.2 Success Criteria List: Complete 87 Criteria Guide
• WCAG Level AA Checklist for 2026
• WCAG 2.4.11 Focus Appearance Minimum: CSS Guide
• WCAG 2.3.3 Animation from Interactions Guide
• Automated vs Manual Accessibility Testing

This article was crafted using a cyborg approach—human expertise enhanced by AI to provide accurate, comprehensive accessibility guidance based on the official W3C WCAG 2.2 specification at https://www.w3.org/TR/WCAG22/ and the What's New in WCAG 2.2 documentation at https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/.