What WCAG 2.2 is
The Web Content Accessibility Guidelines, usually shortened to WCAG, provide testable criteria for making websites and digital services more accessible to people with disabilities. WCAG 2.2 was published by the World Wide Web Consortium, W3C, as a Recommendation on 5 October 2023.
The standard is organised around four principles: content should be perceivable, operable, understandable and robust. Individual success criteria sit at levels A, AA or AAA. To claim conformance at level AA, a page must satisfy all applicable level A and AA success criteria, not simply achieve a particular score in an automated scanner.
That distinction matters when testing a real website. Automated tools can find issues such as some missing labels, colour contrast failures and invalid accessibility attributes, but they cannot reliably establish whether an entire user journey works with a keyboard or screen reader. Manual checks remain necessary.
For UK public-sector websites and apps, current GOV.UK guidance specifies WCAG 2.2 AA under the Public Sector Bodies Accessibility Regulations. Private-sector organisations also have duties under the Equality Act 2010, including duties relating to reasonable adjustments, but the Act does not simply state that every private website must obtain WCAG 2.2 AA conformance.
The nine new WCAG 2.2 success criteria
WCAG 2.2 keeps the earlier WCAG 2.0 and 2.1 criteria with one notable change: success criterion 4.1.1 Parsing was removed as obsolete. Nine new criteria were added.
- 2.4.11 Focus Not Obscured (Minimum), AA: an element receiving keyboard focus must not be completely hidden by author-created content such as a sticky header or fixed banner.
- 2.4.12 Focus Not Obscured (Enhanced), AAA: the stricter version requires the focused component to remain fully visible.
- 2.4.13 Focus Appearance, AAA: visible keyboard focus indicators must meet defined size and contrast requirements.
- 2.5.7 Dragging Movements, AA: functions that use dragging need an alternative that does not require a dragging movement, unless dragging is essential.
- 2.5.8 Target Size (Minimum), AA: pointer targets generally need to be at least 24 by 24 CSS pixels or have sufficient spacing, subject to stated exceptions.
- 3.2.6 Consistent Help, A: repeated help mechanisms need to appear in a consistent relative order across a set of pages.
- 3.3.7 Redundant Entry, A: information already supplied during the same process should normally be populated automatically or available for selection instead of being requested again.
- 3.3.8 Accessible Authentication (Minimum), AA: authentication must not depend solely on cognitive tests such as remembering or transcribing information where the criterion applies, unless an allowed alternative or assistance mechanism is provided.
- 3.3.9 Accessible Authentication (Enhanced), AAA: applies a stricter version of the accessible authentication requirement.
The practical effect is broader than changing CSS. Checkout flows, account logins, cookie controls, fixed headers, multi-step forms and draggable interfaces may all need testing.
What WCAG 2.2 AA means in practice
Level AA is usually the working target for organisations applying WCAG because it includes all level A and AA requirements. Passing an automated accessibility checker is not the same as conforming to WCAG 2.2 AA.
A proper assessment needs to examine actual behaviour. Keyboard testing should follow focus through menus, dialogs, forms and account areas and check that sticky elements do not cover the active control. Pointer testing should look at small icons, pagination, close buttons and controls positioned close together. A 20 pixel control is not automatically a failure under 2.5.8 because the spacing exception may apply, so target size needs to be measured in context.
Authentication deserves similar care. WCAG 2.2 does not simply ban passwords. W3C specifically identifies mechanisms such as allowing password managers and copy and paste as ways of reducing cognitive demands. Blocking pasted passwords or forcing users to memorise one-time codes can therefore create accessibility problems.
Our free accessibility checker can identify machine-detectable problems. For a fuller assessment, an accessibility audit combines automated scanning with manual keyboard and screen-reader testing.
A practical WCAG 2.2 checklist
Start with the journeys that matter most rather than checking only the homepage. A shop should include product selection, basket, checkout and account access. A service website should test navigation, forms, downloads and any booking or login process.
- Run an automated scan. Use it to find repeatable code-level problems across templates and key pages.
- Test without a mouse. Use Tab, Shift plus Tab, Enter, Space and arrow keys where appropriate. Confirm that focus is visible, logical and never trapped or hidden.
- Check zoom and reflow. Content should remain usable when text or the viewport is enlarged rather than forcing unnecessary two-dimensional scrolling.
- Review forms and authentication. Inspect labels, instructions, errors, repeated data entry, password-manager support and any CAPTCHA or verification step.
- Test with assistive technology. Screen-reader testing can expose missing names, poor heading structure, ambiguous controls and status changes that visual review misses.
- Record failures by criterion. A useful remediation plan identifies the affected component, the WCAG criterion, severity and the change required.
Accessibility should also be retested after template changes, new plugins, navigation redesigns and major content releases. A site can pass an audit and later regress when new components are introduced.
When a WCAG 2.2 audit is worth doing
An audit is particularly useful before a public-sector launch, procurement exercise, redesign or accessibility statement update, or when an automated scan has produced results that need manual interpretation.
Our published fixed-price £549 accessibility audit assesses the site against WCAG 2.2 AA, includes manual keyboard and screen-reader testing, maps identified issues to the relevant WCAG criteria and provides a prioritised, costed fix plan. See the accessibility audit service for details.
If ongoing changes are the main risk, accessibility monitoring provides recurring checks after the initial work rather than treating accessibility as a one-off exercise.