Audit a web page for accessibility issues
Conduct a structured accessibility audit of a publicly available web application. Using a combination of automated scanning (axe DevTools browser extension), keyboard navigation testing, and screen reader spot-checking, identify and classify all accessibility issues against WCAG 2.1 AA criteria, then write prioritised remediation notes for the development team.
Why this matters
Accessibility failures are both a legal risk and a quality failure; a page that cannot be navigated by keyboard is broken for power users and assistive technology users alike. A QA engineer who can audit for accessibility and write actionable remediation notes is rare and genuinely high-value, because most accessibility issues are introduced by developers who have never run a screen reader through their own UI.
Before you start
- Chrome or Firefox with the axe DevTools extension installed (free tier is sufficient)
- NVDA (Windows, free) or VoiceOver (Mac, built-in) for screen reader testing
- Access to a publicly available web application with interactive elements (forms, navigation, modals)
- Basic knowledge of WCAG 2.1; understand the four principles: Perceivable, Operable, Understandable, Robust
Step-by-step guide
- 1
Run the automated axe scan
Navigate to the target page, open axe DevTools, and run a full page scan. Export the results. Note: automated tools catch roughly 30-40% of accessibility issues. Every issue axe finds is real; the absence of findings does not mean accessible.
- 2
Test keyboard navigation
Close your mouse and navigate the entire page using only Tab, Shift+Tab, Enter, Escape, and arrow keys. Check: can you reach every interactive element? Is the focus indicator always visible? Does focus order match visual reading order? Does every modal trap focus correctly? Record every failure.
- 3
Check colour contrast
Use the axe colour contrast checker or the WebAIM Contrast Checker on 5 text/background combinations. WCAG AA requires 4.5:1 for normal text and 3:1 for large text. Record any failures with the exact hex colours and measured ratio.
- 4
Test with a screen reader
Enable NVDA or VoiceOver and navigate to the page. Listen: are images announced with useful alt text? Are form fields announced with their labels? Are error messages announced when they appear? Do buttons announce their purpose? Record anything that sounds confusing or empty.
- 5
Classify all findings
Group every finding into three categories: Critical (blocks task completion for an assistive technology user), Serious (causes significant difficulty), and Moderate (causes minor confusion). Apply WCAG criteria codes (e.g., 1.4.3 Contrast Minimum) to each finding.
- 6
Write remediation notes
For each critical and serious finding, write a one-paragraph remediation note: what the issue is, the affected element (CSS selector or XPath), the WCAG criterion, the specific fix required, and the expected outcome after the fix. Good remediation notes turn an audit report into developer action.