Target Size: Accessible Touch Targets and WCAG 2.5.8

Every interactive element has a target — the region you can click or tap to activate it. When that region is small or hemmed in by neighbors, activating it demands fine motor control that not everyone has. A user with a hand tremor, reduced dexterity, or a temporary injury will miss repeatedly; so will anyone tapping with a thumb on a moving bus. Missed taps are not just annoying — they can trigger the wrong action entirely.

Generous targets help everyone: they are faster to hit under Fitts's law, more forgiving on touch screens, and less error-prone for all users. This is why WCAG 2.2 promoted a target-size minimum to Level AA — small, crowded controls are a mainstream usability problem, not an edge case.

Two criteria govern target size, at two levels of strictness. The AA one is new in WCAG 2.2 and is the one most teams now have to meet.

The sizes are in CSS pixels, not physical device pixels, so they scale correctly across screen densities. If you design every standalone control to 44 px, you clear both criteria at once and match the platform touch guidelines users already expect — a good default even though AA only strictly requires 24.

2.5.8 is pragmatic — it ships with exceptions so you are not forced to bloat every control. A target under 24×24 still passes if one of these applies:

• Spacing. The target is small, but a 24 px diameter circle centered on it does not overlap the circle of any adjacent target. In other words, undersized controls are fine if they are spaced far enough apart.
• Inline. The target is in a sentence, or its size is constrained by the line-height of surrounding text — so links within prose are exempt.
• Essential. A specific size is legally required or essential to the information (for example, a pin on a map at a precise location).
• User-agent control. The size is determined by the browser and not modified by the author (a default checkbox, a native <select>).
• Equivalent. The same action is available through another control on the page that does meet the minimum.

The visible graphic can stay small; what matters is the hit area. The simplest, most robust approach is a minimum size plus padding, so the clickable region grows around the content regardless of the icon or label inside.

/* Guarantees the hit area meets AA (and reaches for AAA at 44px) */
.icon-button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 44px;   /* 24px passes AA; 44px is the comfortable target */
  min-height: 44px;
  padding: 10px;     /* grows the hit area around a small icon */
}

/* Icon-only controls in a tight toolbar: use the spacing exception */
.toolbar .icon-button {
  min-width: 24px;
  min-height: 24px;
  margin: 6px;       /* keep 24px circles from overlapping neighbors */
}

A few implementation notes:

• Set the size on the interactive element itself (the <button> or <a>), not a wrapper — the target is whatever actually receives the click.
• Prefer min-height / min-width over fixed heights so long labels can still grow the control.
• Use padding rather than a transparent overlay where you can; padding is simpler and keeps focus outlines wrapping the true hit area.

The controls that fail target size most often, and the fix for each:

• Sizing the icon, not the button. A 16 px SVG in a shrink-wrapped button gives a 16 px target. Pad the button.
• Fixed heights that clip. A hard height: 20px both fails the minimum and truncates long labels. Use min-height.
• Crowded controls with no spacing. Small and adjacent fails both the size rule and the spacing exception. Give them room.
• Assuming inline text links must be 24 px. They are exempt — do not over-pad prose links and break your line spacing.
• Testing only on desktop with a mouse. Target-size problems surface on touch. Check on a real phone, and remember hover is not available there.