Accessibility Audit

Review UI and markup for accessibility and suggest concrete fixes aligned with WCAG so all users can perceive, operate, and understand the interface.

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 / major / minor.
4. Suggest fixes — Code snippet or attribute change 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) and manual testing (keyboard only, screen reader) for broader coverage. Do not claim full WCAG compliance from a single review.