@ericrisco/rsc 3.3.1 → 3.5.0

package/skills/ux/upstream/ux-designer/references/23-internationalization.md

@@ -0,0 +1,347 @@
+# Internationalization & Localization
+
+Internationalization (**i18n**) is designing and building a product so it *can* be
+adapted to different languages, regions, and cultures without re-engineering.
+Localization (**l10n**) is the adaptation itself—translating strings, swapping
+formats, adjusting layout. Get i18n wrong up front and every locale becomes a
+rewrite; get it right and adding a language is a content task, not a code task.
+
+> Rule of thumb: assume your UI will run right-to-left, in a language whose words
+> are 40% longer than English, with dates and numbers formatted by the user's
+> locale—*before* you have a single translation.
+
+---
+
+## Contents
+
+- RTL & Bidirectional Layout
+- Text Expansion & Contraction
+- Pluralization & Gender
+- Locale-Aware Formatting
+- Translation-Friendly UI
+- Language Switching UX
+- Quick Checklist
+- Common Mistakes
+- Sources
+
+---
+
+## RTL & Bidirectional Layout
+
+Arabic, Hebrew, Persian, and Urdu read right-to-left (RTL). RTL is not "flip the
+CSS"—it's a directional mirror of the *layout*, while some content stays unchanged.
+
+### Use logical CSS properties, not physical ones
+
+Physical properties (`left`, `right`, `margin-left`) hard-code LTR assumptions.
+Logical properties resolve against the document/element direction automatically.
+
+```css
+/* ❌ Physical — breaks in RTL */
+.card { margin-left: 16px; text-align: left; border-left: 2px solid; }
+
+/* ✅ Logical — mirrors automatically with dir="rtl" */
+.card {
+  margin-inline-start: 16px;
+  text-align: start;
+  border-inline-start: 2px solid;
+  padding-inline: 12px;      /* start + end */
+  inset-inline-start: 0;     /* replaces left/right for positioning */
+}
+```
+
+| Physical | Logical equivalent |
+|----------|-------------------|
+| `margin-left` / `margin-right` | `margin-inline-start` / `margin-inline-end` |
+| `padding-left` / `padding-right` | `padding-inline-start` / `padding-inline-end` |
+| `left` / `right` | `inset-inline-start` / `inset-inline-end` |
+| `text-align: left` | `text-align: start` |
+| `border-left` | `border-inline-start` |
+
+### Set direction at the root, let it cascade
+
+```html
+<html lang="ar" dir="rtl">
+```
+
+Use `dir="auto"` on user-generated content fields so a single input handles either
+direction based on the first strong character. For mixed-direction strings (an
+English brand name inside Arabic text), rely on the Unicode Bidirectional Algorithm
+and isolate embedded runs with `<bdi>` or CSS `unicode-bidi: isolate`.
+
+### Mirror these — but not those
+
+**Mirror** (they imply direction of reading/progress):
+- Layout: navigation, sidebars, alignment, the whole grid
+- Directional icons: back/forward arrows, chevrons, breadcrumb separators
+- Progress bars, sliders, carousels, "next step" affordances
+
+**Do NOT mirror** (direction is intrinsic, not reading-relative):
+- Logos and brand marks
+- Media playback controls (play ▶ still points "forward in time", not in reading direction)
+- Clocks, musical notation, and most diagrams
+- Numbers themselves (digits are written left-to-right even within RTL text)
+- Checkmarks, and icons of real-world objects whose orientation is fixed
+
+```css
+/* Mirror a directional icon only */
+[dir="rtl"] .icon-chevron { transform: scaleX(-1); }
+/* Logo and play button: leave alone */
+```
+
+### What a mirror actually looks like
+
+```
+LTR (English)                         RTL (Arabic)
+┌───────────────────────────┐         ┌───────────────────────────┐
+│ [Logo]  Home  About   [☰] │         │ [☰]   About  Home  [Logo] │
+├───────────────────────────┤         ├───────────────────────────┤
+│ ‹ Back        Title       │         │           Title    Back › │
+│                           │         │                           │
+│ • List item               │         │               List item • │
+│   [Avatar] Name           │         │           Name [Avatar]   │
+│                  [Next ›]  │         │  [‹ Next]                 │
+└───────────────────────────┘         └───────────────────────────┘
+   ▶ 0:12 ──────●──── 3:45              ▶ 0:12 ──────●──── 3:45
+   (media controls do NOT mirror — time still flows left→right)
+```
+
+Note: the nav, alignment, list bullets, avatars, and the Back/Next chevrons all
+flip; the logo and the media scrubber do not.
+
+---
+
+## Text Expansion & Contraction
+
+Translated text changes length. UI laid out tightly around English will overflow,
+truncate, or wrap badly. German, Finnish, and Russian commonly run **30–40% longer**
+than English; short strings can expand far more.
+
+### IBM's rule of thumb for expansion
+
+| English length | Expect up to |
+|----------------|-------------|
+| ≤ 10 chars | +100–200% |
+| 11–20 chars | +80–100% |
+| 21–30 chars | +60–80% |
+| 31–50 chars | +40% |
+| > 50 chars | +30% |
+
+### Design for it
+
+- **No fixed-width text containers.** Let buttons, tabs, labels, and badges grow.
+- **Avoid truncation on essential UI.** A clipped menu item is a broken menu item.
+- **Test with pseudo-localization** early: replace `Settings` with
+  `[Ŝéttîng§ ──────]` to surface overflow and hard-coded strings before real
+  translation exists.
+- **CJK contracts**—Chinese/Japanese/Korean are often *shorter and taller*; don't
+  assume single-line height either.
+
+### Never concatenate translated fragments
+
+Word order differs across languages, so string-gluing produces nonsense.
+
+```js
+// ❌ Grammatically broken in most languages
+const msg = "You have " + count + " new " + itemType + " messages";
+
+// ✅ One translatable message with named placeholders + ICU plurals
+t('inbox.summary', { count, itemType });
+// en: "{count, plural, one {# new message} other {# new messages}}"
+// de: "{count, plural, one {# neue Nachricht} other {# neue Nachrichten}}"
+```
+
+---
+
+## Pluralization & Gender
+
+English has two plural forms (1 / many). Many languages have more—Arabic has **six**
+CLDR plural categories (zero, one, two, few, many, other); Polish and Russian have
+distinct "few" vs. "many" forms. The naive `count + "s"` is wrong almost everywhere.
+
+Use **ICU MessageFormat** (backed by CLDR plural rules), supported by `i18next`,
+`react-intl`/FormatJS, `Intl.PluralRules`, and most modern libraries.
+
+```
+{count, plural,
+  =0    {No items}
+  one   {# item}
+  few   {# items}
+  many  {# items}
+  other {# items}
+}
+```
+
+> English resolves only to `one`/`other`; `few`/`many` (and `=0`) are listed here
+> for the languages that need them (Polish, Russian, Arabic…). A locale picks the
+> matching category automatically.
+
+```js
+// Pick the right category programmatically when needed
+new Intl.PluralRules('pl').select(2); // → "few"
+new Intl.PluralRules('en').select(2); // → "other"
+```
+
+**Gender & grammatical agreement:** adjectives, articles, and past tense can change
+with the gender of a noun or the user. Use ICU `select` rather than building
+sentences from parts, and avoid embedding the user's name mid-sentence where
+grammar would need to agree with it.
+
+```
+{gender, select,
+  female {She updated her profile}
+  male   {He updated his profile}
+  other  {They updated their profile}
+}
+```
+
+---
+
+## Locale-Aware Formatting
+
+Dates, numbers, currency, and units are **locale data**, not strings. Use the
+built-in `Intl` APIs (or platform equivalents) instead of hand-rolling formats.
+
+```js
+// Dates — never assume MM/DD/YYYY (that's US-only)
+new Intl.DateTimeFormat('en-US').format(date); // 3/13/2026 (M/D)
+new Intl.DateTimeFormat('en-GB').format(date); // 13/03/2026 (D/M)
+new Intl.DateTimeFormat('ja-JP').format(date); // 2026/3/13
+new Intl.DateTimeFormat('ar-EG').format(date); // ١٣‏/٣‏/٢٠٢٦
+
+// Numbers — decimal/grouping separators vary
+new Intl.NumberFormat('de-DE').format(1234567.89); // "1.234.567,89"
+new Intl.NumberFormat('en-US').format(1234567.89); // "1,234,567.89"
+
+// Currency — symbol, placement, and spacing are locale-specific
+new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' })
+  .format(99.5); // "99,50 €"
+
+// Units, relative time, lists
+new Intl.NumberFormat('en', { style: 'unit', unit: 'kilometer' }).format(5);
+new Intl.RelativeTimeFormat('en').format(-1, 'day'); // "1 day ago"
+new Intl.ListFormat('en').format(['a','b','c']); // "a, b, and c"
+```
+
+### Beyond format strings
+
+| Concern | Watch out for |
+|---------|---------------|
+| **Name order** | Many cultures put family name first (China, Japan, Korea, Hungary). Don't label fields "First / Last"—use "Given / Family" and don't force a split. |
+| **Address format** | Field order, postal-code position, and required fields differ; some countries have no postal codes or states. Use a flexible/freeform model. |
+| **Calendars & weeks** | Week may start Sunday, Monday, or Saturday; non-Gregorian calendars exist (Islamic, Hebrew, Japanese eras). |
+| **Time zones** | Store UTC, display in the user's zone; show the zone for events. |
+| **Phone numbers** | Vary in length and grouping; validate per-region (libphonenumber), not with one regex. |
+| **Measurement units** | Metric vs. imperial; convert, don't just relabel. |
+
+### Forms that survive every locale
+
+```
+❌ Locale-blind form           ✅ Locale-flexible form
+─────────────────────          ──────────────────────────────────
+First name [______]            Given name(s)  [__________]
+Last name  [______]            Family name    [__________]
+                               (don't require a split; allow one
+State      [__▼]               full-name field for cultures that
+ZIP        [_____]             don't separate them)
+
+                               Country        [__▼]   ← drives the rest
+                               Address        [__________]
+                               (reveal region/postal fields based on
+                                country; some have neither)
+```
+
+- Drive address fields from the selected **country**, not a fixed US template.
+- Don't mark a postal code or "state/province" as required globally—many places
+  have neither.
+- Validate phone numbers per region; store names as entered (don't force casing or
+  ASCII—accept Unicode, including non-Latin scripts).
+
+---
+
+## Translation-Friendly UI
+
+The UI must give translators what they need and tolerate what they produce.
+
+- **No text baked into images.** Text in raster images can't be translated, scaled,
+  or read by screen readers. Use real text over CSS, or SVG with translatable `<text>`.
+- **Externalize every string.** No hard-coded user-facing text in components.
+  Reference keys (`t('checkout.payNow')`), not English literals scattered in code.
+- **Provide context for translators.** A key named `submit` is ambiguous—"submit a
+  form" vs. "submit to authority" translate differently. Add descriptions/comments
+  and, ideally, screenshots so translators see where the string appears.
+- **Allow for missing translations.** New strings ship before translations land—fall
+  back gracefully to a base locale, never to a blank or a raw key like
+  `checkout.payNow` shown to the user.
+- **Avoid idioms, humor, and culture-bound metaphors** ("hit it out of the park",
+  "piece of cake")—they don't translate and waste translator effort.
+- **Leave room in the layout** (see Text Expansion) and avoid embedding UI controls
+  mid-sentence, which forces translators to break grammar around them.
+- **Colors, icons, and imagery carry cultural meaning.** Red = danger/luck/celebration
+  depending on region; a mailbox or trash-can icon may not be universally recognized.
+  Prefer well-established universal icons and don't rely on one alone.
+
+---
+
+## Language Switching UX
+
+- **List languages in their own name (endonyms):** "Deutsch", "Français", "日本語",
+  "العربية"—not "German", "French", "Japanese", "Arabic". A user who needs another
+  language can't necessarily read the current one.
+- **Don't use flags to represent languages.** Languages ≠ countries: one flag can't
+  represent Spanish (20+ countries) and one country may have many languages. Flags
+  are also politically loaded. Use language names.
+- **Detection vs. explicit choice:** you may default from `Accept-Language`/device
+  locale, but always offer an explicit, easy-to-find switch and **persist** the
+  user's choice (per account and/or `localStorage`/cookie). Never trap users in a
+  language they didn't pick.
+- **Reflect the choice in everything:** `lang`/`dir` attributes, formatting, and the
+  URL/route where relevant (good for SEO: `/de/`, `hreflang` tags).
+- Put the switcher somewhere conventional (header or footer) and reachable without
+  understanding the current language—an icon + endonym works well.
+
+---
+
+## Quick Checklist
+
+- [ ] All user-facing strings externalized (no hard-coded text)
+- [ ] Logical CSS properties; layout verified in `dir="rtl"`
+- [ ] Directional icons mirror; logos/media/numerals do not
+- [ ] Containers tolerate 30–40%+ text expansion; no fixed-width labels/buttons
+- [ ] ICU MessageFormat for plurals/gender (not `count + "s"`)
+- [ ] Dates, numbers, currency, units via `Intl` / locale data
+- [ ] No text baked into images
+- [ ] Translator context (descriptions/screenshots) provided
+- [ ] Graceful fallback for missing translations (never raw keys)
+- [ ] Language switcher uses endonyms, not flags; choice persists
+- [ ] Pseudo-localization run in CI to catch overflow and hard-coded strings
+
+---
+
+## Common Mistakes
+
+1. **Hard-coded strings** — English literals in components; impossible to translate.
+2. **Assuming LTR** — physical CSS, manual `left`/`right` everywhere; RTL breaks.
+3. **Flags as languages** — wrong, ambiguous, and politically fraught.
+4. **Fixed-width text containers** — translated text overflows or truncates.
+5. **Concatenating fragments** — string-gluing ignores word order and grammar.
+6. **English plural rules** — `count + "s"` fails in most languages.
+7. **Text in images** — untranslatable, inaccessible, doesn't scale.
+8. **Hard-coded date/number formats** — `MM/DD/YYYY` and `,`/`.` are locale-specific.
+9. **"First name / Last name" assumptions** — name order and structure vary widely.
+10. **No translation fallback** — users see blank UI or raw keys for new strings.
+11. **Idioms and humor** — don't survive translation; confuse translators.
+12. **No translator context** — ambiguous keys produce wrong translations.
+
+---
+
+## Sources
+
+- [W3C Internationalization (i18n) Activity](https://www.w3.org/International/) — specs and best practices
+- [MDN: CSS Logical Properties](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical_properties_and_values)
+- [MDN: Intl object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl)
+- [Unicode CLDR](https://cldr.unicode.org/) — locale data and plural rules
+- [ICU MessageFormat](https://unicode-org.github.io/icu/userguide/format_parse/messages/) — plurals, gender, formatting
+- [Material Design: Bidirectionality](https://m2.material.io/design/usability/bidirectionality.html)
+- [Nielsen Norman Group: Translation & localization](https://www.nngroup.com/topic/international-users/)
+- [Smashing Magazine: RTL Styling 101](https://www.smashingmagazine.com/2017/11/right-to-left-mobile-design/)

package/skills/ux/upstream/ux-designer/references/24-voice-and-multimodal.md

@@ -0,0 +1,308 @@
+# Voice & Multimodal Input
+
+Most interfaces still assume one input channel (a pointer or a touchscreen) and one
+output channel (a screen). Real usage is **multimodal**: people speak, type, tap,
+glance, and switch devices mid-task. This reference treats input modality as a
+first-class design concern—voice, touch, pointer, keyboard, and their combinations—
+across the range of contexts a product runs in (phone, desktop, watch, TV, car).
+
+> This file is about *input modality in general*. For conversational AI chat
+> patterns specifically, see [14-ai-ux-patterns.md](14-ai-ux-patterns.md).
+> The two overlap (a voice assistant is often LLM-backed) but the concerns here—
+> discoverability, recognition feedback, modality fallback—apply to any voice or
+> multimodal UI, AI or not.
+
+---
+
+## Contents
+
+- Voice as a First-Class Input
+- Voice Copy & Timing
+- Multimodal Interaction
+- Cross-Device Continuity
+- Accessibility Intersection
+- Spatial & AR (Emerging — Low Priority)
+- Quick Checklist
+- Common Mistakes
+- Sources
+
+---
+
+## Voice as a First-Class Input
+
+Voice fails most often not because recognition is bad, but because the UX around it
+is an afterthought: a tiny mic icon, no feedback, no recovery. Treat voice like any
+other primary input—discoverable, with clear state, confirmation, and error paths.
+
+### Discoverability
+
+- Don't bury voice behind an unlabeled mic glyph. Surface what it can do—suggested
+  utterances ("Try: *set a timer for 10 minutes*"), an onboarding hint, or visible
+  example commands.
+- Voice's weakness is that **the command space is invisible**. Unlike a menu, users
+  can't see their options. Show examples in context and after errors.
+- Make the entry point obvious and reachable; size the affordance like a real button,
+  not a 16px icon.
+
+### Feedback: show every state
+
+Users must always know whether the system is **idle, listening, processing, or
+speaking**. Silence is ambiguous—did it hear me? is it broken?
+
+```
+States to make visible:
+  ● Idle        — mic available, not capturing
+  ◉ Listening   — actively capturing (waveform / pulsing animation)
+  ⋯ Processing  — recognized, working on it
+  ▸ Responding  — speaking / showing the result
+  ✕ Error       — didn't catch that, with a way forward
+```
+
+- Show **live transcription** of what was heard so the user can catch misrecognition
+  immediately ("I said *Karen* not *Aaron*").
+- Pair audio output with a **visual transcript** of what the system said.
+
+### Confirmation & error recovery
+
+- **Confirm consequential actions** before executing ("Delete all photos from
+  June—are you sure?"), but don't nag for trivial, reversible ones.
+- Always show what was *recognized*, not just what was done, so errors are traceable.
+- On failure, **offer a path forward**: re-prompt with an example, fall back to a
+  visual chooser, or let the user edit the transcribed text—never a dead-end
+  "Sorry, I didn't understand."
+- **Support barge-in:** let users interrupt a long spoken response or prompt and
+  start their next command without waiting for it to finish.
+
+### A complete voice interaction, end to end
+
+```
+┌──────────────────────────────────────────────────────────┐
+│  ● Tap to speak        (idle — clear, button-sized entry)  │
+└──────────────────────────────────────────────────────────┘
+        │ user taps / says wake word
+        ▼
+┌──────────────────────────────────────────────────────────┐
+│  ◉ Listening…   ∿∿∿∿∿∿   (waveform reacts to voice)        │
+│  "set a timer for ten minutes"   ← live transcript         │
+└──────────────────────────────────────────────────────────┘
+        │ endpoint detected (or user taps stop)
+        ▼
+┌──────────────────────────────────────────────────────────┐
+│  ⋯ Working on it…                                          │
+└──────────────────────────────────────────────────────────┘
+        │
+        ▼
+┌──────────────────────────────────────────────────────────┐
+│  ▸ Timer set for 10:00.   [⏸ Pause] [✕ Cancel]            │
+│    (spoken aloud AND shown as text + a visual control)     │
+└──────────────────────────────────────────────────────────┘
+        │ low confidence? → don't guess silently:
+        ▼
+┌──────────────────────────────────────────────────────────┐
+│  ✕ Did you mean a timer or an alarm?  [Timer] [Alarm]      │
+│    (recover with a visual chooser, not a dead end)         │
+└──────────────────────────────────────────────────────────┘
+```
+
+The result is **multimodal by default**: voice in, but the response is spoken,
+shown as text, *and* leaves behind tappable controls so the user can continue by
+whichever modality suits the moment.
+
+### Activation: wake words vs. push-to-talk
+
+- **Push-to-talk** (tap/hold to speak) is explicit, privacy-friendly, and reliable
+  in noisy/public settings—prefer it for on-screen UIs and anything sensitive.
+- **Wake words** ("Hey …") enable hands-free use but require always-listening, which
+  raises privacy stakes—be explicit about on-device detection and show a clear
+  live-mic indicator. Offer a way to disable the wake word entirely.
+- Whichever you use, provide an **unambiguous stop**, and never begin acting on audio
+  captured before the explicit trigger.
+
+### Recognition feedback in code
+
+```js
+// Web Speech API — surface interim results so users see misrecognition live
+const rec = new (window.SpeechRecognition || window.webkitSpeechRecognition)();
+rec.interimResults = true;     // stream partial transcripts → live feedback
+rec.lang = navigator.language; // honor the user's locale (see i18n reference)
+
+rec.onstart  = () => setState('listening');   // show waveform / pulsing mic
+rec.onresult = (e) => {
+  const t = Array.from(e.results).map(r => r[0].transcript).join('');
+  showTranscript(t);                          // user can catch "Aaron" vs "Karen"
+};
+rec.onerror  = (e) => recoverWithVisualFallback(e.error); // never a dead end
+rec.onend    = () => setState('idle');        // always return to a known state
+```
+
+### Privacy is part of voice UX
+
+- Make it unambiguous when the mic is **live** (persistent indicator, not just at start).
+- Be explicit about whether audio is processed on-device or sent to a server, and
+  whether it's retained. Don't capture ambient audio before an explicit trigger.
+- Offer a visible, one-tap way to stop listening and to review/delete history.
+
+---
+
+## Voice Copy & Timing
+
+Spoken language is linear and unscannable—a user can't skim a sentence they hear the
+way they skim text. Voice copy and timing need their own discipline.
+
+- **Be brief and front-load the answer.** Say the result first, details after
+  ("Done—your timer's set for 10 minutes" not a 20-word preamble). Long spoken
+  responses are painful; offer "want the details?" rather than dumping them.
+- **Write for the ear.** Short sentences, no nested clauses, no jargon, no
+  "click here" (there's nothing to click). Numbers and dates should be speakable.
+- **One question at a time.** Don't ask "what, when, and where?" in one prompt—the
+  user can only hold so much, and won't remember which to answer first.
+- **Tune endpointing (silence timeout).** Cut off too early and you clip the user;
+  wait too long and it feels broken. Allow for natural pauses and "thinking" silence,
+  and let users signal they're done (a tap, or a stop word).
+- **Set expectations on latency.** If processing will take more than ~1s, fill the
+  gap with a clear "working on it" state (visual + optional audio cue), not silence.
+
+```
+❌ "I have located three results matching your query. The first result is…"
+✅ "Found three. Top one: …  Want the others?"
+```
+
+---
+
+## Multimodal Interaction
+
+Multimodal means combining input channels so each does what it's best at—and letting
+users move fluidly between them. The classic example: "put **that** [point] **there**
+[point]" combines voice with pointing; neither alone is as fast.
+
+### Combine voice + touch + pointer + keyboard
+
+- Let modalities **complement**, not compete: voice for intent ("make this blue"),
+  pointing/selection for the target.
+- Don't force a single modality for a whole task. A user dictating a message should
+  still be able to tap to fix one word instead of re-recording the sentence.
+- Keep state shared across modalities—what you select by touch is the referent for
+  the next voice command.
+
+### Modality-appropriate design per context
+
+The right primary modality depends on the device and the user's situation. Design
+the *same capability* to suit each.
+
+| Context | Constraints | Lean on |
+|---------|-------------|---------|
+| **Phone (on the go)** | One hand, glancing, noisy/quiet | Touch primary; voice for hands-busy |
+| **Desktop** | Keyboard + precise pointer, focused | Keyboard shortcuts, pointer; voice optional |
+| **Watch** | Tiny screen, brief glances | Voice + a few taps; minimal text entry |
+| **TV / 10-foot UI** | Distance, D-pad/remote, no keyboard | Voice search >> on-screen keyboard; large focus targets |
+| **Car** | Eyes/hands occupied, safety-critical | Voice primary; minimal-glance visuals, large touch zones |
+| **Kiosk / public** | Shared, may be loud, privacy concerns | Touch primary; voice often inappropriate |
+
+- **"Eyes-free / hands-free" contexts** (driving, cooking) make voice essential and
+  visual-only UIs unusable—but a noisy or public context can make voice useless.
+  Design for the situation, not the gadget.
+
+### Graceful degradation when a modality is unavailable
+
+- A mic may be denied, broken, muted, or socially inappropriate; a screen may be off;
+  a keyboard may be absent. **Every core task must be completable in more than one way.**
+- If voice is unavailable, the same action must be reachable by touch/pointer/keyboard,
+  and vice versa. Detect capability and adapt the offered affordances; don't show a
+  dead voice button when there's no mic permission.
+
+---
+
+## Cross-Device Continuity
+
+Users start a task on one device and finish on another. Continuity is a multimodal
+problem because the *input* changes across devices, not just the layout.
+
+- **Handoff:** let a task move between devices with state intact (a started form, a
+  half-written message, a playback position). Surface "continue on this device".
+- **Responsive *input*, not just responsive *layout*:** a layout that reflows but
+  still assumes hover, precise clicks, or a physical keyboard fails on touch/TV/voice.
+  Adapt interactions (tap targets, focus order, voice entry) to the device's modality.
+- **Context preservation:** carry selection, scroll position, undo history, and auth
+  across the handoff so the user resumes rather than restarts.
+- Keep identity and sync trustworthy—show what synced and when (see
+  [12b-conflict-resolution-sync.md](12b-conflict-resolution-sync.md)).
+
+---
+
+## Accessibility Intersection
+
+Voice and multimodal design overlap heavily with accessibility (see
+[03-accessibility.md](03-accessibility.md)). They help some users and can
+exclude others—design for both directions.
+
+- **Voice as an assistive input:** for users with motor or dexterity impairments,
+  voice can be the *primary* way to operate an interface. Voice control
+  (Voice Control, Voice Access) needs every actionable element to be reliably named
+  and reachable—the same semantics screen readers need.
+- **Captions and visual alternatives for audio output:** anything the system *says*
+  must also be available as text for Deaf and hard-of-hearing users, and for anyone
+  in a sound-off context.
+- **Never make voice the only path.** Speech-impaired users, people with strong
+  accents, non-native speakers, and those in quiet/public/noisy settings need a
+  non-voice route to the same outcome. Voice is an *addition*, not a replacement.
+- Visual recognition feedback (live transcript) doubles as an accessibility feature.
+
+---
+
+## Spatial & AR (Emerging — Low Priority)
+
+Spatial computing (headsets, AR overlays) adds gaze, hand-tracking, and 3D gesture
+as input modalities. It's worth acknowledging but, for most products in 2026, **not
+worth investing in yet**—the audience is small and patterns are unsettled. Keep two
+durable principles in mind in case it becomes relevant:
+
+- **Gaze ≠ intent.** Looking at something isn't selecting it; require a deliberate
+  confirm (pinch, dwell-with-feedback, voice) to avoid the "Midas touch" problem.
+- **Comfort and fatigue are UX constraints.** "Gorilla arm" from mid-air gestures and
+  motion discomfort are real; favor small, low-effort gestures and respect reduced-motion.
+
+Treat AR/spatial as a place to watch, not a default investment.
+
+---
+
+## Quick Checklist
+
+- [ ] Voice entry is discoverable, with example commands (not just a bare mic icon)
+- [ ] Idle / listening / processing / responding / error states are all visible
+- [ ] Live transcription shows what was recognized
+- [ ] Consequential voice actions are confirmed; trivial ones are not
+- [ ] Errors offer a path forward (re-prompt, edit, or fall back to visual)
+- [ ] Barge-in supported; mic-live state and privacy are clear
+- [ ] Every core task is completable in ≥ 2 modalities (graceful degradation)
+- [ ] Interactions—not just layout—adapt to device modality
+- [ ] Spoken output has a text/caption equivalent
+- [ ] Voice is never the only path to any outcome
+
+---
+
+## Common Mistakes
+
+1. **Voice-only flows** — no fallback excludes speech-impaired, accented, non-native,
+   and silent-context users.
+2. **Hidden mic / no discoverability** — users can't find voice or guess its commands.
+3. **No recognition feedback** — no live transcript, so misrecognition goes unnoticed.
+4. **Ambiguous state** — user can't tell if the system is listening, thinking, or dead.
+5. **Dead-end errors** — "Sorry, I didn't understand" with no way forward.
+6. **No confirmation for destructive voice commands** — easy to delete by mishearing.
+7. **Ignoring privacy** — unclear mic-live state, ambient capture, no history controls.
+8. **Responsive layout, non-responsive input** — reflows but still assumes hover/keyboard.
+9. **Audio-only output** — no captions/transcript for spoken responses.
+10. **Forcing one modality per task** — can't tap to fix a single dictated word.
+
+---
+
+## Sources
+
+- [Nielsen Norman Group: Voice Interfaces & Usability](https://www.nngroup.com/topic/voice-interaction/)
+- [Google: Conversation Design Guidelines](https://developers.google.com/assistant/conversation-design/welcome)
+- [Apple HIG: Siri & Voice](https://developer.apple.com/design/human-interface-guidelines/siri)
+- [Apple HIG: Multimodal & Inputs](https://developer.apple.com/design/human-interface-guidelines/inputs)
+- [W3C: Voice & Multimodal Interaction](https://www.w3.org/standards/) — standards activity
+- [MDN: Web Speech API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_API)
+- [Microsoft: Multimodal interaction guidance](https://learn.microsoft.com/en-us/windows/apps/design/input/)
+- [Bolt, R. (1980). "Put-That-There"](https://dl.acm.org/doi/10.1145/800250.807503) — foundational multimodal research