Build a repeatable, designer-led accessibility audit workflow — automated tools, manual keyboard testing, screen reader evaluation, and a structured audit report with prioritized remediation.
Build a repeatable, designer-led accessibility audit workflow — automated tools, manual keyboard testing, screen reader evaluation, and a structured audit report with prioritized remediation.
The first audit layer uses automated tools to catch the 30-40% of WCAG issues detectable without human judgment. Run these in order:
1. axe DevTools (free Chrome extension): Analyze → Accessibility → Run scan. Shows violations with WCAG criterion references and suggested fixes. Covers contrast, ARIA, form labels, and more. Free version catches most Level A and AA issues.
2. WAVE (free at wave.webaim.org or Chrome extension): Provides visual overlays on the page showing errors (red), alerts (yellow), and structural features. Particularly good for visualizing heading hierarchy and landmark regions.
3. Lighthouse (built into Chrome DevTools): Audits > Accessibility. Scores 0-100 with issues categorized by impact. Good for quick progress tracking but misses many issues that axe catches.
4. Accessibility Insights for Web (Microsoft, free extension): Provides a structured manual test guide after running automated checks, prompting you to do keyboard and visual checks that tools cannot automate.
Document every finding: tool name, page URL, screenshot, WCAG success criterion, element selector. Use a spreadsheet or Notion database as your audit log. Do not attempt to fix while auditing — finish the full audit first, then prioritize.
After automated tools, the manual testing layer catches the 60-70% of issues that cannot be automated:
Keyboard navigation checklist:
Visual checks (no tools needed):
Document time spent per page and which pages were tested. A complete keyboard audit of 10 pages takes approximately 2 hours — plan accordingly.
The third layer is the most time-intensive but catches the most impactful issues for screen reader users. Prioritize your 5 highest-traffic pages and your core user flows (sign up, main feature, settings).
Designer-friendly screen reader test procedure (NVDA + Chrome):
1Step 1: Open NVDA and navigate to the page
2Step 2: Press NVDA+F7 to open the Elements List
3 - Check headings: is the hierarchy logical? Is h1 the page title?
4 - Check landmarks: main, nav, footer present?
5 - Check links: are there any 'click here' or 'read more' links without context?
6
7Step 3: Close Elements List, press H to jump between headings
8 - Can you understand the page structure from headings alone?
9
10Step 4: Tab through all interactive elements
11 - Does every button and link have a meaningful name?
12 - Are form fields announced with their label?
13 - Are required fields announced as required?
14
15Step 5: Submit a form with errors
16 - Are errors announced automatically?
17 - Can you find and correct each error?
18
19Step 6: Trigger a modal or dialog
20 - Is 'dialog' announced when it opens?
21 - Is the dialog title announced?
22 - Are you trapped inside? Can you exit with Escape?Log every discrepancy between what you see and what you hear as a finding.
A professional accessibility audit report has a consistent structure:
1# Accessibility Audit Report
2
3**URL:** https://app.example.com/checkout
4**Date:** 2026-06-05
5**Auditor:** [Name]
6**Standards:** WCAG 2.1 Level AA
7**Tools Used:** axe 4.9, WAVE, NVDA 2024.1 + Chrome 124, Keyboard
8
9## Summary
10- Critical violations (block merge): 3
11- High violations (should fix): 7
12- Medium issues (consider fixing): 12
13- Passes: 41
14
15## Findings
16
17### [CRITICAL] Missing form labels
18**WCAG:** 1.3.1 Info and Relationships (Level A), 4.1.2 Name, Role, Value (Level A)
19**Element:** `<input type="email" placeholder="Email address">`
20**Location:** Checkout form, step 1
21**Screenshot:** [attached]
22**Impact:** Screen reader users cannot determine the purpose of the field
23**Fix:**<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email" />
1
2### [HIGH] Insufficient contrast: button text
3**WCAG:** 1.4.3 Contrast Minimum (Level AA)
4**Element:** `.btn-secondary` — #6B7280 text on #E5E7EB background
5**Current ratio:** 2.3:1 (required: 4.5:1)
6**Fix:** Change button text to #374151 (5.4:1 on #E5E7EB)Prioritize audit findings using an impact-frequency matrix:
1Severity × Frequency = Priority Score
2
3Severity:
4- Critical (WCAG Level A violation): 4 points
5- High (WCAG Level AA violation): 3 points
6- Medium (best practice, AAA violation): 2 points
7- Low (minor improvement): 1 point
8
9Frequency (how many users encounter this):
10- Every user on every page: 4 points
11- Every user on this page: 3 points
12- Users with specific condition/device: 2 points
13- Rare: 1 point
14
15Priority Score = Severity × Frequency
16Fix 12+ immediately (block release)
17Fix 9-11 this sprint
18Schedule 6-8 for next quarter
19Backlog 1-5 for continuous improvementPrevent regression with a recurring audit schedule:
Store audit results with dates in your design system docs. Trend graphs showing violation count over time demonstrate progress to leadership.
Run a complete automated audit of your highest-traffic page using axe DevTools. Follow it with a 20-minute keyboard-only navigation test. Document your top 5 findings using the audit report format and share with the team as your baseline.
Your progress is saved in this browser, on this device only.