ADA Website Accessibility Audit: Scope and WCAG Testing

An ADA website accessibility audit identifies technical barriers and records WCAG results. It does not by itself determine legal compliance. The applicable ADA title, entity type, jurisdiction, content exceptions and accommodation duties require legal review.

This guide separates the DOJ's defined Title II rule from the less uniform Title III website landscape, then gives a technical process for recording barriers. Use counsel to connect those facts to a particular entity and claim.

What Is ADA Compliance

The ADA is a civil rights law that prohibits discrimination against individuals with disabilities in all areas of public life. Title III of the ADA covers public accommodations — businesses and organisations that serve the public. The legal question that has been debated and increasingly settled over the past decade is whether websites qualify as places of public accommodation.

The Department of Justice's 2024 Title II rule sets WCAG 2.1 Level AA requirements for state and local government web content and mobile apps, subject to stated exceptions and compliance dates. That rule does not create the same technical standard for private businesses under Title III.

Federal courts have taken different approaches to Title III websites and the connection to a physical public accommodation. Do not use a single national rule or a case list as a substitute for advice on the relevant circuit and facts.

Regardless of the unresolved Title III questions, test whether disabled users can complete the service's real tasks and provide an effective route for assistance. That evidence supports product remediation and any legal assessment.

Legal Landscape

Private litigation exists, but annual complaint totals and settlement figures come from third-party trackers and vary by method. Base remediation priority on user impact and verified barriers rather than unsupported litigation statistics.

A complaint may arise when a disabled person cannot complete a transaction, access information or use a service. Audit the reported task and barrier directly. Avoid assumptions about a claimant or the validity of a legal case.

Remedies and costs depend on the claim, jurisdiction and outcome. Record barriers accurately and ask qualified counsel to assess legal exposure. The Eleventh Circuit vacated the district-court judgment in the Winn-Dixie case, so it should not be presented as a current nationwide compliance order.

Prioritise public and transactional journeys such as product research, booking, account access, forms and payment because a barrier there can prevent the underlying service.

A widget or overlay may change selected client-side behaviour, but it cannot establish WCAG conformance or ADA compliance for untested content, documents, integrations and processes. Verify the underlying page and task, including the widget's own keyboard and assistive-technology behaviour.

WCAG as the Standard

The ADA statute does not name a general website technical standard. The DOJ's Title II rule specifically adopts WCAG 2.1 Level AA for covered state and local government content, with exceptions and dates. Title III cases and agreements require separate review.

WCAG conformance requires all applicable Level A and AA success criteria for full pages and complete processes, plus the standard's other conformance requirements. A representative sample can find defects but cannot establish a claim for untested content.

WCAG conformance does not guarantee legal immunity or access for every individual. Use WCAG as technical evidence and test real tasks with assistive technology. Ask counsel how that evidence applies to the organisation.

WCAG 2.2 is W3C's current Recommendation and adds nine success criteria while removing 4.1.1 Parsing. W3C recommends using the latest version, but the applicable rule or contract may still name 2.0 or 2.1.

Common Violations

Prioritise barriers that block essential tasks or affect many pages. Legal frequency claims require a defined case dataset and should not replace user-impact evidence.

• Missing text alternatives — identify meaningful images whose purpose or information is unavailable to screen-reader users. Decorative images need an empty alternative rather than a description.
• Inaccessible forms — form fields without associated labels, missing error messages, and forms that cannot be completed using a keyboard. Checkout forms and account registration forms are the most legally sensitive because they directly block access to goods and services.
• Lack of keyboard accessibility — interactive elements that can only be operated with a mouse. Dropdown menus, modal dialogs, carousels, and custom widgets are common offenders. If a blind user navigating with a screen reader and keyboard cannot access these elements, they cannot use the site.
• Insufficient colour contrast — under WCAG 2.1 AA, normal text generally needs 4.5:1 and large-scale text 3:1, with stated exceptions. Test rendered foreground and background colours in each relevant state.
• Missing page structure — pages without proper heading hierarchy, landmark regions, or skip navigation links. These structural elements are how screen reader users navigate and understand page layout. Without them, every page is an undifferentiated wall of content.
• Inaccessible video content — videos without captions exclude deaf and hard-of-hearing users. Product demonstration videos and instructional content on ecommerce and service sites are frequently cited.
• Missing link purpose — links with text like "click here," "read more," or "learn more" that do not describe their destination when read out of context. Screen reader users often navigate by listing all links on a page, and generic link text is meaningless in that context.

