WCAG 2.2 Level A Explained for Testers: The Complete Checklist
Thirty-one criteria. Not thirty-two. Here's all of them, what breaks, and how you verify each one by hand.
WCAG 2.2 has 31 Level A success criteria. Level A is the floor: the failures that lock people out entirely, rather than the ones that merely make things hard. Two of the 31 are new in 2.2 — 3.2.6 Consistent Help and 3.3.7 Redundant Entry — and one that used to be Level A, 4.1.1 Parsing, has been removed as obsolete. The standard is a W3C Recommendation, published 5 October 2023 and updated 12 December 2024.
If you've been handed accessibility and told to check that "we're compliant", this page is the thing to work through. Not the spec itself; the spec is written for people who write specs. Every Level A criterion below gets three things: what it requires, what a failure looks like in an actual product, and the fastest way to check it. Most of them need a browser and your keyboard and nothing else.
One thing to settle before the list. Level A is not a score you get a percentage on. It's a pass/fail line, and you fail it by missing one criterion on one page.
Why do the checklists disagree on the number?
Go looking for a WCAG 2.2 Level A checklist and most of them will tell you 32. I'm telling you 31. Worth thirty seconds, because the reason is also a warning about the sources you're about to be buried in.
The extra one is 4.1.1 Parsing. Level A in WCAG 2.0 and 2.1; in WCAG 2.2 it is, in the spec's own words, "obsolete and removed". Browsers got good enough at recovering from broken markup that the criterion stopped tracking real user harm. Count it and you get 32. Read the current standard and you get 31.
A checklist that says 32 was built against 2.1 and had the two new criteria bolted on without anyone re-reading Principle 4. Which tells you how carefully the rest of it was assembled.
A checklist you haven't checked against the spec is somebody else's homework — and you're the one signing it.
One practical caveat, and this is the bit that matters on a contract. The W3C says authors required by policy to conform to WCAG 2.0 or 2.1 "may need to continue to test and report 4.1.1." So if your acceptance criteria name 2.1, parsing is still yours regardless of what 2.2 did with it. Check which version you're being held to before you drop anything.
What does "Level A" actually mean?
Three things testers get wrong about it.
It's per page, and it's all-or-nothing. Conformance is claimed for full pages and for complete processes. So if step 4 of your checkout fails 3.3.7, the whole checkout doesn't conform, however clean steps 1 through 3 are. No partial credit, no percentage, nothing to put on a dashboard.
Level A alone is almost never the target. It's the minimum WCAG defines. The level most laws and contracts actually reference is AA. Testing Level A first is a sequencing decision rather than a scope decision — it's where the worst barriers live, so it's where the first pass pays best. Then you go up. [TODO: internal link → EAA for QA teams]
Passing isn't the same as usable. Every criterion below can be technically satisfied by something nobody can operate. A field can carry a programmatic label reading field_2. That's 3.3.2 satisfied and a user stuck. The criteria are a floor under judgment, not a replacement for it.
The complete WCAG 2.2 Level A checklist
Grouped by the four principles — Perceivable, Operable, Understandable, Robust. Work through them in this order the first time; after that, use the pass order further down, which is faster.
Perceivable — 9 criteria
| Criterion | What it requires | What a failure looks like | How to check it |
|---|---|---|---|
| 1.1.1 Non-text Content | Every image, icon and control has a text alternative serving the same purpose | A chart with alt="chart"; an icon-only button with no accessible name; a decorative divider announced as "image spacer-2" |
Cover the image. Would the alt text do the same job in its place? Decorative images take alt="" |
| 1.2.1 Audio-only / Video-only (Prerecorded) | Transcript for audio-only; transcript or audio track for silent video | A podcast episode or a soundless explainer GIF with no text equivalent | Inventory every media file. Is there a text equivalent, and is it linked next to the media? |
| 1.2.2 Captions (Prerecorded) | Captions for prerecorded video with sound | No captions, or auto-generated captions that mangle every product name | Turn captions on and read along with the audio for one minute |
| 1.2.3 Audio Description or Media Alternative | Prerecorded video needs audio description or a full text alternative | A demo where the narrator says "and click here" while the click only happens on screen | Close your eyes and listen to the whole thing. Did you lose information? |
| 1.3.1 Info and Relationships | Structure you can see is also in the markup | Headings faked with bold divs; layout tables; a required field marked only by a red asterisk in a span |
Run a heading-outline view. Check tables for th and scope. Check labels are real label elements |
| 1.3.2 Meaningful Sequence | DOM reading order matches intended reading order | CSS grid or flex order rearranges columns visually; the DOM reads as nonsense |
Disable CSS, or read the DOM top to bottom, and see if it still makes sense |
| 1.3.3 Sensory Characteristics | Instructions don't rely only on shape, colour, size, position, orientation or sound | "Click the round button on the right"; "see the box below" | Search the copy for above, below, left, right, the green one, the round icon |
| 1.4.1 Use of Color | Colour is never the only way information is conveyed | Errors shown by a red border alone; in-paragraph links distinguished only by hue; a chart legend keyed only by colour | Put the page in greyscale. What information just disappeared? |
| 1.4.2 Audio Control | Audio playing automatically for over 3 seconds must be pausable, stoppable, or independently controllable | Autoplaying hero video with sound and no visible control | Load the page with your volume up. Can you stop it without leaving? |
Operable — 14 criteria
| Criterion | What it requires | What a failure looks like | How to check it |
|---|---|---|---|
| 2.1.1 Keyboard | All functionality operable by keyboard | A custom dropdown that only opens on click; drag-only reordering with no keyboard path | Push the mouse out of reach. Complete the whole journey on Tab, Shift+Tab, Enter, Space, arrows |
| 2.1.2 No Keyboard Trap | If keyboard focus can enter a component, it can leave | A modal you can Tab into but not out of; an embedded player that swallows Tab | Tab all the way around the page and back into the browser chrome |
| 2.1.4 Character Key Shortcuts | Single-character shortcuts must be turnable off, remappable, or active only on focus | Pressing "s" anywhere opens search — which speech-input users trigger constantly by accident | With nothing focused, type a normal sentence into the page. Watch what fires |
| 2.2.1 Timing Adjustable | Time limits can be turned off, adjusted, or extended | A 15-minute session timeout with no warning and no "give me more time" | Find every timer: session, OTP, booking hold, checkout reservation |
| 2.2.2 Pause, Stop, Hide | Content that moves, blinks, scrolls or auto-updates for more than 5 seconds alongside other content needs a pause/stop/hide | Auto-rotating hero carousel with no pause control; a live ticker you can't freeze | Find anything that moves on its own. Try to stop it |
| 2.3.1 Three Flashes or Below Threshold | Nothing flashes more than three times per second | A strobing loader; a hard-cut video sequence | Rare, but review animations and any video you ship |
| 2.4.1 Bypass Blocks | A way to skip content repeated across pages | 40 nav links before the main content on every page, no skip link | Load the page, press Tab once. Does a skip link appear — and does it actually move focus? |
| 2.4.2 Page Titled | Page titles describe topic or purpose | Every route in the SPA titled "React App"; three pages all called "Home" | Click through the app watching the browser tab. Single-page apps fail this constantly |
| 2.4.3 Focus Order | Focus order preserves meaning and operability | Opening a modal leaves focus behind it; Tab jumps header → footer → back up | Tab through slowly and narrate where you are. Does the order match the reading order? |
| 2.4.4 Link Purpose (In Context) | Each link's purpose is clear from its text, or its immediate context | Eight "Read more" links on one page with nothing to tell them apart | Pull up a links list and read them with no surrounding page. Can you tell them apart? [TODO: internal link → "Read more" links and aria-label] |
| 2.5.1 Pointer Gestures | Multipoint and path-based gestures need a single-pointer alternative | A slider that only responds to drag; a map that only zooms on pinch | Try to operate everything with single clicks or taps only |
| 2.5.2 Pointer Cancellation | Single-pointer functions shouldn't fire on down-event, or must be abortable | A button that activates on mousedown, so sliding off doesn't cancel it |
Press down on a control, drag away, release. Did it fire anyway? |
| 2.5.3 Label in Name | The accessible name contains the visible label text | Button reads "Send", aria-label says "Submit form" — a voice user says "click Send" and nothing happens |
Compare visible text against the accessible name in the accessibility tree. This one is aria-label's favourite trap |
| 2.5.4 Motion Actuation | Motion-triggered functions need a UI equivalent and must be disableable | Shake-to-undo with no undo button | Any feature driven by tilting or shaking also needs a control you can press |
Understandable — 7 criteria
| Criterion | What it requires | What a failure looks like | How to check it |
|---|---|---|---|
| 3.1.1 Language of Page | "The default human language of each web page can be programmatically determined" | Missing lang; or lang="en" on a Hungarian page, so the screen reader reads Hungarian with English phonetics |
View source, look at <html lang>. Ten seconds, and it's wrong more often than you'd think |
| 3.2.1 On Focus | Receiving focus doesn't change context | Tabbing into a select immediately navigates away | Tab through every control without activating anything. Did the page move under you? |
| 3.2.2 On Input | Changing a setting doesn't change context unless the user was warned first | Picking a country reloads the page and dumps focus back at the top | Change each form control by keyboard and watch what happens |
| 3.2.6 Consistent Help (new in 2.2) | Repeated help mechanisms appear in the same order relative to other page content | Chat widget bottom-right on the product page, buried in the footer at checkout | Note where help lives on four pages, then compare their position in the page order |
| 3.3.1 Error Identification | Automatically detected errors are identified and described in text | Red borders and nothing else; "Error 422"; a summary that says "please fix the errors" | Submit a form with bad data. Is the problem described in words a person can act on? |
| 3.3.2 Labels or Instructions | Labels or instructions are provided where input is required | Placeholder-as-label that vanishes when you type; password rules revealed only after you fail them | Click each visible label. Did focus jump into the field? If not, it isn't connected |
| 3.3.7 Redundant Entry (new in 2.2) | Info already entered in the same process is auto-populated or selectable | A checkout that makes you retype the shipping address as the billing address, with no "same as" option | Run a multi-step process end to end and count how many times you retype something |
Robust — 1 criterion
| Criterion | What it requires | What a failure looks like | How to check it |
|---|---|---|---|
| 4.1.2 Name, Role, Value | Every UI component exposes its name and role; states and values are programmatically set and changes are announced | A div with an onclick acting as a button; a custom toggle with no aria-pressed; a dialog with no role |
Open the accessibility tree and inspect every custom component. If it isn't native HTML, check it here |
One Level A criterion in the whole of Robust, and it's the one that breaks most design systems. Native HTML elements pass 4.1.2 for free. Everything hand-rolled has to earn it.
Which of these can a tool check for me?
Some. Not most, and not the ones that hurt.
A scanner reliably catches the mechanical end of this list — missing alt attributes, missing lang, missing form labels, absent page titles, some ARIA misuse. Parts of 1.1.1, 3.1.1, 3.3.2, 2.4.2 and 4.1.2. Run one. It's free and it takes seconds, and there's no reason not to.
Then look at what's left. Whether the alt text means anything (1.1.1). Whether the Tab order makes sense (2.4.3). Whether "Read more" is distinguishable from the seven other "Read more"s (2.4.4). Whether an error message tells you what to do (3.3.1). Whether help sits in the same place across a journey (3.2.6). Whether a process makes you retype your own address (3.3.7). Every one of those is a judgment call, and a judgment call needs a person.
A clean automated report means "none of the machine-checkable things are broken." On this list, that's the minority of the work. I've written up the split in more detail in manual vs automated accessibility testing. For a criterion-by-criterion breakdown of what one specific tool catches: [TODO: internal link → What axe-core actually catches]
What order should I test these in?
Criterion order is how the spec is organised. It's a miserable order to test in, because it sends you back over the same page six times. Test by pass instead: one interaction mode, one sweep, several criteria closed at once.
- Keyboard pass. Mouse out of reach. Tab the whole journey. Closes 2.1.1, 2.1.2, 2.4.1, 2.4.3 and 3.2.1 — and you'll spot AA's focus-visible problems (2.4.7) on the way past, free. Highest-yield twenty minutes in accessibility testing.
- Structure pass. Heading outline, landmarks, DOM order, page titles. Closes 1.3.1, 1.3.2, 2.4.2.
- Forms pass. Every input: label connected, instructions present, errors in text, nothing retyped. Closes 3.3.1, 3.3.2, 3.3.7, 3.2.2.
- Vision pass. Greyscale the page, then read the copy for directional language. Closes 1.4.1, 1.3.3.
- Component pass. Accessibility tree on every custom widget, visible label against accessible name. Closes 4.1.2, 2.5.3.
- Media and motion pass. Captions, transcripts, autoplay, carousels, flashing, gestures, device motion. Closes the 1.2.x set, 1.4.2, 2.2.1, 2.2.2, 2.3.1, 2.5.1, 2.5.2, 2.5.4.
- Cross-page pass. Help position and skip links across four or five pages. Closes 3.2.6, confirms 2.4.1.
Seven passes and Level A on a page is genuinely finished. Not "scanned" — finished, by someone who can defend every line of it to a developer.
Never done any of this? Run pass 1 and stop there: how to start accessibility testing walks it through with no tooling at all. Come back for the other six. [TODO: internal link → Screen reader walkthrough]
Quick FAQ
How many Level A criteria are in WCAG 2.2? 31. Anything saying 32 is still counting 4.1.1 Parsing, which 2.2 removed as obsolete.
Is Level A enough to be compliant? Almost certainly not. Most legislation and procurement contracts reference Level AA. Level A is where you start, not where you stop.
Do I need a screen reader for this list? Not for a first pass. The checks above are keyboard, browser and accessibility-tree work. Verifying 1.1.1 and 4.1.2 properly does eventually mean listening to what assistive tech announces, but that's a separate skill and a separate afternoon.
What about 4.1.1 Parsing? Removed in 2.2. Still testable and reportable if your contract names WCAG 2.0 or 2.1. Check which version you're being held to before you drop it.
How long does a full Level A pass take? One page, seven passes, done carefully: half a day the first time, an hour once the passes are habit. Considerably longer if you're testing a single-page app that fails 2.4.2 on every route. Most of them do.
Get the checklist
The tables above are the working version of the WCAG 2.2 Level A Tester Checklist. Same 31 criteria, laid out as a printable pass-order sheet. Carry it into a session and tick off as you go. [TODO: capture link → WCAG 2.2 Level A Tester Checklist download]
What no sheet gives you is the judgment. Reading a custom component the way assistive tech reads it. Deciding whether a label is the right label. Holding a finding steady in front of a developer who says the scanner is green. That's what the Pearly Quality accessibility workshop is built around. Small group, live, hands on your own product.
Every criterion, level and quoted phrase on this page was checked against WCAG 2.2 (W3C Recommendation, 5 October 2023, updated 12 December 2024) and the W3C Understanding WCAG 2.2 documents. If you find a discrepancy, the spec wins — tell me and I'll fix the page.