← All criteria

Operable · Level A · 2.5.2

Pointer Cancellation

A function shouldn't fire the instant a finger or mouse button goes down — it should wait for the up-event (release), or offer a way to abort or undo before it completes. That gives anyone whose pointer lands slightly wrong a chance to notice and slide away before anything actually happens.

  • Blind
  • Low vision
  • Cognitive
  • Motor
The problem, in practice — select the image to enlarge it
A shopping cart interaction compared with actions firing on pointer-down versus pointer-up with cancel support. 'Action fires on pointer down' shows a pressed 'Add to cart' button that immediately adds a pair of sneakers to the cart the instant it's pressed, with a note that the item can't be undone. 'Action occurs on release or can be canceled' shows the same button only adding the item once the pointer is released (labeled 'Pressed (down)' then 'Released (up)'), alongside a second pattern showing a 'Delete item?' confirmation with Delete/Cancel buttons and a pending action with a 5-second Undo option. Paired examples below contrast immediate activation on a navigation link, drag-to-reorder, freehand drawing, and a 'Pay now' button against versions that activate on release, allow canceling, confirm on release, or offer a 10-second undo.

How to recognize it

Press down on a button or touch target and, without lifting, slide off it before releasing — does the action fire anyway? A common failure binds the interaction to touchstart or mousedown instead of touchend/click/mouseup, so it activates the instant contact is made, with no chance to reconsider or correct a mis-tap. This is especially disruptive for motor impairments, where a finger commonly lands near a target and then slides onto it — with down-event activation, whatever's under the initial landing point fires first, before the intended target is even reached. The exceptions are narrow and specific: things meant to emulate a real physical key press (a virtual piano key, a game's fire button) or activities where precise timing is the entire point (a rhythm game, skeet shooting) are allowed to fire on down-event, since reversing that would fundamentally change what the interaction is.

How to fix it

Bind actions to the up-event (click, touchend, mouseup) rather than the down-event, so a user can press, see or feel where their pointer landed, and slide away to cancel before anything happens. Where down-event activation is genuinely unavoidable, provide an explicit way to abort (releasing outside the target cancels the action) or an immediate undo. Native HTML buttons and links already behave correctly by default — click fires on release, not on press — so this failure almost always comes from custom touch or gesture-handling code that explicitly listens for the down-event instead of using the platform default.

Example

Avoid

<div class="btn" ontouchstart="submitOrder()">Place order</div>
element.addEventListener('mousedown', deleteItem);

Prefer

<button onclick="submitOrder()">Place order</button>
element.addEventListener('click', deleteItem);

Resources