Precise-path gestures are nearly impossible under tremor or limited motor control

What it is

A gesture that must draw a recognizer-accepted shape—a swipe far and straight enough, a letter, a drag along a narrow rail to an endpoint—is nearly undoable under tremor or limited motor control. A large target can still catch a scattered landing. A path treats shape as the signal. Noise accumulates across samples, and the recognizer simply fails. That failure is native to a path constraint. Making the target a bit larger does not buy the same repair.

Why it happens

A tap is one spatial verdict: overlap between the landing cloud and a rectangle. A path is a continuous constraint: every sample must stay in a corridor that also looks like a template. Tremor injects error into each sample; the trail becomes a saw. The recognizer wants a smooth stroke. A saw does not look like “swipe right”; it looks like cancel or scribble. Limited range never reaches the minimum displacement, so the gesture is always short of breath.

Filtering and target growth help that one spatial verdict. They do not turn a polyline into the curve the recognizer wants, and they do not rewrite “must draw a shape” as “must hit a patch.” So on a UI where point targets are already hittable, path gestures can still lock a population out of a feature by themselves.

Studying it

Capture contact traces. Tremor or motor-limited groups versus controls, on the same path gestures (horizontal swipe, reverse stroke, drag a slider to the end). Score recognition success, deviation from the template, and mid-gesture cancels. Use real list and rail sizes, not a full-screen button.

Independent variables: path length, corridor width, recognizer tolerance, whether a pause is allowed. Dependent variables: recognition rate, RMS deviation, share interpreted as scroll or cancel.

A sine jitter on the pointer is a preview only. Tremor time patterns differ; one perturbation is not a clinic population.

Where it stops holding

A coarse, short, high-tolerance flick (turn the page) fails less often than drawing a letter or seating on a thin rail. Once switch or voice takes over, the path primitive is not used and the barrier moves. Painting the path on a huge region lowers failure and widens false triggers. Success of point-target filtering is not evidence that path gestures now work.

Applying it

• Do not put a required feature behind a precise trajectory; the same result must be reachable with a click, an explicit button, or system pointer assistance.
• If the gesture stays for people who can do it, widen tolerance, and do not map a jagged trail to the opposite action.
• Verify: ask someone with an unstable hand to perform the product’s path gestures ten times; score traces and recognizer output only. If controls almost always pass and the target user almost always fails, the path is not executable for that group—log that separately from whether an alternative is findable or fast.

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.4 The alternative must produce the same result, not a reduced approximation
• Nearby: A8.16.3 Compensation requires both input filtering and target enlargement · J3.05 Single Pointer Alternatives · A8.16 Pathological and Intention Tremor
• Search terms: path-based gesture · tremor · stroke recognition