The alternative must produce the same result, not a reduced approximation

What it is

If the button can only “mark read” while the gesture “archives and closes the thread,” or pinch zooms continuously while buttons jump three steps, the stand-in is a reduced approximation, not another road to the same feature. Accessibility asks whether the result set is the same: can someone who cannot follow the path still reach the state the gesture user gets. One missing end state, and the path remains the only way there.

Why it happens

Products treat gestures as shortcuts and buttons as “good enough.” Once the shortcut carries unique parameters—archive not read, arbitrary rotation not ninety-degree steps, free crop not preset ratios—the simplified control does not cover that dimension. People who cannot motor the path are also dropped a dimension in feature space.

Equivalence is capability, not UI isomorphism. A gesture is a continuous trail; the stand-in may be discrete, if every parameter can still be specified: an angle field, crop handles or numbers, a slider for a curve. What must not be missing is the parameter, not “it still has to be a line.”

Studying it

List end states and parameters the path gesture can reach (action type, ranges, batching). List what the visible alternative can reach. The set difference is the reduction. Then have people who cannot gesture use only the alternative, and watch those difference tasks fail.

Independent variables: whether the alternative exposes the full parameter set, or only “common” presets. Dependent variables: end-state coverage, completion on the difference set, whether users recruit someone else to swipe.

Do not take “gesture users feel the button is fine” as evidence. They were never forced into the difference set.

Where it stops holding

If the gesture only accelerates the same command (swipe = the same toolbar Archive, byte-identical end state), reduction does not apply; what remains is findability and time. If a platform limit temporarily omits an expert parameter, say so in the UI; do not pretend parity. File pickers and move-up/move-down for lists are a different alternative class; do not accept them as coverage of path-shape result sets.

Applying it

• Make a table: every dimension the gesture can change, a button, field, or picker can change across the same range—not only a “quick” preset.
• If the gesture packs a compound result (archive and next, crop and export), the alternative must reach that compound in one act or two explicit steps, not half of it.
• Verify: disable path gestures and complete every treatment the product claims. Any end state that exists only by gesture is a reduction—log it apart from menu depth or a few extra seconds.

Related

• Same group: J3.11.1 A path-gesture alternative must be as findable as the gesture itself, not buried in a menu · J3.11.2 If the alternative takes much longer than the gesture, it is not a working alternative · J3.11.3 Precise-path gestures are nearly impossible under tremor or limited motor control
• Nearby: J3.05 Single Pointer Alternatives · J3.07 Drag Alternatives
• Search terms: equivalent outcome · pointer gesture alternative · feature parity