F101: When the Click Fires Too Early

There's a moment every driver knows — you start to turn into a parking space, realize it's too tight, and pull back before you've committed. The steering wheel responds because you haven't finished the motion yet. You still have a way out.

Pointer events work the same way. The down-event is the turn of the wheel. The up-event is the commitment. WCAG 2.2 Failure F101 (opens in new window) documents what happens when developers remove that recovery window — when they fire the action the moment a user touches a button, before the finger lifts, before the mouse button releases, before the user has had any chance to reconsider.

The result isn't a minor UX inconvenience. For users with motor disabilities, tremors, or low dexterity, it's a consistent source of unrecoverable errors.

The Failure

F101 (opens in new window) is a documented failure of Success Criterion 2.5.2: Pointer Cancellation (opens in new window), which lives under WCAG 2.2's Guideline 2.5 (Input Modalities). The criterion requires that functionality triggered by a single pointer meets at least one of four conditions: it doesn't trigger on the down-event, it can be aborted or undone, the up-event reverses the down-event action, or triggering on the down-event is essential.

F101 captures the failure mode where none of those conditions are met. The control fires on mousedown, touchstart, or pointerdown — and there's no abort, no undo, no reversal.

The W3C's own example is clarifying in its specificity:

<!-- 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);

A user fills out a long form inside a modal. Their hand trembles slightly — a common reality for people with Parkinson's, essential tremor, or spasticity. Their finger grazes the Close button. Before they can lift it, the dialog is gone. The form data is gone. There was no warning, no confirmation, no recovery path.

The developer chose mousedown over click. That single decision removed the user's ability to course-correct.

Why This Matters

The standard browser click event fires on the up-event — when the mouse button releases or the finger lifts. This isn't arbitrary. It's a deliberate design choice that preserves a cancellation window: press down, realize you're on the wrong target, slide your pointer away, release. No action taken.

When developers bypass click in favor of down-events, they eliminate that window entirely. The W3C's description of F101 is direct: "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."

For users without motor disabilities, this might register as a slightly snappier interface. For users with tremors, spasticity, or reduced fine motor control, it transforms interactive controls into traps. The very users who most need recovery time — who may be using adaptive hardware, switch controls, or touch devices with imprecise input — get the least of it.

This also affects users on mobile touchscreens navigating with assistive technology. A touchstart listener fires before the user's gesture intent is fully established. It fires before a screen reader user has confirmed their selection.

The human cost of F101 isn't theoretical. It's the data entered and lost, the transaction abandoned, the service inaccessible — repeated, across every visit.

The Fix

The corrected pattern is straightforward. Use click instead of down-events for standard interactive controls:

// WRONG — fires on down-event, no recovery window
trigger.addEventListener('mousedown', closeDialog);
trigger.addEventListener('touchstart', closeDialog);
trigger.addEventListener('pointerdown', closeDialog);
// CORRECT — fires on up-event, preserves cancellation window
trigger.addEventListener('click', closeDialog);

If down-event behavior is retained for a specific reason, SC 2.5.2 (opens in new window) permits it under three conditions:

1. Abort/undo: Provide a mechanism to cancel the action before it completes, or reverse it afterward (a confirmation dialog, an undo option).
2. Up-event reversal: The up-event reverses whatever the down-event triggered.
3. Essential: The down-event is genuinely required for the functionality — a piano key simulation, a real-time game control. The W3C is explicit that this exception is narrow.

For the modal form example, the fix is either switching to click, or adding a confirmation step before the destructive action executes. Both preserve user agency.

Applying This

Automated testing can detect the presence of mousedown, touchstart, and pointerdown event listeners — but as the W3C notes in F101's own documentation, "the automated test would not be sufficient to make a pass/fail determination." Detection narrows the field; human judgment closes it. This is exactly the dynamic our research on testing methodology describes: automated tools surface candidates, manual review determines whether the essential-use exception applies.

Practical steps for development teams:

• Code review checklist: Flag any mousedown, touchstart, or pointerdown listener on an interactive control. Require justification for why click wasn't used.
• Linting rules: ESLint plugins can be configured to warn on down-event listeners attached to button or anchor elements.
• Manual test protocol: For any flagged control, test whether sliding the pointer away before releasing prevents the action. If the action already fired, you have F101.
• Destructive actions get extra scrutiny: Close buttons, delete controls, submit actions — these warrant confirmation dialogs regardless of which event triggers them.

The essential-use exception requires documentation. If a team claims down-event behavior is essential, that claim should be recorded in the accessibility conformance record, not just assumed.

CORS Perspective

Through a Risk/Legal Priority lens, F101 sits at an interesting intersection: it's a WCAG 2.2 criterion (not 2.1), which means it isn't yet universally required under every legal framework — but the trajectory of DOJ digital accessibility enforcement (opens in new window) is clearly toward WCAG 2.1 AA as a floor, not a ceiling. Organizations that treat 2.5.2 as optional today may find it cited in complaints tomorrow. More immediately, the community impact is concrete: motor-disability users face real, recurring data loss from this pattern. Strategically, the fix costs almost nothing — swapping mousedown for click is a one-line change — which means the operational capacity argument for remediation is unusually strong. The compliance frameworks we examine in The Compliance Framework Paradox often create paralysis around complex, expensive fixes. F101 isn't one of them. The barrier to getting this right is low. The barrier to justifying inaction is getting higher.