Accessibility checkers all report against the same WCAG success criteria, so the differences that matter are where they run, what they can see, and how noisy they are. Here is what people who do this for a living actually keep installed.
Deque's axe-core is the rules engine inside Lighthouse's accessibility category, the axe DevTools extension, and most CI integrations. It is deliberately conservative: it reports issues it can prove, which is why its findings are worth fixing and why its pass result means very little on its own. Run it in a real browser against the rendered DOM — a static HTML scan misses everything your JavaScript adds.
Two options, both free:
@axe-core/playwright — inject axe into an existing Playwright test and assert zero violations on a per-page basis. Best when you already have E2E tests, because you can check states, not just initial loads: menu open, modal shown, form in error.pa11y-ci --sitemap https://example.com/sitemap.xml — crawls a whole site and fails the build on new issues. A .pa11yci file lets you set per-URL actions (log in, click, wait) and a threshold while you burn down a backlog.The state coverage point is the one that separates a real setup from a checkbox: most serious failures live in modals, menus, error messages and focus traps, none of which exist on a freshly loaded page.
Accessibility Insights for Web is the most useful free extension because of its guided Assessment mode and Tab Stops visualiser, which draws the actual focus order on the page — the fastest way to find a keyboard trap or an element that focus skips. axe DevTools gives you the same engine as CI with an inspector. IBM's Equal Access Checker reports against its own ruleset and often flags things axe stays quiet about. WAVE remains the easiest for showing a non-specialist stakeholder what is wrong.
eslint-plugin-jsx-a11y stops a class of mistakes at the keyboard — missing alt attributes, click handlers on non-interactive elements, invalid ARIA roles — before the code is even committed. Storybook's a11y addon runs axe against each component in isolation, which is where design-system problems are cheapest to fix.
Automated tooling typically identifies around a third of WCAG failures. It cannot tell you whether alt text is meaningful, whether focus order matches reading order, whether an error message explains how to fix the error, or whether a screen-reader user can complete checkout. Reserve real time for a keyboard-only run and a screen-reader run — NVDA on Windows and VoiceOver on macOS and iOS cover most users — through your three most valuable journeys.
eslint-plugin-jsx-a11y in the editor, axe via Playwright on component and page states in CI, pa11y-ci crawling staging weekly, Accessibility Insights for the manual assessment, and a scheduled screen-reader pass each release. That combination costs nothing, runs automatically, and leaves human attention for the things only humans can judge.