WCAG Target Size: How to Meet the Touch Target Rules

A recognizable icon can still be difficult to activate. People using touch, a mouse, a stylus, or an alternative pointer need enough space to select the intended control without activating its neighbor. WCAG target-size requirements address the interactive area, not the visual size of the symbol inside it.

Start with the clickable rectangle

Use browser developer tools to inspect the element that actually receives pointer input. A 16-pixel icon inside a 40-pixel button has a different target from a 16-pixel icon with a click handler attached directly. Padding usually expands a button's interactive area; margin usually only separates it from other elements.

The px-to-rem converter helps translate proposed component dimensions into relative units. Enter the root font size used by your design and convert a target dimension such as 44 pixels. At a 16-pixel root, that is 2.75rem. Measure rendered CSS pixels afterward because user settings and application styles can change the final dimensions.

Target sizing complements rather than replaces the checks in the accessible interface guide. A large button with no accessible name remains inaccessible. A generous hit area also cannot repair a control that only works with a mouse.

Understand the AA minimum and its exceptions

WCAG 2.2 success criterion 2.5.8, Target Size (Minimum), is Level AA. Pointer targets must be at least 24 by 24 CSS pixels, unless an exception applies. Both dimensions matter: a 100-by-18-pixel control does not meet the dimensional minimum on width alone.

The spacing exception is geometric. Center an imaginary circle with a diameter of 24 CSS pixels on each undersized target's bounding box. It must not intersect another target or the corresponding circle for another undersized target. This is not a universal requirement for 24 pixels of empty space between controls.

For two small square icons on the same horizontal centerline, centers more than 24 pixels apart can satisfy that part of the check, provided neither circle touches another target. Larger neighbors and diagonal arrangements require examining the actual geometry. Do not reduce the rule to a single gap token for every shape.

Other exceptions matter in realistic interfaces:

• Equivalent controls can provide the same function elsewhere on the same page while meeting the criterion.
• Inline targets in sentences, or targets constrained by surrounding non-target text line height, have an exception.
• User-agent controls qualify when the author has not modified their size.
• An essential presentation, or a legally required presentation, can justify a specific exception.

Document the exception and the evidence. A dense layout, an established brand style, or a request to fit more controls above the fold is not automatically essential.

Separate the AAA goal from product defaults

Target Size (Enhanced), criterion 2.5.5, is Level AAA and generally calls for 44 by 44 CSS pixels, subject to its own exceptions. It does not have the AA spacing exception. A product can choose 44-pixel defaults without claiming full AAA conformance.

For a primary mobile toolbar, start with a 44- or 48-pixel square as a design choice and evaluate the resulting layout. This leaves room for a recognizable icon and forgiving padding. For a dense desktop table, consider a dedicated actions menu rather than squeezing four tiny controls into every row.

Avoid treating larger targets as a reason to hide essential actions. Moving everything into menus adds interaction cost and can harm discoverability. Decide which actions deserve persistent controls, which can be grouped, and which need confirmation because an accidental activation is costly.

CSS pixels are not physical device pixels. A high-density phone may use several device pixels to render one CSS pixel. Do not multiply the WCAG threshold by the device pixel ratio, and do not assume a desktop screenshot establishes the physical comfort of a mobile interface.

Build a target that matches its visible affordance

A native button with padding is usually easier to reason about than a pseudo-element extending an invisible click region. Here is a reusable starting point for icon controls:

<button class="icon-button" type="button" aria-label="Close panel">
<svg width="20" height="20" viewBox="0 0 20 20"
     aria-hidden="true" focusable="false">
  <path d="M5 5l10 10M15 5L5 15" />
</svg>
</button>

.icon-button {
box-sizing: border-box;
display: inline-flex;
align-items: center;
justify-content: center;
min-inline-size: 2.75rem;
min-block-size: 2.75rem;
padding: 0.75rem;
border: 1px solid currentColor;
}

.icon-button:focus-visible {
outline: 3px solid #174d87;
outline-offset: 3px;
}

The accessible name describes the action, while the SVG stays out of the accessibility tree. In production, give the path suitable stroke styling and verify the control in forced-colors mode. See MDN's button reference for native behavior and form-related defaults.

Avoid overlapping hit areas. Expanding multiple adjacent controls with absolute-positioned pseudo-elements can make the apparent target ambiguous or let one control intercept another's clicks. Keep focus outlines aligned with the usable control whenever possible. If you intentionally extend the hit region, inspect stacking, clipping, and pointer behavior along every edge.

Test compact layouts and record the evidence

Create a small audit sample covering navigation, pagination, dismiss buttons, date pickers, password visibility toggles, and table actions. Include loading states, validation errors, translated labels, and narrow viewports. Those states frequently change spacing without changing the original component specification.

For each target, record its width and height using the element's bounding rectangle, then confirm the intended pointer behavior manually. A measurement is a diagnostic aid, not a verdict: transforms, clipping, overlapping elements, and event delegation can change which region is truly operable.

Test controls at 200% zoom and with larger text as additional usability checks. Ensure the layout wraps or grows instead of clipping labels or collapsing button height. Activate the outer edges as well as the center, and verify that tapping near a destructive action does not trigger it unexpectedly.

Keep target dimensions in shared component specifications and add representative examples to design-system guidance. Use separate tokens for icon size, target size, and spacing; one number rarely serves all three purposes well. Review any exception when the layout changes, because its original spacing evidence may no longer apply.

A useful issue report names the control, viewport, measured dimensions, neighboring targets, criterion, and proposed fix. Write “increase the dismiss button's interactive height from 18 to at least 24 CSS pixels” rather than “make the icon accessible.” That gives developers a testable change without prescribing unnecessary visual enlargement.

Key takeaways

• Measure the interactive area, not the glyph or surrounding empty space.
• AA generally requires 24 by 24 CSS pixels, with defined exceptions.
• AAA generally uses 44 by 44 CSS pixels and has different exceptions.
• Padding can enlarge a target; margin mainly changes separation.
• Keep click regions distinct and verify their edges manually.
• Record measurements and exception reasoning with each finding.