WCAG 2.2 Success Criteria: What They Mean for Your Website
WCAG 2.2 is the current accessibility standard for the web. Since October 2024 it has been the version referenced by UK public sector accessibility regulations, making it a legal requirement for councils, NHS trusts, government departments and other public bodies. For private sector organisations, the pressure to invest in website accessibility compliance has grown just as firmly. WCAG 2.2 was approved as an ISO international standard in 2025, the European Accessibility Act came into force the same year and any UK court assessing whether a website makes reasonable adjustments under the Equality Act will look to the current W3C Recommendation as its benchmark. The nine success criteria that WCAG 2.2 added to its predecessor close genuine usability gaps, from buttons that are too small to tap on a phone to login systems that lock out users with cognitive disabilities. If your site was built to meet WCAG 2.1 AA you are already in a strong position, but those gaps still need addressing.
This guide breaks down each of the WCAG 2.2 criteria in plain English, explains what they mean in practice and covers what UK organisations need to do to stay compliant.
What Changed Between WCAG 2.1 and WCAG 2.2
WCAG 2.2 is not a rewrite. It builds directly on top of WCAG 2.1, which means everything in 2.1 still applies. If your site meets 2.1 AA, you already satisfy the vast majority of what 2.2 requires. Published as a W3C Recommendation on 5 October 2023, the update added nine success criteria across three conformance levels (A, AA and AAA) and removed one outdated criterion from the previous version.
The removed criterion is 4.1.1 Parsing, which originally required valid HTML to ensure assistive technologies could interpret page content correctly. Modern browsers and screen readers have become far more resilient to parsing errors, so the W3C decided this criterion no longer served its intended purpose. Removing it doesn’t mean sloppy HTML is acceptable. Clean, semantic markup still matters for accessibility. It just means you won’t fail a WCAG 2.2 audit specifically for parsing issues.
The nine additional criteria focus on three broad themes. First, better visibility of keyboard focus indicators, which helps anyone navigating a site without a mouse. Second, improved support for people with motor impairments, particularly around touch targets and drag interactions. Third, reduced cognitive load during authentication and form completion. These themes reflect the W3C’s growing emphasis on cognitive and motor accessibility, areas where WCAG 2.1 was widely acknowledged to have gaps.
The full WCAG 2.2 specification is publicly available and free to read. It is dense, as any technical standard tends to be, but the sections below translate each criterion into language that doesn’t require a computer science degree to follow.
The AA Success Criteria You Need to Know
Five of the nine criteria added by WCAG 2.2 sit at the AA level, which is the conformance target most UK organisations aim for. These are the ones that affect the majority of websites and the ones you should prioritise if you’re working toward full compliance.
| Criterion | Level | What It Requires |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | The keyboard focus indicator must not be entirely hidden by other page content such as sticky headers, overlays or chat widgets. |
| 2.5.7 Dragging Movements | AA | Any function that uses a dragging movement must also be operable with a single pointer action (such as a click or tap) without dragging. |
| 2.5.8 Target Size (Minimum) | AA | Interactive targets must be at least 24 by 24 CSS pixels or have sufficient spacing from adjacent targets. |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login processes must not rely on cognitive function tests such as memorising a password, unless an alternative method is available. |
| 3.3.7 Redundant Entry | A | Information previously entered by the user in the same process must be auto-populated or available to select, unless re-entry is essential for security. |
Let’s walk through each of these in practical terms.
2.4.11 Focus Not Obscured (Minimum) tackles a frustration that keyboard users encounter constantly. You’re tabbing through a page and the focus lands on a link or button, but a sticky navigation bar, a cookie banner or a live chat widget is sitting right on top of it. You can’t see where you are on the page. Under WCAG 2.2 AA, the focused element must not be completely hidden by author-created content. Partially obscured is technically permitted at the AA level (the AAA version, 2.4.12, requires full visibility), but the practical fix is straightforward: make sure sticky elements don’t cover interactive content when it receives focus.
2.5.7 Dragging Movements applies to any interface where users drag items, such as reordering a list, moving a slider or positioning an element on a canvas. People with motor impairments, tremors or those using mouth sticks, head pointers or eye-tracking devices often cannot perform a drag. The fix is to provide an alternative. A sortable list should also have “move up” and “move down” buttons. A slider should allow users to type a value directly. A map that supports drag-to-pan should also support click-to-move controls.
2.5.8 Target Size (Minimum) addresses the all-too-common problem of tiny clickable elements. If you’ve ever tried to tap a small icon on a mobile screen and hit the wrong thing, you’ve experienced exactly what this criterion aims to prevent. Interactive elements need to be at least 24 by 24 CSS pixels or they need enough spacing from neighbouring targets that accidental activation is unlikely. This applies to buttons, links, form controls and any other clickable or tappable element. Inline links within a block of text are exempt, as are targets where the size is controlled by the browser rather than the author.
3.3.8 Accessible Authentication (Minimum) is arguably the criterion with the broadest impact. It says that login processes must not depend on a cognitive function test, such as remembering a password, recognising an image from a set or solving a puzzle, unless an alternative is provided. This doesn’t ban passwords outright. It means that if your login requires a password, you must also allow a password manager to fill it in (don’t block paste), offer a passwordless alternative or support a mechanism like a hardware security key. CAPTCHAs that require users to identify objects in images are problematic under this criterion unless an accessible alternative is available.
3.3.7 Redundant Entry is classified at Level A, making it the most basic of the requirements that 2.2 added. It says that if a user has already entered information during a process, they shouldn’t have to type it again. Think of a multi-step checkout where you enter your address on one page and then get asked for it again on the payment page. The information should auto-populate or be available for the user to select. This helps everyone, but it particularly benefits people with cognitive disabilities, memory difficulties or motor impairments who find repeated data entry exhausting and error-prone.
The A and AAA Criteria
Beyond the AA criteria covered above, WCAG 2.2 includes one additional A-level criterion (3.2.6) and three AAA-level criteria (2.4.12, 2.4.13 and 3.3.9). While AAA conformance is rarely a realistic target for an entire website, understanding these criteria helps you make informed decisions about where to exceed the minimum.
3.2.6 Consistent Help (Level A) requires that if your site offers help mechanisms, such as a contact phone number, email address, chat feature or self-help page, they appear in the same relative position on every page. The help itself doesn’t have to be identical everywhere, but users must be able to find it consistently. If your contact details are in the footer on your homepage but buried in a submenu on your product pages, that’s a problem. This criterion is about predictability. People who need help shouldn’t have to hunt for it on every new page they visit.
2.4.12 Focus Not Obscured (Enhanced) at AAA level goes further than its AA counterpart. Where 2.4.11 only requires that focus is not entirely hidden, 2.4.12 requires that no part of the focus indicator is obscured by author-created content. In practice, if you’ve already solved 2.4.11 properly (by ensuring sticky elements don’t overlap focused content), you’ll likely meet 2.4.12 as well.
2.4.13 Focus Appearance (AAA) sets detailed requirements for how the focus indicator itself looks. It specifies that the focus indicator must have a minimum area (at least as large as a 2 CSS pixel thick perimeter of the element), a contrast ratio of at least 3:1 against the unfocused state and a contrast ratio of at least 3:1 against adjacent colours. This criterion gives developers clear, measurable targets for designing focus styles rather than relying on vague browser defaults.
3.3.9 Accessible Authentication (Enhanced) at AAA level tightens the rules around login processes even further. Where the AA version (3.3.8) allows cognitive function tests if an alternative mechanism is provided, the AAA version removes that exception. At this level, authentication must not rely on any cognitive function test at all, full stop. Passwordless login methods, biometric authentication and hardware security keys all satisfy this criterion.
What WCAG 2.2 Means for UK Organisations
WCAG 2.2 AA is a legal requirement for UK public sector websites. The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 were updated in October 2024 to reference WCAG without a specific version number, which means the obligation automatically tracks the current W3C Recommendation. As of that date, the current Recommendation is WCAG 2.2. Public sector organisations must meet WCAG 2.2 AA and publish an accessibility statement. Compliance is monitored by the Government Digital Service, with enforcement carried out by the Equality and Human Rights Commission.
The Equality Act 2010 sits alongside these regulations and applies to both public and private sector organisations. It requires anyone providing goods, services or facilities to the public to make reasonable adjustments for disabled people. Websites fall firmly within that scope. Courts interpret what counts as reasonable partly by reference to recognised standards, so the Equality Act effectively points to WCAG 2.2 without naming it directly.
WCAG 2.2 AA is not aspirational. It is the legal standard for UK public sector websites and the benchmark that courts are likely to apply when assessing private sector compliance under the Equality Act. Organisations that have not yet moved beyond WCAG 2.1 are already behind.
For private sector businesses, particularly those selling digital products or services into the EU, the European Accessibility Act adds another layer. The EAA became enforceable in June 2025 and its technical standard EN 301 549 is being updated to incorporate WCAG 2.2 directly. WCAG 2.2 was also approved as an ISO international standard (ISO/IEC 40500:2025) in October 2025, reinforcing its standing as the global benchmark. Investing in accessible web design to the 2.2 AA standard gives you the strongest position across UK, EU and international legal frameworks.
The GOV.UK Service Manual provides clear, plain-language guidance on meeting WCAG requirements and is a useful resource regardless of whether you are in the public or private sector. It is one of the better starting points for teams who find the W3C documentation itself overwhelming.
Practical Steps for Meeting WCAG 2.2
If your site already meets WCAG 2.1 AA, the path to 2.2 compliance is manageable. You’re closing specific gaps, not rebuilding from scratch. Here’s a practical approach to getting there.
- Start with an audit against the five AA criteria that WCAG 2.2 added. Test keyboard focus visibility across your entire site, paying close attention to pages with sticky headers, overlays, cookie banners and chat widgets. Check every drag-based interaction for a non-drag alternative. Measure your interactive target sizes. Review your login and registration flows for cognitive function barriers. Walk through any multi-step forms to identify redundant entry.
- Fix focus obscuring issues first, because they tend to affect every page. Adjust the z-index of sticky elements, add scroll padding so focused content sits below fixed headers and ensure overlays can be dismissed before they block navigation. These are CSS-level fixes that a competent WordPress development team can handle without major rework.
- Review all interactive target sizes. Buttons, links in navigation menus, form controls, icon buttons and social media links are common offenders. If an element is smaller than 24 by 24 pixels, either increase its size or add spacing so users can’t accidentally activate the wrong control. Pay particular attention to mobile layouts where space is tightest.
- Ensure your authentication flows support password managers at minimum. Don’t disable paste on password fields. If you use CAPTCHAs, provide an accessible alternative. Consider whether passwordless options like magic links or passkeys could replace traditional password entry entirely.
- Audit multi-step forms for redundant data entry. If your checkout, application or onboarding process asks users for the same information twice, implement auto-population. Store previously entered data within the session and pre-fill subsequent fields. This is good UX for every user, not just those with disabilities.
- Verify that help mechanisms appear consistently across your site. Check that contact information, chat widgets and help links occupy the same position relative to other content on every page. Run a quick visual comparison across your main templates to catch inconsistencies.
Automated testing tools like Axe, WAVE and Lighthouse will catch some of these issues, but not all of them. Focus visibility, target size context and authentication flow usability all require manual testing. Keyboard-only navigation testing and screen reader testing should be part of your regular quality assurance process, not a one-off exercise.
For organisations running WordPress sites, many of these fixes sit at the theme and plugin level rather than in the content itself. Theme developers who understand WCAG 2.2 will build focus styles, target sizes and consistent help placement into the design system from the start. If your current theme doesn’t support these requirements, it may be time for a conversation with your WCAG accessibility audit and development team about what needs updating.
FAQs
Is WCAG 2.2 a legal requirement in the UK?
Yes, for public sector organisations. The Public Sector Bodies Accessibility Regulations 2018 were updated in October 2024 to reference WCAG without a specific version number. Since WCAG 2.2 is the current W3C Recommendation, it is the version that public sector websites must meet at AA level. For private sector organisations, the Equality Act 2010 does not name a specific version, but courts look to the current recognised standard when assessing whether reasonable adjustments have been made. Aiming for WCAG 2.2 AA gives any organisation the strongest legal position available.
Do I need to meet all nine criteria added by WCAG 2.2?
That depends on your target conformance level. Most UK organisations aim for AA, which means the five AA criteria added by 2.2 (plus the A-level criteria Consistent Help and Redundant Entry) are your priority. The three AAA criteria are aspirational goals rather than mandatory targets for most sites. Meeting them where practical, particularly around focus appearance and authentication, strengthens your overall accessibility.
Will my WCAG 2.1 compliant site automatically pass WCAG 2.2?
No. WCAG 2.2 includes everything from 2.1, so a 2.1 compliant site meets all of the inherited criteria. But the nine criteria that 2.2 added are requirements your site has not been tested against. You will need a targeted audit of those requirements, particularly around focus visibility, target sizes, authentication flows and redundant entry in multi-step forms.
What happened to criterion 4.1.1 Parsing?
WCAG 2.2 removed 4.1.1 Parsing because modern browsers and assistive technologies have become robust enough to handle HTML parsing errors without breaking functionality. This does not mean clean HTML no longer matters. Semantic, well-structured markup is still important for accessibility. You simply will not fail a WCAG 2.2 conformance assessment specifically because of HTML validation errors.
How often should I audit my site against WCAG 2.2?
Accessibility is not a one-off project. You should audit after any significant design or development change. The same applies when adding plugins or third-party tools. At minimum, run a full audit once a year as part of your regular site maintenance. Content updates can also introduce issues, so building accessibility checks into your content workflow is just as important as the technical audits.
Co-Founder at Priority Pixels
Paul leads on development and technical SEO at Priority Pixels, bringing over 20 years of experience in web and IT. He specialises in building fast, scalable WordPress websites and shaping SEO strategies that deliver long-term results. He’s also a driving force behind the agency’s push into accessibility and AI-driven optimisation.
