WCAG 2.1 vs 2.2: What Changed and Why It Matters for Your Compliance

In October 2023, the Web Content Accessibility Guidelines (WCAG) 2.2 became an official W3C recommendation. For the first time in 5 years, the accessibility standards have been updated with new requirements.

If you've built your website to WCAG 2.1 standards, you have established a good accessibility foundation. However, WCAG 2.2 adds new requirements that organizations should consider addressing to maintain current accessibility best practices.

This guide breaks down what changed, what matters, and what you need to consider for your accessibility strategy.

Brief History: Why WCAG Keeps Evolving

Web accessibility standards evolve as technology changes and our understanding of disability improves.

• WCAG 1.0 (1999): First official guidelines. Very desktop-focused. Outdated now.
• WCAG 2.0 (2008): Major rewrite. Technology-neutral principles. Still used widely.
• WCAG 2.1 (2018): Added mobile accessibility, low-vision design, cognitive considerations. This is what most companies target today.
• WCAG 2.2 (2023): NEW. Focuses on target sizing, persistent user controls, and improved cognitive accessibility. This is emerging as a new standard.

Legal reality: The ADA doesn't specify which WCAG version organizations must follow. However, accessibility professionals and legal observers often reference WCAG 2.1 Level AA as a reasonable standard. As WCAG 2.2 becomes more established, it may increasingly be recognized as current best practice.

The question isn't "must we adopt WCAG 2.2?" It's "when should we start planning for it?"

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

WCAG 2.2 adds 9 new success criteria (accessibility requirements). Here are the ones that will likely impact your website:

1. Target Size (Level AAA) - 2.5.8

• What it means: Clickable targets (buttons, links, form fields) must be at least 24×24 CSS pixels, with exceptions for inline links and targets next to other targets.
• Why it matters: Affects users with motor disabilities, tremors, or anyone on a mobile device. This is the most impactful new requirement.
• Your action: Audit your buttons and links. Many sites use 18-20px targets. You'll need to expand them to 24px or document exemptions.
• Implementation difficulty: Medium. May require redesign of compact layouts.

2. Dragging (Level AAA) - 2.5.7

• What it means: If your site uses drag-and-drop interactions (reordering lists, moving files), provide keyboard-accessible alternatives.
• Why it matters: Keyboard users and switch control users can't use drag-and-drop alone.
• Your action: If you have drag-and-drop, add buttons or keyboard shortcuts (e.g., "Move Up," "Move Down").
• Implementation difficulty: Low to Medium. Most modern frameworks support this.

3. Consistent Help (Level A) - 3.2.6

• What it means: Navigation, search, and other persistent UI controls (that appear on multiple pages) must appear in the same relative order each time.
• Why it matters: Users with cognitive disabilities rely on consistency. Randomized layouts are confusing.
• Your action: Make sure your navigation, search box, and other repeated elements are in the same place on every page. No randomization.
• Implementation difficulty: Very Low. Most sites already do this.

4. Focus Not Obscured (Level AA) - 2.4.11

• What it means: When keyboard users tab through your site, focus indicators must be visible (not hidden or covered by other elements).
• Why it matters: Keyboard users rely on seeing where they are on the page.
• Your action: Check that your focus indicators aren't hidden behind sticky headers or other elements. Don't use `outline: none` without providing an alternative visual indicator.
• Implementation difficulty: Very Low. Usually CSS only.

5. Focus Appearance (Level AAA) - 2.4.13

• What it means: Focus indicators must meet specific design criteria: 2px minimum thickness, sufficient contrast, etc.
• Why it matters: This is a more rigorous version of visible focus indicators. The focus indicator itself must be well-designed.
• Your action: Review your focus indicators. If they're thin, low-contrast lines, upgrade them to at least 2px thick with high contrast.
• Implementation difficulty: Very Low to Low. CSS refinement.

6. Accessible Authentication (Level AA) - 3.3.8

• What it means: Authentication mechanisms should not rely solely on cognitive function tests. Provide alternatives to CAPTCHAs or memory-based authentication.
• Why it matters: Users with cognitive disabilities may struggle with traditional CAPTCHAs.
• Your action: If you use CAPTCHAs, provide alternatives like email verification or authentication apps.
• Implementation difficulty: Medium. Depends on current authentication approach.

Other New Criteria (Lower Impact):

