WCAG 2.2: Why Accessibility Matters and How to Get It Right

WCAG 2.2 is the current web accessibility standard from the W3C, published October 5, 2023. It adds 9 new success criteria to WCAG 2.1—covering focus visibility, touch target size, dragging alternatives, and simpler authentication—to better serve users with cognitive, motor, and visual disabilities. Meeting Level AA is the practical benchmark for legal compliance and good user experience.

Around 1.3 billion people worldwide live with a disability, yet most websites still shut them out. WebAIM’s 2024 analysis found that over 96% of homepages fail basic accessibility requirements. That gap isn’t just an ethical problem—it’s lost customers, legal risk, and damaged trust.

The Web Content Accessibility Guidelines (WCAG) exist to close that gap. The latest version, WCAG 2.2, sharpens the rules around how people actually interact with sites today, especially on phones and with assistive technology. If accessibility wasn’t part of your website development plan before, version 2.2 makes a strong case for building it in now.

This guide explains what WCAG 2.2 is, how it differs from WCAG 2.1, why it matters for your business, and how to implement it correctly. You’ll get the 9 new success criteria in plain language, a practical rollout plan, and clear guidance on testing your work.

What is WCAG 2.2 and how is it different from WCAG 2.1?

WCAG 2.2 is the W3C’s official set of guidelines for making web content accessible to people with disabilities. It builds on the same four POUR principles as earlier versions—content should be Perceivable, Operable, Understandable, and Robust.

Published on October 5, 2023, WCAG 2.2 adds 9 new success criteria to the 2.1 standard. It also retires one outdated criterion, 4.1.1 Parsing, because modern browsers now handle HTML parsing errors gracefully on their own. That brings the total from 78 criteria in WCAG 2.1 to 87 in WCAG 2.2.

The most important thing to know: WCAG 2.2 is fully backward compatible. If your site already conforms to WCAG 2.1 Level AA, you don’t need to redo that work. You only need to assess and address the new criteria. Sites that meet WCAG 2.2 automatically meet 2.1 and 2.0 as well.

The new criteria cluster around three real-world problem areas: mobile and touch interactions, cognitive accessibility, and focus visibility for keyboard and low-vision users. These were the gaps that earlier versions left underserved.

Why does website accessibility matter so much?

Accessibility is a moral obligation, a legal requirement, and a business opportunity rolled into one. Ignore it and you turn away a huge share of potential customers.

The numbers are blunt. Research from AllAccessible shows that 71% of users with disabilities leave an inaccessible site immediately, and 86% won’t return after a bad experience. With 1.3 billion people living with disabilities globally, that’s an enormous market most businesses unintentionally exclude.

Legal risk is climbing too. Level Access reports that federal web accessibility lawsuits filed under Title III of the ADA reached 3,117 in 2025—a 27% increase over 2024. Settlements typically range from $5,000 to $15,000, and that’s before legal fees. In Europe, the European Accessibility Act came into force on June 28, 2025, with penalties reaching up to €100,000 or 4% of annual revenue for non-compliant businesses.

There’s an upside that’s easy to overlook. Accessible sites tend to have cleaner code, clearer structure, and better semantics—all things search engines reward. Designing for accessibility often improves usability for everyone, not just users with disabilities. Larger buttons, readable text, and predictable navigation help every visitor.

What are the 9 new success criteria in WCAG 2.2?

The nine additions split across three conformance levels: 3 at Level A, 5 at Level AA, and 1 at Level AAA. Level AA is the benchmark most regulations reference, so that’s where to focus.

Level A criteria (the baseline)

These three additions are entry-level requirements that benefit users with cognitive and motor disabilities.

• 2.4.11 Focus Not Obscured (Minimum): When a keyboard user moves focus to an element, it can’t be completely hidden behind sticky headers, footers, or cookie banners. Users need to see where they are to navigate.
• 3.2.6 Consistent Help: If help options like a contact link or chat widget appear across multiple pages, they must stay in the same relative order. Predictable placement reduces confusion for users with cognitive disabilities.
• 3.3.7 Redundant Entry: Don’t force people to re-enter information they’ve already provided in the same process. Auto-fill it or let them select it instead—unless it’s essential for security, like confirming a password.

Level AA criteria (the legal standard)

These five criteria are where most compliance efforts should concentrate.

• 2.4.12 Focus Not Obscured (Enhanced): A stricter version of 2.4.11—no part of a focused element may be hidden by author-created content.
• 2.4.13 Focus Appearance: Focus indicators must be clearly visible: at least 2 CSS pixels thick with a 3:1 contrast ratio against adjacent colors. This finally gives the vague “make focus visible” rule something testable.
• 2.5.7 Dragging Movements: Any feature that relies on dragging—sliders, sortable lists, drag-and-drop uploads—must offer a single-pointer alternative like buttons. This helps users with tremors, limited dexterity, or screen readers.
• 2.5.8 Target Size (Minimum): Interactive targets like buttons and links must be at least 24×24 CSS pixels, with sensible exceptions for inline text links. Small targets are hard to hit for users with motor impairments and anyone on a touchscreen.
• 3.3.8 Accessible Authentication (Minimum): Logins can’t depend on a cognitive test like remembering a password or solving a puzzle, unless an alternative exists. Support password managers, send email or SMS codes, or allow biometrics. Avoid distorted-text CAPTCHAs.

