WCAG 2.5.5 Target Size — Testing Guide for Mobile and Web

WCAG 2.5.5 Target Size (Enhanced) requires interactive targets to be at least 44 × 44 CSS pixels. The less-strict 2.5.8 Target Size (Minimum) is 24 × 24 with spacing exceptions. Get this right and the

WCAG 2.5.5 Target Size (Enhanced) requires interactive targets to be at least 44 × 44 CSS pixels. The less-strict 2.5.8 Target Size (Minimum) is 24 × 24 with spacing exceptions. Get this right and the app is usable for people with motor impairments, tremor, or large fingers. Get it wrong and every tap becomes a lottery.

What 2.5.5 requires

Every interactive element — button, link, icon, form control — must present a tappable area of at least 44 CSS pixels square. Exceptions:

• Equivalent — another control with the same function meets the size
• Inline — links inside a block of text
• User-controlled — user set smaller size themselves
• Essential — the specific presentation requires the smaller target (rare)

At AA level, WCAG 2.2 introduced 2.5.8 (Minimum) at 24 × 24 with exceptions. Most regulated jurisdictions use 2.5.8 as the legal floor.

Why it matters

Aging users, users with tremor (Parkinson's, essential tremor), users in a moving vehicle, users with prosthetics — all benefit. And nearly all users benefit marginally from larger targets. The design tradeoff is density vs accessibility; regulation picks accessibility.

Common violations

• Close icons (X) at 20 × 20 — universally too small
• Navigation bar items at 32 × 32 — many mobile apps fail here
• Radio buttons and checkboxes at 20 × 20 — default browser styles pre-2.5.5
• Inline text buttons in dense lists — 16px text size, 16px height
• Icon-only action buttons in toolbars — 24 × 24 actual, even if touch target is larger

How to test

Automated

• Android: Accessibility Scanner flags < 48dp
• iOS: Accessibility Inspector reports small targets
• Web: axe-core and Lighthouse have target-size rules
• Playwright: assert bounding box per interactive selector

Manual

Use an actual finger. Test on the smallest device you support. Test while walking. Test with nails. Rotate to landscape where thumbs reach differently.

Measurement

Chrome DevTools → computed styles → bounds. React Native, use Flipper or the Inspector. Android, enable "Show layout bounds" in Developer Options for visual inspection.

How to fix

Pad the touch target without enlarging the visual:

.icon-btn {
  width: 24px; height: 24px;  /* visual size */
  padding: 10px;              /* 44 × 44 touch target */
}

Android:

<ImageButton
  android:layout_width="44dp"
  android:layout_height="44dp"
  android:padding="10dp"
  android:src="@drawable/ic_close" />

SwiftUI:

Image(systemName: "xmark")
    .frame(width: 44, height: 44)
    .contentShape(Rectangle())  // makes entire frame tappable

Jetpack Compose:

IconButton(onClick = onClose, modifier = Modifier.size(44.dp)) {
    Icon(Icons.Default.Close, contentDescription = "Close", modifier = Modifier.size(24.dp))
}

Inline link exception

For inline links in running text (not buttons), 24 × 24 is not required. Make them clearly identifiable (underline, contrast) and the exception applies.

How SUSA tests target size

SUSA's elderly persona and accessibility_user persona both check touch target sizes on every discovered screen. Violations are reported with the element label, measured size, and suggested fix. The exploration surfaces dense toolbars, cluster of small icons, and overlapping targets.

susatest-agent test myapp.apk --persona elderly --wcag-level AA

Spacing matters too

If two 24 × 24 targets are adjacent with no spacing, a finger cannot reliably hit either. WCAG 2.5.8 allows 24 × 24 only if there is 8 CSS pixels of spacing on all sides. Verify spacing as well as size.

Test on a real device. Anything you build measuring 44 × 44 in CSS looks small on a 6.1" phone screen. Add padding generously.