What changed in WCAG 2.2

If your accessibility statement, your procurement template or your QA checklist still says WCAG 2.1, it is a version behind.

WCAG 2.2 has been the current W3C Recommendation since 5 October 2023. It adds nine success criteria, six of which apply at Level A or AA, and it retires exactly one old one.

For an organisation already working towards WCAG 2.1 AA or if you previously were assessed and passed WCAG 2.1 AA, this is a focused gap assessment, not a restart. This article explains each change in words we hope you can understand and tells you what to inspect on your own site.

Ask DDSN to check your compliance with WCAG 2.2

What is WCAG 2.2?

WCAG stands for Web Content Accessibility Guidelines, the W3C standard that defines what an accessible website actually is.  Read our intro to accessibility article.

Each guideline breaks down into testable success criteria, and each criterion carries a conformance level: A, AA or AAA. The levels are not quality scores. They mark how broadly a requirement applies and how much design freedom it constrains. Level AA, the target most contracts specify, means meeting every Level A and every Level AA criterion, on complete pages and across complete processes. A checkout that passes on four screens and fails on the fifth does not conform, and neither does a component library that passes a scanner while the pages built from it do not.

WCAG 2.2 was published on 5 October 2023 and, as at August 2026, it remains the current version of the guidelines. WCAG 3.0 exists only as a discussion piece and is still years from replacing 2.2.

The 2.2 release is deliberately conservative: every criterion from 2.0 and 2.1 stays the same except one, 4.1.1 Parsing, which has been removed as obsolete. A site that conforms to WCAG 2.2 therefore also conforms to 2.1 and 2.0, subject to that one exception. This is described in  What's New in WCAG 2.2.

Which WCAG 2.2 changes apply at Level A or AA?

Six of the nine new criteria sit at Level A or AA, which makes them part of the standard to achieve for most websites. All six respond to problems that testing with real users kept surfacing: keyboard focus disappearing behind sticky interface furniture, controls too small for an unsteady hand, and processes that quietly assume a good memory and fine motor control.

The table below lists all nine new rules or criteria; the sections that follow explain the six that most teams need to know about.

Keep keyboard focus visible: 2.4.11 Focus Not Obscured (Minimum)

When a control (a part of the page that is able to be interacted with) receives keyboard focus, at least part of it must remain visible. That sounds obvious until you consider how much modern interface furniture floats above the page: sticky headers, cookie banners, chat widgets, back-to-top buttons. A keyboard user tabbing towards a footer link can watch their focus indicator slide underneath a persistent banner and vanish. They are still moving through the page; they just have no idea where they are.

What to inspect: tab through every template with your sticky elements in place, at desktop and mobile widths. Pay particular attention to cookie consent banners, chat launchers, sticky navigation, and in-page validation messages that appear above form fields. The failure is almost never in the component itself. It is in the collision between two components that each passed review alone.

Provide an alternative to dragging: 2.5.7 Dragging Movements

Any action that works by dragging must also work without it. Press, hold, move and release is a demanding sequence for someone with a tremor, limited grip strength, or a head pointer, and it is exactly the sequence that drag-to-reorder lists, range sliders and map panning assume. The fix is usually a modest one: reorder buttons beside the drag handle, a text input beside the slider, pan buttons on the map. Dragging can stay; it just cannot be the only way.

What to inspect: maps, sliders, sortable lists, kanban-style boards, file-upload areas that say "drag files here", and touch carousels. For each, ask one question: can a person complete this with single taps or clicks alone?

Make controls large enough, or space them out: 2.5.8 Target Size (Minimum)

Interactive targets on any screen must be at least 24 by 24 CSS pixels, unless an equivalent control exists elsewhere on the page, the target sits inline within a sentence, the size is set by the browser rather than by you, or that particular presentation is essential. There is also a spacing concession: a smaller target can pass if it sits inside an undersized-target-free 24 pixel circle of its own, in effect, if its neighbours keep their distance. The intent is plain even if the geometry is fiddly: stop asking people to hit tiny things packed closely together.

What to inspect: icon-only buttons, pagination links, close buttons on modals and tags, date-picker grids, social icons in footers, and any row of small controls sitting flush against each other. Mobile views first; that is where the small targets cluster.

Put help in a consistent place: 3.2.6 Consistent Help

If pages across your site offer help, whether contact details, a contact form, live chat, an FAQ or an automated assistant, those options must appear in the same relative order on every page that carries them. Someone who found the chat launcher in the bottom-right corner on one page should not have to hunt for it in a hamburger menu on the next. Consistency is an accessibility feature in its own right: it lets people who find interfaces effortful spend that effort once, not on every page.

