The Web Content Accessibility Guidelines (WCAG) 2.2 became an official W3C Recommendation in October 2023. If you run a website and haven't looked at what changed, this guide is for you. We'll walk through every new success criterion, explain who needs to care, and give you a practical roadmap for getting compliant.
What Is WCAG 2.2 and Why Does It Exist?
WCAG is the international standard for web accessibility, published by the World Wide Web Consortium (W3C). It defines how websites should be built so that people with disabilities — including those with visual, hearing, motor, or cognitive impairments — can use them effectively.
WCAG 2.2 builds on WCAG 2.1, which itself built on WCAG 2.0. Rather than replacing everything that came before, each version adds new success criteria addressing gaps identified through research and real-world accessibility testing. WCAG 2.2 focuses particularly on three groups: users with cognitive or learning disabilities, users with low vision, and users on mobile devices.
The standard defines three conformance levels:
- Level A — the minimum. Not meeting these criteria makes content inaccessible to some users.
- Level AA — the practical compliance target. This is what laws, procurement policies, and courts typically require.
- Level AAA — enhanced. Not required for whole sites, but aspirational for specific content.
Most organisations target WCAG 2.2 AA. That's what we'll focus on here.
What Changed: The New Success Criteria
WCAG 2.2 introduced nine new success criteria and removed one. Here's what each means in practice.
2.4.11 Focus Not Obscured (Minimum) — AA
When a user navigates with a keyboard, the focused element must not be entirely hidden by sticky headers, cookie banners, or other content. At Level AA, at least part of the focused component must remain visible. The stricter AAA version (2.4.12) requires the component to be fully visible.
In practice: Test keyboard navigation on pages with sticky navbars. If tabbing through a form causes the focused field to disappear behind the header, you fail this criterion.
2.4.12 Focus Not Obscured (Enhanced) — AAA
The same as above, but the focused component must be completely visible — nothing can overlap it at all.
2.4.13 Focus Appearance — AA
This is one of the more technical criteria. When a keyboard focus indicator is visible, it must meet specific size and contrast requirements. The focus indicator must have an area at least as large as the perimeter of the unfocused component multiplied by 2px, and must have a contrast ratio of at least 3:1 between focused and unfocused states.
In practice: The default browser focus ring often doesn't pass this. You'll likely need custom CSS to create a visible, high-contrast focus indicator that's large enough to meet the area requirement.
2.5.7 Dragging Movements — AA
If your interface requires dragging (think sliders, sortable lists, map panning), there must be an alternative single-pointer method. This matters for users with tremors or limited dexterity who cannot reliably drag.
In practice: Sliders need increment/decrement buttons. Drag-to-sort lists need up/down buttons. File upload areas that require dragging need a click-to-browse alternative (most already have this).
2.5.8 Target Size (Minimum) — AA
Clickable targets — buttons, links, checkboxes — must be at least 24x24 CSS pixels, unless there's sufficient spacing around them or an exception applies.
In practice: This catches small icon buttons, close buttons on modals, and pagination links. Audit your smallest interactive elements. Note that WCAG 2.1 AA had no minimum target size requirement, so this is genuinely new ground.
3.2.6 Consistent Help — A
If a website provides a help mechanism (phone number, chat widget, contact form, FAQ), it must appear in the same place on every page where it's offered.
In practice: If your chat widget appears bottom-right on the homepage, it must be bottom-right on every page. This is about predictability for users with cognitive disabilities.
3.3.7 Redundant Entry — A
If a user has already provided information in a process (like a multi-step checkout), they shouldn't have to type it again. Either auto-populate it or let them select it from their previous entries.
In practice: If your checkout asks for billing address after shipping address, either default billing to the same as shipping or pre-fill it. Don't make users retype their email across multiple form steps.
3.3.8 Accessible Authentication (Minimum) — AA
Cognitive function tests — things that require users to remember, solve puzzles, or transcribe characters — cannot be required for authentication unless a mechanism is provided to help. Acceptable alternatives include password managers (don't block paste!), copy-paste for OTP codes, or email magic links.
In practice: The most common failure here is blocking password paste. If your login form prevents users from pasting, you fail 3.3.8. CAPTCHAs that require solving puzzles without an alternative also fail.
3.3.9 Accessible Authentication (Enhanced) — AAA
The stricter version disallows cognitive tests entirely, even with alternatives — no CAPTCHAs at all.
The One Criterion Removed: 4.1.1 Parsing
WCAG 2.1 included 4.1.1 (Parsing), which required valid HTML. Modern browsers handle malformed HTML gracefully, so the W3C removed this criterion as it no longer serves accessibility purposes in practice.
Who Must Comply?
Public Sector
In the UK, the Public Sector Bodies Accessibility Regulations 2018 require public sector websites to meet WCAG 2.1 AA. These regulations are expected to be updated to reference WCAG 2.2. If you're in the public sector, treat WCAG 2.2 AA as your current target.
In the EU, the Web Accessibility Directive applies similar requirements to public sector bodies across member states.
In the US, Section 508 of the Rehabilitation Act requires federal agencies and federally funded organisations to meet WCAG 2.0 AA, though the Department of Justice has updated ADA technical standards to reference WCAG 2.1 AA.
Private Sector
Private sector requirements vary by jurisdiction, but the direction of travel is clear: accessibility standards are becoming legally enforceable across more industries and countries. The European Accessibility Act (which takes effect June 2025) extends requirements to large parts of the private sector. ADA litigation in the US targets private businesses regardless of size.
The honest answer is: if you serve the public, you should be aiming for WCAG 2.2 AA compliance regardless of whether you're legally required to today.
Compliance Deadlines
There is no single global deadline, but here are the key dates:
- October 2023 — WCAG 2.2 became an official W3C Recommendation
- June 28, 2025 — European Accessibility Act applies to private sector organisations in EU member states
- Ongoing — ADA litigation in the US continues; courts increasingly use WCAG 2.1/2.2 AA as the benchmark
For most organisations, "as soon as reasonably possible" is the right answer. Regulators generally look more favourably on organisations actively working toward compliance than those that haven't started.
Practical Steps to Get Compliant
Step 1: Audit Your Current State
You can't fix what you haven't measured. Run an automated accessibility scan to identify the obvious failures — missing alt text, colour contrast issues, form label problems. Automated tools catch roughly 30-40% of accessibility issues.
The remaining 60-70% require manual testing:
- Keyboard navigation (can you use the whole site without a mouse?)
- Screen reader testing (NVDA + Firefox, JAWS + Chrome on Windows; VoiceOver on Mac/iOS)
- Zoom to 400% (does content reflow work?)
- Cognitive walkthrough (could someone with a learning disability complete your key tasks?)
Step 2: Prioritise by Impact
Fix critical barriers first — issues that completely prevent task completion. Then address AA failures systematically, working through your most-visited pages and most-important user journeys.
Step 3: Fix the Common Failures
Based on WebAIM's annual surveys, these are the most common accessibility failures:
- Low contrast text — Ensure text meets 4.5:1 contrast ratio (3:1 for large text)
- Missing image alt text — Every meaningful image needs descriptive alt text; decorative images need empty alt=""
- Empty links — "Click here" and icon-only links need descriptive text or aria-label
- Missing form labels — Every input needs a programmatically associated label
- Missing document language — Set
lang="en"(or appropriate language) on your HTML element - Empty buttons — Icon-only buttons need aria-label
Step 4: Test with Real Users
There's no substitute for testing with people who actually use assistive technologies. Disability advocacy organisations, user research firms, and accessibility consultants can help. Even a few hours of user testing will surface issues no automated tool will find.
Step 5: Document and Maintain
Publish an accessibility statement on your website. Document your conformance level, known issues, and how to request accessible alternatives. Treat accessibility like security: it's not a one-time project, it's an ongoing practice.
The Business Case
Beyond legal compliance, accessibility is good business:
- Market size: Approximately 1.3 billion people globally have some form of disability
- Search engines: Many accessibility improvements (semantic HTML, alt text, clear structure) also benefit SEO
- Usability: Accessible design tends to be clearer for everyone — good contrast helps in bright sunlight, captions help in noisy environments
- Brand reputation: Being demonstrably accessible signals you take inclusion seriously
Using WCAGCheck
WCAGCheck scans your website against WCAG 2.2 criteria and returns specific, actionable fixes — not just a list of errors. Paste your URL, get a report within seconds, and start fixing. We check against both automated-detectable issues and flag areas that require manual review.
WCAG 2.2 isn't fundamentally different from what came before — it builds on the same principles. The new success criteria close specific gaps that real users with disabilities encounter. If your site already passed WCAG 2.1 AA, you have a relatively short list of things to check: focus indicators, target sizes, dragging alternatives, authentication, and redundant entry. If you're starting from scratch, the same systematic approach applies — audit, prioritise, fix, test, repeat.