Skip to main content
CodeRocket
Accessibilitymediumvisual

Provide sufficient touch target size

rule · touch-targets

Touch targets are the portions of the screen that respond to user input. WCAG 2.2 Target Size (Minimum) (opens in a new tab), the older WCAG 2.5.5 target size guidance (opens in a new tab), and platform guidance from Apple and Google all converge on the same idea: interactive areas must be physically generous enough to hit reliably.

Code Example

CSS
/* ✅ Good: padding ensures sufficient touch target */
.button {
  padding: 12px 16px;
  min-height: 44px;
  min-width: 44px;
}
 
/* ✅ Good: icon-only button with padding expanding hit area */
.icon-button {
  display: flex;
  align-items: center;
  justify-content: center;
  width: 20px;  /* Visual icon size */
  height: 20px;
  padding: 12px; /* Expands touch area to 44×44px total */
  background: transparent;
  border: none;
  cursor: pointer;
}
 
/* ✅ Good: invisible pseudo-element extends hit area */
.small-icon-link {
  position: relative;
}
.small-icon-link::before {
  content: '';
  position: absolute;
  inset: -12px; /* Extends hit area 12px in all directions */
}
 
/* ❌ Fail: icon button with no touch area expansion */
.close-icon {
  width: 16px;
  height: 16px;
  /* 16px is too small — fails both 24px and 44px thresholds */
}

Why It Matters

This is a motor-access requirement, not just a mobile polish issue. Small icon buttons and tightly packed actions routinely fail users who cannot make a precise tap.

  • Motor Impairments: Tremors, spasticity, and limited dexterity make precise tapping difficult or impossible on small targets.
  • One-Handed Use: Users holding a device with one hand often tap with a thumb, which has lower precision than a fingertip.
  • Stylus Users: Despite higher precision, users with styluses often have motor impairments that reduce accuracy.
  • All Users: Larger targets reduce accidental activations for everyone, especially in motion or low-light conditions.

Size Requirements

StandardMinimum SizeLevel
WCAG 2.2 SC 2.5.824×24 CSS px (or 24px spacing offset)AA (new in WCAG 2.2)
WCAG 2.1 SC 2.5.544×44 CSS pxAAA
Apple HIG44×44 ptPlatform guideline
Google Material Design48×48 dpPlatform guideline

Aim for 44×44px as a practical target — it satisfies AAA and both platform guidelines.

This pattern still needs to satisfy WCAG 2.5.8 Target Size (Minimum) (opens in a new tab), so the stretched clickable area should be intentional rather than visually implied.

For card-style or row-style UI where the whole block should be clickable (e.g. a checklist card, resource card, or audit row), use a stretched link so the link's accessible name is the card title and the entire area is the touch target:

  • Container: position: relative with the card/row styles.
  • Title link: the <a> or <Link> wraps only the title text inside the heading. It uses ::after (position: absolute; inset: 0) to stretch the clickable area to the card boundaries. Because the link is position: static (the default), the ::after is positioned relative to the card container.
  • Secondary actions (e.g. menu, secondary link): give them position: relative; z-index: 10 so they stay clickable above the stretched ::after.

Do not wrap the entire card in a single <a>, and do not use a separate overlay <a> as a sibling. The link should wrap the title and stretch from there. See project doc docs/card-links.md for reference components.

Exceptions

  • Evaluate the rendered experience before treating a static-code smell as a blocker; interaction timing, browser behavior, and assistive technology output often determine severity.
  • Not every secondary accessibility issue deserves equal weight; prioritize the issue that most directly blocks perception, operation, or understanding.
  • Avoid adding redundant markup or ARIA solely to satisfy a rule when a simpler semantic implementation would eliminate the issue entirely.

Verification

Automated Checks

  • Inspect the browser accessibility tree or accessibility pane for the relevant element, role, or accessible name.
  • Run an automated accessibility checker such as axe or Lighthouse where applicable.

Manual Checks

  • Test the affected UI with keyboard-only navigation and confirm the rule holds in the rendered experience.
  • Re-test one representative user flow with a screen reader if this rule affects a key interaction.