inclusive-and-assistive-design

name	inclusive-and-assistive-design
description	Use when designing beyond the WCAG floor for cognitive, visual, motor, assistive-technology, temporary, or situational ability ranges. Unlike accessibility-wcag-2-2-compliance, this creates inclusive adaptations rather than certifying criteria.
metadata	{"portable":true,"category":"00-cross-cutting-ops-qa-a11y","compatible_with":["claude-code","codex"]}

Inclusive & Assistive Design (Beyond the WCAG Floor)

WCAG 2.2 AA is the floor, not the ceiling. A product can pass every success criterion and still exclude people: text that is technically contrast-compliant but cognitively dense; targets that hit the 24px minimum but punish a tremor; flows that meet 3.3.7 but still overload working memory; markup that is screen-reader-valid but screen-reader-hostile. This skill is the deliberate pass above the floor — it designs for the full human range, using the persona spectrum / exclusion model from Microsoft Inclusive Design.

The companion skill accessibility-wcag-2-2-compliance operationalizes and certifies the legal/technical floor (doctrine/references/wcag-2.2-criteria.md). Run that to know you pass; run THIS to design something people with a range of abilities can actually, comfortably use. They are a pair — never substitute one for the other.

This is doctrine, not decoration: §0 of doctrine/design-doctrine.md says the moat is work that looks authored by a skilled human. Designing for the people a templating tool forgets is exactly that signature — and §3 places accessibility/inclusion in 00-cross-cutting-ops-qa-a11y to co-activate with every group, never skip.

Use When

