Spec — Inclusive design personas

Status: v0.1.0 Draft (2026-05-22). Owner curates names, day-in- the-life copy, and illustrations; structural slots ship now.

R1 — Why personas

WCAG audit gates (contrast / focus / aria / touch target) tell us what fails. Personas tell us who breaks. The same missed focus ring is "the audit didn't pass" to one team and "Jamal-the- parent typing one-handed at the breakfast table can't dismiss the modal" to another. The second framing routinely surfaces design fixes the first misses.

Microsoft's Inclusive Design toolkit popularized the permanence matrix — a disability that's permanent for one person is temporary for another (broken arm) or situational for a third (holding a baby). KDS adopts the matrix so designers don't conflate WCAG categories with edge-case populations; every persona is "us, some percentage of the time."

R2 — Persona matrix

Eight personas × four ability axes × three permanence states. Codes are stable; names are owner-curated and may evolve.

Each persona below carries a 1-sentence stub for the day-in-the-life section (the longer narrative ships owner-curated, per § R3).

P1 — Vision · Permanent

• Day-in-the-life stub: TODO — owner writes 1 paragraph.
• Tools they use: screen reader (TalkBack / VoiceOver / NVDA), browser zoom 200 %, OS high-contrast mode.
• Design constraints they expose:
  1. Every interactive element MUST have an accessible name.
  2. No color-only cues — pair with shape / text / icon.
  3. Focus ring contrast ≥ 3:1 against any surface.
• Linked specs: themes/light-dark.kmd (high-contrast theme), policies/focus-management.kmd, accessibility/aria-roles.kmd.

P2 — Vision · Situational

• Day-in-the-life stub: TODO.
• Tools: phone outdoors in bright sun, OS auto-brightness maxed.
• Constraints:
  1. Body text contrast ≥ 7:1 (AAA) on critical surfaces.
  2. Accent color ≥ 4.5:1 against background.
  3. Photos / illustrations behind text MUST gradient-darken under the type.
• Linked specs: themes/light-dark.kmd, themes/high-contrast.kmd.

P3 — Motor · Permanent

• Day-in-the-life stub: TODO.
• Tools: external keyboard, switch device, head-tracker.
• Constraints:
  1. Every flow reachable via Tab + Enter + Escape.
  2. Visible focus indicator at every step.
  3. No drag-only or hover-only paths (gesture must have a keyboard/click counterpart).
• Linked specs: policies/focus-management.kmd, navigation/back-behavior.kmd.

P4 — Motor · Temporary

• Day-in-the-life stub: TODO.
• Tools: thumb-only reach on phone; one arm in a sling.
• Constraints:
  1. Touch targets ≥ 44 dp.
  2. Primary actions reachable in thumb zone (lower 1/3 of screen).
  3. No bottom-screen swipes that conflict with OS gesture pill.
• Linked specs: app-layout/safe-area.kmd, policies/single-hand-reach.kmd (TODO — opens with this persona set).

P5 — Cognition · Permanent

• Day-in-the-life stub: TODO.
• Tools: prefers reduced motion; uses font size + scaling.
• Constraints:
  1. prefers-reduced-motion: reduce honored.
  2. Plain language — no nested clauses in error messages.
  3. No timeout-based dismissals on critical content.
• Linked specs: errors/user-facing-messages.kmd, motion/reduced-motion.kmd.

P6 — Cognition · Situational

• Day-in-the-life stub: TODO.
• Tools: phone interrupted by child, conversation, doorbell.
• Constraints:
  1. Auto-save on form fields with ≥ 3 inputs.
  2. Restore-where-they-left-off on app resume.
  3. Confirmations for destructive actions; undo for 5 s.
• Linked specs: koder-app/behaviors.kmd § State persistence.

P7 — Hearing · Permanent

• Day-in-the-life stub: TODO.
• Tools: LIBRAS interpreter, captions on, visual notifications.
• Constraints:
  1. No audio-only feedback (every cue has a visual twin).
  2. Captions present on every motion clip with speech (#051).
  3. LIBRAS / sign-language overlay available where applicable (services/ai/signs integration).
• Linked specs: voice/wake-word.kmd § Visual feedback, specs/sound/vocabulary.kmd § R4 mute contract.

P8 — Hearing · Situational

• Day-in-the-life stub: TODO.
• Tools: phone on silent in a meeting; ambient noise washing out audio.
• Constraints:
  1. Visual toast confirms every "sent / saved / error" action.
  2. Vibration available on mobile as a secondary channel.
• Linked specs: errors/user-facing-messages.kmd, specs/sound/vocabulary.kmd.

R3 — Day-in-the-life narrative (owner-curated)

Each persona ships with a 1-paragraph day-in-the-life describing the context in which they use Koder apps. This copy is owner-curated because it must:

• Avoid stereotypes / paternalistic framing.
• Use names + cultural references appropriate to Koder's audience (Brazil-led, en/pt/es trilingual).
• Be vetted with at least one community member matching the persona's axis (FENEIS for P7, Conselho da Pessoa com Deficiência for P1/P3, etc.) before publication.

Until owner curates, the spec page renders the working title and constraints; the day-in-the-life paragraph displays a TODO banner.

R4 — Illustrations

Per-persona portraits — Verge-styled flat illustrations OR sourced CC0 imagery. Owner directs. Until illustrations land, the page uses a neutral silhouette placeholder.

R5 — Audit gates (when ratified)

koder-spec-audit personas (follow-up) walks every persona × every linked spec and asserts:

1. Each linked spec has a test (T-section) that fails when the persona's constraint breaks.
2. No KDS page introduces a UI flow that breaks any persona's constraint without a data-persona-exempt="<P-code>:<spec-ref>" attribute.

R6 — Cross-references

• specs/themes/high-contrast.kmd — P1 + P2 surface.
• specs/voice/wake-word.kmd — P7 + P8 visual-feedback requirement.
• specs/motion/reduced-motion.kmd — P5 baseline.
• specs/app-layout/safe-area.kmd — P4 thumb-zone.
• specs/i18n/contract.kmd — locale-aware persona copy.
• services/ai/signs/ (Track B) — P7 sign-language overlay.

R7 — Open questions

1. Should the persona set evolve over time (additive only) or remain closed at 8? Recommendation: closed for v0, additive in minor versions on owner sign-off only.
2. Do we ship a per-persona test fixture (e.g. for P1, run the page under NVDA's headless mode) — or is per-spec testing sufficient?
3. Trilingual rollout — does P1's working title translate, or stay anglicized as a stable code?

Sign-off