WCAG 2.2: a working developer's guide to all 9 new criteria.

WCAG 2.2 is the current published version of the Web Content Accessibility Guidelines. It became a W3C Recommendation on 5 October 2023, and at the time of writing it has been the live spec for over two and a half years. The European Accessibility Act began enforcement on 28 June 2025, ADA lawsuits in the United States keep climbing, and most procurement RFPs now reference 2.2 explicitly.

So the question isn’t whether to move off 2.1 anymore. It’s how much of 2.2 your product still hasn’t shipped, and how much risk that gap is buying you.

This guide walks the nine criteria 2.2 added on top of 2.1 (and the one it removed) the way a frontend developer needs to read them: what the rule is, why it was added, what fails, what passes, what to fix first. The per-criterion pages on this site go further on testing and edge cases. Use this one to get oriented and prioritise the work.

The 9 new criteria at a glance

Six of the nine sit at A or AA. Six is what you actually have to ship if you target the typical AA bar. The three AAA rules are useful direction even if you don’t conform to them yet.

The one removal: 4.1.1 Parsing

WCAG 2.2 retires 4.1.1 Parsing. The rule asked that markup be valid: tags closed, IDs unique, no duplicate attributes. Modern browsers handle malformed HTML so reliably that the rule had no measurable accessibility effect, and the W3C decided it was costing audit time without buying users anything.

If you had remediation tickets pinned to “4.1.1 Parsing”, close them. Keep validating your HTML for everyone’s sanity. It just stops being a WCAG conformance issue.

2.4.11 Focus Not Obscured (Minimum) — AA

When a component has keyboard focus, the focus indicator must not be entirely hidden by author-created content. A sticky header that covers a focused link on Tab fails this. So does a cookie banner that sits permanently above the focused control.

This was added because sticky headers and persistent banners genuinely strand keyboard users. You Tab forward, the page scrolls, and the focused element ends up under a 64-pixel sticky bar. You can’t see where you are. The fix is small and the failure is everywhere.

A failing pattern:

header.site-header {
  position: sticky;
  top: 0;
  height: 64px;
  z-index: 50;
}
/* No scroll-padding-top. Focused links land under the header. */

A passing pattern:

:root {
  --sticky-header-h: 64px;
}
 
html {
  /* When focus or anchor scrolls into view, leave room for the header. */
  scroll-padding-top: var(--sticky-header-h);
}
 
header.site-header {
  position: sticky;
  top: 0;
  height: var(--sticky-header-h);
}

scroll-padding-top ships everywhere now and solves most cases in one line. For modal-style stickies (cookie banners, chat widgets), give the user a way to dismiss them so the focused control becomes visible after dismissal.

To test, set keyboard focus to elements near the top of the viewport while scrolled. If the focus indicator disappears under sticky chrome, you fail.

Deeper on 2.4.11 →

2.4.12 Focus Not Obscured (Enhanced) — AAA

Same intent as 2.4.11, stricter bar: no part of the focus indicator may be obscured. The Minimum rule lets you partially cover it. The Enhanced rule does not.

In practice, if you fix 2.4.11 with scroll-padding-top, you usually pass 2.4.12 as a side effect. The difference matters most when you have animated overlays, drag handles, or floating toasts that brush against focused controls.

Deeper on 2.4.12 →

2.4.13 Focus Appearance — AAA

The focus indicator itself has minimum dimensions. The focused state must:

1. Have an indicator at least 2 CSS pixels thick around the perimeter of the component.
2. Have a 3:1 contrast ratio between focused and unfocused states.

This is stricter than 2.4.7 Focus Visible (AA), which only requires that an indicator exists, not that it be a particular size or contrast.

A failing pattern:

