WCAG 2.2 Target Size: A Practical Product UI Guide
Tiny icon buttons and disappearing focus rings often survive a desktop review because they look tidy in a static mockup. They become much harder to use on a phone, with a keyboard, or when a sticky header covers the current control. WCAG 2.2 adds practical checks for exactly these kinds of interaction barriers.
This guide focuses on two Level AA criteria that product teams can translate directly into components and QA: Target Size (Minimum) and Focus Not Obscured (Minimum). It is an implementation guide, not a substitute for assessing every applicable WCAG success criterion.
Data-Heavy Dashboard Design: 12 UX Patterns That Stay Readable
What WCAG 2.2 asks teams to check
Success Criterion 2.5.8, Target Size (Minimum), sets a baseline for pointer targets: a target should be at least 24 by 24 CSS pixels. The criterion includes exceptions, including a spacing exception for smaller targets whose prescribed 24 CSS pixel diameter circles do not intersect neighboring targets. Other exceptions cover equivalent controls, inline targets, user-agent-controlled targets, and essential presentations.
That means the rule is not simply “every visible icon must be 24 pixels wide.” A 16-pixel icon can sit inside a larger button whose interactive box meets the target size. Conversely, an icon with a 24-pixel graphic may still have a smaller hit area than its visual suggests. Measure the interactive target, not the glyph.
Success Criterion 2.4.11, Focus Not Obscured (Minimum), addresses what happens as keyboard users move through a page. A focused component must not be entirely hidden by content created by the author. Sticky headers, cookie notices, chat launchers, and fixed footers can all cover the focused item. The AA minimum is not “the control must always be fully visible,” though reducing partial obstruction is a sensible usability goal.
Keep the conformance levels straight: Focus Appearance is a separate Level AAA criterion. It is useful to adopt a visible, consistent focus indicator as a product standard, but do not label that AAA criterion as an AA requirement.
Turn the criteria into design-system defaults
Start with component geometry. Give icon-only buttons a stable hit area, such as a 40–44 CSS pixel square, even if the icon itself is smaller. These larger dimensions are design choices, not the exact WCAG 2.2 AA minimum. They provide breathing room for touch and reduce the need to rely on the spacing exception.
In a component library, make target dimensions part of the component contract instead of asking every feature team to remember them. Define variants for compact density only when the spacing and context remain usable. Avoid packing independent controls so tightly that a user can activate the wrong action.
Then test focus against the whole page, not just the component. A control may have a good focus ring but still be hidden under a sticky navigation bar after tabbing. Set appropriate scroll offsets for anchor navigation, make overlays dismissible where appropriate, and ensure the focused element can be brought into view without trapping keyboard users.
A practical review workflow
- Inventory pointer targets. Review icon buttons, pagination, close controls, segmented controls, and dense toolbars. Measure the actual hit box in CSS pixels.
- Check neighboring controls. Where a target is below 24 by 24 CSS pixels, verify whether a WCAG exception applies rather than assuming visual separation is enough.
- Tab through real content. Test menus, dialogs, tables, sticky elements, cookie notices, and narrow viewports with a keyboard.
- Test at zoom and reflow. Responsive layouts can change spacing and cause fixed overlays to cover controls that were visible at the default viewport.
- Record the result per component. Include target size, focus indicator, overlay interaction, and an exception rationale in the design-system documentation.
Automated accessibility scans can identify some issues, but they cannot reliably judge every target's spacing context or whether focus is obscured during a complete interaction. Pair automated checks with keyboard testing and a manual review of representative states.
Example: make the hit area larger than the icon
<button class="icon-button" type="button" aria-label="Close dialog">
<svg aria-hidden="true" viewBox="0 0 24 24"><!-- icon --></svg>
</button>
.icon-button {
inline-size: 2.75rem;
block-size: 2.75rem;
display: inline-grid;
place-items: center;
}
.icon-button:focus-visible {
outline: 3px solid currentColor;
outline-offset: 3px;
}
The button's interactive box is larger than its icon. The focus style is a design-system choice; test its contrast against each background and make sure it remains visible around adjacent controls.
For form-specific patterns, see the accessible form design guide. For chart controls and data tables, continue with accessible data visualization.