An ADA compliance audit is a structured two-phase process that combines automated scanning with manual expert testing to identify WCAG 2.1 Level AA failures across your entire site. Automated tools catch roughly 30 to 40 percent of issues. Human testers using screen readers, keyboard navigation, and assistive technology catch the rest. The output is a documented report with exact failure locations and fix-ready remediation guidance.
Most business owners discover they have an accessibility problem the wrong way. A law firm sends a letter. A plaintiff files in federal court. And suddenly “ADA compliance” becomes the most urgent line item in the budget.
Here’s the thing most people miss: the gap between a site that looks compliant and one that actually is compliant is rarely obvious from the front end. The failures that generate lawsuits live in the code, in the DOM structure, in the way form elements are wired up, in whether a focus indicator actually appears when a keyboard user tabs through your nav. None of that is visible to a sighted user casually browsing the site. All of it is visible to a trained auditor running the right tools and assistive technologies.
This article walks through exactly how an ada compliance audit works, phase by phase, what each phase is designed to find, and why the structure of the process matters for the legal defensibility of the result.
What an ADA Compliance Audit Is and Why Structure Matters
An accessibility audit is not a scan. That distinction sounds technical, but it has real legal consequences.
A scan is an automated pass over your site’s HTML and CSS looking for machine-detectable WCAG violations. It takes seconds. It catches real issues. And it misses the majority of what a plaintiff’s expert witness will find if your case goes to court.
An audit is a formal, documented process that combines automated analysis with human-verified manual testing. The output is a WCAG 2.1 Level AA conformance report: a structured document that maps each identified failure to the specific WCAG success criterion it violates, records the location in the code, describes the impact on users with disabilities, and provides clear remediation guidance.
That documentation is what makes an audit legally defensible. A plaintiff’s attorney pointing to your site’s failures needs to prove you knew or should have known about them. An audit report proves you did know, and more importantly, that you took structured action. Courts have consistently treated documented remediation efforts more favorably than sites that simply installed a widget and called it done.
What WCAG 2.1 Level AA Requires at the Code Level
WCAG 2.1 Level AA has 50 success criteria. Some are straightforward and machine-detectable. Others require human judgment to evaluate correctly.
The straightforward ones cover things like: images needing non-empty alt attributes, form inputs needing programmatically associated labels, text needing a minimum contrast ratio of 4.5:1 against its background, pages needing unique and descriptive title elements, and interactive components needing visible focus indicators. Automated tools handle these reliably.
The judgment-call criteria cover things like: whether an image’s alt text actually conveys the image’s purpose in context, whether the reading order of a page makes logical sense when the visual layout is removed, whether error messages in forms are specific enough to allow a user to correct their input, and whether time limits on interactive sessions can be extended or removed. These require a human being to actually use the site.
Why Half the Audit Market Gets This Wrong
The accessibility industry has a short-cut problem. Demand for compliance solutions outpaced the supply of trained human auditors, so vendors filled the gap with overlay tools, automated badges, and self-generated certificates.
None of those products produce a WCAG conformance audit in any meaningful sense. They produce a scan score. That score may be useful for understanding your starting point. It is not sufficient as a compliance artifact, and it will not hold up to scrutiny if a demand letter or lawsuit follows.
Phase One: Automated Scanning
A professional audit starts with a full automated scan. Not because automation is sufficient, but because it’s fast, reproducible, and surfaces the issues that can be fixed without consuming expensive human hours.
The scan phase typically uses tools like Axe, WAVE, or Lighthouse, often in combination, because no single tool catches every machine-detectable issue. Each tool has different rule coverage, different false-positive profiles, and different output formats. Running multiple scanners and reconciling results produces a more complete baseline than relying on one tool alone.
What comes out of this phase is a prioritized issue list, organized by WCAG success criterion, severity, and frequency across pages. A well-run scan phase doesn’t just flag problems on the homepage. It crawls the site systematically: landing pages, form pages, checkout flows, blog posts, PDFs linked from content, modal dialogs, navigation menus, and any third-party embedded components that render in the user’s browser.
What Automated Scanning Reliably Catches
- Missing or empty alt attributes on images
- Form inputs without associated label elements
- Color contrast ratios below 4.5:1 for body text or 3:1 for large text
- Missing or duplicate page title elements
- Missing language attribute on the HTML element
- Heading hierarchy violations (skipped heading levels, decorative use of heading tags)
- Links with non-descriptive anchor text like “click here” or “read more”
- iFrames without titles
- Auto-playing media without controls
These are not trivial. Fixing them meaningfully reduces your risk exposure. But they represent roughly a third of what a full WCAG 2.1 AA evaluation covers.
Phase Two: Manual Expert Testing
This is where an accessibility audit separates from a scan report, and where the majority of litigation-relevant failures get identified.
Manual testing means a trained human evaluator working through your site using assistive technologies and documented test procedures. The evaluator is typically testing against WCAG 2.1 Level AA success criteria that cannot be reliably evaluated by machine: criteria that require judgment about context, meaning, logical flow, and real-world usability.
That sounds obvious. But most people do the opposite. They run a scan, fix the flagged items, and consider the job complete. The manual phase is where they get surprised.
Keyboard Navigation Testing
A keyboard navigation test means navigating your entire site without a mouse. Every link, button, form field, dropdown, modal, date picker, accordion, carousel, and interactive widget gets tested by pressing Tab, Shift+Tab, Enter, Space, and the arrow keys.
What evaluators look for: Is there a visible focus indicator on every interactive element? Does tabbing through the page follow a logical order that matches the visual layout? Are there keyboard traps where focus enters a component and can’t escape? Can every action available to a mouse user be completed with a keyboard alone?
Keyboard accessibility failures are among the most commonly cited issues in ADA litigation. They’re also almost never caught by automated scanning, because a scanner reads the DOM, not the interaction model.
Screen Reader Testing
Screen reader testing uses JAWS, NVDA, or VoiceOver to navigate the site as a blind user would. The evaluator is listening, not watching. What matters is whether the spoken output communicates the same information and relationships that the visual layout communicates.
Common failures that only surface here: carousels that read as unlabeled groups of links, data tables without row and column header associations, modal dialogs that don’t receive focus when opened, form validation errors that aren’t programmatically associated with the fields they describe, and icon buttons that have no accessible name because the icon carries no text.
Here’s the thing most people miss: ARIA attributes, when used incorrectly, can make accessibility worse, not better. A developer who adds role=”button” to a div element without also adding keyboard event handlers has created a control that announces as a button but doesn’t behave like one. That’s a WCAG 2.1 Level A failure that a screen reader user will hit every time and that no automated tool will flag as critical.
Cognitive and Visual Accessibility Review
Not every accessibility failure involves a screen reader or a keyboard. WCAG 2.1 Level AA also covers issues that affect users with cognitive disabilities, low vision, and photosensitivity.
This phase checks for: content that requires reading level beyond the scope of the intended audience without appropriate support, instructions that rely solely on sensory characteristics (like “click the green button”), text resizing up to 200 percent without loss of content or function, animations or transitions that can be disabled for users who experience motion sickness, and focus appearance meeting minimum size and contrast thresholds under WCAG 2.2.
What an Accessibility Audit Report Contains
The deliverable from a professional audit is not a spreadsheet of scan results. It’s a structured conformance report.
A complete report includes:
Overall conformance status against WCAG 2.1 Level AA, summary of critical, serious, and minor issue counts, and a plain-language description of the site’s current accessibility posture.
Each issue documented with its WCAG success criterion reference, severity rating, location in the code (URL, DOM path, or component name), description of the failure, impact on affected user groups, and specific remediation guidance.
A WCAG 2.1 AA success criterion checklist showing which criteria the site currently meets, which it fails, and which require ongoing monitoring.
Issues ranked by legal risk, user impact, and implementation complexity. Not all failures are equally urgent. A report that treats a missing language attribute with the same urgency as a keyboard trap is not useful.
Evidence documentation: Screenshots, screen recordings, or assistive technology output showing each identified failure in its actual context.
This report serves two purposes. Internally, it’s your remediation roadmap. Externally, in the event of litigation or a regulatory inquiry, it’s your documented evidence that you identified the issues and took structured steps to resolve them.
How Long an ADA Compliance Audit Takes
It depends on the size and complexity of the site. A small business site with ten to fifteen page templates and a straightforward CMS typically takes five to ten business days for a complete audit. A large e-commerce platform with hundreds of unique templates, a checkout flow, account management features, and embedded third-party components can take four to six weeks.
The most common mistake is treating an audit as a one-time event. Sites change. New content gets published, new features get shipped, new third-party scripts get added. An accessibility audit is a point-in-time snapshot. Maintaining compliance requires either scheduled re-audits or continuous monitoring between full audit cycles.
Frequently Asked Questions
Q: What is an ADA compliance audit?
A: An ADA compliance audit is a structured evaluation of a website against WCAG 2.1 Level AA standards, combining automated scanning with manual expert testing. It produces a documented report mapping each identified failure to a specific success criterion, with remediation guidance and legal evidence value.
Q: How is an accessibility audit different from an automated scan?
A: An automated scan uses software tools to detect machine-identifiable WCAG violations and typically catches 30 to 40 percent of total issues. An accessibility audit adds human expert testing using screen readers, keyboard navigation, and cognitive evaluation, covering the full range of WCAG criteria including those that require judgment to evaluate.
Q: What does an accessibility audit report include?
A: A complete audit report includes an executive summary, a detailed issue register with WCAG criterion references and remediation guidance, a pass or fail matrix for all WCAG 2.1 AA success criteria, severity and priority rankings, and documented evidence for each identified failure.
Q: How often should a website undergo an ADA compliance audit?
A: A full audit should be conducted at least once per year and after any significant redesign, platform migration, or major feature release. Automated monitoring should run continuously between full audit cycles to catch new issues introduced by routine content updates and code changes.
Q: Who conducts an accessibility audit?
A: A qualified accessibility audit is conducted by certified evaluators, typically professionals holding credentials such as the IAAP’s CPWA (Certified Professional in Web Accessibility) or WAS (Web Accessibility Specialist). Auditors use a combination of automated tools and manual testing with JAWS, NVDA, VoiceOver, and keyboard-only navigation.
Q: Can I do an ADA compliance audit myself?
A: You can run automated scans yourself using free tools like Axe DevTools or WAVE. However, the manual phase requires training in assistive technology use, WCAG evaluation methodology, and report documentation. Most organizations commission professional audits because the manual phase is where the most serious and litigation-relevant failures are found.
