Best WCAG 2.2 Testing Tools for 2026 Checks

WCAG 2.2 testing tools differ in one practical way: some let you filter results to WCAG 2.2 AA, and some only run a general set of rules and leave the version question vague. If your target is WCAG 2.2 AA, pick a tool that names that level in its own settings or docs, then add manual checks for the new criteria that code alone cannot judge. This guide lists six tools, states what each one offers for WCAG 2.2 on its own page, and names the manual step that goes with it.

What changed in WCAG 2.2

WCAG 2.2 extends WCAG 2.1 and adds nine new success criteria. The new AA criteria that most teams meet first are 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), and 3.3.8 Accessible Authentication (Minimum). Two new A criteria, 3.2.6 Consistent Help and 3.3.7 Redundant Entry, also sit in the set. A tool that only mentions WCAG in general may still check older criteria well, but it will not tell you, in its own settings, whether it is filtering to the 2.2 set. Check the setting before you trust the label.

Tools with a named WCAG 2.2 setting

Axe DevTools

Axe DevTools gives the clearest version control in this list. Its extension settings page lists WCAG 2.2 AAA, WCAG 2.2 AA, and WCAG 2.2 A as filter choices, beside the 2.1 and 2.0 levels. That matters for reporting. When you set the filter to WCAG 2.2 AA, the panel shows issues tied to that level, and you can read the criterion for each failing element. Use it on a rendered page in the browser, fix the serious items, and re-run the same page after each fix round.

Fit: a developer or a site owner who works in the browser and wants element level detail. Limit: it checks one page at a time, and it cannot judge whether a label makes sense or whether focus stays visible under a sticky header in every scroll state. Add a keyboard pass for those points.

Accessibility Insights for Web

Accessibility Insights for Web frames its work as an assessment against WCAG 2.2 Level AA success criteria. Its assessment includes 24 tests, and each test covers requirements marked automated, assisted, or manual. Automated requirements are judged by the tool. Assisted requirements are judged with tool help. Manual requirements come with instructions for a person to judge. That structure fits WCAG 2.2 well, since several new criteria need a person to look, tab, and try an action.

Fit: a team that wants a structured pass over a key page and a report it can keep. Limit: an assessment takes longer than a quick scan, and it still covers pages one at a time. Use it for home, product, checkout, and form pages first, not for every blog post on day one.

Storybook accessibility addon

Storybook checks components, not whole pages, and its docs state the default rule set covers WCAG 2.0 and 2.1 A and AA plus best practices. The same docs state you can change the rules with the runOnly option to check against WCAG 2.2 AA or WCAG 2.x AAA rules. That distinction is worth noting. Out of the box, Storybook does not claim a 2.2 default. With the runOnly change, it can check components against 2.2 AA during development, before those components reach a live page.

Fit: a React or component based team that wants to catch label, name, and contrast problems in a story before release. Limit: a component that passes alone can still fail on a live page, where layout, sticky headers, and real content change focus and target size. Pair component checks with a page level scan.

Tools that support WCAG 2.2 work without a single version filter

Axe-core

Axe-core is the open engine behind several tools in this list. Its rule set maps to WCAG criteria, and teams can run it in a browser, in tests, or in a pipeline with tags for a chosen level. The strength of axe-core is control: a team can pick a tag set, run the same checks on each build, and keep results in code. The limit is the same as its strength. Axe-core on its own gives no panel, no guided test, and no report format. It needs a wrapper, such as a browser extension, a test library, or a pipeline step, to be useful day to day.

Fit: a development team that already runs automated tests and wants WCAG checks in the same flow. Limit: automated rules cover only part of WCAG 2.2 AA, so a passing run must still be followed by keyboard and screen reader checks.

Google Lighthouse

Lighthouse gives a combined audit in Chrome, with an accessibility score that is a weighted average of audits, weighting based on axe user impact, and each audit marked pass or fail. Lighthouse runs a subset of axe-core rules, plus its own checks, and it lists manual items apart from the score. That makes it a useful smoke test for a page, and a weak choice as the sole proof of a WCAG 2.2 AA target, since its own scoring page does not present it as a full 2.2 AA assessment.

Fit: a quick check during development, and a way to track change on the same page over time. Limit: a high score can hide manual criteria, such as focus obscured by a sticky element or a drag action with no single pointer alternative. Use Lighthouse to spot regressions, then confirm with axe DevTools or Accessibility Insights.

