An ADA compliance checker is an automated tool that scans your website’s code for detectable WCAG 2.1 violations, including missing alt text, contrast failures, unlabeled form inputs, and structural errors. These tools catch roughly 30 to 40 percent of total accessibility issues. The remaining failures require manual testing with screen readers and keyboard navigation. Used correctly, a checker is the right starting point, not the finish line.
The scan runs in under a minute. The score comes back at 94. Green bar, low issue count, a tidy summary of flagged items you can pass to your developer before lunch.
It feels like progress. Sometimes it even is.
But here is the problem with stopping there: a 94 on an automated scan does not mean 94 percent of your accessibility issues have been resolved. It means 94 percent of the issues that automated tools are capable of detecting were not found. Those are completely different things. The issues that remain, the ones outside the scanner’s detection range, are exactly the ones that generate demand letters and show up in federal complaints.
Using an ada compliance checker correctly means understanding what the tool is actually measuring, where its coverage ends, and how to combine it with the other inputs that produce a genuinely defensible compliance posture. That’s what this article covers, along with a practical ADA compliance website checklist you can run against your own site today.
What an ADA Compliance Checker Actually Measures
An ADA compliance checker is a static or dynamic analysis tool that reads your website’s HTML, CSS, and JavaScript output and compares it against a ruleset derived from WCAG 2.1 success criteria.
The word “automated” does a lot of work here. These tools are fast, consistent, and repeatable. They don’t have bad days. They don’t miss the same issue twice in a row. For the class of issues they can reliably detect, they are genuinely useful. The limitation is that their detection class covers only a fraction of what WCAG 2.1 Level AA actually requires.
The most widely used engines underlying most commercial checkers are Axe-core, developed by Deque Systems, and WAVE, developed by WebAIM at Utah State University. Both are open-source rule libraries that power dozens of commercial products. Chrome’s built-in Lighthouse accessibility audit runs on Axe-core. The accessibility panel in browser developer tools typically runs on similar rule engines.
What the Axe-core and WAVE Rule Engines Can Detect
These tools check for issues where the presence or absence of a code element is objectively determinable:
- Images with missing or empty alt attributes
- Form inputs without a programmatically associated label element
- Page elements without a valid language attribute
- Text and background color combinations that fall below WCAG contrast thresholds
- Interactive elements with no accessible name
- Duplicate ID attributes in the DOM
- Missing or broken skip navigation links
- iFrames without descriptive title attributes
- Heading tags used in the wrong hierarchical order
- Buttons or links with no discernible text
These are real failures. Fixing them reduces legal risk and improves actual usability for people using assistive technology. None of that is trivial.
The issue is what the rule engines cannot evaluate.
What No Automated Checker Can Evaluate
This is the part of the documentation that most vendors bury.
Automated tools cannot determine whether an image’s alt text is actually meaningful in context. They can confirm that an alt attribute exists and contains characters. They cannot tell you whether “image001.jpg” or “photo” or “decorative floral element” actually serves the user who cannot see the image. That requires a human to read the alt text and judge whether it conveys the same information the image conveys to a sighted user.
Automated tools cannot evaluate keyboard navigation flow. They can check whether interactive elements are focusable. They cannot follow a Tab sequence through your site, observe whether the focus order makes logical sense relative to the visual layout, and determine whether a keyboard user can complete your checkout flow without getting trapped or losing their place.
Automated tools cannot test dynamic content behavior. A modal that opens on button click, a live chat widget that expands, a date picker that renders a calendar: these introduce interaction states that a scanner evaluating static HTML will never reach. The ARIA implementation inside these components, which determines whether screen readers like JAWS and NVDA announce them correctly, cannot be verified without executing the interaction.
And this is where it gets interesting. Some of the most common failures in ADA litigation fall entirely outside automated detection. Keyboard traps, illogical focus order, modals that don’t receive focus when opened, form error messages that aren’t programmatically associated with the fields they describe: none of these will show up on a scan report. All of them are the kind of barrier that makes a real user with a disability unable to complete a task on your site.
How to Use a Compliance Checker Correctly
None of the above means you shouldn’t use a checker. It means you should use it for what it’s actually good at, and not mistake a scan score for a compliance status.
Here is the correct mental model: an ADA compliance checker is a diagnostic baseline tool, not a certification instrument. Run it first, fix what it finds, and then move to manual testing armed with a cleaner codebase and a shorter list of remaining unknowns.
That sequence produces better outcomes than either extreme: ignoring automation entirely (slow and expensive) or treating automation as sufficient (fast and legally dangerous).
Running a Checker Effectively
Most checkers let you scan a single URL. A single URL is not your site. Run the tool against a representative sample of page types:
- Your homepage
- A core service or product page
- A blog post or article page
- A contact or inquiry form
- Your checkout or signup flow
- Any page with a modal, accordion, or dynamic component
- Any page that embeds a third-party widget (live chat, booking tool, video player)
Each page type will have a different issue profile. A homepage might pass cleanly while a checkout form has five critical label failures. Scanning only the homepage and declaring the site compliant is like inspecting only the lobby of a building and certifying the whole structure.
Interpreting the Results Without Overreading Them
Checker results come in severity tiers. Critical issues are WCAG failures with high confidence and high user impact. Serious issues are likely failures that may require human review to confirm. Moderate and minor issues are lower-confidence flags or lower-impact criteria.
A result of zero critical issues is meaningful. It means the most reliably detectable, high-impact failures are not present in the scanned pages. It does not mean your site is WCAG conformant. It means your automated baseline is clean.
That sounds like a small distinction. Legally, it is not. An organization that can demonstrate a clean automated baseline, combined with documented manual testing and a remediation history, is in a substantially stronger position than one that can produce only a scan score.
The ADA Compliance Website Checklist: What to Verify Manually
After your automated scan, this is the manual checklist that covers what the tool cannot reach. Work through it section by section.
Keyboard Navigation Checklist
Tab through every interactive element on the page. Confirm:
- Every link, button, form field, and widget receives visible focus when tabbed to
- The tab order follows the visual reading order of the page
- No element creates a keyboard trap (focus enters and cannot leave)
- Modal dialogs receive focus when they open and return focus to the trigger when they close
- Dropdown menus can be opened, navigated, and closed using keyboard alone
- Custom date pickers, sliders, and carousels respond to arrow key navigation as expected
If any of those steps fails, you have a WCAG 2.1 Level A or AA keyboard failure that no automated checker flagged.
Screen Reader Checklist
Open NVDA or VoiceOver and navigate your site listening only to the audio output. Confirm:
- Page titles announce correctly when the page loads
- Heading structure creates a logical outline when navigating by heading
- Images announce meaningful descriptions, not file names or empty silence
- Form labels announce correctly when each input receives focus
- Error messages announce when form validation fails, associated with the field that caused the error
- Modal dialogs announce their purpose and dismiss correctly
- Dynamic content changes (cart updates, filter results, live search) announce without requiring navigation
Color and Visual Checklist
Use a color contrast analyzer tool (the TPGi Colour Contrast Analyser is widely used) to spot-check:
- Body text against its background (minimum ratio 4.5:1)
- Large text (18pt or 14pt bold and above) against its background (minimum ratio 3:1)
- UI components and focus indicators against adjacent colors (minimum ratio 3:1 under WCAG 2.1)
- Any information conveyed through color alone, such as required field indicators, error states, or status tags, that needs a non-color alternative
Document and Media Checklist
- PDFs linked from any page are tagged for accessibility and have a logical reading order
- All video content has accurate closed captions
- Audio-only content has a full text transcript available
- Auto-playing media can be paused, stopped, or muted by the user
Structure and Code Checklist
- Every page has a unique, descriptive title element
- The HTML element has a valid lang attribute
- Skip navigation link is present and functional as the first focusable element
- Landmark regions (header, nav, main, footer) are present and correctly applied
- No content relies solely on sensory characteristics for identification
What to Do With Checker Results and Checklist Findings
You now have two documents: your automated scan report and your manual checklist findings. Together they represent the most complete picture of your site’s accessibility status that you can build without commissioning a full professional audit.
The next step depends on what you found.
If both the scan and the checklist came back largely clean, you are in a reasonable position for a small site with limited traffic and lower litigation exposure. Schedule a professional audit to verify, but your immediate risk is lower than most.
If the checklist surfaced keyboard navigation failures, screen reader announcement errors, or missing captions on video content, those are your first remediation priorities regardless of what the scan score says. These are the failures that make your site unusable for real people with disabilities and that generate the demand letters.
If the scan flagged more than 20 critical issues on a single page template, that template is likely used across many pages. Fix it at the component or template level, not page by page.
And if you are operating in a regulated industry, running healthcare services, financial products, legal services, or government-funded programs, the standard you are held to is stricter and the exposure of non-conformance is higher. A checker and a self-administered checklist are starting points in those contexts. A professional WCAG audit with documented evidence is the minimum defensible posture.
Frequently Asked Questions
Q: What is an ADA compliance checker?
A: An ADA compliance checker is an automated tool that scans a website’s HTML, CSS, and JavaScript output against a ruleset derived from WCAG 2.1 success criteria. It identifies machine-detectable accessibility failures including missing alt text, contrast violations, unlabeled form inputs, and structural errors.
Q: How accurate are ADA compliance checkers?
A: Automated checkers reliably detect roughly 30 to 40 percent of WCAG 2.1 Level AA failures. The remaining issues, including keyboard navigation failures, screen reader interaction problems, and dynamic content behavior, require manual testing with assistive technology to evaluate.
Q: What is the difference between an ADA compliance checker and a full accessibility audit?
A: A checker runs automated rules against your code and returns a machine-generated issue list. A full accessibility audit adds human expert testing using screen readers, keyboard navigation, and manual WCAG evaluation, covering the criteria that automation cannot reach and producing a legally documented conformance report.
Q: Can I use a free ADA compliance checker for legal protection?
A: A checker result alone does not constitute legal protection. Courts expect documented WCAG conformance supported by human testing evidence, not a scan score. A checker is the correct first step in the process, but the process does not end there.
Q: What should an ADA compliance website checklist cover?
A: A complete manual checklist covers keyboard navigation across all interactive elements, screen reader testing for page structure and form behavior, color contrast spot-checks using a contrast analyzer, document and media accessibility including PDF tagging and video captions, and HTML structure including page titles, language attributes, and landmark regions.
Q: Which pages should I scan with an ADA compliance checker?
A: Scan a representative sample of every distinct page type on your site: homepage, service or product pages, blog or article templates, contact and inquiry forms, checkout or signup flows, and any page containing dynamic components such as modals, accordions, or embedded third-party widgets. Scanning only the homepage gives an incomplete and often misleading picture of your site’s overall accessibility status.
