Skip to content

Inclusive design personas

Eight archetypal personas — four ability axes (vision, motor, cognition, hearing) across three permanence states (permanent, temporary, situational). WCAG audits tell you WHAT fails; personas tell you WHO breaks.

Why personas

WCAG line items name the failure mode; personas name the person. 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.

The eight personas

Abstract avatar — vision axis
P1 Vision Permanent

Cláudia — low-vision power user

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 that the reader announces 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
Accessible name on every interactive element; no color-only cues; focus ring contrast ≥ 3:1.
Linked specs
themes/light-dark.kmd · policies/focus-management.kmd · accessibility/aria-roles.kmd
Abstract avatar — vision axis
P2 Vision Situational

Renato — courier in bright sun

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 they use
Phone outdoors in bright sun; OS auto-brightness maxed.
Design constraints they expose
Body text contrast ≥ 7:1 (AAA); accent ≥ 4.5:1; gradient-darken photos behind type.
Linked specs
themes/light-dark.kmd · themes/high-contrast.kmd
Abstract avatar — motor axis
P3 Motor Permanent

Henrique — keyboard-only power user

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 they use
External keyboard, switch device, head-tracker.
Design constraints they expose
Every flow reachable via Tab + Enter + Escape; visible focus indicator; no drag-only / hover-only paths.
Linked specs
policies/focus-management.kmd · navigation/back-behavior.kmd
Abstract avatar — motor axis
P4 Motor Temporary

Bia — one-handed (broken arm)

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 they use
Thumb-only reach on phone; one arm in a sling.
Design constraints they expose
Touch targets ≥ 44 dp; primary actions in thumb zone; no swipes that conflict with OS gesture pill.
Linked specs
app-layout/safe-area.kmd · policies/single-hand-reach.kmd (forthcoming)
Abstract avatar — cognition axis
P5 Cognition Permanent

Théo — dyslexia + ADHD

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 they use
Reduced-motion preference, OS font scaling.
Design constraints they expose
prefers-reduced-motion: reduce honored; plain language in error messages; no timeout-based dismissals on critical content.
Linked specs
errors/user-facing-messages.kmd · motion/reduced-motion.kmd
Abstract avatar — cognition axis
P6 Cognition Situational

Marina — parent amid interruptions

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 they use
Phone, frequently interrupted by child, conversation, doorbell.
Design constraints they expose
Auto-save on forms with ≥ 3 inputs; restore-where-they-left-off on app resume; undo window for destructive actions.
Linked specs
koder-app/behaviors.kmd § State persistence
Abstract avatar — hearing axis
P7 Hearing Permanent

Murilo — Deaf user, LIBRAS L1

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 they use
LIBRAS interpreter, captions on, visual notifications.
Design constraints they expose
No audio-only feedback; captions on every motion clip with speech; LIBRAS overlay available where applicable.
Linked specs
voice/wake-word.kmd § Visual feedback · sound/vocabulary.kmd § R4 · services/ai/libras
Abstract avatar — hearing axis
P8 Hearing Situational

Camila — meeting / noisy café

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 they use
Phone on silent in a meeting; ambient noise washing out audio.
Design constraints they expose
Visual toast confirms every "sent / saved / error" action; vibration available as secondary channel.
Linked specs
errors/user-facing-messages.kmd · sound/vocabulary.kmd

How to use this page

When you review a UI, pick three personas — one from each ability axis you haven't tested today. Walk the flow as if you were them. The cards link to the specs whose tests should catch their constraints; if a test is missing, open a ticket.