WCAG 2.2 AA Explained: The Standard Behind ADA Website Compliance

If you have looked into website accessibility at all, you have run into a wall of version numbers. WCAG 2.0, 2.1, 2.2, Level A, AA, AAA, and someone in a forum insisting you should wait for 3.0. It reads like a standards committee talking to itself, which is roughly what it is.

Here is the translation. It is shorter than you would expect, and once you have it, most of the confusing advice online sorts itself out.

What WCAG is, and what it is not

The Web Content Accessibility Guidelines are published by the World Wide Web Consortium, the same body that maintains the standards behind HTML and CSS. WCAG is not a law and it was not written by a government. It is a technical specification.

It matters legally because everyone else adopted it. Federal regulations reference it, procurement contracts require it, settlement agreements are written against it, and courts treat it as the working definition of an accessible site. As I cover in the main piece on ADA website compliance, there is no federal technical standard for private business websites, so WCAG is what fills that vacuum in practice.

The versions, in order

• WCAG 2.0 (2008). Still the version Section 508 names for federal agencies and their vendors.
• WCAG 2.1 (2018). Added criteria for mobile, low vision and cognitive disabilities. This is the version the Department of Justice adopted in its 2024 rule for state and local government.
• WCAG 2.2 (October 2023, updated December 2024). The current recommendation, and an international standard as ISO/IEC 40500 since 2025.

The versions stack. WCAG 2.2 contains everything in 2.1, which contains everything in 2.0. This is the single most useful fact in this article, because it means you do not have to work out which version applies to you and build to that one. Build to 2.2 AA and you have satisfied the others by construction.

Should you wait for WCAG 3.0?

No, and it is not close.

WCAG 3.0 is an incomplete working draft. The W3C’s own page says it “is intended to develop into a W3C Standard in a few years” and declines to give a target date. You will find blogs confidently predicting a year; the organization actually writing it will not, which tells you something.

More to the point, W3C has said plainly that WCAG 3 will not supersede WCAG 2, and WCAG 2 will not be deprecated for at least several years after WCAG 3 is finished. Waiting means being inaccessible and exposed for years in exchange for nothing.

A, AA, AAA, and why AA

Each success criterion in WCAG carries a level. A is the floor, the things that make content usable at all. AA adds the criteria that make it genuinely usable for most people with disabilities. AAA is the ceiling, and W3C itself notes that AAA conformance is not achievable for all content.

AA is the target, universally. The DOJ rule says AA. Section 508 says AA. Settlement agreements say AA. Nobody serious asks for AAA across a whole site, and any vendor promising it either does not understand the standard or is not planning to deliver it.

Conformance is also stricter than people expect. To claim conformance at a level, you have to meet every criterion at that level, on every page, with no exceptions. There is no partial conformance and no scoring out of a hundred. One unlabeled form field on your contact page means the site does not conform, regardless of how good the other forty pages are. This is why a percentage score from an automated scanner is not a conformance claim.

The four principles: POUR

Every criterion in WCAG sits under one of four principles. Content has to be Perceivable, Operable, Understandable and Robust. The acronym is POUR, and it is genuinely the clearest way to hold the whole standard in your head.

Perceivable

People have to be able to sense your content, through whichever sense is available to them. Images need text alternatives so a screen reader has something to say. Video needs captions. Text needs enough contrast against its background, measured as a ratio rather than judged by eye, with 4.5 to 1 the requirement for normal-size text at AA. Content must not rely on color alone to make a point, which is why “the fields in red are required” fails on its own.

Operable

People have to be able to use the interface, including without a mouse. Everything reachable by pointer must work by keyboard, and you must be able to get back out of whatever you tabbed into. There must be a visible focus indicator so a keyboard user can see where they are. Anything moving or auto-playing needs a way to stop it. Time limits need to be extendable.

Understandable

Content and behavior have to be predictable. The page language is declared so a screen reader uses the right pronunciation. Navigation stays in the same place from page to page. Form errors say what went wrong and how to fix it, rather than turning a box red and leaving you guessing. Nothing changes context on you without warning, which is the criterion that catches menus that submit the moment you arrow onto an option.

Robust

The code has to be clean enough that assistive technology can interpret it reliably, now and after the next browser update. Semantic HTML, correctly used, does most of this on its own: a real button element behaves like a button for every user, whereas a styled div pretending to be one has to have every behavior added back by hand, and usually is not. Names, roles and values need to be exposed properly so a screen reader can announce what a control is and what state it is in.

This principle is a large part of why my default is a hand-coded theme rather than letting a page builder generate the markup. When a tool emits the HTML, you inherit whatever it decided to produce, and you tend to find out what that was during an audit.

What 2.2 added that is worth knowing

WCAG 2.2 introduced nine new success criteria. The ones at A and AA level, which is to say the ones that affect you, are these:

• Focus Not Obscured. When you tab to an element, a sticky header or cookie banner must not be covering it. Extremely common failure on modern sites.
• Dragging Movements. Anything you can do by dragging needs a single-pointer alternative, for people who cannot drag accurately.
• Target Size (Minimum). Clickable targets need to be at least 24 by 24 pixels, with some exceptions. This catches cramped mobile icon rows.
• Consistent Help. If help is offered, it appears in the same relative place across pages.
• Redundant Entry. Do not make someone type the same information twice in one process, a real problem in multi-step checkouts.
• Accessible Authentication (Minimum). Login must not require a cognitive test such as solving a puzzle or transcribing characters, unless an alternative exists. Password managers must be allowed to work.

WCAG 2.2 also retired one older criterion, 4.1.1 Parsing, which was made obsolete because modern browsers handle the markup issues it covered. If an audit report you were sold still flags Parsing failures, the tool generating it is out of date.

Where this leaves you

Build to WCAG 2.2 AA and you meet the standard every relevant rule references, with headroom. That is what I remediate to, and what every site I build is made to from the first line rather than bolted on afterward.

You can check a good number of these yourself without buying anything, using the checklist I put together. If you would rather see what a proper measurement involves, here is what happens during an accessibility audit. And the scope and pricing of the work itself are on the ADA compliance page.