How to Audit a Website for ADA Compliance

This article explains how to audit your website for ADA compliance with practical steps: scope the audit, run automated scans, perform keyboard and screen reader tests, map issues to WCAG 2.1 AA, prioritise fixes, and document results. It includes a sampling strategy for large sites, a remediation workflow, and a sample five-day plan for a 50-page marketing site.

What ADA compliance for websites means

How to audit your website for ADA compliance starts with one fact: the Americans with Disabilities Act does not list technical web rules in the statute. Courts and settlement agreements regularly use the Web Content Accessibility Guidelines, typically WCAG 2.0 or WCAG 2.1 at level AA, as the technical benchmark. For projects outside the US, consider local law. For example, UK public sector guidance uses WCAG 2.1 AA as its standard.

Before you begin: scope and goals

Decide what you will audit. Common scopes are a single template, a site section, key user journeys, or the entire domain. Set clear goals. Examples are reducing legal risk, fixing critical barriers, or meeting a procurement requirement. Gather these items before testing:

List of pages or templates in scope
Analytics to find top pages
Credentials for logged-in flows
Design and development contacts

Step 1 — Run automated scans

Automated tools catch many common issues fast. Run at least two scanners because each tool finds different things. Popular choices are WAVE, Axe, Google Lighthouse, Pa11y and Tenon. Use a headless scanner for large batches and a browser extension for single pages.

What automated checks typically find:

Missing or empty alt attributes
Poor colour contrast for text
Missing form labels and duplicate IDs
Heading structure problems

Limitations: automated tools cannot judge meaningful alt text, audio-only content, complex keyboard traps or whether link text makes sense in context. Expect about 20 to 40 percent of issues to require manual verification.

Manual checks find interaction and content problems. Perform a keyboard-only test first. Then test with a screen reader.

Keyboard checks

Tab through the page. Ensure all interactive elements receive focus and the order matches visual flow.
Confirm there are no keyboard traps. You must be able to move backwards and forwards with Tab and Shift+Tab.
Validate visible focus. Users must always see which element has focus.
Test forms: tab order, focus on error, labels, and clear instructions.

Use NVDA on Windows and VoiceOver on macOS or iOS. Listen for logical reading order.
Verify headings, landmarks, and link text provide context.
Test dynamic content like modals, live regions and custom widgets to ensure proper ARIA roles and focus management.

Step 3 — Map findings to WCAG and priority

Record each issue with the closest WCAG 2.1 AA success criterion. That makes remediation and verification easier. Prioritise issues by impact on users and legal risk.

Critical: keyboard traps, missing labels on input fields, non-functional controls, inaccessible checkout flows
High: insufficient colour contrast, missing captions for essential video, inconsistent heading structure
Medium: ARIA misuse, decorative images with non-empty alt text, less-used interactive widgets
Low: purely cosmetic spacing or layout differences that do not affect accessibility

Core WCAG checks to include

Check these areas on every page you audit.

Non-text content: meaningful images have alt text; decorative images use empty alt attributes.
Contrast: normal text should meet 4.5:1 ratio; large text should meet 3:1.
Keyboard: all functionality must work without a mouse.
Text alternatives for media: captions for video and transcripts for audio when content is essential.
Semantics: correct use of headings, lists, buttons and links rather than divs or spans.
Forms: labels, instructions, error identification and suggestions for correction.

Step 4 — Test complex and dynamic components

Widgets often break accessibility. Check carousels, custom selects, date pickers, maps and rich text editors. For each widget verify:

Logical keyboard operation
Correct ARIA roles, states and properties where native HTML cannot be used
Visible focus and screen reader announcements for state changes

Remember ARIA should enhance semantics, not replace missing native elements.

Sampling strategy for large sites (practical method)

For very large sites do not attempt page-by-page checks. Use analytics and templates to sample efficiently.

Export top 20 pages by traffic as measured in your analytics tool.
Identify every distinct template or component used across the site and test each one.
Include all critical user journeys such as login, search, checkout and account settings.
Randomly pick a set of pages from low-traffic areas to check for legacy problems.

This combination catches common issues while keeping effort under control.

How to document issues for developers and legal records

Good documentation speeds fixes and creates an audit trail. For each issue capture:

Page URL and page screenshot that highlights the problem
Steps to reproduce the issue with user-agent and tool versions used
Expected behaviour and the WCAG success criterion being violated
Suggested remediation and estimated developer effort
Priority level and business impact

Store reports in a central location and tag issues in your issue tracker. Keep raw test files and recordings for future reference.

Prioritise fixes: a simple decision framework

Use three factors to choose what to fix first: severity for users, legal exposure, and development effort. Fix issues that block core flows and keyboard access first. Next, fix media accessibility and contrast. Lower priority items include purely visual details that do not affect access.

Remediation workflow and ongoing monitoring

Make accessibility part of your release cycle. Steps to embed it:

Add automated checks to your CI pipeline using Axe or similar
Include accessibility test cases in manual QA scripts
Train designers and developers on semantic HTML and WCAG basics
Schedule periodic re-audits after major releases

Example audit plan for a small marketing site (50 pages) — sample timeline

This is an example to show effort, not a rule.

Day 1: run automated scans across all pages; gather analytics and credentials
Days 2 to 3: manual testing of top 20 pages, templates and contact forms using keyboard and screen reader
Day 4: map each finding to WCAG and estimate remediation effort
Day 5: deliver a prioritized report and handover to development

Practical checklist

Run two different automated scanners
Test keyboard navigation across critical flows
Verify with at least one screen reader
Check colour contrast against 4.5:1 and 3:1 thresholds
Confirm captions or transcripts for essential media
Document fixes with clear reproduction steps and WCAG references
Integrate automated checks into CI and QA

Final notes and next steps

An audit finds barriers. Remediation removes them. If you need a formal compliance opinion or legal advice use a qualified accessibility consultant or lawyer. For technical teams, begin by fixing keyboard access and labels. These changes usually deliver immediate improvements for many users.