At a glance
| Tool | Made by | License or price | How it runs | What decides |
|---|---|---|---|---|
| axe-core | Deque Systems | Open source, MPL-2.0 | A JavaScript library that runs inside the page, called from tests, browser extensions and other tools | Its own rules for WCAG 2.0, 2.1 and 2.2, levels A to AAA, and best practices |
| Lighthouse | Open source, Apache-2.0 | Chrome DevTools, the command line, a Node module, PageSpeed Insights | axe-core, for its accessibility audits | |
| Pa11y | The Pa11y open-source project | Open source, LGPL-3.0 | The command line or Node.js, in headless Chrome; Pa11y CI for lists of URLs and sitemaps | HTML_CodeSniffer by default, or axe-core |
| WAVE | WebAIM, at Utah State University | © WebAIM, under its terms of use; the API is paid per credit, with 100 free credits for new accounts | wave.webaim.org, extensions for Chrome, Firefox and Edge, a subscription API, and a stand-alone API and engine for CI | Its own testing logic, shown as icons in the page for a person to review |
| Rampa | Guilherme Santiago | Open source, MIT; model calls cost what your provider charges, or nothing on a local model | The command line, CI, Playwright tests and coding agents over MCP, with Node.js and Chrome or Edge | axe-core first, then a language model on nine WCAG criteria, with every claim verified against the page |
What each one says about the rest
On one point the five agree: passing an automated check does not make a page accessible.
Additionally, axe-core will return elements as "incomplete" where axe-core could not be certain, and manual review is needed.
Automatic detection can only detect a subset of issues and does not guarantee the accessibility of your web app, so manual testing is also encouraged.
Automated accessibility checks complement manual testing and testing with assistive technologies. Passing these checks does not guarantee that your site is accessible or complies with accessibility standards.
WAVE cannot tell you if your web content is accessible. Only a human can determine true accessibility.
Rampa never says a page is accessible. It reports what was checked and what was not. No automated tool replaces a manual audit or testing with disabled people.
The tools, one by one
axe-core
axe-core is “an accessibility testing engine for websites and other HTML-based user interfaces”, open source and maintained by Deque Systems. It has rules for WCAG 2.0, 2.1 and 2.2 at levels A, AA and AAA, and best practices such as a page having an h1.
Its README says it finds “on average 57% of WCAG issues automatically” and that it “returns zero false positives (bugs notwithstanding)”. Where it cannot be certain, it returns the element as incomplete, for manual review.
- On 1.1.1, 2.4.2, 2.4.4, 2.4.6, 3.1.1 and 3.1.2
Its rules check what markup can prove: that an image has a text alternative (
image-alt), a page a title (document-title), a link a name (link-name), and thatlangis present and valid (html-has-lang,html-lang-valid,valid-lang). No rule is mapped to 2.4.6, and none reads what the text says:alt="img-1"passes.- With Rampa
Rampa runs axe-core 4.14.0 in the page, with the WCAG 2.0 and 2.1 A and AA tags, and reports its violations as they are. The model only sees what those rules passed or do not cover.
Lighthouse
Lighthouse is “an open-source, automated tool to help you improve the quality of web pages”, with audits for performance, accessibility, SEO and more. It runs in Chrome DevTools, from the command line, as a Node module and on PageSpeed Insights.
Its accessibility audits run axe-core inside the page, with the wcag2a and wcag2aa tags and a list of rules switched on or off in its source. The score “is a weighted average of all accessibility audits”, weighted by axe’s user impact, and each audit is pass or fail; manual audits do not count toward it.
- On 1.1.1, 2.4.2, 2.4.4, 2.4.6, 3.1.1 and 3.1.2
The audits that touch these criteria are axe-core’s presence checks, such as “Document has a <title> element”, “Image elements have [alt] attributes”, “Links have a discernible name” and “<html> element has a [lang] attribute”. A score of 100 means every scored audit passed; those audits check that a title, an alt or a link name exists, not what it says.
- With Rampa
Running Lighthouse already runs the engine Rampa starts with. Rampa adds, for nine criteria, the questions those audits do not ask.
Pa11y
Pa11y “runs accessibility tests on your pages via the command line or Node.js”, in headless Chrome through Puppeteer, and can click, type and wait before it tests. Pa11y CI runs it on a list of URLs or a sitemap, in continuous integration.
It has two built-in runners, HTML_CodeSniffer (the default) and axe-core, and can run both in one pass. It tests against WCAG2A, WCAG2AA (the default) or WCAG2AAA, which only HTML_CodeSniffer runs. Results are errors, warnings and notices; warnings and notices are left out of the report by default, because they are “not directly actionable”.
- On 1.1.1, 2.4.2, 2.4.4, 2.4.6, 3.1.1 and 3.1.2
For these criteria, HTML_CodeSniffer, in the version Pa11y uses, raises notices that hand the question to a person: “Check that the title element describes the document.”, “Check that the link text combined with programmatically determined link context identifies the purpose of the link.” and “Check that headings and labels describe topic or purpose.”
- With Rampa
Those notices are the questions Rampa asks a model, one element at a time, with evidence it has to quote from the page. With the axe-core runner, Pa11y and Rampa share the engine.
WAVE
WAVE is “a suite of evaluation tools that helps authors make their web content more accessible to individuals with disabilities”. It marks errors, alerts and features in the page itself, so a person can judge them in context, and it never says a page has passed. The browser extensions run entirely in the browser and send nothing to the WAVE server.
On alt text, its help says it “cannot tell you if your alternative text is equivalent and appropriate, so it instead reveals the alternative text so it can be evaluated by the WAVE user.”
- On 1.1.1, 2.4.2, 2.4.4, 2.4.6, 3.1.1 and 3.1.2
It also checks some words against fixed lists. A page title that is missing or begins with “untitled” is an error. Alt text that is a file name or a word such as “image” or “photo” is a “Suspicious alternative text” alert, and link text such as “click here”, “more” or “read more” is a “Suspicious link text” alert. An alt written for another picture, or “Shipping” over a paragraph about returns, is on no list.
- With Rampa
WAVE and Rampa share the stance that a tool cannot call a page accessible. Rampa asks a model the questions that word lists leave open, and drops any answer whose quote is not on the page.
Where Rampa fits
- It starts with axe-core 4.14.0 and keeps every rule finding as it is.
- For nine criteria, 1.1.1, 1.3.5, 1.4.5 (when asked for), 2.4.2, 2.4.4, 2.4.6, 3.1.1, 3.1.2 and 3.3.2, it asks a model what the rules leave open, one element at a time, with the image as rendered when the criterion needs vision.
- A claim is kept only when the element it cites exists and the text it quotes is in it. Claims that fail are dropped and counted.
- It is measured on the W3C ACT test cases, and the numbers are published with their caveats.
- It can be wrong: the model misses some problems and invents others, and each criterion page shows examples of both.
- It runs where you build, in a terminal or in CI, not on production pages, and it never calls a page accessible.
Running more than one
They can run side by side. Lighthouse and Pa11y with its axe-core runner use the same engine as Rampa, so their rule findings overlap; HTML_CodeSniffer and WAVE have rules of their own.
None of them, Rampa included, covers what only people can check. Audits and testing with disabled people cover the rest.
Every statement about another tool comes from its own documentation or source code, linked under each tool, as read on 8 October 2026. Tools change; check the sources for their current state.