frontend-a11ylisted

# Make the UI accessible Bring the affected UI to WCAG 2.2 AA: operable by keyboard, understandable to assistive tech, and tolerant of user preferences — proven, not assumed. ## Steps 1. **Read the lore first.** Call `search_lore` (Memory MCP) for the repo's accessibility conventions and any design-system a11y primitives already in use. 2. **Use semantic HTML before ARIA.** Reach for the native element (`button`, `a`, `label`, `nav`, `dialog`) first; add ARIA roles/attributes only to fill real gaps. 3. **Make it keyboard operable.** Every interactive element must be focusable and activatable by keyboard, in a logical tab order, with a visible focus indicator. 4. **Label everything.** Associate inputs with `label`s, give icon-only controls an accessible name, and announce dynamic changes with live regions where needed. 5. **Manage focus** for overlays/dialogs/menus: move focus in on open, trap it while open, restore it on close. 6. **Respect preferences.** Honour `prefers-reduced-motion`; ensure text/background contrast meets AA (4.5:1 body, 3:1 large text). 7. **Verify + evidence.** Run the repo's automated a11y checks and exercise keyboard flow; record the results via the `record-evidence` skill and submit for review. ## Rules - Native semantics over ARIA; never use ARIA to paper over the wrong element. - No keyboard trap, no focus loss, no invisible focus. - Don't remove focus outlines without a compliant replacement. - Colour is never the only sig