Concepts

Touch target size

Also: target size, tap target, hit target

The minimum size of interactive elements activated by pointer input. WCAG 2.5.5 (AAA) requires 44×44 CSS pixels; WCAG 2.5.8 (AA, new in 2.2) requires 24×24. Critical for users with motor disabilities and small-screen users generally.

Touch target size is the operative dimension of any element a user can tap or click. WCAG sets two thresholds: an AAA minimum of 44×44 CSS pixels (since WCAG 2.1) and an AA minimum of 24×24 CSS pixels (new in WCAG 2.2). The criterion exists because motor disabilities — and even ordinary inaccuracy on a small screen — make tiny targets unusable.

The two WCAG criteria

  • 2.5.5 Target Size (Enhanced) — Level AAA — pointer-input targets must be at least 44×44 CSS pixels. Long-standing rule; difficult to achieve site-wide.
  • 2.5.8 Target Size (Minimum) — Level AA, new in WCAG 2.2 — pointer-input targets must be at least 24×24 CSS pixels. The practical compliance floor.

A target meeting the 44×44 AAA threshold also meets the 24×24 AA threshold.

What the rule actually requires

The numbers refer to the target area, not just the visible icon. Apple’s Human Interface Guidelines and Google’s Material Design both default to 44pt / 48dp target sizes for the same reason — there is real ergonomic data underneath.

A common pattern: an icon-only button drawn as a 16×16 SVG, but with padding bringing the clickable area to 44×44. That meets the rule. The visible icon is small; the target is the visible icon plus the padded area around it.

Exemptions

2.5.8 (the AA criterion) has explicit exceptions:

  • Spacing-based exemption. If a target is at least 24×24 or surrounded by enough whitespace that no other target is within 24 CSS pixels, it passes. This protects dense inline layouts (like text links in body copy) that have small target areas but are spaced far enough apart not to accidentally tap a neighbour.
  • Equivalent control elsewhere. A small target is fine if the same function is available via another larger control on the same page.
  • Inline targets. Links inside flowing text are exempt — body copy shouldn’t be re-laid out around a 24-pixel-per-link rule.
  • User-agent-controlled. Browser-default controls are exempt.
  • Essential. When the size is essential to the function (e.g., a CAPTCHA grid).

What this affects in practice

Three common production failures:

  • Icon-only nav buttons sized to 28×28. Fails 2.5.8 unless surrounded by sufficient whitespace, which most dense nav bars don’t have.
  • Tightly-grouped checkbox lists. Checkboxes drawn 16×16 with no padding, lined up vertically with no spacing. Both the target and the spacing are short of the rule.
  • Mobile carousel “previous/next” arrows. Often drawn as 32-pixel chevrons with 4 pixels of padding. Fails 2.5.8.

The fastest manual audit

Open DevTools on any mobile-emulated viewport. Inspect every interactive element. Note the bounding box. Anything below 24 CSS pixels in either dimension, with adjacent targets within 24 CSS pixels, fails 2.5.8.

Most teams adopt a target-size design token across components — every interactive element gets at least a 44×44 hit area regardless of visible size. That’s the cheapest way to make the rule a non-issue.