Mid-Air Gesture Interaction Design Guidelines

For designers and engineers: let the system clearly judge what counts as input, let users know which state they are in right now, and keep recognition uncertainty from turning into irreversible consequences.

The fundamental difference between mid-air gestures and touch, mouse, or key input is not "how memorable the gesture is," but how input intent is judged:

Mouse and touch provide explicit events such as press, move, and release, but still require designing for cancellation and mis-operation handling. Mid-air gestures must additionally judge, from continuous motion, whether input has begun, whom it belongs to, and when it ends.

The sensor is always capturing, the user is always moving, and the system must continuously adjudicate "is this motion meant for me." This gives rise to two premises that run through the entire document: false triggering is a structural property of this modality, not a detail to be optimized away; tracking loss is a normal state, not an exception-handling branch. Any design that treats these two things as edge cases will fail in real environments.

These guidelines consist of seven principles and 39 rules: principles state the design direction, and rules specify applicable situations, behavior requirements, and verification methods. Each rule belongs to one and only one principle, and the rule number is the principle number (G4-2 is the second rule under the fourth principle).

Each matter is written in only one place. Take "tracking loss" as an example: what behavior the system takes when tracking is lost, how the user knows loss is occurring, and whether the loss makes an already-occurred change unable to be undone belong to three different rules (G5-1, G4-5, G6-2) — because their regulatory objects differ; they are not three phrasings of the same obligation.

What these guidelines constrain is the nature of the interaction commitments a product makes to users and the mechanisms that fulfill them; they do not presuppose a single sensing approach (optical, radar, ultrasonic, and wearable are all applicable), and do not specify a particular SDK or gesture-recognition algorithm. This is not a gesture dictionary and does not prescribe that "waving means next page"; for standardization of concrete gesture forms see the ISO/IEC 30113 series and ISO/IEC 14754. Adopting these guidelines cannot substitute for dedicated assessments of accessibility, privacy, in-vehicle distraction, and domain compliance.

Entry points for reading: configuration fields are in Design Token; use Appendix A during review.

The document has four chapters: Chapter 1 principles, Chapter 2 how to read and quick-reference the rules, Chapter 3 rules in detail, Chapter 4 terminology; the verification checklist and argumentation boundaries are in Appendices A and B, and external source cross-references are in reference.md in the same directory.

---

1. The Seven Principles¶

The seven principles divide design responsibility by regulatory object: each principle governs obligations on one category of object, and each rule belongs to the single principle matching the direct regulatory object of its obligation. When objects differ, principles cannot substitute for one another — this is both the basis for the division and the way to test it.

A single scenario can touch multiple principles — a user performing a delete gesture at the edge of the interaction zone simultaneously involves boundary perceivability (G4-5), handling under low confidence (G5-3), and the commit path for an irreversible action (G6-1) — this is not a classification error: the three rules constrain obligations on three different regulatory objects. Mutual exclusivity and exhaustiveness are claims this division accepts being tested against, not facts established by mere declaration: when a rule's addition, removal, or attribution is in doubt, verify it against the classification test in Appendix A; if the test fails, what gets revised is the division of principles.

Principles are used to understand the rules and adjudicate attribution; they are not, by themselves, a separate judgment item. When the interpretation of a principle conflicts with that of a specific clause, the applicable clause governs, and the ambiguity needing clarification is recorded.

2. How to Read the Rules¶

2.1 The Structure of Each Rule¶

Rules write the nature of the behavior, not the implementation approach: that a drag MUST NOT continue to advance once the hand leaves the field of view is a product behavior; whether to use a Kalman filter or simply freeze is an engineering approach — the two MUST correspond, but they are not the same deliverable.

2.2 Constraint Words¶

• MUST: not meeting it means not conforming to these guidelines. Without it, some commitment made to the user will fail under foreseeable conditions — this is the sole basis for marking something "MUST" (see Appendix B).
• MUST NOT (forbidden): the negative-strength counterpart of "MUST," at the same strength; in the body text, "MUST NOT" and "forbidden" are used interchangeably.
• SHOULD: followed by default; when there is genuine reason to deviate, record the reason and the alternative approach, and accept the same verification. Deviation does not require approval, but it does require a paper trail.

