awesome-accessibility-auditlisted

# Accessibility Audit Review UI and markup for accessibility and give the concrete fix for each finding, aligned with WCAG, so all users can perceive, operate, and understand the interface. Read-only: it reports findings, each with the markup or attribute change that resolves it, and never applies them. A snippet in a report is reviewable next to the criterion it satisfies; the same edit applied silently is not. Hand the report to whoever owns the component. ## When to Activate - User asks for "accessibility", "a11y", "WCAG", or "screen reader support" - Before shipping a new page or component - Reviewing forms, modals, or interactive UI - After a design or UI change that affects interaction or content ## Work Process 1. Define scope — Page, component, or flow to review (e.g. login form, report table, modal dialog). 2. Check each area — Semantic HTML, keyboard, labels and names, color and contrast, dynamic content, motion. Use the checklists below. 3. Document findings — Location (component/file or element type), WCAG criterion or principle, issue, impact, and recommended fix. Severity: Critical / High / Medium. 4. Give the fix, do not apply it — A code snippet or attribute change in the report where possible. Prefer native HTML and correct ARIA over custom widgets when they suffice. 5. Recommend follow-up — Suggest automated tools (e.g. axe, Lighthouse, pa11y; in CI, fail the build on critical) and manual testing for broader coverage. Automated tools catch roughly 30–4