Skip to main content

Accessibility Audit Guide

A full accessibility audit for screen-reader and keyboard navigation requires combining automated checks, manual testing, and real-user assistive technology workflows. Automated tools only surface a subset of issues (~30-40%), so manual testing is essential.

Audit Process Overview

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│ Automated │ ──▶ │ Keyboard │ ──▶ │ Screen Reader │
│ Scanning │ │ Testing │ │ Testing │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────┐
│ Document & Report Findings │
└─────────────────────────────────────────────────────────────────┘

Phase 1: Automated Scanning

Automated tools are fast and catch common issues (missing alt text, ARIA mistakes, color contrast, label issues). They give you a baseline.

ToolWhat It DoesCost
axe DevToolsDeep rule set integrated in browser DevToolsFree + Paid
WAVE (WebAIM)Browser extension highlights errors inlineFree
LighthouseQuick overall accessibility scoreFree
Pa11yCLI/CI accessibility testing automationFree
Accessibility InsightsFast automated + guided manual testsFree

How to Use

  1. Install axe or WAVE extension in Chrome/Edge
  2. Open your target page
  3. Run the scan on critical pages and record findings
  4. Export report (CSV/JSON) for later comparison
warning

Automated checks typically catch only ~30-40% of total issues — this is just one part of the audit.

Phase 2: Keyboard Navigation Testing

Automated tools can't fully assess keyboard experiences. You need to walk through the app manually.

What to Test

ActionWhat to Check
TabIs order logical and predictable?
Shift+TabDoes backward navigation work?
Enter/SpaceDo buttons and links activate?
Arrow keysDo they work in dropdowns, radio groups?
EscapeDoes it close modals/dialogs?

Checklist

  • All interactive elements reachable by Tab
  • Focus indicator is clearly visible
  • No keyboard traps
  • Custom components (dropdowns, sliders, modals) are keyboard-operable
  • Focus is trapped inside open dialogs
  • Focus returns to triggering element after dialog close
  • Skip link exists and works

Phase 3: Screen Reader Testing

This is where automated tools do not help. You must test with actual screen readers.

PlatformScreen Reader
WindowsNVDA (free), JAWS (paid)
macOSVoiceOver (built-in)
iOSVoiceOver (built-in)
AndroidTalkBack (built-in)

What to Check

  • Meaningful link/button announcements
  • Correct headings structure (H1, H2, ...)
  • Form labels read aloud
  • ARIA role accuracy (menus, dialogs, live regions)
  • Dynamic updates announced
  • Content not announced twice

Basic Commands

NVDA/JAWS:

  • H - Navigate by headings
  • T - Navigate by tables
  • F - Navigate by form fields
  • K - Navigate by links
  • B - Navigate by buttons
  • Insert+F7 - List all elements

VoiceOver (Mac):

  • Cmd+F5 - Start/Stop VoiceOver
  • VO+A - Start reading
  • VO+Right Arrow - Next item
  • VO+Cmd+H - Next heading
  • VO+U - Rotor menu

Phase 4: Document Findings

For each page or flow, record:

  • Page/component name
  • Device/OS/browser/screen reader used
  • Automated errors/warnings
  • Keyboard issues
  • Screen reader confusion points
  • Severity & screenshots
  • Fix recommendations

Week 1: Automated + Keyboard Testing

DayTask
1Install and configure automated tools
2-3Keyboard navigation testing on all pages
4-5Run automated scans with multiple tools

Week 2: Screen Reader Testing

DayTask
1Setup screen readers (NVDA, VoiceOver)
2-4Test critical user flows
5Document findings and prioritize fixes

Priority Order

Critical (Blockers)

  • Keyboard traps
  • Missing form labels
  • Inaccessible interactive elements

High Priority

  • Missing alt text on meaningful images
  • Poor heading structure
  • Color contrast issues

Medium Priority

  • Missing landmarks
  • Non-descriptive link text
  • Missing skip links

Low Priority

  • Minor ARIA issues
  • Redundant alt text