Skip to main content
Beta: Front-End Checklist is currently in beta. Some issues are still being fixed. Thanks for your patience.

Provide sufficient touch target size

Interactive elements must have large enough touch targets so users with motor impairments can activate them accurately on touchscreen devices.

Utilities
Quick take
Typical fix time 10 min
  • WCAG 2.2 SC 2.5.5 (AAA): touch targets must be at least 44×44 CSS pixels
  • WCAG 2.2 SC 2.5.8 (AA, new in WCAG 2.2): targets must be at least 24×24 CSS pixels OR have 24px of spacing from other targets
  • Apple HIG recommends 44×44 pt minimum; Google Material Design recommends 48×48 dp minimum
  • Use `padding` to enlarge the interactive area without changing the visual size
  • Inline text links are exempt from SC 2.5.8
Why it matters: Motor disabilities such as essential tremor, Parkinson's disease, hemiplegia, and spasticity make it difficult to tap small targets with precision. A 24×24px icon button with no padding requires a fine-motor action that many users simply cannot perform. Insufficient tap target size is one of the most common barriers for users with mobility impairments on mobile and tablet devices. Even users without disabilities benefit from larger targets, reducing accidental activations.

Rule Details

Touch targets are the portions of the screen that respond to user input. WCAG 2.2 Target Size (Minimum) (opens in new tab), the older WCAG 2.5.5 target size guidance (opens in 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

/* ✅ 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 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.

Use with AI

Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.

Check

Verify implementation

Find all interactive elements: `<button>`, `<a>`, `<input>`, `<select>`, `<textarea>`, and elements with click/touch event handlers or `role='button'`. For each, compute the rendered bounding box size (including padding). Flag elements whose width or height is less than 24px (WCAG 2.2 AA threshold) or less than 44px (AAA / platform guidelines). Also check spacing: elements smaller than 44px should have at least 24px of clear space from adjacent interactive elements.

Fix

Auto-fix issues

To increase touch target size without changing visual appearance: (1) Add `padding` to the element — e.g., `padding: 12px` on a button adds 12px to each side of the visual content. (2) Use `min-width` and `min-height` to enforce a floor: `min-width: 44px; min-height: 44px`. (3) For icon-only buttons, use a transparent pseudo-element to extend the hit area: `.icon-btn::before { content: ''; position: absolute; inset: -12px; }` with `position: relative` on the button. (4) Ensure adequate spacing between small targets so users do not accidentally activate the wrong element.

Explain

Learn more

WCAG 2.2 introduced SC 2.5.8 (Target Size, Minimum) at Level AA, requiring touch targets to be at least 24×24 CSS pixels or have 24px of offset spacing from neighboring targets. The older SC 2.5.5 (Target Size) at Level AAA recommends 44×44px. These thresholds are based on average human fingertip size (approximately 10mm) and the precision required for touchscreen interaction. Users with tremors or limited dexterity need larger targets because their touch point can deviate by 20–30px from where they intend. The 44px recommendation aligns with Apple's Human Interface Guidelines and Google's Material Design system.

Review

Code review

Review the rendered markup and interactive states that affect Provide sufficient touch target size. Flag exact elements, roles, labels, focus behavior, or keyboard interactions that violate the rule, and note how to verify the fix with browser accessibility tooling or assistive tech.

Sources

References used to support the guidance in this rule.

Further Reading

Tools and supplementary material for exploring the topic in more depth.

axe DevTools
deque.comTool

Rules that often go hand-in-hand with this one.

Meet minimum color contrast ratios

Text and background colors must have sufficient contrast to be readable by users with low vision or color blindness.

Accessibility
Provide visible custom focus indicators

Ensure all interactive elements have a clearly visible focus indicator for keyboard navigation — never just remove the default outline without providing a better alternative.

CSS
Make links in text blocks visually distinguishable

Links within blocks of text must be distinguishable from surrounding non-link text by more than color alone.

Accessibility

Was this rule helpful?

Your feedback helps improve rule quality. This stays internal for now.

Loading feedback...
0 / 385