What it asks for, in plain English
Pressing a button has two halves: the pointer goes down, and the pointer comes up. Actions should happen on the up half, so that someone who presses the wrong thing can slide their finger or pointer off it before letting go and nothing happens. That is how native buttons already behave.
If an action does fire on the down half, there must be a way to abort or undo it, or the up half must reverse it (as with a button that previews on press and only commits on release). The only exception is when down-event behaviour is essential, such as a piano key that sounds the moment it is touched.
Custom components that listen to mousedown, touchstart or pointerdown to feel faster are the usual failures.
This is an independent explanation. The binding wording is the W3C Recommendation, and the W3C's own Understanding 2.5.2 page has the full intent, techniques and definitions.
Who it affects
Someone with a tremor or poor fine motor control often touches the wrong control first and relies on sliding away to cancel.
A person with low vision presses a control to feel where it is, then moves off it, and does not expect the action to have already happened.
Anyone on a bumpy bus mis-taps constantly and needs the same forgiveness.
How to check it
- Press and hold on each button or control with the mouse, then move the pointer off it before releasing. Nothing should happen.
- Do the same on a touch device: touch, slide your finger off, lift.
- For anything that does act on press, look for an undo or a confirmation step.
- Search custom component code for mousedown, touchstart and pointerdown handlers that trigger actions.
What Websight checks for 2.5.2
Websight has no automated check for this criterion. It lists it in the manual checklist that comes with every report, so it is not forgotten.
Only a person can check this. A scanner cannot press and slide, and cannot tell which event a script listens for.
Practical tips
- Use the click event, which fires on release and is cancelled by moving away, for everything.
- If a drag-and-drop or custom gesture needs pointerdown, only use it to start tracking, and commit on pointerup.
- Give destructive actions a confirmation or an undo regardless.
Other criteria in guideline 2.5, Input Modalities
- 2.5.1 Pointer Gestures (level A)
- 2.5.3 Label in Name (level A)
- 2.5.4 Motion Actuation (level A)
- 2.5.7 Dragging Movements (level AA)
- 2.5.8 Target Size (Minimum) (level AA)