WCAG 2.2 Checklist: The New Criteria in Plain Language
WCAG 2.2 adds nine success criteria and removes one. A plain-language checklist for business sites, and what an automated scan can and cannot catch.
Our content is written and reviewed by the Four Cents team. We may recommend our own services. Read our editorial standards.
On this page
This guide explains each new criterion in plain language, with where it fails on real business sites and how to fix it. Then it gives a working checklist for the whole of WCAG 2.2 AA, marked with what an automated scan can catch and what needs a person. The criteria list comes directly from the W3C.
What is new in WCAG 2.2
WCAG 2.2 became a W3C Recommendation on 5 October 2023, and the current edition of the specification is dated 12 December 2024 (W3C). It keeps everything from WCAG 2.1 except one criterion, and adds nine new ones. Here is the full list from the W3C's own summary (What's New in WCAG 2.2).
| Criterion | Level | In plain language |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | When something gets keyboard focus, it is not completely hidden behind something else you put on the page |
| 2.4.12 Focus Not Obscured (Enhanced) | AAA | The focused item is fully visible, not even partly covered |
| 2.4.13 Focus Appearance | AAA | The focus indicator is large enough and has enough contrast |
| 2.5.7 Dragging Movements | AA | Anything you can do by dragging can also be done with a simple click or tap |
| 2.5.8 Target Size (Minimum) | AA | Click and tap targets are at least 24 by 24 CSS pixels, or have enough space around them |
| 3.2.6 Consistent Help | A | If help (phone, chat, contact link, FAQ) appears on several pages, it is in the same place each time |
| 3.3.7 Redundant Entry | A | Do not make people type the same information twice in the same process |
| 3.3.8 Accessible Authentication (Minimum) | AA | Logging in does not require remembering, transcribing or solving something, unless there is an alternative or help |
| 3.3.9 Accessible Authentication (Enhanced) | AAA | Same as above, without the exceptions for recognizing objects or your own images |
Removed: 4.1.1 Parsing. W3C describes it as obsolete, because modern browsers and assistive technology no longer depend on the markup issues it checked for.
Which ones a business site must meet
Most laws, contracts and settlements aim at Level AA, which includes Level A. So the six new criteria that matter for a typical business website are 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 and 3.3.8. The three AAA criteria are good practice but rarely required.
WCAG 2.2 is backward compatible: a site that meets 2.2 AA also meets 2.1 AA, apart from the removed Parsing criterion, which no longer needs testing. That is why we build new sites to 2.2 AA even when a rule, such as the US ADA Title II web rule, names 2.1. In Europe, the updated harmonised standard EN 301 549 V4.1.1, adopted in August 2026, aligns its web requirements with WCAG 2.2 (ETSI).
2.4.11 Focus Not Obscured: sticky headers and banners
When a keyboard user tabs to a link or button, at least part of it has to stay visible. The usual failure is a sticky header, a sticky "book now" bar, a chat widget or a cookie banner that sits on top of the focused element.
How to check: Load the page, press Tab repeatedly, and watch. If the focus disappears under a fixed header, footer bar or banner at any point, you fail.
How to fix: Add scroll-padding-top (and bottom) in CSS equal to the height of sticky bars, so the browser scrolls focused items into clear view. Make cookie banners either non-overlapping or dismissible before the user tabs into the page.
2.5.7 Dragging Movements: sliders, carousels and maps
If something works by dragging, there must also be a single-pointer way to do it, such as a click or tap, unless dragging is essential. People with tremors, limited dexterity, or who use a head pointer or voice control often cannot drag reliably.
Where this shows up on business sites: price range sliders on store filters, before-and-after image sliders, drag-to-reorder lists, drag-and-drop file upload, carousels that only respond to swipes, and maps you can only move by dragging.
How to fix: Add buttons or inputs alongside the drag action: plus and minus buttons or number fields for price sliders, previous and next buttons on carousels, a "choose file" button next to the drop zone, and up and down buttons for reordering.
2.5.8 Target Size: 24 by 24 pixels
Click and tap targets must be at least 24 by 24 CSS pixels, with exceptions. The main exception is spacing: a smaller target passes if a 24 pixel circle centered on it does not touch another target or another small target's circle. Links inside a sentence of text are also excepted (WCAG 2.2, 2.5.8).
Common failures: tiny social icons packed together in the footer, the "x" to close a pop-up, quantity plus and minus buttons in a cart, pagination numbers, and small icons in a mobile menu.
How to fix: Increase padding so the clickable area is at least 24 by 24 even if the icon looks smaller, or add spacing between targets. For important controls, aim higher than the minimum; bigger targets help everyone on a phone.
3.2.6 Consistent Help
If you offer help on multiple pages, such as a phone number, a contact link, a chat button or a FAQ link, keep it in the same relative order on each page. People who rely on finding help in a predictable place should not have to hunt for it.
This criterion does not require you to offer help. It requires consistency when you do. Most sites pass by default because help sits in a shared header or footer. Failures tend to come from landing pages and checkout templates that move or drop the help link.
3.3.7 Redundant Entry: checkouts and multi-step forms
Within one process, information the user already entered must be filled in automatically or available to select, not typed again. Exceptions cover security (such as confirming a new password), information that is no longer valid, and cases where re-entering is essential.
Common failures: a checkout that asks for the billing address after the shipping address with no "same as shipping" option, a multi-step quote form that asks for the email again on step three, and appointment booking that asks for the name twice.
How to fix: Add "same as shipping" checkboxes, carry values forward between steps, and show earlier answers for the user to select. This usually improves conversion too.
3.3.8 Accessible Authentication: logins and CAPTCHA
No step of logging in should rely on a "cognitive function test", such as remembering a password or solving a puzzle, unless you provide an alternative, a mechanism that helps, or the test is recognizing objects or the user's own content (WCAG 2.2, 3.3.8).
In practice, a normal password login passes as long as people can use a password manager or paste their password, because that is a mechanism that helps. What fails:
- Blocking paste in password or one-time code fields
- Splitting a verification code into separate boxes that break paste or autofill
- Puzzle or text-transcription CAPTCHAs with no alternative
- Asking the user to type characters 3, 5 and 8 of a memorable word
How to fix: Allow paste and autofill (use correct autocomplete values), offer email magic links or passkeys, and replace puzzle CAPTCHAs with options that do not test memory or transcription.
The full checklist for business websites
WCAG 2.2 AA has 55 success criteria at Levels A and AA. You do not need to memorize them. The checklist below groups the ones that most often matter on business sites, including the new 2.2 criteria, with whether an automated scan can reliably catch each one.
| Check | WCAG | Automated scan? |
|---|---|---|
| Every informative image has accurate alt text; decorative images have empty alt | 1.1.1 | Partly: finds missing alt, cannot judge accuracy |
| Videos have captions; audio has a transcript | 1.2.2, 1.2.1 | No |
| Headings, lists and tables are marked up as such | 1.3.1 | Partly |
| Form fields have labels tied to them in code | 1.3.1, 3.3.2 | Yes |
| Form fields use correct autocomplete values for personal data | 1.3.5 | Partly |
| Information is not conveyed by color alone | 1.4.1 | No |
| Body text contrast at least 4.5 to 1; large text 3 to 1 | 1.4.3 | Mostly, on static text |
| Page works at 200% zoom and at 320 pixels wide without horizontal scrolling | 1.4.4, 1.4.10 | Partly: can detect zoom being disabled |
| Buttons, icons and input borders have 3 to 1 contrast | 1.4.11 | Partly |
| Everything works with a keyboard alone, with no traps | 2.1.1, 2.1.2 | No |
| A skip link or landmarks let users bypass repeated menus | 2.4.1 | Yes |
| Each page has a descriptive title | 2.4.2 | Partly: finds missing, cannot judge quality |
| Focus order is logical | 2.4.3 | No |
| Link text makes sense ("View pricing", not "click here") | 2.4.4 | Partly |
| Focus is visible on every interactive element | 2.4.7 | No |
| New: focused items are not hidden behind sticky bars or banners | 2.4.11 | No |
| New: drag actions have a click or tap alternative | 2.5.7 | No |
| New: targets are at least 24 by 24 pixels or well spaced | 2.5.8 | Partly, in a browser-based tool |
| Page language is set | 3.1.1 | Yes |
| Nothing changes unexpectedly when a field gets focus or a value changes | 3.2.1, 3.2.2 | No |
| New: help links are in the same place across pages | 3.2.6 | No |
| Form errors are described in text and suggest a fix | 3.3.1, 3.3.3 | No |
| New: no re-typing the same information in one process | 3.3.7 | No |
| New: login allows paste and password managers; no puzzle-only CAPTCHA | 3.3.8 | No |
| Buttons and links have accessible names; custom widgets expose role and state | 4.1.2 | Partly: finds empty names, not wrong states |
| Status messages ("added to cart") are announced to screen readers | 4.1.3 | No |
This is a working checklist, not the full standard. For a formal audit, test against every Level A and AA criterion in the WCAG 2.2 specification.
What an automated scan can and cannot catch
Automated tools are fast and useful, but they find only part of the problems. In a 2017 test, the UK Government Digital Service built a page with 143 accessibility failures and ran ten free automated tools against it. Together the tools found 71% of the barriers; 29% were missed by every tool, and the best single tool found 41% when its prompts for manual checks are counted (GDS accessibility blog). Tools have improved since, but the reason for the gap has not changed: many criteria need a person to judge.
They are still worth running, because the issues they catch are extremely common. The WebAIM Million 2026 report found detectable WCAG failures on 95.9% of the top one million home pages, led by low contrast text (83.9% of pages), missing alt text (53.1%), and missing form labels (51%) (WebAIM).
| Automated scans are good at | A person has to check |
|---|---|
| Missing alt attributes | Whether alt text is accurate and useful |
| Form fields with no label | Whether labels and error messages make sense |
| Links and buttons with no name | Whether a custom menu or dialog works with a keyboard and screen reader |
| Missing page language and title | Whether focus order is logical and focus stays visible |
| Zoom disabled in the viewport tag | Whether the layout survives 200% zoom and narrow screens |
| Heading structure problems | Most of the new 2.2 criteria: obscured focus, dragging, consistent help, redundant entry, authentication |
What our free checker does
Our free accessibility checker scans one public page at a time. It reads the HTML the server sends and checks for common failures, such as images without alt text or with alt text that looks like a file name, form fields without labels, links and buttons with no accessible name, missing page title and language, heading problems, missing skip link and main landmark, untitled frames, positive tabindex values, autoplaying media, timed refreshes and disabled zoom. Each result links to the relevant WCAG criterion.
Be clear about its limits. Because it reads the HTML before any JavaScript runs, it does not see content that scripts add later, and it does not test the new WCAG 2.2 criteria that need a browser and a person. Treat a clean result as "no common markup failures found", not as "accessible". Then do the manual checks below.
Five manual tests anyone can do
- Keyboard only. Unplug the mouse. Use Tab, Shift+Tab, Enter, Space and the arrow keys to complete your main task: book, buy, or send the contact form. Watch that focus stays visible and never hides under a sticky bar.
- Zoom to 200%. In your browser, zoom in to 200% and check that nothing overlaps, gets cut off, or needs sideways scrolling to read.
- Phone tap test. On a phone, try every small control: close buttons, cart quantity buttons, footer icons. If you miss, others will too.
- Login and checkout. Try pasting a password and a one-time code. Check that the shipping address carries over to billing.
- Screen reader basics. Turn on VoiceOver (Mac or iPhone) or NVDA (free, Windows) and listen to your home page and a form. Unlabeled buttons and fields become obvious within a minute.
Write down what you tested, when, and what you fixed. That record is useful if your site is ever challenged, and it keeps your next round of testing fast. Our web accessibility guide covers the fundamentals behind each test.
Next steps
Start with an automated scan of your home page and your most important form or checkout page using our free checker. Then work through the five manual tests and the new 2.2 items in the checklist above. If the list of fixes is long, or the problems sit deep in your theme or platform, a rebuild can be cheaper than patching; our free website cost calculator gives a USD estimate.
If you are in the US, read our guide to ADA website lawsuits. If you sell to EU consumers, see the European Accessibility Act for US companies.
Frequently asked questions
Nine: 2.4.11 Focus Not Obscured (Minimum), 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, 3.3.8 Accessible Authentication (Minimum) and 3.3.9 Accessible Authentication (Enhanced).
Success criterion 4.1.1 Parsing was removed because W3C considers it obsolete.
WCAG 2.2 became a W3C Recommendation on 5 October 2023. The current edition of the specification is dated 12 December 2024.
Yes. WCAG 2.2 is backward compatible with 2.1. The only change to the earlier criteria is the removal of 4.1.1 Parsing.
Under 2.5.8 at Level AA, targets must be at least 24 by 24 CSS pixels, unless they are spaced so a 24 pixel circle around each does not overlap another, or another exception applies, such as links inside a sentence.
Only partly. Automated tools catch common markup failures such as missing alt text and unlabeled fields, but most of the new 2.2 criteria and many older ones need manual testing by a person.
Not if users can paste or use a password manager, because that counts as a mechanism that helps. Blocking paste, or using puzzle CAPTCHAs with no alternative, is what usually fails.
WCAG 2.2 Level AA. It covers WCAG 2.1 AA, which US government rules name, and it matches the updated European standard EN 301 549 V4.1.1.
Sources
Each figure and date above comes from one of these. The retrieved date is when we last confirmed the source still says what we say it says.
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation 12 December 2024 W3C. Retrieved 2026-10-20.
- What's New in WCAG 2.2 W3C Web Accessibility Initiative. Retrieved 2026-10-20.
- What we found when we tested tools on the world's least-accessible webpage UK Government Digital Service, Accessibility blog. Retrieved 2026-10-20.
- The WebAIM Million: 2026 report WebAIM, Utah State University. Retrieved 2026-10-20.
- EN 301 549 V4.1.1 (2026-09): Accessibility requirements for ICT products and services ETSI, CEN and CENELEC. Retrieved 2026-10-20.
About the author
Founder, Accountant & Project Manager, Four Cents
Hamza Hai is a founder of Four Cents and its accountant and project manager. She keeps projects on track and the numbers clear.
She manages timelines, scope and client communication, so there are no surprises for clients along the way.
She writes the guides on DeveloperOfWeb.com, including its website costing and planning guides. They draw on the quoting and scoping work she does for Four Cents clients every week.
Areas of expertise
- Software and app project management
- Development costing and estimates
- Project scoping
- Budgeting for software projects
All articles by Hamza Hai (114 on DeveloperOfWeb.com)
Reviewed by Zee, Founder & Lead Developer, Four Cents
Zee leads every Four Cents build as the senior full-stack engineer, from the first call to launch and beyond, and technically reviews the articles on this site.
Our editorial standards: who writes and reviews our articles, where our prices come from and how to report a correction.