/* 1px is half the required thickness. */
button:focus-visible { outline: 1px solid #444; }
 
/* Colour change only, no perimeter, no contrast against unfocused. */
button:focus-visible { background: rgba(0, 0, 0, 0.05); }

A passing pattern:

:focus-visible {
  outline: 3px solid #ffd700;
  outline-offset: 2px;
}

A 3-pixel ring on a yellow that contrasts strongly against most surfaces. Pair with a thin dark inset (box-shadow: 0 0 0 5px #1e293b) if your design uses both light and dark backgrounds, since yellow alone fails on white.

Deeper on 2.4.13 →

2.5.7 Dragging Movements — AA

Any function that uses dragging must also work with a single-pointer non-dragging action. A draggable list item must have an alternative (up and down buttons, keyboard arrows, a move-to menu). A draggable map must have pan controls. A draggable file uploader must accept clicks too.

Dragging requires fine motor control. Tremor, RSI, voice control, head-pointer use, and switch users all struggle with sustained drag. The criterion does not ban drag. It requires an equivalent.

A failing pattern is a Kanban board where cards only move by drag.

A passing pattern is the same Kanban with a move menu on every card:

<KanbanCard>
  <DragHandle />
  <button onClick={() => moveCard(id, "up")} aria-label="Move up">
    &uarr;
  </button>
  <button onClick={() => moveCard(id, "down")} aria-label="Move down">
    &darr;
  </button>
  <Menu label="Move to column">
    {columns.map((col) => (
      <MenuItem key={col.id} onSelect={() => moveCard(id, col.id)}>
        {col.name}
      </MenuItem>
    ))}
  </Menu>
</KanbanCard>

React DnD’s default examples do not pass. You add this layer yourself. The same applies to most JavaScript drag libraries. Drag is the affordance, not the only path.

The exception: if dragging is essential to the task (drawing, annotating with a stylus, signing a signature), you don’t need an alternative. The bar for “essential” is high. Reordering items is not essential. Drawing a signature is.

Deeper on 2.5.7 →

2.5.8 Target Size (Minimum) — AA

Pointer targets must be at least 24×24 CSS pixels. Smaller targets pass only if:

• An equivalent control of sufficient size exists elsewhere on the page, or
• The target is inline in a sentence (a link inside a paragraph), or
• The user agent itself controls the target’s size, or
• The target’s size is essential to the function (a digital signature canvas, a colour picker swatch, etc.)

Note: this is the AA rule. The AAA rule (2.5.5 Target Size Enhanced) sits at 44×44 and dates back to WCAG 2.1.

A failing pattern is the 16×16 close button on a card or the 14×14 pagination arrow.

A passing pattern pads the hit area without changing the visible glyph:

button.icon {
  /* Visible glyph is 16x16, hit area is 24x24. */
  width: 24px;
  height: 24px;
  padding: 4px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  background: transparent;
}

Watch for inline links: a link in flowing text gets the inline exception, but a link styled as a tag chip is no longer inline and must hit 24×24. The exception is about the visual context, not the markup.

Deeper on 2.5.8 →

3.2.6 Consistent Help — A

If your site offers help mechanisms (contact info, chat, FAQ link, self-help portal), they must appear in the same relative order on every page that has them. The rule does not say every page must have help, only that when present, the location is consistent.

People with cognitive variation, people new to a product, and people in stress (think a checkout error) lose orientation quickly. A help link that moves between pages forces a re-orientation each time.

Failing: footer “Contact” on the homepage, header “Chat with us” on product pages, no obvious help on the checkout page.

Passing: pick one location (the footer is fine) and keep it. If you add a chat widget, keep its position consistent across pages.

This is one of the cheapest 2.2 fixes. Audit the help layout once, write it down, hold the line in design reviews. It is also the only new criterion at A level, which means it’s required even for the lowest WCAG bar.

Deeper on 3.2.6 →

3.3.7 Redundant Entry — A

Information the user has already entered in the same process must not be required again, unless re-entry is essential. Either auto-fill it or let the user select it from a previous step.

Long forms (insurance, government, healthcare, multi-step checkouts) routinely ask the same thing twice. People with memory variation, low-vision users, and anyone using a screen reader pay the cognitive tax twice each time.

Failing: a checkout that asks for the billing address on step 2 and the shipping address on step 3, with no “same as billing” option.

Passing:

<label>
  <input
    type="checkbox"
    checked={shippingSameAsBilling}
    onChange={(e) => setShippingSameAsBilling(e.target.checked)}
  />
  Shipping address same as billing
</label>
{!shippingSameAsBilling && <ShippingForm initial={billing} />}

Auto-fill is the strongest answer. If you cannot auto-fill (privacy, security), give a one-click way to copy the previous value. Re-entry is allowed when it is essential: confirming a password, re-typing a security-critical value, or when the original input has expired.

Deeper on 3.3.7 →

3.3.8 Accessible Authentication (Minimum) — AA

Authentication must not require a cognitive function test (memory, transcription, calculation, puzzle solving) unless an alternative or a mechanism is offered.

Cognitive function tests it bans by default:

• Memorising and typing a password (memory)
• Transcribing a code from one device to another (transcription)
• Solving a CAPTCHA puzzle that requires reading distorted text or recognising abstract patterns (cognition)

Acceptable mechanisms include:

• Allowing password manager autofill, which means not blocking paste in password fields
• Email or SMS magic links
• Passkeys / WebAuthn
• Object recognition CAPTCHAs (“find the bus”), which the spec exempts because pattern recognition is not a memory test
• A non-cognitive alternative path

Failing: a login form that disables paste on the password field, plus a CAPTCHA that asks the user to type a distorted word.

Passing: accept paste, support passkeys or magic links, and use object-recognition CAPTCHAs only when CAPTCHA is necessary at all.

<!-- Failing: blocks password manager paste -->
<input type="password" onpaste="return false" />
 
<!-- Passing: vanilla paste support -->
<input type="password" autocomplete="current-password" />

The single biggest gain is removing paste blocks on password and OTP fields. It costs nothing and helps everyone, not just users with disabilities.

Deeper on 3.3.8 →

3.3.9 Accessible Authentication (Enhanced) — AAA

Same intent, stricter: even object recognition and personal-content recognition tests are out. Effectively, the AAA bar is “passkeys, magic links, or biometrics”.

Most consumer apps will not chase AAA here. Enterprise products targeting government users or accessibility-first procurement (EAA, US Section 508) increasingly will. If you’re shipping authentication into either, design for AAA from the start. Retrofits are expensive.

Deeper on 3.3.9 →

What to fix first

If your product targets WCAG 2.2 AA (the typical bar), prioritise in this order:

1. 3.2.6 Consistent Help. Cheapest fix at A level. Audit help layout, hold the line in reviews.
2. 2.4.11 Focus Not Obscured (Minimum). One CSS line solves most cases: scroll-padding-top on the html element.
3. 3.3.7 Redundant Entry. Review long forms for repeated fields. Add “same as” toggles.
4. 2.5.8 Target Size (Minimum). Audit icon-only buttons. Bump anything under 24×24 with padding.
5. 3.3.8 Accessible Authentication (Minimum). Stop blocking paste, add a passkey or magic-link path.
6. 2.5.7 Dragging Movements. Only matters if you have draggable UI. Add equivalent buttons.

Three of those are pure CSS fixes. Two are form refactors. One is auth pattern work. Most teams clear the list in a sprint or two. The AAA rules (2.4.12, 2.4.13, 3.3.9) are worth doing once you have the rest. They tighten the same intent.

What did not change

The version number went up but most of WCAG 2.2 is identical to 2.1. The principles, the levels, the testing methodology, the success criteria for inherited rules: all unchanged. If your site passed 2.1 cleanly, the gap to 2.2 is the nine criteria above, minus 4.1.1 Parsing.

This is by design. WCAG versions are backwards-compatible. WCAG 3.0 will break that compatibility, but it is years away from final Recommendation status, and current drafts are still very much in flux.

Conformance and the law

The European Accessibility Act has been enforceable since 28 June 2025. Its harmonised standard EN 301 549 still cites WCAG 2.1 AA at the floor, with the EN 301 549 update for 2.2 alignment progressing. In practice, EU national enforcement bodies are accepting 2.2 AA as satisfying the directive on the “at least 2.1 AA” reading, and large EU procurement RFPs increasingly ask for 2.2 directly.

In the United States, ADA Title III case law and DOJ consent decrees keep citing WCAG 2.0 / 2.1 AA. ADA-related digital lawsuits crossed 8,000 federal filings in 2024 and continued climbing through 2025. US Section 508 procurement is on a 2.2 update path, with agencies already specifying 2.2 in newer contracts.

Practical takeaway: 2.2 AA is now the realistic target everywhere, not the optimistic one. The regulatory floor is moving toward 2.2, the procurement floor is already there in most enterprise deals, and the litigation floor doesn’t care which version of WCAG your team committed to internally. The cost of shipping 2.2 is small. The cost of not shipping it is no longer hypothetical.

Closing

WCAG 2.2 isn’t an accessibility revolution. It’s a careful tightening of the screws on focus, target size, dragging, and authentication. None of the new rules are surprising. All of them codify problems that real users hit every day. Two and a half years after publication, none of the patterns are exotic and none of the fixes are expensive.

If your team is still on a 2.1 AA bar, the gap is the nine criteria above (minus 4.1.1 Parsing). Audit it once, work the prioritised list, and you’re current. If you’re building new and targeting 2.2 AA from day one, the patterns above are the table stakes.

For deeper companion reading on each rule, the per-criterion pages on this site go further on testing and edge cases. For a single book, Inclusive Components by Heydon Pickering is the closest thing to a canonical implementation reference, and most of the patterns here trace back to it.