accessibility-auditlisted

# Accessibility audit Two jobs: keep `criteria.md` current with what accessibility actually requires of *this* app, then audit the running UI against it. **Read `.claude/skills/audit/audit-loop.md` first** — it owns the loop (research gating, the critique test, how criteria change, the report format, and the rule that findings only become issues with the user's approval). This file owns the domain: where to look and how to probe it without being lied to. Pass `--research` to force a research pass; otherwise the cadence in `criteria.md` decides. ## Research sources (phase B) Ask what changed **since `last-researched`**, not what accessibility is: - **W3C** — WCAG (2.2 is the current Recommendation; treat 3.0 as a draft, i.e. not yet a criterion), WAI-ARIA, and the APG patterns for dialog, tabs, listbox and disclosure — the four patterns this UI actually uses. - **EN 301 549** and the EAA/BFSG applicability question — but only far enough to hand the *legal* question to `legal-audit` (see A-R05). Do not decide a legal duty here. - **Browser/platform changes** that invalidate a held technique: `:focus-visible` behaviour, `inert`, dialog element semantics, `prefers-reduced-motion`. Then run the critique in `audit-loop.md` §C. Two conflicts are pre-recorded in `criteria.md` (A-R02 target size, A-R03 `aria-modal`) — if research proposes either again, that is the ledger working, not a new finding. ## Setting up a session you can trust (phase E) Three things will ea