Touch Targets That Are Too Small: Size, Spacing, and the 24 Pixel Floor
Tiny icons and packed link rows fail WCAG 2.2 target size rules and frustrate every phone user. How to measure targets, use the spacing exception honestly, and fix the worst offenders first.
A shopper on a train tries to tap the small x on a promo pop-up three times, hits the offer link twice, and leaves. Nobody files that as an accessibility bug. It gets filed, if anywhere, as a bounce. But small, crowded touch targets are exactly what WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum), was written to catch, and they are one of the cheapest classes of barrier to remove once you know how to measure them.
The rule is narrower than most teams fear and stricter than most themes ship. This post walks through what 2.5.8 actually requires, where its exceptions stop, and the order in which to fix a real storefront: pop-up closes, header icons, swatch rows, and footer link clusters, in that order.
What the criterion requires, in plain terms
WCAG 2.2 sets the Level AA floor at 24 by 24 CSS pixels for pointer targets. A target smaller than that can still pass if a 24 pixel circle centred on it does not overlap any neighbouring target, which is the spacing exception. Inline links inside a sentence of body text are exempt, as are targets whose size is set by the browser rather than the page. Level AAA, criterion 2.5.5, raises the bar to 44 by 44 CSS pixels.
Apple's Human Interface Guidelines recommend 44 by 44 points and Android's Material guidance recommends 48 by 48 density-independent pixels. Those are platform recommendations, not WCAG requirements, and the gap between them is the practical story: building to 24 pixels exactly passes the standard and still feels cramped on a moving bus. Build new components to the platform numbers, test old ones against the 24 pixel floor.
Where stores actually fail it
The failures cluster in the same places on almost every storefront. Close buttons on pop-ups and cookie notices are routinely drawn at 14 to 18 pixels. Social icon rows in footers pack five targets into the width of two. Colour swatches sit shoulder to shoulder with gaps of 2 or 3 pixels. Quantity steppers, pagination arrows, and the remove-item link in a mini cart are all drawn for a mouse cursor, not a thumb.
Zoom does not rescue these. A shopper who zooms to read the price then has to scroll horizontally to find the checkout button, trading one barrier for another. The fix is in the component, not in hoping users compensate.
How to measure without guessing
Open the page at a mobile viewport, 360 to 390 pixels wide, and inspect each interactive element's rendered box, padding included. The target is the whole clickable area, not the visible glyph, so a 16 pixel icon inside a button with 8 pixels of padding all round is a 32 pixel target and passes. Record the box and the gap to the nearest neighbour; a screenshot with the numbers beats a paragraph of opinion in a remediation ticket.
Automated scanners mostly cannot do this check. Target size needs layout-aware measurement, which is why axe or Lighthouse passing a page tells you almost nothing about 2.5.8. This one is a manual pass, page template by page template, and it is fast once the first template is done.
Fix order that respects a real budget
Start with anything that blocks a task when mistapped: pop-up closes, banner dismissals, cart removal, checkout steppers. Then the header, because it appears on every page. Footer icon rows and pagination can wait a sprint. Where a visual design truly cannot grow, use the spacing exception properly: keep the glyph, grow the padding, and document that the 24 pixel circle clears its neighbours.
Related reading: Accessible Size and Fit Selectors: Swatches Are Radio Groups, Not Pictures, Accessible Gift Card Flows: Buying, Sending, and Redeeming Without a Trap, Accessible Quantity Pickers and Steppers on Product Pages.
Frequently asked questions
Does every link on my site need to be 24 pixels tall?
No. Links inside a sentence or block of body text are exempt from WCAG 2.5.8. The criterion is aimed at standalone controls and link lists: menus, icon rows, swatches, buttons, and footer clusters where a mistap lands you somewhere wrong.
Is 24 pixels big enough for real users?
It is a floor, not a recommendation for comfort. Apple suggests 44 points and Android 48dp for tappable elements. Meeting 24 by 24 CSS pixels satisfies WCAG 2.2 Level AA, but new design work should aim at the platform sizes where the layout allows it.
Can a scanner check target size for me?
Mostly no. Mainstream tools have limited or no reliable coverage of 2.5.8 because it requires measuring rendered layout and spacing between neighbours. Plan a short manual pass per template with a mobile viewport and the browser inspector.
What should I fix first if dozens of targets fail?
Fix the ones where a wrong tap costs the user something: dismiss buttons, cart controls, checkout steppers, and anything inside a modal. Decorative footer icons can be scheduled after the task-blocking controls are safe.