← ClaudeAtlas

a11y-auditlisted

Audit a UI for accessibility against WCAG 2.2 AA — run the engine, then do the two-thirds it cannot see. Load when designing, building, or verifying any user-facing surface.
soumit-kaz/lazysitter · ★ 1 · Code & Development · score 69
Install: claude install-skill soumit-kaz/lazysitter
# Accessibility audit ## Run the engine first If an accessibility engine exists (jest-axe, `@axe-core/react`, `@axe-core/playwright`, or a wired `eslint-plugin-jsx-a11y`), **run it and report its output**. Automated testing catches roughly a third of real defects — a genuinely useful third, mechanically, with zero judgement. If none exists, say **`degraded: true`** and name the gap. Do not substitute a reasoned reading of the JSX for a missing engine: accessibility properties are observable, and closing an observable concern by argument is exactly the failure the observable-claim rule exists to prevent. ```bash lazysitter fe-index signals --rule A11Y # mechanical findings with path:line ``` ## Then the two-thirds the engine cannot see An engine cannot press keys, follow focus, or judge whether an accessible name is *meaningful*. These checks need you. ### 1. Keyboard path — the highest-value check With the pointer untouched: - **Reach** every interactive element with `Tab`, in an order matching the visual order. - **Activate** with `Enter` (and `Space` for buttons and checkboxes). - Find anything **unreachable**: a control behind a hover-only affordance, a custom widget with no `tabIndex`, an element after a focus trap. - Find any **trap**: somewhere `Tab` cannot escape and `Escape` does not release. - Check **skip-to-content** exists if the nav is long. ### 2. Focus lifecycle - **On open** (dialog, drawer, menu, popover): where does focus go? Usually the first fo