Touch Target Sizing (WCAG 2.5.8 / 2.5.5)

Interactive example · Touch target sizeResize the targets

Target size: 44px

＋✎⤴🗑

✓ WCAG 2.5.8 minimum (24px)✓ Comfortable (44px, Apple/AAA)

Small targets cause mis-taps, especially for motor impairments and one-handed use. WCAG 2.2 sets a 24×24px floor (2.5.8); 44×44px is the comfortable target on touch.

The full lesson

Getting touch targets right is one of the highest-return accessibility improvements you can make. It costs almost nothing to do correctly from the start. It directly helps users with motor impairments, arthritis, or tremors — and also anyone using a stylus, glove, or one hand. WCAG 2.2 (published October 2023) made target sizing a normative requirement, not just a suggestion. That means undersized controls are now a legal compliance failure in any jurisdiction that references WCAG 2.2 AA. Understanding both criteria — 2.5.5 and 2.5.8 — lets you build interfaces that are genuinely easier to use for everyone.

Why Target Size Matters

Fitts’s Law captures something every designer knows instinctively: the smaller a target, the harder it is to hit accurately. On a touchscreen, there is no cursor snap to help. Your finger pad is 7–10 mm wide, and the device cannot correct for aim. A 24 × 24 px button on a 390-point-wide phone screen is roughly 6 mm across — smaller than most fingertip contact areas.

The consequences are measurable. A 2022 study referenced by the W3C Mobile Accessibility Task Force found error rates 3–4× higher on targets below 24 CSS pixels compared with targets at 44 px. For users with essential tremor or Parkinson’s disease, that mismatch causes fatigue, frustration, and eventually task abandonment.

The Two WCAG Criteria — 2.5.5 vs. 2.5.8

WCAG 2.2 has two distinct success criteria for target size. They are not interchangeable. They serve different compliance levels and different design contexts.

Criterion	Level	Minimum size	Conditions / exceptions
2.5.5 Target Size (Enhanced)	AAA	44 × 44 CSS px	No exceptions for inline targets
2.5.8 Target Size (Minimum)	AA	24 × 24 CSS px	Spacing exception; inline exception; essential exception

2.5.8 is the current legal baseline for AA conformance. Every interactive target must either: (a) have a target size of at least 24 × 24 CSS pixels, OR (b) have enough offset spacing from adjacent targets so that a 24 px circle centred on the target does not intersect another target or its offset area.

2.5.5 is the aspirational standard — 44 × 44 CSS pixels with no exceptions. Apple’s Human Interface Guidelines and Google’s Material Design 3 both recommend this size. Apple specifies 44 pt minimum; Material specifies 48 dp. If your team targets AAA, or simply wants best-in-class usability, 44 × 44 is your working floor.

The Spacing Exception in 2.5.8 — Explained Clearly

The spacing exception is the most misunderstood part of 2.5.8. It does not mean you can add a little padding and call a 16 px icon compliant. It means the offset area — the clickable bounding region including any invisible padding around the visible target — must ensure that a 24 px diameter circle centred on the control does not overlap an adjacent control’s offset area.

Here is a concrete example. Your icon is 16 × 16 px. You add 4 px of invisible padding on all sides, making the offset area 24 × 24 px. For the spacing exception to apply, none of an adjacent target’s 24 px circle can intersect yours. In a row of three 16 px icons spaced 8 px apart, this fails — their circles overlap. You would need at least 8 px of gap between each icon’s offset area edge (not the visible icon edge) to satisfy the exception.

The cleanest approach: size the tappable area to 44 × 44 CSS px from the start. The spacing exception is a last resort for dense UIs like inline text links, not a routine design shortcut.

What Counts as a “Target”

WCAG 2.5.8 applies to all user-interface components that receive pointer input, including:

• Buttons and links
• Checkboxes and radio buttons (the control itself, not just the label)
• Custom toggles and switches
• Menu items and dropdown options
• Carousel controls (previous/next arrows)
• Close (“X”) buttons on modals, alerts, and chips
• Draggable handles and resize controls
• Map pins and data-viz interaction points

The criterion does not apply to targets where size is “essential” to the information conveyed — for example, a mini-map with precise geographic pin positions. It also does not apply to inline text links within a sentence when resizing would disrupt text flow. Use those exceptions honestly. They are not a wholesale exemption for dense UI.

Implementation Patterns

Minimum clickable area with CSS

Separate the visual size from the interactive footprint using padding or pseudo-elements.

