Eye-Tracking Interaction Design Guidelines

For designers and engineers: let "looking" remain looking, and let "selecting" truly be selecting; let users know where the system believes they are looking, what the system did based on that, and where that data goes — and let them still complete tasks when they cannot or do not want to use their eyes.

Eye tracking enters a product through two paths: the explicit path — treating gaze as a pointing channel, completing selection through dwell or gaze paired with gesture or speech; and the implicit path — treating gaze as an attention signal, used for render optimization, content ranking, reading measurement, driver monitoring, and cognitive-load assessment. The two paths regulate different design objects and carry different risks, but share the same set of premises:

1. The eye is first a sensory organ, and only secondarily an input device. As long as the eyes are open and observing, gaze signals may be continuously generated; they cannot be treated as an operation by default. The Midas Touch problem, gaze fatigue, and the "fleeing cursor" all derive from this premise, rather than being independent defects each.
2. The measurement of gaze position is probabilistic, and degrades over time. Accuracy is affected by calibration quality, wearing-position changes, lighting, pupil size, and fatigue. The deterministic assumption of traditional interfaces — "clicking the target hits the target" — does not hold here.
3. Gaze and related eye data may support inferences about interest, cognitive state, identity, or health indicators, but this does not mean these states can be reliably read. Privacy is not an appendix to these guidelines; it is an independent object of regulation.

These guidelines consist of six principles and 31 rules: principles state the design direction; rules specify applicability conditions, behavior requirements, and verification methods. Each rule belongs to one and only one principle, and the rule number is the principle number (E3-2 is the second rule under the third principle). Each rule answers three questions: what the designer decides, what facts engineering provides, and how the user knows it is in effect.

These guidelines govern the nature of the experience commitments a product makes to users and the mechanisms that honor them; they do not presuppose a single hardware solution, algorithm, or SDK. They are not a component library, not an implementation architecture, and do not constitute proof of safety, privacy, or medical-device compliance. Adopting these guidelines cannot replace a dedicated accessibility evaluation, a Data Protection Impact Assessment (DPIA), human-factors testing, domain compliance for medical and driving scenarios, or dedicated review of monitoring minors and workplace surveillance.

These guidelines do not cover: eye tracking as a research method (heatmaps and gaze-trajectory analysis in usability testing) — its measurement methods must be selected according to the research question; ISO 15007 and SAE J2396 address only driver visual behavior and cannot be generalized to usability research at large; nor do they cover the algorithmic implementation of eye tracking (pupil-corneal reflection, appearance models, calibration algorithms).

Four chapters in all: Chapter 1 principles, Chapter 2 how to read the rules and a quick reference, Chapter 3 rules in detail, Chapter 4 terminology; classification checks and acceptance are in Appendix A, numeric bases in Appendix B, and the status and factual contract of selection attempts in Appendix C. For configurable parameters see Design Token.md in the same directory; for sources and verification level see reference.md.

This document is used for design delivery and project review; [MUST] indicates a product requirement of these guidelines, not that the cited vendor, paper, or law imposes a requirement of the same strength.

---

Entry point and scope of application¶

First determine what job eye tracking performs in the product, then select rules and parameters; do not infer "every element can be selected by looking" directly from "the device supports eye tracking."

A product may contain multiple forms, but each capability must have a clear home. For parameters see Design Token. Items that do not apply must state the reason; "not holding raw data" cannot exempt an application from the submission and feedback behavior it itself controls.

1. The six principles¶

The six principles divide design responsibility by object of regulation: each principle governs obligations on one class of object, and each rule is assigned to exactly one principle according to the direct object of regulation of its obligation.

A single scenario can touch multiple principles — one dwell activation involves the trigger mechanism (E2-2), hit-testing (E3-1), and progress acknowledgment (E4-3) at once — this is not a classification error: the three rules constrain obligations on three different objects of regulation.

Mutual exclusivity and exhaustiveness are claims this division submits to testing, not facts established by declaration: when a rule is added, removed, or its home is in doubt, verify using the classification checks in Appendix A; if the check fails, what gets revised is the principles' division, not the addition of an intermediate layer or a mapping table.

Principles are used to understand the rules and adjudicate their home; they are not themselves a separate judgment item. When a principle's reading conflicts with a specific clause, the applicable clause governs, and the ambiguity needing clarification is recorded.

2. How to read a rule¶

2.1 The structure of each rule¶

The rule text specifies the requirement; Applies to and Boundary conditions together bound the requirement's scope; Design application, verification examples, counterexamples, and basis/references add no further obligation.

2.2 Normative terms¶

• MUST: failing to satisfy it means non-conformance with these guidelines. Without it, some commitment to the user will fail under foreseeable conditions.
• MUST NOT / forbidden: the negative form at the same strength as "MUST"; "MUST NOT" and "forbidden" are used equivalently in the main text.
• SHOULD: followed by default; when there is genuine reason to deviate, record the rationale and the alternative, and accept the same verification. "SHOULD NOT" is the negative form of "SHOULD."

Conformance judgments take the independent obligation clauses in the main text as their unit; text without an explicit normative term carries the strength of the rule heading: a "forbidden / MUST NOT" clause inside a [SHOULD] rule remains a hard constraint. "cannot" in the main text is used only for statements of capability or fact, and expresses no obligation.

Every numeric threshold appearing in the main text of these guidelines carries a unit and has its source and verification level noted in Appendix B. A value without a noted source MUST NOT be used as a conformance criterion — it is an example, not a requirement.

2.3 The two sides of a counterexample¶

Counterexamples come in two sides: "under-delivery" means missing this requirement; "over-delivery" means piling on confirmations, feedback, and toggles in order to satisfy it. Neither side counts as getting it right.

Eye-tracking interactions tend to go wrong in a way heavily concentrated on "over-delivery": because the user is always looking, any feedback triggered by gaze will be triggered far more often than the designer expects. A highlight effect that looks "just right" in a prototype becomes continuous flickering after twenty minutes of sustained use. During review, treat this side as the default suspect.

2.4 Rule quick reference: 31 rules¶

E1 Gaze is not intent

E2 Activation matches error cost

E3 Accuracy is bounded and degrades

E4 Feedback is restrained and attributable

E5 Gaze data is visible and controllable

E6 The channel is exitable and non-exclusive

---

3. Rules in detail¶

3.1 E1 Gaze is not intent¶

The eye's primary function is gathering information. Translating a gaze signal into user intent is an inference made by the system, not an expression made by the user. This principle governs that layer of translation: when translation is permitted, how much effect the translated result carries, and what happens when the translation is wrong.

E1-1Observing state and controlling state are distinguishableMUST¶

One-line summary: Let the user look without selecting at any time, and know which state they are currently in.

Applies toany interface that uses gaze as a selection or activation channel.

RuleThe product MUST have a state in which the user can freely observe without triggering any selection, activation, or external effect, and the user MUST be able to determine whether they are currently in the observing state or the controlling state. Entering the controlling state MUST be decided by a condition the user can perceive — an explicit signal, a clear region boundary, or a declared mode switch; using "gaze duration exceeding some value" as the sole boundary between the observing state and the controlling state is forbidden, unless that activation falls into the lowest-cost tier permitted by E2-1. A gaze candidate MUST NOT seize keyboard focus, the text insertion point, or assistive-technology focus merely because the gaze moved; taking over requires an explicit initiating action.

Boundary conditionsThis clause does not require making the observing state a standalone interface mode or a global switch. A region-level division (gaze-activatable areas versus pure-reading areas) or an object-level division (only objects explicitly marked participate in gaze activation) both satisfy the requirement, as long as the user can tell.

Design applicationPlace content meant purely for viewing — long text, images, video — in a region excluded from gaze activation; visually distinguish objects that can be gaze-activated from it. A cross-modal scheme may use an explicit signal to enter the controlling state, but must still verify the moment of pointing, object binding, and the absence of side effects while observing; it is not judged as satisfying the requirement merely because it uses another channel.

Verification examples

• User side: let the user read freely in the interface for two minutes, count unintended activations; ask whether they know "when they will trigger something."
• Implementation side: check whether a path to an irreversible action exists in the observing state; check whether the exclusion-region determination breaks when the layout changes.

CounterexamplesUnder-delivery — the entire screen is dwell-activatable, and the user jumps to a new page just by reading a paragraph of instructions; over-delivery — a manually toggled "gaze-control mode" master switch is required, so every time the user wants to click something they must first go turn on the switch, and the switch itself must be clicked with the eyes.

E1-2Gaze does not constitute authorization or informed consentMUST¶

One-line summary: Having looked does not equal having agreed, nor does it equal having read, understood, or been informed.

Applies toany interface involving authorization, consent, a duty to inform, read confirmation, disclaimers, or risk notices.

RulePassive viewing, gaze coverage, or a candidate event produced without an explicit confirmation process are forbidden from serving as evidence that the user has consented, read, been informed, or understood; it is forbidden to reduce, simplify, or skip a confirmation that should be completed by an explicit action, on the grounds that "the user's gaze passed over that area." Gaze may serve as a product metric of whether the line of sight fell within the presented area, but MUST NOT serve as the judgment basis for whether the user bears the corresponding informed consequence.

A confirmation action completed through an active, staged confirmation process that meets the boundary conditions of E2-1 may serve as a record of the user's decision on that specific request — such a record must retain the request, decision, object content, and confirmation method, stored separately from raw samples and candidate hit records and managed under E5; but it only proves the user performed the confirming action, and MUST NOT be used to claim the user understood all the content. When the request or object content is replaced, the old confirmation becomes invalid.

