As asked
Walk me through how you would run an accessibility audit on a web app. What do you check, and how do you prioritise the findings?
Sample answer outline
Automated first: axe DevTools or Lighthouse for the obvious wins (missing labels, contrast, semantic HTML). Manual next: keyboard navigation through every primary flow without a mouse, screen reader pass with VoiceOver or NVDA on the highest-traffic pages, zoom to 200 percent and check responsive behaviour. Test with users who rely on assistive tech, not just simulated. Prioritise by WCAG severity and traffic: critical paths on top, decorative issues last. Report findings with screenshots, the specific WCAG criterion, the user impact, and a suggested fix. Track to remediation, do not just file and forget.
Expect these follow-ups
- What is the biggest a11y mistake even careful teams make?
- How do you embed a11y into the design and review process so audits find less?
- When is a custom component cheaper than fixing the native equivalent?
accessibilitywcagaudit