WCAG 2.2 Explained: A Technical Engineering Guide

Overview of WCAG 2.2 Changes

The World Wide Web Consortium officially released the WCAG 2.2 Recommendation to address critical gaps in mobile device usability, low-vision keyboard interaction, and cognitive accessibility. Crucially, WCAG 2.2 also removed SC 4.1.1 (Parsing) because modern web browsers and assistive technologies now handle HTML error correction uniformly according to the HTML Living Standard.

• 9 new success criteria introduced (6 at Level A/AA, 3 at Level AAA).
• 1 obsolete criterion deprecated (SC 4.1.1 Parsing).
• Increased focus on pointer interactions, cognitive load, and visual indicator visibility.

Focus Appearance & Focus Not Obscured

Under SC 2.4.11 (Focus Not Obscured - Minimum, Level AA), author-created sticky headers, floating action buttons, cookie consent bars, or bottom navigation bars must not completely conceal an element when it receives keyboard focus. Under SC 2.4.13 (Focus Appearance, Level AAA), the focus indicator must achieve a 3:1 contrast ratio against the unfocused state and surrounding background with a minimum surface area of a 2px outline.

/* Recommended CSS for WCAG 2.2 compliant focus styling */
:focus-visible {
  outline: 3px solid #0284C7;
  outline-offset: 2px;
  scroll-margin-top: 5rem; /* Prevents sticky headers from obscuring focus */
  scroll-margin-bottom: 5rem;
}

Target Size (Minimum) Engineering

Success Criterion 2.5.8 (Target Size - Minimum, Level AA) mandates that interactive pointer targets must have an area of at least 24 by 24 CSS pixels, unless an offset spacing is provided such that a 24px diameter circle centered on the target does not intersect another target or another target's circle.

• Inline link targets within text sentences are exempt.
• Essential targets (such as pins on a tight interactive map) have specific exemptions.
• Best practice for mobile touch targets remains 44x44 CSS px (Apple) or 48x48 CSS px (Android/Material).

Dragging Movements & Single Pointer Fallbacks

Under SC 2.5.7 (Dragging Movements, Level AA), any function requiring a dragging path (such as kanban board task cards, range sliders, or sortable lists) must provide a simple click or tap alternative, such as up/down reorder buttons or a numeric input field.

// Example: Pairing drag-and-drop with accessible button controls
<div role="listitem">
  <span>Task Name</span>
  <div className="flex gap-2">
    <button aria-label="Move task up" onClick={moveUp}>↑</button>
    <button aria-label="Move task down" onClick={moveDown}>↓</button>
  </div>
</div>

Redundant Entry & Accessible Authentication

SC 3.3.7 (Redundant Entry, Level A) prevents requiring users to re-enter information previously provided in the same session (such as billing address matching shipping address). SC 3.3.8 (Accessible Authentication, Level AA) mandates that authentication cannot rely solely on cognitive function tests, such as memorizing passwords or solving visual CAPTCHAs, without alternatives like password manager autofill, paste support, or WebAuthn passkeys.

Quick Implementation Checklist

Review this technical checklist during code reviews to ensure new features comply with WCAG 2.2 before shipping:

• Confirm sticky banners or headers do not obscure focused elements (use scroll-padding/scroll-margin).
• Ensure buttons and icon toggles have at least 24x24px bounding boxes.
• Provide up/down or keyboard alternatives for any drag-to-sort widgets.
• Allow paste on all password and MFA verification fields.
• Auto-populate repeated address or personal information in multi-step forms.