Accessibility Audit Checklist: Step-by-Step WCAG 2.2 Guide

A complete guide to finding accessibility issues on your website, from free automated scanning tools to manual keyboard and screen reader testing. Covers WCAG 2.1 and 2.2.

February 02, 2026

You can't fix what you don't measure

Most teams know accessibility matters, but when they sit down to actually evaluate their website, the question becomes: where do you start? WCAG has dozens of success criteria. Your site has dozens (or hundreds) of pages. Testing everything manually would take weeks.

The answer is a structured accessibility audit - a systematic process that combines automated scanning, manual testing, and assistive technology verification to identify issues efficiently and prioritize fixes effectively.

This guide walks you through the complete audit process, from initial automated scans to hands-on testing with screen readers.

Step 1: Automated scanning

Automated tools are the fastest way to identify a large number of accessibility issues. They can scan hundreds of pages in minutes, checking for programmatically detectable failures like missing alt text, insufficient contrast, broken ARIA, and missing form labels.

What automated testing catches

Automated tools excel at detecting issues that follow clear, testable rules:

Missing alt text on images
Color contrast failures - comparing foreground and background colors against WCAG thresholds
Missing form labels - inputs without associated <label> elements
Heading hierarchy errors - skipped levels or missing <h1>
Missing document language - no lang attribute on <html>
Invalid ARIA - wrong roles, missing required properties, invalid values
Missing landmark regions - no <main>, <nav>, or <header>
Empty links and buttons - interactive elements with no accessible name

What automated testing misses

Research consistently shows that automated tools can detect roughly 30-40% of WCAG issues. The rest require human judgment. Automated tools struggle with:

Alt text quality - a tool can check if alt text exists, but can't judge if it's accurate or useful
Keyboard usability - tools can check if elements are focusable, but can't evaluate if the focus order makes sense or if custom widgets are operable
Content clarity - whether instructions are understandable, error messages are helpful, or reading level is appropriate
Context-dependent issues - whether a form's workflow makes sense, whether a timeout is too short, or whether animation can be paused
Visual presentation - whether text reflows properly when zoomed, whether content is visible when colors are overridden, or whether hover/focus states provide sufficient information

This is why automated scanning is the first step of an audit, not the only step. It efficiently clears the straightforward issues so you can focus manual testing on the nuanced ones.

Step 2: Manual keyboard testing

After running automated scans and fixing the identified issues, the next step is manual testing with a keyboard. This catches interaction problems that automated tools can't detect.

Set your mouse aside and navigate your site using only your keyboard. Work through this checklist:

Navigation checklist

Skip link: Press Tab once from the top of the page. Does a "Skip to main content" link appear? Does it work?
Focus visibility: As you Tab through the page, can you always see which element has focus? Is the focus indicator clearly visible against the background?
Tab order: Does focus move through elements in a logical order that matches the visual layout?
All interactive elements: Can you reach every link, button, form field, menu, and custom widget with Tab?
Activation: Can you activate links with Enter? Buttons with Enter or Space? Checkboxes with Space?
Dropdowns and menus: Can you open them, navigate options with arrow keys, select with Enter, and close with Escape?
Modals and dialogs: When a modal opens, does focus move to it? Can you navigate within it? Does Escape close it? Does focus return to the triggering element?
No keyboard traps: Can you always move forward with Tab and backward with Shift+Tab without getting stuck?

Step 3: Screen reader testing

Screen reader testing reveals how your content is actually experienced by blind and low-vision users. Even if your HTML passes automated checks, the real-world experience might be confusing, verbose, or missing critical context.

Getting started with screen readers

You don't need specialized equipment to test with a screen reader. Free options are built into the operating systems you already use:

VoiceOver (macOS/iOS) - press Command+F5 on Mac to enable. Built into every Apple device.
NVDA (Windows) - a free, open-source screen reader widely used by blind users. The most popular screen reader on Windows alongside JAWS.
TalkBack (Android) - built into Android devices, accessible through accessibility settings.

For your first screen reader test, you don't need to become an expert. Focus on these basics:

Page load: Does the screen reader announce a meaningful page title?
Headings navigation: Can you navigate by headings to get an overview of the page structure?
Images: Are images described meaningfully? Are decorative images silent?
Forms: Are form fields announced with their labels? Are required fields indicated? Are error messages announced?
Dynamic content: When content updates on the page (search results, notifications, form validation), is it announced?
Links: Do link texts make sense when heard without surrounding context?

Step 4: Visual and zoom testing

Test how your site behaves when users modify the visual presentation to meet their needs:

Zoom to 200%: Use your browser's zoom (Ctrl/Cmd + Plus) to zoom to 200%. Does all content remain visible and functional? Is there horizontal scrolling? Do elements overlap?
Text-only zoom: In Firefox, you can zoom text only (View > Zoom > Zoom Text Only). Does the layout handle larger text gracefully?
High contrast mode: On Windows, enable High Contrast mode to verify your content is visible when users override your color scheme. Custom CSS properties may be lost.
Reduced motion: If your site uses animations, enable the "Reduce motion" setting in your operating system preferences. Do animations respect prefers-reduced-motion?

Step 5: Prioritizing your findings

After completing your audit, you'll likely have a list of issues ranging from critical blockers to minor improvements. Prioritize based on severity and impact:

Fix first: Errors

These are WCAG violations that completely block users from accessing content or functionality. Missing alt text on critical images, keyboard traps, missing form labels, and broken ARIA that prevents screen reader interaction all fall here. Fix these immediately - they represent real barriers for real users.

Fix next: Warnings

These are likely WCAG violations that create significant barriers but may not completely block access. Low contrast text that's still somewhat readable, heading hierarchy issues that make navigation harder, and links that open in new windows without warning belong in this tier. Plan to fix these in your next development cycle.

Fix when possible: Notices

These are best practice recommendations that improve the experience without being strict WCAG violations. Redundant ARIA, suboptimal alt text that's present but could be better, and missing skip links on pages with few navigation items. Address these as part of ongoing improvement.

Making audits a regular practice

A single audit gives you a snapshot. But websites change - new pages are added, features are updated, content is published. Accessibility can regress with any change if it's not monitored.

Sustainable accessibility requires regular scanning:

Automated scans on every deployment or at least weekly
Manual keyboard testing when new interactive components are added
Screen reader testing when page templates or navigation change
Full audits quarterly or semi-annually

How AccessGuard fits into your audit process

AccessGuard handles Step 1 comprehensively - automated scanning across all the major WCAG categories including alt text, contrast, ARIA, headings, forms, keyboard indicators, landmarks, and more. Each issue is categorized by severity (error, warning, notice) and mapped to the specific WCAG criterion it violates, giving you the prioritization framework described above right out of the box.

By starting with an AccessGuard scan, you clear the automated-detectable issues quickly, freeing your team to focus manual testing time where it matters most - the nuanced, context-dependent issues that only human judgment can evaluate.