Search topics
Small tap targets packed too close together
Icon buttons drawn at 16 pixels and set 2 pixels apart leave no room for an imprecise tap.
The problem
People with tremors, large fingers or an imprecise pointer press the wrong button, or miss it.
A shopping basket shows each item on one line: "Linen napkins, Qty 2", then three icon buttons to decrease the quantity, increase it, and remove the item. The buttons are drawn at 16 by 16 pixels and sit 2 pixels apart. On a phone, a tap aimed at plus lands on remove often enough that the item disappears. With a mouse, the same row needs a careful, steady hand.
WCAG 2.5.8 Target Size (Minimum) asks for pointer targets of at least 24 by 24 CSS pixels. A smaller target still passes if a 24-pixel circle centred on it does not intersect another target or the circle of another undersized target. Here each button is 16 pixels and their centres are only 18 pixels apart, so the circles overlap and neither route passes. None of the exceptions apply: these are not links inside a sentence, there is no larger equivalent control on the page, and the size is a design choice, not something essential.
People with tremors or limited fine motor control, people using a head pointer, eye tracking or a mouth stick, and anyone tapping with a thumb on a moving bus. Older users and people with low vision also hit small targets less often. A missed tap that does nothing is annoying; a missed tap that triggers the neighbouring action, like removing the item, costs work and trust.
Size and spacing are geometry, so a scanner can measure them: axe-core's target-size rule flags this row. What it can't judge are the exceptions: whether a larger control for the same action exists elsewhere on the page, or whether the small size is essential. It measures the element's box, so it doesn't see a hit area extended with a pseudo-element. Automated click tests hit the exact centre of an element, so they never slip onto a neighbour. A generated design often shrinks icon buttons to match the text size, and the result looks tidy in a screenshot. A scan finds the small targets; measuring the hit areas and tapping with a real finger confirms the fix.
Try it
Raise the quantity to 5 by tapping plus.
Try it on a phone, or turn on Show target areas. Dashed circles that overlap mean a slip can press the neighbour, like remove.
Broken Can you fix this?
A recreated demo. The broken version is intentionally inaccessible.
The fix
Make each target 24 pixels or larger, extend its hit area, or space it out so a 24-pixel circle around it touches nothing.
- 1Measure the hit area, not the icon: at least 24 by 24 CSS pixels, or a 24-pixel circle that touches no other target.
- 2Hit areas never overlap their neighbours.
- 3Keep native buttons and their names; change only size and spacing.
<div class="line-actions"> <button type="button" aria-label="Decrease quantity">−</button> <button type="button" aria-label="Increase quantity">+</button> <button type="button" aria-label="Remove Linen napkins">×</button></div>Each target is 16 by 16 pixels and the centres are 18 pixels apart. A 24-pixel circle around each button overlaps its neighbour's circle, so the row fails both the size and the spacing route.
Each button is now 32 by 32 pixels, comfortably above the 24-pixel minimum, and the visible button is the whole hit area. People can see how much room they have, and the HTML does not change. flex-shrink: 0 stops a narrow screen from squeezing the buttons back down.
Use bigger buttons. They do the same job as the larger hit area with less CSS and nothing invisible to break, and they also make the target easier to see, a step towards the 44-pixel size of 2.5.5. Keep the larger hit area for when the visible size is fixed, for example by a design system you can't change: it passes, but people still aim at a small shape, and because the area can't be seen, a later change to the gap can make areas overlap without anyone noticing. Spacing is the smallest change and stops wrong presses, but it is not enough on its own: the target stays small, so people with tremors still miss it more often, and the pass breaks as soon as a row or another control moves within reach of the circle.
Measure the hit area in CSS pixels, not the icon inside it: padding and pseudo-elements count, and margins do not. A pseudo-element that runs outside a parent with overflow: hidden is clipped, and so is its hit area. Do not let extended hit areas overlap a neighbour or a nearby link; where two areas overlap, the one on top wins, and the other target shrinks.
The criterion has exceptions: links inside a sentence, controls whose size the browser sets and you have not changed, and targets with an equivalent larger control on the same page. Do not rely on an equivalent hidden in a menu. In component libraries, set the minimum on the shared icon button, not on each use, so a new row cannot shrink it again.
Verify the fix
4 checks.
Test with: Target measurement, Touch, Mouse, Zoom
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the shared button styles change.
Limits
This is a starting pattern, not a guarantee for every application. 24 pixels is the minimum at level AA; 44 pixels, as in 2.5.5, is easier for most people. The guide covers icon buttons in one row; grids, sliders and drag handles need their own checks. Test with the people and devices your users actually have.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.