Pointer Cancellation

What it asks

When a user starts a tap or click and then realises they’re on the wrong target, they should be able to slide off before lifting their finger / releasing the mouse, and the action should not fire. That means the activation must happen on pointerup / click — the standard browser behaviour — not on pointerdown / mousedown.

The SC asks for one of four guarantees:

• The down-event does not trigger the function, or
• Completion happens on up-event over the same target, with the option to abort by moving away, or
• An “undo” is available after activation, or
• The reverse of the function reverses the result (toggle).

Essential activations — like the down-stroke of a piano key in a music app — are exempt.

How to meet it

• Use click listeners, not mousedown / touchstart. The browser already implements the correct cancel-on-drag behaviour.
• For custom widgets handling pointer events manually, fire on pointerup and check the target is still the same element under the cursor.
• For destructive actions (delete, send), pair with a confirmation step or an Undo toast.
• For toggle buttons (mute, favorite, pressed state), a second tap reverses the change, which also satisfies the SC.

Common failures

• Buttons wired up with onmousedown that fire as soon as the pointer presses. Drag-off does nothing.
• Custom drag handles that interpret pointerdown as a “select” event.
• Native-feeling cards that navigate to a detail page on touchstart — the user cannot scroll past without accidentally activating.
• Dropdown menus that close on mousedown outside instead of click, eating the click.

Why it matters

Drag-off-to-cancel is how users with tremor, motor impairments, or imprecise pointing (stylus on a wobbling train) recover from a mis-tap. Firing on the down-event removes that escape hatch — once the finger touches, the action is committed. It is also a usability tax on everyone: even non-disabled users routinely rely on drag-off when their tap lands on the wrong target.