Level AAA criterion (best practice)

• 3.3.9 Accessible Authentication (Enhanced): The same rule as 3.3.8 but with no exceptions, including object recognition. Most organizations won’t target this, but government and healthcare services should.

How do you implement WCAG 2.2 correctly?

Rolling out WCAG 2.2 works best in phases, starting with high-impact, low-effort wins and building from there.

Phase 1 — Quick wins (weeks 1–2). Start with the changes that take the least effort and deliver the most value. Audit every button, link, and input to meet the 24×24 pixel target size (2.5.8). Standardize where your help mechanisms sit on every page template (3.2.6). Add “same as shipping” checkboxes and autocomplete attributes to cut redundant entry (3.3.7).

Phase 2 — Forms and authentication (weeks 3–4). Enable password manager support, stop blocking paste in verification fields, and replace inaccessible CAPTCHAs with invisible alternatives (3.3.8). Then audit your drag-based features and add button or keyboard alternatives (2.5.7).

Phase 3 — Focus management (weeks 5–6). Add scroll-margin-top to focusable elements so sticky headers never obscure them (2.4.11 and 2.4.12). Apply a consistent, high-contrast focus outline across your whole site (2.4.13). A simple global rule covers most cases:

*:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
  scroll-margin-top: 100px;
}

One important warning: accessibility overlays and widgets cannot make you WCAG 2.2 compliant. Criteria like Focus Not Obscured and Dragging Movements require real changes to your source code, not a script bolted on top. The W3C and disability advocates consistently advise against overlay-based shortcuts.

How do you test for WCAG 2.2 compliance?

Testing combines automated tools with hands-on checks, because software alone catches only part of the picture—roughly 40% of WCAG 2.2 issues.

Start with automated scanners to flag the obvious problems:

• axe DevTools — a browser extension that detects WCAG 2.2 violations.
• WAVE — WebAIM’s visual tool that maps issues directly onto your page.
• Lighthouse — built into Chrome DevTools, with accessibility scoring.

Then test the things machines miss. Tab through your entire site with only a keyboard and confirm focus is always visible and never hidden. Measure your touch targets in DevTools. Try your login flow with a password manager. Walk through multi-step forms looking for repeated entry. Finally, test with real screen readers like NVDA on Windows or VoiceOver on Mac, and where possible, involve users with disabilities.

Make accessibility part of how you build

WCAG 2.2 isn’t a box to tick once and forget. It’s a clearer, more practical standard that reflects how people genuinely use the web—on phones, with keyboards, and with assistive technology. Meeting it widens your audience, lowers your legal exposure, and produces a better experience for every visitor.

Don’t wait for a lawsuit or a regulatory deadline to act. Run an automated scan this week to see where you stand. Fix the quick wins first—target sizes, consistent help, redundant entry—then work methodically through forms, dragging alternatives, and focus management. Bake these checks into your design system and code reviews so new features ship accessible by default.

Accessibility is most affordable and effective when it’s built in from the start rather than retrofitted later. Pick one criterion, apply it to your highest-traffic pages, and build from there.

Frequently asked questions

Is WCAG 2.2 legally required?
Not universally yet, but it’s the recommended standard and the direction regulators are heading. The EU’s European Accessibility Act and the U.S. Section 508 framework are updating to reference WCAG 2.2, and courts increasingly cite it in ADA cases. Implementing it now keeps you ahead of mandates.

Do I need to redo my WCAG 2.1 audit for 2.2?
No. WCAG 2.2 is additive and backward compatible. If you already conform to WCAG 2.1 Level AA, you only need to assess the 9 new criteria—6 of which apply at Level AA for most organizations. Your previous audit work remains valid.

How long does it take to become WCAG 2.2 compliant?
For most sites with moderate issues, expect 4 to 8 weeks. Simple sites can be done in 2 to 3 weeks, while complex web applications may take 2 to 3 months. A phased rollout that tackles quick wins first keeps progress steady.

Which new criteria should I prioritize?
Focus on the Level AA additions with the biggest user impact: Focus Not Obscured (2.4.11 and 2.4.12), Focus Appearance (2.4.13), Target Size (2.5.8), and Accessible Authentication (3.3.8). These address the most common failures and carry the most legal weight.

Can automated tools fully check WCAG 2.2 compliance?
No. Automated tools catch only about 40% of WCAG 2.2 issues. Criteria like consistent help, redundant entry, and accessible authentication need manual testing. Combine automated scans with keyboard testing, screen reader checks, and, ideally, testing with users who have disabilities.

Do accessibility overlays make my site WCAG 2.2 compliant?
No. Overlays and widgets can’t address most WCAG 2.2 requirements, which need source-code changes rather than surface-level fixes. The W3C and accessibility experts consistently recommend against relying on them.