2.5.2 Pointer Cancellation

Level A
Operable
Since WCAG 2.1

Summary

This criterion protects people who press the wrong thing. Users with tremors, limited dexterity, or unsteady aim frequently land a finger or pointer on a control they did not intend to activate. If activation happens on the up-event, they have a way out: keep the pointer down, slide off the control, release, and nothing happens. If the control fires the moment the pointer goes down, that escape route is gone and every mis-tap becomes an executed action.

The auditor's mental model is simple: up-event completion is the default behaviour on every platform. Native buttons, links, and standard controls all activate on release, so they pass automatically. Failures are almost always custom-built: a control wired to fire on the down side of the interaction, or a long-press action that executes while the pointer is still down. Grade against the four options in the official text; a control needs only one of them, and for the vast majority of controls the one that applies is straightforward up-event completion with slide-off abort.

Official wording

For functionality that can be operated using a single pointer, at least one of the following is true:
No Down-Event: The down-event of the pointer is not used to execute any part of the function;
Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
Up Reversal: The up-event reverses any outcome of the preceding down-event;
Essential: Completing the function on the down-event is essential.

Success Criterion 2.5.2 Pointer Cancellation, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 5 October 2023 (updated 12 December 2024). Copyright © 2023-2024 World Wide Web Consortium. https://www.w3.org/copyright/document-license-2023/. Reproduced unmodified under the W3C Document License.

EN 301 549 mapping

Web pages: Clause 9.2.5.2
Software and native apps: Clause 11.2.5.2 (via Table 11.9)

Clause 9.2.5.2 applies this criterion to web pages unchanged. For software, clause 11.2.5.2 carries the requirement through a word-substitution table (Table 11.9) that restates it for application user interfaces.

Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.

In practice

Web

Start with the code. In browser developer tools, inspect suspect interactive elements and check which events their handlers are attached to (the event listeners panel shows this per element). Handlers on click are safe: click fires after the up-event and is cancelled by sliding off. The red flags are functional handlers on mousedown, touchstart, or pointerdown that do more than visual feedback. Pressed-state styling on the down-event is fine (that is not "executing the function"); submitting a form, opening a menu, deleting an item, or firing navigation on the down-event is not.

Then run the behavioural check, which is the universal auditor procedure for this criterion: press down on the control, slide the pointer off it while still held down, release outside the control, and confirm nothing fired. Repeat with touch on a mobile viewport or real device, because touch and mouse handlers are often wired separately. Concentrate on custom widgets: JavaScript-built buttons, drag handles, custom dropdowns, canvas-based interfaces, and anything with "fast tap" style optimisations that listen to touchstart to shave perceived latency.

Watch for long-press behaviour implemented with a touchstart timer: if the action executes while the finger is still down, the down side of the interaction executed the function and there is no release to cancel, which fails unless a genuine abort or undo mechanism exists.

iOS

The European standard carries this requirement through to software, restating it for application user interfaces, so native iOS screens are graded against the same four options.

The platform split is touchDown versus touchUpInside. Standard UIButton targets wired to .touchUpInside (and SwiftUI's standard tap handling) complete on release and support slide-off cancellation natively: press a system button, drag your finger off, release, nothing happens. A custom control whose action is attached to .touchDown, or a gesture recogniser that fires its handler on the began state, executes on the down side and fails the slide-off test. In an audit, run the slide-off test on device against every custom control; where you have the project, search target-action wiring and gesture recogniser state handling for down-side execution.

Also check long-press context actions: system context menus preview on the press and commit on selection, which is fine, but a custom long-press that performs a destructive action while the finger is still down needs an abort or undo to pass.

Android

As on iOS, the European standard applies this criterion to application software, so Android apps are graded the same way.

The platform split is onTouch versus onClick. The standard onClick listener fires on release and Android cancels it when the finger slides outside the view's bounds, so conventional buttons and clickable views (and Compose clickable modifiers) pass automatically. The failure pattern is an OnTouchListener that executes functionality inside ACTION_DOWN: the action runs the instant the finger lands, and sliding off changes nothing. Run the slide-off test on device against every custom control; in code review, treat any functional work inside ACTION_DOWN (beyond pressed-state visuals or starting a drag that ACTION_UP completes) as a finding.

Long-press is usually safe when built on the platform's OnLongClickListener, but verify what the long-press does: an action that executes mid-press with no way to abort before release, and no undo afterwards, fails.

Pass and fail examples

Passes:

Any native button, link, or standard platform control: activation on the up-event with slide-off cancellation is built in.
A custom web button whose only handler is on click, with mousedown used solely to apply a pressed visual state.
A delete action that completes on release but shows an "Undo" option immediately afterwards: abort or undo satisfied even though the deletion is instant.
An on-screen piano keyboard that sounds a note on the down-event and stops it on release: the up-event reverses the outcome of the down-event (and down-event timing is essential to playing an instrument).
A shooting control in an action game that fires on press: completing on the down-event is essential to the gameplay mechanic.

Fails:

A custom toolbar button wired to pointerdown or touchstart that opens a panel the instant the pointer lands: slide-off does nothing, no abort, no undo.
An iOS custom control whose action is attached to .touchDown: press, slide off, release, and the action has already run.
An Android view whose OnTouchListener submits a form inside ACTION_DOWN.
A long-press "delete item" gesture that removes the item while the finger is still down, with no confirmation step and no undo.

Not a fail under this criterion:

A mis-tap caused by two controls being tiny and crowded together: that is a target size finding under Target Size (Minimum). This criterion is the recovery mechanism; 2.5.8 is the prevention.
A control that requires a two-finger pinch or a drawn path with no simple alternative: gesture complexity belongs to Pointer Gestures.
Dragging that has no click or tap alternative: file under Dragging Movements. Note that a legitimate drag starts on the down-event by nature; the drag itself is not a 2.5.2 failure as long as the operation completes or commits on release.
Keyboard behaviour of any kind: this criterion is scoped to single-pointer operation.

Commonly confused with

Pointer Gestures, SC 2.5.1. 2.5.1 asks whether the gesture is too complex (multipoint or path-based) and demands a single-pointer alternative; 2.5.2 asks when a single-pointer action commits. A plain tap can pass 2.5.1 and still fail 2.5.2 if it fires on the down-event.
Dragging Movements, SC 2.5.7. 2.5.7 requires a single-pointer, non-dragging alternative to drag operations. 2.5.2 governs the drag's commit timing: pressing down to pick something up is fine, provided release completes (or cancels) the operation. The same drag handle can raise findings under both.
Target Size (Minimum), SC 2.5.8. Undersized targets cause mis-taps; pointer cancellation determines whether a mis-tap can be escaped. Prevention files under 2.5.8, recovery under 2.5.2. A cramped control that fires on touchstart earns both findings separately.
SC 3.3.4 Error Prevention (Legal, Financial, Data). Confirmation and undo for consequential submissions is a 3.3.4 question about the transaction. 2.5.2's abort-or-undo option is about the pointer interaction itself; do not use a checkout confirmation page to excuse a button that fires on the down-event elsewhere.

How AUDITSU tests this

AUDITSU's audit walkthrough covers pointer cancellation on every screen with interactive elements. The per-screen questions direct you to identify custom controls (anything that is not a plainly native button or link), run the slide-off test on each (press, slide off, release, confirm nothing fired), and check any long-press actions for down-side execution. Where a control does complete work early, the walkthrough prompts you to look for a qualifying abort or undo mechanism, or a genuine essential case, before grading. Each question records a pass, fail, or not applicable result per screen with evidence attached, so the finding lands in your report tied to the exact screen and control.

For the full guided workflow, see the audit platform.