Adequate size with inadequate spacing still causes false taps
Aliases: false tap · target spacing · adjacent controls
What it is
Even if every target meets a minimum size, insufficient spacing lets touch error land on neighbours and cause false taps. Size answers whether a target can be hit; spacing answers whether a small miss hits another action.
Why it happens
Effective hit regions compete at boundaries. Finger area, angle bias, and aim error jointly form a distribution scattered around the intended landing point, not a single precise dot. Spacing's job is to leave a buffer around the edge of that distribution — the narrower the gap, the higher the fraction of the distribution that falls outside the buffer and across the boundary into a neighbour, and this relationship is not linear: as spacing narrows from generous to tight, the false-tap rate tends to rise sharply below some particular width rather than degrading gradually. An easily overlooked detail: a hit region may already have been expanded beyond an icon's visual boundary to satisfy a minimum touch target size, which means two icons can still appear to have a visible gap between them while their expanded hit regions have quietly overlapped underneath that gap — inspecting the visible gap alone cannot reveal this, because the overlap happens in a hit-testing layer that has no visual rendering at all.
Where it stops holding
Combined selection, segmented sliders, or continuous regions may need no large gaps, but should clearly be one whole rather than independent dangerous buttons. Bigger hit regions must not cross into opposing actions. Software keyboards are a recognized exception to this rule: adjacent keys have almost no physical gap between them and the false-tap rate is inherently high, but these systems generally rely on statistical correction from a language model to absorb that error, not on physical spacing — which shows that "insufficient spacing" is not by itself an unacceptable endpoint, as long as another layer can correct a mistaken input back to the intended one. That compensating mechanism usually does not exist for isolated button-style actions such as delete or send, so a keyboard's high-density layout cannot be treated as a precedent to copy for those.
Applying it
- Leave real blank or non-hit bands between independent actions, and verify that space against the actually rendered hit-region boundary, not just the visible gap between icons.
- Use secondary menus, combined operations, or confirmation where separation is impossible, or introduce a compensating mechanism such as statistical correction the way software keyboards do.
- How to check: plot a heatmap of actual touch coordinates and specifically measure how the rate of cross-boundary contamination — intending to tap A but actually hitting B — changes with physical spacing, rather than reporting only an overall false-tap rate.