F105: When Gestures Lock Out Pointer Users

A screen that requires you to trace a letter to undo an action isn't innovative design. For users who rely on simple pointer input — a single tap, a mouse click, a switch device — it's a wall.

WCAG 2.2 Failure F105 (opens in new window) documents exactly this pattern: functionality implemented through path-based gestures with no simple pointer alternative. The failure is straightforward to define, surprisingly common in production interfaces, and almost entirely avoidable.

The Failure

Success Criterion 2.5.1 Pointer Gestures (opens in new window) requires that any functionality using multipoint or path-based gestures can also be operated with a single pointer — a click, tap, or long press. F105 describes the specific case where developers have provided only a path-based gesture, leaving no alternative path for users who cannot execute that gesture.

The W3C document gives two concrete examples that are worth examining closely because they represent two different implementation contexts:

Example 1 — Custom gesture shortcut: A web application lets users draw a "Z" on screen to undo the last action. No other undo mechanism exists. The gesture is the only path.

Example 2 — Swipe-to-reveal controls: An item reveals one set of options when swiped left, a different set when swiped right. After a user opens the item with a single tap, one or more of those options remain unavailable through any other interaction.

Both patterns share the same structural problem: the path-based gesture is the only route to functionality. The fix isn't to remove the gesture — it's to ensure an equivalent single-pointer alternative exists alongside it.

In code, these failures often surface through specific event handlers. If you're auditing third-party content or an interface you didn't build, the W3C guidance points directly at touchstart and touchend event handlers as signals worth investigating:

// Pattern that may indicate F105 failure — path tracking with no alternative
document.addEventListener('touchstart', (e) => {
  startX = e.touches[0].clientX;
  startY = e.touches[0].clientY;
});
document.addEventListener('touchend', (e) => {
  // Complex path calculation — "Z" shape detection
  if (isZShape(pathPoints)) {
    undoLastAction(); // Only undo mechanism in the application
  }
});

// Corrected pattern — path gesture preserved, simple alternative added
document.addEventListener('touchstart', (e) => {
  startX = e.touches[0].clientX;
  startY = e.touches[0].clientY;
});
document.addEventListener('touchend', (e) => {
  if (isZShape(pathPoints)) {
    undoLastAction();
  }
});
// Single-pointer alternative — always present
document.getElementById('undo-btn').addEventListener('click', undoLastAction);

The gesture can stay. The button must also exist.

Why This Matters

The population affected by F105 failures is broader than many developers assume.

Users with motor disabilities — including those with tremors, limited hand mobility, or who use switch access devices — often cannot execute controlled directional paths across a screen. A "Z" gesture requires deliberate multi-directional movement. A left-then-right swipe discrimination requires consistent directional control. These aren't edge cases; they're fundamental barriers for a significant portion of the disability community.

The W3C's own guidance on this criterion makes the device context explicit: on many mobile and tablet devices, there is no keyboard available. This is why SC 2.5.1 exists separately from Success Criterion 2.1.1 Keyboard (opens in new window) — keyboard access alone doesn't solve the problem for pointer users on touchscreen-only devices. Both criteria need to be met, but they address different access gaps.

The swipe-to-reveal pattern is particularly worth flagging because it appears frequently in mobile-first design systems. When options are permanently hidden behind a directional swipe — and remain inaccessible after a tap opens the item — users who can't reliably swipe in a specific direction lose access to those features entirely. This isn't a degraded experience. It's functional exclusion.

Applying This in Practice

F105 failures are detectable through a combination of manual testing and targeted code review. Automated tools will not reliably catch these — the failure depends on whether an alternative exists, not just whether a gesture is present. This is precisely the kind of contextual gap that research on automated testing limitations consistently identifies: tools can flag event handlers, but they cannot determine whether equivalent functionality is available through another path.

For development teams, a practical review checklist looks like this:

In code review, any touchstart/touchend handler that computes path geometry should trigger an immediate question: what is the single-pointer alternative for this function? If the answer is "there isn't one," that's F105.

For swipe-to-reveal specifically, the fix often requires a design conversation, not just a code change. The options hidden behind a swipe need to be surfaced somewhere — a context menu, an expanded view, a visible action bar — that's reachable with a single tap. This is worth raising early in the design process rather than retrofitting after implementation.

The compliance framework challenges that many organizations face often push pointer gesture failures down the priority list. They're less visible than color contrast failures, less likely to be caught by automated scans, and easier to rationalize as "edge case" issues. That framing is wrong. For users who rely on simple pointer input as their primary access method, F105 failures aren't edge cases — they're the difference between using an application and being excluded from it.

CORS Perspective

From a balanced analytical lens, F105 sits at an interesting intersection of operational and community dimensions. The failure is operationally easy to prevent at the design stage and expensive to retrofit after launch — a pattern that post-settlement implementation data consistently confirms. The community impact is concentrated among users with motor disabilities and touchscreen-only device users, a population whose needs are systematically underrepresented in usability testing that defaults to keyboard-and-mouse scenarios. Strategically, organizations that treat SC 2.5.1 as a mobile-only concern miss that pointer gesture requirements apply across all interactive technologies — any interface with pointer-triggered controls falls within scope. The risk calculus is clear: catching this in design review costs almost nothing; catching it in litigation costs considerably more.