On each web page, can actions triggered with a pointing device on a single point of the screen be cancelled (except in special cases)?
A user accidentally presses 'Delete account'. If your button reacts on press (pointerdown), the action executes before they release their finger. If it reacts on release (pointerup), the user can still move their cursor away from the target to cancel. A fraction of a second. All the difference.
For each action triggered by a pointer at a single point on the screen, at least one of these three conditions must be met: the action triggers on pointer release; the action triggers on press but is canceled on release; a mechanism exists to abandon (before completion) or cancel (after completion). The criterion gives you the choice of condition.
Drag-and-drop deserves special attention. Two levels are required: releasing the element outside the target zone must cancel the current operation; once the drop is complete, the user must be able to cancel it via a confirmation dialog or by repositioning the element to its original location.
Native elements (<button>, <a>, <input>) trigger their actions on the click event, which executes on release. Compliance provided by the browser. The problem arises from custom mousedown or pointerdown handlers that provide no cancellation.
Un test to ensure that the action on hover can be cancelled
Triggering on release or cancellation mechanism for pointer actions
- Identify all actions triggered by a pointing device at a single point on the screen: clicks, taps, single presses.
- For each action, verify that at least one of these conditions is met:
a. The action triggers on pointer release (event
click,pointerup,mouseuportouchend). b. The action triggers on press but is canceled on release. c. An abandonment or cancellation mechanism exists. For drag-and-drop: releasing outside the target zone cancels the operation; after drop, a confirmation dialog or the ability to replace the element to its original location is provided. - If each action meets at least one condition, the test is validated.
Examples
❌ Non-compliant : mousedown handler without cancellation mechanism
<button id="btn-delete">Delete file</button>
<script>
document.getElementById('btn-delete').addEventListener('mousedown', function () {
deleteFile(); // Executed on press: impossible to cancel before release
});
</script>The action triggers on button press. A user who presses by mistake cannot cancel by moving their cursor away from the target before releasing. The operation is irreversible from first contact.
✅ Compliant : click handler (trigger on release)
<button id="btn-delete">Delete file</button>
<script>
document.getElementById('btn-delete').addEventListener('click', function () {
// 'click' triggers on release: dragging the cursor away from the button before releasing cancels the action
deleteFile();
});
</script>The click event triggers on release. If the user presses by mistake, they can move their cursor away from the button before releasing to cancel. No additional JavaScript is needed.
✅ Compliant : Drag-and-drop with confirmation dialog on drop
<div id="drop-zone"
ondragover="event.preventDefault()"
ondrop="confirmDrop(event)">
Drop zone
</div>
<script>
function confirmDrop(event) {
event.preventDefault();
var file = event.dataTransfer.getData('text/plain');
if (confirm('Move this file to this folder?')) {
moveFile(file);
}
// If the user chooses Cancel, the file remains at its original position
}
</script>Two levels of cancellation are present: releasing the element outside the drop zone abandons the operation (native drag-and-drop behavior); if the element reaches the target zone, a confirmation dialog allows the user the option to decline.
Tips and pitfalls
⚠️ mousedown without cancellation: the most frequent audit error
The most common non-compliance case: a mousedown (or touchstart on mobile) handler triggers an action without any mechanism to cancel it before or after. Custom button-press, slider, and context menu components are the first suspects to check during an audit.
⚠️ Keyboard emulators and press-triggered features
Some features require by nature that the action triggers on press: a virtual keyboard emulator must behave like a physical keyboard, whose keys activate on contact. In these specific cases, criterion 13.11 does not apply. Document this choice in your accessibility statement with a functional justification.
💡 The click event is compliant without additional configuration
On native elements (<button>, <a>, <input>), the click event triggers on pointer release, automatically satisfying the first condition of the criterion. Non-compliance almost always stems from a deliberate choice to use mousedown or pointerdown without providing cancellation.
⚠️ Touch events: touchstart is the mobile equivalent of mousedown
On mobile, touchstart behaves like mousedown: the action triggers on initial contact, before release. If your interface handles touch and mouse events separately, check both. A component compliant on desktop may be non-compliant on mobile if touchstart triggers an action without cancellation possibility.
⚠️ Drag-and-drop: two distinct mechanisms are required
The RGAA distinguishes two moments in drag-and-drop: during dragging, releasing outside the target zone must cancel the operation; after drop, a cancellation mechanism must exist. Providing only one of the two is insufficient. Systematically test both scenarios during your audits.
Frequently asked questions
Why is the click event compliant by default with RGAA criterion 13.11?
Yes. The click event triggers on pointer release, after mouseup or pointerup. It satisfies the first condition of criterion 13.11 without additional configuration. This is why native HTML buttons and links are compliant by default.
How do you verify compliance with pointer cancellation during a RGAA audit?
Press a button or interactive control without releasing, move the cursor away from the element, then release. If the action executed on press, the test fails. On mobile, perform the same test with a finger. For drag-and-drop, test abandonment mid-operation and verify that cancellation is possible after drop.
When does an interaction triggered on mousedown remain compliant with RGAA pointer cancellation?
When sketch initiation on mousedown is functionally justified. This case is covered by the third condition: a cancellation mechanism must exist (Ctrl+Z, 'Undo' button, or pressing Escape to interrupt the current sketch). If the final action is cancellable, criterion 13.11 is met.
How do you design a drag-and-drop compliant with RGAA criterion 13.11 cancellation on pointer?
No, provided the user can replace the dropped element to its original location. The RGAA accepts two forms of post-drop cancellation: a confirmation dialog at drop time, or the ability to undo the operation through manual repositioning. If neither is available, the criterion is not met.
What multi-point gestures like pinch-to-zoom are covered by RGAA criterion 13.11?
None. Criterion 13.11 concerns only actions triggered at a single point on the screen. Gestures requiring multiple simultaneous points of contact fall under criterion 13.10, which addresses trajectory-based or complex gesture interactions.