WCAG Checker: Test Your Site Against WCAG 2.1 and 2.2 Success Criteria

What a WCAG checker actually tests

WCAG, the Web Content Accessibility Guidelines, is the international standard maintained by the W3C for making web content usable by people with disabilities. A WCAG checker inspects your rendered pages against the individual rules in that standard, called success criteria, and flags the places where your markup, styling, or content does not meet them. The current stable versions are WCAG 2.1 and WCAG 2.2, and most organizations aim for Level AA, which combines all Level A and Level AA criteria.

It is important to be precise about what any automated checker can and cannot see. Automated scanning reliably detects issues that are machine testable: missing alternative text, form fields without labels, insufficient color contrast, empty links and buttons, missing document language, broken heading structure, and invalid ARIA usage. These are real, high frequency failures, and catching them removes a large share of the barriers on a typical site.

A WCAG checker cannot judge everything, though. Criteria that depend on meaning and intent, such as whether alternative text is accurate, whether a heading describes its section, or whether keyboard focus order is logical, still need human review. VASTROX AccessGuard is a scanner and issue detection tool. It surfaces the machine testable failures with precision and gives your team a structured starting point for the manual checks that remain.

WCAG 2.1 vs WCAG 2.2, and A vs AA

WCAG 2.1 was published in 2018 and added criteria for mobile, low vision, and cognitive accessibility on top of WCAG 2.0. WCAG 2.2 became a W3C Recommendation in October 2023 and is backward compatible: if you meet WCAG 2.2, you also meet 2.1. WCAG 2.2 adds nine new success criteria and removes one, 4.1.1 Parsing, which is now considered obsolete. Meeting 2.2 is the strongest current target for most teams.

The new Level AA criteria in WCAG 2.2 are the ones most sites need to check. They include 2.4.11 Focus Not Obscured (Minimum), which requires that a focused element is not entirely hidden behind sticky headers or cookie banners; 2.5.7 Dragging Movements, which requires a single pointer alternative to drag actions; 2.5.8 Target Size (Minimum), which asks that interactive targets be at least 24 by 24 CSS pixels or have equivalent spacing; and 3.3.8 Accessible Authentication (Minimum), which discourages cognitive function tests like puzzles at login.

Conformance levels stack. Level A is the minimum and covers the most fundamental barriers. Level AA is the common legal and commercial benchmark and is what regulators and procurement contracts usually reference. Level AAA is the most demanding and is generally applied selectively rather than site wide. AccessGuard lets you scan against WCAG 2.1 or 2.2 at Level A and AA so you can match whatever target applies to your project.

The POUR principles that organize every criterion

Every WCAG success criterion sits under one of four principles, known by the acronym POUR: Perceivable, Operable, Understandable, and Robust. Understanding POUR makes your results easier to reason about, because it tells you which kind of user experience a failure affects rather than leaving you with a list of isolated rule numbers.

Perceivable means information must be presentable in ways users can sense, which covers text alternatives for images, captions for media, and sufficient contrast. Operable means the interface must be usable by keyboard and other input methods, with enough time, no seizure risks, and clear navigation and focus. Understandable means content and operation must be predictable and readable, with labeled inputs and helpful error handling. Robust means content must work reliably with assistive technologies, which is where valid HTML and correct name, role, and value information for controls matter.

AccessGuard groups your findings by these four principles and then by the specific criterion beneath each one. That structure helps you prioritize: a cluster of Perceivable contrast failures points at your design system, while repeated Robust ARIA failures usually point at a component library that needs a fix once and benefits every page.

Common WCAG failures a checker will surface

Across the web, a small set of issues accounts for most automatically detectable failures. Low contrast text is consistently the single most common, where foreground and background colors do not meet the 4.5 to 1 ratio for normal text (criterion 1.4.3). Missing image alternative text (1.1.1) is close behind, followed by form inputs with no associated label (1.3.1, 3.3.2), and links or buttons that contain no discernible text (2.4.4, 4.1.2).

Other frequent findings include missing document language (3.1.1), which breaks screen reader pronunciation; skipped or out of order heading levels (1.3.1), which fragment the page outline; and invalid or misused ARIA attributes (4.1.2), which can actively mislead assistive technology. Keyboard traps and missing visible focus indicators (2.1.1, 2.4.7) affect anyone who does not use a mouse, and on WCAG 2.2 you will also see new checks around target size and focus visibility.

Because these failures repeat, fixing them is high leverage. A single corrected color token, one labeled component, or one template level language attribute can clear the same issue across hundreds of pages. AccessGuard counts occurrences so you can see which fixes have the widest reach.

• Low contrast text (WCAG 1.4.3, Level AA)
• Images missing alternative text (WCAG 1.1.1, Level A)
• Form fields without labels (WCAG 1.3.1 and 3.3.2)
• Empty links and buttons (WCAG 2.4.4 and 4.1.2)
• Missing page language attribute (WCAG 3.1.1, Level A)
• Broken or skipped heading structure (WCAG 1.3.1)
• Invalid or misused ARIA (WCAG 4.1.2, Level A)
• Missing visible focus indicator (WCAG 2.4.7, Level AA)

How AccessGuard maps issues to success criteria and fixes

A raw list of accessibility warnings is not useful on its own. What your team needs is to know which rule was broken, why it matters, and what to change. AccessGuard ties every finding to a specific WCAG criterion by number and name, tags its conformance level, and places it under its POUR principle, so the report reads as a coherent map of your compliance rather than a pile of alerts.

Each finding comes with developer fix guidance written for the code, not the abstract. For a contrast failure you get the measured ratio, the offending colors, and the target ratio. For a missing label you get the element and the accessible ways to associate a name. For an ARIA problem you get the specific attribute at fault and the correct pattern. You can scan on demand with the free web scanner, install the WordPress plugin for ongoing checks inside your CMS, export a PDF report for stakeholders, and track progress over time in the dashboard.

These results are accessibility scan findings and EAA readiness signals, not legal advice, and passing an automated scan does not guarantee legal compliance. AccessGuard is built to drive real accessibility improvements and to give you a defensible, criterion by criterion record of the work. Where a fix needs hands on engineering, VASTROX web development, WordPress maintenance, and accessibility repair services can carry out the remediation for you.

Frequently asked questions

More accessibility checkers