Skip to main content

Website accessibility checker

A website accessibility checker is software that loads a live page and flags Web Content Accessibility Guidelines (WCAG) failures a machine can detect. Complience.app runs axe-core inside Playwright, then can repeat that check on a schedule. It is evidence of what failed on that crawl, not a certificate that the site is accessible.

What does a website accessibility checker do?

It opens the URL you give it, looks at the rendered HTML, and compares that DOM against a published ruleset. Complience.app uses axe-core for WCAG 2.2 Level A and AA. The output is a list of rule failures with severity, a selector, and a snippet. That is the same class of engine inside Chrome Lighthouse and many developer tools. It is not a visitor toolbar injected onto the site.

How the Complience.app check runs

Playwright starts a clean browser profile and loads the public page. axe-core evaluates the live DOM, including content that only appears after JavaScript. In the same session we record cookies and third-party requests before any Accept click, plus a handful of HTTP security headers. You get one evidence pack: accessibility, cookies, headers.

The public scan form is ungated for a homepage teaser. Sign in for history, a PDF, and a weekly or monthly recrawl. Pro adds a client label and logo on the cover. Plans cap sites, scans per month, and pages per scan. This is not an enterprise crawl of thousands of URLs.

What a WCAG checker catches

  • Images with no alternative text
  • Buttons, links, and inputs without an accessible name
  • Color contrast below the numeric WCAG threshold
  • Empty or duplicate landmarks, missing document language or title
  • Invalid ARIA roles and states the engine can see in the DOM

Those are the failures that show up most often in large automated samples. Public numbers live on our accessibility statistics page (WebAIM Million and lawsuit trackers, not our customer data).

What it still misses

Meaningful alt text, logical reading order, custom widgets, and real assistive-technology use still need a person. Automated tools typically catch a minority of barriers. The report says so on every PDF. If you need the human layer, that is a website accessibility audit, not a second checker URL.

Website accessibility checker vs WAVE and Lighthouse

WAVE is the right tool when a designer is looking at one page in the browser. Lighthouse is already in Chrome and is useful in pull requests. Keep both. Complience.app is the job after that: store the score, recrawl next month, email a drop, and attach cookie evidence WAVE does not collect. A longer comparison is on WAVE vs Complience.app, Lighthouse vs Complience.app, Sigentra vs Complience.app, and AccessibilityChecker.org vs Complience.app. If the CMS is WordPress, use the WordPress accessibility checker for theme and plugin framing. The engine is the same.

Free checker vs overlay widget

A checker reports problems in the source. An overlay injects a script that offers contrast and font controls. Overlays can help some visitors. They do not reliably fix WCAG failures in the HTML, and regulators have challenged “make any website compliant” claims. If that is the pitch you are leaving, read accessiBe alternative. Complience.app does not sell a widget and does not auto-remediate.

ADA, EAA, and the same engine

People who type “ADA compliance checker” want legal cover. The technical path is still WCAG. We run the same axe-core pass and refuse to stamp the site compliant. Use the ADA compliance checker page for that intent, and the EAA checker page if you sell into the EU. One cluster per URL. This page is the website accessibility checker.

Questions

Check a public URL

Homepage teaser. Sign in for PDF, history, and a schedule. The 7-day trial does not require a credit card.