Boundary conditionsThis clause does not forbid using gaze signals to improve disclosure design — for example, re-presenting a key clause when the user is detected not to have looked at it. The distinction is one of direction: using gaze to reinforce disclosure is allowed; using gaze to replace confirmation is forbidden.

Design applicationWhere confirmation is required, keep a confirming action distinguishable from passive viewing (assistive-technology exception, see E2-1); if a product uses gaze to measure reading coverage, keep it in internal metrics and out of the user's rights-and-obligations chain.

Verification examples

• User side: have the user's gaze pass over an authorization notice without taking any action; verify the system still requires explicit confirmation.
• Implementation side: audit the write paths for states such as "read," "informed," and "consented," confirming none has a gaze event as its sole source.

CounterexamplesUnder-delivery — the user's line of sight passes over the privacy clause area for three seconds, and the system records "read and agreed"; over-delivery — for fear of being mistaken for evidence of being informed, the product collects no reading metric at all, losing the ability to discover that "no one looked at the critical notice."

E1-3Implicit use does not change task stateMUST¶

One-line summary: Attention-driven adaptation may change presentation; it MUST NOT change outcomes or produce external effects.

Applies toall implicit features that use gaze as an attention signal — foveated rendering, content ranking, dynamic prompts, reading metrics, driver/operator state monitoring.

RuleThe scope of any adaptation automatically triggered by a gaze signal MUST be confined to the presentation layer: rendering precision, layout emphasis, prompt timing, content ordering. It is forbidden for a gaze signal not explicitly confirmed by the user to directly submit a business decision or produce an unauthorized external effect — including irreversible actions, outbound sending, payment, and writes to persistent business state. A necessary measurement record made for a disclosed purpose and governed by E5 (reading coverage, hit logs) is not automatically forbidden by this clause merely for being a "data write"; but such a record MUST NOT be repurposed as evidence of the user's confirmation or consent (see E1-2). When the output of an implicit feature enters a decision chain affecting the user (for example, a fatigue determination triggering an alert or intervention), that output MUST be separately authorized per E5-3 and handled per E5-6.

Boundary conditionsIntervention in safety-critical scenarios is an exception, but the exception must be explicit: a driver-monitoring system that issues an alert on detecting closed eyes is a safety commitment of the product, SHOULD be stated in the capability disclosure, and its criteria, false-alarm rate, and the actions available to the user must be declared in advance; this exception MUST NOT be extended to non-safety purposes.

Design applicationSeparate "using gaze to adjust presentation" from "using gaze to trigger an action" at the architectural level — the former may run continuously, while the latter MUST go through the trigger mechanism in E2.

Verification examples

• User side: browse freely in a list with attention-based ranking enabled; verify that browsing does not submit a business decision; check any necessary measurement within the disclosed scope separately.
• Implementation side: trace all write operations of implicit features, distinguishing necessary measurement from business writes; confirm no unauthorized side effect exists; verify any declared monitoring branch under its applicable conditions.

CounterexamplesUnder-delivery — the user looked at a product for two extra seconds, and the system added it to the cart; over-delivery — out of fear of overstepping, even purely presentational optimizations like foveated rendering require the user's authorization every single time.

E1-4Gaze-intent inference is correctableSHOULD¶

One-line summary: When the system guesses what you want to select, there SHOULD be a correction path that does not require repeating a difficult hit.

Applies toproducts that use probabilistic hit-testing, intent prediction, or gaze-trajectory anticipation to select a target.

RuleThe system's judgment of "which object the user wants to operate" SHOULD be presented as a correctable hypothesis, and SHOULD provide a correction method that does not depend on repeating the same difficult gaze; when another channel is available, non-gaze correction SHOULD be preferred. When gaze is the only channel available, magnification, staged disambiguation, or an independent undo region MAY be used. When the confidence between candidate targets is insufficient to distinguish them, the system SHOULD request disambiguation or make no selection, and SHOULD NOT default to the nearest candidate and execute directly.

Basis and referencesCorrecting a gaze error within the gaze channel itself forms a closed loop of difficulty — the user looks away to change their selection, and that very movement triggers a new determination. This is another manifestation of the same problem as the dual role of "observing vs. controlling" (see E1-1).

Design applicationWhen another channel is available, correct with gesture, key press, or speech; when gaze is the only channel available, provide magnification, staged disambiguation, or an independent undo region, avoiding making the user redo the original difficult hit.

Verification examples

• User side: construct two adjacent, similar targets; have the user reselect after the system picks wrong, recording reselection time and second-error rate.
• Implementation side: check whether a disambiguation path exists and does not require repeating the original precise hit; check the default behavior when confidence is insufficient.

CounterexamplesUnder-delivery — after a wrong pick, the only recourse is to stare at the correct target and dwell again, and this time it picks the adjacent one instead; over-delivery — every selection first pops up "did you mean A or B," turning what could be a direct selection into two steps.

E1-5State inference is evidence-based and allows "unknown"MUST¶

One-line summary: Eye-tracking metrics are not a direct readout of mental state; when evidence is insufficient, output unknown.

Applies tofeatures that infer user interest, load, emotion, fatigue, or health state from metrics such as gaze, pupil, or blink.

RuleThe product MUST distinguish the measured metric from the inferred state, state the population, task, and environment for which the inference applies, and verify the error rate with an independent reference. Gaze duration alone or a single pupil-size change MUST NOT be used to claim the user has understood, likes, is anxious, or is cheating. When data is insufficient, conditions fall outside the validated range, or an unremovable confound is present, the system MUST allow outputting unknown or suspending inference; absence of data MUST NOT be recorded as inattention. See E5-3 for authorization requirements and E5-6 for restrictions on use in evaluation.

Basis and referencesPupil response is influenced simultaneously by brightness, near-viewing distance, and mental activity; inferring a single state from a metric is ambiguous (Mathôt, 2018). The rejection and subgroup-verification requirements in this clause are a design inference based on this measurement boundary.

Design applicationSeparate "insufficient valid gaze coverage on this segment" from "you were not reading carefully"; control for brightness and content difficulty in evaluation, and report the model's performance on unseen users.

Verification examples

• User side: change only the screen brightness, and check whether the system directly interprets the pupil change as an emotional change.
• Implementation side: replay missing data and inputs outside the validated conditions, confirming the output is unknown; record false-positive, false-negative, and unknown rates — do not show only overall accuracy.

CounterexamplesUnder-delivery — the user looking away is recorded as low attentiveness; over-delivery — every instance of low confidence turns into a questionnaire the user must answer.

3.2 E2 Activation matches error cost¶

The mechanism between "the system believes the user is looking at X" and "the system performs an action on X" is the object this principle regulates. E1 governs whether gaze can be treated as intent at all; this principle governs, once an action is decided, what method triggers it and how its parameters are set.

E2-1Trigger method is tiered by error costMUST¶

One-line summary: An irreversible action MUST NOT be triggered by a single passive dwell.

Applies toall actions triggered with gaze participation.

Rule (configuration takes effect): Each selection attempt is bound to the configuration snapshot resolved at the moment it begins. When a parameter affecting hit-testing, dwell criteria, or the action's risk tier is modified while an attempt is in progress, retroactively converting samples already accumulated into an activation is forbidden: the product must declare one of two behaviors — cancel the current attempt and require it to be reinitiated, or let the old attempt finish under its still-valid original configuration while the new attempt uses the updated configuration. A tightening of disabling, deauthorization, or risk protection intercepts an affected attempt first. A change to a presentation-only setting MUST NOT be converted into a user's business confirmation.

RuleThe product MUST define error-cost tiers for gaze-activatable actions, distinguishing at minimum: reversible and low cost, reversible but high cost, and irreversible or producing an external effect. An action that is irreversible or produces an external effect is forbidden from being triggered directly by a single passive dwell or gaze entry; it MUST require a confirmation signal independent of the eyes (gesture, key press, speech, controller; for eye-tracking-only availability, see the boundary conditions below), and cancellation MUST be allowed before submission. Having a cancellation window is not grounds for waiving confirmation. Reversible-but-high-cost actions SHOULD likewise use explicit activation. The mapping between tiers and trigger methods MUST be declared in advance and MUST NOT be decided ad hoc, screen by screen.

Boundary conditionsIn assistive scenarios where eye tracking is the only channel available, a specially validated staged confirmation MAY be provided: first select and present the specific object and its consequence, end the original dwell, then have the user reinitiate an independent confirmation step, while providing a reachable cancellation path. Reusing the same timer, or letting a newly appearing confirmation button inherit the old target's charge, is forbidden; merely extending the dwell does not satisfy this exception. This exception is an inclusive-design proposal of these guidelines and must be validated with false-confirmation testing on target users; it does not represent a platform-guaranteed reliability.

Basis and referencesTobii's XR interaction design documentation states plainly that gaze paired with an explicit activation signal is the most predictable and controllable interaction state, and for high-error-cost elements it is in most cases better than gaze entry or dwell activation; Microsoft's HoloLens 2 guidelines likewise recommend triggering selection with a voice command, gesture, key press, or extended dwell rather than reacting directly to gaze. Both support separating pointing from submission, but neither jointly prescribes this guideline's risk tiering and prohibition scope; the latter is a design inference of these guidelines (see reference.md §1, §9).

Design applicationWrite the tier mapping into the design system rather than deciding it screen by screen; the trigger method for a given tier is consistent across the whole product, so that user expectations transfer.

Verification examples

• User side: for every irreversible action, verify whether passive browsing can accidentally complete it; eye-tracking-only assisted confirmation must additionally test the staged process.
• Implementation side: audit the list of trigger paths, confirming irreversible tiers comply with independent confirmation or a declared assistive-confirmation exception, and that the object and consequence are not swapped after confirmation.

