Audit Components Against the Accessibility Floor

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: `{{sistema_url}}/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** — For each text/background pairing, POST the hex values to `{{sistema_url}}/api/contrast` and use the returned ratio and pass/fail verdict. Report the exact ratio — do not estimate. All normal text must return `aa_text: true` (≥ 4.5:1); large text and UI components must return `aa_ui: true` (≥ 3:1). 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 ---