Free website accessibility checkers compared: WAVE, axe, Lighthouse, Pa11y and more
Updated October 26, 2026 · 12 min read
Short answer. WAVE is the friendliest visual checker, axe DevTools and Lighthouse suit people comfortable with browser developer tools, Pa11y suits automation, and Accessibility Insights adds guided manual tests. All of them find only the issues automation can detect, so pair any of them with hand testing.
At a glance
| Tool | Made by | How you use it | Best for | Limits |
|---|---|---|---|---|
| WAVE | WebAIM | Web page or browser extension; draws icons on the page next to each issue. | Non-developers who want to see issues in place. | One page at a time; cluttered on busy pages. |
| axe DevTools | Deque Systems | Browser extension; the free version is built on the open-source axe-core engine. | Developers who want a clean list of WCAG-mapped issues. | Single page at a time in the free version; advanced features are paid. |
| Lighthouse | Built into Chrome DevTools; gives a score out of 100. | Quick checks alongside performance and SEO audits. | Runs a subset of axe rules, and a score of 100 does not mean a page is accessible. | |
| Pa11y | Open source | Command line; can run in a build pipeline. | Developers adding checks to automated tests. | Needs technical setup; one page per run unless scripted. |
| Accessibility Insights for Web | Microsoft | Browser extension with automated checks plus guided manual assessments. | Teams who want to learn manual testing. | More time-consuming; aimed at people who test regularly. |
| Clir free scan | Clir | Paste one URL; no signup. Shows detected issues on that page. | Business owners who want a plain-language first look. | One page; the full report with evidence, a Fix Pack and rechecks is the $99 One Page assessment. |
How to choose
- You own a business site and want a first look: WAVE or the Clir free scan. Both explain results without developer knowledge.
- You are a developer fixing a site: axe DevTools or Lighthouse in the browser, and Pa11y if you want automation.
- You want to learn how professionals test: Accessibility Insights.
- You manage many client sites: a single-page tool gets slow; see accessibility QA for agencies.
Why results differ between tools
Different tools run different rules and scan the page at different moments, so two scanners can report different counts on the same page. Some count one problem once and others count every affected element, so compare which issues were found, not the totals. Lighthouse and many extensions use axe-core under the hood; others use their own rules.
Three kinds of free tool
Free accessibility tools fall into three groups, and knowing which kind you are using explains most of the differences in what they report.
- Browser extensions such as axe DevTools, WAVE and Accessibility Insights run on the page you are looking at, including pages behind a login. They are good for developers and for testing logged-in or unpublished pages.
- Built-in browser tools such as the Lighthouse panel in Chrome DevTools give a quick score and a short list of issues. They are convenient, but they check only a subset of rules.
- Web-based scanners take a web address and report on the public page. They need no installation and are the easiest starting point for a business owner.
How to read a score
Some tools produce a score out of 100. A score is a summary of how many of the tested rules passed, and it can be misleading in both directions. A page can score 100 and still be unusable because the score only counts what the tool tested. A page can score 70 because of one problem repeated many times. Use the list of issues, not the number, to decide what to do.
If you compare tools, compare the same page and the same state. A page with a popup open, a cookie banner showing or a logged-in account will produce different results from a clean load.
A simple way to use two tools together
- Run a web-based scanner on your main page types and note the issues it reports.
- Run a browser extension on the same pages and compare. Where they agree, treat the issue as real. Where they differ, look at the element yourself.
- Add a manual keyboard and zoom test, because none of the automated tools can check them fully.
- Fix the issues that appear in both, then recheck.
Questions to ask before you trust a tool
- Does it say which WCAG version and level it tests against?
- Does it list each issue with the element, the criterion and a suggested fix?
- Does it say what it cannot check?
- Does it work on more than one page, or only the page you typed in?
- Is it clear who made it and how it is paid for?
- Does it avoid promising that a passing result means a site is accessible or legally safe?
A tool that answers these questions plainly is easier to rely on than one that leads with a large badge or a promise.
Choosing the right level of testing
| Your situation | Free tools are probably enough | Consider more |
|---|---|---|
| A new small site you are building | Yes, as part of regular checks | A manual review before launch |
| An online store taking payments | As a first pass | Manual checkout testing, and a review by a specialist if you can |
| A site that has received a legal letter | As a starting point only | A lawyer and a manual audit, as described in the demand letter guide |
| A government site subject to Title II | For routine monitoring | Documented manual testing |
| A product sold to large buyers | For routine checks | A full conformance evaluation and report |
Common free tools and what each is good for
The tools below are widely used. This is a description of how they are typically used, not a ranking, and each has strengths. Check the current features on each tool's own site, since they change.
| Tool | Type | Typically good for | Worth knowing |
|---|---|---|---|
| axe DevTools (free extension) | Browser extension | Developers testing a page they are building | Built on the open-source axe-core engine, which many other tools also use |
| WAVE | Extension and web service | Seeing issues marked on the page itself | Visual overlays make it good for learning and for showing others |
| Lighthouse | Built into Chrome DevTools | A quick check as part of a wider performance review | Tests a limited set of accessibility rules and gives a score |
| Accessibility Insights for Web | Browser extension | Guided manual testing in addition to automated checks | Includes a step-by-step assessment that walks you through manual checks |
| Pa11y | Command line tool | Automated checks in a build process | Needs some technical knowledge to set up |
| Web-based business scanners | Web service | Non-technical owners who want a readable report | Usually limited to public pages, and capabilities vary by provider |
Limits that apply to all of them
- They test a page as it looks at one moment. Pages that change after a click or a delay need a human to open the menu or trigger the popup.
- They cannot judge whether text is clear, whether alternative text is accurate or whether a sequence makes sense.
- They produce suggestions, not decisions. Someone has to decide what to do.
- They do not replace testing with real assistive technology and, ideally, real people.
How to explain scanner results to a developer
Developers can fix problems faster when the report is specific. Send the page address, the issue name, the element or its selector, the WCAG criterion and the suggested fix. Attach a screenshot if there is one. Avoid sending only a score or a screenshot of a dashboard, because those do not say what to change. Where a tool offers a downloadable report, include it.
Avoiding the trap of chasing a score
When a score becomes the goal, teams sometimes do things that improve the number and not the experience, such as adding labels no one reads or hiding elements the tool dislikes. A better goal is a short list of real tasks that a person can complete with a keyboard and a screen reader, and a score that stays high because the code is sound. Use the tool to find problems, and use people to decide whether they are fixed.
Putting it into practice: a one-week plan
| Day | What to do |
|---|---|
| 1 | Run a free web-based scanner on your main page types. Save the results. |
| 2 | Install one browser extension and run it on the same pages. Compare. |
| 3 | Do the keyboard test and the zoom test. Add findings to the same list. |
| 4 | Sort the list by severity and decide what you can fix yourself. |
| 5 | Fix the quick ones, send the rest to a developer with clear notes. |
| Next week | Rescan and update the list. Decide how often you will repeat this. |
What to expect from a business scanner report
If you use a web-based scanner aimed at business owners, a good report is more than a list of rule names. It should explain each issue in words you can read, show where on the page it occurs, say how serious it is, map it to the relevant WCAG criterion and suggest how to fix it. It should also tell you which things it did not test, because the gaps matter as much as the findings.
Look for a report that explains each finding, names the standard it uses and says what it covered, rather than one that gives a single pass or fail verdict. Legal questions depend on the facts of your business, so the most useful reports give your team evidence to act on.
Choosing by role
| If you are | Start with | Why |
|---|---|---|
| A business owner with no technical background | A web-based scanner with a readable report | You can run it in a minute and share the result with whoever builds your site |
| A developer building a site | axe DevTools or Accessibility Insights, plus automated checks in your build | They show the element and the code, and they catch regressions early |
| A designer | A contrast checker and WAVE | You can check color and structure before anything is built |
| A content editor | A quick scan of each new page, plus a checklist for images and links | Most content problems are alt text, link text and headings |
| An agency managing several client sites | A scanner that can save and compare reports, plus a manual checklist | You need repeatable evidence for each client. See the agency QA workflow |
Frequently confused ideas
- A free scan is not an audit. An audit is a structured evaluation, usually by a specialist, with manual testing and a written report.
- A badge is not evidence. A badge on a website says a vendor wants you to trust a tool. Evidence is a dated report that lists pages tested and problems found.
- A plugin is not a fix. Some plugins add a toolbar or change the page on the fly. They may help a few visitors, but they do not replace repairing the page. See overlays explained.
- Passing is not the same as usable. A page can pass every automated check and still be frustrating for a screen reader user.
Looking at one issue the way a tool would
Take a simple search button that shows only a magnifying glass icon. A scanner checks whether the button has an accessible name. If the button has no text and no label, the tool reports "Buttons must have discernible text". The fix is to add a label, either visible text or a hidden label that a screen reader announces. After the fix, the same tool passes the button, but a person should still check that the label says "Search" and not something like "icon-24".
This small example shows the division of work: the tool finds the missing label, and the person confirms the label is useful.
If you want a readable report for a public page, Clir's free website accessibility checker is one option. It lists the affected elements and suggested fixes and states what it did not test.
What none of them can do
Automated checks cover the detectable issues; a few questions, such as whether alt text is meaningful or a custom widget reads well with a screen reader, are best settled by a quick look. Use the hand-testing steps and see what scanners find best.
Clir's published benchmark compares its confirmed findings with axe-core and HTML_CodeSniffer on public W3C test material, with its method published. The figures describe those published test sets. Read the methods and results on the methodology page.
Common questions
Which free checker should I start with?
There is no single answer, because results depend on the rules each tool runs and the page tested. Use two tools together and treat both as a starting list.
Is a Lighthouse score of 100 enough?
No. Lighthouse itself notes that its score covers only the automated checks it runs.
Is WAVE better than axe?
They are different tools that tend to catch overlapping sets of issues. WAVE is visual and good for learning; axe is built for developers and automated testing. Using both on the same page is common.
Is Lighthouse enough to test accessibility?
Lighthouse runs a subset of axe rules and shows a score. It is useful as a quick check but misses many issues and should not be the only test.
Do free tools work on pages that need a login?
Browser extensions do, since they run on the page you see. Web-based scanners generally cannot reach pages that need a login.
Why does each tool report different issues?
Tools use different rule sets, interpret borderline cases differently and read the page at different moments. See the section above on why results differ.
What is the best free website accessibility checker?
It depends on who is using it. For owners, a web-based scanner with a readable report; for developers, axe DevTools or Accessibility Insights. No single tool is best at everything, and all of them miss issues that need a person.
Is there a free online accessibility checker I can run on any page?
Yes. Web-based scanners accept a page address and return a report, and browser extensions test the page you have open, including pages behind a login. Check the report for the standard it uses and what it left untested.
What are the best free accessibility testing tools?
Common free choices are axe DevTools, WAVE, Lighthouse, Accessibility Insights and Pa11y, alongside free screen readers such as NVDA. A free accessibility testing tools list is only useful if you also test by hand.
What are the best automated accessibility testing tools?
Open-source engines such as axe-core power many tools, and Pa11y and Lighthouse are common in build pipelines. Pick one that fits your workflow and run it on every release.
Does Lighthouse test accessibility well?
Lighthouse runs a subset of axe-core rules and shows a score. It is a convenient check, but a high Lighthouse accessibility score does not mean a page is accessible. Use it with manual tests.
Is there a WAVE alternative or an axe DevTools alternative?
Yes. Accessibility Insights, Pa11y, Lighthouse and several web-based scanners overlap with both. Choose by how you work: in the browser, on the command line or from a report.
Can I use a browser extension as a website accessibility checker?
Yes, and it is one of the most useful ways to test, since it works on the page you are viewing. Extensions from Deque, WebAIM and Microsoft are widely used. Check them on logged-in pages and states a scanner cannot reach.
See what a scan finds on your own site
Run a free scan on one page, no signup. For the full picture, the $99 One Page assessment adds a detailed report, a Fix Pack and two rechecks.
Clir runs automated checks against WCAG 2.2 Level A and AA success criteria. How Clir tests.