What 2.5.8 requires
The target for pointer input must be at least 24 by 24 CSS pixels, unless one of five exceptions applies. It's new in WCAG 2.2. The stricter 44 by 44 requirement is 2.5.5 Target Size (Enhanced), Level AAA. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 2.5.8 (opens in a new tab) [1][2].
Exceptions and scope:
- Spacing: an undersized target passes if a 24 CSS pixel circle centred on it doesn't intersect another target or another undersized target's circle.
- Equivalent: the same function is available through another control on the page that meets the size.
- Inline: the target is in a sentence, or its size is constrained by the line-height of surrounding text (links in a paragraph).
- User agent control: the size is set by the browser and not modified by the author.
- Essential: a particular presentation is essential or legally required.
Why it matters
Small targets close together are hard for people with tremors, limited dexterity or low vision, and for anyone on a phone on the move. A mis-tap that hits "remove" instead of "quantity +" in a cart, or the wrong page number in pagination, costs time and sometimes an order. W3C's Understanding document recommends meeting the 24 pixel size as a best practice, regardless of spacing.
Common failures
Tiny icon buttons packed together
16 px icons with 4 px gaps.
/* Fails */
.toolbar button { width: 16px; height: 16px; margin: 2px; }
/* Better */
.toolbar button { min-width: 24px; min-height: 24px; }Close (×) button drawn at text size
<!-- Fails -->
<button class="close" style="font-size:12px">×</button>
<!-- Better -->
<button class="close" aria-label="Close" style="min-width:24px;min-height:24px">×</button>Pagination links crammed in a row
Page numbers of a few pixels each, with no gap.
/* Fails */
.pager a { padding: 0 2px; }
/* Better */
.pager a { display: inline-block; min-width: 24px; min-height: 24px; }Hit area smaller than the visible control
The visual is large, but only the small inner icon is clickable.
<!-- Fails -->
<div class="chip"><a href="/x"><svg width="12" height="12">…</svg></a></div>
<!-- Better -->
<a class="chip" href="/x" aria-label="Remove filter">…</a> <!-- whole chip is the target -->Can automated testing check 2.5.8?
Partly. axe-core measures target size and spacing for many targets. It flags some for review, and exceptions like "equivalent control" or "essential" need a person.
| axe-core 4.13.0 rule | What it checks |
|---|---|
target-size | touch targets have sufficient size and space (failure, sometimes needs review) |
What automation can't decide: Whether an equivalent control exists elsewhere on the page, whether a presentation is essential, targets created by overlapping or transformed elements the rule can't measure reliably, and how the layout behaves at other viewport sizes.
A clean automated result is never proof that 2.5.8 is met. See why sites pass axe-core but fail real screen reader users.
How to test it by hand
- On a phone-width viewport, look for small clickable things: icons, close buttons, pagination, carousel dots, inline controls in tables.
- Use browser devtools to measure the clickable box of each, not just the icon inside it.
- For anything under 24 by 24 CSS pixels, check the spacing exception by imagining a 24 pixel circle centred on it.
- If you're relying on the equivalent exception, confirm the alternative control does the same thing and meets the size.
New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.
How Accessible helps (and where it stops)
Scanning runs axe-core's WCAG 2.2 rules, including target-size, on every URL on a paid plan, and the free page check covers one page against WCAG 2.2 (automated scanning). Real-user monitoring runs axe-core in visitors' browsers with the viewport, zoom and font-size context attached to each finding, so you can see whether problems cluster at small viewports.
Where it stops: Journeys use the keyboard, not a pointer, so they don't test target size. Exceptions and edge cases need a person, ideally with a phone in hand. No automated tool, ours included, can certify that a criterion is met.
Related criteria
Sources
- Understanding Success Criterion 2.5.8: Target Size (Minimum) (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
- Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 2.5.8 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
- axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.
Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.