CounterexamplesUnder-delivery — "delete all" and "expand list" are triggered by the same 800ms dwell; over-delivery — even a one-step, reversible action like switching tabs requires "gaze + voice confirmation," and the user has to say a dozen sentences to complete one browsing session.

E2-2Dwell activation is abortable and shows progressMUST¶

One-line summary: Dwell can be reconsidered at any point before completion, and the user can see how much remains.

Applies toany interaction that uses dwell as its trigger.

RuleDwell triggering MUST provide feedback indicating progress, so the user knows charging is underway and roughly how much remains before activation occurs; gaze leaving the target MUST immediately stop accumulation, and reaching the declared tolerance time limit while away MUST reset it to zero, and the cancellation MUST be perceptible to the user. Within the tolerance window, progress may only be frozen, and it may only resume when returning to the same object with content and action both unchanged; time spent away MUST NOT be counted toward dwell. After resuming, at least a new valid-dwell interval is required — the first sample after resuming MUST NOT backfill the interruption or submit directly. Dwell duration MUST be configurable and chosen according to the target user population, tracking performance, and error cost; it MUST NOT be forced as an unadjustable hardcoded value for all users and situations; validated similar targets MAY share a preset. The product MUST declare the dwell duration used and its basis.

Boundary conditionsThis clause does not require dwell progress to be shown as a circular progress ring, nor does it forbid using different durations for different tiers within the same product. What it requires is "charging is visible" and "leaving stops it immediately"; it does not prescribe the form of presentation.

Basis and referencesPenkar et al.'s experiment jointly examined dwell time, button size, and reading content position, showing these parameters need to be tested together (see reference.md §4.2). Dwell time is validated together with layout, not adopted as a uniform duration across products.

