E1.07.2non-overlapping hit targetsdesignresearch

Adjacent buttons’ hit regions must not overlap

Aliases: overlapping hit slop · hit-test fight · neighbor miss

What it is

Each button may expand its hit region, but two neighbors must not claim the same pixel. After an overlap, ownership of that pixel is decided by z-order, bubbling, or “who registered last,” which the user cannot predict. Visually the keys may sit 8 pixels apart; if the hot regions meet in the gap, a tap on “empty space” still fires one of them—often the wrong one.

Why it happens

Expansion is an optimization for one control. Side by side, the two expansion bands collide on the midline. Hit-testing is a point query: one coordinate can go to one control. If the implementation takes the topmost or the last listener, the overlap band becomes a random machine. Worse, the visual gap teaches “nothing happens here,” yet a tap fires, so a cancel gesture (slide out, then lift) may hit the neighbor in the gap. A contact also has area: the centroid can sit in the gap while the contact circle covers both hot regions, and the driver stack’s tie-break is invisible. Overlap is not “easier to hit.” It dissolves Fitts’s target edges and glues two targets back into one ambiguous zone.

Studying it

Hold visual spacing fixed and grow both expansions until the hot regions intersect. Log which control fires for taps near the midline. Compare “topmost wins” with “neither fires.”

Independent variables: visual spacing, expansion on each side, simulated contact radius, arbitration rule. Dependent variables: gap taps that fire, fires of the unintended button, cancel gestures eaten by the neighbor.

A mouse click on an exact pixel underestimates the problem: a mouse has no contact circle. Touch, or a circular contact simulation, is what reveals the overlap band’s true width.

Where it stops holding

A segmented button group is drawn as one block with dividers, not gaps; the hit on a divider must have a stated owner (usually half each). That is deliberate adjacency, not accidental overlap. An absolutely positioned close “×” on a card corner already fights the card’s hit and needs an explicit “× wins.” A decorative layer with pointer-events none is not a button; clicking through it is not overlap.

Applying it

  • Expand back from the midline so the hit rectangles leave a seam that belongs to no one, or assign the seam to one control and paint it in the debug layer.
  • Give toolbar icon buttons a fixed slot at least as wide as the minimum reach, icon centered, rather than letting each expand until it hits the neighbor.
  • Color hit regions in debug; any mixed-color pixel is overlap.
  • Verify by walking a line of taps down the gap. If left/right activation is unstable, or a tap on “empty” fires a button, the hit regions overlap.

Related

  • Within the group: E1.07.1 The hit target may be larger than the visual area · E1.07.3 A text button’s hit region needs an explicit expansion
  • Adjacent: C2.03 Minimum spacing of touch targets · E1.14 Button groups and split buttons · C2.09 Accidental touch and palm rejection
  • Search terms: overlapping hit targets · hit testing · tap spacing

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E1.07.2