What to inspect: compare your templates. If help appears in the header on some layouts, the footer on others, and a floating widget on a third, pick one arrangement and apply it everywhere. This is a Level A requirement, the baseline tier.

Do not make people enter the same information twice: 3.3.7 Redundant Entry

Within a single process, information the person has already supplied must be auto-populated or available to select rather than demanded again. The classic failure is an application form that asks for a postal address on one screen and again two screens later, or a booking process that requests the same details for each of three attendees with no copy-forward option. Re-entering data is an inconvenience for most people; for someone with a memory impairment, or someone typing through a switch device, it can end the transaction.

There are sensible exceptions: re-entry is allowed where it is essential (confirming a new password), where security requires it, or where the earlier information may no longer be valid. What to inspect: every multi-step form, checkout, enrolment and application process, walked end to end, watching for any field you have typed before.

Do not make memory puzzles the only way to sign in: 3.3.8 Accessible Authentication (Minimum)

Authentication must not rest solely on a cognitive function test, remembering a password, solving a puzzle, or transcribing distorted characters, unless an alternative method exists or a mechanism helps the person through. In practice the mechanism is usually simple: let password managers fill the fields, allow paste in password and one-time-code inputs, support passkeys or email links. Blocking paste on a password field, which some sites still do in the name of security, is now a direct route to failure. CAPTCHAs that demand transcription or puzzles need an alternative, though object-recognition tests ("select the traffic lights") remain permitted at AA.

What to inspect: sign-in, registration, password reset, multi-factor prompts and account recovery. Try the whole path with a password manager and with copy and paste. If either is blocked anywhere, that is the finding.

What changed at Level AAA?

Three of the nine new criteria sit at Level AAA: 2.4.12 Focus Not Obscured (Enhanced), which requires that no part of the focused control is hidden; 2.4.13 Focus Appearance, which sets minimum size and contrast for the focus indicator itself; and 3.3.9 Accessible Authentication (Enhanced), which removes the object-recognition allowances from its AA sibling. AAA is rarely a contractual requirement, and the W3C itself does not recommend demanding it wholesale. But these three are worth reading anyway, because they describe good design cheaply achieved. A clearly visible focus indicator costs a few lines of CSS. Choosing an authentication flow that never needs a puzzle costs nothing at all if you choose it at design time.

What happened to 4.1.1 Parsing?

It has been removed. Criterion 4.1.1 dated from an era when assistive technologies parsed markup themselves and choked on unclosed tags and duplicate attributes. Modern assistive technology reads the browser's accessibility tree instead, so the criterion no longer measured anything real, and WCAG 2.2 declares it obsolete.

This is not permission to ship broken markup. The problems 4.1.1 used to catch, duplicate IDs that confuse label associations, malformed structures that scramble names and roles, now simply fail other criteria, most often 4.1.2 Name, Role, Value or 1.3.1 Info and Relationships. One practical wrinkle remains: a contract or policy that explicitly names WCAG 2.0 or 2.1 still technically includes Parsing, so your test reports may need to address it until those documents are updated. That is a reason to update the documents, not to keep testing for a retired criterion forever.

What should an IT manager do next?

A realistic 30-day plan, assuming a site already at or near WCAG 2.1 AA.

In the first week, confirm with whoever owns your contracts and policies that the target is WCAG 2.2 AA, and list your critical transactions: sign-in, payment, enrolment, application, renewal.

In the second week, run automated scans to clear the mechanical faults, then schedule the manual work the scanners cannot do: keyboard-only passes, 400 percent zoom and reflow checks, and assistive technology testing on the critical transactions.

In the third and fourth weeks, log every finding in a remediation register with a named owner and a retest date, fix the shared components first, and record scope, exclusions and evidence as you go. A register with owners and dates is the difference between an audit and an improvement. This is the scan, prioritise, repair cycle our Accessibility as a Service work runs continuously; a 2.2 uplift is one turn of that wheel, and our standards compliance service can run it with you.

Work with us on a WCAG 2.2 gap assessment, or read how Accessibility as a Service keeps a site compliant continuously.

The change is smaller than the version number suggests

WCAG 2.2 does not redraw the map. It closes six practical gaps at the levels most organisations are contracted to meet, all of them in the places where real users were already struggling: signing in, filling forms, hitting small controls, finding help, and keeping sight of keyboard focus. If your site honestly met 2.1 AA, you are most of the way there, and the remaining distance is measurable in components, not in rebuilds. The teams that treat this as a scoped gap assessment will be finished before the teams still debating whether it applies to them have started.

Frequently asked questions