Best Accessibility Testing Tools for Developers

Opening answer

The best accessibility testing tools for developers in CI/CD are the ones that fail a build on a real fault, point at the code behind that fault, and stay quiet on a clean build. A tool that only reports after release is too late, and a tool that blocks every pull request on a minor warning will be switched off within a week. This article compares five tools by pipeline stage: local page check, pull request gate, scheduled site scan and fix delivery. Facts below were last checked on October 31, 2026.

Pick by pipeline stage, not by tool name

A developer pipeline has four stages, and each stage needs a different tool shape. Local development needs a fast page check inside the browser, so a developer sees a fault while the component is open. A pull request needs a gate that runs on a list of pages and reports pass or fail before merge. A scheduled run needs a site wide scan that tracks faults over time, since a single pull request check cannot see a fault introduced by content. Fix delivery needs a diff a reviewer can read, since a report alone still leaves the fix to be written by hand.

Map each tool below to one stage first. If two tools cover the same stage, pick the one your team will actually keep running. A gate that runs on every pull request beats a stronger tool that runs once a quarter.

axe-core: the engine under most of these tools

axe-core is the open source accessibility engine from Deque, and it sits under axe DevTools, Lighthouse accessibility checks and Axeazy scans. That shared engine is useful for a team, because a fault found locally with axe-core will usually be the same fault found later by a CI tool built on axe-core. It also means a team should not count axe-core twice when comparing tools: two tools on the same engine differ in workflow, reporting and gating, not in the core rule set.

Use axe-core directly when your test suite already runs in code and you want accessibility assertions inside existing tests. Use a tool built on axe-core when you want a browser view, a report or a CI gate without writing the test setup yourself. Either way, name the rule and the criterion in the failure message, so a developer who has never read WCAG can still find the fault.

axe DevTools: the local page check

axe DevTools, the free browser extension from Deque, gives page by page automated testing run on axe-core. It is the local stage tool: open a page, run the extension, read the findings with the code location for each one. A developer fixing a component can run it, fix the fault, and rerun it in the same session, which is faster than waiting for a CI run.

Its limit is scope. A page by page tool cannot see a fault that lives in a template across 200 pages, and it cannot gate a pull request on its own. Use it for local work and for checking a fix, and use a CI runner for the gate. When axe DevTools and a CI tool disagree, check the page state first: a fault that appears only after a user interaction, such as opening a menu, may be missed by a static page load and found by a browser test.

pa11y-ci: the open source pull request gate

pa11y is a range of free and open source tools for testing web pages. pa11y-ci, its CI runner, is a command line tool which iterates over a list of web pages and highlights accessibility issues, and its own site describes it as geared towards use in CI. That shape fits a pull request gate: give it a list of URLs, let it run on each one, and read the report before merge.

Set the gate in three decisions, described here in words rather than config. First, choose the page list: homepage, one product or article page, one form page and one search results page cover most template faults. Second, choose the standard to test against, such as WCAG 2.2 AA, so the team tests the same bar on every run. Third, choose the fail rule: fail the build on errors, and report warnings separately, so a new warning does not block a release while a new error does. Start with a short page list and a strict error rule, then add pages once the gate has run clean for two weeks. A gate that blocks on day one for faults the team cannot fix yet will be disabled, so fix the existing errors first or start the gate in report only mode for one sprint.

Lighthouse CI: trends and assertions on every pull request

Lighthouse CI is a suite of tools that make continuously running, saving, retrieving and asserting against Lighthouse results as easy as possible, with a Lighthouse report alongside every pull request. Its strength is history: results are saved and compared over time, so a team can see whether accessibility results improved or slipped after a change, rather than reading a single pass or fail.