WAVE

WAVE shows errors, contrast errors, alerts, features, structural elements, and ARIA as icons on the page. Its own site describes it as a suite that can identify many accessibility and WCAG errors and helps human evaluation. WAVE is a strong second view because it draws problems on the rendered page, which helps a non developer see why a heading or a label matters. Its own page does not present a WCAG 2.2 AA filter in the same way axe DevTools does, so treat WAVE as a visual check and a human evaluation aid, not as the version filter for a 2.2 AA report.

Fit: a visual review, a second opinion after an axe based scan, and a teaching tool for a team that is new to accessibility. Limit: WAVE can confirm that alt text exists, but it cannot confirm that the alt text is accurate. A person must read it.

The manual checks WCAG 2.2 still needs

Four checks belong in every WCAG 2.2 pass, and no scanner in this list does all four alone.

• Focus not obscured: tab through a page with sticky headers, cookie banners, and chat panels open, and watch whether the focused element stays at least partly visible.
• Target size: check small icon buttons and close controls on a phone view, and confirm each target is at least 24 by 24 CSS pixels or has enough spacing around it.
• Dragging alternatives: try every drag action with a single pointer action, such as a button or a tap, and confirm the same result is possible without dragging.
• Accessible authentication: check login and signup flows for a puzzle, a memorised code, or a cognitive test with no alternative, and confirm a paste, a password manager, or another supported route works.

Keep notes on each check with the page address and the date. That dated note is more useful than a screenshot of a score, since it shows what a person actually tried.

How to choose a WCAG 2.2 stack

Pick one version filter tool as your reporting tool: axe DevTools for page work, or Accessibility Insights for a guided assessment. Add Storybook or axe-core in tests if you build components. Add WAVE for a visual second view. Add Lighthouse only as a smoke test. Then set a rule for releases: no page ships with a known serious automated failure, and no key flow ships without the four manual checks above. That rule is simple to keep, and it stops a team from trading a clean score for a page that is hard to use with a keyboard.

Axeazy as a homepage check

Axeazy scans a homepage with 98 automated checks from axe-core rules covering WCAG 2.0 A and AA, 2.1 AA, 2.2 AA, and best practices. For sites with a GitHub repository, fixes arrive as a real pull request with a visible code diff that the owner or developer reviews and merges. For other sites, the owner gets computed fix values plus a guided checklist to apply by hand. Read the detail in Axeazy's capabilities page.

Related reading: How to Choose an Accessibility Tool: 10 Criteria and Best Accessibility Tools for Small Business. For a quick self test on focus, try the focus quiz.

FAQ

Which tool has the clearest WCAG 2.2 AA setting?

Axe DevTools, on its own settings page, lists WCAG 2.2 AA as a filter choice. Accessibility Insights frames its assessment against WCAG 2.2 Level AA success criteria. Both give a reader a named level to cite in a report, rather than a general WCAG label.

Does Storybook check WCAG 2.2 AA by default?

No, on its docs page. The default set covers WCAG 2.0 and 2.1 A and AA plus best practices. You can change the rules with the runOnly option to check against WCAG 2.2 AA. Set that option in your project config, or a component pass will miss the newer criteria.

Can Lighthouse alone prove WCAG 2.2 AA?

No. Lighthouse runs a subset of axe-core rules and gives a weighted score, with manual items kept apart from the score. Use it to spot change and regressions, then confirm with a version filter tool and manual checks for focus, target size, dragging, and authentication.

What is the most common WCAG 2.2 miss on a live page?

Small targets and hidden focus lead the list in practice. Icon buttons shrink on mobile views, and sticky headers cover the focused link as a keyboard user tabs down a page. Both are easy to check by hand: open a phone view, tab from the top, and watch where focus goes.

Last checked: October 31, 2026

Sources

• WCAG 2.2 from W3C
• Axe DevTools extension settings from Deque
• Assessment in Accessibility Insights for Web
• Accessibility tests in Storybook docs
• Lighthouse accessibility scoring from Chrome for Developers
• WAVE evaluation tools from WebAIM

For a homepage check that leads to code level fixes, run Axeazy's free scan.

Related reading

• Best Accessibility Tools for React and Next.js