WCAG 2.1 AA in plain English

What WCAG is

The Web Content Accessibility Guidelines are published by the World Wide Web Consortium (W3C), the standards body behind CSS and much of the rest of the web. Version 2.0 came out in December 2008, 2.1 on June 5, 2018, and 2.2 on October 5, 2023. Each version keeps the requirements of the one before and adds new ones, so a site that meets 2.2 also meets 2.1 and 2.0.

WCAG is organized in layers: 4 principles, a set of guidelines under them, and under those, testable success criteria. The criteria are what you are measured against. Each one has a level:

• Level A is the floor: without it, some people cannot use the page at all.
• Level AA adds the criteria that remove the most common remaining barriers, such as low contrast and text that breaks when enlarged.
• Level AAA is the most demanding. W3C itself does not recommend requiring AAA for entire sites, because some content cannot meet every AAA criterion.

“Meeting WCAG 2.1 AA” means meeting every Level A and Level AA criterion in version 2.1: 50 in all, 30 at A and 20 at AA.

Why 2.1 AA, and why now

In April 2024 the Justice Department adopted WCAG 2.1 Level AA as the technical standard for the websites, web content and mobile apps of state and local governments under Title II of the ADA. Governments of 50,000 people or more have until April 26, 2027; smaller governments and special districts have until April 26, 2028. The rule covers content a vendor provides for you, too. Our ADA Title II summary has the details.

Nonprofits are not covered by Title II, but 2.1 AA is still the sensible target. It is the bar the federal government set for public services, and a site that clears it is usable by far more of the people you serve.

The 4 principles

Every criterion sits under one of 4 principles. If you remember nothing else, remember these:

• Perceivable. People can take in the content whatever their senses allow: text alternatives for images, captions for video, enough contrast to read.
• Operable. People can use every control, with a keyboard, a switch or their voice, not only a mouse, and have enough time to do it.
• Understandable. Pages behave predictably, forms explain what they need, and errors say how to fix them.
• Robust. The code is built to standards, so screen readers and other assistive technology can interpret it reliably.

Where public and nonprofit sites usually fall short

The Justice Department’s web accessibility guidance names the barriers it sees most: poor color contrast, color used alone to carry meaning, missing alt text, videos without captions, forms people cannot complete, and pages that only work with a mouse. In our experience with government and nonprofit sites, the same list comes up, plus documents and third-party tools. With the WCAG criterion numbers, so you can look them up:

• Images without text alternatives (1.1.1). Charts, maps, scanned flyers and buttons made of icons are the usual misses. Decorative images should be marked so screen readers skip them.
• Video and meetings without captions (1.2.2, 1.2.4). Recorded video needs captions, and so do live streams, which matters for council and board meetings broadcast online.
• Low contrast (1.4.3, 1.4.11). Body text needs a contrast ratio of at least 4.5:1 against its background; large text, 3:1. WCAG 2.1 added a 3:1 minimum for form borders, icons and other controls.
• Color as the only signal (1.4.1). “Required fields are in red” fails people who cannot see red. Add a word or a symbol.
• Keyboard traps and invisible focus (2.1.1, 2.1.2, 2.4.7). Menus, date pickers and pop-ups that cannot be reached, used or closed by keyboard, or a focus outline the design removed.
• Forms (1.3.1, 3.3.1, 3.3.2, 3.3.3). Fields need real labels, instructions up front, and error messages that name the problem and suggest a fix.
• Structure (1.3.1, 2.4.4, 2.4.6). Headings that are only bold text, and links that say “click here.” Screen reader users navigate by headings and links, so both need to make sense on their own.
• Zoom and small screens (1.4.4, 1.4.10). Text must enlarge to 200% without breaking, and content must reflow at a width of 320 CSS pixels, roughly a desktop page zoomed to 400%, without scrolling sideways.
• Documents. PDFs, Word files and slide decks you post are web content under the Title II rule. An untagged PDF of a scanned agenda fails nearly every criterion above.
• Third-party tools. Payment portals, agenda systems, calendars and maps embedded on your site count as yours, even when a vendor built them.

What WCAG 2.2 adds

WCAG 2.2 adds 9 success criteria. 6 of them are at Level A or AA:

• Focus Not Obscured, Minimum (2.4.11, AA). A sticky header or cookie banner cannot completely hide the control that has keyboard focus.
• Dragging Movements (2.5.7, AA). Anything you can drag, such as a map pin or a reorderable list, also works with a single click or tap.
• Target Size, Minimum (2.5.8, AA). Click and tap targets are at least 24 by 24 CSS pixels, or spaced so they are hard to miss.
• Consistent Help (3.2.6, A). If you offer help, such as a phone number or chat, it appears in the same place on every page.
• Redundant Entry (3.3.7, A). Don’t make people type the same information twice in one process.
• Accessible Authentication, Minimum (3.3.8, AA). Logging in cannot depend only on remembering something or solving a puzzle. Letting people paste a password or use a password manager is usually enough.

2.2 also retires one criterion, 4.1.1 Parsing, which W3C now treats as obsolete. The Title II rule requires 2.1, not 2.2, but W3C encourages using the latest version, and the 2.2 additions mostly describe good design anyway. We build to WCAG 2.2 AA, which covers everything in 2.1.

How to test

Testing takes 2 kinds of work. Automated checkers scan pages quickly and catch problems like missing alt attributes and low contrast. They cannot judge whether alt text is accurate, whether a heading describes its section, or whether a form makes sense when read aloud. W3C puts it plainly: evaluation tools can only assist, not determine, accessibility. The Justice Department adds that a “clean” report does not mean everything is accessible.

So pair the scan with checks by hand:

1. Unplug the mouse. Tab through your top tasks: pay a bill, find a meeting, submit a form. You should always see where you are, and never get stuck.
2. Zoom to 200% and 400%. Nothing should overlap, cut off or need sideways scrolling.
3. Listen to it. Turn on a screen reader (VoiceOver is built into Macs and iPhones; NVDA is free for Windows) and move through the page by headings and links.
4. Read the alt text and captions. Do they say what a sighted visitor gets from the image or video?
5. Break the forms. Leave fields empty and enter bad data. Errors should be announced and explain the fix.
6. Open the documents. Check that the PDFs people rely on are tagged and read in the right order.

For a quick first look, W3C’s Easy Checks need no special skills. For a formal audit, its WCAG-EM methodology explains how to choose a sample of pages and report results. Best of all, involve people with disabilities in testing; they will find what a checklist misses.

Then keep it up. Accessibility is not a one-time project: every new page, PDF and plugin can undo it. Build checks into each release and train the staff who post content.

Where to start

If your deadline is April 2027 or 2028, start with the services people use most and the documents they need to use them. The ADA Title II readiness checklist walks through the rest.

This article is a plain-language summary, not legal advice. Sources: W3C WCAG overview, WCAG 2.1, What’s new in WCAG 2.2, ADA.gov fact sheet on the Title II web rule.