Buttons passed during a scroll or drag must not count as clicks

What it is

A finger or pointer goes down on empty space, travels across a row of buttons, and comes up. That is a scroll or a drag. Buttons on the way were not clicked. If down lands on a button and then movement exceeds click tolerance, the gesture should promote to scroll or drag, not still fire click on release. Treating “passed through” as “hit” turns browsing into random activation.

Why it happens

A click’s intent is a down-up with almost no movement. A pan’s intent is visible displacement. Platforms split them with touch slop: past the threshold, the gesture belongs to scrolling or dragging, and controls along the path should not receive click. Limited motor control often adds movement even to an intended tap, so slop must tolerate small jitter. Once the movement is clearly sweeping a list, “Buy” and “Delete” on the way have even less claim to fire.

This is not the same story as “pressed on the target, then slid off to cancel.” Cancel is about an aimed press. Traversal is about a gesture that was never a click. Firing on pointerenter or touchmove uses hit-testing as a stand-in for gesture classification.

Studying it

On a dense button list, perform unambiguous scrolls and drags: start off-button, start on-button then pass the slop, travel across a destructive control. Log click, change, and submit.

Independent variables: slop, whether move handlers fire actions, native versus custom scrolling. Dependent variables: accidental activations during a pan, intended taps swallowed as scrolls because of small jitter.

Custom scrollers often synthesize their own clicks. Test with a real finger. Mouse text-selection is not a substitute.

Where it stops holding

Drawing, sliders, and drag-to-reorder are supposed to respond on move; that is the drag, not “someone else’s button on the way.” A game reticle that hits enemies while held is a design choice; do not score it with list-button rules. Too much slop swallows real taps as scrolls; too little turns scrolls into clicks. Log both failures; do not prevent only one.

Applying it

• Use the platform’s click synthesis. Do not run purchase, delete, or play on touchmove or pointerenter.
• After movement exceeds click slop, do not send click to controls along the path on up. Change the pressed visual into a scrolling state.
• Verify: pan from empty list space across a row of actions. Any activation means traversal was treated as a click. Separately, press a button, barely move, release, and confirm a real click still works.

Related

• Same group: J3.13.1 Fire on release, not press, so the pointer can still cancel · J3.13.3 Double-tap and long-press succeed less often when motor control is limited · J3.13.4 After a miss-tap, recovery should be one undo, not repeating the whole flow
• Nearby: J3.07 Drag Alternatives · J3.09 Accidental Activation and Undo
• Search terms: touch slop · pointer traversal · scroll click