a11y-gatelisted

# Accessibility gate (WCAG 2.2 AA, verified) Make a web UI accessible and **prove it** — conformance is gated by checks that run (axe-core, scripted keyboard/reflow audits) plus a mandatory human checklist, not by assertion. ## Core principle **Conformance is measured, not claimed.** The loop is: scan → triage by severity → fix the root cause → re-scan, until the automated gate is green; then complete the manual + screen-reader checklist before sign-off. **Be honest about scope (this is the rule that keeps the skill correct):** automated tools catch only ~30–50% of WCAG issues. A green scan is **necessary, not sufficient**. Never report "WCAG AA conformant" on automated results alone — report "0 blocking automated violations; manual checklist completed and attested." → `references/01-standards-and-scope.md` ## When to use vs. not - Use for: auditing/fixing accessibility of a site, app, page, or component; adding an a11y CI gate; keyboard/contrast/ARIA/screen-reader review; WCAG / ADA / Section 508 / EAA remediation. - Not for: native-mobile-only a11y (different tooling), or general UI design with no accessibility ask. ## Inputs to gather first 1. **What to audit** — URL(s)/routes, and key interactive states (menus, modals, tabs). The app must be runnable locally (prefer the production build). 2. **Target level** — default **WCAG 2.2 AA**; confirm if a different standard (2.1 AA, AAA, Section 508) is required. 3. **Severity bar** — default gate blocks on `c