Free Accessibility tool

WCAG 2.2 Checker

See where your site stands on each of the 55 WCAG 2.2 Level A and AA success criteria. Every criterion gets one of four statuses, so you can tell what automated tests covered and what a person still has to check.

Free. Tests up to five key pages in about a minute.

What this tool checks

  • Every Level A and AA criterion

    All 55 criteria, 31 at Level A and 24 at Level AA, in WCAG order with their number and name. 4.1.1 Parsing is left out because WCAG 2.2 marks it obsolete.

  • Automated results mapped to criteria

    axe-core rules run on the page you enter and up to four key pages, and each result is attached to the success criteria that rule tests. A criterion fails when any of its rules fails on any tested page.

  • Keyboard evidence

    A 40-press Tab probe on the first page feeds 2.1.2 No Keyboard Trap, and, as a heuristic shown for review, 2.4.7 Focus Visible.

  • Undecided results kept apart

    When a rule can’t reach a verdict, for example on text over an image, its criteria show Needs review rather than a pass or a fail.

  • Visible gaps instead of a score

    Criteria that no automated rule covers are marked Manual check. Nothing is averaged into a percentage that would hide what wasn’t tested.

What it can’t check

  • Decide criteria that need human judgment, such as 1.4.10 Reflow, 1.4.11 Non-text Contrast, the 1.2 criteria on captions and audio description, and 3.3.1 to 3.3.4 on form errors.
  • Turn “No automated failures” into a pass. A rule that ran and passed covers only what that rule tests.
  • Produce a conformance claim, an accessibility statement or a VPAT. Conformance is judged on full pages and complete processes, by people.
  • Test Level AAA, or pages beyond the five in the scan.
  • Reach the steps behind a login or a checkout, where criteria such as 3.3.7 Redundant Entry and 3.3.8 Accessible Authentication usually apply.

Why it matters

WCAG is written as success criteria, and that is how auditors, procurement teams and accessibility statements describe a site. A list of failing rules tells you what to fix. A criterion view tells you what you can and can’t yet say about the site.

Automated tools touch fewer than half of the Level A and AA criteria: axe-core maps its rules to about 25 of the 55. For the rest there is no reliable automated test. Software can’t tell whether an error message suggests a correction (3.3.3) or whether a page still works at 320 CSS pixels wide (1.4.10). Listing those as manual checks shows where testing still has to happen.

Even a criterion with no automated failures can fail. Rules for 1.1.1 Non-text Content check that an image has alt text; they can’t tell that alt="IMG_2041.jpg" is useless to someone who can’t see the photo.

How to read the results

Failed
At least one automated rule tied to this criterion failed on a tested page. This is a definite problem; the accessibility checker shows the elements and pages behind it.
Needs review
An automated check flagged something it couldn’t decide, such as the contrast of text on a gradient. A person has to look at the element.
No automated failures
At least one axe-core rule tied to the criterion ran and passed. This is not conformance: the rules cover only part of what the criterion asks.
Not triggered
Automated rules exist for this criterion, but nothing on the tested pages gave them anything to check, for example no video for the caption rules or no forms for the label rules. Test it by hand if your site has such content elsewhere.
Manual check
No automated rule covers this criterion, so the scan says nothing about it either way. Test it by hand.
Level A and Level AA
Level A is the minimum. Policies that cite WCAG usually name Level AA, which includes every Level A criterion.

How to fix the most common problems

  • 4.1.2 Name, Role, Value failed

    Custom controls built from div or span elements (menus, tabs, accordions, toggles) don’t tell assistive technology what they are or whether they’re open. Use a native <button> wherever possible, give it a name, and set aria-expanded or aria-pressed so its state is announced.

  • 1.3.1 Info and Relationships failed

    Structure must be in the markup, not only in the styling. Use real h2 and h3 elements instead of bold paragraphs, ul or ol for lists, th with scope for table headers, and labels or fieldset with legend for groups of form fields.

  • 3.1.1 Language of Page failed

    Add a lang attribute to the html element, for example <html lang="en">. WordPress themes normally print it with language_attributes(); in a Shopify theme, use <html lang="{{ request.locale.iso_code }}"> in layout/theme.liquid.

  • 2.5.8 Target Size (Minimum) failed

    Small icons and tightly packed links are hard to hit with a finger. Make each target at least 24 × 24 CSS pixels, or space small targets so a 24 px circle centred on each doesn’t overlap another target. Padding enlarges the target without changing the icon.

  • Working through the manual checks

    Start with the quick ones. For 1.4.10 Reflow, zoom a 1280 px wide browser window to 400% and check that nothing needs sideways scrolling. For 2.4.7 and 2.4.11, tab through the page and check that focus is always visible and never hidden behind a sticky header or cookie banner. For 3.3.1, submit a form with mistakes and see whether the errors are clearly described in text.

Questions about this tool

What changed at Levels A and AA in WCAG 2.2?

Six criteria were added: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry and 3.3.8 Accessible Authentication (Minimum). WCAG 2.2 also adds three Level AAA criteria and removes 4.1.1 Parsing.

Why isn’t 4.1.1 Parsing listed?

WCAG 2.2 marks 4.1.1 Parsing as obsolete and removes it, because browsers and assistive technologies no longer depend on the markup errors it covered. W3C notes that for WCAG 2.0 and 2.1 it is now treated as always satisfied for HTML content.

Does meeting WCAG 2.2 also cover WCAG 2.1?

Yes. WCAG 2.2 is backward compatible: content that conforms to 2.2 also conforms to 2.1 and 2.0. Testing against 2.2 therefore covers the older versions that many policies still cite.

Can I use this to write an accessibility statement or a VPAT?

It is a starting point, not a conformance report. A statement or VPAT needs every criterion evaluated, most of them by a person; the Manual check and Needs review lists show which ones still need that.

Why do so many criteria say “Manual check”?

Because no automated rule exists for them. Questions like whether a time limit can be extended, whether help appears in the same place on every page, or whether a login needs a memory test depend on how people use the site, not on markup a rule can read.

Sources

Related tools

The Accessibility Fix Report ($174, one-time) starts from the full free scan and adds more pages, the change to make for every finding, a PDF and re-tests to verify your fixes.

About the Accessibility Fix Report