Cancelling accidental taps and the ADA

Accidental taps and why release matters

Anyone can put a finger down in the wrong place. People with tremor, limited dexterity or poor aim do it far more often. WCAG 2.1 success criterion 2.5.2 asks that, for functions operated with a single pointer, at least one of these is true:

• No down-event: the pointer-down event (mouse button pressed, finger touching) does not run any part of the function.
• Abort or undo: the function completes on the up-event (release), and the user can abort before completing or undo afterwards.
• Up reversal: the up-event reverses anything the down-event did.
• Essential: finishing on the down-event is essential, as with an on-screen piano key. Emulating a keyboard or keypad press counts as essential.

The most dependable route is the first: let the function run on release, as native click and button activation already do. The user can slide the pointer off the target before letting go and nothing happens.

The ADA angle: payments, filings and deletions

The riskiest controls on a government site are the ones that cannot be taken back: Pay now on a utility bill page, Submit on a court e-filing, Cancel reservation on a county clinic booking. When these fire on touch-down, a missed tap becomes a real transaction. The Title II rule applies WCAG 2.1 to web content and mobile apps a public entity provides, so the way a button reacts to a press is part of what gets tested. Related: common barriers.

Web examples: pay, filing, drag-and-drop, delete

Utility bill payment button

<div role="button" tabindex="0" onpointerdown="payBill()">
  Pay $84.20
</div>

<button type="button" id="pay-bill">Pay $84.20</button>
<script>
  document.getElementById("pay-bill")
    .addEventListener("click", payBill);   // runs on release
</script>

Court e-filing submit with pointerdown

submitFiling.addEventListener("pointerdown", () => {
  sendFiling(caseNumber);
});

submitFiling.addEventListener("click", () => {
  sendFiling(caseNumber);
});

Drag a school to a preference list

document.addEventListener("pointerup", e => {
  dropChoice(e.target);     // always commits where released
});

let dragging = false;
document.addEventListener("keydown", e => {
  if (e.key === "Escape" && dragging) { cancelDrag(); dragging = false; }
});
document.addEventListener("pointerup", e => {
  if (!dragging) return;
  if (!isValidDropZone(e.target)) { cancelDrag(); return; } // released outside: abort
  dropChoice(e.target);
  showUndo("Moved to choice 2", undoLastMove);              // and offer undo
  dragging = false;
});

Mobile examples: SwiftUI and Jetpack Compose

A SwiftUI Button and a Compose clickable or Button already activate on release inside the control. Problems appear when developers build their own touch handling.

// SwiftUI
Text("Pay $84.20")
  .gesture(DragGesture(minimumDistance: 0)
    .onChanged { _ in payBill() })   // fires on first touch

// SwiftUI
Button("Pay $84.20") {
  payBill()                          // fires on release inside
}

// Jetpack Compose
Box(Modifier.pointerInput(Unit) {
  detectTapGestures(onPress = { payBill() })   // fires on press
}) { Text("Pay $84.20") }

// Jetpack Compose
Button(onClick = { payBill() }) {          // fires on release
  Text("Pay $84.20")
}

Manual checks first, then tools

1. Press and hold each control and look at what happens before you release. If something already happened (a page changed, a payment started, an item was deleted), it is a down-event action.
2. Press, slide off the control, and release. The action should not run.
3. Try dragging an item, then press Escape or release outside the target. It should snap back or ask.
4. Search the code for mousedown, touchstart, pointerdown and onPress handlers that call business functions. Each hit needs a reason.
5. Automated checkers rarely test this. Plan a manual pass on the five or six highest-risk controls.

Typical errors

• Using mousedown or pointerdown to feel snappier.
• Offering undo only for some actions: if one control commits on release without a way back, check it against the other options on this page.
• Treating the confirmation dialog as the whole answer; the dialog button itself can also fire on touch-down.
• Marking a function essential when it is only faster. Typing on a custom on-screen keypad is one example of a genuine exception; a Pay button is not.

Ship it when

• Buttons and links run on release (native click or equivalent).
• Drag-and-drop can be cancelled, or the result can be undone.
• Any remaining down-event action is documented as essential.

Sources

• Understanding SC 2.5.2: Pointer Cancellation (W3C), opens in a new tab
• 28 CFR Part 35, Subpart H: Accessibility of Web Information and Services (eCFR), opens in a new tab

Standard version: WCAG 2.1 (W3C Recommendation, 5 June 2018), as named in the Title II web rule. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official ADA statute and regulations, and ask a lawyer how they apply to you.