WCAG 2.2 — What Changed

The previous lesson put accessibility on concrete footing — contrast numbers, focus outlines, labels, landmarks, "no ARIA is better than bad ARIA." Everything there was WCAG 2.1 AA, the standard that's been the practical bar for a decade.

WCAG 2.2 is the small, important update. It doesn't replace 2.1 — the 2.1 criteria are all still in 2.2, unchanged. It adds nine new success criteria, most of them at Level AA, that catch failure modes the earlier version didn't name. This lesson covers the six that matter most for day-to-day front-end work.

Focus Not Obscured (Minimum) — Level AA

The scenario: a user is tabbing through a page with a sticky header, focus moves to a field that scrolls into view behind the sticky header, and the keyboard user can no longer see which control they're on. The sighted mouse user never noticed; the keyboard user is lost.

The requirement: when a component receives focus, no part of it is entirely hidden by author-created content. A sticky header can partially cover the focused element if a meaningful piece is still visible; it can't swallow it completely.

The common fixes:

• Use scroll-padding-top on the scrolling container so programmatic scroll leaves room for the sticky header.

  html {
    scroll-padding-top: 4rem; /* same height as the sticky header */
  }

• For large cookie/consent banners and floating toolbars that can overlap focus anywhere on the page, give users a way to dismiss or collapse them, and account for their size in scroll-padding.

The stricter version — Focus Not Obscured (Enhanced) at Level AAA — requires no part of the focused element to be obscured, not just not entirely. Worth aiming for; not required to pass AA.

Target Size (Minimum) — Level AA

The requirement: interactive targets have at least a 24×24 CSS pixel hit area.

This is deliberately a floor, not best practice. Apple's human interface guidelines and Material Design both recommend 44×44 or 48×48; those remain good targets. 24×24 is the number below which WCAG considers the target objectively hard to hit for users with motor impairments, large fingers, a shaky touch surface, or a tremor.

The hit area isn't the element's visual size — it's the clickable area, which includes padding:

/* A small icon button, legal under WCAG 2.2 AA */
.icon-button {
  padding: 0.5rem;   /* 8px on each side → 16px icon + 16px padding = 32px hit area */
  background: none;
  border: none;
}

The exceptions are honest ones: inline links inside a sentence of prose, native unstyled controls, targets whose size is essential (small zoom controls on a map), and cases where an equivalent larger control exists on the same page.

The most frequent failure: a row of close-packed icon buttons in a toolbar, each 18px, with no padding. Give each one enough padding to reach 24px effective, or respace the row.

Dragging Movements — Level AA

The requirement: anything you can do by dragging — reorder a list, resize a panel, pan a map, drop a file — must have a non-dragging alternative that produces the same outcome.

This is not "remove drag-and-drop." It's "make sure drag isn't the only way." A sortable list needs up/down buttons or keyboard reorder; a resizable panel needs number inputs or snap handles; a drag-and-drop file uploader needs an actual file-picker button alongside the drop zone (which most libraries get right by default).

The usability payoff is bigger than the compliance payoff: drag works poorly on every input method except a pointing device, which means your keyboard users, screen reader users, and anyone on a spotty touchscreen all benefit from the alternative.

Consistent Help — Level A

The requirement: if your site provides help mechanisms (contact information, a "Help" link, a chat widget, a feedback form), they appear in the same relative order on every page that offers them.

Users form a mental map of where help lives. Shuffling it between pages — chat bottom-right on one page, top of a sidebar on another, inside a footer accordion on a third — costs cognitive effort every time they look for it. Pick a position and keep it.

The fix is almost always one of design review, not CSS. Audit the site's help affordances and lock down where they sit.

Redundant Entry — Level A

The requirement: within the same session's process (checkout, a multi-step form, a signup flow), information the user already entered must either be auto-populated or available to select — not re-entered from scratch.

The textbook offender: a checkout where the shipping address form and the billing address form are identical fields, with no "same as shipping" checkbox. The user types their address twice; the second time they make a typo and don't notice. The fix is the checkbox — or the autofill — and it's a usability win, not just a compliance one.

Exceptions: fields where re-entry is essential for security (confirming a password, re-typing a PIN), or where the previously- entered value is no longer valid.

Accessible Authentication (Minimum) — Level AA

The requirement: the sign-in flow cannot force the user to solve a cognitive function test — remember a password, transcribe a code from one device to another, solve a puzzle, recognise distorted text — unless an alternative path exists.

"Alternative path" is the load-bearing word. Passkeys and WebAuthn satisfy this cleanly; so does "sign in with magic email link"; so does OAuth-with-Google. But even a classic password form passes if the user can paste from a password manager — which means do not set autocomplete="off" on password fields, do not block paste on input events, and do not fragment the password across multiple inputs (the "verification code" four-digit boxes are a classic failure).

The practical fix for an existing password form:

<!-- Fails: blocks the manager alternative. -->
<input type="password" autocomplete="off" onpaste="return false">
 
<!-- Passes: the user can paste from a password manager. -->
<input type="password" autocomplete="current-password">

CAPTCHA that requires solving a puzzle is a cognitive function test; "click here to prove you're not a robot" (checkbox CAPTCHA) and invisible CAPTCHA are not. If you can't get away from image CAPTCHA entirely, offer an audio alternative so the test isn't the only path through.

What else is in WCAG 2.2 but less common to encounter

Three more criteria rounded out WCAG 2.2:

• Focus Not Obscured (Enhanced) — Level AAA, no part of focus obscured.
• Focus Appearance — a thickness/contrast specification for the focus indicator, Level AAA, useful as design guidance even without aiming for AAA conformance.
• Accessible Authentication (Enhanced) — Level AAA, bans the cognitive test entirely even if an alternative exists.

Worth knowing they exist; not required to pass AA.

Also worth noting: WCAG 2.2 removed one 2.1 criterion — "Parsing" (4.1.1) — because modern parsing is a browser concern that no author can meaningfully fail. One fewer thing to audit.

What to remember

• WCAG 2.2 is additive: everything in WCAG 2.1 AA still applies; 2.2 adds nine new criteria. The six most common for front-end work are Focus Not Obscured, Target Size, Dragging Movements, Consistent Help, Redundant Entry, and Accessible Authentication.
• Focus Not Obscured (Minimum, AA): a sticky header or floating toolbar can't entirely hide a focused control. Fix with scroll-padding-top and account for banners.
• Target Size (Minimum, AA): 24×24 CSS pixel hit area. Padding counts. Larger (44–48) remains best practice.
• Dragging Movements (AA): every drag has a non-drag alternative. Not "remove drag" — add the other path.
• Consistent Help (A): help mechanisms appear in the same relative order across pages that have them.
• Redundant Entry (A): don't make users re-type information they already entered in the same session; offer autofill or a "same as" checkbox.
• Accessible Authentication (AA): no cognitive function test as the only path. Allowing the password manager (don't autocomplete="off", don't block paste) usually passes a classic password form.
• WCAG 2.2 also removed "Parsing" (4.1.1) — one fewer thing to audit.