Free WCAG 2.1 Compliance Checker

What is WCAG and why does it matter legally?

WCAG stands for Web Content Accessibility Guidelines. It's the international standard published by the World Wide Web Consortium (W3C) that defines how to make web content accessible to people with disabilities. The W3C has been developing these guidelines since 1999, and they've become the technical foundation that accessibility laws around the world point to.

WCAG 2.1 Level AA is the version and conformance level that virtually every accessibility law references. The ADA in the United States, the European Accessibility Act, Section 508 for federal agencies, Canada's Accessible Canada Act, and Australia's Disability Discrimination Act all use WCAG AA as their benchmark for what "accessible" means in practice.

In 2024, the DOJ formally recognized WCAG 2.1 AA as the standard for ADA web compliance, codifying what courts had already been treating as the de facto requirement for years. This matters because it removes any ambiguity about what standard your website will be measured against if an accessibility complaint is filed. Before 2024, defendants could argue that no specific technical standard applied. That argument is essentially gone now.

Courts increasingly treat WCAG AA conformance as the dividing line between compliant and non-compliant. If your site meets WCAG 2.1 AA, you have a strong defense. If it doesn't, you're exposed. The standard itself is thorough but achievable, which is exactly why regulators chose it.

The four WCAG principles explained

WCAG is built around four principles, sometimes called POUR. Every success criterion in the standard falls under one of these four categories, and together they cover the full range of ways a website can fail its users.

Perceivable

Content must be presentable in ways that all users can perceive, regardless of sensory ability. If information is only conveyed visually, users who are blind or have low vision can't access it. If it's only conveyed through audio, users who are deaf miss it entirely.

Common violations include images without alt text (a screen reader announces "image" with no context, leaving the user guessing), videos without captions (deaf users lose all dialogue and narration), and text with insufficient color contrast (users with low vision or color blindness can't read it). These aren't edge cases. Missing alt text alone accounts for roughly a third of all accessibility issues found across the web.

Operable

Every interface component and navigation element must be usable by everyone, including people who can't use a mouse. This principle covers keyboard accessibility, sufficient time for interactions, seizure prevention, and navigability.

A dropdown menu that only opens on mouse hover is unusable for keyboard-only users. A form with a 30-second timeout gives no chance to users who type slowly or use assistive input devices. Rapidly flashing content can trigger seizures in people with photosensitive epilepsy. These failures don't just create inconvenience; they make entire features or pages completely inaccessible to specific groups of users.

Understandable

Content and interface behavior must be clear enough that users can comprehend and use them. This covers readable text, predictable page behavior, and input assistance for forms.

A page that doesn't declare its language (the lang attribute on the HTML element) causes screen readers to mispronounce every word on the page, rendering the content incomprehensible. A form that submits when a user selects a dropdown option, without warning, violates the predictability principle. Error messages that say "invalid input" without explaining what's wrong leave users stuck in a loop of failed attempts. These issues disproportionately affect users with cognitive disabilities, but they frustrate everyone.

Robust

Content must be structured well enough that assistive technologies can reliably interpret it. This is the most technical principle and it's where many modern web applications fail silently.

Custom UI components built with div and span elements instead of semantic HTML (or proper ARIA attributes) are invisible to screen readers. A button coded as a styled div with a click handler won't be announced as a button, won't be keyboard-focusable, and won't appear in the accessibility tree. Duplicate IDs in the DOM cause assistive technologies to associate labels and descriptions with the wrong elements. These issues are common in component-based frameworks where developers build custom controls without considering how they're exposed to the accessibility API.

WCAG conformance levels: A, AA, and AAA

Targeting Level AA is the right balance of legal protection and practical achievability. Level A is too low to be defensible, since it allows sites with serious usability problems for disabled users. Level AAA criteria like sign language interpretation for all video content or restricting text to a lower-secondary reading level simply aren't feasible for most organizations to maintain across every page. AA is where you get the strongest legal standing without committing to requirements that are unrealistic to sustain.

What automated WCAG testing catches (and what it misses)

Transparency matters here: automated tools can reliably test about 30-40% of WCAG 2.1 AA success criteria. That's a real limitation, and you should know about it before you interpret your scan results.

What automated testing catches well: the presence or absence of alt text on images, form inputs without associated labels, heading hierarchy violations (skipping from h2 to h4), missing document language declarations, color contrast ratios that fall below the 4.5:1 threshold, empty links and buttons, duplicate IDs, and missing ARIA attributes on custom components. These are structural, deterministic checks where the tool can give a definitive pass or fail.

What requires human testing: whether alt text actually describes the image meaningfully (an image tagged alt="photo" passes automated checks but fails the spirit of the requirement), whether the logical reading order makes sense when CSS positioning is removed, whether custom interactive components are usable with a screen reader in practice, whether error messages are clear enough for users with cognitive disabilities, and whether focus management in single-page applications works correctly through complex user flows.

Why automated testing is still worth it: the issues that automated tools catch are the most commonly cited in accessibility lawsuits. Missing alt text, contrast failures, and unlabeled form fields show up in the majority of demand letters and legal complaints. Fixing these issues first gives you the highest compliance return for the least effort. Think of automated testing as the foundation, not the whole structure.

WCAG 2.2: what's changing

WCAG 2.2 was published by the W3C in October 2023, adding nine new success criteria on top of everything in 2.1. The new criteria focus on areas where 2.1 had gaps, particularly around authentication, mobile interactions, and target sizing.

The most notable additions: Focus Not Obscured requires that when a UI component receives focus, it isn't entirely hidden behind other content like sticky headers or cookie banners. Dragging Movements mandates that any functionality triggered by dragging (like reordering a list) must also be achievable through a simple click or tap alternative. Accessible Authentication prohibits cognitive function tests (like solving a puzzle) as the sole authentication method, requiring alternatives like password managers or passkeys. Target Size sets a minimum 24x24 pixel touch target for interactive elements, addressing a persistent mobile usability problem.

For now, WCAG 2.1 AA remains the current legal benchmark. The DOJ's 2024 rule references 2.1, and courts have not yet shifted to requiring 2.2 conformance. That said, the 2.2 criteria address real usability problems that affect your users today, and adopting them proactively puts you ahead of the curve when regulations catch up.

Frequently asked questions