WCAG 2.2 became a W3C Recommendation in October 2023 and is now the version most accessibility work is measured against. It adds nine success criteria to WCAG 2.1 and retires one. This guide explains each change in plain language — what it requires, who it helps, how sites typically fail it and how to fix it — and how to test for WCAG 2.2 compliance on a Toronto business website.
What Changed in WCAG 2.2
WCAG 2.2 keeps everything in WCAG 2.1 (which kept everything in 2.0) and adds nine success criteria. Six are at Level A or AA, so they are part of any WCAG 2.2 AA claim; three are at Level AAA. One old criterion, 4.1.1 Parsing, was removed because modern browsers and assistive technologies no longer depend on it.
The new criteria focus on three groups the earlier versions served less well: keyboard users (focus that stays visible), people with motor disabilities (alternatives to dragging, bigger targets) and people with cognitive disabilities (consistent help, no re-typing, sign-in without memory tests).
Does the AODA require WCAG 2.2?
Not yet. Ontario’s AODA still requires WCAG 2.0 Level AA from public-sector organisations and organisations with 50 or more employees. But because each version contains the last, a site that meets WCAG 2.2 AA also meets 2.0 AA — and it reflects how people actually use the web on phones and touch screens today. That is why WCAG 2.2 AA is the sensible target for new work. For the legal picture in full, see our website accessibility and WCAG compliance guide.
The Six New Level A and AA Criteria
2.4.11 Focus Not Obscured (Minimum) — Level AA
When an element receives keyboard focus, it must not be entirely hidden by other content on the page. The usual culprits are sticky headers and footers, cookie banners and chat widgets: a keyboard user tabs to a link and it disappears behind the header.
How to fix it: set scroll-padding-top on the page to the height of any sticky header (and scroll-padding-bottom for sticky footers), and make sure banners and chat buttons don’t sit on top of content while it has focus — let people dismiss them, or keep them out of the way of the main content.
2.5.7 Dragging Movements — Level AA
Anything that can be done by dragging must also be possible with a single pointer action — a click or tap — unless dragging is essential. Range sliders, sortable lists, kanban boards, map panning and “drag to upload” areas are common failures. Many people with tremors, limited dexterity or head pointers can’t hold and drag precisely.
How to fix it: pair every drag with buttons or inputs — plus and minus buttons or a number field next to a slider, “move up / move down” controls on sortable items, zoom and pan buttons on maps, and a normal file picker next to the drop zone.
2.5.8 Target Size (Minimum) — Level AA
Pointer targets — buttons, links, icons, form controls — must be at least 24 by 24 CSS pixels, with sensible exceptions: a smaller target passes if it has enough space around it, if the same function is available through another target of the right size, if it is a link inside a sentence, or if its size is set by the browser.
How to fix it: give icon buttons (close, social, carousel arrows, pagination) a 24px minimum hit area — padding counts — and keep small targets apart. On touch screens, larger is better: 44px remains a good design target for primary controls.
3.2.6 Consistent Help — Level A
If a website offers help — a phone number or email address, a contact form, a chat, an FAQ link — on several pages, it must appear in the same relative order on each page. People who rely on finding help in a familiar place shouldn’t have to search for it again.
How to fix it: place help in a shared header or footer component, and don’t reorder it on individual templates.
3.3.7 Redundant Entry — Level A
Information a person has already entered in a process must not have to be typed again in the same process — it should be filled in automatically or available to select. The exceptions are re-entry that is essential (for example a memory game), required for security, or needed because the earlier information is no longer valid.
How to fix it: offer a “billing address same as shipping” option, carry details forward between the steps of a multi-page form, and show earlier answers as choices rather than empty fields.
3.3.8 Accessible Authentication (Minimum) — Level AA
Signing in must not depend on a cognitive function test — remembering a password, solving a puzzle, transcribing characters — unless there is an alternative or a mechanism to help. Allowing password managers and copy-paste satisfies the criterion; so do passkeys, sign-in links sent by email and other methods that don’t rely on memory.
How to fix it: never block pasting into password or code fields, use the right autocomplete attributes so password managers work, and replace text-transcription CAPTCHAs with options that don’t test memory or transcription.
The Three New AAA Criteria
- 2.4.12 Focus Not Obscured (Enhanced): no part of the focused element may be hidden — a stricter version of 2.4.11.
- 2.4.13 Focus Appearance: the focus indicator must be large enough — at least as large as a 2 CSS pixel outline around the element — and have a 3:1 contrast between its focused and unfocused states.
- 3.3.9 Accessible Authentication (Enhanced): like 3.3.8, but without the exceptions for recognising objects or personal content.
Level AAA isn’t required for whole sites, but 2.4.13 is worth adopting anyway: a strong, consistent focus style is one of the cheapest accessibility improvements a design system can make.
What Was Removed: 4.1.1 Parsing
WCAG 2.2 removed 4.1.1 Parsing, which required clean, well-formed markup. Browsers and assistive technologies now handle markup errors consistently, so the criterion no longer protected users; the W3C has noted it should be treated as satisfied for WCAG 2.0 and 2.1 too. Clean HTML is still good practice — problems such as duplicate IDs or broken relationships are caught by other criteria, such as 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.
How to Test for WCAG 2.2 Compliance
Automated tools have added checks for some new criteria — target size in particular — but most of WCAG 2.2 needs a person. Combine the tools with these manual checks:
| Criterion | Manual check |
|---|---|
| 2.4.11 Focus Not Obscured | Tab through every page with sticky headers, banners and chat open. Does focus ever disappear? |
| 2.5.7 Dragging Movements | Try each slider, sortable list, map and drop zone using only clicks or taps. |
| 2.5.8 Target Size | Measure icon buttons and closely spaced links in the browser’s developer tools. |
| 3.2.6 Consistent Help | Compare the order of contact options and help links across templates. |
| 3.3.7 Redundant Entry | Complete every multi-step form. Are you asked for anything twice? |
| 3.3.8 Accessible Authentication | Sign in with a password manager and with paste. Is any memory or puzzle test unavoidable? |
Free tools such as axe DevTools, WAVE, Lighthouse and Accessibility Insights remain the right first pass for the rest of WCAG; our digital accessibility audit guide explains the full process.
Updating a Design System for WCAG 2.2
Most WCAG 2.2 fixes belong in shared components, not individual pages. If your site is built from a design system or a set of templates, these updates cover most of the new criteria at once:
- A single focus style used by every interactive component — thick enough and contrasting enough to meet 2.4.13 Focus Appearance, even though that is AAA. One token, defined once.
- A minimum hit area of 24 × 24 px built into buttons, icon buttons, pagination and close controls, using padding so the visual design doesn’t have to change.
- Global scroll padding that matches the sticky header’s height, so in-page links and keyboard focus never land under it.
- Slider, list and map components that ship with their button alternatives, so no team has to remember to add them.
- Form patterns that carry information forward between steps, offer “same as shipping”, and use correct
autocompletevalues. - Sign-in patterns that allow paste and password managers, and support passkeys or email sign-in links where possible.
- A shared header and footer that place help and contact options in the same order everywhere.
Document each pattern with its WCAG reference, so designers and developers know why it is built that way — and test the components themselves with a keyboard and a screen reader before they reach a page.
WCAG 2.2 on Phones and Touch Screens
Several of the new criteria matter most on mobile. Small, crowded tap targets are the most common mobile failure, and drag-only gestures — swiping a carousel, dragging a map, reordering a list — exclude people who can’t perform them reliably. Sticky bottom bars and cookie banners take up more of a small screen and are more likely to cover focused fields. When you test for WCAG 2.2 compliance, test on a real phone with the screen reader on (VoiceOver on iOS, TalkBack on Android), not only on a desktop browser.
WCAG 2.2 Compliance Checklist
- Sticky headers, footers and banners never hide the focused element.
- Every drag interaction has a click or tap alternative.
- Pointer targets are at least 24 × 24 px, or spaced so they don’t crowd each other.
- Help and contact options appear in the same order on every page.
- Multi-step forms never ask for the same information twice.
- Sign-in works with password managers and paste, with no memory or puzzle test.
- Focus styles are clearly visible everywhere — ideally meeting 2.4.13 as well.
- Everything from WCAG 2.1 AA still passes: contrast, reflow, text spacing, labels, captions.
Frequently Asked Questions
What is the difference between WCAG 2.0, 2.1 and 2.2?
WCAG 2.0 (2008) set the foundation. WCAG 2.1 (2018) added criteria for mobile devices, low vision and cognitive disabilities, such as reflow and the contrast of icons and controls. WCAG 2.2 (2023) adds nine criteria — six at Levels A and AA — on focus visibility, dragging, target size, consistent help, redundant entry and accessible sign-in, and removes 4.1.1 Parsing. Each version includes the previous one.
Is a site that meets WCAG 2.1 AA already WCAG 2.2 compliant?
Not necessarily. It must also meet the six new A and AA criteria. Many sites fail 2.4.11 (sticky headers), 2.5.8 (small icon buttons) or 3.3.8 (blocked paste in password fields) without anyone noticing.
How much does a WCAG 2.2 audit cost?
Free tools are a useful start. A professional manual audit of a typical Toronto business website of 10–50 pages generally costs $2,000 to $8,000, depending on its size, interactive features and documents. Remediation costs depend on what the audit finds.
Can a small Toronto business be fined for an inaccessible website?
The AODA’s website requirement applies to public-sector organisations and organisations with 50 or more employees, and penalties apply to those that don’t comply. Smaller businesses aren’t covered by that section, but complaints can still be made under the Ontario Human Rights Code — so building to WCAG 2.2 AA protects any business.
Want to know how your site measures up against WCAG 2.2? PerfectPixels audits, fixes and builds websites to WCAG 2.2 Level AA. Contact us to talk about your website.
Further reading: What’s new in WCAG 2.2 — W3C WAI.