WCAG 2.5.2: Pointer Cancellation

Who this helps

Touching a screen or pressing a mouse button is a two-part act: contact down, then release. Between those two moments is the only window a user has to change their mind. People with motor disabilities need that window far more often than others — and everyone needs it sometimes.

The stakes scale with the action. An accidental tooltip is a nuisance; an accidental “Delete”, “Send”, or “Buy now” on the down-event is data loss or money spent. For legal and financial transactions, 3.3.4 Error Prevention adds further protection on top of this criterion.

The four ways to conform

You only need to satisfy one of the four conditions for each pointer-operated function. In order of how often they apply in real interfaces:

1. 1

   No Down-Event (the default — use click)

   The down-event does not execute any part of the function. Native activation of <button>, <a>, and <input>, and the JavaScript click event, all fire on release. If you never attach behavior to mousedown, touchstart, or pointerdown, you conform automatically. This is the right answer for almost every control.

2. 2

   Abort or Undo

   The function completes on the up-event, and the user can either abort before completion (slide off the target before releasing, press Escape mid-drag) or undo afterwards (an Undo button or snackbar). This is the usual path for drag-and-drop and destructive actions.

3. 3

   Up Reversal

   The up-event reverses what the down-event started. Press-and-hold interactions work this way: pressing down on a thumbnail pops up a preview, releasing dismisses it. Nothing persists after release, so nothing needs cancelling.

4. 4

   Essential

   Completing on the down-event is essential to the function. On-screen piano keys must sound on press; on-screen keyboards must emulate physical key-down behavior (the W3C note explicitly treats keyboard emulation as essential). This exception is narrow — convenience or perceived snappiness does not qualify.

Pass and fail examples

Code examples

The core rule: click, not mousedown

The failing version executes on the down-event. The passing version uses click, which the browser only fires when press and release happen on the same element — cancellation built in.

// ✗ Fails: the down-event executes the function
deleteButton.addEventListener("mousedown", () => deleteItem(id));
deleteButton.addEventListener("touchstart", () => deleteItem(id));

// ✓ Passes: click fires on release, and releasing off-target cancels
deleteButton.addEventListener("click", () => deleteItem(id));

Custom pointer handling that preserves cancellation

If you must use pointer events (for a custom control), complete the action only on pointerup and only when the pointer is still over the target.

let pressedElement = null;

control.addEventListener("pointerdown", (e) => {
  // ✓ Down-event only records intent — it executes nothing
  pressedElement = e.currentTarget;
});

control.addEventListener("pointerup", (e) => {
  const stillOverTarget =
    pressedElement === e.currentTarget &&
    e.currentTarget.contains(document.elementFromPoint(e.clientX, e.clientY));

  // ✓ Releasing outside the control aborts the action
  if (stillOverTarget) activate();
  pressedElement = null;
});

control.addEventListener("pointercancel", () => {
  pressedElement = null; // scrolling or system gestures abort too
});

Drag-and-drop with abort and undo (React)

The down-event may begin a drag, because beginning is not completing. Provide an Escape abort during the drag and an undo after the drop.

function Board() {
  const [dragging, setDragging] = useState(null)
  const [lastMove, setLastMove] = useState(null)

  useEffect(() => {
    function onKeyDown(e) {
      // ✓ Abort: Escape cancels an in-progress drag
      if (e.key === "Escape" && dragging) setDragging(null)
    }
    window.addEventListener("keydown", onKeyDown)
    return () => window.removeEventListener("keydown", onKeyDown)
  }, [dragging])

  function handleDrop(card, toColumn) {
    setLastMove({ card, from: card.column, to: toColumn })
    moveCard(card, toColumn) // completion happens on the up-event (drop)
  }

  return (
    <>
      <Columns onDragStart={setDragging} onDrop={handleDrop} />
      {lastMove && (
        // ✓ Undo: the completed action can be reversed
        <button type="button" onClick={() => moveCard(lastMove.card, lastMove.from)}>
          Undo move
        </button>
      )}
    </>
  )
}

Common failures

• ✗Binding actions to mousedown, touchstart, or pointerdown to make the UI feel faster — every accidental press becomes an activation.
• ✗Custom components (in any framework) that activate in the down handler and provide no abort or undo mechanism.
• ✗Game-like or canvas interfaces where pressing anywhere immediately commits an action that cannot be reversed.
• ✗Drag-and-drop implementations with no way to abort mid-drag (no Escape handling, no safe drop-back) and no undo after the drop.
• ✗Press-and-hold controls where the down-event already performs a persistent action instead of a transient preview.
• ✗Third-party widget libraries that fire on the down-event by default — you own the failure if you ship it.
• ✗Claiming the essential exception for ordinary buttons or menus; essential covers keyboard emulators and instruments, not perceived snappiness.

How to test for 2.5.2

1. 1

   Press down and hold on every interactive element

   With a mouse or finger, press each button, link, and custom control and do not release. If anything happens while you are still holding — navigation, deletion, submission, a toggled state — the down-event is executing the function. Note it for step 4.

2. 2

   Press, slide off, and release

   Press down on the control, move the pointer off it, then release. Nothing should activate. This is the abort behavior that native click gives you for free; custom controls must replicate it.

3. 3

   Search the code for down-event handlers

   Grep for mousedown, touchstart, and pointerdown (and framework equivalents like onMouseDown, onTouchStart, onPointerDown). Each hit needs review: recording intent or starting a drag is fine; executing the function is not.

4. 4

   Check remaining down-event activations for an escape route

   For every function that does execute on the down-event, verify one of the other conditions: does the up-event reverse it (press-and-hold preview)? Is there an abort or undo? Is it genuinely essential (keyboard emulation, instrument)? If none apply, it fails.

5. 5

   Test drags for abort and undo

   Start a drag, then try to cancel: press Escape, or drop outside any valid target. The item should return to its origin. If a drop cannot be aborted, check for an undo mechanism after completion.

Automated scanners cannot tell what your event handlers do, so 2.5.2 is a manual and code-review test. Fold it into the full WCAG 2.2 checklist alongside the other input-modality criteria.

Frequently asked questions