ux-inclusive-design

What this skill does

<!-- VERSION: 1.1.0 | DATE: 2026-03-04 | SOURCE: skills/user-experience/SKILL.md | PARENT: /user-experience skill | REVISION: Iter2 quality gate fixes -- complete Synthesis Hypothesis Confidence table (3 entries), model frontmatter, inline citations, severity cross-reference, reading level eval method, Nielsen severity alignment note -->

# Inclusive Design Sub-Skill

> **Version:** 1.1.0
> **Framework:** Jerry User-Experience -- Inclusive Design
> **Constitutional Compliance:** Jerry Constitution v1.0
> **Parent Skill:** `/user-experience` (`skills/user-experience/SKILL.md`)
> **Wave:** 3 (Design System)
> **Project:** PROJ-022 User Experience Skill | GitHub Issue [#138](https://github.com/geekatron/jerry/issues/138)

## Document Sections

| Section | Purpose |
|---------|---------|
| [Document Audience](#document-audience-triple-lens) | Triple-Lens audience guide |
| [Purpose](#purpose) | Sub-skill overview and key capabilities |
| [When to Use This Sub-Skill](#when-to-use-this-sub-skill) | Activation triggers and scope boundaries |
| [Available Agents](#available-agents) | Single agent with role, model, and output location |
| [P-003 Compliance](#p-003-compliance) | Worker agent hierarchy position |
| [Invoking the Agent](#invoking-the-agent) | Invocation via ux-orchestrator |
| [Methodology](#methodology) | WCAG 2.2 compliance audit, Microsoft Inclusive Design Persona Spectrum, accessibility testing protocols |
| [MCP Dependencies](#mcp-dependencies) | Figma REQ with screenshot-input fallback; Storybook ENH; Context7 for WCAG and ARIA docs |
| [Output Specification](#output-specification) | Output location, L0/L1/L2 structure, required sections |
| [Routing](#routing) | Keywords and lifecycle-stage routing integration |
| [Cross-Framework Integration](#cross-framework-integration) | Handoff from Atomic Design and Heuristic Eval; accessibility findings output |
| [Synthesis Hypothesis Confidence](#synthesis-hypothesis-confidence) | Confidence classifications for Inclusive Design outputs |
| [Constitutional Compliance](#constitutional-compliance) | Governing principles and AI-augmented analysis limitations |
| [Registration](#registration) | H-26 parent-routed registration model and AGENTS.md confirmation |
| [Deployment Status](#deployment-status) | Wave 3 stub agent status and implementation timeline |
| [Quick Reference](#quick-reference) | Common workflows and agent selection hints |
| [References](#references) | Full repo-relative paths, requirements traceability, external citations |

## Document Audience (Triple-Lens)

This SKILL.md serves multiple audiences:

| Level | Audience | Sections to Focus On |
|-------|----------|---------------------|
| **L0 (Stakeholder)** | Product managers, designers, legal/compliance officers | [Purpose](#purpose), [When to Use This Sub-Skill](#when-to-use-this-sub-skill), [Quick Reference](#quick-reference) |
| **L1 (Developer)** | Engineers invoking the agent | [Invoking the Agent](#invoking-the-agent), [Methodology](#methodology), [Output Specification](#output-specification) |
| **L2 (Architect)** | Workflow designers, skill maintainers | [Cross-Framework Integration](#cross-framework-integration), [MCP Dependencies](#mcp-dependencies), [Synthesis Hypothesis Confidence](#synthesis-hypothesis-confidence) |

---

## Purpose

The Inclusive Design sub-skill provides structured accessibility evaluation using two complementary frameworks: **WCAG 2.2 conformance auditing** (W3C, 2023) and **Microsoft Inclusive Design methodology** (Microsoft, 2016). It targets tiny teams (1-5 people) who need to ensure their products are accessible to the broadest possible range of users while meeting legal compliance requirements (ADA, EAA, Section 508).

This sub-skill is part of Wave 3 (Design System), meaning it requires Wave 2 completion (launched product with analytics OR 1 completed Lean UX hypothesis cycle) before deployment. It pairs with `/ux-atomic-design` in the "Build to Evaluate" canonical sequence: components are built using atomic design principles, then evaluated for accessibility compliance.

### Why Inclusive Design Matters for Tiny Teams

- **Legal compliance** -- The Americans with Disabilities Act (ADA; US DOJ, 2024), European Accessibility Act (EAA, effective June 2025; European Parliament, 2019), and Section 508 (US federal; 29 U.S.C. Section 794d) create legal obligations for digital accessibility. Non-compliance exposes organizations to litigation risk, particularly under Title III ADA case law.
- **Broader user reach** -- Microsoft's Persona Spectrum methodology reveals that designing for permanent disabilities simultaneously benefits users with temporary and situational impairments. Designing for one person with a permanent arm injury also serves someone with a broken arm (temporary) or a parent holding a child (situational). This expands the addressable user base beyond what accessibility compliance alone achieves.
- **Microsoft Inclusive Design principles** -- The methodology operates on three principles: (1) Recognize exclusion -- identify who is being excluded by current design decisions, (2) Solve for one, extend to many -- design for a person in the most constrained scenario and the solution benefits everyone, (3) Learn from diversity -- people with disabilities are experts on adaptation and workarounds that inform better design for all.
- **Cost efficiency** -- Addressing accessibility during design (Wave 3) is significantly less expensive than retrofitting after launch. Teams that evaluate accessibility alongside component design avoid the accumulation of accessibility debt.

### Key Capabilities

- **WCAG 2.2 Compliance Auditing** -- Systematic evaluation against WCAG 2.2 success criteria across four principles (Perceivable, Operable, Understandable, Robust) at conformance levels A, AA, and AAA
- **Persona Spectrum Analysis** -- Application of Microsoft Inclusive Design Persona Spectrum methodology to map permanent, temporary, and situational disability scenarios for each interaction pattern
- **Color Contrast Evaluation** -- Assessment of text and UI component color contrast ratios against WCAG 2.2 success criteria 1.4.3 (AA: 4.5:1 normal text, 3:1 large text) and 1.4.6 (AAA: 7:1 normal text, 4.5:1 large text)
- **Keyboard Navigation Assessment** -- Evaluation of keyboard-only operability including focus order, focus visibility, keyboard traps, and shortcut key conflicts per WCAG 2.2 Operable principle
- **Screen Reader Compatibility Review** -- Assessment of semantic HTML structure, ARIA landmark roles, live region announcements, and alternative text adequacy for assistive technology compatibility
- **Cognitive Load Assessment** -- Evaluation of information density, reading level, consistent navigation patterns, error prevention mechanisms, and input assistance per WCAG 2.2 Understandable principle

> **Source:** Key capabilities derived from parent SKILL.md [skills/user-experience/SKILL.md -- Key Capabilities] ("Inclusive Design Evaluation -- WCAG 2.2 compliance and Microsoft Inclusive Design (Wave 3)") and [skills/user-experience/SKILL.md -- Available Agents] ("Inclusive design and accessibility auditor").

---

## When to Use This Sub-Skill

Activate when:

- Auditing an existing interface or component for WCAG 2.2 conformance at A, AA, or AAA level
- Evaluating color contrast ratios for text, UI components, and graphical objects
- Assessing keyboard navigation completeness and focus management
- Reviewing screen reader compatibility and ARIA implementation
- Performing a Persona Spectrum analysis to map permanent, temporary, and situational disability scenarios
- Evaluating cognitive load and understandability of an interface
- Checking accessibility of components from an atomic design system (Build to Evaluate sequence)
- Responding to "Any stage: Check accessibility" routing from the ux-orchestrator
- Preparing accessibility documentation for legal compliance (ADA, EAA, Section 508)