ADA Website Accessibility Checker: WCAG 2.1 AA, plain language

Give it your pages, or a site to crawl, and it tests each page against WCAG 2.1 Level A and AA in headless Chrome with axe-core, the open source accessibility rules engine. Every problem found comes with a plain language explanation of what the guideline asks for, a severity rating, the elements affected, and what to change, so you can hand the list to your web team.

This tool runs automated tests. It does not certify that a site meets the ADA, WCAG or any other standard. It does not make a site compliant. It is not legal advice.

Which standard it checks, and why

The Americans with Disabilities Act (ADA) covers state and local governments under Title II and businesses open to the public under Title III [5].

Title II, state and local governments. In April 2024 the US Department of Justice published a rule that adopts the Web Content Accessibility Guidelines (WCAG) version 2.1, Level AA, as the technical standard for the web content and mobile apps of state and local governments [2]. The rule, at 28 CFR 35.200, refers to the Level A and AA success criteria and conformance requirements of WCAG 2.1 [1]. An interim final rule published on 20 April 2026 moved the compliance dates to 26 April 2027 for public entities with a total population of 50,000 or more, and to 26 April 2028 for public entities with a total population under 50,000 and for special district governments [3][4]. In that interim final rule, the Department says it plans further rulemaking on the substance of the 2024 rule [3].

Title III, businesses open to the public. The Department's guidance on web accessibility says it has no regulation setting out detailed web standards, that businesses can choose how they make their online goods and services accessible, and that WCAG and the Section 508 Standards give helpful guidance [5].

This actor tests against WCAG 2.1 Level A and AA, the standard named in the Title II rule. Every finding names the WCAG 2.1 success criterion it relates to.

What automated testing can and cannot find

axe-core 4.13.0 runs 62 rules for WCAG 2.1 Level A and AA. Those rules cover 19 of the 50 success criteria at those levels. The rest need a person: whether alt text describes the image, whether captions match what is said, whether every task on a page can be done with a keyboard.

The axe-core project states that the engine finds on average 57% of WCAG issues automatically [6]. The Department's guidance says a clean report from an automated checker does not by itself mean a site is accessible, and suggests pairing automated checks with a manual check [5]. A page with no problems in this report can still have barriers. Plan a manual review as well.

Input

• Pages or sites (required)
• Crawl the site (default off). Follows links from each start page to pages on the same site, skipping files such as PDF and images.
• Maximum pages per site (default 20) and maximum crawl depth (default 2)
• Exclude URLs: regular expressions for crawled links to skip
• Respect robots.txt (default on). Applies to crawled links. Pages you list are always tested.
• List what needs a person to check (default on)
• Device: desktop (1366 by 900) or mobile (iPhone 13 profile)
• One row per affected element (default off), for a flat CSV or Excel export
• Examples per problem (default 5). The full count is always given.
• HTML report (default on)
• Wait until, wait for selector, extra delay (default 1,000 ms), page timeout (default 30 seconds), pages at once (default 3)

Output

One dataset row per page (type: page):

• url, finalUrl, status, title, standardChecked, device
• summary: one plain sentence, such as "Found 5 problem types affecting 44 elements. Rated critical: 1.1.1 Non-text Content, 4.1.2 Name, Role, Value."
• problemCount, affectedElementCount, highestSeverity
• problems: one entry per WCAG 2.1 success criterion with a problem, most severe first. Each has criterion, criterionName, level, whatItMeans (what the criterion asks for, in plain words), severity, affectedElements, a link to the W3C explanation, and fixes. Each fix has the issue, severity, howToFix, a learnMore link, and examples with the CSS selector and HTML of affected elements.
• needsHumanReview: checks the automated tests could not decide, with the criteria they relate to
• axeVersion, checkedAt

Severity is the impact rating axe-core gives each issue: Critical, Serious, Moderate or Minor.

One summary row per site (type: summary): pages tested, pages with problems, pages not tested, affected elements, the ten most common problems with what they mean, a plain summary sentence, a notice on the limits of automated testing, and the link to the HTML report.

With one row per affected element on, each listed element also gets a row (type: issue) with the page, criterion, severity, issue, selector, HTML and how to fix.

A page that cannot be tested gets ok: false and an error: an address that is not a web address, a host that does not resolve, a page that answers with an HTTP error such as 404, or a file such as a PDF. The run carries on with the next page.

The HTML report is saved as report.html in the run's key value store. It lists the problems for each site and page in plain language and opens in any browser.

Pricing

Pay per event: one event per page tested. Pages that cannot be tested are not charged. The run stops when it reaches the maximum charge you set.

Scope and conduct

Only public pages are opened. The actor does not log in, fill in forms or collect personal data. Each page opens in a fresh browser context with no cookies carried over. No proxies are used. Test sites you are allowed to test.

axe-core 4.13.0 is included unchanged under the Mozilla Public License 2.0 [7], and its license file ships with the actor.

Support

Questions and problems: the Issues tab on this page. Replies are written by an AI assistant on behalf of the developer and reviewed by the developer.

References

[1] Electronic Code of Federal Regulations, 28 CFR 35.200, Requirements for web and mobile accessibility. https://www.ecfr.gov/current/title-28/chapter-I/part-35/subpart-H/section-35.200

[2] Federal Register, 24 April 2024, Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities, 89 FR 31320, section I.D, Overview of Key Provisions of This Final Rule. https://www.federalregister.gov/documents/2024/04/24/2024-07758/nondiscrimination-on-the-basis-of-disability-accessibility-of-web-information-and-services-of-state

[3] Federal Register, 20 April 2026, Extension of Compliance Dates for Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities, 91 FR 20902, Summary, section I (Background and Legal Authority) and section II (Need for This Interim Rule). https://www.federalregister.gov/documents/2026/04/20/2026-07663/extension-of-compliance-dates-for-nondiscrimination-on-the-basis-of-disability-accessibility-of-web

[4] ADA.gov, Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments. https://www.ada.gov/resources/2024-03-08-web-rule/

[5] ADA.gov, Guidance on Web Accessibility and the ADA, sections "When the ADA Requires Web Content to be Accessible" and "How to Make Web Content Accessible to People with Disabilities". https://www.ada.gov/resources/web-guidance/

[6] axe-core README, opening section. https://github.com/dequelabs/axe-core

[7] axe-core LICENSE (Mozilla Public License 2.0). https://github.com/dequelabs/axe-core/blob/develop/LICENSE