WCAG 2.2 - What Changed and What It Means for Your UI

WCAG 2.2 is the Web Content Accessibility Guidelines version 2.2, published as a W3C Recommendation in October 2023. It adds nine new success criteria and removes two from WCAG 2.1. The new criteria target areas that most production codebases handle poorly: focus appearance, target sizes, and dragging interactions. These are not edge cases - they are everyday UI patterns.

The most important thing to know: if your design system owns the focus ring, touch target sizes, and interaction patterns at the token and component layer, WCAG 2.2 compliance becomes structural. One update propagates everywhere. If you are patching per-component after an audit, you will be patching again next year.

What Are the New WCAG 2.2 Success Criteria at Level AA?

WCAG 2.2 adds nine new success criteria and removes two (4.1.1 Parsing and 1.4.10 Reflow, which was moved). Here is the full set:

Criterion	Name	Level	What it requires
2.4.11	Focus Appearance	AA	Minimum focus indicator area and contrast ratio
2.4.12	Focus Appearance (Enhanced)	AAA	Stronger focus indicator requirements
2.4.13	Focus Appearance (Enhanced)	AAA	Stronger version of 2.4.11
2.5.7	Dragging Movements	AA	Dragging functionality must have a single-pointer alternative
2.5.8	Target Size (Minimum)	AA	Interactive targets at least 24x24 CSS pixels
3.2.6	Consistent Help	A	Help mechanisms appear in consistent locations
3.3.7	Redundant Entry	A	Information already provided does not need to be re-entered
3.3.8	Accessible Authentication (Minimum)	AA	Cognitive function tests not required for authentication
3.3.9	Accessible Authentication (Enhanced)	AAA	Stricter version of 3.3.8

The three AA criteria most likely to fail in existing production UIs are SC 2.4.11, SC 2.5.8, and SC 2.5.7 - in that order. The other AA criteria (consistent help, redundant entry, accessible authentication) are important but less likely to require significant refactoring in a well-built application.

What Are the New WCAG 2.2 Success Criteria for Focus Appearance?

SC 2.4.11 (Focus Appearance, AA) requires that keyboard focus indicators meet two requirements: minimum area and minimum contrast ratio. Specifically, the focus indicator must have an area at least as large as a 2 CSS pixel perimeter around the focused component, and that indicator must have a contrast ratio of at least 3:1 against the unfocused state and 3:1 against adjacent colors.

The default browser focus ring passes in some browsers and fails in others - Chrome’s default blue ring generally meets the contrast requirement on white backgrounds; Safari’s ring on older OS versions does not. Firefox’s default ring is a dashed blue outline that often fails contrast requirements against colored backgrounds. The only reliable approach is an explicit custom focus indicator applied with focus-visible.

In practice at the design system layer, implementing SC 2.4.11 compliance means defining a focus ring token that specifies color, width, and offset, then applying it consistently through a utility class or CSS custom property. In my design systems work implementing WCAG 2.2 compliance, I define three focus ring tokens: --focus-ring-color (typically the brand primary at sufficient contrast), --focus-ring-width (minimum 2px, usually 3px for visibility), and --focus-ring-offset (1px to 2px to separate the ring from the element background).

The focus-visible pseudo-class (now at Baseline 2024 - supported in all major browsers) is the right selector. It applies focus styles only when focus is indicated by keyboard navigation, not on mouse click - addressing the UX complaint that visible focus rings interfere with pointer-based interactions. Using :focus alone applies the ring on every interaction; using :focus-visible applies it only where the user needs it.

The W3C criterion page for SC 2.4.11 is at w3.org/WAI/WCAG22/Understanding/focus-appearance.

What Is the Minimum Target Size Under WCAG 2.2?

SC 2.5.8 (Target Size Minimum, AA) requires interactive targets to be at least 24x24 CSS pixels, with exceptions for inline text links and when a minimum spacing between targets is maintained. This is more permissive than the AAA version from WCAG 2.1 (SC 2.5.5, which requires 44x44 CSS pixels), but many icon buttons in existing production UIs still fail the 24x24 threshold.