• Redundant Entry (Level A) - 3.3.7: If users enter information previously provided, don't make them re-enter it.
• Accessible Authentication (Minimum) (Level A) - 3.3.8: Basic authentication accessibility requirements.
• Accessible Authentication (Enhanced) (Level AAA) - 3.3.9: Enhanced authentication accessibility requirements.

Impact by Site Type: What This Means for You

E-Commerce Sites

• Most affected by: Target size (24×24 buttons), persistent checkout flow
• Action required: Audit checkout buttons, review cart controls, ensure consistent checkout flow
• Estimated effort: 20-40 hours

SaaS / Admin Dashboards

• Most affected by: Drag-and-drop alternatives, target size for data table controls, focus appearance
• Action required: Add keyboard alternatives to drag-and-drop, audit button/icon sizes, verify focus indicators
• Estimated effort: 40-80 hours

Content / Blog Sites

• Most affected by: Persistent navigation order, focus appearance
• Action required: Ensure navigation is consistent across pages, audit focus indicators
• Estimated effort: 5-15 hours

Government / Healthcare Sites

• Most affected by: ALL of the above. Government and healthcare sites often have higher accessibility expectations.
• Action required: Complete WCAG 2.2 Level AA audit and remediation
• Estimated effort: 100-200+ hours depending on site size

When Should You Consider WCAG 2.2?

There's no immediate federal mandate requiring WCAG 2.2. However, momentum is building toward recognizing it as current best practice.

What's already happened:

• Accessibility professionals increasingly reference WCAG 2.2 as the current standard
• Some accessibility audits and lawsuits have begun citing WCAG 2.2 criteria
• Several states are reviewing their accessibility standards
• Federal contractors and healthcare organizations are evaluating adoption timelines

Realistic timeline considerations:

• 2025-2026: WCAG 2.2 Level AA may increasingly be recognized as current best practice
• 2026-2027: WCAG 2.2 Level AA may become commonly referenced in accessibility discussions
• 2027-2028: Federal standards updates may formalize WCAG 2.2 references

Strategic approach:

• If your site is not yet compliant: Consider targeting WCAG 2.2 Level AA
• If your site is WCAG 2.1 compliant: Plan a WCAG 2.2 evaluation over the next 2 years
• If you're starting a new site: Consider building for WCAG 2.2 from day one

Is WCAG 2.1 Still Valid?

You might wonder: "We're WCAG 2.1 compliant. Is that still acceptable?"

Yes, for now.

WCAG 2.1 is still a valid, respected standard. Compliance with WCAG 2.1 Level AA represents a solid accessibility foundation. Most accessible websites currently target WCAG 2.1.

However: As WCAG 2.2 becomes more established, accessibility professionals and organizations may increasingly reference it as current best practice.

Strategic approach:

• If your site is not yet compliant: Consider targeting WCAG 2.2 Level AA instead of 2.1
• If your site is WCAG 2.1 compliant: Plan a WCAG 2.2 evaluation over the next 2 years
• If you're starting a new site: Consider building for WCAG 2.2 from day one

Quick Reference: Major Changes for Your Team

• Target sizes matter more: 24×24 CSS pixels minimum (enhanced from previous recommendations)
• Focus indicators must be visible: No hiding or low-contrast outlines
• Drag-and-drop needs keyboard alternatives: Must support keyboard input
• Consistent navigation: UI controls must appear in the same order on all pages
• Authentication accessibility: Provide alternatives to cognitive tests like CAPTCHAs

Your WCAG 2.2 Evaluation Plan

Month 1: Assessment

• Run a WCAG 2.2 accessibility audit
• Document specific gaps and remediation effort
• Identify high-priority issues (target size, focus visibility, drag-and-drop)

Months 2-3: Planning

• Create a remediation roadmap
• Estimate effort and budget
• Decide: New build with WCAG 2.2 vs. retrofitting existing site

Months 4-5: Development

• Address high-priority issues (target size, focus appearance)
• Add keyboard alternatives for complex interactions
• Test thoroughly with assistive technology

Month 6: Verification

• Get an independent WCAG 2.2 audit to verify compliance
• Document compliance efforts
• Update your accessibility statement

Resources

• WCAG 2.2 Quick Reference
• Understanding WCAG 2.2
• WCAG 2.2 Techniques
• WebAIM (accessibility learning resource)
• The A11y Project