Haptic Interaction Design Guidelines

For designers and engineers: make haptics felt, recognized, on time, degradable, and turn-off-able, and do not treat the user's body as an output channel that can be occupied at will.

These guidelines focus on vibrotactile haptic output on phones, watches, trackpads, styluses, and game controllers. A single haptic event may confirm an operation, or may convey a boundary, a result, or a texture; designing it requires considering semantics, bodily sensation, device capability, and playback conditions together.

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

These guidelines start from two experience commitments: the user can understand the feedback, and can control whether to accept it. When a device contacts the body, vibration may cause disturbance or discomfort; while business meanings such as success and failure need to be learned through a stable mapping. This document does not treat "haptics are uniquely unavoidable," "haptics have no natural meaning at all," or "habituation is irreversible" as scientific premises: physical collisions can have intuitive associations, and semantics are also shaped by context. Every hard constraint MUST state which commitment fails if it is missing; a platform recommendation or a single experiment does not automatically constitute a universal mandatory requirement.

These guidelines constrain the nature of the commitments a product makes to the user through haptics and the mechanisms that fulfill them; they do not presuppose an actuator type, specify a concrete API shape, or dictate an aesthetic orientation for waveforms. They are not a haptic effect library, not a hardware-selection guide, and do not substitute for the independent review of ergonomics standards (ISO 9241-910/920), dedicated accessibility assessment, or domain regulations (automotive HMI, medical devices, children's products).

Chapters 1–3 are for understanding and checking requirements, Chapter 4 unifies terminology, Chapter 5 helps complete design decisions, and Chapter 6 explains verification and delivery. Appendix A provides a checklist, and Appendix B explains the evidence boundaries. For configurable decisions see Design Token; for external grounding see source notes.

Start from a concrete problem: read Chapter 5 first when adding a new haptic point; check H1 and H4 for inconsistent device behavior; check H3 and H7 for late or repeated feedback; check H5, H6, and H4-5 for turning off, canceling, and interrupting. Rule numbers are for tracing requirements; designers are not required to fill in a form for all 35 in sequence.

---

1. The seven principles¶

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

A single scenario can touch multiple principles — one "payment successful" haptic simultaneously involves signal perceptibility (H1-1), semantic mapping (H2-2), not preceding server-side confirmation (H3-4), and an alternate channel on a device without an actuator (H4-2 and H5-1) — this is not a classification error: these rules constrain obligations on different regulated objects.

Mutual exclusivity and exhaustiveness are claims this division accepts being tested against, not facts that hold simply by being declared: when a rule is added, removed, or its assignment is in doubt, verify it against Appendix A's classification test (whether different reviewers can independently reach a similar assignment for a specific requirement); when the test fails, what gets revised is the principles' division.

Several divisions that are easily mistaken for duplicates but actually regulate different objects:

• H1 and H4: H1 governs the human side (whether this intensity is enough for this person in this context), and H4 governs the device side (whether this device can produce this waveform). The same failure can come from either side, and the handling is completely different.
• H5 and H6: H5 governs the division of information labor (information cannot be conveyed by haptics alone), and H6 governs bodily autonomy (the user has the right to refuse haptics itself). H6 allows the user to turn haptics off, and it is precisely H5 that guarantees the product remains usable after it is turned off.
• H1-2 and H7-1: H1-2 governs whether individual signals can be distinguished from one another (including the weakest tier and degraded forms), and H7-1 governs whether the intensity distribution over a period within the same effect family matches importance. The former is a perceptual question, the latter is a budget question.

Principles are used to understand rules and adjudicate assignment; they are not themselves a separate criterion for judgment. When a principle's reading conflicts with that of a specific clause, the applicable clause governs, and the ambiguity requiring clarification is recorded.

2. How to read a rule¶

2.1 The structure of each rule¶

In one sentence, the binding force of each part: the rule's main text specifies the requirement; Applies to and Boundary condition together bound the requirement's scope; Design application, Verification example, Counterexample, and Basis and reference add no separate obligation.

Rules write the nature of the behavior, not the implementation method: degrading along a defined path when capability is insufficient is a product behavior; which actuator to use, which driver IC to configure, is an engineering solution — the two MUST line up, but they are not the same deliverable.

Numeric values appearing in the main text are reference values, not acceptance thresholds. They come from public research and platform documentation (provenance in Appendix B), and are used to indicate magnitude and direction. The rules require the product to determine and verify its own thresholds; a reference value provides a starting point when there is no self-measured data, and helps a reviewer judge whether a chosen value obviously deviates from a known magnitude.

2.2 Normative terms¶

The main text of the rules uses three tiers of normative terms:

• MUST: not meeting it means not conforming to these guidelines. Without it, the haptic either cannot be felt, cannot be recognized, arrives too late, or becomes a disturbance the user cannot escape — this is the sole basis for marking something "MUST" (see Appendix B).
• MUST NOT: the negative counterpart of "MUST" at the same strength, specifying behavior that must not occur; in the main text, "must not" and "prohibited" are equivalent.
• SHOULD: followed by default; when there is a genuine reason to deviate, record the reason and the alternative, and accept the same verification. Deviation does not require approval, but does require a record. "SHOULD NOT" is the negative counterpart of "SHOULD."

Compliance is judged at the level of independent obligation clauses in the main text: a declarative sentence without a normative term carries the strength of its rule's heading; a clause with an explicit normative term is judged at its own strength — a MUST-NOT clause within a SHOULD rule remains a hard constraint (H1-3, H1-4, H1-6, H2-3, H3-3, H4-4, H5-3, H7-4 contain such clauses), and the strength label on a rule's heading or in the quick-reference table does not replace a clause's own binding force. "Cannot" in the main text is used only for statements of capability or fact (e.g., "the device does not support the specified primitive"), not to express an obligation.

Strength indicates binding force, not importance: "MUST" determines whether the product can ship, while "SHOULD" often determines whether the haptics are done well.

2.3 The two sides of a counterexample¶

A counterexample has two sides: "under-delivery" is missing this requirement, and "over-delivery" is stacking vibration, switches, or prompts in order to satisfy it. Neither side counts as getting it right — both kinds of failure should be included in review: if every button buzzes, the important one no longer wakes anyone up. Repeated stimulation may reduce response, and overly dense feedback may also mask itself; these situations need to be found through long-task testing, and cannot be judged from a successful interface call alone.

2.4 Rule quick reference: 35 rules¶

The table below is the one-line memorable version of every rule. The quick reference does not replace each rule's applicability conditions and full requirements; a few SHOULD rules contain a MUST-NOT-level clause, and judgment follows the main text (see 2.2).

H1 Perceptible

H2 Distinguishable in meaning

H3 Timed

H4 Degrades with capability

H5 Not the sole channel

H6 Body-controllable

H7 Restraint

---

3. Rules in detail¶

This chapter unfolds all 35 rules under the seven principles. Each rule's structure and the binding force of its parts are given in 2.1; the design applications, verification examples, and counterexamples within it are only notes that help implementation — they do not prescribe a single implementation, nor do they require a separate deliverable document. Numeric values in the main text are reference values; their effect is given at the end of 2.1.

3.1 H1 Perceptible¶

A haptic signal must first be received by the body. This principle governs the relationship between the signal's physical properties and human perceptual capability: whether it is strong enough, whether it can be told apart, whether it still holds in real usage postures and environments, and whether it holds the same way for different people. The most common failure of this principle is not a design error but an acceptance error — confirmed as "I can feel it" on a quiet desk, held in the hand, by the very designer who is familiar with the signal, and then shipped to a user carrying the phone in a pocket on the subway, wearing gloves, or with reduced peripheral sensation.

H1-1Signal is detectableMUST¶

One-line summary: Detectable by real users in real usage conditions, not judged from a dev desk.

Applies toAll haptic signals that carry an information-delivery responsibility. Pure textural embellishment (conveying no information the user needs to know) does not fall under this rule, but is still subject to H7's total-amount constraint.

RuleEvery haptic signal that carries an information-delivery responsibility MUST be detectable by the target user population under the product's declared primary usage conditions (see token haptic.context.usage), with a verification record. Detectability MUST be verified per condition; the result from a single condition (especially a development or demo environment) MUST NOT be extended to all conditions. The signal's intensity, frequency, and duration MUST be jointly verified under the target conditions. The approximately 200–250 Hz sensitive range may serve only as a directional reference from specific vibration experiments; it is not the default frequency for all body locations, contact modes, or actuators.

Boundary condition: This rule does not require making every signal strong. It requires two things: "detectable under the declared conditions" and "verified"; rhythm, duration, envelope, and device-supported parameter adjustments may be compared to choose a verified, comfortable expression; there is no adjustment order that is better for all hardware.

Basis and reference: The finger-vibration experiment supports detection thresholds varying with frequency; Android gives a design reference for button-feedback duration. Neither proves a unified perceptibility floor. For measurement conditions and sources see reference.md, Section 3.

Design applicationRecord, for each signal, the combination of conditions it has been verified under; treat "wearing gloves," "on a desk," "in a pocket," and "environment already vibrating" as conditions to verify during the design phase, not as post-release defects. Compare parameter combinations based on capability and user testing, avoiding compensating solely by increasing amplitude.

Verification examples

• User side: for each declared condition, first do an exploratory walkthrough, then present signal-present and signal-absent conditions in random order over a pre-set number of repeated trials, recording hits, misses, false alarms, and discomfort; include perceptual differences within the target population. A single trigger can only find obvious problems and cannot serve as formal passing evidence.
• Implementation side: check whether each signal has a corresponding condition-verification record; an unverified condition is either removed from the declaration or, under that condition, routed through H5's alternate channel.

CounterexamplesUnder-delivery — the "message sent" haptic is completely imperceptible when the phone is on a desk, so the user resends repeatedly; over-delivery — to guarantee it's felt even in a pocket, every signal is uniformly cranked to maximum, so every tap feels like being flicked when held in the hand.

H1-2Signals that must be distinguished are distinguishableMUST¶

One-line summary: Signals carrying different meanings must remain distinguishable even at the weakest tier and in degraded form, not merely have different waveforms.

Applies toWhen a product has two or more haptic signals carrying different meanings that the user may need to distinguish.

RuleBetween haptic signals carrying different meanings, the user MUST still be able to distinguish them at the target device, at the user's selected intensity tier (including the weakest tier), under the declared conditions, and in defined degraded forms. Relying solely on a subtle amplitude difference for distinction SHOULD be avoided — rhythm (pulse count and spacing), duration, envelope, or texture are usually more stable. A design that encodes distinction along a single dimension (including amplitude alone) MUST provide distinguishability evidence covering all the conditions above; when the evidence is insufficient, add another dimension or switch to an equivalent channel. Distinguishability MUST be verified, and "whether it feels different" MUST be kept separate from "whether the meaning can be recognized": the former may use paired discrimination without cueing the semantic; the latter is tested using the learning method the product actually provides, recording the teaching content and number of training trials — guessing the meaning wrong before any teaching is not equated with being perceptually indistinguishable.

Boundary condition: This rule does not require every pair of signals in the product to be pairwise distinguishable, only that pairs the "user may need to distinguish" are distinguishable. Variants made within the same semantic category for expressiveness (such as three tiers of collision weight) are not signal pairs that must be distinguished.

Design applicationPrefer rhythm over intensity to carry the distinction — the difference between "two short, one long" and a single tap is far more stable than the difference between "medium intensity" and "slightly above medium." Record the distinguishing dimension for every pair of signals that must be distinguished.

Verification examples

• User side: first do same/different paired discrimination in random order, then teach the meaning per the product's actual guidance and test random recognition; record detection rate, the confusion matrix, and the consequence of misjudgment separately, evaluated against pre-defined acceptance criteria.
• Implementation side: for every pair of signals that must be distinguished, build a confusion matrix at the target device, the user's weakest tier, and defined degraded forms; do not pass it merely because "the waveforms differ," and do not fail it merely because "only one dimension was used" — the criterion is whether the distinguishability evidence holds under the conditions above.

CounterexamplesUnder-delivery — "sent successfully" and "sent failed" use the same single tap, just with the failure one slightly stronger, so the user relies entirely on looking at the screen; over-delivery — to make every semantic distinguishable, a dozen-plus signals with different rhythms are created, and the user can't remember any of them (also violating H2-4 and H7-4).

H1-3Calibrated to the declared contextSHOULD¶

One-line summary: Held in hand, set on a desk, in a pocket, or worn on the wrist are not the same thing.

Applies toWhen the product may be used across multiple grips, wearing positions, or environmental conditions.

RuleThe product SHOULD declare its primary usage conditions and calibrate signal parameters per condition; when context-detection capability exists, it SHOULD adjust intensity or switch to another channel accordingly. Context adjustment MUST NOT exceed H6-4's safety ceiling, and MUST NOT restore intensity on the grounds of "the context requires it" after the user has already lowered intensity or turned haptics off (see H6-2). When the context cannot be detected, it SHOULD be handled per the declared primary context, not assumed to be whichever context is most favorable for perception.

Design applicationTreat context as a first-class token citizen (haptic.context) rather than an implementation detail; for motion and wearable scenarios, determine a baseline context during the design phase rather than reinforcing it with a patch after release.

Verification examples

• User side: repeatedly test the same signal's detectability and comfort separately under the declared handheld, desk, and pocket conditions; do not treat a single trial playback as a pass.
• Implementation side: check that context adjustment only weakens or reroutes, never strengthens without a ceiling; check that the user's setting always takes priority over context adjustment.

CounterexamplesUnder-delivery — a wrist device reuses the phone's signal parameters and is completely imperceptible while worn; over-delivery — detecting "possibly in a pocket" raises every notification to maximum, startling the user when they're holding it in hand.

H1-4Do not assume individual consistencySHOULD¶

One-line summary: Perceptual thresholds vary by person; a single intensity does not work for everyone.

Applies toProducts aimed at an unspecified user population.

RuleThe product SHOULD NOT assume all users perceive the same signal the same way; device contact mode and individual perceptual differences affect the experience — some people find it hard to detect, others find it uncomfortable. When actual capability supports it, the product SHOULD offer intensity scaling or verified discrete tiers (requirements in H6-1), and MUST NOT use "most users can feel it" as a reason to waive the alternate channel (H5-1).

Design applicationTreat intensity scaling as infrastructure, not an accessibility add-on; explicitly include haptic-perception differences in user-study recruitment criteria, rather than assuming all participants are "typical."

Verification examples

• User side: test the same set of signals among participants spanning different age groups and known perceptual differences, recording the distribution of both detection rate and discomfort rate.
• Implementation side: when intensity control is offered, confirm it takes effect across every declared signal; a device that offers only on/off does not present a fake slider.

CounterexamplesUnder-delivery — every parameter is calibrated to a 25-year-old engineer's fingers, and older users receive no reminder at all; over-delivery — building an item-by-item haptic calibration wizard for every user, and most people abandon it by step three.

H1-5Playback is not deliveryMUST¶

One-line summary: The system calling the actuator does not mean the user felt it.

Applies toAny scenario that uses haptics as a means of notification, confirmation, or reminder.

RuleThe system MUST NOT treat "the haptic interface was called" or "the actuator executed" as "the user has been informed." The interface itself cannot confirm perception or understanding, so any flow that depends on the user being informed MUST advance its state based on the user's actual action or another confirmable signal, not on whether the haptic played. Ordinary information retains an equivalent expression per H5-1; important information under H5-2 also retains a checkable channel.

Basis and reference: This is one of the key differences between haptics and vision — a UI element can remain on screen waiting to be seen, though the UI having been shown likewise does not mean the user has understood it; a haptic occurs and then vanishes, and whether it is perceived depends on whether the device was in contact with the body at that moment. Most design errors stem from treating a haptic as a "delivery" rather than an "attempt."

Design applicationDistinguish playback state from business-awareness state; it is fine to record "haptic reminder attempted," while a business state requiring confirmation depends on the user's action.

Verification examples

• User side: with the device left on a desk, trigger a reminder that requires a user response, and confirm the reminder can still be discovered and handled afterward.
• Implementation side: check whether a playback receipt is used to advance a state such as "user informed / consented"; the playback engine's own scheduling, completion, or resource release does not qualify as such a state.

CounterexamplesUnder-delivery — after "the user was reminded via vibration," the to-do is marked notified and further prompts stop, while the device was actually in a bag; over-delivery — appending a popup after every haptic asking "did you feel that?"

H1-6Avoid interfering with capture and the surrounding environmentSHOULD¶

One-line summary: Avoid interfering with capture and the surrounding environment.

Applies toUsing haptics during capture, recording, voice recognition, inertial sensing, or in a quiet shared environment.

RuleHaptics may introduce mechanical noise and sensor disturbance. The product SHOULD verify the impact while these functions are running, and choose suppression, attenuation, or a timing change based on the result; feedback that has already made a critical task unusable MUST NOT continue to be issued. A sensor signal produced by the vibration MUST NOT be mistaken for a user action and cause a repeated trigger.

Design applicationCompare results separately for handheld versus a hard desk, and with recording and capture turned on; still check for mechanical vibration noise after muting audio.

Basis and reference: Apple HIG notes that haptics may interfere with the camera, gyroscope, and microphone. See Playing haptics.

Verification examples

• User side: compare recording, capture, and normal task performance with and without haptics.
• Implementation side: inject a vibration disturbance and confirm it does not repeatedly trigger an action; record the handling rule and applicable devices.

CounterexamplesUnder-delivery — the recording-start feedback gets picked up on the audio track, and voice detection then triggers the next feedback; over-delivery — to eliminate recording noise, all operation feedback is permanently disabled even after recording has ended.

3.2 H2 Distinguishable in meaning¶

The business meaning of a haptic must be learned; physical analogies such as mechanical collision can help understanding, but this cannot be used to assume the user naturally knows which signal means "submission succeeded." This principle therefore governs the mapping relationship between signal and meaning itself: whether the mapping is unique, whether it is stable, whether it is consistent with the vocabulary the user has already learned in the system, and whether the product knows how many words it has in total. A haptic vocabulary needs to be managed just like interface copy — the only difference is it has no spell-checker.

H2-1Same meaning, same signal; different meaning, distinguishableMUST¶

One-line summary: The same meaning is always the same signal within the product.

Applies toAll products that use haptics.

RuleThe same meaning MUST map to the same haptic signal within the product, and MUST NOT change because of UI location, module ownership, or team differences; different meanings MUST NOT share the same signal, unless they genuinely need no distinction for the user (judgment and verification in H1-2). Introducing a one-off signal for a single screen's expressiveness that conflicts with the global mapping is a violation of this rule.

Boundary condition: The degraded rendering of the same meaning is allowed to differ across devices with different capabilities, but it MUST still fall within the same semantic mapping (see H4-3). This is not an exception to this rule.

Design applicationConsolidate ownership of the haptic mapping at the design-system layer rather than leaving it to each business module to decide; build haptics into the component library rather than letting each call site choose its own.

Verification examples

• User side: trigger events with the same meaning in three different modules of the product, and confirm the user does not believe different things happened.
• Implementation side: cross-check the actual signal at each call site against the semantic registry (H2-5); the same meaning with different signals, or different meanings requiring distinction sharing one signal, is non-conformant.

CounterexamplesUnder-delivery — "added successfully" on the home page is a double tap, and "added successfully" in the cart is a single tap, so the user never builds the association; over-delivery — for absolute consistency, every module is banned from using haptics except for three global signals, cutting even clearly valuable feedback like drag-snap.

H2-2Follow system semantics, do not repurpose themMUST¶

One-line summary: The haptic vocabulary a platform has established is one the user has already learned; do not overwrite it.

Applies toRunning on a platform that has established system-level haptic semantics (iOS's notification / impact / selection, Android's HapticFeedbackConstants and predefined effects, etc.).

RuleFor a scenario where the platform has already established semantics, the product MUST prioritize following the system's corresponding signal; repurposing system semantics is prohibited — a signal meaning error MUST NOT be used to mean success, and a selection-change signal MUST NOT be used to mean an irreversible operation completed. The product's own signals MUST NOT conflict in meaning with system semantics, and MUST NOT form a competing mapping against a system signal within the same scenario category.

Basis and reference: System semantics are learned repeatedly by the user across apps on the device, and their learning cost has already been paid by the platform; overwriting it means making the user relearn it inside your product, and it also pollutes their understanding in other products. Both Apple HIG and Android's haptic design principles list "stay consistent with the system" as a top recommendation. See reference.md for sources.

Design applicationFirst cross-check the product's semantic registry against the platform's semantics; adopt directly whatever matches, and only consider custom signals for what doesn't, declaring capability and degradation per H4.

Verification examples

• User side: have users familiar with the platform judge, without looking at the screen, whether what just happened was success or failure.
• Implementation side: check each entry in the semantic registry that follows a system effect, confirming the constant used matches its semantics.

CounterexamplesUnder-delivery — using the system's error haptic to mean "added to favorites," because "that one feels better"; over-delivery — out of fear of conflict, refusing to use haptics even for a button tap, a scenario where the platform already has a clear constant.

H2-3Semantics are learnable and stableSHOULD¶

One-line summary: Let the user learn the meaning through real operation, without relying on guessing or rote memorization.

Applies toSignals whose meaning the user needs to recognize, especially a product's custom haptic vocabulary.

RuleThe product SHOULD let the user understand the meaning through real operation, by pairing the haptic with a stable event and UI state; the teaching method and amount of training used for acceptance SHOULD match what the product actually provides. An already-established signal's meaning MUST NOT be quietly reassigned to a conflicting meaning, and the user's understanding MUST NOT be claimed merely because test staff are familiar with the signal. Necessary teaching SHOULD be brief, skippable, and provide a task path that does not depend on haptic memory.

Design applicationThe first time it snaps to a target, the haptic appears together with a readable target state; provide a voluntary preview entry when extra explanation is needed. Success and failure are learned through the result state, without making the user memorize a rhythm dictionary first.

Verification examples

• User side: distinguish recognition results at first use, after actual guidance, and after a time gap; check misjudgment of important meanings, without letting an overall average mask confusion between success and failure.
• Implementation side: verify that the teaching used in testing genuinely exists in the product; check whether the same signal's meaning is stable across different scenarios.

CounterexamplesUnder-delivery — internal staff who have memorized six vibrations test perfectly, while real users never receive any learning cue; over-delivery — first use requires reciting the haptic vocabulary item by item before continuing.

H2-4Do not use haptics to convey information requiring precise decodingMUST¶

One-line summary: Haptic bandwidth is extremely low; do not use it to encode quantity, identity, or text.

Applies toA scenario considering using haptics to convey information content (rather than merely that an event occurred).

RuleUsing haptics to encode a quantity, identity, sequence number, or text content that the user needs to accurately recognize is prohibited. There is only one exception: the encoding scheme has been explicitly declared a dedicated encoding path, the user has received corresponding training, and the scheme's decodability has been verified on the target population. Such a dedicated path is outside the scope of these guidelines per Appendix B.2; its channel design, training, and acceptance need independent assessment — this rule's exception only acknowledges it exists, and does not mean these guidelines have already given it sufficient requirements. The size of the semantic registry MUST be determined by the target users' recognition performance under actual conditions, with no uniform numeric ceiling lacking applicable evidence; confusion among high-consequence signals is checked with particular care.

Boundary condition: This rule does not prohibit using haptics to express degree (weak/strong, fast/slow, near/far) or process (in progress, approaching a boundary, complete) — these are continuous-quantity expressions haptics are good at, and do not require precise decoding. What it prohibits is moving a discrete symbol system onto the haptic channel.

Design applicationUse vision or hearing when "which one," "how many," or "who" needs to be conveyed; haptics carries only judgments such as "it happened," "arrived," or "crossed a boundary."

Verification examples

• User side: randomly test recognition of every semantic that must be distinguished under the actual learning conditions, recording confusion and reaction time; retest after a long task ends.
• Implementation side: check whether a newly added semantic has a corresponding recognition verification; whether a precise encoding declares its applicable population, training, and verification result.

CounterexamplesUnder-delivery — using vibration count to represent the number of unread messages, and the user loses count by the fourth pulse; over-delivery — out of fear of overload, not even daring to express a single judgment like "reached the boundary" with haptics.

H2-5Semantics are registeredMUST¶

One-line summary: Every signal can be found as a unique entry in a registry; a new one is registered before use.

Applies toAll products that use haptics.

RuleThe product MUST maintain a haptic semantic registry recording each signal's meaning, trigger scenario, required capability (H4-1), and fallback chain (H4-2); a product-initiated haptic call MUST resolve to a unique entry in the registry; feedback built into a standard component may be registered by component and running platform, without requiring the system's internal implementation to be intercepted every time. A new signal MUST be registered before use; the registry MUST be traceable to the effect and configuration actually used, and serve as a shared basis for design and engineering — it MUST NOT exist with only one of them.

Basis and reference: This is what turns H2-1 from a claim into an enforceable mechanism. Without a registry, "same meaning, same signal" can only be kept in someone's memory, and haptic inconsistency will not trigger an error in any automated check — it will only quietly fail in front of the user.

Design applicationToken haptic.semantic.registry references the semantic registry; the registry's signal entries, business facts, and measurement records are not themselves new tokens; the component library consumes the registry, and business code does not directly specify a waveform.

Verification examples

• Implementation side: scan the code's haptic call sites, confirming that proactive calls reference the registry through a unified mapping; platform constants and waveforms may live in the adaptation layer, and a standard component's own feedback should be documented in the mapping and a duplicate addition avoided.
• Implementation side: check whether every registry entry has filled in its capability requirement and fallback chain; a missing one is non-conformant with H4-1, H4-2.

CounterexamplesUnder-delivery — haptics are hardcoded scattered across business code, and no one can say how many kinds of vibration the product has in total; over-delivery — building a process for the registry that requires three levels of approval to add an entry, so the team simply bypasses it and calls the platform API directly.

3.3 H3 Timed¶

A haptic is part of a causal relationship, not a message that can be delivered late. A user presses a button, a finger crosses a tick mark, a payment completes — a haptic is meaningful because it happens right against that event. This principle governs the time relationship between haptics and the user's action, vision, and hearing. It has two failure modes that must be distinguished: excessive latency may cause misattribution; a result haptic that precedes the fact conveys a conclusion that has not yet held. This is a different problem from the small output offset that may exist between modalities.

H3-1Causal binding and a latency ceilingMUST¶

One-line summary: A late haptic is worse than none; once it times out, abandon it rather than replaying it.

Applies toA haptic signal serving as direct feedback for a user action or system event.

RuleEvery feedback-type haptic signal MUST be bound to an event confirmed to have occurred; the product MUST define and verify an onset-latency ceiling for each signal type, so feedback can still be correctly attributed. A request that has already exceeded the ceiling at scheduling time and has not yet been submitted MUST be discarded, and MUST NOT be delayed and replayed — the user will attribute the late vibration to whatever action happens after it, forming an incorrect causal relationship. Latency is counted from when the bound event becomes true to the device's actual onset; the platform call moment only reflects software scheduling. A measured onset margin MUST be reserved before submission; "called before the deadline" MUST NOT be treated as "onset before the deadline"; that direct feedback is omitted when it cannot be shown to still be within its validity window. Android's 10–20 ms refers to button-feedback duration, not onset latency, and an asynchronous result that only becomes true seconds later should not be timed from the click moment either.

Boundary condition: This rule does not apply to proactive-notification haptics (reminders, message arrival); that kind of signal does not itself form a causal relationship with the user's current action, and its timing constraints are in H6-2 and H7-2.

Basis and reference: Visual-haptic timing research supports that the actual output moment needs to be measured, but the threshold depends on the task and stimulus. Onset and trailing are simultaneously affected by the actuator, drive, and mounting; a fixed latency cannot be derived from an ERM/LRA name. See reference.md, Section 3.

Design applicationBuild scheduling around real events, and check the actual moment together with the paired visual/audio; when the device cannot meet it, choose a more suitable effect or do not play, instead of substituting a changed number for verification.

Verification examples

• User side: tap repeatedly on the low end of the target device's range, confirming the haptic does not land on the next tap.
• Implementation side: record software scheduling latency, and calibrate the distribution and trailing from event to actual onset using on-device measurement such as an accelerometer or contact pickup; when hardware cannot be observed, note an estimated range. Check that a request already expired at scheduling time is discarded, and an already-submitted short pulse that cannot be canceled is not claimed to be revocable.

CounterexamplesUnder-delivery — when a network response is slow, the tap feedback is queued, and it vibrates only after the user has swiped to the next screen, making them think they mistouched something; over-delivery — to keep latency low, triggering before the event is confirmed (violating H3-4).

H3-2Cross-modal synchronization is verified per scenarioMUST¶

One-line summary: The visual, audio, and haptic output of the same event stay within a measured sync window; a generic offset value is not applied.

Applies toWhen the same event is expressed through haptics and vision or hearing at the same time.

RuleA haptic signal paired with a visual or audio signal to express the same event MUST fall within a sync window the product has verified for that modality combination, device, and task. The window MUST declare the reference event, timing direction, and measurement method; the goal is actual perceived synchrony, and this MUST NOT be shown merely by a shared callback. Timestamps MUST come from a comparable clock; across devices, the clock-alignment error is recorded, and the two devices' local times MUST NOT simply be subtracted. The window may be asymmetric, but the direction and value from a particular visual-haptic experiment MUST NOT be applied directly to audio-haptic pairing, other body parts, or other devices. A direct-feedback event past its valid window that has not yet been submitted is discarded per H3-1; a signal already issued cannot be recalled, so the subsequent scheduling must be corrected.

Basis and reference: Di Luca and Mahnan's (2019) 19-participant VR fingertip-touch experiment reports that haptics lagging vision by under about 50 ms is difficult to reliably detect, with a tolerance of about 15 ms for the haptic leading; the paper also discusses variation across tasks. These results cannot be used directly as an acceptance threshold for other devices, body parts, or audio-haptic pairings. See the original paper.

Design applicationThe animation and the haptic share one trigger moment, rather than each firing from its own lifecycle callback; cross-modal pairing is written into the token (haptic.timing.sync.window).

Verification examples

• User side: judge the sync experience at real speed; slow motion is used only for analysis, not as perceptual verification. Screen recording does not prove actual onset.
• Implementation side: measure the actual output time difference and jitter of the paired signals, checking whether they fall within the verified sync window; a shared event source is an implementation reference, not sufficient evidence.

CounterexamplesUnder-delivery — the haptic vibrates 40 ms before the button animation starts, making the user feel the device is moving on its own; over-delivery — to guarantee strict synchrony, the visual animation is also delayed until after the haptic onset, making the whole interface feel sluggish.

H3-3In continuous interaction, haptics follow the actionSHOULD¶

One-line summary: Haptics for dragging and swiping follow the process, not tacked on at the end.

Applies toContinuous interactions such as dragging, scrolling, swiping, tick selection, snapping, and zooming.

RuleHaptics within a continuous interaction SHOULD change in real time with the interaction state, expressing ticks, boundaries, snapping, and resistance, rather than issuing one summary feedback event at the end of the interaction. The density of segmented feedback SHOULD adapt to interaction speed; discrete pulses that would stack into an obvious trailing buzz during fast swiping MUST NOT continue to be issued — such output both loses its segmentation meaning and falls into the buzzy expression H4-4 prohibits. The total amount is still subject to H7-2.

Design applicationTreat haptics in a continuous interaction as a simulation of physical damping rather than event counting: crescendo as it nears a snap point, a bump when it crosses a boundary, and gone once back in the free zone.

Verification examples

• User side: complete the same swipe at both very slow and very fast speeds, confirming the haptics are usable and not harsh at both speeds.
• Implementation side: measure pulse overlap, distinguishability, and total amount within the product's declared speed range; check whether there is speed-adaptive or equivalent density control. A fixed interval is recorded as non-conformant only when it causes the failure this rule prohibits (merging into continuous buzz, losing segmentation meaning), not judged as a failure merely because "the interval is fixed."

CounterexamplesUnder-delivery — scrolling a long list quickly still buzzes for every item passed, and the hand is numb by the bottom; over-delivery — to avoid merging into a buzz, swipe feedback is removed entirely, and the tick selector loses its most valuable part.

H3-4Haptics MUST NOT precede the factMUST¶

One-line summary: Do not vibrate before the result is determined; a haptic is on the body and cannot be taken back.

Applies toA haptic signal representing a result, state, or consequence.

RuleA result-representing haptic MUST play only after the result has actually been confirmed; triggering early based on an optimistic prediction is prohibited. When an external operation's result distinguishes three states — success, failure, and unknown — the haptic may express only a confirmed success or failure; a success haptic MUST NOT be played for the unknown state, nor should a failure haptic, and instead a checkable channel should state that the current status is undetermined. Unknown MUST NOT be disguised as confirmed failure either.

Boundary condition: This rule does not prohibit a process-type haptic expressing "acknowledged" or "in progress," as long as it genuinely expresses the fact that has already occurred — "the request has been sent" — and is semantically distinguishable from a result-representing signal (see H1-2, H2-1).

Basis and reference: A result haptic cannot be recalled once issued, and an incorrect signal may cause the user to stop checking or leave the flow, so result semantics MUST have a factual basis; this requirement likewise does not allow the visual layer to state an unknown result as already successful.

Design applicationDecide "optimistic UI" and "optimistic haptics" separately; while waiting, it is fine to show acknowledged or in-progress; business success MUST be based on the actual result, and vision, audio, and haptics keep semantic consistency.

Verification examples

• User side: complete a payment or submission under weak-network or server-failure conditions, confirming the user does not feel a success haptic before seeing a failure message.
• Implementation side: inject success, failure, lost receipt, and duplicate callbacks, checking whether the triggering basis proves the business result; entering a response callback or receiving a transport-success code by itself does not prove business success.

CounterexamplesUnder-delivery — tapping to pay plays the success haptic immediately, and a failure message pops up afterward, by which time the user has already put the phone away; over-delivery — delaying every haptic until the entire subsequent flow completes, so even the button-press's immediate feedback is gone (violating H3-1).

3.4 H4 Degrades with capability¶

The haptic that the same piece of code produces can be an entirely different thing on different devices: the rendering is jointly affected by the actuator, drive, mounting, platform tuning, and interface support. A wide frequency band is not the only condition for realizing continuous change, and crisp or rich expression also cannot be judged from a device's name alone. This principle governs the objective fact of device-capability differences: the design MUST acknowledge that it does not know what the user's device can do, so every signal declares what it needs, and when it cannot be done, it follows a predetermined path rather than leaving it to the platform's discretion. The most dangerous failure of degradation is not a worse-sounding effect, but semantic drift — degrading a success signal into a long buzz for the sake of "still being felt," when a long buzz happens to mean error in this product.

H4-1Declare the required capability and support statusMUST¶

One-line summary: Support is judged by effect, primitive, amplitude, and envelope capability, not by device model alone.

Applies toProducts released across multiple device forms or multiple hardware tiers.

RuleEvery signal MUST declare the capability its effect requires, and this MUST be checked against the target output device and running platform. The capability profile distinguishes at least no haptics, not supported, supported, and unknown; specific system effects, composed primitives, amplitude control, envelope, and output location are checked as needed. A custom envelope MUST also have its parameter combination verified: frequency range, control-point count and spacing, total duration, and the end condition the platform requires — checking merely that the interface exists is not enough. Unknown MUST NOT be treated as supporting a custom effect; but a platform predefined effect being "unoptimized / unknown" does not mean "cannot be played" — a system-level degradation that the documentation commits to and the product has verified may be used. After the running platform or peripheral changes, the affected capability MUST be re-determined.

Design applicationTreat target-device capability as an input at the design stage, not a fix during adaptation: before deciding "this needs a textured scroll feedback," first confirm what proportion of the target device matrix can achieve it.

Verification examples

• Implementation side: separately simulate no actuator, a missing required primitive, no amplitude control, envelope unsupported, and unknown support status; check each degradation path.
• User side: verify degradation quality on actual devices; an API's reported support does not substitute for perceptual and semantic verification.

CounterexamplesUnder-delivery — the entire haptic set is designed for a flagship's wideband actuator, and everything degrades into the same buzz on mid- and low-end devices; over-delivery — maintaining a fully independent haptic design for every hardware tier, with four semantic registries drifting apart from each other (violating H2-1).

H4-2The fallback chain is defined; no silent failureMUST¶

One-line summary: When it cannot be done, degrade along a defined path; not silently failing to play or degrading into a plain buzz.

Applies toAny signal that may encounter insufficient capability, an unknown state, or a device with no output.

RuleEvery signal MUST have a resolvable, acyclic fallback chain with an explicit endpoint; failing without a defined path when a capability condition does not hold is prohibited. The final item may be "do not play," with the conveyed information retained through H5-1's equivalent channel; a purely textural piece of feedback may simply be omitted. For direct-operation feedback such as taps and selections, degrading a crisp piece of feedback into an obviously trailing buzz is prohibited; proactive attention alerts such as incoming calls or alarms may use a verified on/off pattern, still subject to user settings, duration, and total-amount limits. A platform's degradation commitment for its predefined effects MUST NOT be applied to a custom composition.

Basis and reference: Android separately explains system-level degradation of predefined effects and capability checking and self-degradation for custom compositions, and distinguishes the applicability of buzzy expression between touch feedback and attention alerts. These guidelines organize them into a checkable degradation contract, without claiming the platform lacks a degradation mechanism. See the Android API documentation.

Design applicationThe fallback chain is written into the token (haptic.capability.fallback.chain), executed uniformly by the component library, rather than left to business code to judge case by case.

Verification examples

• User side: complete the primary task on the lowest-capability device, confirming there is no "pressed and nothing happened" or "keeps buzzing" experience.
• Implementation side: force every signal to degrade to each tier, recording the actual rendering tier by tier; check whether "do not play" has an explicit reason and equivalent information, and whether direct-operation feedback shows an unsuitable trailing effect.

CounterexamplesUnder-delivery — a wideband texture effect simply doesn't play on an ERM device, and the user thinks the swipe had no effect; over-delivery — to "at least make the user feel something," every signal on a low-end device is replaced with a 300 ms long buzz.

H4-3Degradation does not change the semanticMUST¶

One-line summary: Success must still be success after degradation; it cannot turn into an error.

Applies toAny signal that has a fallback chain.

RuleA degraded signal MUST still fall within the mapping range of its original semantic; degrading across semantics is prohibited; no tier in the fallback chain MUST be identical to, or so similar as to be indistinguishable from (judged per H1-2), another meaning in the semantic registry that requires distinction. When a given tier genuinely cannot express the original semantic without overstepping, the correct degradation result is "do not play, and route through the alternate channel," not borrowing some other, similar signal. The relationship between frequency and intensity is judged only within a declared, comparable effect family, and is not converted across families.

Basis and reference: This is a corollary of H2-1 on the capability dimension, but the regulated object differs: H2-1 governs the mapping at design time, while this rule governs mapping drift caused by runtime degradation. The latter never appears in any design mockup — it only appears in the hands of a user with a low-end device.

Design applicationRun a cross-tier collision check on the semantic registry — lay out every signal's rendering at every degradation tier, and check whether two different meanings land on the same one.

Verification examples

• User side: on the lowest-capability device, have users distinguish between success and failure result feedback.
• Implementation side: judge by the unit of semantics the user can understand, not by whether the API call succeeded; check every pair of signals the user must distinguish, tier by tier; a pair that becomes indistinguishable after degradation while still carrying a distinguishing responsibility is recorded as non-conformant.

CounterexamplesUnder-delivery — the success signal degrades into one longer vibration on a narrow-band device, which happens to be identical to the error signal, and the user on a low-end phone cannot tell them apart at all; over-delivery — to absolutely avoid any collision, every fallback chain is cut down to only "do not play," losing haptics even on devices that could support them.

H4-4Prefer the platform's predefined effectsSHOULD¶

One-line summary: A custom waveform is the exception, not the default; a long buzz is not interaction feedback.

Applies toA scenario where the platform provides predefined haptic effects or primitives.

RuleWhen the platform already provides a corresponding predefined effect or primitive, the product SHOULD prioritize using it rather than synthesizing its own waveform — a predefined effect is tuned by the platform to each device's actuator characteristics, giving more consistent cross-device rendering. A custom waveform SHOULD be used only when a predefined effect genuinely cannot express the target semantic, and MUST come with both a capability declaration (H4-1) and a fallback chain (H4-2). Prohibited: substituting an obviously trailing long buzz for a brief, direct-operation feedback; the applicability boundary for proactive attention alerts is in H4-2.

Basis and reference: Android's haptic design principles list "prefer predefined constants and effects" as the first item, and explicitly require avoiding legacy one-shot vibration (which produces a buzzy expression on low-performance actuators). See reference.md for sources.

Design applicationMake "can this be expressed with an existing system effect" the default question during design review; a custom-effect proposal needs to state what it buys.

Verification examples

• Implementation side: tally the number of custom waveforms and their recorded rationale; check the code for any legacy long-buzz interface calls.

CounterexamplesUnder-delivery — to "have our own brand feel," every system effect is replaced with an in-house waveform, which ends up worse than the system effect on half the devices; over-delivery — insisting on predefined effects only, giving up even the continuous snap feedback the product genuinely needs.

H4-5Playback interruption and recovery are definedMUST¶

One-line summary: After an interruption, recover only within the same still-valid interaction, up to a predefined number of attempts; old events are not replayed.

Applies toUsing a custom playback engine, continuous feedback, or when background suspension and peripheral disconnection may occur.

RuleThe product MUST distinguish its own observable states — not played, submitted, ended, suppressed, interrupted, and failed; unknown MUST NOT be recorded as completed. An already-stale discrete event MUST NOT be automatically replayed after an interruption. When resuming a continuous effect is allowed, the interaction MUST first be verified as still valid, the user as still permitting it, and the device as still available, before creating output per the current interaction state. A recovery attempt is made only within the same, still-valid, ongoing interaction, and its count and termination condition MUST be predefined; once the ceiling is reached or that interaction has become invalid, automatic recovery stops, and a haptics-free task path is retained. A frame update within the same interaction does not reset the count; only a new, independent interaction may begin a new recovery cycle. A discrete old event is not replayed on account of recovery.

Design applicationAttribute the playback lifecycle to a specific interaction; leaving the interaction invalidates old requests. Rebuilding the engine only restores capability; it is not a reason to play again.

Basis and reference: The Apple Core Haptics documentation describes the mechanism for interrupting and rebuilding the player. Recovery semantics and bounded retries are design requirements of these guidelines; see Preparing your app to play haptics and resetHandler.

Verification examples

• User side: switch to the background while dragging, then return, and confirm no old vibration appears; a new action still gets feedback.
• Implementation side: inject suspension, engine reset, disconnection, and recovery failure, checking that old events are invalidated and retries are bounded.

CounterexamplesUnder-delivery — after an incoming-call interruption, every recent tap re-vibrates; over-delivery — requiring the user to re-enable haptics before every recovery, adding operational burden even for an ordinary interruption.

H4-6Output location and recipient are explicitMUST¶

One-line summary: Output location and recipient are explicit.

Applies toWhen the same product can output to multiple devices, multiple controllers, or multiple vibration locations.

RuleEvery signal MUST be bound to the current interaction's recipient, device, and needed location. After the input device, controller ownership, or connection state changes, the routing MUST be re-checked; misdirecting to another user's device or broadcasting to all devices is prohibited. Output carrying directional meaning MUST have its left/right and positional mapping verified; when the target is unavailable, an explicit alternate route or not playing is used — switching to a non-equivalent location without authorization is prohibited.

Design applicationDirect-operation feedback prioritizes matching the device currently being operated; multi-device alerts are deduplicated by event identifier. When location affects semantics, register positional capability together with its degradation.

Basis and reference: Apple's Game Controller uses locality to specify a vibration location, demonstrating that multi-location output is achievable; object binding and misdirection prevention are inferences of these guidelines. See WWDC20 controller capabilities.

Verification examples

• User side: switch controllers, left/right hand, or between phone and peripheral, confirming the feedback location matches expectations.
• Implementation side: swap the device ownership of two players and disconnect the target device, checking routing and deduplication.

CounterexamplesUnder-delivery — after player A acts, player B's controller vibrates; over-delivery — a device picker pops up before every tap, even though the current interaction's target is already clear.

3.5 H5 Not the sole channel¶

A haptic is a momentary channel that cannot be reviewed and may not have been received at all (see H1-5). It has an advantage in scenarios that don't require looking at a screen — the user doesn't need to look anywhere, and it doesn't occupy hearing — but a speed advantage does not mean it can carry exclusive delivery responsibility. This principle governs the division of information labor between haptics and other channels: haptics can arrive first, but cannot be the only one that arrives. This is also the premise on which H6 rests — the user has the right to turn haptics off precisely because nothing is lost once it's off.

H5-1Haptics MUST NOT be the sole channelMUST¶

One-line summary: Information carried in a vibration MUST also have a non-haptic equivalent expression.

Applies toAny scenario that conveys information through haptics.

RuleIn the general-purpose products covered by these guidelines (see Appendix B.2), any information conveyed through haptics MUST have an equivalent non-haptic expression; information loss or a feature becoming unusable because the user turned haptics off, the device has no actuator, capability degraded to "do not play" (H4-2), or the signal was not perceived (H1-5) is prohibited. A dedicated device where haptics is the primary channel does not fall under this rule; its equivalence requirement is assessed separately per B.2. The equivalent expression MUST carry the same information, not merely hint that "something happened."

Boundary condition: This rule does not require every haptic to be accompanied by a visual or audio prompt. The equivalent expression may exist in a UI state the user can actively check, and need not occur at the same time as the haptic — what is required is that no information is lost, not that the channel count doubles. Pure textural embellishment (conveying no information) does not fall under this rule.

Basis and reference: XAG 110 explicitly recommends that important game cues have another output method; these guidelines retain equivalent information as an experience commitment for general-purpose products. WCAG 1.3.3 constrains operating instructions that rely on sensory characteristics; it cannot be directly stated that "every haptics-only design violates WCAG AA." See XAG 110 and the W3C explanation.

Design applicationWhen designing a haptic, simultaneously answer "after it's turned off, where does the user learn this"; being unable to answer means this piece of information still has no home.

Verification examples

• User side: complete the same set of tasks with all haptics turned off, confirming all information remains available.
• Implementation side: check the semantic registry entry by entry, annotating each signal's corresponding non-haptic equivalent expression; a gap is non-conformant.

CounterexamplesUnder-delivery — in silent mode, an incoming call and an alarm are distinguished only by vibration, and once haptics is off the two are completely indistinguishable; over-delivery — every haptic is paired with a toast, drowning the interface in confirmation prompts.

H5-2Safety-critical information needs a coexisting, checkable channelMUST¶

One-line summary: A haptic is momentary; miss it and it's gone. Important things need to stick around.

Applies toA prompt involving safety, an irreversible consequence, a deadline, or a cost.

RuleWhen such a prompt uses haptics, a checkable channel MUST coexist — a state, record, or entry point the user can still proactively find the information from after missing the haptic. Haptics may carry the role of "arrives fastest" in this kind of scenario, but MUST NOT carry the role of "the only arrival" or "a one-time arrival." The checkable channel's existence MUST be independent of whether the haptic played successfully. Information requiring an immediate response MUST also be reachable within the response deadline; being checkable afterward does not substitute for timely expression.

Boundary condition: This rule does not require the checkable channel to be presented at the same time as the haptic, nor does it require it to permanently reside on the main screen; what is required is that the user can proactively find it afterward.

Design applicationPlace this kind of prompt's state onto a persistent UI object (a list item, a status area, the notification center), with the haptic serving only as its advance reminder.

Verification examples

• User side: leave the device in another room when the haptic occurs, and afterward confirm the user can still discover and handle the item.
• Implementation side: check the checkable channel of every safety-critical signal one by one; a signal with only momentary presentation is recorded as non-conformant. Being checkable afterward does not substitute for the expression of "currently respondable in time"; the two are checked separately.

CounterexamplesUnder-delivery — a watch timer ending vibrates only once, the user didn't feel it at the time, and afterward there is no state on the UI showing it has ended; over-delivery — turning every prompt into a permanent, undismissable banner.

H5-3Haptics reinforce, they do not replaceSHOULD¶

One-line summary: Haptics lower the cost of confirmation; they do not replace confirmation itself.

Applies toA flow requiring the user to make a judgment or confirmation.

RuleHaptics SHOULD be used to lower the cost of confirmation and improve localization efficiency — sparing the user from looking down at the screen, from double-checking, from waiting for visual feedback — and SHOULD NOT be used to replace a necessary explanation or confirmation step. For an operation involving an irreversible consequence, haptic feedback MUST NOT substitute for user-readable confirmation information.

Design applicationFor each haptic point, clearly state which kind of benefit it belongs to and what specific cost it saves (one look-down, one visual search, one double-check); this is also the statement H7-4 requires.

Verification examples

• User side: per the benefit this haptic point declares, compare the corresponding metric (number of visual fixations, completion time, error rate, or subjective burden) with and without the haptic; no difference on a single metric does not prove it has no benefit at all — it must be checked against which specific cost it declared.

CounterexamplesUnder-delivery — a delete operation gives only one haptic, with no readable confirmation at all; over-delivery — believing haptics can never replace anything, so a value-confirmation dialog is still forced to pop up on a slider that already has clear haptic feedback.

H5-4The all-off condition enters routine acceptanceMUST¶

One-line summary: With all haptics off, the primary task can still be completed — and this must actually be tested.

Applies toAll products that use haptics.

RuleThe product MUST make "all haptics off" one of its routine acceptance conditions, covering every primary task path; under this condition, no information gap, no blocked flow, and no artificially added punitive step such as nagging or extra confirmation are permitted. The criterion is "whether the target user can obtain the necessary information within the time the task requires," not "the action count being exactly identical to when it's on" — a reasonable difference in viewing or operation that the channel switch itself introduces (such as switching to proactively checking a state once, see H5-1) does not count as a violation, but its reachability and burden MUST still be verified; hiding information on a secondary history page where it arrives too late to respond does not pass on the grounds of "being checkable." This acceptance step MUST NOT be run only within a dedicated accessibility track, nor skipped on the grounds that "it's on by default so it doesn't affect most users."

Basis and reference: This turns H5-1 from a statement into an executable acceptance step. Empirically, an equivalent expression is most easily omitted in a feature added later, and this kind of omission only surfaces under the all-off condition.

Design applicationAdd all-haptics-off to the regression test's device/setting matrix, treated on equal footing with dark mode and large text.

Verification examples

• Implementation side: run a regression pass of the primary tasks under the all-haptics-off configuration; a defect found is treated as a regular defect, not downgraded to an experience suggestion.

CounterexamplesUnder-delivery — acceptance is run only on devices with haptics on, so after a new feature ships, users with haptics off receive no such prompt at all; over-delivery — to cover the all-off condition, redundant prompts are patched in everywhere on the UI for users with haptics off, making it noisier than when haptics is on.

3.6 H6 Body-controllable¶

When a device contacts the body, vibration may cause discomfort; accessibility guidelines specifically call for attention to users with chronic pain or sensory-processing differences. This principle governs haptics' effect on the body and the user's control over it. A user's authority over how their own body is used takes priority over any experience goal or commercial goal of the product.

H6-1Can be turned off, adjusted, and turned off by categoryMUST¶

One-line summary: Can be turned off within the product; when intensity adjustment is supported, a genuine control is provided, and it can be turned off by category when there are multiple usages.

Applies toAll products that use haptics.

RuleThe product MUST provide an in-app entry that fully turns off haptics. When usable intensity control or calibrated strong/weak effects exist, the product MUST provide the corresponding adjustment; when there are two or more usages, the product MUST allow those categories to be turned off separately, at minimum separating direct-operation feedback from proactive alerts. The control UI MUST match the actual capability: when continuous intensity adjustment is not supported, verified discrete tiers may be offered; when only on/off capability exists, only an on/off control is offered — no ineffective slider. Turning off MUST take effect at the playback entry and stop cancelable output in progress; it MUST NOT merely set a platform parameter to 0 and assume there is no output.

Basis and reference: XAG 110 recommends an off switch, intensity adjustment, and alternate channels; Game Accessibility Guidelines states the necessity of an in-game off switch, and recommends fine-tuning and per-usage control. These are game-domain design references, not a unified standard requiring a continuous slider on every platform. Android's combined primitives may still output at scale=0; see the custom effects documentation.

Design applicationPrioritize offering a simple switch; add the corresponding control incrementally as multiple usages and intensity-adjustment capability exist. A preview is triggered only by the user, using the actual routing and limits, and does not vibrate automatically every time settings are opened.

Verification examples

• User side: have the user turn off only notification-type haptics while keeping operation feedback, confirming the setting takes effect and does not affect other categories.
• Implementation side: verify off, the weak tier, and a newly added signal separately; on a device with no amplitude control, check whether a non-zero parameter is mapped to full intensity — when the weak-tier promise cannot be met, do not play or choose a verified alternate effect.

CounterexamplesUnder-delivery — there is only one "vibration on/off," so keeping button feedback means enduring every push-notification vibration too; over-delivery — splitting haptics settings into a dozen-plus independent switches filling a whole screen, and no one can find the one they want.

H6-2System settings take priorityMUST¶

One-line summary: System-level mute, focus, and haptics settings MUST NOT be bypassed.

Applies toRunning on a platform that provides system-level haptics, mute, or focus-mode settings.

RuleThe product MUST execute per the settings and call policy the platform specifies for the current usage; mute does not mean all haptics are off, and focus does not necessarily block proactive-action feedback. System-level settings MUST take priority over the product's own settings: the product may further tighten within what the system allows, and providing an option to "override the system setting," or bypassing it by any means, is prohibited. After the user turns haptics off, the product MUST NOT resume playback on the grounds of "important reminder," "safety-related," or "just this once"; such information routes through another channel per H5-1, H5-2. An adjustment resulting from context detection (H1-3) likewise MUST NOT override the user's setting.

Boundary condition: This rule does not exclude an exception channel the platform itself defines (such as a system-level emergency alert); that kind of channel's behavior is decided by the platform, not the product, and the product MUST NOT imitate it on its own.

Design applicationPrioritize semantic interfaces and notification channels that comply with system policy; when the platform does not expose a settings query, comply with its call contract, without claiming the ability to read every system state.

Verification examples

• User side: turn on the system's focus mode and trigger various events, confirming the product's behavior matches the system setting.
• Implementation side: check for a direct call path that ignores system state; its existence is non-conformant.

CounterexamplesUnder-delivery — the user turned haptics off in the system, and the app still vibrates in the name of "critical notification"; over-delivery — once the system's focus mode is on, even the feedback for a user's active tap is stopped, making the interface feel unresponsive.

H6-3Do not initiate haptics for commercial purposesMUST NOT¶

One-line summary: Do not use vibration for marketing, retention, urging, or competing for attention.

Applies toAny proactive haptic not triggered by the user's current action.

RuleInitiating a haptic the user did not request, for marketing, engagement-boosting, retention, time-limited urging, or competing for attention, is prohibited. A proactive haptic MUST correspond to an event the user has subscribed to, or progress on a task the user has delegated; the product MUST NOT manufacture urgency through haptics, nor use haptics as a means to raise open rates. This prohibition is not relaxed because the user "did not explicitly decline" — not declining is not consent.

Basis and reference: This is these guidelines' design stance on unrequested bodily disturbance, based on the predictability of proactive alerts and the user-control commitment; it does not claim haptics is a uniquely unavoidable channel, nor is it written as an existing industry ban.

Design applicationIn haptic-plan review, make "is this event something the user subscribed to" the admission question for a proactive haptic; unrequested promotions, re-engagement campaigns, and content recommendations get no haptic; an event with an explicit subscription still needs its usage and system notification settings checked.

Verification examples

• Implementation side: tally every proactive haptic's trigger source, confirming one by one that it corresponds to an event the user subscribed to or a task the user delegated; one with no such correspondence is non-conformant.

CounterexamplesUnder-delivery — vibrating when a cart item's price drops even though the user never subscribed, and vibrating again right before a countdown ends; over-delivery — stripping haptics even from an important, time-bound reminder the user explicitly subscribed to, causing a genuinely needed reminder to be missed.

H6-4Intensity and duration are bound by a safety ceilingMUST¶

One-line summary: The ceiling comes from the body and the device, not from an experience goal.

Applies toAll haptic output, including custom waveforms and continuous haptics.

RuleA haptic's intensity and duration MUST be bound by a ceiling, determined based on the device or platform's allowed output boundary, contact condition, and applicability assessment for the target population; it MUST NOT be loosened by the product's experience goal or an emphasis need. Using a long, continuous haptic to create pressure, urge, or obstruct the user from completing an action is prohibited. A continuous or repeated haptic MUST have a total-duration ceiling that includes repetitions and gaps, and an automatic stop condition; when the user turns it off, cancels, or ends the owning interaction, a stop request MUST be issued immediately, and the cancelable output MUST end within the device's measured stop deadline. Recalling an already-issued short pulse MUST NOT be promised; an ordinary drag update is not a cancel action and SHOULD NOT be uniformly treated as a stop.

Boundary condition: This rule does not target dedicated devices whose core function is continuous haptics (massage, rehabilitation, professional haptic displays); such products' ceilings are determined by their domain specifications, and their stop mechanisms must also be verified against their domain standards.

Design applicationWrite the ceiling determined through device specification and product assessment into a resolvable policy, and enforce it at the output layer (haptic.intensity.limits.ref, haptic.texture.duration.max, haptic.playback.stop.max_latency); when the platform does not expose the physical amplitude, record the interface's control boundary and measurable output rather than fabricating a value; a frequency quota or a comfort test is not human-safety certification.

Verification examples

• Implementation side: construct an out-of-bounds configuration and a case where the ceiling is reached during operation; confirm the former is rejected and the latter stops or is suppressed per a verified policy; do not claim the semantic is still correct by arbitrarily truncating an unknown waveform.
• Implementation side: during a continuous haptic, turn off the switch, cancel, or leave the interaction, measuring the stop deadline; a normal drag update still gets feedback per H3-3.

CounterexamplesUnder-delivery — an error message uses a 2-second continuous strong vibration to "draw attention," and a user with limited hand mobility cannot dismiss it quickly; over-delivery — pushing the ceiling down to nearly imperceptible, so that H1-1 no longer holds.

H6-5Turning off MUST NOT become a punishmentMUST¶

One-line summary: After turning haptics off, no loss of functionality, no added punitive step, no repeated nagging to turn it back on.

Applies toWhen the product provides a haptics switch or intensity adjustment.

RuleAfter the user turns haptics off or lowers it, the product MUST NOT remove functionality, artificially add a punitive step, degrade response quality, or repeatedly prompt to turn it back on. A reasonable viewing difference introduced by the channel switch is verified for reachability and burden per H5-4's standard, and is not judged by whether the action count is exactly identical; reducing redundant steps is still the default direction. Guidance about haptics provides, at most, a one-time explanation; repeated nagging MUST NOT occur on every launch, every related action, or every re-entry into settings. The off state MUST be retained within the app's own persistence scope, and MUST NOT be reset by a restart or a configuration reload; when backup restore or cross-device sync is offered, the preference-restoration and conflict rules MUST be defined, preventing an old "on" value from overriding a more recent "off" decision. A fresh install with no backup cannot restore an old preference, and this MUST NOT be claimed as possible; a device-specific intensity tier needs to be re-adapted.

Basis and reference: This is the condition that fulfills H6-1. A switch that can be turned off but keeps being harassed afterward, or gets quietly changed back, is no switch at all; and for a user who turned haptics off because of pain, the repeated nagging is itself an ongoing burden.

Design applicationHandle haptics settings the same way as privacy settings under "the user has decided, don't ask again"; explicitly preserve this item when settings are reset.

Verification examples

• User side: complete a representative long task with haptics off, confirming there is no repeated nagging, missing functionality, or artificial obstacle, and record the reasonable burden of the channel switch.
• Implementation side: restart and reload the configuration, confirming the off state is retained; when the product offers backup restore or cross-device sync, also check the corresponding path.

CounterexamplesUnder-delivery — after turning haptics off, every launch still pops up "turn on haptics for a better experience," and the default is restored automatically after a configuration reload; over-delivery — because prompting is disallowed, not even giving the one-time, first-entry note "this app uses haptic feedback, adjustable in settings."

3.7 H7 Restraint¶

Feedback from multiple features, each moderate on its own, can still stack into excessive disturbance or mutual masking. H7 manages the product's shared output frequency, total duration, and priority, and checks the actual benefit through long-task testing. A budget constrains disturbance; it cannot guarantee every critical reminder will be felt.

H7-1Intensity matches importance and frequencyMUST¶

One-line summary: More frequent means lighter, more important means stronger; not escalated just because "we want it noticed."

Applies toWhen the product has multiple intensity tiers to choose from.

RuleWithin the same device, a comparable effect family, and the same class of task, signal intensity SHOULD correlate positively with the event's importance and negatively with its frequency: a high-frequency event (scrolling, selection, tapping) SHOULD prioritize a weaker signal within that family that is verified to remain detectable, distinguishable, and comfortable, and only an important, low-frequency event uses a stronger signal. No intensity ranking is made across different effect families. Raising a feature's intensity tier merely because it "wants to be noticed" is prohibited — an escalation MUST be based on the event's actual consequence for the user, with the rationale recorded. A progressive interaction (drag, snap, approaching a boundary) may strengthen gradually through the process, but its peak is still bound by this rule and H7-3.

Basis and reference: Android's haptic design principles explicitly require linking event importance and frequency to intensity, and give a recommendation of gradual escalation for progressive interactions. See reference.md for sources.

Design applicationAdd "frequency" as a column in the semantic registry, reviewed alongside the intensity tier; the correlation between the two columns is visible at a glance, and outliers naturally surface.

Verification examples

• Implementation side: tally each signal's actual trigger frequency and cross-check it against its intensity tier; every high-frequency, high-intensity entry requires a stated rationale.

CounterexamplesUnder-delivery — every cell of a scrolling list uses medium intensity, and the hand goes numb after three screens; over-delivery — pushing every signal down to the same weakest tier, so an important reminder and a scroll tick feel exactly the same (also violating H1-2).

H7-2The total has a ceiling; over the limit, coalesce or dropMUST¶

One-line summary: Under dense triggering, coalesce or drop; do not queue and replay.

Applies toA scenario that may trigger haptics densely within a short time.

RuleThe product MUST define the minimum interval, per-unit-time ceiling, and shared measurement scope for signals of the same class; overlapping scopes MUST all be satisfied simultaneously, and the budget MUST NOT be reset by splitting the signal group or rebuilding the player. Multiple pulses within one semantic effect MUST NOT be split into multiple business events to confuse the count, and the total output duration is still separately limited. When the ceiling is exceeded, coalescing or dropping is required, and queuing to replay is prohibited (an expired direct-feedback event is covered by H3-1; a proactive alert likewise does not compensate for a backlog of historical events item by item). The coalescing rule MUST be explicit (take the signal with defined priority, take the latest, suppress subsequent ones), and MUST ensure the coalesced result does not create a semantic misdirection. A batch event (batch import completed, multiple messages arriving at once) MUST issue a haptic by event group, not by item.

Design applicationHandle throttling uniformly at the output layer, rather than letting each feature judge for itself "am I vibrating too much" — a single feature will always think it isn't.

Verification examples

• User side: trigger a large number of events at once (e.g., receiving twenty messages simultaneously), confirming the haptic fires once, not twenty times.
• Implementation side: concurrently trigger a signal within the same scope from multiple call entries, confirming the shared ceiling cannot be bypassed; the implementation location alone is not a criterion.

CounterexamplesUnder-delivery — during a group-chat flood, it vibrates for every message, and the phone jumps on the desk; over-delivery — the throttling window is set too long, so two consecutive, different actions by the user get only one piece of feedback, making them think the second one didn't take effect.

H7-3The strongest tier is a scarce resourceMUST¶

One-line summary: A reserved output has a restricted usage and frequency, and other valid information channels are retained.

Applies toThe tier or effect set a product designates a high-salience reserved output — that is, the output set constrained by level.max.reserved_for in the token, regardless of whether it is called "strong" in an enum or implemented as some custom effect. The criterion is "whether it is designated a reserved output," not the enum item's literal name; when the product designates no reserved output, this rule does not apply, but there also must not be an output that in practice long carries that role without being subject to the quota constraint. Having only one light tap, or an effect happening to be the strongest among ordinary effects, does not automatically constitute a reserved output.

RuleA reserved output MUST have an explicitly restricted usage list (such as an irreversible consequence, a safety alert, an event requiring the current action to be interrupted immediately), and MUST have a per-unit-time quota ceiling; once the quota is exceeded, it MUST degrade or route through another channel, and MUST NOT continue to be issued. When the usage list is empty, the product MUST NOT designate a reserved output, nor let any output carry that role in practice. This tier's scarcity MUST be actively maintained — frequent use may reduce its salience, but habituation MUST NOT be described as permanently irreversible, and increasing amplitude MUST NOT substitute for information-channel design.

Basis and reference: This is the haptic-channel analog of "confirmation fatigue": the reason the genuinely important instance works is the restraint that came before it. These guidelines use a quota to constrain disturbance, but the quota value and net benefit still need long-task testing — it is not an existing physiological safety threshold.

Design applicationTreat the reserved output's usage list as a review object; a new application must state whether it is more important than, or equal in importance to, items already on the list.

Verification examples

• Implementation side: tally the call sites and actual trigger frequency of reserved outputs (per the level.max.reserved_for registration, not by enum name); handle, one by one, anything whose usage falls outside the list or whose frequency exceeds the quota. Also check whether there is an unregistered output that in practice carries the reserved role.

CounterexamplesUnder-delivery — every error message uses the reserved output, and the user encounters it a dozen-plus times a day, so a genuine safety alert gets treated as just another form-validation failure; under-delivery (another form) — implementing the most salient effect as a custom effect literally named "medium," to route around the quota; over-delivery — establishing a reserved output but, out of fear of misuse, never using it, so a safety alert feels identical to an ordinary one.

H7-4The default is not to add; if added, state what it buysSHOULD¶

One-line summary: The default answer for adding a new haptic is "don't."

Applies toA design decision to add a new haptic point.

RuleThe default answer for adding a new haptic SHOULD be "don't"; when proposing an addition, the proposer SHOULD state which category of benefit it belongs to, and explain it per that category's standard:

The statement MUST NOT cite only a general reason ("haptics improve the experience," "competitors have it too"), and a texture-category proposal MUST NOT be written up as a functional cost improvement. A haptic point that cannot be explained per its category SHOULD not be added, or SHOULD undergo comparative verification first.

Boundary condition: This rule does not prohibit haptics aimed at texture and delight. What it requires is that such a proposal is likewise subject to review under the total-amount budget (H7-2, H7-3), and states clearly which category it belongs to — what this rule actually intends to stop is presenting a texture proposal as a functional necessity.

Design applicationTurn this into a fixed field in design review, not a one-off discussion; and compare trigger volume against task benefit during ongoing use, avoiding a preset improvement magnitude.

Verification examples

• User side: for a functional cost improvement, run a with/without comparison, observing whether the declared metric (visual-fixation count, operation duration, or error rate) genuinely differs; for a texture proposal, check against subjective evaluation and the trigger-volume budget, not judged by a functional metric.
• Implementation side: check whether every entry in the semantic registry has filled in its benefit category and corresponding explanation; a blank entry, or one where the category and explanation don't match, is reviewed again in the next round.

CounterexamplesUnder-delivery — every new component shipped casually comes with a haptic, and a year later the product has forty kinds of vibration; over-delivery — rejecting every texture-category haptic outright, leaving the product with only three functional prompts, making the interaction feel stiff.

H7-5Concurrent signals are resolved by semanticsMUST¶

One-line summary: Concurrent signals are resolved by semantics.

Applies toWhen multiple signals may overlap, the same event may be triggered repeatedly by multiple component layers, or a continuous effect and a prompt share an output endpoint.

RuleThe product MUST define deduplication of repeated events, priority among different events, and the coalescing, preemption, or suppression rule for overlaps. Priority is based on the user's task and consequence, not automatically decided by amplitude. Stacking signals that must be distinguished without verification, in a way that changes their meaning, is prohibited; a preempted discrete event is not replayed, and a continuous process is resumed per H4-5 only while it remains valid. Arbitration MUST NOT override user settings, duration, or the total-amount ceiling.

Design applicationRemove duplicate calls for the same business event first, then handle competition among different events. When a system control has its own feedback, avoid the business layer adding another on top; a game effect that needs mixing is verified separately.

Basis and reference: The platform supporting mixing does not mean the mix remains distinguishable in meaning. Apple's controller documentation describes player stacking; this rule's semantic arbitration comes from the necessity inference of H1-2 and H2-1.

Verification examples

• User side: trigger an error or a boundary during a continuous texture, verifying the key meaning is still recognizable with no sudden strong burst.
• Implementation side: simultaneously trigger success and failure, and duplicate events from the component and business layers, checking deduplication, priority, and quota.

CounterexamplesUnder-delivery — one successful submission vibrates once each from the control, business, and notification layers, feeling like three results; over-delivery — treating different business events all as duplicates, so two consecutive, genuine actions get only one piece of feedback.

---

4. Terms and definitions¶

---

5. From task to a haptic plan¶

This chapter provides a design method and adds no mandatory clauses. First determine what the user needs to know, then decide whether to output, what to output, and what to do when output is not possible.

5.1 Scenario selection¶

The platform's meaning MUST be checked first. The API name "notification feedback" does not mean having background push permission, and "impact" does not mean business success either. For the applicable conditions of specific mechanisms see source notes.

5.2 Six steps to design one signal¶

1. Define the benefit: state at which task moment the user encounters a confirmation, localization, or texture problem; write down the baseline without haptics. Being able to complete the task without haptics is the starting point for comparing plans.
2. Define the fact and the meaning: write out the trigger basis, cancellation condition, and validity window clearly. Separate pressed, acknowledged, in progress, success, failure, and unknown; do not let one result haptic carry the entire flow.
3. Choose the minimal expression: check system components and platform semantic effects first. Add vocabulary only for meanings that need to be distinguished; intensity and rhythm are candidate expressions, not already-established perceptual conclusions.
4. Determine the device and contact condition: list the actual output device, handheld or worn method, and capability condition. For every candidate effect, write out its degradation endpoint, including not playing; there's no need to force a value onto a frequency that cannot be controlled.
5. Combine control and budget: clarify off, category-level off, validity, total amount, concurrency trade-offs, and stopping. Multiple limits take effect simultaneously; high priority does not exempt them from these limits.
6. Present evidence and failure handling: verify configuration, output mechanism, and user experience separately. Write the passing criteria before testing; on failure, choose a simpler effect, narrow the applicable scope, or do not play — do not use increasing intensity as the sole fix.

5.3 Minimal design record¶

The following can be placed into an existing design mockup, ticket, or effect list; there's no need to establish a separate process. Rule numbers and token names serve traceability; runtime event identifiers and test results are not made into configuration items.

5.4 Delivery responsibility¶

Design is responsible for semantics, benefit, comprehensibility, equivalent information, and control entries; engineering is responsible for capability adaptation, clocks, deduplication, budget, and the stop mechanism; testing and research are responsible for obtaining the corresponding evidence on target devices and populations. One person may hold multiple roles, but "the configuration has been written" cannot substitute for execution evidence.

Delivery comes with a resolvable effect reference, applicable conditions, what has not yet passed, and failure handling. There's no need to show the user waveform parameters, interface names, or budget fields; what the user sees is "operation feedback," "reminder," "off," and a genuinely effective intensity choice.

6. Verification, acceptance, and ongoing use¶

6.1 Three kinds of evidence¶

On-device measurement covers cold start, prepared state, load, background switching, and target peripherals. The statistical method records sample count, distribution, tail latency, and measurement error; reporting only the average time masks late feedback. Preparing the engine can reduce latency, but does not guarantee onset, nor does it permit expressing the result early. Apple prepare() notes that the prepared state ends, and calling it only right before playback may not improve latency either.

6.2 Minimal scenario matrix¶

6.3 Minimal discipline for user research¶

• Separate detection from guessing: randomly mix in no-haptic trials, recording misses and false alarms; avoid letting participants see the test administrator press a button and then guess.
• Separate "feels different" from "knows the meaning": first do discrimination for the required signal pairs, then test semantic recognition using the product's actual guidance; record the consequence of a success misjudged as failure and a failure misjudged as success separately.
• Predetermine the threshold: define the sample, trials, pass criteria, and handling of uncertainty based on the task's consequence; no unified percentage is provided across products. A small number of trial playbacks can screen candidates, but cannot prove effectiveness for the entire target population.
• Verify the benefit per its declaration: compare no haptics, the minimal necessary feedback, and the candidate plan; compare the corresponding error, time, viewing burden, or texture evaluation. Vary the trial order to reduce practice effects.
• Long tasks and the right to exit: observe the cumulative burden after the short-term novelty fades; participants may pause or turn it off at any time. Record device contact, learning conditions, individual differences, and failure samples; do not require enduring discomfort to complete the trial.

6.4 Acceptance decision¶

Do not average every metric into a single overall score. A failure that violates an applicable hard requirement — still outputting after being turned off, misreporting the result, misdirecting to another user's device, a bypassable budget — cannot be offset by a high satisfaction score. Perception, timing, and benefit are judged against a preset product standard; missing evidence is recorded as pending validation.

Observe suppression, timeout, interruption, configuration error, user turning it off, and discomfort feedback during use. A high suppression rate may mean the setting is being correctly honored, or it may mean the design is too dense; "raising the playback rate" is not used as an optimization goal. Debug logs should, as much as possible, retain only the event type, effect identifier, output-target category, and reason, without copying business content. Re-review the affected evidence when device capability, contact condition, effect, or target user changes; see Appendix A for details.

---

Appendix A: Verification checklist¶

This checklist is for self-checking and review; it adds no obligations. Each item corresponds to a specific rule in the main text, and the main text governs the judgment.

Classification test (for testing the principles' division, see Chapter 1): take a specific requirement from any rule, and have three reviewers who were not involved in writing it independently assign it to one of the seven principles; for an item with disagreement, what is being checked is the principles' division, not the reviewers' understanding.

Signal-level checks (for each entry in the semantic registry):

• The meaning-to-signal correspondence is clear, meanings that must be distinguished are not confused, and it is consistent within the product (H2-1)
• Does not conflict with the platform's system semantics (H2-2)
• The required capability is declared (H4-1)
• Has a fallback chain with an explicit endpoint; direct-operation feedback does not degrade into a trailing buzz (H4-2)
• No tier in the fallback chain collides with another semantic (H4-3)
• When conveying information, has a corresponding non-haptic equivalent expression; pure texture is marked not applicable (H5-1)
• Verified per the tiers in the table below, under each declared condition (H1-1, H1-3, H1-2)
• The benefit category (functional cost improvement / texture and delight) and its corresponding statement are recorded (H7-4)
• The relationship between intensity tier and trigger frequency is reasonable (H7-1)

Perceptual and experience verification (each piece of evidence is recorded separately; semantic recognition depends on the necessary detection and discrimination, while comfort and task benefit are judged separately. Pure texture does not require semantic recognition, and its textural goal must not be dismissed just because there is no functional benefit):

Re-verification triggers (when any item is hit, the corresponding tier's existing conclusion is voided, and re-verification is required with the trigger reason recorded in the evidence):

• Signal parameters, the effect family, or the fallback chain changed
• The target device, actuator, or system behavior changed, altering the capability-verification result
• A declared condition was added or adjusted
• A new entry was added to the semantic registry, or an existing entry's meaning changed
• The intensity-tier mapping or platform scaling behavior changed
• The target population expanded to a group not covered by the original verification

When not triggered, the existing conclusion carries over; while a conclusion is voided, "it was verified before" MUST NOT serve as evidence, nor may the signal be treated as passing merely for lack of new evidence.

System-level checks:

• The all-haptics-off condition is in the routine acceptance matrix, covering the primary task paths (H5-4)
• An in-app off entry exists; intensity and category-level controls match the actual capability and usage (H6-1)
• Complies with the system setting and call policy corresponding to the current usage, with no bypass path (H6-2)
• The intensity and duration ceilings are enforced before actual output (H6-4)
• The shared budget takes effect at every entry, and over the limit is coalescing or dropping (H7-2)
• The reserved output (level.max.reserved_for) has a usage list and quota, and there is no unregistered output that in practice carries the reserved role (H7-3)
• Every proactive haptic is traceable to an event the user subscribed to or a task they delegated (H6-3)
• No state transition treats a haptic-playback receipt as the user having been informed of or consented to something (H1-5)
• A result-type haptic's trigger point is after the result is confirmed (H3-4)

Fault injection:

• Force the capability-detection result to "unknown," confirming a custom capability is not treated as supported, and the allowed system degradation is still usable (H4-1)
• Force every signal to degrade to each tier, recording the actual rendering tier by tier (H4-2, H4-3)
• Inject delay so a haptic exceeds the ceiling, confirming it is discarded rather than replayed (H3-1)
• Trigger a large number of same-class events at once, confirming they are coalesced or dropped per the definition (H7-2)
• Off state is retained after a restart and configuration reload; when backup restore or cross-device sync is offered, check its conflict handling (H6-5)

Supplementary fault and long-task verification:

• Verify "off truly produces no output" on both a custom-primitive scale=0 path and a no-amplitude-control device path (H6-1)
• Old events are not replayed after an interruption, reset, background switch, or cancellation, and a new valid action can continue (H4-5)
• Swapping controllers and exchanging user ownership, feedback is not sent to the wrong device or location (H4-6)
• With multiple event classes competing and the same event delivered repeatedly, semantics and total amount remain correct (H7-5)
• Mechanical interference is verified during recording, capture, a hard desk surface, and sensor use (H1-6)
• Compare error, time, confusion, discomfort, and user burden with and without haptics across a complete task; operational difficulty caused by too little feedback is likewise recorded (H1-1, H1-2, H5-3, H7-4)

Review evidence should record the device and running environment, contact condition, target population, learning method, actual effect and configuration, pass criteria, and failure samples. Existing test records may be used; a separate document is not required. Automated software checks verify gating and state, on-device measurement verifies physical onset/stop and output characteristics, and user testing verifies detection, discrimination, semantic recognition, comfort, and task benefit; the three cannot substitute for one another, and the perceptual tiers likewise cannot substitute for one another (see the tier table above).

---

Appendix B: Argument boundaries and sources¶

B.1 The basis for normative terms¶

The basis for marking something "MUST" is that its absence would predictably break the experience commitment of being understandable, usable, or controllable. Each is judged against its specific applicable conditions; the mandatory force of these guidelines is not equivalent to the mandatory force of law or an international standard.

B.2 Scope of applicability¶

This document covers vibrotactile output in general-purpose products. Dedicated tactile-reading and encoding devices may reference the semantic and control principles, but their channel design and training need independent assessment, and H5's general-purpose-product premise cannot be mechanically applied to them. The specific requirements of force feedback, impedance, exoskeletons, thermal stimulation, electrical stimulation, ultrasound, and electrostatic haptics are outside the scope. Automotive, medical, and children's products need domain assessment; this document does not prove their safety or conformance.

ISO 9241-920's public abstract explicitly includes requirements and recommendations, and covers a broader range of tactile input, output, and encoding. Only the public abstract is adopted here; the restricted full text was not read, so no judgment is made on whether it already covers every mechanism in this document, nor is it claimed that this document is the only systematic specification. Code examples in platform documentation are only implementation references; the error handling within them does not directly determine product behavior.

B.3 Cross-reference of sources and clauses¶

For clickable sources, retrieval status, numeric conditions, and unresolved items, see reference.md.

---

Implementation acceptance scenarios¶

The scenarios below turn existing clauses into reviewable acceptance inputs, without setting an additional universal performance threshold. Select per 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 passing.

Each scenario checks the configuration's effective value, the execution record, and the user-understandable result separately. Retain the version, target, event timing, failure scope, and recovery result; an unknown external result is not filled in as success or failure.