accessibility-checklistlisted

## Purpose Turn "make it accessible" into a concrete, checkable set of steps instead of a vague aspiration applied inconsistently. Use this on any UI that a real user will interact with — accessibility isn't a separate pass reserved for "important" screens. ## When to use it While building any new interactive UI, and as a review pass on any UI diff before it's called done — especially anything with custom widgets (dropdowns, modals, tabs, tooltips), forms, or dynamically appearing content. ## Checklist **Semantic HTML first** - Use `button` for anything clickable that performs an action, `a`/`Link` for anything that navigates — not a `div` with an `onClick`. - Use real form elements (`label`, `input`, `select`, `fieldset`) with `label` correctly associated to its control (via `for`/`id` or wrapping). - Use heading elements (`h1`–`h6`) in a logical, non-skipping order to convey document structure, not just for font size. - Reach for ARIA roles/attributes only when semantic HTML genuinely can't express the pattern (e.g. a custom combobox) — an ARIA role bolted onto a `div` is a fallback, not a first choice. **Keyboard navigation** - Every interactive element (buttons, links, form controls, custom widgets) must be reachable via Tab and operable via Enter/Space (or arrow keys, for things like tabs/menus, per the expected pattern for that widget). - Tab order should follow visual/logical order — don't let a positioning trick silently reorder focus. - Nothing should trap keyb