a11y

# A11y Help ship interfaces that work for **keyboard, screen readers, voice control, and low vision**—without treating accessibility as a bolt-on checkbox. ## What this skill is for - **Concrete fixes**: focus traps, missing names/roles, heading order, label–control wiring, live regions, skip links. - **Design trade-offs**: custom components vs native elements, motion reduction, contrast vs brand color. - **Verification**: what to test in browser + AT, and what still needs human QA. ## What to skip or defer - Legal **compliance certification** (VPAT, formal audits)—suggest specialists when the user needs signed-off conformance. - **Visual design** taste without an accessibility angle—unless it affects contrast, touch targets, or readability. ## Workflow (adapt freely) 1. **Context** — Who uses what (keyboard-only, VoiceOver, NVDA, zoom)? Which WCAG **level** (A/AA) is the target? 2. **Surface problems** — Route critical paths; list failures (not vague “be more accessible”). 3. **Fix in order** — Blockers first (can’t complete task), then serious (wrong info), then polish. 4. **Prove it** — Tab order, focus visible, screen reader labels, automated checks where useful, manual pass on real flows. ## Anti-patterns to call out - `div` buttons without keyboard support; **only** running Lighthouse and declaring done. - Hiding focus rings “for aesthetics”; icon-only controls with no accessible name. - Over-using `aria-*` instead of using the right **semantic** element first. ## Done when - Critical paths are **keyboard-operable** and **named** for assistive tech; known gaps are documented with owners.