Audit and Refactor a Design System

Use this play to evaluate the current state of the design system's components against the non-negotiable accessibility requirements. Produces a structured report with severity levels. **Step 1 — Read the living brief:** Read `LIVING_BRIEF.md`. Note which components are implemented and any accessibility decisions already recorded. **Step 2 — Read the references:** Read the following from the Sistema knowledge base: - Accessibility floor: `/raw/principles/accessibility/floor` This is the normative checklist. Every item marked "must" in that document is a blocking violation if not met. **Step 3 — Define the audit scope:** Components to audit: [List the components you want to audit, or write "all implemented components" to audit everything in the living brief's current state list.] **Step 4 — Evaluate each component:** For each component, evaluate against each section of the accessibility floor: 1. **Color contrast** — Do all text/background pairings meet 4.5:1 (normal text) or 3:1 (large text / UI components)? 2. **Keyboard navigation** — Is every interactive element reachable by keyboard? Can it be activated with the correct key? 3. **Focus visibility** — Is the focus indicator visible? Does it meet 3:1 contrast against the adjacent surface? 4. **Touch targets** — Is the interactive area ≥ 44×44px? 5. **Semantic structure** — Does the component use semantic HTML or a full ARIA implementation? 6. **Accessible name** — Does every interactive element have an accessible name? 7. **Dynamic state** — Are state changes (expanded, selected, checked) exposed via ARIA attributes? **Step 5 — Produce the audit report:** For each component: - Pass / Fail / Needs verification per criterion - Specific violations with severity: **blocking** (WCAG A/AA violation), **recommended** (best practice not met), **minor** (enhancement) Summary: - Components fully passing - Components with blocking violations (must fix before ship) - Components with recommended improvements ---