Compliance judgment takes the independent obligation clause in the body text as its unit: a declarative sentence with no constraint word carries the strength of its rule heading; an explicit constraint word takes precedence. "SHOULD NOT" is the negative-direction expression of "SHOULD." A "MUST / forbidden / MUST NOT" clause inside a [SHOULD] rule remains a hard constraint (G1-6, G2-5, G2-6, G3-4, G6-5, and G7-5 contain such clauses; among them, G2-6's practice isolation contains both a MUST-level and a forbidden-level clause), and the strength annotation on a rule heading or in the quick-reference table does not replace clause-level binding force.

Strength indicates binding force, not importance: "MUST" decides whether a product can ship at all; "SHOULD" often decides whether the product is good to use.

2.3 The Two Sides of a Counterexample¶

Counterexamples have two sides: "under-delivery" is missing this requirement; "over-delivery" is piling on confirmations, dwell circles, and prompts in order to satisfy it. Neither side counts as getting it right. The most typical way mid-air gesture design goes wrong is precisely the latter: to suppress false triggering, wrapping every action in a two-second dwell-confirmation circle, turning the interaction into standing at attention — the false-trigger rate does go down, but the interaction dies with it.

2.4 Rule Quick Reference: 39 Rules¶

The table below is the one-line memorable version of every rule. The quick reference does not replace each rule's applicability conditions and full requirements.

G1 Input Validity Is Judgable

G2 Binding Between Gesture and Meaning

G3 Physical Cost Has a Budget

G4 State Is Perceivable

G5 Recognition Uncertainty Is Made Explicit

G6 Consequence Is Decoupled from Gesture

G7 Context and Other People

---

2.5 From Task to Interaction Decision¶

First state what problem the gesture solves for the target user — for example, hands should not touch the screen, fast remote control is needed, or spatial objects are manipulated directly. Compare the gesture path and the non-gesture path for the same task, counting discovery, entry, error correction, and exit together as cost; comparing only the speed of a single recognition is not enough to prove the value of adopting gestures.

The table below is a design record template; it adds no rules and standardizes no values. First choose the platform's existing standard input model, then decide which parts genuinely need to be customized.

Minimum delivery includes: one complete task path, an action-to-consequence mapping, a state-and-transition table, parseable configuration, and verification records and sources. Platform defaults may be inherited, but the platform, input contract, and applicable conditions SHOULD be labeled.

---

3. Rules in Detail¶

This chapter lays out all 39 rules under the seven principles. The design applications, verification examples, and counterexamples in it are only explanatory aids for implementation; they do not prescribe a single implementation.

3.1 G1 Input Validity Is Judgable¶

The sensor is continuously capturing and the user is continuously moving; a clear line is needed between the two: which motions count as a command. This line is defined by the product, enforced by the mechanism, and MUST be visible to the user. A vaguely drawn line makes the product fail in both directions at once — both false triggers and "nothing responds no matter what you do."

G1-1Participation State Is ExplicitMUST¶

In one sentence: Give the user and the system the same answer to "is it receiving gestures right now."

Applies toall products that use mid-air gestures as an input channel.

RuleThe product MUST define a finite, enumerable set of participation states (distinguishing at least "not participating" from "receiving input"), and ensure the system has a single, unambiguous determination of the current state at any moment. Entry and disengagement MUST each have explicit conditions, and the disengagement conditions MUST include at least one method the user can actively execute. The current participation state MUST be perceivable to the user (perception requirements are in G4-1). Equating "a hand appearing within the capture range" directly with "the user wants to interact" is forbidden, unless the false-trigger consequence has already been constrained by G6 to an acceptable range and recorded as an explicit design decision.

Design applicationentering participation may be an explicit separator gesture, entering a specific spatial volume, an attention anchor (gaze or body orientation), a trigger from another modality, or a combination of the above; the basis for the choice is false-trigger consequence and usage frequency, not technical feasibility.

Verification examples

• User side: have the user approach the device and move naturally without being told anything, and observe whether they can state "whether the system is currently listening to me."
• Implementation side: check whether there is a window in which two modules disagree on the participation-state judgment; check whether state transitions are logged as events.

CounterexamplesUnder-delivery — the system starts responding the moment a hand enters frame, and the user setting down a water glass triggers the next page; over-delivery — every interaction requires a two-second raised-hand confirmation first, and the user would rather just press a physical button.

G1-2Gesture Start and End Are JudgableMUST¶

In one sentence: Every gesture has a clear beginning and end, not guessed from continuous motion.

Applies toproducts in which gestures produce discrete commands or continuous control. Each sub-clause of this rule applies according to its own object: the segmentation requirement applies to input that must identify a single operation out of a motion stream; the target-binding requirement applies to object-directed operations; the cancellation and progress-reset requirement applies to operations with a preview, drag, dwell, hold, or other not-yet-effective stage. A command with no spatial target may declare "target binding not applicable," but this does not exempt it from the requirements on command start/end and active cancellation.

RuleEvery gesture MUST have judgable start and end conditions. The system MUST be able to distinguish "one complete gesture," "a not-yet-completed gesture," and "a transitional motion between gestures," and MUST NOT recognize a transitional motion (hand retraction, reset, posture switch) as a command. The product MUST explicitly declare the segmentation basis it uses: a separator gesture, a posture change, a speed or position threshold, a time window, or a combination of these.

Boundary conditionsthis rule does not require all gestures to use the same segmentation basis; different consequence tiers may use different bases (see G6-5).

Rule (target and cancellation): an object-directed operation MUST define the point at which the target binds, and how movement, a gaze shift, target disappearance, or content change afterward is handled. Once an operation has begun, silently handing the same gesture segment off to a new target is forbidden. When a preview, drag, dwell, or hold stage exists, active-cancellation conditions before it takes effect MUST be defined; losing tracking is not equivalent to a valid release (G5-1). Dwell progress MUST be bound to the current target, and MUST NOT carry over the original target's accumulated progress after the target changes.

Rule (continuous mapping): continuous control MUST declare how hand motion maps to object change — position, displacement, or velocity control; the coordinate system, axis, ratio or gain, and permitted range used; and the stop or inertia behavior after release. When snapping is offered, its entry and exit conditions MUST be declared, and silently switching targets is forbidden. When a long-distance operation requires releasing the hand to reposition, a clutch action that "pauses control to reposition the hand" MUST be distinguished from a commit action; a new baseline MUST be established before re-grasping, and the reposition displacement MUST NOT be counted back in as input. Two-handed control MUST define the role of each hand and the behavior when either hand is lost, and MUST NOT silently downgrade to one hand while changing the mapping.

Verification supplement (continuous mapping): turn around, change distance, release the hand to reposition, relocate the coordinate anchor, or lose the assisting hand during a drag, and check whether the object jumps; check whether velocity control stops as specified at the neutral position, on exit, and on tracking loss. A declared inertia animation after a valid release is a different case from mistaking loss for a release.

Basis and referencesWCAG 2.5.2 Pointer Cancellation explains the distinction among press, release, cancel, and undo. Its direct object is single-pointer input; applying a cancelable operation stage to mid-air interaction here is a design derivation of these guidelines, and does not require every gesture to use release-triggering.

Verification supplement: start dragging A then look at B, switch targets mid-dwell, actively cancel before commit; check whether the target was swapped, whether progress carried over, and whether the action still takes effect after cancellation.

Design applicationdesign explicit grab and release semantics for continuous control (drag, zoom); release judgment should not depend on a speed threshold alone, or a user releasing slowly will be judged as still gripping.

Verification examples

• User side: have the user perform the same gesture three times in a row, and observe whether the reset motion is misrecognized as a fourth.
• Implementation side: record a continuous motion stream and check the consistency between the segmentation points and human annotation, paying particular attention to the hand-retraction phase.

CounterexamplesUnder-delivery — after swiping right to turn a page, retracting the arm is recognized as a leftward swipe that flips back; over-delivery — every gesture requires an explicit "ready" posture before it and an "end" posture after it.

G1-3Not Having Left Does Not Mean Continued AuthorizationMUST¶

In one sentence: Not actively exiting does not mean ongoing consent; participation state expires.

Applies toproducts in which participation state can persist beyond a single gesture.

Ruleparticipation state MUST have deactivation conditions: at minimum, a timeout with no valid motion. The user going still, turning around, leaving the capture range, shifting attention, or starting to talk to someone else is forbidden from being treated as continued consent to receive commands. After participation state deactivates, interacting again MUST re-satisfy the entry conditions; if the product offers brief cost-free re-entry, its grace period MUST be explicitly defined and finite.

Basis and referencesafter the user finishes an operation, the system may still interpret everyday motion as input. Participation deactivation limits this window of false-trigger exposure; simply holding the same posture cannot itself prove the user still wants to issue a command.

Boundary conditionslow-consequence features may forgo a separate entry action; when there is no participation session spanning multiple motions, the participation timeout does not apply, but every command must still re-satisfy the subject, spatial, and segmentation criteria, and expires once the operation ends or recognition times out. When a participation session exists, after timeout, re-entering automatically on the next frame merely because the earlier entry condition still holds true is forbidden. Re-entry grace MUST NOT restore an old candidate's eligibility to commit.

Design applicationtimeout duration is tiered by false-trigger consequence, not a single uniform value; give a perceivable cue at deactivation, rather than switching silently.

Verification examples

• User side: have the user turn around and talk to someone for two minutes after finishing an operation, and observe whether their hand motion triggers a command.
• Implementation side: check whether any participation state exists with no timeout; check whether the grace re-entry duration resolves to a concrete value.

CounterexamplesUnder-delivery — after finishing watching TV in the living room, the user keeps chatting and their gestures keep being interpreted as volume adjustments; over-delivery — exiting after five seconds of stillness, so a moment of thought forces the user to raise a hand again.

G1-4Unintentional Motion Does Not Become InputMUST¶

In one sentence: Gesturing while talking, scratching your head, handing something over — none of this should trigger a command.

Applies toproducts whose capture range covers the user's everyday activity space.

Rulethe system MUST distinguish command motion from non-command motion; the criteria MUST be explicitly defined and testable, and MUST NOT rely on gesture form alone. Command criteria SHOULD combine at least one of the following: participation state (G1-1), attention direction, the motion's spatial position, or a separator gesture. The rate at which everyday conversational gestures, unrelated actions, and body-adjustment motions are recognized as commands MUST be measured in real usage environments, and used as one of the release criteria.

Basis and referencesthis is mid-air gesture's most famous failure mode (the Midas touch problem). Raising the recognition threshold changes the trade-off between false positives and false negatives, but form classification alone is not enough to prove "this is a command" — that requires combining participation state or contextual criteria, and verifying the resulting trade-off on target data. The effective lever is architectural: add a layer of participation state or an attention anchor, splitting "is it a command" and "which command is it" into two separate determinations.

Design applicationsplit command determination and gesture classification into two tiers; the first tier is as conservative as possible, and only the second tier performs form discrimination.

Verification examples

• User side: record one hour of natural activity in a real environment (including conversation, eating, using a phone), and tally the number of false triggers and their consequences.
• Implementation side: confirm that command determination is not simply form-classification confidence; the change in false-trigger rate after disabling the attention anchor can be measured.

CounterexamplesUnder-delivery — gesturing while on a phone call triggers a delete; over-delivery — requiring the user to gaze at the camera for three seconds every time first, making it unusable during ordinary conversation.

G1-5Input Ownership Is ClearMUST¶

In one sentence: Clear about whom the system listens to right now and which hand, with explicit conditions for switching person or hand.

Applies toproducts where multiple people or multiple hands may appear within the capture range at once, where multiple input modalities are offered simultaneously, or where the same motion may be interpreted by multiple event sources.

Rulethe system MUST make explicit, at any moment, the subject to which the current input is attributed (which person, which hand) and the operation instance it belongs to, and MUST define the conditions under which ownership is established, held, and transferred. Ownership transfer MUST have explicit conditions; transferring automatically because another hand is closer, clearer, or detected first is forbidden. When another person or another hand enters the capture range, it MUST NOT inherit an already-locked target or already-accumulated confirmation progress; coordinate continuity by itself does not constitute evidence that the subject is the same. When the owning subject leaves or deactivates, the current unfinished continuous operation MUST be ended, and MUST NOT be continued by a new subject (for the abort behavior of continuous operations, see G5-1).

Boundary conditionsthis rule does not require the product to support multiple people; a product declared "single-user" satisfies it merely by ensuring that ownership transfer or misrecognition does not occur when a second person appears. When the platform provides no subject evidence, satisfy this rule with verifiable isolation or an explicit participation mechanism, and do not fabricate an identity confidence score. Handling of third parties being captured itself is covered in G7-3.

Rule (multimodal routing): when gesture, gaze, speech, touch, or a controller are used together, the role each input plays in target selection, operation, and commit MUST be defined, along with priority when they compete. The same user intent MUST NOT take effect more than once because multiple entry points respond simultaneously. When the app loses input focus, the system takes over, the device sleeps, or modality switches, an unfinished operation MUST be ended or suspended; after recovery, the subject, target, and participation conditions MUST be re-checked, and automatically re-issuing an old commit event is forbidden.

Rule (event unification): when the same physical motion simultaneously produces platform selection, grab, and custom recognition events, the event source responsible for the current operation MUST be designated, and the remaining events correlated or excluded; the same intent MUST NOT be interpreted as multiple commits. A debounce duration cannot substitute for operation ownership and duplicate-side-effect prevention.

Basis and referencesthe Microsoft interaction model guidance notes that mixed input models can produce competing operational cues; W3C XAUR §3.8 discusses focus loss during input switching. These sources support the problem and the design direction; event deduplication and recovery conditions are a necessity derivation of these guidelines.

Verification supplement: pick up a controller mid-pinch, summon the system menu and return, confirm from two entry points at once; check whether it commits twice or continues using a stale target.

Design applicationdefine arbitration rules for multi-person scenarios (first-come, explicit takeover, binding to a designated subject), and make the current ownership visible to everyone present.

Verification examples

• User side: while one person is dragging an object, have another person walk by and raise a hand, and observe whether the drag is hijacked or interrupted.
• Implementation side: check whether ownership-transfer events are logged; check whether the other hand's input is correctly ignored while one hand is bound.

CounterexamplesUnder-delivery — with two people present, the system keeps jumping back and forth between the two pairs of hands, and neither can control anything; over-delivery — requiring facial-recognition login before every operation.

G1-6Participation Cost Matches the ScenarioSHOULD¶

In one sentence: The cost of the entry point should match the value of the feature; avoid extremes on either end.

Applies toproducts that define a participation entry method.

Rulethe cost of the action to enter interaction SHOULD match the value and frequency of the task to be accomplished: high-frequency, low-consequence operations SHOULD have a low-cost entry; low-frequency, high-consequence operations SHOULD have participation conditions sufficient to discern intent, object, and consequence — "higher cost" means more thorough criteria, not a more tiring motion or a longer wait; protection against consequence is carried mainly by G6's commit constraints. Substituting "zero-cost entry plus after-the-fact undo" for G6-1's commit constraint on irreversible actions is forbidden.

Design applicationa single product may have entry points at multiple tiers — a shortcut gesture reaching a common operation directly, and a full participation flow for other operations.

Verification examples

• User side: measure the total motion time from "wanting to do it" to "having done it" for a common operation, and compare it against the touch or speech path.
• Implementation side: check whether all features share the same high-cost entry point.

CounterexamplesUnder-delivery — adjusting the volume also requires completing a three-step participation flow first; over-delivery — for the sake of speed, delete is also placed behind a zero-cost shortcut gesture.

3.2 G2 Binding Between Gesture and Meaning¶

Custom mid-air gestures usually lack a physical label; visible objects and platform-standard interactions can supply affordance and existing convention. The gestures a user can use equal the gestures they can discover and remember — a number far smaller than designers tend to estimate. This principle governs the gesture set itself: how large it is, how it is discovered, how far apart its members are, and where its meaning comes from.

G2-1The Gesture Set Is Bounded and DiscoverableMUST¶

In one sentence: The number of gestures has a ceiling, and users can discover what they can do without reading a manual.

Applies toall products that define a gesture vocabulary.

Rulethe number of gestures valid at the same time within the same context MUST have an explicit ceiling, recorded as a design decision. Users MUST be able to discover every gesture needed to complete the primary task without reading external documentation; the primary path is forbidden from depending on a hidden gesture that can only be learned through documentation, tutorial videos, or word of mouth.

Design applicationprioritize mapping gestures to direct manipulation of visible objects (push, grab, drag); this kind of interaction's affordance comes from the object itself, which can lower the memory burden, though its discoverability still needs verification; reserve pose-type gestures that need to be memorized for a small number of high-value global operations.

Verification examples

• User side: give an untrained target user a task, and record how many gestures they can discover and use with no prompting.
• Implementation side: count the number of gestures valid at the same time in each context, and check whether it exceeds the declared ceiling.

CounterexamplesUnder-delivery — twelve custom poses, of which the user only remembers two, so the remaining features are effectively unreachable; over-delivery — a gesture cheat sheet permanently displayed on every screen, obscuring the content itself.

G2-2Semantic Mapping Is StableMUST¶

In one sentence: The same gesture has only one meaning within the same context.

Applies toall products that define a gesture vocabulary.

Rulethe same gesture form MUST be bound to only one meaning within the same context. The same form may carry different meanings in different contexts, but the difference in context MUST be perceivable to the user, and that perception MUST NOT depend solely on the user remembering which mode they are currently in. A gesture's meaning silently changing along with internal system state is forbidden.

Basis and referencesthis is the mid-air-gesture form of mode confusion. In a GUI, modes have visible visual cues; gestures have no physical input-device state to rely on, so a mode error is often not discovered until after execution.

Design applicationlet the difference in context be reflected in the object being operated on or its spatial position, rather than in an abstract mode switch.

Verification examples

• User side: have the user switch between two contexts and immediately perform the same gesture, and observe whether their expectation of the result matches what actually happens.
• Implementation side: inventory whether any same-form, multi-meaning combinations exist, and check the context-distinguishing basis for each group.

CounterexamplesUnder-delivery — the same fist gesture means pause during playback and delete in a list, and the user does not know where they are; over-delivery — to avoid reuse, every feature gets its own separate pose, exploding the vocabulary (violates G2-1).

G2-3Formal Differences Are Sufficient to DistinguishMUST¶

In one sentence: Similar-looking gestures do not carry functions with widely differing consequences.

Applies toall products that define a gesture vocabulary.

Rulethe difference between gestures MUST hold at two levels simultaneously: the recognition level (the system can reliably distinguish them) and the execution level (a person can reliably produce a distinguishable difference). Satisfying only one of the two does not satisfy this rule. Two actions with widely differing consequence tiers are forbidden from being bound to similar-looking gestures; the criteria for "similar" MUST be explicitly defined and measured against target users.

Rule (platform conflicts): custom and remapped gestures MUST be checked for conflicts with the target platform's system gestures, assistive-technology input, and everyday communicative motion. Intercepting a system-reserved exit or takeover operation is forbidden; related conflicts MUST be re-checked after upgrading the platform or the gesture vocabulary.

Basis and referencesApple WWDC23: Design for spatial input recommends prioritizing standard gestures, with custom gestures kept distinct from system gestures and common communicative motions. This is a platform design reference, and does not prove that a unified vocabulary exists across platforms.

Design applicationplace heavy-consequence actions on poses that are visibly distinct in form and not easily formed by accident through everyday motion (see G6-4).

Verification examples

• User side: have the user perform each of two similar gestures twenty times in a row, and tally how distinguishable their own execution is and their subjective confidence.
• Implementation side: measure the confusion matrix, and check the confusion rate between a high-consequence action and its nearest-neighbor gesture.

CounterexamplesUnder-delivery — four fingers extended means "save," five fingers extended means "discard"; recognition performs decently, but users cannot reliably perform them consistently themselves; over-delivery — requiring users to make awkward, unnatural poses purely for the sake of distinguishability.

G2-4Do Not Assume Universal IntuitionSHOULD¶

In one sentence: Gesture meaning is verified against target users, not against what the designer feels is natural.

Applies toproducts that define or modify a gesture-semantic mapping.

Rulethe binding between gesture and meaning SHOULD be based on empirical evidence from the target user group, and SHOULD NOT rest solely on the design team's intuition that "this gesture feels natural." The product SHOULD account for cultural differences, handedness differences, and the effect on gesture choice of prior expectations users bring from existing devices (touchscreens, remote controls, mice).

Basis and referencesdesign candidates SHOULD incorporate the expectations that come from existing interface experience — for example, users may try to "tap" or "swipe" in mid-air. Existing experience shapes user expectation, but this does not constitute a cross-device ranking of these forms as better or worse — a candidate gesture's comprehensibility, executability, recognizability, and fatigue still MUST be verified separately on the target device and with the target population. The role of empirical evidence is therefore not to directly adopt users' proposals, but to expose the gap in expectation between designer and user.

Design applicationtreat elicitation results as a constraint rather than an answer; if a gesture that users highly consistently propose is unusable, at least ensure it is not bound to the opposite meaning.

Verification examples

• User side: test candidate gestures' semantic-guessing agreement rate and first-attempt success rate among target users.
• Implementation side: record the selection basis and evidentiary source for each gesture.

CounterexamplesUnder-delivery — the team votes internally to decide the gesture set, and after launch the primary user group cannot guess any of it; over-delivery — treating elicitation results directly as a specification, and adopting a batch of gestures that are the most tiring to perform and the worst-recognized.

G2-5Customizable and Can Be Turned OffSHOULD¶

In one sentence: Individual gestures may be replaced or turned off, but this cannot be used to bypass consequence constraints.

Applies toproducts whose gesture set contains entries that may conflict with users' everyday motion, or products aimed at a widely varied user population.

Rulethe product SHOULD allow users to turn off or remap individual gestures. Customization MUST NOT change the action's own consequence tier, nor may it be used to bypass G6-1's requirement on the commit path for irreversible actions; a user may swap delete onto a different gesture, but MUST NOT turn it into something that no longer requires a second confirmation. After turning off an individual gesture, the corresponding feature MUST still be reachable through another path (see G7-1).

Design applicationmake "this gesture always false-triggers" a single-tap-away toggle, not something buried deep in settings.

Verification examples

• User side: have the user turn off a gesture that false-triggers frequently, and check whether the corresponding feature is still usable.
• Implementation side: check whether a custom configuration can break through the consequence-tier mapping and commit constraints.

CounterexamplesUnder-delivery — a gesture conflicts with motions from the user's occupation, and the only option is to turn off gesture input entirely; over-delivery — opening customization so far that users can bind payment to a wave.

G2-6Learning Cost Is Re-EnterableSHOULD¶

In one sentence: Gestures that need to be learned can be learned again at any time, not covered once and for all in first-run onboarding.

Applies toproducts that include pose-type gestures requiring learning.

Rulegestures requiring learning SHOULD have a teaching-and-practice entry point that can be re-entered at any time, and that entry point SHOULD be reachable from the point of use, not requiring the user to interrupt their task to dig through settings. Teaching SHOULD provide an immediate distinction between doing it right and doing it wrong, not merely display a diagram.

Rule (practice isolation): practice motions within teaching MUST be confined to a demonstration object or a recoverable practice environment, and producing an actual send, payment, delete, or permission change is forbidden. Entering and exiting practice MUST be perceivable, and after exiting, continuing an unfinished practice gesture as a real command is forbidden.

Verification supplement: immediately return to the task after practicing a confirmation gesture, and check whether real objects and external systems remain unchanged.

Design applicationwhen recognition fails repeatedly, offer an in-place "see how it's done" on the spot, rather than playing it only once at first launch.

Verification examples

• User side: have the user, one week into use, find the learning entry point for an infrequently used gesture again, and record the time taken.
• Implementation side: check the number of steps needed to reach the teaching entry point from the main usage scenario.

CounterexamplesUnder-delivery — a tutorial video plays on first launch and can never be found again afterward; over-delivery — the teaching is forced to replay every single time the app is opened.

3.3 G3 Physical Cost Has a Budget¶

In mid-air gestures, the input device is the user's body. It gets tired, its precision has a ceiling, its form varies from person to person, and none of these costs show up in any log — they show up as the user quietly no longer using the feature. This principle treats what the body can bear as a hard constraint, on equal footing with a latency budget or a memory budget.

G3-1The Primary Path Does Not Depend on Fatiguing MotionMUST¶

In one sentence: High-frequency operations do not require raising the arm above shoulder height or holding it aloft for a long time.

Applies toall products that use mid-air gestures as routine input.

Rulethe primary path for high-frequency operations is forbidden from requiring the hand to be raised above shoulder height, requiring the arm to hold a posture unsupported for an extended time, or requiring large-amplitude, whole-arm motion. The product MUST declare a motion budget for the primary path (amplitude, height, single-hold duration), and verify its sustainability over the target usage duration.

Cases where motion itself constitutes the activity's content are assessed separately (motion-based training, rehabilitation, exercise assessment, performance): their physical load is judged by that activity's own goals and safety requirements, and this rule's budget for "command shortcuts" does not apply to them; but the control actions that enter, pause, and exit these activities still fall under this rule, and MUST NOT require additional fatiguing motion.

Basis and referencesarm fatigue ("gorilla arm") is not a stamina problem but a design problem — an unsupported raised arm can cause fatigue and reduced precision, and its severity is affected by posture, motion load, task duration, and individual differences. The effective countermeasure is to design motions that let the arm get support (small motions close to the body, postures with elbow support), not to require the user to power through.

Design applicationdesign high-frequency operations as small motions completable in front of the body with the elbow naturally lowered; reserve gestures requiring large motion for low-frequency operations.

Verification examples

• User side: have the user operate continuously at typical usage intensity, and measure subjective fatigue and the decline in execution success rate over the second half.
• Implementation side: check whether the declared motion budget for the primary path matches the motion actually required by the interaction.

CounterexamplesUnder-delivery — turning every page requires raising the hand above the shoulder and waving, and the user gives up after ten minutes; over-delivery — compressing every motion to an extremely small amplitude, making recognition unstable and users afraid to move.

G3-2Precision Requirements Match Human CapabilityMUST¶

In one sentence: Do not carry mouse-level precision requirements into unsupported open air.

Applies toproducts involving target selection, value adjustment, or position control.

Ruletarget size, stability requirements, and adjustment resolution MUST be achievable under the support conditions the user actually has. The product MUST declare the precision tier required by the primary path, and using point-level precision selection as the primary path under unsupported conditions is forbidden. When precision is insufficient, it MUST be solved by enlarging the target, providing snapping, switching to relative adjustment, or tiered adjustment; solving it by requiring the user to hold steadier is forbidden.

Design applicationangular jitter in remote pointing is amplified with distance, so the same amount of hand tremor is acceptable at near range and unacceptable at far range; near-field direct manipulation and far-field pointing SHOULD use different target-size standards.

Verification examples

• User side: measure target-selection success rate and time at real distances and postures, including both standing and seated.
• Implementation side: check whether target size varies with interaction distance and input model (near-field / far-field).

CounterexamplesUnder-delivery — small desktop-scale controls are carried into mid-air unchanged, and users keep selecting the wrong adjacent item; over-delivery — every control is enlarged to a quarter of the screen, so a single screen cannot fit three features.

G3-3Completable with One HandSHOULD¶

In one sentence: The core path can be completed with one hand, and does not assume a dominant hand.

Applies toproducts that may be used in scenarios where the user's other hand is occupied.

Rulethe core task path SHOULD be completable with one hand, and SHOULD NOT assume the user uses a particular dominant hand. Gestures requiring two hands SHOULD be limited to operations where they are genuinely necessary (such as two-handed zoom), and SHOULD have a one-handed alternative path.

Design applicationboth the recognition model and the interaction layout need to support left-right hand symmetry; do not recognize the mirrored motion of the left hand as a different meaning (unless that semantic difference is an explicit design and visible to the user, see G2-2).

Verification examples

• User side: have the user hold an object in one hand while completing the core task; test once with the left hand and once with the right.
• Implementation side: check whether any gesture has a significantly lower recognition rate on one hand specifically.

CounterexamplesUnder-delivery — a user holding a child cannot use any feature at all; over-delivery — to guarantee one-handed usability, removing an interaction like two-handed zoom that is clearly better to use.

G3-4Continuous Use Has a Ceiling and Allows RestSHOULD¶

In one sentence: Long tasks offer a supportable posture or an alternative modality, and do not require sustained holding.

Applies toproducts where a single session is expected to last more than a few minutes.

Rulethe product SHOULD declare a duration ceiling for continuous gesture use, and provide a supportable posture, a segmented completion method, or an alternative modality as that ceiling is approached or exceeded. Designing an interaction that requires the user to hold a posture for the entire duration of a task is forbidden — the cost of holding a posture rises non-linearly over time, and the user cannot put their hand down partway through.

Design applicationbreak a long process into pausable segments, letting the user put their hand down without losing progress (state-continuity requirements are in G5-1).

Verification examples

• User side: have the user complete one full, typical long task, and record how often they give up partway or actively switch modality.
• Implementation side: check whether any state exists that can only be maintained by holding a posture.

CounterexamplesUnder-delivery — requiring the user to hold a pinch posture the entire time until the upload finishes; over-delivery — a "suggest taking a break" popup interrupting work every two minutes.

G3-5Bodily Differences Do Not Constitute ExclusionMUST¶

In one sentence: People with small hands, tremor, missing fingers, or prosthetics must also be able to complete the task.

Applies toall products that use mid-air gestures as an input channel.

Ruledifferences in recognition and execution caused by hand size, joint range of motion, tremor, missing finger joints, a prosthesis, or worn items (gloves, jewelry, bandages) MUST NOT prevent the user from completing the task. The product MUST verify usability under these conditions; where recognition cannot cover a case, feature reachability MUST be guaranteed by G7-1's non-gesture path, and that path MUST NOT be a functionally limited substitute.

Boundary conditionsthis rule does not require gesture recognition to cover every bodily condition — that is unrealistic. What it requires is that wherever recognition cannot reach, the feature remains reachable. This is also one of the reasons G7-1 exists.

Design applicationexpose adjustable parameters (gesture-amplitude tolerance, debounce strength, dwell duration) to the user, rather than offering only a single configuration calibrated to an average hand shape.

Verification examples

• User side: test core-task completion rate among users who have the relevant bodily conditions.
• Implementation side: check whether the non-gesture path is exposed automatically and perceivably when recognition fails.

CounterexamplesUnder-delivery — a user with tremor can never complete a dwell confirmation, and there is no other entry point; over-delivery — loosening every threshold until it works for everyone, letting the false-trigger rate spiral out of control (this SHOULD be solved with adjustable parameters, not a uniform loosening).

3.4 G4 State Is Perceivable¶

Gesture interaction has no mechanical feedback: a finger press has resistance, a mouse click has a sound — none of this exists in mid-air. Everything the user judges about system state comes from feedback the product actively provides. When feedback is missing, the user's default strategy is to repeat the motion — which simultaneously amplifies false triggering and frustration.

G4-1Each of the Three States Has Its Own FeedbackMUST¶

In one sentence: In-range, locked, and committed must be distinguishable from one another.

Applies toall products that use mid-air gestures as an input channel.

Rulethe system MUST let the user distinguish the three applicable feedback layers: in-range (the hand is within the product's effective interaction zone and input is available), locked (the current candidate target or global command is determined, but has not yet taken effect), and committed (the action has taken effect). Capturing a hand does not equal being in participation; participation state is expressed per G1-1. When a global gesture has no spatial target, what is locked is the command, and a target selection MUST NOT be fabricated. When a layer genuinely does not exist, record it as not applicable; a dwell or confirmation step MUST NOT be artificially inserted just to fill out the three states. The form of feedback is unconstrained, as long as target users can distinguish it reliably.

Rule (result state): the three states are feedback layers, not a complete state machine. When asynchronous execution exists, processing, failed, result-unknown, and cancelled MUST additionally be distinguished; a request being sent or a receipt being received does not equal the action having taken effect. The "committed" feedback MUST come from a real result; a pending or failed state MUST NOT be obscured by a prior-success cue. Verification and duplicate prevention when the result is unknown are covered in G6-2.

Basis and referencesa missing feedback layer produces the following foreseeable failure: the user does not know whether "it didn't see me," "it saw me but didn't select," or "it selected but didn't succeed," and can only redo the action over and over. For tasks that have these stages, the three correspond to different next actions; conflating them can induce mistaken retries. This is these guidelines' interaction model, not a unified platform standard.

Design applicationthe three states may be assigned to different channels — in-range via a cursor or hand visualization, locked via object highlighting or snapping, committed via sound plus the object's actual change.

The table below is an example task that includes a candidate stage and asynchronous commit; a simple local operation may go directly from valid input to result, without an artificial wait. Participation state and execution result are managed separately; exiting participation does not erase a result that has already occurred.

Rule (state facts and races): input participation, data validity, operation stage, and execution result MUST be judged separately. The interface MUST be able to link feedback to the current operation's subject, target, action, event order, and real result; these are runtime facts, not Tokens. When cancellation, deactivation, or data invalidation races against a not-yet-effective commit, the no-longer-qualifying commit MUST be intercepted first; if an external consequence has already occurred, the actual result MUST be reflected and a genuinely usable undo or remedy provided — claiming "cancelled" is forbidden. A late receipt from an old operation MUST NOT overwrite a new operation's state, and a confirmed failure or pending result MUST NOT be cleared by "tracking the hand again."

Verification examples

• User side: pause in each state, and have the user describe the system's current state and their own next step.
• Implementation side: check whether the three states have independently observable presentations; the same element's form, text, or contrast may change, but this MUST be verified through a discrimination test.

CounterexamplesUnder-delivery — there is only a single small dot, and the user is left guessing forever; over-delivery — each of the three states gets its own animation plus sound effect, so a single operation triggers three sounds.

G4-2Feedback Delay Has a CeilingMUST¶

In one sentence: When feedback is slow enough to break the sense of causality, it degrades to discrete feedback rather than no feedback.

Applies toall products that provide feedback for actions.

Rulethe product MUST declare an end-to-end latency budget for feedback (from when the action occurs to when the user can perceive the feedback). When latency exceeds the budget, it MUST degrade to explicit discrete feedback (such as a "processing" status indicator), and appearing as no feedback is forbidden. Once the latency of tracking feedback (hand visualization, cursor) exceeds the budget, continuing to present it in tracking form is forbidden — lagging tracking is more misleading than no tracking, because the user adjusts their motion based on it, causing overshoot and oscillation.

Degrading MUST NOT merely stop the display while continuing to accumulate input: if the current quantity needed for closed-loop judgment cannot be provided to the user at this point, new business updates for that continuous control MUST be paused, and the retained value, the not-yet-effective portion, and the available exit method MUST be made explicit; the control baseline is re-established on recovery. It MAY continue if a verified, reliable feedback channel intrinsic to the object still exists — one display channel failing does not equal overall feedback failing.

Design applicationmeasure tracking feedback and result feedback separately; the former is involved in correcting continuous motion, the latter is used to judge whether the action took effect, and a single average MUST NOT substitute for both budgets.

Verification examples

• User side: artificially inject latency, and observe whether the user overshoots, repeatedly corrects, or repeats the action.
• Implementation side: measure the end-to-end latency distribution for each type of feedback (not just the mean), and check whether the degradation behavior triggers when the budget is exceeded.

CounterexamplesUnder-delivery — the hand cursor lags by half a second, and the more the user corrects, the further off they get; over-delivery — sacrificing recognition quality to push latency down, so feedback is fast but frequently wrong.

G4-3Continuous Motion Has Continuous FeedbackMUST¶

In one sentence: Display the current value continuously during drag or zoom, not report the result only at the end.

Applies toproducts that include continuous control such as drag, zoom, rotate, or slider adjustment.

Rulecontinuous control MUST continuously feed back the current value or current position while the motion is in progress, so the user can judge before commit whether the target has been reached and adjust accordingly. Presenting the result only once, after the motion ends, is forbidden. Continuous control MUST have explicit release semantics, and the release determination MUST be perceivable to the user (start/end determination is in G1-2).

Design applicationusing the manipulated object itself as the feedback carrier is preferable to an extra numeric display — the object moves with the hand, and the user does not need to split attention between two places.

Verification examples

• User side: have the user adjust a value to a specified target, and record the number of overshoots and corrections.
• Implementation side: measure the consistency between the current value and the feedback, end-to-end latency, tail-end stutter, and the number of overshoots and corrections; "the refresh rate equals the sampling rate" is not the pass criterion — the two need not be equal; the criterion is whether the end-to-end loop can be closed.

CounterexamplesUnder-delivery — waving to adjust volume, and only finding out where it landed after releasing the hand; over-delivery — a floating numeric panel precise to two decimal places hovering next to the hand, obscuring the content being adjusted.

G4-4Feedback Is Not Exclusively VisualSHOULD¶

In one sentence: The primary state has at least one non-visual channel.

Applies toproducts where the user's gaze may not be on the display area.

Ruleprimary-state feedback SHOULD have at least one non-visual channel (auditory, tactile, mid-air haptics, or a perceivable change intrinsic to the controlled physical object). In scenarios where the user's gaze must be directed elsewhere (driving, cooking, surgery, far-field operation of a large display), non-visual feedback is mandatory (see G7-6).

Basis and referencesthe scenarios where mid-air gestures are most valuable are precisely the scenarios where hands cannot conveniently touch and eyes cannot conveniently look — and relying on visual feedback in such scenarios is self-contradictory. Mid-air haptics is the direct solution to this gap, but is limited by device and range; hearing is the more realistic choice in most scenarios.

Design applicationthe non-visual channel need not carry all the information; carrying the state transition is enough — "locked" and "committed" can cover most needs with two short, distinguishable sounds.

Verification examples

• User side: have the user complete the core task without looking at the screen.
• Implementation side: check whether distinguishable state feedback still exists under muted conditions, or whether the product explicitly declares that scenario not applicable.

CounterexamplesUnder-delivery — all feedback for in-vehicle gesture control is on the center console screen, and the user must look down to confirm; over-delivery — every minor motion is accompanied by a prompt tone, and the passenger asks to have the whole feature turned off.

G4-5Boundaries Are PerceivableMUST¶

In one sentence: About-to-exit and already-exited must be known to the user as they happen, not inferred from a lack of response.

Applies toproducts where the interaction zone has an effective spatial boundary (that is, the vast majority of products).

Rulethe user approaching the interaction-zone boundary, and having already left the interaction zone, MUST be perceivable. Feedback for having left MUST be distinguished from "system malfunction" and "action not recognized" — the three call for completely different next actions from the user. Representing having crossed the boundary with no response is forbidden.

When the cause can be determined, give a corresponding cue; when only "input is currently unavailable" can be determined and the cause cannot, the unknown cause MUST be honestly stated, along with a safe recovery or switching entry point — fabricating a definite diagnosis such as "too far" or "insufficient light" when the cause is unknown is forbidden. What this rule requires distinguishing is known fact; it does not require the sensor to have diagnostic capability it does not possess.

Design applicationgive a progressive cue when approaching the boundary (hand visualization fading, a directional indicator), rather than failing suddenly at the instant the boundary is crossed.

Verification examples

• User side: have the user actively move their hand out of the interaction zone and back, and observe whether they can state what happened and how to recover.
• Implementation side: check whether boundary crossing, tracking loss (G5-1), and recognition failure have distinguishable presentations.

CounterexamplesUnder-delivery — the user stands a bit too far away, no gesture gets any response, and they think the feature is broken; over-delivery — a warning box pops up every time the hand gets a little closer to the edge.

G4-6Feedback Does Not OverloadSHOULD¶

In one sentence: Feedback intensity matches the consequence of the action; not every minor movement gets a loud prompt.

Applies toall products that provide feedback for actions.

Rulethe intensity and prominence of feedback SHOULD match the consequence of the action. High-frequency, low-consequence operations SHOULD use lightweight, ignorable feedback; prominent feedback SHOULD be reserved for state transitions and high-consequence actions. The product SHOULD NOT apply a prominent cue to every minor positional change just to satisfy G4-1.

Basis and referencesthis rule is the counterweight to G4-1. The typical result of over-delivering three-state feedback is: all feedback becomes equally prominent, so all of it degrades into background noise, and the one truly important commit confirmation gets ignored — this is the same mechanism as alarm fatigue.

Verification examples

• User side: after continuous use, ask the user whether they noticed a particular key state change.
• Implementation side: count the number of feedback events per unit time and the proportion that are prominent-level.

CounterexamplesUnder-delivery — commit and movement use the same weak cue, and the user does not know they have already committed; over-delivery — every frame's position update is accompanied by a sound effect and animation.

3.5 G5 Recognition Uncertainty Is Made Explicit¶

Gesture recognition may output a label, a score, or a probability estimate, none of which is equivalent to the fact of user intent. The product MUST explicitly decide how to handle this uncertainty: which side to lean toward, how uncertain is uncertain enough to stop, what to do on loss, and which way to fall back when capability degrades. If these decisions are not made, a default takes over — and that default tends to be "take the top-scoring classification and execute it," which is unacceptable for high-consequence actions.

G5-1Tracking Loss Is a Normal StateMUST¶

In one sentence: Behavior on loss is predefined and safe; continuing to advance using the last frame is forbidden.

Applies toall products that depend on continuous tracking.

Ruletracking loss MUST be handled as a normal operating state, not an exception branch. The product MUST define the behavior on loss for every class of ongoing operation, and that behavior MUST be a safe default: freeze the current value and wait, roll back to the state before the operation began, or wait for tracking to be regained for a defined grace period. Continuing to advance the operation using the last frame's data is forbidden; automatically committing an in-progress action after loss is forbidden. Loss MUST be perceivable to the user (see G4-5), and the continuation behavior after tracking is regained MUST be explicitly defined, with silent jumps forbidden.

Basis and referencescontinuous-tracking failure destroys the positional and motion evidence continuous control depends on. If the last frame's velocity vector is extrapolated when the hand leaves the field of view, it produces a large motion the user never actually made — in drag, delete, or swipe-confirm interactions, this directly causes unpredictable consequences. Occlusion (another hand, the body, a held object), sudden lighting changes, and going out of range all produce the same phenomenon, and do so frequently in real environments.

Rule (data eligibility): the product MUST declare the data each class of operation depends on and its validity criteria: the joints or directions needed, the maximum data-freshness age, how the platform's validity and tracking flags are to be interpreted, and how partial loss is handled. Having a numeric value does not equal tracking being valid — when coordinates exist but the required data is invalid or stale, it does not constitute usable input; when the platform separately provides an active-tracking flag, the combined criterion with the validity flag MUST be declared. An API that lacks a particular flag MUST use whatever pose validity or standard input event it actually provides, neither fabricating the flag nor defaulting to treating stale coordinates as valid. Smoothing, carrying forward the old value, and extrapolation after invalidity may be used only for display; they do not restore operation eligibility, and do not constitute a basis for commit; a normal pose estimate that has already passed the platform's and the product's validity judgment is not forbidden across the board merely for being an "estimate."

Rule (regaining tracking): when continuation is permitted, it MUST be verified that the subject, target, and operation are still the same, and the control relationship between the current hand position and the object position MUST be re-established; when this cannot be verified, the candidate is cancelled or a restart is required.

Design applicationprepare a snapshot of the operation's starting point for continuous operations, making rollback an available option; set grace duration separately per operation type, not a single uniform value.

Verification examples

• User side: move the hand out of the field of view and back during a drag, and observe whether the object undergoes displacement or commit the user did not intend.
• Implementation side: inject a tracking interruption and check whether extrapolation occurs; check whether the position jumps after tracking is regained; check whether the old operation is wrongly continued after changing the input subject or target.

CounterexamplesUnder-delivery — the instant the hand is occluded, the dragged object flies off-screen and commits; over-delivery — the loss of a single frame immediately rolls back the entire operation, so normal use is constantly interrupted (a limited grace period may instead be used based on the operation's consequence, during which updates simply pause).

G5-2Bias Direction Is Explicit and TieredMUST¶

In one sentence: The base recognition value can be shared, but the consequence-release policy MUST be verified by tier.

Applies toall products that determine gestures based on classification or thresholds.

Rulethe product MUST explicitly declare the recognition bias direction (favoring a miss over a false trigger, or the reverse), and this declaration MUST be tiered by the action's consequence level; releasing every consequence tier based on a single unverified global threshold is forbidden. Recognizers may share a base threshold, but the release policy and false-trigger acceptance criteria for each tier MUST be defined independently; an additional confirmation MUST NOT be replaced by high confidence. Irreversible actions, actions with external effects, or actions involving funds are forbidden from using a trigger-happy setting. The choice of bias direction MUST be recorded as a design decision, and may be adjusted with the scenario (see G7-5).

Basis and referenceswith the recognizer and data distribution held fixed, adjusting the decision threshold usually trades off false triggers against missed recognition; improving the model, the data, or the participation mechanism may improve both at once, so it cannot be asserted that the two can never be optimized simultaneously. Scores are also not inherently calibrated probabilities. The scikit-learn decision-threshold tuning documentation separates statistical prediction from action decisions, and calls for avoiding tuning the threshold directly on training data; it supports the method, and does not supply thresholds for gesture products.

Design applicationbind the threshold to the consequence-tier mapping (see gesture.recognition.confidence.threshold and gesture.commitment.risk.mapping in the Design Token), rather than scattering a handful of magic numbers through the code.

Verification examples

• User side: measure the actual incidence of false triggers and missed recognitions and the user's reaction, separately for high-consequence and low-consequence actions.
• Implementation side: check whether each consequence tier has an explicit release policy and verification record, and whether a high score is used to bypass confirmation.

CounterexamplesUnder-delivery — every gesture shares one confidence threshold, and delete is just as easy to false-trigger as turning a page; over-delivery — tuning every threshold extremely high to suppress false triggers, so three out of ten normal operations get no response.

G5-3Low Confidence Does Not Pass as CertaintyMUST¶

In one sentence: When unsure, do not execute a high-consequence action, and do not silently guess one either.

Applies toproducts whose recognition results carry confidence information.

Rulewhen recognition confidence is below the threshold corresponding to an action, directly executing a high-consequence action is forbidden. The system MUST do one of the following: hold its current state and give a perceivable cue, present candidates for the user to choose from, or require additional confirmation. Silently executing the top-scoring candidate is forbidden, as is presenting a low-confidence result as a determined recognition result.

Boundary conditionsthis rule does not require exposing the confidence value to the user. What it requires is differential treatment in behavior — the user does not need to know whether it is 0.6 or 0.9; what they need to know is "the system isn't sure, please try again" versus "the system is certain."

Design applicationwhen a target is already bound, the current value may be held with a cue that recognition is still pending; when a command is not yet determined, show candidates or offer a choice, and this MUST NOT be called "locked." Request confirmation only when the user's judgment is actually needed.

Verification examples

• User side: produce ambiguous gesture input, and observe whether the system executes an action the user did not intend.
• Implementation side: check whether the high-consequence action path has any branch that bypasses the confidence determination.

CounterexamplesUnder-delivery — an ambiguous motion is judged as delete and executed directly; over-delivery — a confirmation box pops up at the slightest uncertainty, so confirmation boxes keep appearing during normal use (the choice among hold, candidate, or cancel SHOULD instead depend on whether a valid target is already bound, see Design application).

G5-4Recognition Conditions Can Be Known and ImprovedSHOULD¶

In one sentence: When recognition degrades, tell the user the reason, and make it a reason they can act on.

Applies toproducts whose recognition quality is significantly affected by environmental conditions.

Rulewhen conditions such as lighting, occlusion, distance, motion speed, or worn items cause recognition quality to drop, the product SHOULD inform the user in a way they can act on. The cue SHOULD point to a concrete improving action (move a little closer, raise your hand a little, get out of the backlight), and SHOULD NOT present only "recognition failed" or a technical error code.

Design applicationunify this cue with G4-5's boundary cue within the same feedback language, so the user does not have to learn two separate sets of error presentations.

Verification examples

• User side: under backlighting, partial occlusion, and being too far away, observe whether the user can restore usability on their own.
• Implementation side: check whether the different kinds of recognition degradation are distinguished, or all lumped into a single failure.

CounterexamplesUnder-delivery — always displaying only "gesture not recognized," and the user does not know whether to step forward or turn on a light; over-delivery — continuously displaying a recognition-quality gauge, forcing the user to constantly monitor sensor state.

G5-5Degradation Path Is PredefinedMUST¶

In one sentence: How to fall back when capability drops is decided in advance, in order, not improvised at runtime.

Applies toproducts whose recognition capability may degrade during operation (that is, the vast majority of products).

Rulethe product MUST predefine a degradation order for when recognition capability drops; the available tiers include lowering the precision requirement, shrinking the set of simultaneously valid gestures, switching to coarser-grained interaction, switching modality, and stopping gesture input. Degradation MUST be perceivable to the user, and the scope of features still reachable after degradation MUST be clear. Continuing to run with the full gesture set when capability is insufficient, and relying on the user to keep retrying, is forbidden.

Boundary conditionsthis rule does not require the product to implement every degradation tier; it requires that whichever tiers are adopted are predefined, ordered, and that the final tier lands on G7-1's non-gesture path.

Design applicationexplicitly bind degradation trigger conditions (consecutive failure count, continuous loss duration, environmental conditions) to degradation actions at the configuration layer (see gesture.recognition.degradation.order and gesture.fallback.auto_fallback.trigger in the Design Token).

Verification examples

• User side: progressively worsen recognition conditions, and observe whether the user can still complete the task at every tier, or clearly knows what to switch to.
• Implementation side: occlude the camera, and check whether the system enters a defined degraded state rather than continuously erroring out.

CounterexamplesUnder-delivery — after the camera is blocked, the app becomes completely unresponsive and gives no hint of what else can be done; over-delivery — the slightest fluctuation in recognition switches straight to speech, repeatedly forcing the user to change modality.

3.6 G6 Consequence Is Decoupled from Gesture¶

Misrecognition is the norm in this modality. What these guidelines actually need to protect, therefore, is not recognition accuracy but the scale of a misrecognition's consequence. This principle governs the strength of the coupling between a gesture and the consequence it causes: the heavier the consequence, the less that chain can consist of a single gesture alone.

G6-1Irreversible Actions Are Not Committed by a Single GestureMUST¶

In one sentence: Delete, send, and pay cannot be completed with a single wave.

Applies toproducts where a gesture can trigger an irreversible action, an action with external effects, or an action involving funds.

Ruleirreversible actions, external sending or publishing, payment and funds transfer, and permission changes are forbidden from being committed directly by a single gesture. Such actions MUST be confirmed through a second channel in a different modality (speech, a key, touch, or human operation), or through a second gesture confirmation explicitly bound to the object being confirmed. Being able to remedy an external result after the fact does not equal it never having had a consequence, and this MUST NOT be used to exempt confirmation. Confirmation MUST be bound to the specific object, content, current state, and consequence, and MUST NOT be a generic "are you sure"; if a key condition changes or the confirmation expires while waiting, confirmation MUST be redone. Confirmation does not substitute for platform identity verification and permission checks.

Basis and referencesunintentional motion can trigger external consequences. The second confirmation exists to let the user judge the specific object and consequence; a higher recognition score alone, or a longer or more tiring motion alone, cannot substitute for that judgment.

Design applicationa low-consequence action that is fully recoverable and has no external effect may take effect directly with undo provided; actions such as external sending and payment are confirmed first. A button during a countdown-to-send period cancels a not-yet-sent request; it does not undo an already-sent message.

Verification examples

• User side: have the user use the product for five minutes in an environment with bystander interference, and check whether any unintended irreversible action occurs.
• Implementation side: inventory every trigger path for irreversible actions, and check whether any branch reaches commit directly from a single gesture.

CounterexamplesUnder-delivery — waving deletes an email, unrecoverably; over-delivery — even switching songs requires a second confirmation.

G6-2Undo Is ReachableMUST¶

In one sentence: Recoverable changes have a real undo, and undo does not depend on gestures alone; unrecoverable consequences are not falsely presented as undoable.

Applies toproducts where a gesture can trigger a state change.

Rulefor recoverable state changes, the product MUST provide a genuinely effective undo, and the undo path MUST NOT depend on gesture input alone — if recognition is precisely what is failing, the user cannot use a gesture to undo. The duration of the undo window MUST be explicitly defined, and may be set separately by action category. An action that has been committed and is genuinely unundoable MUST be covered by G6-1 before commit; after commit, an undo entry point MUST NOT imply that recovery is possible.

Rule (unknown result and recovery): when an asynchronous operation times out or a receipt is lost, the actual result MUST be verified first; when failure is not confirmed and duplicate effect cannot be guaranteed not to occur, treating a repeated user gesture as a new, identical request and resending it directly is forbidden. Cancelling a not-yet-committed action, undoing an already-effective change, and remedying an external effect MUST be given separate feedback. Undo MUST state its scope, and MUST protect valid modifications made afterward by other users or entry points.

Verification supplement: simulate an action that has taken effect but whose receipt is lost, then repeat the gesture; check whether it takes effect only once. Modify the object through another entry point, then undo the gesture operation, and check whether the subsequent modification is wiped out.

Design applicationplace undo on a non-gesture channel (a physical button, speech, an on-screen control); undo remains usable even if gesture recognition fails completely.

Verification examples

• User side: under degraded recognition quality, have the user undo a mis-operation that just occurred.
• Implementation side: check whether the undo entry point depends on gestures; check whether the undo cue in the interface matches the actual undoable scope.

CounterexamplesUnder-delivery — a false trigger causes a delete, and the undo gesture cannot be recognized either, so the user can only watch it happen; over-delivery — maintaining an unlimited undo stack for every operation, letting performance and storage cost spiral out of control.

G6-3False-Trigger Cost Has a CeilingMUST¶

In one sentence: A single misrecognition's consequence has a ceiling, and repeated false triggers must be detectable and made to converge.

Applies toall products that use mid-air gestures as an input channel.

Rulethe scale of consequence a single misrecognition can cause MUST have an explicit ceiling, recorded as a design decision (quantity, amount, scope of effect, visibility). The product MUST declare a cumulative-impact ceiling for continuous operations, its statistical window, and the over-limit behavior, and this MUST NOT be bypassed by re-entering participation or switching modality. The product MUST have a mechanism for detecting repeated false triggers, and MUST take a converging action once a threshold is reached: raising the recognition threshold, shrinking the gesture set, prompting a modality switch, or pausing gesture input. Leaving the detection and handling of false triggers entirely to the user is forbidden.

Basis and referencesan impact acceptable once may become unacceptable once it accumulates through repetition. Sustained occlusion, interference, or everyday communicative motion can cause clustered false triggers, so both single-instance impact and cumulative impact need to be limited.

Design applicationtreat "the user has undone the same kind of operation three times in a row" as a false-trigger signal, rather than waiting for the user to go into settings and turn the feature off.

Verification examples

• User side: create conditions for sustained false triggering, and observe whether the system converges on its own before the user complains.
• Implementation side: check whether any gesture path can cause large-scale impact in a single instance; check whether the converging mechanism's trigger threshold resolves to a concrete value.

CounterexamplesUnder-delivery — a single misrecognized gesture clears an entire list; over-delivery — a single false trigger permanently disables that gesture, and the user has no idea where the feature went.

G6-4The Confirmation Gesture Does Not Share Its Form with Common GesturesMUST¶

In one sentence: The gesture used for confirmation must be clearly distinct in form from high-frequency gestures.

Applies toproducts that use gestures as the confirmation channel.

Rulethe gesture used to confirm a high-consequence action MUST have a significant formal difference from high-frequency operation gestures (the difference criteria are in G2-3), and MUST NOT be a pose easily formed by accident during everyday activity. The confirmation gesture is forbidden from being a continuation, repetition, or slight variant of a high-frequency gesture — a user can easily arrive at that form naturally within the motion flow of a continuous operation.

Design applicationmake the confirmation action orthogonal to common actions along the motion dimension — if common actions are horizontal, the confirmation should not also be a horizontal variant.

Verification examples

• User side: have the user rapidly perform high-frequency operations in succession, and tally whether confirmation is accidentally triggered.
• Implementation side: measure the confusion rate between the confirmation gesture and its nearest-neighbor high-frequency gesture, and its rate of accidental occurrence in recordings of natural activity.

CounterexamplesUnder-delivery — a one-finger point is select, a two-finger point is confirm-delete, and a slight tremor of the user's hand triggers a delete; over-delivery — the confirmation gesture is designed to be so rare and awkward that the user has to try three times every time.

G6-5Consequence Tier Determines Interaction FormSHOULD¶

In one sentence: Protection strength matches the consequence; a more tiring or slower action does not by itself prove greater safety.

Applies toproducts that include actions at multiple consequence tiers.

Rulean action's consequence tier SHOULD determine the protection strength of its commit path: the heavier the consequence, the more it SHOULD use a clear object preview, explicit confirmation, or a second channel. Increasing dwell duration or motion amplitude does not inherently increase safety, and remains subject to G3's physical budget. Unifying the commit form across all actions for the sake of design consistency is forbidden — unifying toward the low-cost side violates G6-1, and unifying toward the high-cost side makes high-frequency operations unusable.

Design applicationmodel the consequence tier explicitly as a dimension of the gesture set (see gesture.commitment.risk.mapping in the Design Token), letting the interaction form be derived from the tier, rather than decided feature by feature.

Verification examples

• User side: verify the erroneous-commit rate, scope of consequence, and recovery cost at each tier, and measure whether additional confirmation impedes normal tasks; do not use a longer time as proof of greater safety.
• Implementation side: check whether any action has its consequence tier and commit cost inverted relative to each other.

CounterexamplesUnder-delivery — every operation is "point once and it executes," including emptying the recycle bin; over-delivery — every operation applies the highest tier's three-step confirmation, making the product too slow to use.

3.7 G7 Context and Other People¶

Mid-air gestures happen in open physical space: there are bystanders, changing light, occupied hands, and a primary task of driving underway. These are not "edge cases" but the normal usage conditions of this modality. This principle governs the environment the interaction is situated in, and the people in that environment who are not the user.

G7-1A Non-Gesture Path MUST ExistMUST¶

In one sentence: Every feature has an entry point reachable without gestures.

Applies toall products that use mid-air gestures as an input channel.

Ruleevery feature reachable by gesture MUST have at least one reachable path that does not depend on gestures. That path MUST meet the needs of all three situations at once: bodily conditions make gestures unavailable (see G3-5), both hands are occupied, and recognition capability has failed (see G5-5). The non-gesture path MUST NOT be a functionally limited substitute — differing operational efficiency is allowed, missing functionality is not. Gesture input MUST be fully turnable-off by the user, and every feature MUST remain reachable after it is turned off.

Boundary conditionsthis rule's functional equivalence applies to tasks where motion issues a command. When measuring hand motion itself constitutes the essence of the activity (such as a motion assessment), faking an equivalent measurement result with a button is not required; the inapplicable condition MUST be stated, and a usable entry point MUST be retained for entering, pausing, exiting, and accessing results.

Rule (usable alternative): the alternative path MUST be actually usable in the target situation; for example, when both hands are occupied, touch buttons alone are not sufficient to cover that condition. The switching entry point MUST be discoverable and operable when recognition fails, and MUST retain still-valid objects and progress; any part that cannot be continued MUST be explained.

Basis and referencesWCAG 2.5.4 Motion Actuation explicitly covers gestures made toward a camera, requiring alternative controls and the ability to turn it off, and lists exceptions for assistive interfaces and essential activities. It applies directly to the Web; these guidelines' adoption of it for other products is a design requirement, and does not constitute WCAG compliance certification. WCAG 2.5.7 separately requires that applicable dragging functions offer a single-pointer operation that does not require dragging; "just drag with a different hand" cannot serve as the substitute.

Design applicationdesign the non-gesture path as the primary path and treat gestures as an accelerator, not the reverse.

Verification examples

• User side: turn off gesture input entirely, and have the user complete every core task.
• Implementation side: inventory the feature matrix, and check whether any feature is reachable only by gesture.

CounterexamplesUnder-delivery — a particular setting can only be opened through one specific gesture; over-delivery — to guarantee equivalence, every gesture gets a matching button on the interface, and the interface is drowned in buttons (an equivalent path does not require the same entry-point form).

G7-2Capture State Is VisibleMUST¶

In one sentence: Users can know when the sensor is capturing, and this indicator cannot be turned off.

Applies toproducts that use a camera, radar, depth sensor, or microphone array for gesture capture.

Rulewhile the sensor is in a capturing state, there MUST be an indication perceivable to people present, and that indication MUST NOT be turned off by product configuration or the application. The capture range, the category of content captured, and the retention policy MUST be queryable. The retention period for the raw sensory data needed for gesture recognition MUST be explicitly declared, independent of the product's other data-retention policies.

Rule (minimal capture): a feature that can be accomplished by the platform's standard input events MUST NOT additionally request raw images or a full hand skeleton just to achieve the same feature. When such data is genuinely needed, the purpose, where it is processed, the recipient, and the behavior after authorization is declined or withdrawn MUST be stated. Skeleton and derived features are not treated as anonymous merely because images are not saved; retention for diagnostics, personalization, or training MUST be declared separately, and does not inherit permission granted for "this interaction."

Basis and referencesthe privacy and security section of WebXR Hand Input treats hand data as input carrying privacy risk. The minimal-capture and purpose-distinction requirements here are a product design requirement, and do not apply this working draft's API behavior to all devices.

Boundary conditionsthis rule does not require the indication to take a specific form (an indicator light, an on-screen icon, and a physical shutter are all acceptable); what it requires is that it be perceivable to people present and unable to be turned off.

Design applicationa physical-level indication (a hardware-linked indicator light, a mechanical shutter) is preferable to a software-drawn icon — the latter's trustworthiness depends on the software itself.

Verification examples

• User side: have a non-user who is present judge whether the device is currently capturing.
• Implementation side: check whether any configuration path can turn off the indication; check whether the raw data's actual retention period matches what is declared.

CounterexamplesUnder-delivery — a camera stays on permanently with no sign whatsoever that it is capturing; over-delivery — a large privacy banner permanently displayed on screen, obscuring content, and one the user quickly learns to ignore.

G7-3Third Parties Are Not Treated as UsersMUST¶

In one sentence: Passersby do not trigger commands, and are not silently retained.

Applies toproducts whose capture range may cover people who are not the user.

Rulethe motion of a non-user person appearing within the capture range is forbidden from being recognized as a command (ownership determination is in G1-5), and their identifiable personal information MUST NOT be retained without explicit basis. The product MUST declare how it handles a third party entering the capture range. A product deployed in a shared or public location MUST provide, within the deployment environment, a way to make the capture range knowable, so a non-user can know whether they are within capture.

Basis and referencesthis rule's regulatory object differs from G1-5's: G1-5 governs "whose input counts" (a system determination), while this rule governs "what happens when a person who is not the user gets captured" (third-party rights). Getting the former wrong is a functional problem; getting the latter wrong is a rights problem.

Design applicationuse the detection result for a non-user to suppress false triggering (their motion does not count as input), rather than to identify who they are.

Verification examples

• User side: have a second person move around behind the user, and observe whether it affects the interaction.
• Implementation side: check whether data for a non-owning subject enters persistent storage; check whether the capture range can be known by people present in the deployment environment.

CounterexamplesUnder-delivery — someone walking by behind the user waves and switches out what is playing; over-delivery — performing facial recognition and building a profile on everyone present, just to distinguish the user from bystanders.

G7-4Social Acceptability Is Built into the DesignSHOULD¶

In one sentence: Gestures in public do not make the performer feel embarrassed or make bystanders misunderstand.

Applies toproducts that may be used in public or shared locations.

Rulethe amplitude and form of gestures aimed at public or shared locations SHOULD account for the social cost to the performer: users SHOULD NOT be required to make a motion that appears abnormal, conspicuous, or liable to be misunderstood by bystanders in that setting. The same feature SHOULD be allowed different gesture amplitudes in private versus public settings (scenario adaptation is in G7-5).

Basis and referencessocial acceptability is not a comfort issue but a usability issue — a user will not perform a motion that embarrasses them in public, so the feature is effectively unusable, and this will not show up in a lab test.

Design applicationdesign gestures for public settings as small motions close to the body, and reserve large motions for private settings.

Verification examples

• User side: observe, in a real public environment (not a lab), whether users actually use the gesture.
• Implementation side: check whether a smaller-amplitude alternative gesture is provided for public settings.

CounterexamplesUnder-delivery — requiring users to raise a hand above their head and wave on the subway; over-delivery — shrinking every gesture to the public-setting standard, so recognition rate actually drops in private settings.

G7-5Environmental Change Triggers AdaptationSHOULD¶

In one sentence: When lighting, noise, or posture changes, configuration changes with it, rather than one setup for everything.

Applies toproducts whose usage-environment conditions vary significantly.

Rulethe product SHOULD adjust recognition parameters, feedback channels, and the valid gesture set according to environmental conditions (brightness, noise, space size, user posture, whether an object is being held). The trigger conditions and content of adaptation SHOULD be predefined and perceivable to the user; changing a gesture's semantic mapping without the user's knowledge is forbidden (see G2-2) — adjusting parameters and adjusting semantics are two different things.

Design applicationenvironmental adaptation SHOULD act on thresholds, feedback channels, and the size of the gesture set, not on gesture meaning.

Verification examples

• User side: switch between light/dark and quiet/noisy conditions, and observe whether the user needs to change how they operate, and whether they are informed.
• Implementation side: check whether adaptation changes any gesture's semantic binding.

CounterexamplesUnder-delivery — usable during the day, completely unusable at night before the lights are turned on, with no notice; over-delivery — switching the entire gesture set at the slightest environmental change, so the user never knows which gestures are currently valid.

G7-6Does Not Compete for Attention with Safety-Critical TasksMUST¶

In one sentence: In scenarios such as driving, gestures MUST NOT require looking at a screen or disengaging from the primary task for an extended time.

Applies toproducts used in safety-critical scenarios such as driving, operating machinery, or medical procedures.

Rulethis rule protects the ongoing safety-critical primary task, and constrains the secondary gesture task that competes with it for attention. Within this scope, gesture interaction is forbidden from requiring the user to move visual attention away from the primary task, forbidden from requiring both hands to disengage from primary-task control at once, and forbidden from requiring a posture to be held beyond a brief duration. Feedback in such scenarios MUST include a non-visual channel (see G4-4). The available gesture set MUST be restricted to what can be completed without visual confirmation; "a target must be selected" does not constitute a blanket prohibition — the criterion is whether that selection diverts resources the primary task needs (in a setting such as image interpretation, where the primary task is itself visual, selecting a target may not take attention away from the primary task at all). When a gesture directly carries the control of the safety-critical primary task itself, this is not the secondary-task situation covered by this rule: it MUST instead be handled by that domain's dedicated interaction design and functional-safety assessment, and these guidelines do not use "having non-visual feedback" as proof of applicability. When recognition fails, requiring the user to keep retrying is forbidden; the retry ceiling and degradation conditions MUST be determined by the domain assessment. When it cannot be shown that retrying is acceptable, no additional retry is added; instead, fall back to an assessed, usable alternative or defer the secondary task (see G5-5).

Boundary conditionswhat this rule specifies is a necessary condition on interaction form; it does not substitute for that domain's distraction assessment, functional safety, or regulatory compliance work — those have their own measurement methods and limits, and this rule gives no specific duration threshold. Non-visual does not equal no cognitive load; the complete task and the effect of failure recovery on the primary task SHOULD be assessed. The U.S. NHTSA official guidance document catalog can locate visual-manual distraction test procedures, but this guidance is voluntary and cannot directly serve as certification for every jurisdiction or for mid-air gestures.

Design applicationas a secondary task, prioritize a small number of coarse-grained motions that do not require moving gaze away from the primary task; whether target selection is allowed is judged by the complete task's effect on primary-task attention.

Verification examples

• User side: measure the number and duration of gaze departures from the primary task, and the change in primary-task performance, under simulated primary-task load.
• Implementation side: check whether any gesture path requires visual confirmation to complete; check the failure-retry policy.

CounterexamplesUnder-delivery — a gesture menu while driving requires aiming at an option on the center console screen; over-delivery — providing a lengthy spoken explanation to replace the visual menu, which, although it does not require looking at the screen, still continuously occupies primary-task attention.

---

4. Terms and Definitions¶

---

Appendix A: Fault-Injection Verification Checklist¶

For rules involving recognition reliability and environmental conditions, the verification method is fault injection: create scenarios that would break the commitment, and a failed test means the corresponding commitment has failed. A candidate rule for which such a test cannot be written should not enter these guidelines. The table below is an example subset, not an exhaustive checklist. The numbers are fault-injection samples, not release thresholds; high-consequence actions are verified only in a sandbox, a simulator, or on test objects.

The last row cannot be omitted: otherwise a product might pass every anti-false-trigger test and still be too slow for anyone to want to use. Besides fault injection, classification (whether different reviewers can independently arrive at a similar attribution for a specific requirement) and user value (whether false triggering actually drops, whether the task actually completes faster) SHOULD also be verified separately; the three cannot substitute for one another. Coverage SHOULD also be checked with a complete task walkthrough — running a real case through "approach, enter interaction, discover available gestures, execute, correct errors, leave," checking whether any important design requirement has nowhere to be attributed.

---

A.1 Metrics and Release Records¶

Thresholds are predefined by the target product; the table below gives the measurement basis, not universal numbers, and does not constitute a set of acceptance criteria already validated with users.

Consumed Endurance (CHI 2014, author institution page) offers a method for estimating arm fatigue based on postural load; NICE (2023, author institution abstract) re-examines CE's applicability. Both serve as measurement-method references, and cannot substitute for target-user testing.

Each verification record includes the device, SDK, a snapshot of the actual configuration, the task and user sample, the environment, the preset threshold, the actual result, inapplicable items, and the responsible owner. After a change to the recognizer, vocabulary, input routing, or default configuration, re-verify the affected journeys; do not use overall recognition accuracy alone as the basis for release.

---

A.2 Acceptance Records and Pass Conditions¶

Each applicable obligation is recorded separately: rule clause → scenario and preconditions → injected event → expected state and consequence → user-visible feedback → measured evidence → conclusion and owner. The conclusion is pass, fail, or not applicable (with a reason attached); not executed does not count as pass. When a "SHOULD" clause is deviated from, attach the reason and alternative verification; a hard-constraint failure is not offset with an aggregate score.

Statistics on false triggers during natural activity MUST report exposure time, number of participants, environmental stratification, and uncertainty, and MUST NOT claim zero risk directly from zero events. Latency measurement notes the sampling event, the clock-alignment method, and the endpoint; logs retain only the facts needed to demonstrate the behavior, and do not default to recording the complete sensory stream. When the facts supporting a judgment are insufficient, a dependency is missing, or a hard constraint fails, the affected capability is restricted or disabled; evidence holds only for the devices, input models, users, and task scope actually tested.

---

Appendix B: Argumentation Boundaries and Scope of Applicability¶

B.1 Criteria for Constraint Words¶

The sole basis for marking something "MUST" is necessity: without this requirement, some commitment the product makes to the user will fail under foreseeable conditions. Judging a rule uses three types of argument:

Only a rule whose necessity argument holds is marked "MUST"; a rule that satisfies only quality or efficiency is downgraded to "SHOULD" or removed from these guidelines entirely. Specific recognition algorithms, sensor selection, and performance engineering do not enter these guidelines.

B.2 Scope of Applicability and Known Weaknesses¶

The scope of these guidelines is: interactive products that use hand or upper-limb mid-air motion as one of their input channels, covering headsets, in-vehicle, large-display, public-terminal, home-appliance, and industrial scenarios. It does not cover: gesture-recognition algorithms and sensor engineering; standardization of gesture form itself (see the ISO/IEC 30113 series and ISO/IEC 14754); dedicated accessibility assessment; privacy and data-protection compliance; the measurement and limits of in-vehicle distraction; and functional safety and domain regulation. G7-6 specifies a necessary condition on interaction form, and gives no duration threshold — that belongs to domain-specific work.

Three weaknesses are honestly stated:

1. These guidelines give no specific numeric threshold anywhere. Dwell duration, latency budget, confidence threshold, and interaction-zone size are all written as "MUST be explicitly declared and verified," rather than given as numbers. The reason is that these values depend strongly on the sensing approach, usage distance, user posture, and scenario; existing material is insufficient to support a unified number across products, and vendor values cited are tied to specific hardware and input models (see reference.md). This is a deliberate trade-off, at the cost that these guidelines cannot be used directly as an acceptance checklist — the values MUST be determined by each product on its own and incorporated into the Design Token.

2. The failure arguments are mainly foreseeable counterexamples, platform warnings, and scenario research. No first-hand post-mortem sufficient to support attributing a project failure has been obtained; a product's withdrawal from market is not attributed to any single interaction flaw, and a simulated counterexample is not written up as an incident that actually occurred. Sources and the scope read are in reference.md.

3. These guidelines' division of principles has not been tested by outside reviewers' classification. Mutual exclusivity and exhaustiveness remain claims yet to be tested. Two known high-risk boundaries: the division between G1-5 (input ownership) and G7-3 (third-party handling), and the division between G4-5 (boundary perceivability) and G5-4 (informing about recognition conditions). If attribution disagreement recurs at these two boundaries in actual review, the division of principles SHOULD be adjusted rather than adding more cross-references.

B.3 Issues Pending Verification¶

The following issues still need to be checked with a complete task walkthrough, and are not treated as independent rules:

• Cross-product gesture-set consistency: existing platform conventions and conflict re-checking are already carried by G2-3 and G2-4; existing material is insufficient to support a unified gesture dictionary across all platforms.
• Simultaneous multi-user feedback: for now, carried jointly by G1-5 and G4-1. It becomes an independent obligation only in products that explicitly support simultaneous multi-person interaction.
• External visibility of a false trigger's consequence: for now, carried by G6-3's consequence ceiling. When a walkthrough finds this insufficient, upgrade it per Appendix A's classification test.

External source cross-references are in reference.md in the same directory.

---

Implementation Acceptance Scenarios¶

The scenarios below turn existing clauses into reviewable acceptance input, and set no additional universal performance threshold. Select according to the product's applicable capabilities, and supplement with real devices, users, input sequences, and evidence; record the reason when not applicable, and not executed MUST NOT be recorded as passed.

Each scenario separately checks the configuration's effective values, the execution record, and the user-comprehensible result. Version, target, event timestamp, failure scope, and recovery result are retained; an unknown external result is not filled in as success or failure.