Lighthouse accessibility checks are based on axe-core, so its accessibility findings will overlap with axe DevTools findings. The difference is the report shape. Lighthouse CI reports sit next to performance and best practice results, which helps a team that already reviews Lighthouse on every pull request. The risk is score chasing: a team that only watches the accessibility score may miss a fault that the score does not weight heavily, such as a focus order fault that a keyboard user hits on every visit. Read the individual audits, not only the score, and keep a manual keyboard check in the release routine.

Axeazy: from finding to fix as a pull request

Axeazy covers the stage after a CI tool finds a fault: fix delivery. Its methodology page describes how scanning works with axe-core, and it scans with 98 automated checks and fixes code in 14 categories, including alt text, form labels, link names, button names and keyboard tab order. For sites with a GitHub repository, fixes arrive as a real pull request with a visible diff that the owner or developer reviews and merges. That diff is the point for a developer team, since it can be reviewed, commented on and tested like any other change, rather than applied blindly.

Paid plans monitor weekly, so a fault that returns after a content change is caught in the next weekly run. Paid prices are shown at checkout, and annual billing saves 20 to 25 percent. Start with the free scan on the Axeazy homepage, which takes about 60 seconds, is homepage only and needs no signup and no card. Use Axeazy after the CI gate, not instead of it: the gate stops a new fault from merging, and the pull request workflow fixes faults already live on the site. A team that only runs a weekly scan without a pull request gate will keep fixing the same class of fault, since nothing stops it from merging again.

Manual checks a CI tool cannot run

Automated tools cannot test every WCAG criterion. Many criteria need a human: whether reading order makes sense, whether a custom widget behaves with a keyboard, whether a video needs captions, and whether link text makes sense out of context. Build three manual checks into the release routine. First, tab through the changed page with a keyboard, from the top to the footer, and note where focus goes and whether the focus indicator stays visible. WCAG 2.2 criterion 2.4.7 covers focus visible, and criterion 2.4.3 covers focus order. Second, test the changed controls on a phone, and check target size: criterion 2.5.8 asks for pointer targets of at least 24 by 24 CSS pixels, with stated exceptions. Third, read the page with a screen reader for one minute, or ask a colleague to do so, and note any image, button or link whose name makes no sense out of context.

Practice judging focus states with the focus quiz, then run the same focus test on a real changed page. A quiz sharpens the eye, but only a keyboard test on the real page finds a focus trap in a real menu.

For a wider read on developer tools, see axeazy vs axe devtools scan then fix and how to choose an accessibility tool 10 criteria.

FAQ

Should a team fail a build on accessibility errors?

Yes, once the existing errors are fixed or the gate runs in report only mode for a short period first. Fail on errors, report warnings separately, and keep the page list short at the start. A gate that fails on every pull request for old faults will be switched off, which helps no one.

Is one CI tool enough for a developer team?

No. A CI gate catches template and code faults before merge, but it cannot test reading order, custom widget behaviour or captions. Pair the gate with a local browser check during development and a manual keyboard check before release, and add a scheduled site scan for faults that content changes introduce.

Why do so many tools use axe-core?

Because axe-core is a shared open source engine with a wide rule set, and tools built on it give consistent results across local, CI and site wide checks. When tools share an engine, compare them on workflow, gating, reporting and fix delivery, not on the engine name alone.

How should a team start if it has no CI accessibility test today?

Start with axe DevTools locally for one sprint, so developers learn the common faults. Then add pa11y-ci or Lighthouse CI on a short page list, in report only mode, for one sprint. Then turn on the fail rule for errors. Adding all three stages in one week usually ends with the gate disabled.

Last checked and sources

Last checked: October 31, 2026.

Sources: Deque axe-core page, axe DevTools extension page from Deque, pa11y project site, Lighthouse CI documentation, Chrome developer documentation on Lighthouse accessibility scoring, Axeazy methodology and pricing pages, WCAG 2.2 from the World Wide Web Consortium.

Compare plans on Axeazy pricing, then pick one pipeline stage to gate first and add the next stage only after the first gate runs clean.

Related reading

• Best Accessibility Monitoring Tools