The common failure case: an icon button with a 16x16 or 20x20 icon and no padding. The icon is the entire clickable area. At 20x20 CSS pixels, it fails SC 2.5.8. The fix is straightforward - add padding to expand the clickable area to at least 24x24 without changing the visual icon size. For a 16x16 icon, 4px padding on all sides produces a 24x24 clickable area. For production reliability, 44x44 is worth targeting - it meets the AAA criterion and aligns with iOS and Android human interface guidelines for minimum touch targets.

The spacing exception in SC 2.5.8 allows targets smaller than 24x24 if the target plus its offset area (the space between it and adjacent targets) totals 24x24. This exception covers tightly-spaced icon toolbars where meeting the 24x24 requirement for each icon independently would require visual redesign. The offset area is not clickable - it is just spacing that counts toward the minimum. This exception is worth understanding but not worth designing for; the safer path is to ensure the target itself meets the minimum.

From experience auditing enterprise UI libraries: icon buttons in data table action columns are the highest-frequency failure point. A table with five actions per row, using 16x16 icons with 4px padding, produces 24x24 targets that technically meet the minimum but are frustrating in practice on touch devices. Increasing those to 32x32 (8px padding around a 16x16 icon) is a one-line token change that dramatically improves the touch experience.

The W3C criterion page for SC 2.5.8 is at w3.org/WAI/WCAG22/Understanding/target-size-minimum.

What Does WCAG 2.2 Require for Dragging Movements?

SC 2.5.7 (Dragging Movements, AA) requires that any functionality that uses dragging can also be accomplished with a single pointer without dragging. Sortable lists, sliders, map pan controls, and drag-and-drop interfaces are the common failure points.

The principle is that some users cannot perform precise dragging operations due to motor difficulties. A user with a tremor may be able to click or tap precisely but not maintain contact with the screen while moving a pointer across a distance. SC 2.5.7 requires an alternative that achieves the same result without the dragging movement.

What counts as a valid single-pointer alternative:

• A sortable list with “move up” and “move down” buttons alongside the drag handle
• A range slider with click-to-set (clicking anywhere on the slider track sets the value to that position) in addition to drag-to-adjust
• A drag-and-drop file upload that also accepts a click-to-browse file dialog
• A map with pan-by-click (double-click to center) or button-based zoom and pan controls in addition to drag-to-pan

The keyboard alternative (which handles SC 2.1.1) does not satisfy SC 2.5.7 on its own - SC 2.5.7 specifically requires a single-pointer (mouse click or touch tap) alternative, not just a keyboard alternative. Both are required.

In practice, this criterion creates the most remediation work in complex web applications that have drag-and-drop as a primary interaction pattern. If you are building a kanban board, a sortable list, or any other drag-primary interface, designing the non-drag alternative from the start is significantly cheaper than retrofitting it. Clicking a card to open a “move to column” select menu is one pattern; arrow key navigation with visual position feedback is another. The key is that the alternative is a first-class interaction, not a hidden accessibility escape hatch.

How Do You Implement WCAG 2.2 Compliance at the Design System Layer?

The practical approach to all three new AA criteria is the same: start with the design token and component layer, not the audit. If your focus ring, touch target sizes, and interaction patterns are defined in the system, compliance becomes structural.

For focus appearance (SC 2.4.11): define focus ring tokens (--focus-ring-color, --focus-ring-width, --focus-ring-offset), create a shared focus-visible utility class that all interactive components use, and run automated contrast checks against the token matrix as part of CI.

For target size (SC 2.5.8): define minimum touch target size as a spacing token (--min-touch-target: 24px, or preferably 44px), and apply it via a consistent padding pattern in all interactive component variants. Icon buttons should have the minimum target size as a base, not as an afterthought.

For dragging movements (SC 2.5.7): establish a design pattern for drag-enabled components that requires a single-pointer alternative. Document it in the design system as a required pattern alongside any drag-and-drop implementation guide. Enforce it in code review and component acceptance criteria.

One update to the system propagates everywhere. That is the leverage that makes design system investment worthwhile for accessibility compliance - not just WCAG 2.2, but every future version.