Free accessibility testing tools and a 30-minute WCAG 2.2 check

Most accessibility failures on the web are not exotic. They are missing labels, empty buttons, images without text alternatives and low-contrast text, and free tools find them in minutes. This guide lists the free, maintained tools we checked on 9 October 2026, explains what each one is good at, and gives you a 30-minute routine that combines automated scans with the manual checks no scanner can do.

It is written for developers, founders and small teams who want to meet WCAG 2.2 Level AA without buying an enterprise platform first. You will finish with a short list of tools to install, a repeatable check for every release, and a small Node.js script that runs axe-core in your test suite.

Why automated tools are a start, not a finish

The WebAIM Million, an annual automated scan of the home pages of the top one million websites, is the clearest picture of where the web stands. Its 2026 report (February 2026 data) detected WCAG 2 failures on 95.9% of home pages, with an average of 56.1 detected errors per page. The six most common failure types were:

Every item in that table can be found automatically, which is good news. The limit is just as important: Deque, which maintains the open-source axe-core engine, says axe-core finds on average 57% of WCAG issues automatically. The rest, such as whether alt text is meaningful, whether focus order makes sense or whether an error message is announced, needs a person with a keyboard and a screen reader.

The free toolkit at a glance

Browser extensions: find problems on the page you are looking at

WAVE: see the problems in context

WAVE, from WebAIM, overlays icons on the page itself, so you see exactly which image lacks alt text and which heading level was skipped. WebAIM says the extension runs entirely in the browser and no information is sent to the WAVE server, which makes it safe for staging sites, intranets and pages behind a login. Why this resource: it is the friendliest way to show a designer or content editor what is wrong, because the issues sit on top of the design they recognise.

axe DevTools: the same engine your tests can use

The axe DevTools extension is free for automated testing. Deque's FAQ is explicit about the boundary: the free extension provides only automated testing, one page at a time, while guided tests, AI-assisted features and advanced reporting are part of the paid Pro tier (with a 14-day trial). Why this resource: the free extension uses axe-core, the same rules you can run in CI, so a result in the browser matches a result in your pipeline.

Accessibility Insights for Web: automated checks plus guided manual tests

Accessibility Insights for Web is a Microsoft extension for Chrome and Edge, open source under the MIT licence and still actively developed in October 2026. Its FastPass mode is designed to catch common, high-impact issues in under five minutes, and it includes a visual tab-stops check that draws the keyboard path across the page. Why this resource: it turns manual keyboard testing into a guided step rather than something people skip.

Built-in and command-line tools

Lighthouse in Chrome DevTools

Open DevTools, choose the Lighthouse panel and run the Accessibility category. Google's documentation describes the score as a weighted average of the accessibility audits, weighted by axe user-impact assessments, and each audit is pass or fail with no partial credit. Why this resource: it is already installed for anyone using Chrome. Treat a score of 100 as "no automated failures found", not "accessible".

axe-core in your own tests

axe-core is the open-source engine (MPL-2.0) behind many of these tools. Its rules cover WCAG 2.0, 2.1 and 2.2 at levels A, AA and AAA, plus best practices, and version 4.14.0 was published on npm on 5 October 2026. You can run it against rendered HTML in Node.js with jsdom. This script is a minimal check you can adapt for components or server-rendered pages:

// a11y-check.mjs: npm install axe-core jsdom
import { JSDOM } from 'jsdom';
import { readFileSync } from 'node:fs';

const html = `<!doctype html><html><head><title>Sign up</title></head>
<body><main>
  <img src="hero.png">
  <form><input type="email" name="email"><button></button></form>
  <a href="/pricing"></a>
</main></body></html>`;

const dom = new JSDOM(html, { runScripts: 'outside-only' });
dom.window.eval(readFileSync('node_modules/axe-core/axe.min.js', 'utf8'));

const result = await dom.window.axe.run(dom.window.document, {
  runOnly: { type: 'tag', values: ['wcag2a', 'wcag2aa', 'wcag22aa'] },
  // jsdom does not render, so colour contrast cannot be measured here
  rules: { 'color-contrast': { enabled: false } },
});

for (const v of result.violations) {
  console.log(`${v.id} (${v.impact}): ${v.nodes.length} element(s)`);
}
process.exitCode = result.violations.length ? 1 : 0;

When we ran it with Node.js 24 and axe-core 4.14.0, it reported five violations: button-name, html-has-lang, image-alt, label and link-name. That is five of the six most common failures in the WebAIM Million, caught before the page ships. For contrast, run axe in a real browser instead, for example through Playwright or the browser extension.

Pa11y for a list of URLs

Pa11y is a free command-line tool (version 10.0.0 was published in August 2026) that loads pages in a headless browser and reports issues. Why this resource: it suits sites without a JavaScript test suite, such as WordPress or Laravel Blade sites, because you only need a list of URLs. Pa11y CI, a separate package from the same project, runs it against many URLs in a pipeline.

Manual testing: the part no scanner can do

Screen readers

• NVDA is a free, open-source screen reader for Windows from NV Access. Pair it with Firefox or Chrome.
• VoiceOver is built into macOS and iOS. On a Mac, Command + F5 turns it on and off. Test with Safari, the combination most VoiceOver users have.

You do not need to be an expert. Listen to a sign-up form: does each field announce its label, does the error message get read out, and can you reach the submit button?

The keyboard-only check

Unplug the mouse, or simply do not touch it, and use Tab, Shift + Tab, Enter, Space and the arrow keys. Every interactive element should be reachable, the focus indicator should be visible, and nothing should trap focus. WCAG 2.2 added success criteria that make this stricter, including Focus Not Obscured (2.4.11, AA), which requires that a focused element is not entirely hidden by content such as sticky headers or cookie banners.

Reference material worth bookmarking

• How to Meet WCAG 2.2 (Quick Reference) from the W3C, filterable by level and technology. WCAG 2.2 is a W3C Recommendation, most recently updated on 12 December 2024.
• WebAIM Contrast Checker for colour pairs. WCAG AA requires 4.5:1 for normal text and 3:1 for large text.

A 30-minute accessibility check for every release

1. Automated scan (5 minutes): run axe DevTools or WAVE on the three most important templates, such as home, a content page and a form.
2. Fix the obvious (10 minutes): missing labels, alt text, empty links and buttons, document language and contrast.
3. Keyboard pass (5 minutes): tab through the main journey; confirm visible focus and no traps.
4. Screen reader pass (5 minutes): listen to the main form and one content page with NVDA or VoiceOver.
5. Zoom and small screens (5 minutes): zoom the browser to 200% and narrow the window to 320 CSS pixels; content should reflow without horizontal scrolling.

How to choose: what to install first

• Solo developer or founder: WAVE plus the free axe DevTools extension, and a keyboard pass before each release.
• Team with a JavaScript test suite: add axe-core to component or end-to-end tests so regressions fail the build.
• Content-heavy site (WordPress, Laravel, static): Pa11y against a list of key URLs in CI, plus WAVE for editors.
• Before a public launch or procurement review: do a full manual pass with Accessibility Insights' guided tests and a real screen reader, or bring in a specialist auditor.

Automated tools will not make a site accessible on their own, but they remove the most common failures cheaply. Put one scanner in the browser, one in CI and a short manual pass in your release checklist, and you will be ahead of most of the web.