/* Pattern 1 — padding on the element */
.icon-button {
  /* visible: 24×24 icon via SVG */
  padding: 10px;           /* tappable area: 44×44 */
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

/* Pattern 2 — pseudo-element overlay (no layout impact) */
.icon-button {
  position: relative;
}
.icon-button::before {
  content: "";
  position: absolute;
  inset: -10px;            /* expands hit area 10px on all sides */
  border-radius: inherit;
}

The pseudo-element approach is useful when you cannot change the element’s own padding — for example, a tightly spaced navigation tab bar where adding padding would break the visual layout.

Checkbox and radio sizing

Native input[type="checkbox"] and input[type="radio"] render at browser-default sizes (typically 13–16 px), which fail 2.5.8 without enlargement. Two reliable approaches:

/* Enlarge native control */
input[type="checkbox"],
input[type="radio"] {
  width: 24px;
  height: 24px;
  cursor: pointer;
}

/* Or: make the label the full tap target */
label {
  display: flex;
  align-items: center;
  gap: 0.5rem;
  min-height: 44px;   /* tap height covers label+control together */
  cursor: pointer;
}

When a label is programmatically associated via for/id or wraps the input, clicking anywhere on the label activates the control. This is often better UX anyway — users can tap the text, not just the tiny box.

Design tokens for minimum tap sizes

Encode minimum tap-target sizes as design tokens so the constraint is system-wide, not a per-decision guess.

{
  "touch-target-min": { "$value": "44px", "$type": "dimension" },
  "touch-target-comfortable": { "$value": "48px", "$type": "dimension" },
  "touch-target-spacing-min": { "$value": "8px", "$type": "dimension" }
}

Using the W3C DTCG token format ($value/$type) means these values can flow to Figma via token plugins, CSS custom properties, and native mobile design systems from a single source of truth. That eliminates the class of bugs where constraints drift between platforms.

Responsive and fluid contexts

On a desktop with a mouse, pointer precision is much higher. The safest approach is to keep a 24 × 24 minimum universally and offer 44 × 44 on coarse-pointer devices.

/* coarse pointer = touchscreen (finger), stylus, controller */
@media (pointer: coarse) {
  .icon-button {
    min-width: 44px;
    min-height: 44px;
  }
}

This media query targets devices where the primary pointing mechanism is imprecise — phones, tablets, and hybrid laptops in touch mode — without over-padding desktop button rows.

Common Failures and How to Spot Them

Failure pattern	Why it fails	Fix
Icon-only buttons with no padding (e.g., 16×16 px close “X”)	Visual size below 24 px, offset area insufficient	Add padding or pseudo-element to reach 44×44
Dense pagination: “1 2 3 4 5” with 8 px gaps	Offset circles overlap between numerals	Increase spacing or wrap each number in a 44 px min-height tap region
Checkbox rendered at system default (~13 px)	Below 24 × 24 CSS px threshold	Use CSS to enlarge, or redirect click to the label
Social share icon row: three 20 px icons at 4 px apart	Below 24 px; spacing exception also fails	Increase icon size to 24 px minimum plus 8 px gap, or 44 × 44 with any gap
Dropdown option rows at 24 px height	Hits minimum but leaves no breathing room	Target 44 px row height for comfort; 32 px absolute minimum
Native date-picker sub-controls	Browser-rendered; may be below threshold	Use a custom accessible datepicker with ARIA and adequate row height

Testing Touch Targets

Automated testing catches some failures, but not all. A layered approach works best.

Automated (fast, shift-left): Axe-core and IBM Equal Access Checker flag targets with zero hit area or visually undersized controls. Chrome DevTools’ Rendering panel surfaces repaint regions that help verify actual painted size.

Manual browser testing: Chrome DevTools > Elements > Computed tab shows the rendered box model, including padding. For a button, check total padding-inclusive dimensions. On mobile, Chrome DevTools remote debugging lets you inspect elements on a real device.

Manual touch testing: Use a real phone, not just a desktop browser with device emulation. Test with a finger and pay attention to mis-taps on small controls. An informal 5-user motor-stress test — ask participants to complete flows with one hand or while walking — surfaces failures no automated tool will ever catch.

Figma audit: The Accessibility Annotation Kit (a community Figma file) includes a “Touch Target” annotation component. Designers can mark controls and flag those that fall below 44 × 44 before handoff, preventing the problem from ever reaching code.

Outdated Habits to Retire

Several legacy approaches are still common in codebases and design systems, even though they are objectively insufficient.

• Relying on the label without association: Many older form libraries make only the radio circle or checkbox box interactive, not the label. If the label is not a label for element or does not wrap the input, tapping it does nothing — a usability and 2.5.8 failure at the same time.
• Targeting WCAG 2.0 or 2.1 only: WCAG 2.0 has no target-size criterion at all. WCAG 2.1 added 2.5.5 as AAA-only. Teams that have not upgraded their compliance target to WCAG 2.2 AA are missing the legally current standard in many jurisdictions. (EU EN 301 549 maps to WCAG 2.1 with 2.2 under active adoption; US Section 508 is expected to reference 2.2 in its next refresh.)
• Treating pixel density as a compliance multiplier: A button specified as “44 pt” in an iOS Sketch file exported to a 3× screen is not “3× compliant” — it is still 44 CSS-equivalent points. Physical device pixels are irrelevant to WCAG measurement.
• Removing focus rings alongside target fixes: Touch-target remediation often happens alongside “polishing” custom controls. Removing outline without a replacement is a separate WCAG 2.4.7 / 2.4.11 violation that makes keyboard-only navigation impossible. Fix touch target size and focus visibility together.

A Decision Framework

When reviewing any interactive component, step through these four checks in order.

1. Is the target at least 44 × 44 CSS px (including padding or pseudo-element hit area)? If yes, you satisfy both 2.5.8 and 2.5.5 — done.
2. Is the target at least 24 × 24 CSS px? If yes, check spacing: does a 24 px circle centred on this target overlap any adjacent target’s 24 px circle? If there is no overlap, you satisfy 2.5.8 (AA). Still consider whether 44 px is achievable.
3. Is the target below 24 × 24 CSS px with no spacing exception possible? This is a WCAG 2.2 AA failure. Resize the hit area.
4. Is this an inline text link or an “essential” exception? Document the exception explicitly in your audit notes. Do not rely on it silently.