WCAG 2.2 New Success Criteria Explained: What Changed and How to Fix Your Website

Web accessibility lawsuits surpassed 4,600 federal filings in 2023, and courts are increasingly referencing WCAG 2.2 as the compliance benchmark. If your site was built to an older standard—or no standard at all—you're exposed. The good news is that the WCAG 2.2 new success criteria are specific, testable, and fixable. This post breaks down exactly what changed, why it matters legally, and how to implement the fixes yourself.

What Changed in WCAG 2.2

WCAG 2.2 became an official W3C recommendation in October 2023. It builds on 2.1 by adding nine new success criteria and removing one (4.1.1 Parsing, which became obsolete as browsers matured). The additions focus heavily on keyboard navigation, authentication, and focus visibility—three areas where modern web apps consistently fail users with disabilities.

Understanding the WCAG 2.2 new success criteria isn't optional anymore. The DOJ's final rule under Title II of the ADA (published April 2024) explicitly cites WCAG 2.2 as the technical standard for state and local government websites, and private-sector enforcement is following the same benchmark.

The 9 New Success Criteria, Prioritized by Risk

High Priority: Fix These First

2.4.11 Focus Not Obscured (Minimum) – Level AA
When a user tabs to an element, that element cannot be completely hidden behind sticky headers, cookie banners, or chat widgets. Partial visibility is acceptable at this level.

The fix:

/* Add scroll-margin-top to account for sticky headers */
:focus {
  scroll-margin-top: 80px; /* match your header height */
}

2.4.12 Focus Not Obscured (Enhanced) – Level AAA
Same concept, stricter: the focused component must be fully visible. Most businesses only need to meet Level AA, but this is worth noting if you serve enterprise clients with strict requirements.

2.5.7 Dragging Movements – Level AA
Any functionality that uses drag-and-drop must have a single-pointer alternative. Think sliders, sortable lists, and map controls. Users with motor disabilities can't reliably execute precise drag gestures.

The fix: Add up/down arrow buttons alongside every draggable interface element. If you're using a component library, check whether it exposes keyboard controls natively.

<!-- Sortable list with keyboard alternative -->
<li>
  Item Name
  <button aria-label="Move item up">↑</button>
  <button aria-label="Move item down">↓</button>
</li>

2.5.8 Target Size (Minimum) – Level AA
Interactive targets must be at least 24×24 CSS pixels, or have sufficient spacing around them so the total activation area meets that threshold. This hits small icon buttons, close icons, and inline links hard.

The fix:

/* Use padding to expand the clickable area without affecting layout */
button.icon-btn {
  min-width: 24px;
  min-height: 24px;
  padding: 8px;
}

Check your mobile nav, form close buttons, and cookie consent dialogs first—these are the most frequent offenders.

Authentication Criteria: High Legal Risk

3.2.6 Consistent Help – Level A
If your site has a help mechanism (phone number, chat, FAQ link), it must appear in the same relative location across pages. This one is deceptively simple but commonly violated by sites where the footer layout changes between templates.

3.3.7 Redundant Entry – Level A
Users should not have to re-enter information they've already provided in the same session. Multi-step checkout forms that ask for the same shipping address twice fail this criterion.

The fix: Use session storage or form state management to pre-populate fields the user has already completed.

// Pre-populate billing address if same as shipping
const shippingData = sessionStorage.getItem('shippingAddress');
if (shippingData) {
  const parsed = JSON.parse(shippingData);
  document.getElementById('billing-street').value = parsed.street;
}

3.3.8 Accessible Authentication (Minimum) – Level AA
This is one of the most impactful WCAG 2.2 new success criteria. Cognitive function tests—like "type the characters you see in this image" CAPTCHAs—cannot be the only way to authenticate. Users with dyslexia, memory impairments, or cognitive disabilities are blocked by these.

The fix: Replace image-based CAPTCHAs with:
- hCaptcha or reCAPTCHA v3 (invisible, behavior-based)
- Email magic links
- Passkeys/WebAuthn

If you must use a CAPTCHA, provide an audio alternative and an option to use a password manager (don't block paste functionality).

3.3.9 Accessible Authentication (Enhanced) – Level AAA
Removes even the audio CAPTCHA option. Again, AAA is aspirational for most SMBs, but if you're rebuilding your auth flow anyway, build to this standard.

New Criterion: 2.4.13 Focus Appearance – Level AA

Focused elements must meet specific visual contrast requirements: the focus indicator must have a minimum area of the perimeter of the unfocused component, and the color change must have at least a 3:1 contrast ratio.

Browser defaults often fail this. Custom designs almost always do.

The fix:

/* High-visibility focus indicator */
:focus-visible {
  outline: 3px solid #0057b7;
  outline-offset: 2px;
  border-radius: 2px;
}

/* Remove default only after setting custom */
:focus:not(:focus-visible) {
  outline: none;
}

Never set outline: none without providing a styled replacement.

The One Criterion That Was Removed

4.1.1 Parsing is gone in WCAG 2.2. This previously required valid HTML to avoid parser errors that could confuse assistive technologies. Modern browsers handle malformed HTML gracefully, making this criterion effectively redundant. If you have old audit reports flagging 4.1.1 issues, you can deprioritize those—focus your effort on the new criteria above.

How to Audit for WCAG 2.2 New Success Criteria

Automated tools catch roughly 30–40% of accessibility issues. For the WCAG 2.2 new success criteria specifically, manual testing is essential because criteria like Focus Not Obscured and Target Size require visual inspection and keyboard navigation testing.

Quick manual checklist:
1. Tab through every page—does the focused element stay visible above sticky elements?
2. Try completing your checkout or signup flow using only a keyboard
3. Measure your smallest buttons with browser dev tools
4. Test your login page with a password manager (Bitwarden, 1Password)—does it allow autofill?
5. Check that help links appear in the same location on every page

Automated scanners can flag target size violations, missing focus styles, and authentication patterns that suggest CAPTCHA usage—giving you a starting list before manual review.

The Legal Reality for SMBs

Serial litigants and law firms specifically target sites that haven't updated to current standards. The average ADA demand letter settlement is $25,000–$75,000 before legal fees. Remediation, by comparison, is a fraction of that cost. Courts don't distinguish between intentional non-compliance and simple neglect—both result in liability.

The WCAG 2.2 new success criteria aren't a moving target you need a consultant to decode. They're concrete, testable, and documented. The fixes above cover the highest-risk items in under a day of focused development work.

Ready to find out exactly where your site stands? Scan your site for free at wcagrepair.com and get a remediation guide with exact code fixes for $8.99. You'll know within minutes which of the WCAG 2.2 criteria you're failing and have a prioritized list of fixes to hand off to your developer—or implement yourself.