Skip to content

Technique F101:Failure of Success Criterion 2.5.2 due to activating a control on the down-event

About this Technique

This technique relates to 2.5.2: Pointer Cancellation (Failure).

This failure applies to all technologies that include interactive controls that can be triggered using a pointer.


The objective of this Failure is to describe situations where:

  1. Controls are set to activate functionality on the down-event of a pointer;
  2. No further mechanism to abort or undo is available;
  3. The up-event does not reverse the outcome of the activation;
  4. It is not essential for the functionality to execute and complete on the down-event.

Rather than taking advantage of the click event, authors may use down-events such as mousedown, touchstart or pointerdown. As a result, functionality will be executed as soon as a mouse button is pressed (but not released yet), or a finger or stylus makes contact with a touchscreen.

It is possible to use the down event and mitigate potential issues to avoid failing the Success Criterion. For example, provide a method to easily undo or abort the functionality, or reverse the outcome on the up-event (when the mouse button is released, or when the finger or stylus are lifted from the touchscreen). And note that some uses of the down-event are essential for the functionality (e.g., where the control simulates the operation of a musical instrument like a set of piano keys, or when the control is used as an on-screen control for a game where a fast and immediate response is required), in which case they would not fail this Success Criterion.


The test procedure outlined below could be supplemented with automated or semi-automated tests to scan for JavaScript that registers event listeners such as mousedown, touchstart, or pointerdown. The automated test would not be sufficient to make a pass/fail determination, but it can help narrow down the number of potentially problematic controls.


Example 1: A close button that triggers on down-events

A modal dialog contains a lengthy form that a user needs to complete. The modal provides a simple "Close" control that closes the dialog and loses all information the user may already have entered in the form. However, instead of simply listening to the click event - which in most user agents is triggered on the up-event - the author decided to close the dialog on the down-event. This may lead to the user accidentally closing the dialog and losing all the data they entered into the form up to that point.

<!-- modal dialog with a form -->
<button id="close" type="button">Close</button>
const trigger = document.getElementById("close");

function closeDialog() {
  /* close the modal dialog */

trigger.addEventListener('mousedown', closeDialog);
trigger.addEventListener('touchstart', closeDialog);
trigger.addEventListener('pointerdown', closeDialog);



Open the content on a device with pointer inputs (mouse, touchscreen, stylus) and for all available controls (buttons, links, complex widgets):

  1. Trigger down-events (e.g. by pressing but not releasing the mouse button, or placing a finger or stylus on the touchscreen) and check if functionality is executed prior to the up-event (e.g. releasing the mouse button or lifting the finger/stylus)
  2. If functionality was executed on the down-event, check if triggering the up-event (releasing the pressed mouse button, or lifting the finger or stylus from the touchscreen) reverses the outcome
  3. Evaluate if it could be deemed essential for the controls to execute and complete functionality on the down-event

Expected Results

  • If #1 is true, and #2 and #3 are false then the content fails the Success Criterion.
Back to Top