Audit Process

An ADA compliance audit follows a structured process that combines automated testing, manual testing, and assistive technology evaluation. Here is the process we recommend and follow in our own audits.

Step 1: Define scope. List pages, states, components, documents, third-party content and complete processes, including authenticated and error paths where applicable. A representative template sample can identify recurring defects; do not use it to claim whole-site conformance for untested pages and processes.

Step 2: Run automated rules. Use axe, WAVE or Lighthouse on the sampled states and validate each alert. Automated tools cover only machine-testable patterns and cannot establish conformance.

Step 3: Perform keyboard testing. Navigate each page, state and complete process in scope using the keyboard. Test the keys defined by native behaviour or the component's interaction pattern and document elements that cannot be reached, operated or exited.

Step 4: Test with screen readers. Use the browser and screen-reader combinations named in scope. Verify reading order, names, roles, values, headings, alternatives, instructions, errors and dynamic status messages through complete tasks.

Step 5: Check visual criteria. Test colour contrast on all text elements. Verify that information is not conveyed by colour alone. Test zoom to 200% and 400%. Verify that focus indicators are visible. Check that animations can be paused and that no content flashes more than three times per second.

Step 6: Document and prioritise. Compile all findings into a structured report. For each issue, record the affected page and element, the WCAG success criterion violated, the severity (critical, serious, moderate, minor), a description of the user impact, and a specific remediation recommendation. Prioritise by severity and user impact.

Remediation Priority

Prioritise from blocked tasks, affected users and pages, frequency, workarounds, technical dependencies and any legal advice. Example operational categories are:

Critical priority: Issues that completely block a core task or create a serious safety or privacy risk, such as a keyboard trap or an unusable payment flow. Escalate these through the product's incident or urgent-fix process.

High priority: Issues that seriously impair an important task, affect a shared component or occur across many pages. Agree an owner and deadline from the service risk and release process.

Medium priority: Issues that cause avoidable effort or confusion but have a usable workaround. Record the affected scope and schedule the fix with related component work.

Advisory: Improvements outside the claimed level or findings whose applicability is uncertain. Keep these separate from confirmed conformance failures.

Validate a fix against the original steps and affected complete process. Publish only remediation dates the organisation can support, and do not present a temporary workaround as conformance.

Ongoing Compliance

ADA compliance is not a project with an end date. Every content update, design change, code deployment, and third-party integration can introduce new accessibility barriers. Without ongoing processes, a site that passes an audit today can fail one three months from now.

Publish accurate accessibility information: Name the scope and standard actually assessed, known limitations, available accommodations and a monitored contact route. Date the statement and avoid unsupported conformance claims.

Train your team: Content editors, designers, and developers all contribute to accessibility. Content editors need to know how to write alt text and structure headings. Designers need to understand colour contrast requirements and touch target sizes. Developers need to implement keyboard accessibility, ARIA attributes, and semantic HTML correctly. Provide role-specific training and include accessibility criteria in your QA checklists.

Integrate testing into development: Run automated accessibility scans in your CI/CD pipeline to catch regressions before they reach production. Include keyboard and screen reader testing in your QA process for every new feature and template. Add accessibility acceptance criteria to your user stories and ticket definitions.

Monitor continuously: Use automated scanning tools to monitor your site on a regular schedule. Set up alerts for new issues. Review third-party widgets and embedded content for accessibility — your site is only as accessible as its least accessible component.

Re-evaluate on a risk-based schedule: Use release frequency, component change, user reports and contractual requirements to set the interval. State whether each review is a sample, regression test or full conformance evaluation.

Budget ongoing accessibility work from component count, release frequency, testing depth and remediation effort. Compare quotes on the same scope rather than relying on a generic annual-cost claim.

Read the DOJ's Title II web rule fact sheet and W3C's WCAG 2.2 Recommendation. Use our accessibility checklist for technical evidence and qualified counsel for a legal conclusion.