DEV Community

Matthew Dillon
Matthew Dillon

Posted on • Originally published at cleara11y.net on

WCAG 2.1 vs 2.2: What Changed and What You Need to Know

What is WCAG?

The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility. Published by the W3C, they define how to make web content accessible to people with disabilities.

WCAG 2.2 was officially published in October 2023, adding 9 new success criteria to the existing WCAG 2.1 guidelines.

Quick Comparison

Aspect WCAG 2.1 WCAG 2.2
Published June 2018 October 2023
Success Criteria 78 86 (+9, -1)
Focus Areas Mobile, low vision, cognitive Authentication, navigation, input
Legal Standard Still widely referenced Increasingly adopted

What's New in WCAG 2.2

WCAG 2.2 adds 9 new success criteria. Here's what you need to know about each:

2.4.11 Focus Not Obscured (Minimum) - Level AA

The Problem : When you tab to an element, other content (like sticky headers or chat widgets) sometimes covers it.

The Requirement : The focused element must not be entirely hidden by other content.

How to Fix :

/* Ensure sticky headers don't cover focused elements */
:target {
  scroll-margin-top: 80px; /* Height of your sticky header */
}

/* Or use scroll-padding on the container */
html {
  scroll-padding-top: 80px;
}

Enter fullscreen mode Exit fullscreen mode

2.4.12 Focus Not Obscured (Enhanced) - Level AAA

Same as above, but stricter: no part of the focused element can be hidden (versus "not entirely hidden" at AA).

2.4.13 Focus Appearance - Level AAA

The Requirement : Focus indicators must:

  • Have a minimum area (at least as large as a 2px thick perimeter)
  • Have at least 3:1 contrast between focused and unfocused states
/* Good focus indicator */
:focus {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

Enter fullscreen mode Exit fullscreen mode

2.5.7 Dragging Movements - Level AA

The Problem : Drag-and-drop interfaces are impossible for users who can't perform dragging motions.

The Requirement : Any action that requires dragging must have a single-pointer alternative (like clicking buttons).

How to Fix :

<!-- Sortable list with drag AND button alternatives -->
<li draggable="true">
  Item 1
  <button aria-label="Move Item 1 up">↑</button>
  <button aria-label="Move Item 1 down">↓</button>
</li>

Enter fullscreen mode Exit fullscreen mode

2.5.8 Target Size (Minimum) - Level AA

The Requirement : Interactive targets must be at least 24x24 CSS pixels, OR have sufficient spacing from other targets.

Why It Matters : Small tap targets cause errors for users with motor impairments, tremors, or on touch screens.

/* Ensure minimum target size */
button, a, input {
  min-width: 24px;
  min-height: 24px;
}

/* Or ensure spacing between small targets */
.small-button {
  margin: 12px; /* Creates 24px gap between adjacent targets */
}

Enter fullscreen mode Exit fullscreen mode

Exceptions : Inline links in text, where size is determined by the text.

3.2.6 Consistent Help - Level A

The Requirement : If you provide help mechanisms (contact info, chat, FAQ), they must appear in the same relative location on each page.

How to Fix : Put your help link, chat widget, or contact info in a consistent spot - typically the header or footer.

3.3.7 Redundant Entry - Level A

The Problem : Asking users to re-enter the same information multiple times in a process.

The Requirement : Don't ask for the same info twice, OR auto-populate it, OR let users select from previously entered data.

How to Fix :

<!-- Bad: Asking for shipping address then billing address separately -->

<!-- Good: Provide a checkbox -->
<label>
  <input type="checkbox" id="same-address">
  Billing address same as shipping
</label>

Enter fullscreen mode Exit fullscreen mode

3.3.8 Accessible Authentication (Minimum) - Level AA

The Problem : CAPTCHAs and cognitive tests block users with cognitive disabilities.

The Requirement : Authentication can't require:

  • Cognitive function tests (puzzles, memory tests)
  • Transcribing characters
  • Recognizing objects

Allowed :

  • Password managers (don't block paste!)
  • WebAuthn / passkeys
  • Email or SMS codes
  • OAuth ("Sign in with Google")
<!-- Don't block password paste -->
<input type="password" id="password">

<!-- Never do this -->
<input type="password" onpaste="return false">

Enter fullscreen mode Exit fullscreen mode

3.3.9 Accessible Authentication (Enhanced) - Level AAA

Same as above, but also prohibits object recognition CAPTCHAs ("click all the traffic lights").

What Was Removed?

4.1.1 Parsing was removed from WCAG 2.2. Modern browsers and assistive technologies handle parsing errors gracefully now. You still want valid HTML, but it's no longer a WCAG requirement.

Which Version Should You Target?

For legal compliance : Check your jurisdiction. Many laws still reference WCAG 2.1 AA. However, courts increasingly expect current standards.

Our recommendation : Target WCAG 2.2 Level AA. The new criteria address real usability issues, and you'll be ahead of legal requirements when they update.

WCAG 2.2 Compliance Checklist

Level A (Must Have)

  • 3.2.6: Help mechanisms appear in consistent locations
  • 3.3.7: Don't ask for the same information twice

Level AA (Should Have)

  • 2.4.11: Focused elements aren't completely hidden
  • 2.5.7: Drag actions have click alternatives
  • 2.5.8: Touch targets are at least 24x24px (or spaced apart)
  • 3.3.8: Authentication doesn't require cognitive tests

Level AAA (Nice to Have)

  • 2.4.12: Focused elements aren't partially hidden
  • 2.4.13: Focus indicators meet size and contrast requirements
  • 3.3.9: No object recognition in authentication

How ClearA11y Helps

ClearA11y tests against WCAG 2.1 and 2.2 criteria, including:

  • Focus indicator visibility
  • Target size requirements
  • Form input issues
  • Color contrast

Scan your website now to see which WCAG criteria you're passing and failing, with AI-powered code suggestions to fix each issue.

Stay Current

Accessibility standards evolve. WCAG 3.0 is in development (though years away from being finalized). The best approach is to:

  1. Build accessibility into your development process
  2. Test regularly with tools like ClearA11y
  3. Include users with disabilities in your testing
  4. Stay informed about standards updates

Your users - and your legal team - will thank you.

Top comments (0)