WCAG 2.2 Explained: What It Actually Means for Your Business

WCAG.

You've probably seen it in a demand letter, a vendor pitch, or a compliance checklist. Maybe a developer mentioned it. Maybe it came up when you were researching ADA lawsuits and trying to understand what your website is actually supposed to do.

Almost nobody explains what it actually means.

The full name doesn't help: Web Content Accessibility Guidelines. Four words that tell you everything and nothing at the same time. The document itself runs to hundreds of pages and is written for engineers, not business owners. Most explainers either drown you in technical criteria or skip the substance entirely and leave you no better informed than when you started.

This is my attempt to do it properly — in plain English, without the jargon, for someone who runs a business and needs to understand what they're actually being measured against.

I'm Laura, co-founder of AccessBridge. We help small businesses find and document accessibility issues on their websites. WCAG is the framework we scan against, and I hear from business owners constantly that the acronym means nothing to them. Understanding what it's trying to do makes the whole compliance picture click into place. That's what this post is for.

What WCAG Actually Is

WCAG stands for Web Content Accessibility Guidelines. It's a set of technical standards published by the World Wide Web Consortium — the international body that governs web standards — that defines what it means for a website to be usable by people with disabilities.

The guidelines aren't a law in themselves. But they've become the benchmark that courts, regulators, and plaintiffs' attorneys use when assessing whether a website meets its legal obligations under the ADA and similar legislation. When a lawsuit claims a website is inaccessible, WCAG is almost always the measuring stick.

WCAG 2.2 is the current version. It was released in October 2023 and approved as an international standard (ISO/IEC 40500:2025) in October 2025. If you're scanning your site for accessibility issues, 2.2 is what you should be testing against — not the older 2.1, which many tools still default to.

The Four Principles — What Every Website Must Be

WCAG organises everything around four core principles. Every requirement in the guidelines connects back to one of these four ideas. In plain English, they are:

Perceivable. Users must be able to perceive the information on your site. If someone can't see, the content needs to work through sound. If someone can't hear, the content needs to work visually. Images need text descriptions. Videos need captions. Nothing critical should exist only in a format that some users simply cannot access.

Operable. Users must be able to operate your website. This is where keyboard navigation, touch target sizes, and drag interactions all live. If your site can only be used with a mouse, or requires precise physical movements that some users can't make, it fails on operability.

Understandable. Users must be able to understand what your site is saying and how it works. Error messages need to explain what went wrong. Forms need to label their fields. Navigation needs to behave predictably. A site that confuses users — especially those with cognitive disabilities — is not accessible, even if it technically renders correctly.

Robust. The site must work across different technologies. Screen readers, voice input tools, and browser extensions need to be able to parse your content correctly. A site built with sloppy code might look fine visually but be completely unreadable to assistive technology.

The Three Levels — A, AA, and AAA

Within those four principles, every individual requirement is assigned a level: A, AA, or AAA.

Level A is the minimum. These are the most critical barriers — things so fundamental that without them, some users simply cannot use a website at all.

Level AA is the practical target. This is what courts, regulators, and the legal standard expects. When a business is sued over website accessibility, Level AA is almost always what's being tested against. The HHS Section 504 final rule we covered in our post on dental practice accessibility specifically requires WCAG 2.1 Level AA. Most ADA litigation uses the same benchmark.

Level AAA is the gold standard — the highest level of accessibility, not required by law, but worth knowing exists.

For most small businesses, Level AA is the target. Not perfect, not AAA, just: every user can access your core content and complete your core tasks.

What Changed in WCAG 2.2

WCAG 2.2 adds nine new requirements on top of everything in 2.1. They address gaps that the previous version left open — particularly around mobile usability, cognitive accessibility, and keyboard navigation. Here are the ones most likely to affect small business websites.

Focus appearance. When a keyboard user tabs through your site, there needs to be a visible indicator showing where they are — think of it as the cursor equivalent for keyboard navigation. WCAG 2.2 tightens the requirements around how visible that indicator must be. Many sites have a focus indicator that technically exists but is so faint it's effectively invisible.

Dragging movements. If any interaction on your site requires a sustained drag — a range slider, a date picker, a sortable list — there must be an alternative that doesn't require dragging. A simple typed input, a set of buttons, anything that doesn't demand fine motor control. This matters significantly for users with limited dexterity, including many older users and anyone with conditions affecting hand steadiness.

Target size. Clickable elements — buttons, links, form inputs — must meet a minimum size so users with limited dexterity can reliably hit them. Small "close" buttons, tightly packed menu items, and tiny checkbox targets all fail this criterion. The minimum is 24 by 24 pixels for most elements.

Accessible authentication. Login processes cannot rely solely on cognitive function tests. If your site uses a standard CAPTCHA — "type the distorted letters" or "solve this puzzle" — without an accessible alternative, it fails WCAG 2.2. This matters for any site with a customer account, booking system, or patient portal behind a login.

Consistent help. If your site offers a help mechanism — a chat widget, a contact link, a FAQ — it must appear in the same location on every page. Users with cognitive disabilities rely on consistency to navigate.

Why Some Tools Still Report Against WCAG 2.1

This is worth knowing. Many popular accessibility checkers — including free tools widely used by developers — have not yet been updated to test against WCAG 2.2. They'll scan your site and give you a clean or near-clean report, but they're not checking for dragging movement alternatives, target sizes, or accessible authentication.

This is one reason we see businesses with recent accessibility audits still facing claims. The audit was real, but it tested against an outdated standard. We wrote about the limits of overlay tools in Why Accessibility Overlays Are Getting Businesses Sued — the same principle applies to scanners that haven't kept up with the current standard.

AccessBridge tests against WCAG 2.2. If a tool doesn't tell you which version it's testing against, ask.

What WCAG 2.2 Means Practically for Your Business

You don't need to read the full specification. What you need to know is this:

Your website is probably being tested against WCAG 2.2 by anyone who files an ADA claim against you. The courts don't require you to have read the standard — they require your site to meet it.

The good news is that the vast majority of violations are fixable. Missing text descriptions, unlabelled form fields, low colour contrast, inadequate focus indicators, tiny tap targets — these are not exotic engineering challenges. A competent web developer can address most critical issues in a day or two once they know what to look for.

The first step is knowing what's on your site. A scan against the current standard — 2.2, not 2.1 — will tell you what you're working with. See how your site scores before assuming you're covered.

This Isn't Just a Legal Framework

WCAG wasn't created to generate litigation. It was built by accessibility researchers and disability advocates who spent years documenting, in precise technical detail, every way a website can fail the people who need it most.

There are 61 million adults in the United States living with a disability. A significant number of them encounter barriers on websites every single day — barriers that sighted, non-disabled users never notice and developers never intended to create. WCAG is the attempt to describe those barriers systematically, so they can be fixed.

When a business works toward meeting it, real people have a better experience. That's the point. The legal exposure is the consequence of getting it wrong — not the reason to get it right.

See how your site scores against WCAG 2.2 — free scan, no sign-up required.
[Run your free accessibility scan → https://accessbridge.app/demo]

A note from Laura: WCAG is genuinely complex and I've simplified it significantly here. If you're a developer or accessibility professional and something in this post is imprecise, I'd welcome the correction — accessibility advocates have been building and refining these standards for decades and I have enormous respect for that work.

Sources

AccessBridge identifies accessibility issues to support your remediation process. We are not a law firm and do not provide legal advice or guarantee legal compliance.