Do not require swipes without a single-tap alternative
A function can be reached only by tracing a path with a finger. Swipe the row, pinch the map, draw a Z to undo. F105 is the failure technique for that, and a match is a defect rather than a gesture worth defending. The rule covers two kinds of gesture and most write-ups mention only one. Path-based gestures, where the route your finger takes is part of the instruction, and multipoint gestures like a pinch or a two-finger rotate. Keyboard support does not settle it either, which is the misunderstanding that costs teams the most time. A keyboard route is good and it answers a different rule, because the people this one protects are pointer users on devices with no keyboard attached. And swipe-to-reveal is not automatically a failure. It fails when an option behind the swipe cannot be reached any other way.
How we find it in an audit
We drive every interaction with taps and clicks alone. No swiping, no pinching, no dragging, and we note anything that becomes unreachable. Where a gesture exists, the question is whether the same function has a control a person could press instead. A source scan for touchstart and touchend narrows the hunt, which matters on a long page. Sliders get their own check, since the documented answer there is letting a tap on the track move the handle rather than insisting on a drag.
How affected users experience it
A screen-reader user on a phone has most gestures claimed by the screen reader itself, so a swipe across your list moves the reading cursor and never reaches your handler. The gesture your interface is waiting for simply does not arrive. Switch users and people using head or eye control have a plainer problem, because their input is a series of discrete presses and a traced path is not something they can produce at all. Both groups need the same thing, which is a control they can hit.
Passes vs. fails
Passes
<button>Previous slide</button> <button>Next slide</button>
<!-- alongside the swipe handling, not instead of it -->Fails
carousel.addEventListener("touchmove", trackSwipe); // swiping is the only controlThe other techniques filed under this rule
3 guides on this site are filed under 2.5.1 Pointer Gestures. W3C documents this one as a failure of that rule, so it describes a way the rule gets broken rather than a way to pass it.
This guide is our interpretation of W3C technique F105: Failure of Success Criterion 2.5.1 due to providing functionality via a path-based gesture without simple pointer alternative. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.