WCAG 2.2 became a W3C Recommendation in October 2023. By early 2024, it was the technical standard cited in the DOJ's ADA Title II final rule. If you're still testing against WCAG 2.1, you're behind — but the gap isn't as large as some of the coverage makes it sound.

Here's what actually changed, what it means in practice, and which of the new criteria I see violated most often in audits.

The One Removal: 4.1.1 Parsing

WCAG 2.2 removed Success Criterion 4.1.1 (Parsing), which required valid, well-formed HTML. The W3C removed it because modern browsers and assistive technologies handle malformed HTML well enough that the criterion no longer meaningfully predicts user impact. This isn't a reason to write sloppy HTML — it just means it's no longer a WCAG conformance issue.

The 9 New Success Criteria

2.4.11 Focus Appearance (Minimum) — Level AA

This is the one I see violated most often on audits. The criterion requires that keyboard focus indicators meet a minimum size and contrast ratio. Specifically: the focus indicator must have a perimeter of at least the perimeter of the unfocused component, and the contrast ratio between focused and unfocused states must be at least 3:1.

/* Before — common violation: outline removed entirely */
:focus { outline: none; }

/* After — minimum compliant focus style */
:focus-visible {
  outline: 3px solid #66FCF1;
  outline-offset: 2px;
  border-radius: 3px;
}

/* For dark backgrounds specifically */
@media (prefers-color-scheme: dark) {
  :focus-visible {
    outline-color: #66FCF1; /* high contrast on dark */
  }
}

The single most common WCAG failure I find in any audit is outline: none on focus. This criterion finally puts a hard requirement on the minimum size of the indicator.

2.4.12 Focus Appearance (Enhanced) — Level AAA

The Level AAA version requires a focus indicator that encloses the entire component, with at least 2px thickness and a 3:1 contrast ratio. If you're targeting AAA conformance, this is the bar. For most projects targeting AA, 2.4.11 is the requirement to meet.

2.4.13 Focus Appearance — Level AAA

Note: the numbering in the final WCAG 2.2 spec consolidated these. The key point is that 2.4.11 is your AA requirement. Build solid focus styles and you've covered it.

2.5.7 Dragging Movements — Level AA

Any functionality that uses a dragging movement must also be operable with a single pointer — a click, tap, or similar. If you have a drag-to-reorder list, a drag-to-resize panel, or any other drag interaction, there must be an alternative.

<!-- Drag-to-reorder list: needs alternative controls -->
<li draggable="true">
  Item
  <!-- Add accessible move buttons -->
  <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 so that a 24px circle centered on the target doesn't intersect another target or its spacing boundary. This is a minimum — WCAG 2.1 had an AAA criterion requiring 44×44px, which was rarely met. The new AA standard is more realistic.

In practice: small icon buttons, inline text links in dense lists, and close buttons in notification banners are the most common violations I find.

/* Minimum compliant touch target */
.btn-icon {
  min-width: 24px;
  min-height: 24px;
  /* Better: use padding to expand the clickable area */
  padding: 8px;
}

/* The 44x44 AAA target is still best practice for touch */
.btn-touch {
  min-width: 44px;
  min-height: 44px;
}

3.2.6 Consistent Help — Level A

If a help mechanism (contact number, chat link, self-help page) appears on multiple pages, it must appear in the same relative order each time. This is a fairly easy criterion to meet if your navigation and footer are templated consistently — which they should be anyway.

3.3.7 Redundant Entry — Level A

Information previously entered in a multi-step process must be auto-populated or available for the user to select, unless re-entry is essential or the information needs to change. The classic case: a shipping address that was entered on step 1 shouldn't require manual re-entry on step 3 for billing.

This is a UX issue that disproportionately affects users with cognitive disabilities, motor impairments, and screen reader users navigating long forms.

3.3.8 Accessible Authentication (Minimum) — Level AA

Authentication processes that rely on a cognitive function test (CAPTCHA, solving a puzzle, remembering a complex password) must have an alternative — unless the cognitive test is to recognize an object the user has provided, or a personal content test. Practically: if you use CAPTCHA, you need an accessible alternative. Audio CAPTCHAs are not sufficient — they're notoriously difficult to parse with screen readers in a noisy environment.

3.3.9 Accessible Authentication (Enhanced) — Level AAA

The AAA version removes the exceptions. No cognitive function tests of any kind in authentication flows. If you're building for maximum accessibility, this is the target.

What This Means for Your Audit Checklist

If you were already testing thoroughly against WCAG 2.1 AA, the new Level AA additions that require the most attention are:

3.2.6 and 3.3.7 are likely already met if your site is well-templated and your multi-step forms save state. Verify them, but they rarely turn up as new failures in audits I run on sites that were already WCAG 2.1 AA compliant.

The Bottom Line

WCAG 2.2 is an incremental update, not a revolution. The most important thing it did was make focus appearance a Level AA requirement — something that was technically required under 2.1 but under-enforced because the language was vague. Now it's specific. Now there's a measurable bar.

If your site passes WCAG 2.1 AA and you have solid focus styles, you're close. Do a focused pass on the nine new criteria and you'll get there.

Need a real accessibility audit?

Not a Lighthouse score — a thorough WCAG 2.2 AA audit with manual JAWS testing and code-level remediation guidance your developers can actually use.

Schedule a Free Consultation