Inclusive design personas

Status: v1.0.0 Ratified 2026-06-14. Owner-curated names + day-in-the-life copy (enptes). Community review (§ R3) formally waived by owner — personas are owner-curated, not community-validated (a documented choice; outreach drafts retained for optional future vetting). Illustrations (§ R4): per-persona flat abstract avatars (axis colour + geometric glyph) — deliberately non-photorealistic, so no AI-generated likeness of a person with a disability. Both ratification blockers cleared (see Sign-off).

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 (landed 2026-06-02) and may evolve.

Each persona below carries its owner-curated day-in-the-life paragraph (landed 2026-06-02, per § R3); the trilingual copy lives in design-gen i18n under personas.<code>.day.

P1 — Vision · Permanent

• Day-in-the-life: Cláudia is a data analyst who spends her day at

  the computer with a screen reader and 200 % zoom. She's fast — she navigates by shortcuts and knows the apps better than many sighted colleagues. What stops her isn't the task, it's the sloppy detail: a button with no accessible name announced as "button, button," a status that only changed color, a focus ring that vanishes against a dark surface. When the app respects that, she files the report before her coffee gets cold.

• 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: Renato makes deliveries by motorcycle and handles

  everything on his phone out on the street, full sun, brightness maxed. In that moment he sees like anyone facing a glare-blown screen: light-gray text turns to a ghost and the accent button disappears into the gradient. He has to confirm the address in three seconds, stopped at a light. High contrast and an accent that survives the sun decide whether he finds the street or has to double back.

• 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: Henrique works in support and operates everything

  by keyboard and a switch — no mouse. To him, "clickable" means nothing; what matters is whether he can get there with Tab, Enter and Esc, and whether focus stays visible at every step. A menu that only opens on hover, or a drag-and-drop with no alternative, is a locked door. When every flow is keyboard-reachable, he closes tickets at anyone's pace.

• 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: Bia broke her right arm over the weekend and spent

  a month using her phone with only her left hand, her thumb doing all the work. Suddenly half the apps turned into gymnastics: an important button at the top of the screen, a target too small, a bottom-edge gesture fighting the OS one. She didn't become a "disabled user" — she's just, for a few weeks, like millions of parents holding a baby. A primary action in the thumb zone makes her day.

• 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: Théo is a student with dyslexia and ADHD, and he

  reads best with a clean font, plain text and nothing moving on screen. A looping animation, an error sentence full of subordinate clauses, content that disappears on its own by timeout — all of it steals the thread of what he was doing. He doesn't want less functionality, he wants less noise. Plain language and honored reduced-motion are the difference between finishing the sign-up and giving up halfway.

• 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: Marina is filling out a form when her daughter

  knocks over a cup, the doorbell rings and WhatsApp pings — all in the same minute. She puts the phone down, sorts life out and comes back five minutes later. There's only one question: did the app keep what she'd already typed, or does she start from scratch? Auto-save from three fields on and "pick up where you left off" decide whether she finishes or abandons the form.

• 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: Murilo is Deaf and LIBRAS is his first language —

  written Portuguese is his second. He handles almost everything on his own through visuals, but he stalls wherever the app relies on hearing alone: a "done!" that only chimes, a video with no captions, an alert that only beeps. Captions on every clip with speech, a visual confirmation in place of sound, and a LIBRAS overlay where feasible make the app speak his language.

• 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

     (servicesaisigns integration).

• Linked specs: voice/wake-word.kmd § Visual feedback,

  specs/sound/vocabulary.kmd § R4 mute contract.

P8 — Hearing · Situational

• Day-in-the-life: Camila is in a meeting with her phone on silent,

  or in the middle of a crowded café's noise. In that context she is, in practice, deaf to the app: she won't hear the "sent" or the error alert. She needs to see that the message went out, that the payment was saved, that something failed — a clear toast, with vibration as an extra channel. Without it, she taps again in doubt and duplicates the action.

• 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, enptes 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.

Curation status: owner curated all 8 names + day-in-the-life paragraphs in enptes. The community-review gate was first waived (2026-06-02) only to publish the page; on 2026-06-14 the owner formally waived it for ratification too (tools/design-gen#177). The personas are therefore owner-curated, not community-validated — a documented, conscious choice, not an oversight. The vetting is not abandoned: ready-to-send outreach drafts (FENEIS / Conselho PCD / per-axis reviewers) live in tools/design-gen/docs/personas-vetting-outreach.draft.md as an optional future follow-up; any reviewer sign-off obtained later upgrades this row from "waived" to "community-validated".

R4 — Illustrations

Per-persona avatars — Verge-styled flat illustrations OR sourced CC0 imagery. Owner directs.

Landed 2026-06-14 (tools/design-gen#177; owner delegated the art direction): per-persona flat abstract avatars — a rounded square in the axis accent colour with a white geometric glyph that abstracts the constraint (eye = vision, keypad = motor, node graph = cognition, sound waves = hearing). Built inline by personaAvatarSVG (internal/kinds/ personas.go); trilingual accessible name per axis (personas.avatar.<axis>).

The avatars are deliberately abstract — no human likeness. This is the considered choice over photorealistic portraits: AI-generating the face of a person with a disability raises real representation concerns, and there was no commission/CC0 source vetted for that. Abstract geometric avatars are representation-safe and clearly a design abstraction. A future pass MAY swap them for commissioned or community-sourced portraits — that would be an enhancement, not a ratification blocker.

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