Design applicationProvide a setting to shorten dwell duration for proficient users; lengthening the duration for high-error-cost targets is not a good approach (Tobii's guidelines note that an overly long dwell feels tense and unnatural) — use E2-1's explicit activation instead.

Verification examples

• User side: have the user look away when charging is half complete, verifying activation is canceled and the user perceives the cancellation.
• Implementation side: check whether the dwell timer pauses or resets on tracking loss (E3-3), rather than continuing to accumulate.

CounterexamplesUnder-delivery — with no progress indication at all, the user only knows "staring long enough triggers something," so they avoid dwelling the whole time; over-delivery — every gaze-eligible object continuously displays a spinning progress ring, and the entire interface looks like it's breathing.

E2-3Multimodal activation binds at the initiation momentMUST¶

One-line summary: Bind the object at the declared initiation event; do not let recognition latency turn A into B.

Applies toactivation methods that combine gaze with gesture, speech, key press, or a controller.

RuleWhen the activation signal comes from another channel, the system MUST use the gaze target at that signal's initiation moment (or within a declared time window before that moment) as the object acted on; it MUST NOT use the gaze target at the moment recognition of the signal completes. This time window MUST be explicit and compatible with the typical recognition latency of the signal used; it MUST NOT trace back indefinitely to an earlier gaze target. The cross-channel timing-alignment requirement MUST also hold in custom input controls. The product MUST specify which event represents initiation (such as pinch start, a key event, or the segment of speech that points to the object), and use an alignable time base; the start of an entire speech utterance MUST NOT be uniformly treated as the pointing moment. When a sample has expired, the timestamp is unknown, the object content has changed, or the object cannot be uniquely determined, the activation MUST be canceled or disambiguation requested, and a correction path that does not depend on repeating a difficult hit MUST be retained. When a platform already provides the binding result, the product SHOULD reuse it directly rather than requiring the application to separately collect raw gaze.

Basis and referencesThis is an independently documented failure mode; Microsoft's HoloLens 2 guidelines call it "leave before click" — research shows that during rapid target selection, a user's gaze moves away before the manual click completes. Voice-command recognition latency makes this offset larger (see reference.md §1).

Design applicationKeep a gaze-history buffer in the input pipeline, and when the activation signal arrives, look back and take the value by its timestamp; for custom gestures, record the start moment or approximate duration rather than reporting only the recognition result.

Verification examples

• User side: have the user select multiple adjacent targets in sequence at a natural pace, tallying the agreement rate between the selected object and the user's reported intended object.
• Implementation side: inject a voice signal with artificially extended recognition latency, verifying the object acted on is still the gaze target at the initiation moment.

CounterexamplesUnder-delivery — the user looks at A and says "delete"; voice recognition takes 700 ms, during which the gaze moves to B, and the system deletes B; over-delivery — to align timing, every interaction is delayed to respond only after the longest possible latency, making the whole interface feel sluggish.

E2-4Mis-trigger suppression and repeat-activation controlMUST¶

One-line summary: Blinks, saccades, jitter, and repetition MUST NOT be read as activation.

Applies toall gaze-activation channels.

RuleThe system MUST suppress the following signals from being judged as activation: a gaze interruption during a blink, a saccade passing through a target, a brief dwell below the gaze-determination threshold, and repeated jumping between targets caused by tracking jitter. After activating a given target, a re-activation threshold MUST exist, preventing continuous repeated activation caused by gaze not having moved away. An ordinary button MUST wait for a valid departure and re-entry, or obtain a new explicit initiation signal; the mere end of a timed cooldown MUST NOT itself trigger the next submission. Step controls that genuinely require sustained looking to repeat MUST separately declare their repeat mode, pacing, and stop condition. A single selection attempt MUST NOT be submitted repeatedly due to event replay, dual-channel callbacks, or a delayed result. Suppression parameters MUST be compatible with the sampling rate and accuracy of the device used, and MUST be configurable. A declared and validated active blink-coding scheme is handled as the assistive exception in E2-5, and is not conflated with a natural blink interruption.

Design applicationConfigure the minimum stable gaze-determination duration, saccade-velocity threshold, and blink-tolerance window separately (see Design Token §3); after activation, actively remove the target from the activatable set until gaze leaves and returns.

Verification examples

• User side: have the user browse a row of activatable objects at a normal pace, tallying mis-activation count; have the user blink normally ten times, verifying no activation occurs.
• Implementation side: replay gaze data containing saccades, blinks, and tracking jitter, checking whether the activation-event count is zero.

CounterexamplesUnder-delivery — the user blinks once, the interface judges the gaze as interrupted and then re-entered, and the dwell timer resets or directly triggers activation; over-delivery — the suppression window is too long, and the user's deliberate second selection gets swallowed, forcing them to wait two seconds and try again.

E2-5Unnatural eye movements are not mandatedSHOULD¶

One-line summary: Do not require the user to draw symbols with their eyes to issue commands.

Applies toproducts where gaze is the primary interaction channel.

RuleThe product SHOULD NOT require the user to perform unnatural eye movements (directional eye gestures, deliberate prolonged staring, blink coding) as a necessary condition for completing the primary task. Such interactions MAY be offered as an optional acceleration method, but MUST NOT be the only path.

Boundary conditionsThis clause does not apply to heavy-assistive scenarios where gaze is the only available channel — for users who have completely lost other motor abilities, blink coding and eye gestures may be a feasible means of communication, in which case they are not a "mandated unnatural movement" but the only means of expression. The distinguishing factor is whether the user still has another channel available.

Basis and referencesMicrosoft's HoloLens 2 guidelines directly give the recommendation "avoid forcing unnatural eye movement as input" (see reference.md §1). Deliberate eye movement accelerates visual fatigue and conflicts with natural behaviors such as reading and observing.

Design applicationReserve eye gestures as a shortcut for proficient users; use the primary path of gaze plus an explicit signal, or dwell.

Verification examples

• User side: verify that every primary task can be completed without using any eye gesture.
• Implementation side: check whether the feature list contains a capability exposed only through an eye gesture.

CounterexamplesUnder-delivery — going back a level requires "looking quickly left twice"; over-delivery — to avoid eye gestures entirely, all shortcut operations are removed, and heavy users lose their means of efficiency.

E2-6Activation is bound to its object and operation meaningMUST¶

One-line summary: When layout and content change, stale dwell progress MUST NOT trigger a new action.

Applies togaze interfaces involving scrolling, animation, asynchronous loading, list reuse, content reordering, or moving targets.

RuleDwell progress and cross-modal confirmation MUST be bound to the specific object, the input source, and the operation meaning at the time, not merely to screen coordinates or a list index. When the target is replaced, occluded, disabled, moved out of the active interaction layer, or the action's consequence changes, the selection MUST be canceled or re-acquired validly; the progress of an old target MUST NOT be transferred to a new target. When the input source switches or the coordinate space is repositioned, the affected attempt MUST be canceled and quality and geometry re-verified. When the same object moves, the product MUST declare a pause, reset, or validated following strategy, and judge it against the scene geometry corresponding to the sample; a hit MUST NOT be assembled by combining an old gaze sample with a new layout.

Basis and referencesApple documents that a close button suddenly appearing on hover can draw the gaze and cause accidental dismissal (WWDC25). Binding the object to the operation meaning is this guideline's engineering inference for this class of failure, not a requirement in the original API documentation.

Design applicationKeep list updates on a stable object identity; freeze local content that would change the operation's meaning during confirmation. There is no need to freeze the entire interface, nor to retain gaze trajectories long-term.

Verification examples

• User side: insert a row or introduce an overlay when dwell is half complete, confirming the user does not accidentally select a new target that displaced the original position.
• Implementation side: inject scrolling, object replacement, and expired samples, checking whether the activated object, action meaning, and accumulated progress remain consistent.

CounterexamplesUnder-delivery — "expand details" is replaced with "delete," and when the old timer finishes it deletes; over-delivery — all page updates stop the moment anyone is looking.

3.3 E3 Accuracy is bounded and degrades¶

E2 governs how a target is triggered once it is determined; this principle governs how the target is determined: how geometry is set, how accuracy is measured, and what the system does when it is inaccurate.

E3-1Target geometry is defined by visual angleMUST¶

One-line summary: Size and spacing are in degrees, not pixels; the hit area may be larger than the visible size.

Applies toall gaze-activatable interface elements.

RuleThe minimum size and minimum spacing of a gaze-activatable target MUST be defined in visual angle (degrees), with the viewing distance or display geometry it is based on declared; a specification defined only in pixels, points, or physical length without declaring the distance condition does not satisfy this clause. The hit area and the visible size MAY be separated — the hit area is allowed to be larger than the visible element, but the hit areas of adjacent targets MUST NOT overlap to the point of being indistinguishable. The product MUST declare the minimum visual-angle value it adopts and its basis, checking the projected width and height separately; a three-dimensional target must additionally specify the visible surface, occlusion, and depth arbitration. A hidden object that the gaze ray passes through MUST NOT be activated merely because it ranks first in hit order.

Boundary conditionsThis clause does not prescribe a universal lower bound across products. HoloLens 2's 2° is that device's vendor recommendation, not a hard physiological threshold. Apple's official talk requires at least 60 pt of target space for each element, which may be jointly satisfied by visible size and spacing; its fixed-ratio 3D object reference converts to approximately 2.5° (see Appendix B). When adopting platform-standard controls and dynamic scaling, the requirement MAY be satisfied through the platform's traceable display-geometry conventions, without requiring the designer to separately fill in a physical distance. The achievable accuracy of headsets, desktop remote eye trackers, and in-vehicle DMS differs; the value taken MUST be determined by that device's own measured accuracy.

Basis and referencesA 2° visual angle is approximately 2.1 cm at a 60 cm viewing distance (conversion in Chapter 4). When the relative measurement error of a target is too small, it is typically harder to distinguish; error is not a fixed-radius circle, and absolute hit rate cannot be derived from size alone. Target spacing, offset, jitter, and the determination method need to be measured jointly.

Design applicationIn the design tool, lay out the gaze interface on an angular grid rather than a pixel grid; when the same design is used for devices at different distances, reconvert rather than proportionally scale pixel values.

Verification examples

• User side: measure target selection rate and mis-selection rate under the device's actually measured accuracy, rather than looking only at the size annotations on the design file.
• Implementation side: check whether the layout system retains the distance parameter; check whether responsive layout compresses targets below the threshold at extreme sizes.

CounterexamplesUnder-delivery — reusing the mobile 44 pt touch-target spec for a gaze interface, so the user can never select it no matter how they look; over-delivery — expanding the hit area to be extremely large to make it "easy to select," so that adjacent targets' hit areas overlap each other, and the one ranked first is always what gets selected.

E3-2Accuracy is an observable operational stateMUST¶

One-line summary: The system itself must know whether it is currently accurate, and change its behavior accordingly.

Applies toall features that make determinations based on gaze position.

RuleThe system MUST maintain an evidence-based tracking-availability state, which may come from measured error, a validity flag, calibration verification, or a quality level provided by the platform, recording its basis, coverage area, and freshness; when no measured value is available, "unknown" MUST be allowed, and per-frame accuracy MUST NOT be fabricated. When quality is expressed as angular error, a smaller value is better, and only exceeding the error ceiling counts as insufficient; accuracy, precision, and data-loss rate MUST NOT be conflated into a single metric. During binocular fusion, monocular use, or input-source switching, verification MUST follow the corresponding population and device conditions; a missing eye MUST NOT be included in an average as a zero coordinate, nor may head direction silently impersonate gaze position. When quality is insufficient or unknown, behavior MUST be defined — at minimum one of: deactivating gaze activation, enlarging the target and verifying it remains distinguishable, or switching to an alternative channel (corresponding behavior, see E6-3). Changes to the accuracy state MUST be readable by product logic; it is forbidden to keep judging hits at the nominal accuracy when accuracy is already known to be insufficient. The system's estimate of accuracy and the disclosure to the user are two different things: this clause requires the former to exist; disclosure requirements are in E4-1.

Boundary conditionsThis clause does not require exposing the specific accuracy value to the application layer — out of the considerations in E5-2, exposing a level (available/degraded/unavailable) may be a more suitable granularity. What it requires is that this state exists internally in the system and that behavior changes accordingly.

Basis and referencesTracking accuracy degrades from lighting changes, wearing-position shifts, pupil-size changes, and fatigue — this is a repeatedly documented phenomenon; Microsoft's guidelines note that accuracy may drop to some degree with lighting changes and recalibration may be needed (see reference.md §1, §4). Nominal accuracy cannot substitute for verification with the target user under actual use conditions (measurement basis in Appendix A.3).

Design applicationWire the accuracy estimate into layout and hit-testing, not just into a "please recalibrate" prompt; tiered accuracy rather than a continuous value is easier to use in product logic.

Verification examples

• User side: use the product under artificially induced low-accuracy conditions (changing lighting, moving the wearing position), observing whether operations requiring high accuracy are still demanded of the user.
• Implementation side: inject a degraded accuracy estimate, verifying that hit-testing and target geometry genuinely change accordingly.

CounterexamplesUnder-delivery — accuracy is never re-assessed after calibration, and after wearing the headset for two hours the user can no longer select anything, with no response from the product; over-delivery — a recalibration prompt pops up at the slightest accuracy fluctuation, interrupting the user every few minutes.

E3-3Tracking loss is an explicit stateMUST¶

One-line summary: Lost means lost — no extrapolation, no guessing, no silently reusing the last position.

Applies tofeatures that use gaze position to determine selection, hits, and activation. Pure rendering prediction is not bound by this clause's prohibition on extrapolation, but the predicted value MUST NOT be reused as valid operational evidence.

RuleInvalidity and timing are adjudicated by clause according to the table below, not governed by a single "loss timeout"; accumulation and activation stop the moment the first invalid, expired, or unexplainable-timestamp sample appears, without waiting for the loss time limit to be reached. When the data source stops sending events, freshness expiry MUST likewise be detected; the system MUST NOT rely on "receiving an invalid sample" as the only way to discover a stream cutoff. When cancellation, deauthorization, object invalidation, and a timing threshold are pending at the same time, the blocking condition is handled first, before deciding whether to allow submission.

Extrapolating gaze position to continue judging hits during tracking loss is forbidden; reusing the last valid gaze point as the current gaze point is forbidden. Recovering valid tracking only restores eligibility for a valid selection: an uncanceled short interruption may continue under its contract, while a canceled attempt MUST restart; an incomplete prior submission MUST NOT be automatically completed. The invalid state MUST be perceptible to the user (requirement in E4-1).

Basis and referencesAvailable signal, brief invalidity, and sustained failure must be distinguished; an unavailable signal must not be silently folded into a valid selection. OpenXR's validity, tracking flags, and time information provide a partial implementation basis, but are not a one-to-one mapping of this guideline's state model (reference.md §3.1).

Design applicationStop the activation timer the moment the first invalid, expired, or unexplainable sample appears, without waiting for the tracking-loss prompt's time limit before preventing mis-triggers. Distinguish a brief interruption (blink, momentary occlusion) from true loss — the former is absorbed by E2-4's suppression window, the latter enters the invalid state; the two time limits are configured separately.

Verification examples

• User side: have the user briefly cover the eye-tracking camera with a hand or close their eyes for a few seconds, verifying no activation is produced and the state is clear after recovery.
• Implementation side: replay a data stream containing tracking interruptions, checking whether the hit-testing count during the interruption is zero.

CounterexamplesUnder-delivery — after tracking loss, the system reuses the last position; while the user rests with eyes closed, the dwell timer fills up and triggers an operation; over-delivery — a single 100 ms blink interruption grays out the entire screen with "tracking lost."

E3-4Calibration cost is proportionate to its benefitSHOULD¶

One-line summary: Judge whether there truly is an offset before recalibrating; do not treat a guessed intent as calibration ground truth.

Applies toproducts that require user cooperation to complete calibration.

RuleThe product SHOULD require recalibration only once drift reaches a degree that affects the task, and SHOULD prefer a low-interruption quality check; implicit correction is used only when the reference target is reliable and the improvement is verified; recalibration SHOULD NOT be required unconditionally at fixed time intervals. Regardless of the correction method used, the object selected after a probabilistic hit MUST NOT be directly treated as the ground truth of the user's actual gaze. When a shared device switches users, or a profile is imported across devices, it MUST be re-verified before it can be used for that user; another person's fitted result MUST NOT be reused. The triggering condition and required duration of calibration SHOULD be predictable to the user. Whether the first calibration can be skipped, and the scope of availability after skipping, SHOULD be explicitly declared (corresponding to the uncalibrated behavior in E6-3).

Basis and referencesEye-tracking reporting guidelines require stating the calibration method, verification criteria, and recalibration trigger condition (reference.md §4.4). They do not prove that "implicit correction is always better"; that approach must demonstrate its benefit within this product.

Design applicationKeep calibration and verification separate, checking key regions with reference points that were not part of the fit whenever possible. If natural interaction is used to correct offset, retain the pre-correction parameters and compare the effect. When re-verification fails, only a profile still applicable to the current user and conditions, and that passes verification, may be restored; otherwise degrade to a path that does not depend on calibration.

Verification examples

• User side: use continuously for 30 minutes, recording the number of times recalibration is requested and the interruption duration each time.
• Implementation side: check whether the recalibration trigger condition includes an accuracy criterion, rather than only a timer.

CounterexamplesUnder-delivery — drift has grown so large the user can select nothing, and the system still does not prompt for calibration; over-delivery — a mandatory five-point calibration every ten minutes, so the user spends a third of their time staring at dots.

3.4 E4 Feedback is restrained and attributable¶

E3 governs how the system internally computes a hit; this principle governs how the system tells the user about it. Feedback design for eye tracking carries a unique constraint: trigger frequency is determined by the user's eye movement, and eye movement is far more frequent than any manual input.

E4-1Gaze acknowledgment is attributableMUST¶

One-line summary: Let the user see where the system believes they are looking, so they can identify offset.

Applies toall interfaces where gaze participates in selection, and scenarios where the gaze feature may fail.

RuleWhen gaze participates in selection, the system MUST let the user determine which object is currently identified by the system as the gaze target; when the system is in a state of insufficient accuracy or tracking loss (E3-2, E3-3), it MUST let the user perceive this, rather than letting the user mistake the system's failure for their own operating error. The acknowledgment MAY be attached to the target object; a continuous gaze cursor is not required.

Boundary conditionsThis clause does not require presenting gaze-point coordinates or a gaze trajectory. A state change attached to the target (a slight highlight, border, or size change) satisfies the requirement, and is usually preferable to a continuous cursor. Only supplementary effects may be suppressed (supplementary animation, expansion, routine sound effects); candidate distinguishability, the charging-and-cancellation acknowledgment, and the invalid-and-off acknowledgment are not within the suppressible scope. This clause does not require the product to report the actual deviation between the user's real gaze direction and the system's determination — only the object the system has identified may be presented; when there is no reliable basis for measuring the deviation, display "unknown," and do not give a directional indicator.

Basis and referencesMicrosoft's HoloLens 2 guidelines explicitly recommend not binding an element like a cursor directly to the user's gaze — a tiny offset in the projected gaze signal produces the "fleeing cursor" effect, where the harder the user tries to look straight at the cursor, the more it runs (see reference.md §1). This is the typical cost of turning "attributable" into "a continuous cursor."

Design applicationCarry the acknowledgment through the target's state rather than a cursor's state; give the invalid state a presentation clearly distinct from the normal state (rather than simply "nothing happens," which is indistinguishable from "I didn't aim right").

Verification examples

• User side: use the product under conditions with a systematic offset, observing whether the user can realize "the system thinks I'm looking at the one next to it" and compensate.
• Implementation side: check whether tracking loss and insufficient accuracy have a presentation distinct from the normal state.

CounterexamplesUnder-delivery — after accuracy drifts, there is no indication at all, and the user thinks it is their own fault, repeatedly straining to stare at the target and causing eye fatigue; over-delivery — a high-contrast cursor that follows gaze, so the user's own gaze is drawn to their own cursor, forming a chase.

E4-2Feedback has timing and suppression conditionsMUST¶

One-line summary: Lightweight acknowledgment appears promptly; expansion and animation are delayed or suppressed according to context.

Applies toall interfaces that give visual, auditory, or haptic feedback in response to gaze.

RuleGaze feedback MUST define its appearance timing and suppression conditions, and distinguish basic hit acknowledgment from supplementary content expansion. A lightweight, stable highlight MAY respond instantly to a valid hit; feedback that expands content, moves the layout, or plays sound MUST have a delay or suppression proportionate to the context, avoiding interference from saccades passing through or pure reading triggering it. Feedback intensity SHOULD be restrained, avoiding high-frequency flashing effects; adjustable timing MAY inherit behavior already validated by the platform, and the application is not forced to layer additional delays on top.

Basis and referencesMicrosoft's HoloLens 2 guidelines repeatedly emphasize this — do not overwhelm the user with instant pop-up effects or hover sound effects, "subtlety is key"; while also noting that feedback itself is necessary, to show the system is working correctly (see reference.md §1). This rule carries the strongest tension between its two sides: with no feedback at all the user has no way to judge, and with feedback slightly too heavy it becomes harassment.

Design applicationContinuous hover sound effects during browsing are off by default; sound acknowledgment for discrete activation is configured per user need; refer to Apple's distinction between instant highlighting and delayed expansion (reference.md §1.3); treat "the user in continuous use for twenty minutes" as the review condition for feedback design, rather than looking only at a screenshot of a single interaction.

Verification examples

• User side: have the user rate the level of disturbance after 20 minutes of continuous use; record the number of feedback triggers per minute.
• Implementation side: replay gaze data containing many saccades, tallying the ratio of feedback triggers to actual dwells.

CounterexamplesUnder-delivery — gaze sweeping across a row of icons makes every single one pop up enlarged and play a sound; over-delivery — gaze feedback is eliminated entirely to avoid disturbing the user, so the user has no idea whether the system is responding to them at all.

E4-3Interaction states are distinguishableSHOULD¶

One-line summary: Hover, charging, activated, and canceled each look like themselves.

Applies tointerfaces that use multi-level gaze-interaction states.

RuleThe states of gaze entering, dwell charging in progress, activation complete, and charging aborted SHOULD be distinguishable in presentation; the same state SHOULD be presented consistently across the product. The trigger having been issued and the business result MUST be kept separate: "complete" MUST NOT be shown while awaiting the result, and "failed" MUST NOT be shown together with an automatic resend when the result cannot be determined. States MUST NOT be distinguished by color alone; when reducing dynamic effects, cues for identifying the object, progress, cancellation, and result must still be retained. Requirements for the progress presentation of dwell charging are in E2-2.

Design applicationDefine the state set at the design-system level (corresponding to Design Token §5), rather than designing it component by component; the aborted state needs an explicit presentation — "returning to the initial state" is often not enough for the user to confirm that abortion occurred.

Verification examples

• User side: have the user describe what just happened ("I selected it," "it's counting," "it was canceled"), checking whether the description matches the actual state.
• Implementation side: enumerate the state-transition matrix, confirming every transition has a corresponding presentation.

CounterexamplesUnder-delivery — charging and activated look the same, and the user doesn't know whether to keep looking; over-delivery — four states use four completely different animation sets, and the interface looks like it's playing a cartoon while the user is just browsing.

E4-4Hover-expanded content is reachable and closableMUST¶

One-line summary: Once new content appears, the user can move to it to read and operate it, and can also close it.

Applies toexplanations, menus, overlays, and hidden controls expanded by gaze.

RuleExpanded content MUST have a discoverable starting point, and MUST allow the user to move from the trigger target to the new content without it disappearing prematurely; it MUST remain available while the user is reading or operating it. When content is occluded, a reachable way to close it MUST be provided. Expansion MUST NOT suddenly seize the current operation target, and MUST NOT force the user to chase the interface by moving text or buttons. Alternative input MUST also be able to access the same information; gaze hover MUST NOT be the only entry.

Boundary conditionsA non-interactive tooltip MAY close once the user leaves the trigger and expansion area; not all overlays are required to remain permanently present. Where WCAG 1.4.13 applies to a webpage, the original conditions and exceptions of that success criterion must still be satisfied item by item.

Basis and referencesW3C requires that additional content produced by hover or focus be dismissible, hoverable, and persistent; this clause translates that into an interaction check for when gaze moves into new content (WCAG 1.4.13).

Design applicationHave the trigger and the expanded content form a continuous reachable region; freeze the closing timer during a brief move-out. Keep key labels positionally stable, reducing layout jumping.

Verification examples

• User side: after expanding a menu, move the gaze to the last item and select it, then open and close the menu through alternative input.
• Implementation side: check the transition path from the trigger area to the content area, occlusion handling, and closing conditions, not judging a normal move into the content as an exit.

CounterexamplesUnder-delivery — the moment the user looks at the tooltip's body text, the tooltip disappears because it left the icon; over-delivery — every tooltip that has ever been viewed once stays permanently present, covering the page.

3.5 E5 Gaze data is visible and controllable¶

The first four principles govern interaction; this principle governs data. Its object of regulation is gaze data itself — what is collected, what is inferred, how long it is kept, and where it goes. This is where eye tracking differs from every traditional input channel: gaze and eye data may support individual-level inferences beyond the current operation; the risk depends on data content, granularity, associated information, and use. Other input trajectories may also leak personal characteristics, and this cannot be taken to mean they carry no inference risk.

E5-1Collection and purpose are disclosed and boundMUST¶

One-line summary: State clearly what is collected, what is inferred, and what it is used for; uses beyond that require re-authorization.

Applies toall products that collect gaze data.

RuleBefore the user gives authorization, the product MUST explain, in an understandable way: which gaze data is collected, what inferences are made from it, what purpose it serves, how long it is retained, and whether it leaves the device. The collection purpose MUST be bound to the actual use — using already-collected gaze data for a purpose beyond the disclosed one MUST require re-authorization; it MUST NOT rely on "eye-tracking authorization already obtained" to cover the new use.

Boundary conditionsThis clause does not require disclosing technical details (sampling rate, algorithm) to the user. What it requires is that the user can understand "what the system will know about me."

Design applicationList uses item by item rather than bundling them into a single phrase like "to improve the experience"; state "needed for interaction" separately from "analytics, recommendation, monitoring" — this is the precondition for E5-3's item-by-item authorization.

Verification examples

• User side: after reading the disclosure, have the user restate "what will the system know about me," checking the gap against the actual collection scope.
• Implementation side: audit the actual data flow against the disclosed content; check whether adding a new use triggers re-authorization.

CounterexamplesUnder-delivery — the authorization page reads only "this application uses eye-tracking functionality"; over-delivery — the full technical specification is crammed into the authorization page, and after reading it the user still doesn't know what the system will know.

E5-2Raw gaze does not leave the device by defaultMUST¶

One-line summary: The application does not get raw gaze-point coordinates by default; it gets only the layer it needs.

Applies toplatforms and systems that provide gaze capability to third-party applications, plugins, or external services.

RuleThe system MUST tier the exposure granularity of gaze data, distinguishing at minimum: no exposure, region-or-object granularity, and gaze-point coordinates. The default exposure level MUST be the lowest level sufficient for the function; exposing gaze-point coordinates to an application MUST go through authorization independent of "enabling the gaze feature." An application requesting higher granularity does not constitute grounds for raising the default level.

Basis and referencesvisionOS's approach is to not provide gaze-position information to applications before the user clicks, with eye-tracking data processed locally on the device (see reference.md §1, §5). The value of this design is that it demonstrates a large share of gaze-interaction functionality does not require the application to know where the gaze point is — the system layer performs hit-testing, handing only the result to the application.

Design applicationPlace hit-testing at the system layer rather than the application layer — this is the most direct architecture that satisfies both this clause and E3-2 at once; the application receives only "which object was selected."

Verification examples

• User side: check whether the user can learn at what granularity a given application is obtaining gaze data.
• Implementation side: audit the gaze interfaces available on the application side, confirming the default level and the authorization threshold.

CounterexamplesUnder-delivery — enabling the gaze feature is equivalent to opening the gaze-point coordinate stream to every application; over-delivery — granularity is restricted so much that the application cannot even get "which button did the user select," and gaze interaction cannot be implemented.

E5-3Each inference type is authorized separatelyMUST¶

One-line summary: Gaze needed for interaction MUST NOT be bundled in authorization with emotion, load, or identity inference.

Applies toproducts that infer attention, interest, or other user states from gaze or related eye data; signal processing used only for current hit-testing, hover, and rendering does not constitute a persistent user profile.

RuleThe product MUST authorize gaze use needed for interaction separately from inferring user state from gaze, and authorize each inference type item by item, distinguishing at minimum: attention and interest, cognitive load, emotion, drowsiness or fatigue, identity recognition, and health-related indicators. For optional analytics, profiling, and general gaze-control functionality, no inference MUST be enabled by default; it is forbidden to make state inference a mandatory condition of enabling gaze interaction, and it is forbidden to let authorization for one inference cover a newly added inference type.

Monitoring capability governed by dedicated regulation is handled separately under its applicable branch: the product must first identify the specific product category, jurisdiction, and applicable clauses, defining the enable/disable authority for monitoring, alerting, recording, and secondary evaluation separately, and truthfully state which capabilities the user cannot legally disable. This exception covers only capability proven necessary to retain, and MUST NOT be extended to marketing, emotion analysis, or after-the-fact evaluation; "this is a safety feature" alone does not constitute exemption — a specific basis must be identifiable.

Basis and referencesGaze and related eye data may be used for identity or state inference, and users may not anticipate such uses; this is a risk that needs assessment, not evidence that the inference is already reliable. Risk varies with representation and use, and de-identified coordinates, regional events, or local processing cannot be assumed inherently risk-free (see reference.md §5). Authorization cannot substitute for the validity verification in E1-5, nor can it legalize a use prohibited by law.

Design applicationState identity-recognition-type inference (gaze behavior may be used for re-identification) separately in product copy, not merged with "personalization"; health-indicator-type inference needs an additional assessment of whether it triggers medical-device or health-data regulatory requirements.

Verification examples

• User side: verify whether the user can enable only gaze interaction without enabling any state inference, and that interaction functionality is unaffected.
• Implementation side: check whether the enabling condition of the inference module is decoupled from the interaction module.

CounterexamplesUnder-delivery — enabling gaze control simultaneously enables emotion analysis by default, with the user completely unaware; over-delivery — even "foveated rendering needs to know where you're looking" is made into an inference authorization requiring a user checkbox, and the authorization page has seventeen toggles.

E5-4Collection status is visibleMUST¶

One-line summary: The user can tell when they are being read.

Applies toall products that collect gaze data.

RuleWhen gaze data is being collected or read by an application, the user MUST be able to know this. The indication method MAY be continuous or event-based, but it MUST exist and be discoverable by the user. Collecting gaze data in the background with no indication whatsoever is forbidden.

Boundary conditionsA necessary system-level function (such as foveated rendering or accessibility navigation) MAY forgo a continuous indicator, but it MUST be checkable in settings and stated in the capability disclosure, and this exemption does not apply to any state inference in the sense of E5-3.

Design applicationFollow the existing mental model of camera and microphone indicators; distinguish "the system is using it" from "a specific application is using it" — the latter SHOULD be traceable to the specific application.

Verification examples

• User side: have the user judge, during use, "is anything reading my eyes right now," checking the accuracy of that judgment.
• Implementation side: enumerate every collection path, confirming each has a corresponding indication or falls within a declared exemption.

CounterexamplesUnder-delivery — a background application continuously reads the gaze stream with no trace on the interface; over-delivery — a large, permanently blinking eye icon sits in the corner of the screen, itself becoming a source of attentional distraction.

E5-5Retention is itemized and deletableMUST¶

One-line summary: Raw gaze, gaze events, calibration profiles, and inference conclusions each have their own retention period.

Applies toany product that persists gaze-related data.

RuleThe product MUST separately define and separately manage the retention period of the following data: raw gaze samples, gaze events (hits, dwells, activations), calibration profiles, and inference conclusions. Each category's retention entry must state the event it counts from (collection time, event-occurrence time, profile-update time, or other), whether it is persisted, the bounded-memory handling window, and any exception reference; merely being read does not extend the retention period. The user MUST be able to view the categories of data retained and request deletion; where a statutory retention obligation exists, the reason, period, and restricted-processing scope for retention must be stated. Deleting an inference conclusion MUST NOT be reconstructed by the system from retained raw data, copies, or backups; but forming a new conclusion from newly collected data under already-disclosed rules, while authorization remains valid and the user has not disabled that inference type, does not count as "reconstruction" — deletion and disabling are two different things, and must be provided and explained separately; when a deletion is promised, instances of that conclusion in downstream profiles, caches, and recipient copies must be handled in step, and the backup cleanup cycle and the re-deletion mechanism after restoration must be stated. If eye images and pupil metrics are collected, they MUST be listed as a separate category with a separately defined retention period, and MUST NOT be folded into the calibration profile. Turning off the gaze feature is not equivalent to deleting already-retained data; the two MUST be provided and explained separately.

Basis and referencesThese four categories of data differ in sensitivity, useful lifetime, and reconstructability: a calibration profile is a device configuration, a gaze event is an interaction log, a raw sample is biometric behavioral data that can be used for re-identification, and an inference conclusion is a judgment about a person. Covering all four with a single retention period either over-retains raw data or loses necessary configuration.

Design applicationRetain raw gaze samples for the shortest period necessary. A calibration profile may be retained independently, but must also support user-initiated deletion or account clearing.

Verification examples

• User side: after deleting an inference conclusion, continue using the product, verifying two things separately: that the system has not restored that conclusion from old data or its copies; and that after the user separately disables that inference type, no such conclusion is formed again even with new data.
• Implementation side: check whether the storage location, retention period, and deletion path of the four data categories are kept separate.

CounterexamplesUnder-delivery — all eye-tracking data is bundled into one "usage data" bucket with a one-year retention period; over-delivery — the calibration profile is cleared at the end of every session, forcing the user to recalibrate every single time they use the product.

E5-6No unilateral judgment adverse to the userSHOULD¶

One-line summary: Attention data does not quietly become grounds for evaluation, exam proctoring, or risk control.

Applies toscenarios where gaze data may enter a judgment chain that produces adverse consequences for the user — workplace monitoring, online exam proctoring, learning assessment, insurance and credit, content compliance.

RuleA judgment of attention, focus, or state derived from gaze data SHOULD NOT be used to produce an adverse consequence for the user without that user being clearly informed. When genuinely needed for such a judgment, the criteria, possibility of misjudgment, and appeal path MUST be separately disclosed, and the product must undergo the corresponding domain compliance assessment (these guidelines do not substitute for that assessment). A use prohibited by applicable law MUST NOT be opened up merely because consent was obtained or an appeal path is provided; see reference.md §5.4, §5.5.

Boundary conditionsReal-time intervention in safety-critical scenarios is not included here — the purpose of a driver drowsiness alert is to protect that user, which is a different matter from using it to evaluate that driver after the fact. Immediate intervention does not exempt it from validity, necessity, and domain review; if its logs are repurposed for evaluation, they fall back under this clause. Legal exceptions must be checked against the specific provisions and cannot be presumed to hold merely on the label of "safety."

Basis and referencesEU AI Act Article 5(1)(f) sets out a prohibition and specific exceptions for emotion inference in workplaces and educational institutions; not every attention or drowsiness indicator automatically falls under that article's emotion recognition. The specific scope of application and exceptions must be checked against the actual use, and cannot be opened up merely on the label of "safety" (see reference.md §5.5).

Design applicationPhysically separate, in the data flow, "used to help the user" from "used to evaluate the user"; the existence of the latter must itself be visible to the user.

Verification examples

• User side: examine one state judgment, verifying the user can discover its use, correct an error, and find the appeal path.
• Implementation side: trace every consumer of gaze-derived metrics, confirming none leads to an evaluative judgment about the user without disclosure.

CounterexamplesUnder-delivery — an online exam system directly judges cheating from the number of gaze deviations and cancels the score, with the student unaware of the criteria and unable to appeal; over-delivery — out of fear of compliance risk, even an aggregate product metric like "most people didn't look at this section" is abandoned as well.

3.6 E6 The channel is exitable and non-exclusive¶

The first five principles assume the gaze channel is working. This principle governs when it is not working, cannot be used, or should not continue to be used: under what conditions the user depends on this channel, and what the exit path is under each condition.

E6-1An equivalent alternative path existsMUST¶

One-line summary: Every task that can be completed with the eyes has a way to complete it without the eyes.

Applies toall products that provide gaze interaction.

RuleFor every primary task of the product, a completion path not dependent on gaze MUST exist, and that path MUST be functionally equivalent to the gaze path — it MUST NOT be a feature-reduced path. The alternative path MUST be discoverable, and MUST NOT require the user to first find it through the gaze channel.

Boundary conditionsThis clause does not apply to dedicated assistive devices where eye tracking is the only available input — for such products, requiring "a path not dependent on gaze" is meaningless. But even in such products, the degraded-behavior requirement of E6-3 still holds (how the user seeks help when tracking fails).

Basis and referencesDesign needs to consider two possibly overlapping or context-varying situations at once: one is eyes only (users with severe motor impairment, the starting point of the COGAIN line of work), and the other is eyes unusable (nystagmus, significant strabismus, certain eyewear or corneal conditions, bright-light environments). The same product needs to accommodate both groups at once, which is why this clause and E6-2 must coexist.

Design applicationTest the alternative path as if it were the primary path, not as an emergency exit; the gaze path may be quicker, but its reachable functionality must not exceed the alternative's.

Verification examples

• User side: with eye tracking disabled, complete all primary tasks, recording any steps that cannot be completed or are significantly worse.
• Implementation side: enumerate the feature list, annotating the non-gaze path entry for each item.

CounterexamplesUnder-delivery — a certain setting can only be entered through a gaze menu, and the user is locked out when eye tracking fails; over-delivery — to make it "equivalent," the gaze path is cut down to exactly the same number of steps as the keyboard path, erasing gaze's speed advantage.

E6-2Physiological and wearing differences are not grounds for exclusionMUST¶

One-line summary: Nystagmus, strabismus, monocular vision, a prosthetic eye, lenses, or drooping eyelids do not mean the product cannot be used.

Applies toall products that provide gaze interaction or gaze-related functionality.

RuleThe product MUST cover, in design and testing, physiological and wearing conditions that affect the usability of eye tracking, including at minimum: nystagmus, strabismus and interocular disparity, monocular vision or a prosthetic eye, ptosis, corrective lenses and contact lenses, abnormal pupil size, and dark iris or eyelash occlusion. For a user for whom tracking is unusable, the product MUST provide the alternative path of E6-1 without reducing their reachable functionality; for a user whose tracking quality is degraded but usable, the product MUST provide adjustable parameters (dwell duration, target size, suppression window) rather than only a single fixed set of values.

Basis and referencesThis clause and E6-1 are two sides of the same coin. A product that offers gaze as an accessibility capability, if it lacks accessible design itself, produces a particular failure: a channel built for accessibility ends up excluding another group of users with disabilities.

Design applicationExpose adjustable parameters in settings; where the device supports it, provide monocular calibration and simplified point sets, without claiming software can make up for hardware conditions it cannot track. State the basis for test conditions according to device mechanism and target population, not treating a given iris color or diagnostic label as necessarily unusable.

Verification examples

• User side: recruit participants covering the above conditions for usability testing, rather than relying only on self-testing by developers.
• Implementation side: check whether the adjustable parameter range covers the values needed by low-accuracy users.

CounterexamplesUnder-delivery — the calibration process requires both eyes to hold a stable gaze simultaneously, and nystagmus users never pass the first step with no way to skip it; over-delivery — for compatibility, the default dwell duration is set to 3000 ms, forcing every user into the slowest configuration.

E6-3Degraded behavior is definedMUST¶

One-line summary: The behavior for uncalibrated, insufficient accuracy, and tracking loss is each specified in advance.

Applies toall gaze-dependent functionality.

RuleThe product MUST separately define and declare system behavior for the following states: never calibrated, calibration expired or drift beyond limit, accuracy below threshold, tracking temporarily lost, and tracking unavailable (hardware fault or permission turned off). The behavior for each state MUST be specific down to activation permission, in-progress progress, ongoing commands, alternative entry, user acknowledgment, and recovery conditions. Unknown quality, a user pause, and the application losing interactive state must also have a determinate behavior; when the application goes to the background or is occluded to the point of being non-interactive, the related selection MUST be canceled and ongoing commands stopped, and returning to the foreground MUST NOT resume the original timer. When gaze is the only channel available, a failure help-seeking path MUST be arranged in advance, such as an available independent switch, a caregiver entry, or an authorized help mechanism; the help button MUST NOT be placed inside the one channel that has already failed. Applying the normal-state judgment logic under an undefined state is forbidden.

Design applicationTurn the applicable states into a state table included in the design deliverable (corresponding to Design Token §4, §7); the user-visible presentation of each state is carried by E4-1.

Verification examples

• User side: construct each applicable state in turn, verifying the product's behavior matches its declaration and the user knows what to do.
• Implementation side: check the priority of state determination — when multiple states hold at once, the most conservative behavior is taken.

CounterexamplesUnder-delivery — after permission is turned off, the interface still displays gaze-activatable elements as usual, and the user stares at them with no response; over-delivery — five states have five completely different interfaces, and the user must relearn the interface every time they encounter one.

E6-4The user can disable by scopeMUST¶

One-line summary: The user can turn off just inference, or just activation, rather than only all-on or all-off.

Applies toall products that provide gaze functionality.

RuleThe product MUST allow the user to disable, by scope, the gaze functionality actually under its own control, distinguishing at minimum: gaze activation (retaining system-level navigation and accessibility uses), state inference (each item in E5-3), and data retention and upload. Disabling MUST take effect immediately, and after disabling, the product MUST operate per the corresponding degraded behavior in E6-3 rather than lose functionality altogether. Placing the disabling entry itself somewhere reachable only through gaze is forbidden.

When a capability is platform-hosted, the product must state the scope it inherits and the boundary it can actually control, and point to the platform's control entry — it MUST NOT promise a disabling authority it does not have, nor evade the portion it actually controls by claiming "the platform is responsible." Monitoring capability that cannot legally be disabled is stated under the applicable branch of E5-3, and presented separately from optional capability.

Basis and referencesApple's official iPhone guidance sets Eye Tracking and Dwell Control as separate settings, demonstrating that pointing and dwell activation can be decoupled. It does not prove the platform already provides every toggle this guideline requires; an application's actual disabling capability must be checked against the platform interface it adopts (see reference.md §1.4).

Design applicationAlign the granularity of disable items with the itemized uses disclosed in E5-1, so the user can map "what I don't want" to "which toggle to turn off."

Verification examples

• User side: have the user express "I don't want it analyzing my emotions, but I want to keep gaze control," and observe whether this can be accomplished in settings.
• Implementation side: verify that the related data flow genuinely stops after disabling, not merely that the interface no longer displays the result.

CounterexamplesUnder-delivery — there is only one master "eye tracking" switch, and to avoid emotion analysis the user must give up all gaze-control functionality; over-delivery — seventeen toggles spread across four levels of settings pages, and the user cannot find which one to turn off.

E6-5Sustained load has a budgetSHOULD¶

One-line summary: Prolonged gaze control has a cost, and the product must account for it.

Applies togaze-interaction products expected to be used continuously for extended periods.

RuleThe product SHOULD define a load budget for sustained gaze control — continuous-use duration, number of dwell activations within a single task — and change behavior when it is exceeded: prompting a rest, switching to a less-effortful trigger method, or relaxing parameters. The prompt SHOULD NOT block an in-progress task. The product SHOULD avoid requiring the user to sustain precise gaze for a long time as a condition of completing a task.

Boundary conditionsThis clause targets the load of gaze as a control channel, not screen-use duration itself (the latter is a broader issue outside the scope of these guidelines). In assistive scenarios where gaze is the only channel, prompting rest may be inappropriate — here this clause becomes "provide a less-effortful trigger method" instead.

Basis and referencesMicrosoft's HoloLens 2 guidelines note that forcing the user to select an overly small target induces tension from ocular accommodation, causing fatigue and irritation; an overly long dwell duration is likewise described as "straining and unnatural" (Tobii). Both attribute fatigue to design parameters rather than usage duration itself — which is precisely the part the product can be held responsible for (see reference.md §1).

Design applicationPlace high-frequency targets in spatial interfaces within the comfortable field of view, reducing frequent large eye or head rotations and depth switching; re-verify selectability after distance, orientation, and scale changes (reference.md §1.3). Link the load budget to E2-1's tiers — high-frequency, low-cost repeated operations most deserve a less-effortful alternative trigger; set natural paragraph pauses for continuous gaze input (such as gaze typing).

Verification examples

• User side: after 30 minutes of continuous use, measure the change in subjective fatigue and selection error rate, rather than only measuring first-use success rate.
• Implementation side: check whether a required flow exists that demands sustaining precise gaze longer than the declared duration.

CounterexamplesUnder-delivery — the gaze-input interface has no pause design at all, and after ten minutes of continuous input the error rate doubles and the user's eyes ache; over-delivery — "please rest your eyes" pops up every five minutes, interrupting ongoing work.

E6-6Continuous control can be completed in stepsMUST¶

One-line summary: Dragging, scrolling, and value adjustment have ways to complete that do not require sustained, precise gaze.

Applies toproducts where gaze participates in dragging, scrolling, slider adjustment, zooming, or other sustained operations.

RulePrimary tasks MUST have a completion method that does not depend on sustained precise gaze or holding a position — for example, selecting the object then selecting the destination, step buttons, or numeric input. Continuous control MUST define behavior for start, stop, cancel, and tracking failure; when switching channels, task state that can be preserved MUST be preserved, and an unconfirmed change MUST NOT be automatically submitted. Gaze scrolling MUST let the user know the active region, and MUST stop when leaving the trigger region or when the signal becomes unavailable; on recovering tracking, an old command MUST NOT automatically resume running.

Boundary conditionsA creative task where the trajectory itself is irreplaceable to the expression MAY state the limitation and provide other available input; "dragging is our interaction method" cannot be used as grounds to claim dragging is indispensable. The functional scope of the alternative path is per E6-1.

Basis and referencesWCAG 2.5.7 explicitly lists the difficulty gaze-control users have with dragging, and requires that a webpage provide a single-pointer, non-dragging path; a keyboard alternative alone is not sufficient (W3C). Extending this clause to native interfaces is a design requirement of these guidelines.

Design applicationProvide "move up / move down" for list reordering, and numeric input alongside a slider; enable edge gaze-scrolling for reading areas as needed, and for dense settings lists prefer retaining an explicit scroll control.

Verification examples

• User side: complete value adjustment and movement using only single selections, then look away or turn off tracking during auto-scroll, verifying it can stop and hold position.
• Implementation side: check whether a failure event clears ongoing commands; verify the keyboard, single-pointer, and gaze-control paths separately.

CounterexamplesUnder-delivery — reordering can only be done by holding and dragging with the eyes through a tiny gap; over-delivery — to avoid dragging errors, the user's familiar dragging capability is removed entirely.

---

4. Terminology and definitions¶

---

Appendix A: Classification checks and verification points¶

A.1 Classification check¶

The principle division of these guidelines claims to be mutually exclusive and exhaustive. Check method: take a specific requirement, have different reviewers independently judge which principle it should belong to, and see whether they arrive at similar assignments. Two failure cases and how to handle them:

• A requirement reasonably belongs to two principles at once — this indicates the two principles' objects of regulation overlap; what gets revised is the principle's definition or the rule's granularity, not adding a "cross-reference layer."
• A requirement cannot be assigned to any principle — this indicates the division is not exhaustive, and a new principle needs to be added or an existing principle's object of regulation needs to be expanded.

Known boundaries prone to confusion, for reference during checks:

A.2 Fault-injection verification points¶

Walking through the rules under the following conditions is the minimum verification set these guidelines recommend:

1. Switching between bright and dim light — the accuracy-degradation path (E3-2, E3-4, E6-3)
2. Wearing-position shift (headset sliding down, posture change) — the drift path (E3-4, E4-1)
3. Covering the camera for 3 seconds — the tracking-loss path (E3-3, E2-2 timing, E6-3)
4. 30 minutes of continuous use — the feedback-overload and fatigue path (E4-2, E6-5)
5. Injecting 500 ms of voice-recognition latency — multimodal timing (E2-3)
6. Disabling eye tracking — alternative-path completeness (E6-1, E6-3)
7. 10 normal blinks, then rapidly scanning a row of targets — mis-trigger suppression (E2-4)
8. Authorizing interaction only, not inference — authorization decoupling (E5-3, E6-4)
9. Continuing to use after deleting an inference conclusion — no automatic reconstruction (E5-5)
10. Participant testing covering the physiological conditions — exclusion check (E6-2)
11. Inserting a row, occlusion, or replacing the target mid-dwell — object-and-operation-meaning binding (E2-6)
12. A validity flag still present but the timestamp expired, unknown, or misaligned across clocks — freshness and timing (E2-3, E3-3)
13. Moving the gaze inside an expanded menu — content reachability and closing (E4-4)
14. Completing a drag-type task using only single selections, and interrupting auto-scroll — continuous-control alternative (E6-6)
15. Changing brightness, inducing missing data, and switching users — inference unknown, calibration-profile isolation (E1-5, E3-4)
16. Stopping sample transmission outright with no failure callback — freshness watchdog stops the timer (E3-3)
17. Shortening the threshold mid-charge, with deauthorization and threshold-reached arriving simultaneously — no retroactive activation, blocking takes precedence (E2-1, E3-3)
18. Continuing to look after activation, duplicate events, and a delayed result — reinitiation and single submission (E2-4, E4-3)
19. Single-eye failure, source switching, coordinate repositioning, and returning from background — quality re-verification, old timer invalidated (E3-2, E6-3)
20. Browsing elsewhere while typing text, disabling animation, and color-only feedback — focus not seized, states still distinguishable (E1-1, E4-3)

The durations and counts above are fault-injection examples, not sufficient conditions for a device to pass testing.

A.3 Evaluation basis and acceptance records¶

Before testing, the product SHOULD state the target population, device and operating environment, task, permitted error consequences, and acceptance criteria. The table below is a suggested record template; it does not prescribe a uniform pass rate or sample size. For measurement method, refer to Dunn et al.'s reporting guidelines; the interaction-acceptance basis is a supplement from these guidelines.

A minimal acceptance record may use: rule number → applicable/not-applicable and reason → configuration snapshot and basis → user-side result → implementation-side evidence → unresolved issues and alternatives. A separate document is not required for every rule. Data minimization during interaction operation still follows E5; evaluation needs are not grounds for long-term collection of raw production trajectories.

A.4 Acceptance is adjudicated separately¶

Hard failures are adjudicated separately: activation during an invalid state, still submitting after deauthorization, an unconfirmed external effect, reusing progress to submit a new object, duplicate submission, unauthorized inference, or unauthorized data outflow — any of these occurring in an applicable test is a fail, and cannot be offset by an average success rate. Performance and human thresholds are set by the project in advance, with sample size, denominator, and uncertainty reported; zero severe errors in testing does not prove real-world use is entirely risk-free.

Conclusions use "pass / pass with limited scope / fail," stating clearly the applicable conditions, unverified parts, alternative paths, and unresolved issues. When the input device, detection method, geometry, target population, or task conditions change, re-verify the affected evidence. Do not claim a product has passed real-world testing on the strength of one filled-out parameter table.

Appendix B: Sources and verification level of numeric thresholds¶

Numeric references in both the main text and the Token do not constitute a cross-device threshold. The recommendation strength in external original sources is judged separately from the binding strength of these guidelines; for the complete record see reference.md.

Dwell duration is still chosen by measured testing against population, task, geometry, and device; no universal default value is provided.

Appendix C: Status and factual contract of selection attempts¶

This appendix concretizes the behavioral requirements of E2, E3, E4, and E6 for joint use by design, engineering, and testing. Platform-hosted portions MAY cite platform guarantees; applications are not required to replicate the platform's internal implementation. State names are semantic, not terms that must be displayed to the user.

C.1 Four categories of state, recorded separately¶

Permission, tracking quality, and result each have their own state, and MUST NOT be masked under a single "loading." The user typically only needs to see the most useful feedback at the moment, such as "paused, keys available," "saving," or "cannot currently confirm whether the save succeeded."

C.2 Dwell state transitions¶

The determination order is: disabled / deauthorized / object invalidated / scene non-interactive → signal validity and freshness → quality and candidate ambiguity → activation condition → request deduplication → result acknowledgment. Completion of the feedback animation does not participate in authorization or completion determination.

C.3 How time accumulates¶

Time windows use a half-open interval: when an interruption is shorter than the window it may be retained, and reaching the window ends it; 0 means immediate cancellation. Once valid dwell reaches the required duration, it may enter the submission check. Accuracy error, by contrast, is compared per the declared statistical basis, and cannot borrow the time-window rules.

• fixation.min_duration is the criterion for a candidate to be established; dwell.duration is the activation timer. A custom implementation must declare whether dwell timing starts after the candidate is established, or includes the interval already used to verify the candidate; the two MUST NOT be unintentionally added together or double-counted. Timing from after candidate establishment is recommended; when platform-hosted, verify against its event semantics.
• Valid time is accumulated based on a monotonic clock and the verified sample-coverage interval, and cannot be computed from render frame count, callback count, or nominal sampling rate. The maximum timeable gap between two samples must have a verified upper bound; a long gap must not be counted in full.
• Valid departure, short-interruption retention, and a sustained-invalidity prompt are timed separately. Once frozen, the upper bound is computed from the original interruption moment, and cannot be continually extended by repeated invalid samples.
• Merely receiving a valid sample again is not sufficient to prove the same target was being looked at throughout; a zeroed-out attempt starts over. Once a continuous-control command stops, it must be reinitiated.

C.4 Minimum operational facts¶

A single attempt needs to be able to verify: the attempt identifier, input source, initiation and sample time semantics, candidate object and action snapshot, configuration at the time, quality basis, accumulated valid duration, freeze or cancellation reason, submission identifier, and actual result. Custom spatial hit-testing additionally records the coordinate space and scene association; when platform-hosted, only the events and contract references the application can obtain are retained.

These are the facts needed for mechanism verification, not a license to collect raw eye data long-term. Raw trajectories may be replayed in an authorized test environment; production records SHOULD use minimal discrete events wherever possible and be retained under the constraints of E5.

---

Implementation acceptance scenarios¶

The scenarios below turn the existing clauses into reviewable acceptance inputs, without setting an additional universal performance threshold. Select according to the product's applicable capability, supplementing real devices, users, input sequences, and evidence; record the reason when not applicable, and an unexecuted item MUST NOT be recorded as passed.

Each scenario checks separately: the configuration's effective values, the execution record, and a result the user can understand. Retain version, target, event timestamps, failure scope, and recovery result; an unknown external result is not filled in as success or failure.