• A request asks to go beyond compliance: "make it inclusive", "who can't use this?", "reduce cognitive load", "plain-language this", "support low-vision/dyslexic users", "make it work for switch/voice/dwell", "run an exclusion audit", "persona spectrum".
• Designing or reviewing a flow (onboarding, checkout, claim, booking, form-heavy task) where memory load, error recovery, reading level, or time pressure could exclude people.
• Deciding accommodations and options above the minimums — adjustable text spacing, a reading mode, a dyslexia-friendly toggle, large/comfortable targets, dwell/switch support, "save and resume", reduced-motion and reduced-cognitive-load modes.
• You need to think about situational and temporary impairments (one hand on a phone, glare outdoors, a noisy room, a sprained wrist, a new-parent's sleep-deprived attention, a slow/expensive connection) — not just permanent disability.
• Verifying real assistive-technology compatibility (screen readers, screen magnifiers, voice control, switch access, OS dyslexia/reading tools) as an experience, not a checkbox.

Do Not Use When

• You only need to certify the WCAG 2.2 AA floor (focus order, ARIA, target-size minimum, audit sheet) → accessibility-wcag-2-2-compliance. This skill assumes that floor is met and builds on top of it.
• The work is purely colour contrast ramps / colour-blind-safe palettes → 02-color-brand-and-visual-identity/accessible-color-and-contrast (this skill cites it for low-vision/contrast but does not own palette construction).
• The work is microcopy/error wording mechanics → 10-content-design-and-ux-writing (this skill sets the plain-language and cognitive-load targets; that skill crafts the words).
• The work is performance budgets / Core Web Vitals → performance-as-ux-and-core-web-vitals (this skill flags slow/expensive connection as a situational exclusion and hands off).
• You need the final pre-launch gate that composes a11y + slop + perf → design-qa-and-pre-launch-review.

Required Inputs

Input	Supplied by	Required?	Why
Product flow and usage contexts	Product team or research	yes	Reveals permanent and situational exclusions
Persona spectrum and assistive modes	Research or inclusive-design brief	yes	Prevents an able-bodied default
WCAG baseline findings	Accessibility audit	recommended	Separates floor failures from above-floor design

Workflow

Follow the ability-spectrum workflow below; stop when affected users, critical tasks, or assistive modes are unknown enough to change the design.

• The flow or screen under work, end to end, with its real tasks and goals (what is the user actually trying to finish, under what pressure, in what context).
• Who it serves: the realistic range of abilities, contexts, devices, and connection quality — including the people usually left out of the default "able-bodied, focused, fast Wi-Fi" persona.
• Confirmation that the WCAG 2.2 AA floor is already met or in progress (this skill builds above it; it does not re-do it).
• Any constraints: brand voice, regulated content that limits plain-language rewrites, platform assistive-tech available for testing (VoiceOver/NVDA/TalkBack, OS magnifier, Voice Control/Voice Access, Switch Control/Switch Access, dwell control).

A. Find the exclusions (persona spectrum first)

1. Frame each ability as a spectrum, not a binary. For every ability dimension — cognitive, vision, motor/dexterity, hearing, speech — Microsoft's model spans permanent → temporary → situational: e.g. one arm (permanent) · arm injury (temporary) · holding a baby (situational); blind · cataract/post-surgery · bright sun; non-verbal · laryngitis · heavy accent on voice control. Designing for the permanent end serves the far larger temporary/situational population too. See references/inclusive-patterns.md §Persona spectrum.
2. Run an exclusion audit on the real flow. Walk each step and ask, per dimension, who gets stuck or shut out here, and why — then record it. Mismatched interactions, not "disabilities", are the exclusions. Use the table in references/inclusive-patterns.md §Exclusion audit and the worked example.
3. Recruit the spectrum, not the average. Validate with people at the edges (a screen-reader user, someone with dyslexia, a switch user, someone on a 3G phone in sunlight) — solutions that work at the edges work for everyone in the middle.

B. Accommodate above the floor (by ability dimension)

4. Cognitive accessibility. Reduce the three loads:
   • Plain language — short sentences, common words, active voice; target a reading age well below your audience's ceiling (often ~Grade 8 / lower secondary). Front-load the point. (Hand wording to 10-content-design-and-ux-writing; set the target here.)
   • Memory load — don't make people hold things in their head. Persist entered data, show a summary before commit, keep instructions visible next to the step (not on a prior screen), prefill the known (extends WCAG 3.3.7 well past the minimum).
   • Error tolerance — make mistakes cheap and recoverable: confirm destructive actions, allow undo, save-and-resume, forgiving input parsing (accept spaces in card numbers, any phone format), inline help before the error, recovery guidance in the error. See references/inclusive-patterns.md §Cognitive.
5. Low vision (beyond contrast minimums). Passing 4.5:1 is not enough.
   • Zoom/reflow past the floor — usable not just at 200% (the WCAG floor) but at 400% and OS text-enlargement; no truncation, no clipped controls, no horizontal scrolling of body text.
   • Spacing as an affordance — respect user text-spacing overrides (line-height ≥1.5, paragraph spacing, letter/word spacing) without breaking layout (WCAG 1.4.12 is the floor; design comfortably above it).
   • Reading & dyslexia-friendly options — offer a clean reading mode; let users pick a dyslexia-friendly face and looser spacing; never justify body text; avoid pure-black-on- pure-white glare (offer a softer/dark theme). Choose typefaces per the engine's font doctrine (no banned defaults). See references/inclusive-patterns.md §Low vision.
6. Motor / dexterity. Above the 24px minimum:
   • Large, comfortable targets with generous spacing; aim 44×44px (HIG) / 48dp (Material) as the comfortable norm, larger for primary actions and for tremor/one-handed use.
   • Forgiving interactions — no precision-required drags (always a tap/click/key path, extending WCAG 2.5.7); no hover-only reveals; generous click areas; no tight time limits.
   • Switch, voice, and dwell — ensure a logical single-switch scan order, that every action has a stable visible/spoken label voice control can target, and that nothing requires a sustained gesture a dwell user can't make. See references/inclusive-patterns.md §Motor.

C. Decide, document, hand off

9. Prefer one robust default over a pile of toggles. Bake inclusion into the baseline (large targets, plain language, persisted data); add options (reading mode, dyslexia face, theme) only where one default genuinely can't serve everyone. Honour OS/user settings (reduced motion, larger text, high contrast, dark mode) rather than reinventing them.
10. Record exclusions found → accommodations made, and route each to its owner (contrast → accessible-color-and-contrast; wording → content design; budget → perf; floor criteria → accessibility-wcag-2-2-compliance). Use examples/inclusive-design-pass.md as the template.

Anti-Patterns

• Treating WCAG AA as "done". Passing the floor while the flow is still dense, forgetful, precision-demanding, or screen-reader-hostile. The floor is the start of this skill, not the end.
• Binary thinking ("disabled vs not") instead of the spectrum — ignoring the huge temporary/situational population that the permanent-end fix would also serve.
• Accessibility-overlay / toggle theatre — a widget that claims to "make the site accessible" instead of fixing the underlying design; a wall of switches no one finds.
• Cognitive overload dressed as features — jargon, walls of text, multi-step flows that demand holding values in your head, dead-end errors with no recovery.
• Contrast-compliant but unreadable — meeting 4.5:1 while justifying text, cramming line-height, glare-white backgrounds, and ignoring text-spacing overrides.
• Minimum-size targets crammed together — hitting 24px on paper but punishing a tremor or a thumb; hover-only or drag-only interactions with no forgiving path.
• "Screen-reader valid" ≠ usable — correct ARIA that still reads as noise, with no headings, no announced changes, or a nonsensical order. Magnifier/voice/switch never tested.
• Designing only for the able-bodied, focused, fast-connection persona — the convergent default this skill exists to break.
• Banned default fonts / lorem in any inclusive option (reading mode, dyslexia face) — still subject to the Anti-Slop Charter.

Outputs

Output	Consumer	Evidence / acceptance
Exclusion map	Product and research teams	Ability, context, task, barrier, and consequence
Inclusive adaptation specification	Designer and engineer	Default, option, and assistive interaction defined
Validation plan and evidence	QA and accessibility owners	Representative users/modes and task outcomes recorded

• An exclusion audit of the flow (per ability dimension, across permanent/temporary/ situational), naming who is shut out and where.
• A matched set of accommodations above the floor — cognitive, low-vision, motor, assistive-tech, situational — baked into the default where possible, offered as options where necessary, each routed to its owning skill.
• A short inclusive-design pass record (exclusions found → accommodations made) suitable for handoff to design-qa-and-pre-launch-review alongside the WCAG audit sheet.

Examples

• Use the worked example in examples/ for an exclusion-map-to-adaptation handoff.

Quality Standards

• Design with affected people and representative assistive modes, not only proxy personas.
• Preserve user agency and avoid segregated or stigmatising alternatives.
• Block release when a critical task excludes a known ability group without an equivalent path.

Decision Rules

Condition	Decision	Wrong-choice failure
Adaptation benefits most users without harm	Make it the default	Useful access is hidden behind settings
Needs conflict across ability ranges	Provide a reversible user preference	One inclusive fix creates another exclusion
Critical task depends on one input mode	Add an equivalent mode	Switch, voice, keyboard, or touch users are blocked
Evidence lacks affected-user participation	Mark conditional and recruit validation	Designer assumptions masquerade as inclusion

Capability Contract

Read and interaction inspection are required. User research must use informed consent and minimise sensitive data. Editing or testing with assistive technology requires task authority; never claim certification from this above-floor review.

Degraded Mode

If required evidence or tooling is unavailable, use the scoped fallback below and mark the result unverified. Without affected-user access, use documented patterns and assistive-mode simulation, label conclusions provisional, and create a recruitment/test plan. Without a complete flow, withhold a pass.

• examples/inclusive-design-pass.md — a worked inclusive-design pass on a real flow (a utility-bill payment / account top-up). Runs the persona spectrum, finds concrete exclusions per ability dimension, and lists the accommodation made for each — going above the WCAG floor that accessibility-wcag-2-2-compliance certifies.

References

• doctrine/design-doctrine.md — the cross-cutting charter; §0 (authored-by-a-human moat), §2 (Anti-Slop Charter — applies to any inclusive font/option), §3 (this skill lives in 00-cross-cutting-ops-qa-a11y, co-activates with every group).
• doctrine/references/wcag-2.2-criteria.md — the floor this skill builds above (target-size 24px, reflow at 200%/320px, 3.3.7 redundant entry, 2.5.7 dragging, contrast minimums). We exceed these, not restate them.
• references/inclusive-patterns.md — the accommodation playbook organised by ability dimension (cognitive, low vision, motor, assistive-tech, situational), plus the persona spectrum and exclusion-audit method.
• Pairs with 00-cross-cutting-ops-qa-a11y/accessibility-wcag-2-2-compliance — that skill certifies the floor (run it first/alongside); this skill designs the experience above it.
• Hands off to 02-color-brand-and-visual-identity/accessible-color-and-contrast (low-vision contrast/themes), 10-content-design-and-ux-writing (plain-language wording), performance-as-ux-and-core-web-vitals (slow-connection budget), and design-qa-and-pre-launch-review (final gate).