Checklists · 55 checks
The Full WCAG 2.2 A and AA Checklist in Plain English
The complete Level A and AA list, translated out of standards language, with the six new 2.2 rules that land at these levels marked.
The Full WCAG 2.2 A and AA Checklist in Plain English
- Checks
- 55
- Time
- A full pass takes several days
- Last reviewed
- August 28, 2026
For the team that is been told to meet WCAG 2.2 AA and needs to know what that actually asks for, rule by rule.
WCAG 2.2 has 55 success criteria at Level A and AA combined. That is the standard nearly every law names, and it is the standard our own audits test against, so this list is the same one we work through.
Every one of them is below in plain language, grouped the way the standard groups them, into the four principles. Where a rule is new in 2.2 the item says so, and each links to the full explanation with the examples, the exceptions and the fixes.
One thing to know before you start, because it changes how you read the whole list. A criterion states an outcome and never a method, so passing is about what your page does rather than about which technique you used. The second thing to hold on to is that exceptions are part of the rule rather than a loophole. Most of the awkward criteria carry one.
The 20 rules under Perceivable
Perceivable is the principle about people being able to take the information in at all, by sight, by sound or by touch. Most of it comes down to two habits. Anything that is not text needs text doing the same job. Anything shown visually has to be findable in the markup too.
Give non-text content a text alternative
Images, icons, charts, and audio and video files all need text serving the same purpose they do. The rule then names six situations where the bar moves, and five of them lower it. A control takes a name saying what it does, a test question takes a label rather than an answer, and pure decoration takes the opposite treatment, which is to be marked so assistive technology skips it entirely.
WCAG 1.1.1
Provide alternatives for audio-only and video-only content
A recording with only sound needs a text version carrying the same information. A recording with only pictures needs either that text version or an audio track describing what is on screen. The text version is more than a rough transcript, because it runs in the recording's own order, names who is speaking, and notes the sounds that carry meaning.
WCAG 1.2.1
Caption pre-recorded video
Every recorded video with speech needs captions, and the test is whether somebody who cannot hear it ends up with the same thing. Automatic captions get you most of the way there. They fail on names, numbers and jargon, which is where the meaning usually sits, so read them through before you publish.
WCAG 1.2.2
Describe pre-recorded video in audio or in text
Where a video shows something that matters and never says it out loud, this level gives you a choice. Narrate the visuals in an audio description track, or write the whole thing out as a text alternative. Check first whether you owe either, because a well-scripted video whose soundtrack already carries the picture passes as it stands. The choice also decides what Level AA costs you later, since 1.2.5 accepts the audio route only.
WCAG 1.2.3
Caption live video
A live stream with speech needs captions as it happens, which is a different job from captioning a recording and usually means a human captioner or a paid service. Plan it before you schedule the event. There is no fixing a live broadcast afterwards.
WCAG 1.2.4
Add audio description to pre-recorded video
At AA the text alternative stops counting and you need the narration track itself, describing what is shown but never said. This is why the choice you made at 1.2.3 matters, because a team that wrote a transcript to clear Level A has to come back and record description to clear this one.
WCAG 1.2.5
Convey structure in markup rather than only visually
Headings, lists, tables and grouped form fields all have to be marked up as what they are, so the structure somebody can see is also the structure a screen reader can find. This is the rule behind a heading being a real heading rather than a styled div, and behind a data table having real header cells rather than a bold top row.
WCAG 1.3.1
Keep the reading order meaningful
Read the page in source order and check it still makes sense. What gets announced comes from the markup rather than from the layout, so a flex or grid rule that moves a column across the screen leaves the original order behind for anybody listening to it.
WCAG 1.3.2
Do not rely on shape, size or position alone in instructions
"Click the button on the right" works only for somebody who can see the layout. What the rule bars is sole reliance rather than the cue itself, so keep the position and add the name. "Choose one of the links below" is fine, because the reading order makes it unambiguous.
WCAG 1.3.3
Work in both portrait and landscape
Most sites pass this by doing nothing, since a page that does not restrict orientation simply takes whatever the device is set to. Locking one is allowed only where that orientation is essential, and essential has two halves that both have to hold. Removing the lock would change what the content fundamentally is, and the same thing could not be delivered another way.
WCAG 1.3.4
Identify the purpose of common input fields
Name, email, address and phone fields need the right autocomplete token, which lets a browser or password manager fill them for somebody who finds typing slow or painful. The scope is the person filling the form in, so a gift recipient's address or a referee's email sits outside the rule and needs nothing.
WCAG 1.3.5
Do not carry meaning by color alone
Turn the page grayscale and look for anything that has just become ambiguous. Required fields, error states, chart series and links inside paragraphs are the usual four. Pair the color with a word, an icon, an underline or a pattern, and then the color can stay exactly as it is.
WCAG 1.4.1
Let people stop audio that plays by itself
Any audio starting on its own and running past three seconds needs either a pause or stop control, or its own volume control that works independently of the system volume, because turning the computer down turns the screen reader down with it. This one binds the whole page rather than a component, so an autoplaying widget in your sidebar is your problem whether or not you wrote it.
WCAG 1.4.2
Meet 4.5 to 1 contrast on text
Measure the pairs rather than judging them, and give large text the lower bar of 3 to 1. Large is defined in points, at 18 point or 14 point bold, which converts to 24px and 18.66px. Text in a logo has no contrast requirement at all, and neither does text in a disabled control. A short measurement is not automatically a finding.
WCAG 1.4.3
Support 200% text resize
Enlarge the text to twice its size using nothing but the browser and confirm that no content and no function is lost. Most sites pass by default, because full-page zoom is a working mechanism and one is enough. What breaks it is usually one line of boilerplate. A viewport meta tag carrying user-scalable=no blocks pinch-zoom on a phone outright.
WCAG 1.4.4
Use real text instead of images of text
Real text zooms, reflows, recolors and translates, and a picture of text does none of it. Two exceptions are written in. A logo or brand name counts as essential, and so does any presentation the technology genuinely cannot produce. There is also a route that is not an exception at all, which is publishing the same words as real text alongside the image.
WCAG 1.4.5
Reflow without two-way scrolling at 400% zoom
Zoom to 400% and look along the bottom for a horizontal scrollbar. The condition is no loss of content and no scrolling in two directions at 320 CSS pixels wide, which is the width a phone gives you. One column is one way of getting there and the rule never asks for it, so a layout that still fits in two columns passes.
WCAG 1.4.10
Meet 3 to 1 contrast on interface parts
Buttons, input borders, icons and focus indicators each need 3 to 1 against whatever sits next to them. This is a separate rule from text contrast and it gets missed far more often, because a team that measures its body copy carefully will still ship a pale gray input border nobody can find.
WCAG 1.4.11
Survive user text-spacing overrides
Set line height to 1.5 times the font size, spacing after paragraphs to twice it, letter spacing to 0.12 times and word spacing to 0.16 times, change nothing else, and check that nothing is lost. You never have to ship those values. You have to survive them. People with dyslexia apply them routinely, and anything with a fixed height around text is where it breaks.
WCAG 1.4.12
Make hover and focus content dismissible, hoverable and persistent
Three conditions, and all three have to hold. It has to be dismissible without moving the pointer or the focus, which usually means Escape. It has to stay put while the pointer travels onto it. And it has to persist until the user moves away from both, dismisses it, or its information stops being true. A plain title attribute tooltip is outside this rule entirely, because the browser draws it.
WCAG 1.4.13
The 20 rules under Operable
Operable is the principle about people being able to drive the thing, whatever they are driving it with. Keyboard, switch, voice, a finger on a small screen. Half of these turn up in two minutes with the mouse unplugged. Test this group first.
Make everything keyboard operable
Every function on the page has to be available without a mouse, so Tab through the whole thing and try to use each control you land on. This is the rule underneath switch access and much of voice control too, because both send keystrokes underneath, which means a keyboard failure strands three groups at once rather than one.
WCAG 2.1.1
Trap focus nowhere
Anything you can Tab into, you have to be able to get out of with the keyboard alone. A component needing Escape or some other key still conforms, as long as it tells the user which key, so look for that instruction before you write it up. There is no mouse to rescue anybody. That makes it the worst keyboard failure of the set.
WCAG 2.1.2
Let people remap or turn off single-key shortcuts
If a single printable character fires an action, one of three things has to be true. The user can turn it off, they can remap it to include Ctrl or Alt, or it only works while its own component has focus. Printable reaches further than letters, so the near-universal slash for search and question mark for help both sit inside this rule.
WCAG 2.1.4
Let people adjust or turn off time limits
Six things satisfy this and any one is enough. Three you build, which are letting the user turn the limit off, letting them stretch it to ten times the default, or warning them with at least 20 seconds and a simple way to extend, then letting them extend at least ten times. Three are exceptions needing nothing, which are a real-time event such as an auction, a limit that extending would invalidate, and any limit longer than 20 hours.
WCAG 2.2.1
Let people pause, stop or hide moving content
Motion that starts on its own, runs past five seconds and sits alongside other content needs a pause, stop or hide control. Content that updates itself on a timer needs one however briefly it runs, because the five-second allowance belongs to the moving half only. A full-screen loading animation with nothing beside it is outside the rule.
WCAG 2.2.2
Keep flashing to three times a second or fewer
Nothing may flash more than three times in one second, and this is the one criterion whose failure can put somebody in hospital, so the numbers matter more here than anywhere else on the page. Past three flashes there are two routes back under the limit. Keep the flashing area small, meaning no more than a quarter of a ten-degree slice of the viewer's visual field. Or keep the change in brightness below the defined threshold. The area is the part people get wrong, because the rectangle usually quoted, 341 by 256 pixels at a 1024 by 768 rendering, is the whole ten-degree field rather than the share of it allowed to flash. A quarter of that is roughly 21,800 pixels. The estimate also rests on an assumed screen size and viewing distance, so treat it as an estimate rather than a licence.
WCAG 2.3.1
Provide a way to skip repeated blocks
A mechanism has to exist for getting past the navigation and header that repeat on every page, and that mechanism takes more than one shape. A skip link is one. Landmark regions are another, a heading on the main content is another, and a navigation menu that collapses is another. Repeated blocks means real blocks, so a "Read more" link recurring down a listing page is not one.
WCAG 2.4.1
Give every page a descriptive title
The title is the first thing announced on arrival and the only thing telling one of your tabs from another, so it has to name the page and then the site. Twelve pages called "Services" help nobody. In a single-page app this needs code, because changing the route does not change the title on its own.
WCAG 2.4.2
Keep focus order logical
Tab through and check that focus preserves meaning and operability, which usually means following the way the page reads. A positive tabindex value is one cause of a mismatch and the less common one now. The commoner cause is CSS, because reordering flex or grid items moves things visually and leaves the tab order following the source.
WCAG 2.4.3
Make link purpose clear from the link text and its context
The purpose has to be clear from the link's own words, or from those words plus the context the code puts them in. That context is a closed list, meaning the sentence, the paragraph, the list item, the table cell or its header cell. So eleven "read more" links each sitting in their own card do conform, and text merely sitting nearby in a different container does not count.
WCAG 2.4.4
Offer more than one way to find a page
Two routes is the bar and W3C documents six of them, including links between related pages, a table of contents, a site map, a search function and a home page linking everything. Most sites already have the first without trying, so the usual failure is being one short. A page that is a step in a process is outside the rule entirely, which takes your checkout and your order confirmation out with it.
WCAG 2.4.5
Write headings and labels that describe what follows
This rule says nothing about markup and everything about words. "Field 3" is a label that labels nothing, and a perfectly coded heading reading "Section 4" fails here while passing 1.3.1. Length is not the test either, because a single word is enough when it tells somebody what they will find.
WCAG 2.4.6
Keep the focus indicator visible
There has to be a mode of operation where the ring shows, which is what lets a focus-visible style conform even though it hides the ring for mouse clicks. Two things this rule does not do. It sets no contrast ratio and no size, so a barely visible ring passes it and fails the non-text contrast rule instead. And once shown the ring has to stay, so one that fades after a second fails.
WCAG 2.4.7
Do not obscure the focused element entirely
New in 2.2. Tab down a long page and watch for focus disappearing under a sticky header or a cookie bar. At AA the test is whether any part of the focused control still shows, so covering it partly passes here deliberately and fails 2.4.12 at AAA. Scroll padding on the scrolling container is the usual fix.
WCAG 2.4.11
Give path-based and multi-finger gestures a simple alternative
Anything needing two pointers at once, or a route that has to be traced, needs a single-pointer alternative that does not depend on the path. A tap, a click, a double tap or a long press all qualify, so it does not have to be a button. Signing your name is the standard's own example of a gesture that is genuinely essential and therefore exempt.
WCAG 2.5.1
Let a mistaken press be cancelled
For anything driven by a single pointer, one of four things has to hold. The down-press does nothing, or the action completes on release with a way to abort or undo it, or the release reverses what the press did, or completing on the press is essential. That third branch is why press-and-hold previews are fine, since letting go already cancels them.
WCAG 2.5.2
Include the visible label in the accessible name
Voice control users activate what they can see by saying it, so a button reading "Search" whose name is "Submit query" cannot be operated by saying "click Search". Capitalization and most punctuation are ignored, and text used as a symbol is not a label at all, which is why the B on a bold button should be named Bold.
WCAG 2.5.3
Provide alternatives to device motion, and let it be switched off
Two things are required together here rather than one. Anything a device movement or a body gesture triggers also has to be reachable from ordinary controls, and the response to motion has to be switchable off so nobody fires it by accident. Somebody with a tremor, or holding a phone in a moving car, needs the second half as much as the first.
WCAG 2.5.4
Give dragging actions a single-pointer alternative
New in 2.2. Anything achieved by dragging has to be achievable with a pointer that does not drag, which usually means adding buttons beside a reorderable list. The route between the two ends is irrelevant here, and that is the whole difference from the gestures rule, where the path is the point. Browser scrolling you have not modified is out of scope.
WCAG 2.5.7
Size targets at 24 by 24 pixels, or space them out
New in 2.2, and the spacing route is the one most designs take. An undersized target passes if a 24 CSS pixel circle centered on its bounding box intersects neither another target nor the circle around another undersized target. Both conditions, which is why two 4 pixel targets sitting 16 pixels apart still fail. Four exceptions take a target out of scope: an equivalent control elsewhere on the page, a target inline in a sentence, a size the browser controls and the author has not changed, and a size essential to the information being conveyed.
WCAG 2.5.8
The 13 rules under Understandable
Understandable is the principle about people being able to follow what is in front of them and predict what happens next. Six of these 13 sit under Input Assistance, which is the forms guideline. That is fair, because a form is where a page asks somebody to commit to something.
Set the page language
One attribute on the html element tells a screen reader which language the page is in, and its software uses that to pick a voice and a set of pronunciation rules. Get it wrong and English can come back through a French synthesizer. How bad that gets depends on the language pair and the software, and it ranges from odd to unusable.
WCAG 3.1.1
Mark language changes inside the page
A passage that switches language needs its own lang attribute, so the screen reader switches pronunciation for it and switches back afterwards. A single word counts. Four things are excepted, and between them they cover most of what looks like a failure. Proper names, technical terms, words of indeterminate language, and borrowed words that have settled into the surrounding language.
WCAG 3.1.2
Change nothing unexpectedly on focus
Tabbing onto a control must never open a window, submit a form, or throw focus somewhere else. Context is narrower than it sounds, so a tooltip appearing on focus is fine and a submenu opening on focus is fine. Unlike its sibling rule about input, this one has no escape, and warning the user in advance does not rescue it.
WCAG 3.2.1
Change nothing unexpectedly on input
Changing a setting must not change the context by itself unless you said it would beforehand. A setting means something that sticks after you stop interacting, so ticking a box or picking from a list counts and pressing a button does not. The warning has to arrive before the control is used and beside it, never as a message afterwards.
WCAG 3.2.2
Keep navigation consistent across pages
Anything helping people move around your site has to keep the same relative order on every page that repeats it, and that covers more than the main menu. A search field, a skip link and a breadcrumb trail are all navigational. Relative order is forgiving, so adding and removing items is fine and reshuffling what was already there is not.
WCAG 3.2.3
Identify the same function the same way everywhere
A control that adds an item to the cart cannot be "Add to cart" on one page and "Buy" on another. Consistency is the test rather than being identical, so "Print receipt" and "Print invoice" are consistent because the functions differ. Identification means the accessible name as much as the visible label, which is why two identical-looking buttons with different aria-label values fail a check a visual review would pass.
WCAG 3.2.4
Keep help in the same place on every page
New in 2.2, and conditional. If a page carries help and that help repeats across a set of pages, it has to sit in the same place in the reading order every time. Help means contact details, a way to reach a human, a self-help option such as an FAQ, or a chatbot. The rule never requires you to offer help at all, so a page without it does not fail.
WCAG 3.2.6
Identify errors in text
When a form rejects something, the page has to say which field is wrong and what is wrong with it, in words. A red border is not text and carries nothing for a blind reader. Two limits are worth having. It only bites where your code detected the error, and it says nothing about where the message is shown, so inline or at the top of the form are equally acceptable.
WCAG 3.3.1
Label fields and state the format up front
Every field that takes input needs a label or an instruction, and the rule means every field rather than only the required ones. A placeholder does not count on its own, because it disappears the moment somebody types. Format requirements belong here too, so if a password needs 12 characters, say so before somebody picks one rather than after.
WCAG 3.3.2
Suggest a correction when your code knows one
"Invalid date" is a verdict. "Enter the date as month, then day, then a four-digit year" is a suggestion, and only one of those lets somebody finish. Two conditions have to hold before the rule applies, which are that your code detected the error and that a correction is actually knowable. One exception lifts it, where telling the user would give away something the content depends on keeping, which is why a login may say only that the username or password was wrong.
WCAG 3.3.3
Let people check or reverse a consequential submission
Four kinds of page are in scope, meaning anything creating a legal commitment, running a financial transaction, changing or deleting the user's own data, or submitting test answers. Any one of three safeguards satisfies it. The submission is reversible, the data is checked with a chance to correct it, or a review step lets them confirm before it commits. The scope attaches to the page, so a single delete button brings the whole page in.
WCAG 3.3.4
Do not make people re-enter information
New in 2.2. Inside one process you cannot ask for the same thing twice, so either fill it in for them or put the earlier answer somewhere on the page where they can pick it up. It covers what you gave them as well as what they gave you, so a reference number you issued counts. Confirming a new password is explicitly allowed, because that re-entry is what keeps it secure.
WCAG 3.3.7
Do not require a cognitive test to log in
New in 2.2. No step of signing in may require somebody to remember, manipulate or transcribe information, which puts passwords, puzzles and copying a code by hand all inside the rule. Four things lift it and any one is enough. Another sign-in method that skips the test. A mechanism helping the user through it, which the standard says includes password manager support and copy and paste. A test that only asks somebody to recognise objects. Or one that asks them to identify content they gave the site themselves. The first two carry the practical weight, and the last two are why a pick-the-traffic-lights challenge clears this rule at AA and not at the enhanced level. Every step has to clear it.
WCAG 3.3.8
The 2 rules under Robust
Robust is the shortest principle at these levels. It is also the one your custom components live or die by. Both rules are about the same thing, which is whether the page tells assistive technology what is going on rather than only showing it.
Give every component a name, role and value
Every control has to say what it is called, what kind of control it is, and what state it is in. There is a fourth part the short version drops, which is that a value the user can set has to be settable from outside rather than only readable, and any change to it has to fire a notification. Native HTML hands you the role and the state for free. It never hands you a name, and a div hands you none of the four.
WCAG 4.1.2
Announce status messages without moving focus
"Added to cart", "3 results found", "Saving". Visually those land as a toast or a changed number, and for a screen reader user they are silence unless the text sits in a live region that was already in the page before the message arrived. Adding the region and the message together announces nothing, which is the single commonest way this rule is failed by people who were trying to pass it.
WCAG 4.1.3
One honest limit
A checklist tells you what to check and never whether you got it right. Twenty-four of these 55 rules have no published automated test rule behind them at all, and 37 have none that W3C has approved. That leaves a person to judge whether the alt text is true, whether the heading describes its section, and whether the error message actually helps. Even where a rule does exist, a pass is weaker than it sounds. On 59 of the 87 live test rules a pass means only that the criterion still needs further testing, and exactly four clear a criterion outright. Ticking a box is not the same as passing.
Keep going
Other checklists
Ticked every box and want it verified?
The full audit tests all 55 WCAG 2.2 A and AA rules with a pass or fail on each, adds an expert review, and puts a real blind screen-reader user on your key journeys. $499, report in 5 business days.