Accessibility testing tools in 2026: axe-core vs Pa11y vs Lighthouse vs WebAIM WAVE vs Accessibility Insights

Accessibility problems can enter a release through a missing control label, an unreachable dialog, or an interaction that only works with a pointer. Automated tools help expose repeatable issues early, but choosing one requires understanding what it actually checks and how a person reviews the remaining experience.

axe-core, Pa11y, Lighthouse, WAVE, and Accessibility Insights serve different parts of that workflow. This comparison uses official repositories and documentation reviewed on October 21, 2026. It is a tool-selection guide, not an accessibility audit of your website or a claim that a passing score establishes complete accessibility.

Compare workflows as well as engines

An engine evaluates rules, a runner loads pages and records results, and a guided interface helps a person investigate. Several tools can use the same underlying engine. Running them all may therefore reproduce the same checks rather than add independent coverage. Specify the rules, page states, and human review steps before counting tools.

Accessibility checking also differs from general browser automation. Our browser testing framework comparison explains how teams drive application behavior. Accessibility checks can run within those journeys, but a successful click does not show that a keyboard or screen-reader user can understand the same task.

The quick difference

Product	Best fit	Primary workflow	Main limitation
axe-core	Developers integrating rule checks into tests	JavaScript accessibility engine	Incomplete results and uncovered behavior need human review
Pa11y	Scriptable URL and CI checks	Command-line runner with configurable engines	Engine choice and application state affect results
Lighthouse	Quick checks within broader web-quality reviews	DevTools, CLI, or Node reports	Its score excludes manual checks
WebAIM WAVE	Visual investigation by developers and content teams	Page annotations, extensions, and paid APIs	Single-page evaluation and bulk services have different scope
Accessibility Insights	Guided automated and manual web assessment	FastPass, keyboard assistance, and structured assessment	People must complete and interpret manual requirements

axe-core

axe-core is an accessibility testing engine for websites and HTML interfaces. Its repository describes rules associated with several WCAG versions and levels, alongside best-practice checks. Developers can integrate the engine into a test environment and evaluate the application after preparing the relevant page or component state.

Strength: rule checks can become part of the same development cycle that already verifies application behavior. Limitation: an automated engine does not establish that every user task is usable. Results marked incomplete need investigation, and behavior outside the inspected state remains outside that run’s evidence.

The engine is open source under MPL-2.0; paid Deque products and guided services are separate offerings. There is no hosted per-page subscription inherent in using the engine locally, but browser execution, maintenance, and any commercial wrapper have costs. Choose it when your team can own integration and turn findings into actionable development work rather than expecting a complete managed reporting system from a library alone.

Pa11y

Pa11y provides free, open-source accessibility tooling, including a command-line interface, a CI-oriented tool, a dashboard, and a web service. The core runner loads a page and reports findings, which is useful for teams wanting repeatable checks without first designing their own browser harness.

Strength: URL-based checks and configurable output can fit existing scripts and build systems. Limitation: a URL alone may not describe the state a user needs checked. Authentication, consent banners, expanded controls, and validation errors may require deliberate setup before the engine sees the intended interface.

The repository documentation identifies HTML_CodeSniffer as the default runner and supports axe as an alternative or alongside it. Record that choice when comparing results. A different runner can produce different findings without proving that the application changed. There is no required vendor-hosted plan for local execution; a dashboard or CI deployment still needs infrastructure, version updates, and someone responsible for interpreting failures.

Lighthouse

Lighthouse is an open-source web-quality tool available through Chrome DevTools, the command line, or a Node module. Accessibility sits alongside performance and other audits, making it useful when developers want a quick report within a broader page review rather than a separate specialist workflow.

Strength: the browser-based entry point lowers the effort required to begin investigating a page. Individual failed audits link to explanations, which can help developers understand a concrete issue. Limitation: the summary number is easy to overinterpret, especially when presented without page state, tool version, or manual review.

The accessibility scoring documentation explains weighted, pass-or-fail automated audits and states that manual audits do not contribute to the score. A high score therefore describes that automated subset, not every accessibility requirement. Local use has no mandatory subscription; the cost of CI runners, stored reports, and any external monitoring service is separate from the open-source tool.

WebAIM WAVE

WAVE emphasizes visual evaluation, presenting accessibility information in the context of the page. Its online tool and browser extensions can help developers and content teams connect a finding with the element or structure it concerns, while still supporting human evaluation rather than presenting a score as a complete answer.

Strength: contextual annotations can make issues easier to discuss with people who do not maintain a test suite. Limitation: reviewing one page state is different from systematically covering a site or an authenticated journey. Establish whether the job needs an extension, remote API, or separately licensed installable engine.

The extension documentation says evaluation runs within the browser without sending page information to the WAVE server, making that mode relevant for non-public pages. The remote API uses purchased credits: basic analysis consumes one credit, while advanced options can consume two or three. The page lists a $10 minimum purchase for 250 credits and volume tiers; confirm currency and selected analysis scope. Those terms are separate from using the browser extension.

Accessibility Insights

Accessibility Insights provides web and Windows tools; this comparison concerns the web extension for Chrome and Microsoft Edge. Its FastPass workflow combines automated checks with assistance for reviewing keyboard tab stops. Its structured Assessment goes further by organizing automated, assisted, and manual requirements.

Strength: the guided process helps a reviewer continue beyond the initial automated findings. Limitation: instructions and visual helpers do not complete human judgments automatically. A team still needs the skills and time to inspect interactions, record results, and resolve ambiguous findings.

The overview retains WCAG 2.1 AA wording, while the current Assessment guide describes WCAG 2.2 AA and 24 tests. Confirm the installed extension and requirement set rather than assuming the two pages describe identical coverage. The project is open source and does not present a mandatory paid seat plan for these checks; the main evaluation cost is trained review effort and maintaining an accurate assessment record.

How to choose

Use axe-core when you need an engine inside developer-owned tests, Pa11y when you want scriptable page execution, and Lighthouse for a convenient first look during broader web-quality work. Evaluate WAVE when visual investigation and content review are central. Choose Accessibility Insights for consideration when a guided process is needed to connect automatic findings with assisted and manual inspection.

Build the comparison around representative tasks rather than a homepage alone. A proposed evaluation could cover opening a navigation menu, completing a form with errors, moving through a dialog, and reading changing status messages. Record the state inspected, the rules enabled, and which requirements remain unreviewed. We have not performed that evaluation on your application.

Keep overlapping engines visible in your evidence. Agreement between several tools using related rules should not be reported as independent proof of complete coverage. Conversely, different issue counts may reflect configuration, engine versions, or duplicate handling rather than a meaningful improvement or regression.

Specify browser, engine version, rule set, and authenticated page states.
Keep automated failures separate from incomplete and manual findings.
Include keyboard and assistive-technology review appropriate to the task.
Budget for triage and remediation, not only scan execution.

Conclusion

The strongest workflow combines repeatable checks with people who can evaluate the experience those checks cannot fully judge. Select the engine, runner, or guided interface that fits the team’s work, and describe results within their actual scope. These five tools support better accessibility work; none turns an isolated automated pass into a complete assessment of every user journey.

References

Official product, documentation, and pricing sources reviewed on October 21, 2026. Plan details can change; confirm the applicable edition, billing term, and currency before purchase.