Pointer Cancellation and Target Size

Pointer cancellation (WCAG 2.1 Success Criterion 2.5.2, Level A) and target size (WCAG 2.2 Success Criterion 2.5.8, Level AA, with 2.5.5 at Level AAA) address different but complementary problems for users who have difficulty controlling a mouse, stylus, or touch input. Pointer cancellation ensures that users can abort or undo an accidental activation. Target size ensures that interactive elements are large enough to be tapped or clicked without accidentally hitting a neighboring control.

These two criteria often appear together in accessibility audits because they both deal with the physical act of pointing at something on screen. A button that is too small increases the chance of mis-taps; a click handler that fires on mousedown instead of mouseup removes the user's ability to drag away and cancel the action. Addressing both issues at the same time produces a more forgiving interface for everyone, not just users with motor disabilities.

Why pointer cancellation and target size matter

People with tremors, limited fine motor control, or those using assistive pointing devices frequently land on the wrong target or press down before they intend to. If a destructive action fires the instant a pointer touches a control, the user has no way to recover. Similarly, if a delete button is 16 × 16 pixels and sits right next to a save button of the same size, even users without disabilities will occasionally hit the wrong one.

Screen magnification users face compounded problems. When the viewport is zoomed to 200% or more, small targets become harder to distinguish and hit, and accidental activation becomes more likely. Mobile users on small screens encounter similar friction.

Failing to meet these criteria results in frustrated users, increased error rates, and potential WCAG non-compliance at the A and AA levels.

How pointer cancellation works

WCAG 2.5.2 requires that for any single-pointer interaction, at least one of the following is true:

• The down-event alone does not trigger the function.
• The function completes on the up-event, and there is a mechanism to abort or undo it before completion.
• The up-event reverses the outcome of the down-event.
• Completing the function on the down-event is essential (e.g., a piano key simulator).

In practice, this means relying on click events (which fire on pointer release) rather than mousedown or pointerdown. Native HTML <button> and <a> elements already satisfy this requirement because the browser fires the click event on release. The most common violation is JavaScript code that binds logic to mousedown, touchstart, or pointerdown without providing a way to cancel.

Up-event completion and abort patterns

A drag-and-drop interface is a good example. The user presses down on an item (pointerdown), drags it, and releases (pointerup) over a drop zone. If the user drags the item away from any valid drop zone and releases, nothing happens. This satisfies the abort requirement.

For actions like deleting a record, a confirmation dialog shown after the click gives the user a chance to reverse the action, meeting the undo provision.

How target size works

WCAG 2.5.8 (Level AA) requires that targets have a size of at least 24 × 24 CSS pixels, unless the target is inline within a sentence, the user agent controls the size (e.g., a default checkbox), or a larger alternative target for the same function exists on the page. The stricter Level AAA criterion (2.5.5) requires at least 44 × 44 CSS pixels.

The measurement includes padding inside the clickable region. A 16 × 16 icon inside a <button> with enough padding to bring the overall tap area to 24 × 24 pixels satisfies the AA requirement.

Spacing also counts. If two 20 × 20 targets are separated by enough offset so that a 24-pixel-diameter circle centered on either target does not overlap the other, the criterion is met. The specification defines this as the "target offset" rule.

Code examples

Bad: action fires on pointer down, no cancel mechanism

<button id="delete-btn" class="small-btn">Delete</button>

<style>
  .small-btn {
    width: 18px;
    height: 18px;
    padding: 0;
    font-size: 10px;
  }
</style>

<script>
  document.getElementById("delete-btn").addEventListener("pointerdown", function () {
    // Fires immediately on press — user cannot cancel
    fetch("/api/items/42", { method: "DELETE" });
  });
</script>

This example has two problems. The delete action fires on pointerdown, giving the user no chance to abort. The button is also only 18 × 18 pixels, below both the AA and AAA target size thresholds.

Good: action fires on click, adequate target size

<button id="delete-btn" class="action-btn" type="button">
  Delete
</button>

<div id="confirm-dialog" hidden>
  <p>Are you sure you want to delete this item?</p>
  <button id="confirm-yes" class="action-btn" type="button">Yes, delete</button>
  <button id="confirm-no" class="action-btn" type="button">Cancel</button>
</div>

<style>
  .action-btn {
    min-width: 44px;
    min-height: 44px;
    padding: 8px 16px;
    font-size: 14px;
    cursor: pointer;
  }
</style>

<script>
  document.getElementById("delete-btn").addEventListener("click", function () {
    document.getElementById("confirm-dialog").hidden = false;
  });

  document.getElementById("confirm-yes").addEventListener("click", function () {
    fetch("/api/items/42", { method: "DELETE" });
    document.getElementById("confirm-dialog").hidden = true;
  });

  document.getElementById("confirm-no").addEventListener("click", function () {
    document.getElementById("confirm-dialog").hidden = true;
  });
</script>

Here the delete action uses a click event, which fires on pointer release. A confirmation dialog lets the user cancel before the destructive request is sent. Each button meets the 44 × 44 pixel AAA target size thanks to min-width, min-height, and padding.

Bad: inline icon buttons with no spacing

<span class="icon-btn" onclick="edit()">&#9998;</span>
<span class="icon-btn" onclick="remove()">&#10005;</span>

<style>
  .icon-btn {
    font-size: 12px;
    cursor: pointer;
  }
</style>

These <span> elements are not focusable by keyboard, lack accessible names, and have no defined tap area. They are packed together with no spacing.

Good: icon buttons with accessible markup and spacing

<button type="button" class="icon-btn" aria-label="Edit item" onclick="edit()">
  &#9998;
</button>
<button type="button" class="icon-btn" aria-label="Remove item" onclick="remove()">
  &#10005;
</button>

<style>
  .icon-btn {
    min-width: 44px;
    min-height: 44px;
    margin-right: 8px;
    font-size: 18px;
    border: 1px solid #767676;
    background: #fff;
    cursor: pointer;
  }
</style>

Each button is a native <button>, keyboard accessible by default. The aria-label provides an accessible name. The 44 × 44 pixel minimum size and 8-pixel margin between buttons satisfy both pointer cancellation (native click behavior) and target size requirements.