WCAG checker tools: what they find and what they miss

What a WCAG checker can and cannot find

Automated rules work well when a problem is visible in the code itself: an attribute is missing, two colors are too close, an id is duplicated. They struggle when a person has to judge meaning or behavior. Many sources estimate that automated testing finds roughly a third of WCAG issues; the rest need a human.

The accessibility testing guide covers the manual half.

Browser extension checkers

Extensions run inside your own browser, so they test exactly what you see, including pages behind a login and states you open by hand. All of these are free:

• WAVE from WebAIM draws icons on the page next to each problem, which makes it friendly for designers and content editors. It also has a contrast panel and a view with styles turned off.
• axe DevTools adds a tab to the browser developer tools. It is built on the open source axe-core rules engine, focuses on low false positives and groups results by severity. The free version scans the whole page; paid tiers add guided tests.
• Accessibility Insights for Web offers a quick FastPass and a longer guided assessment that walks you through manual checks for each WCAG AA criterion, including a tab-stop visualiser.
• Lighthouse is built into Chrome DevTools. Its accessibility score uses a subset of axe rules. A score of 100 means none of those rules failed, not that the page conforms.

W3C keeps a longer, filterable list of evaluation tools if you need something for a specific language, file type or platform.

Online scanners and site-wide crawlers

An online WCAG scanner asks for a web address and returns a report. Single-page scanners are handy for a quick look at a public page. Crawlers go further: they follow links and test hundreds or thousands of pages, then group repeated issues so you can see that one broken template causes most of the errors.

Limits to keep in mind: a scanner usually cannot log in, fill forms, open menus or wait for content loaded later by scripts, so it tests the first state of each page only. Some single-page apps look almost empty to a crawler. Check what the tool actually saw before trusting a clean result.

Design tool plugins

Several popular design apps support plugins that check contrast, simulate color blindness, measure target sizes and let designers annotate headings, landmarks and focus order before any code exists. Fixing a color or a 16 px icon button in a design file is far cheaper than fixing it across a live site.

A plugin checks the drawing, not the product. It cannot tell whether a developer used a real button element or whether the screen reader hears a label, so test again once the design is built. For color pairs, the contrast checker on this site works with any tool.

Command line and CI tools

Development teams can run the same rules automatically. The axe-core engine has integrations for common test frameworks, and Lighthouse can run on every pull request through its CI tooling. Typical uses:

• Fail a build when a new error appears on a key page.
• Scan each component in isolation inside a component library.
• Keep a log of results over time to spot regressions.

Monitoring platforms

Paid monitoring platforms crawl a site on a schedule, store history, assign issues to people and show trends on a dashboard. They suit large sites where many editors publish every day, because new content brings new problems. What makes them cost more is the number of pages or domains, how often they scan, and extras like PDF checks and user seats.

They are still automated tools with the same blind spots. Pair any platform with periodic manual review, and treat its score as a trend line rather than a verdict. Buying guidance is on the accessibility services page.

ADA compliance website checker: what no tool can tell you

Many people search for a website ADA compliance checker. No such tool can give a real answer. The ADA does not include a technical standard for private business websites; courts and the Department of Justice usually look at WCAG, often 2.1 AA, and at whether disabled people could actually use the site. A tool can report WCAG rule failures. It cannot weigh the manual criteria, judge usability or predict how a court will see your site.

How to check WCAG compliance with a free checker

This routine works with any of the browser extensions above:

1. Pick one page per template: home, a listing, a detail page, a form and a page with media.
2. Open the page, complete any login, and open menus or tabs you want included.
3. Run the extension and note each error with its WCAG criterion number.
4. Check every flagged item by hand; mark false positives so you do not fix them twice.
5. Group errors that come from shared components and fix those first.
6. Run the manual checks a tool cannot do: keyboard, zoom, screen reader.
7. Rescan after fixing and keep the report for your records.

For a structured list of what to test by hand, use the WCAG checklist.

Reading results without panic

A first scan of an older site can show hundreds of errors. Usually a handful of root causes explain most of them: one unlabeled search field in the header repeats on every page, one low-contrast footer color repeats everywhere. Sort by rule, not by page.

Tools also separate certain errors from items that need review, often called alerts, warnings or needs review. Alerts are not failures; they mark places where a person should look. Finally, choose a tool that tests against the version you are targeting. A WCAG 2.2 checker should mention 2.5.8 Target size; tools that do not are still using 2.1 rules. See WCAG 2.2 for what changed.