ADA compliance checker
Paste the source of one page and read which accessibility checks it fails. It runs in your browser, sends nothing, and says plainly what it cannot see.
Most accessibility checkers are black boxes with a score attached. This one has no score, because a number would be the one thing it cannot honestly produce. It prints the tests that failed, the tests that passed, and the tests that need a person, each against a named criterion of WCAG (Web Content Accessibility Guidelines) 2.2.
It is free, it needs no account, and it works with the network switched off once the page has loaded.
Run it on your own markup
Open the page you want to check, view its source, select all of it and copy. On Windows that is Ctrl+U and then Ctrl+A and Ctrl+C. On a Mac it is Command+Option+U, then Command+A and Command+C.
Results
No check has run yet. Paste a page of markup above and press Check this markup, or press Check this page instead to read the source of this page and check it.
What no markup check can see
Colour contrast, because contrast is a matter of the computed styles, not of the attributes. Reading order and meaning, because a text alternative can exist and still be useless. Focus behaviour in practice, because a trap is created by script and not by markup. Time limits, motion, hover menus, drag interactions and anything assembled by JavaScript after the page loads.
It also cannot see the two halves of the work that matter most: whether the product can be operated by keyboard and screen reader from start to finish, and whether the language is plain enough to be understood. Both need a person in front of the product, and that is what an audit is.
What the checker looks for
Two groups of tests. The first is judged on the spot. The second is reported with a reason and left to a person, because the markup alone cannot settle it.
| Page level | A language on the html element (3.1.1), a page title (2.4.2), and a main landmark or a skip link (2.4.1) |
|---|---|
| Images | Alternative text on images, image maps and image buttons (1.1.1), and inline graphics that are neither named nor hidden (1.1.1) |
| Names | An accessible name on every link (2.4.4), every button (4.1.2) and every form field (3.3.2) |
| Structure | Empty headings (1.3.1), duplicate ids (1.3.1), header cells missing a scope (1.3.1), and tables with no header cells at all (1.3.1) |
| Operation | Positive tabindex values (2.4.3), controls nested inside controls (2.1.1), click handlers on things a keyboard cannot reach (2.1.1), and media with no controls (2.1.1) |
| ARIA and frames | Hidden content that can still take focus (4.1.2), empty ARIA attributes (4.1.2), role values that are not roles (4.1.2) and frames with no title (4.1.2) |
| Alternative text quality | An alt attribute that describes the file rather than the image (1.1.1) |
|---|---|
| Heading outline | A skipped heading level, and more than one h1 (1.3.1) |
| Link words | The same words pointing at different destinations (2.4.4) |
| Captions | Video with no captions track, which may mean captions are burned into the picture (1.2.2) |
| Focus on load | An element that takes the focus as the page arrives (3.2.1) |
| Zoom | A viewport tag that switches pinch zoom off (1.4.4) |
| Focus outline | outline:none in a style attribute or a style block, which may or may not have a replacement further down the file (2.4.7) |
Where a checker stops
Automated accessibility testing earns its place as a floor, not a ceiling. It is fast, it is repeatable, and it catches code faults before a person wastes an hour finding them. Teams that run it weekly close more issues than teams that run an audit once, because the checks that fail on a Tuesday get fixed on a Tuesday.
What it cannot do is judge. A button can carry a name that says nothing useful. A table can be marked up perfectly and still be the wrong way to present the information. A form can pass every label test and still be impossible to finish after a validation error, because the error text is inserted somewhere a screen reader never reads. None of that is visible in the source.
So we use tools first and by hand afterwards, in that order, on every engagement. The how we test page sets out the passes we run with NVDA (NonVisual Desktop Access), JAWS, VoiceOver and TalkBack, and why manual testing is the core rather than the extra.
There is a second reason to avoid a score. A number invites a target: a team aims at 90 per cent, reaches it, and stops, while the barrier that stops a screen reader user from paying their bill sits in the part of the product nobody scored. Findings with criteria attached are harder to game than a percentage, and they travel into a backlog intact.
From these findings to an ADA compliance audit
An ADA (Americans with Disabilities Act) compliance audit is what happens when the same criteria are tested properly. The scope is written down: which pages, which flows, which apps, which documents, at which text sizes and viewports. Then every one of them is tested by hand, with the assistive technology your users actually have.
That means a keyboard pass with no mouse in reach, a screen reader pass on the current versions of NVDA and JAWS on Windows and VoiceOver on Apple platforms, a test on a real iPhone and a real Android device, magnification at 200 and 400 per cent, and voice control. Findings are confirmed on more than one combination before they go in the report, because an issue that only occurs in one browser is a different problem from a universal one.
The report is the deliverable teams underestimate. Ours names each barrier, its severity, the WCAG 2.2 success criterion, the steps to reproduce it, and the fix. Steps to reproduce are what let your developer see the problem rather than trust ours, and the fix is what keeps the finding from being re-triaged for three sprints. The format is set out in full on the sample report page.
What the audit adds that no checker can
- Real assistive technology. A name that reads correctly in the source can announce as gibberish, and only listening to it proves which one you have.
- Operable flows. A task run from the first screen to the last, with the barriers that only appear in sequence, such as focus escaping to a background page behind a modal.
- Documents and apps. Tagged PDFs, spreadsheets, forms and native apps, none of which can be judged from a web page check.
- Colour and contrast. Computed contrast, measured on the real backgrounds rather than the declared ones, including text over images and focus indicators.
- Third party components. The chat widget, the payment frame and the consent banner, tested where they sit rather than where the vendor claims.
- Severity and order. Which findings block a task, which cause an error, and which are friction, so the work can be scheduled instead of argued about.
- A retest. The same cases run again after the fixes, with the result in writing.
If you sell to public sector buyers in the United States or the European Union, the same testing feeds a VPAT (Voluntary Product Accessibility Template) and an ACR (Accessibility Conformance Report), which are covered on the VPAT and ACR page.
How to use the checker in the meantime
Run it on the page you consider least likely to have a problem. Then run it on your checkout, your account screen, your search results and your login. The second list is where the work usually is, and the results give you an opening agenda for the free one-page audit rather than a blank page.
Checker questions
Is this an ADA compliance test?
No, and it is worth being exact about that. What runs here is a set of markup tests against WCAG (Web Content Accessibility Guidelines) 2.2 criteria, on one page of source code. ADA compliance is a legal question about your organisation, your users and your jurisdiction, and it belongs to your counsel. What the checker gives you is a list of barriers with a criterion beside each one.
Does the checker send my code anywhere?
No. It runs inside your browser, on the text you paste. There is no upload, no account, no cookie and no analytics, which is why the page works with the network switched off after it loads.
Can it check a web address instead of pasted source?
Not from a browser. A page on another domain cannot be read by a page on this one, by design, and no website can change that. Paste the source, or send us the address and we will test it by hand in the free one-page audit.
Why does a clean result not mean we pass?
Because markup is a fraction of the work. These tests read code. They cannot see colour contrast, whether a heading name means anything, whether the reading order makes sense, or how a screen reader behaves on a custom control. Every one of those needs a person.
Which criteria does it cover?
The tables above name them: page language and page title, alternatives for images, names for links, buttons and fields, frame titles, focus order, nested controls, hidden focusable content, ARIA values, table headers and media controls, all mapped to their WCAG 2.2 success criteria and levels.
What do we do with what it finds?
Each finding carries the criterion, why it matters and how to fix it, so it can go straight into a backlog. Our WCAG 2.2 checklist groups the same work by task, and if you want the rest of the product covered, the audit and testing service is the next step.
Fix what it finds: the WCAG 2.2 checklist · Or have the whole product tested
Test the page that matters
One free page, tested by hand, with the findings written out and a scope for the rest.