Skip to main content
My Blog
Insights & Stories

Explore my latest thoughts on design, development, branding, and the creative process.

Back to Blog
Accessibility11 min read
WCAG 2.1 vs WCAG 2.2: What Changed and What Your Site Needs to Do

WCAG 2.2 was published in October 2023 with new success criteria and one removed. Here's a plain-language breakdown of what changed and where to focus first.

E
Excelle Escalada
Digital Experience Architect • Mar 11, 2024

Why the version number actually matters

For most organizations, WCAG compliance is a target, not a moving destination. You get an accessibility audit, fix the issues, update your statement, and move on. When the spec itself updates, it creates real questions: do we need to do another full audit? Do the new criteria apply to us? Are we still compliant?

WCAG 2.2, published by the W3C in October 2023, is not a complete rewrite. It's an incremental update that adds new success criteria focused on mobile interaction, cognitive load, and authentication, while removing one criterion that had become obsolete. Most organizations that are compliant with WCAG 2.1 AA won't have dozens of new issues — but some of the new criteria address patterns that are genuinely common on public-facing websites.

This post explains what changed, what stayed the same, and how to prioritize if you're starting from scratch.

What WCAG 2.2 kept from 2.1

All of the WCAG 2.1 success criteria carry forward into 2.2 with one exception. If you're already working toward WCAG 2.1 AA compliance, everything you've done still counts. WCAG 2.2 builds on 2.1 rather than replacing it.

This means WCAG 2.2 AA compliance is a strict superset of WCAG 2.1 AA compliance. You can't be WCAG 2.2 AA compliant without also meeting WCAG 2.1 AA.

What was removed: 4.1.1 Parsing

WCAG 2.2 removed criterion 4.1.1 Parsing, which required HTML to use valid markup so assistive technologies could interpret it correctly. The removal wasn't because parsing stopped mattering — it's because modern browsers and assistive technologies have become robust enough to handle malformed HTML in ways that make the original criterion largely unenforceable and inconsistently tested.

If you've previously failed audits on 4.1.1 (duplicate IDs, unclosed tags, attribute errors), those specific findings are no longer WCAG failures under 2.2. That said, clean, valid HTML is still good practice and may still surface as a best-practice recommendation rather than a compliance failure.

New criteria in WCAG 2.2

2.4.11 Focus Appearance — Level AA

This new criterion requires that keyboard focus indicators be visible, with a minimum area and contrast. Specifically, the focus indicator must:

  • Have a focus indicator area of at least the perimeter of the focused component times 2 CSS pixels
  • Have a contrast ratio of at least 3:1 between the focused and unfocused states

    • In plain language: focus indicators must be large enough and visible enough to distinguish clearly. The practice of hiding the browser's default focus outline with outline: none without providing an adequate alternative fails this criterion.

    This is one of the most commonly violated new criteria on existing sites because many design systems suppressed focus rings entirely for aesthetic reasons. If your site uses outline: none in its base CSS without providing a visible alternative, this is likely a 2.2 failure.

    2.4.12 Focus Appearance (Enhanced) — Level AAA

    A higher bar for focus indicators: the focus indicator area must have a 3:1 contrast ratio with adjacent colors and enclose the entire component. This is AAA-level, so it's not required for standard compliance — but it's worth knowing if you're building toward best-in-class accessibility.

    2.5.7 Dragging Movements — Level AA

    Any functionality that depends on dragging gestures (slider controls, drag-and-drop sorting, map panning) must also be available using a simple pointer interaction (a single click, tap, or press). This addresses users who have difficulty performing dragging gestures due to motor impairments.

    If your site includes any drag-to-reorder, drag-to-resize, or draggable map or carousel components, check whether there's an equivalent non-drag interaction.

    2.5.8 Target Size (Minimum) — Level AA

    Interactive targets (links, buttons, form controls) must be at least 24 by 24 CSS pixels, unless there's adequate spacing between targets or the target size is determined by the browser's default and not modified.

    This is less strict than the WCAG 2.1 AAA criterion for target size (which required 44 by 44 pixels) but addresses the pattern of very small clickable icons or tightly packed navigation links on mobile that are difficult to activate accurately.

    3.2.6 Consistent Help — Level A

    If your site offers a help mechanism (a contact link, a help chatbot, a FAQ link, a phone number) it must appear in the same location across pages that include it. This prevents users who rely on help mechanisms from having to search for them on each page.

    For most websites with a consistent footer or global navigation, this criterion is met by default. Issues arise on pages with non-standard layouts, modal overlays, or checkout funnels where the help mechanism is removed.

    3.3.7 Redundant Entry — Level A

    When a user is completing a multi-step process, they shouldn't have to re-enter information they've already provided in the same session — unless re-entering is essential (like confirming a password). This addresses checkout and application workflows where users are asked for the same data multiple times.

    For informational websites with minimal form interaction, this criterion is rarely relevant. For service portals, application forms, or multi-step booking or request flows, it's worth reviewing.

    3.3.8 Accessible Authentication (Minimum) — Level AA

    Authentication processes (login, verification, CAPTCHA) cannot require users to solve cognitive function tests — unless an alternative is provided or the test only asks users to recognize objects (not text-based puzzles). The purpose is to ensure that users with cognitive disabilities can log in without being blocked by tests that depend on abilities they may not have.

    Common CAPTCHA implementations using distorted text fail this criterion. Image selection CAPTCHAs ("select all traffic lights") may also fail depending on implementation. Providing an audio alternative or a magic-link email option typically satisfies this criterion.

    3.3.9 Accessible Authentication (Enhanced) — Level AAA

    A stricter version of 3.3.8 that allows no cognitive function tests at all, even object-recognition ones. AAA-level, not required for standard compliance.

    What to tackle first if you're starting from scratch

    If your organization is beginning an accessibility improvement program and isn't sure whether to target 2.1 or 2.2, targeting 2.2 AA from the start is the right approach — it's the current version and any future legal or procurement references will likely cite 2.2.

    Here's a practical priority order for the new 2.2 criteria specifically:

    1. Fix focus visibility (2.4.11) first. This is the highest-impact new criterion for most websites. Audit your CSS for outline: none or outline: 0 and ensure that every interactive element has a visible, contrasting focus state.

    2. Review CAPTCHA and authentication flows (3.3.8). If you have a login portal, application form, or user account system, check whether your verification method uses a cognitive test. This is a Level AA criterion and a real barrier for users with cognitive disabilities.

    3. Check dragging interactions (2.5.7). If your site uses drag-based UI components, confirm that each one has a keyboard or tap equivalent. Most modern component libraries provide this by default, but custom implementations often don't.

    4. Check target sizes on mobile (2.5.8). Test your navigation and inline links on a mobile viewport. Any target smaller than 24 by 24 CSS pixels without adequate spacing is a potential failure.

    5. Review redundant entry in forms (3.3.7). If you have multi-step forms, confirm you're not asking users for data they've already provided.

    6. Confirm help consistency (3.2.6). If you have a help mechanism anywhere on the site, verify it's consistently placed on every page that shows it.

    How WCAG 2.2 affects AODA compliance for Ontario organizations

    The Accessibility for Ontarians with Disabilities Act (AODA) currently references WCAG 2.0 Level AA as its technical standard for web content. As of this post, AODA has not been formally updated to require WCAG 2.1 or 2.2.

    However, WCAG 2.2 is the current specification, and best practice is to target it. Organizations undergoing procurement or accessibility audits are increasingly being evaluated against 2.1 or 2.2. Meeting 2.2 AA is more defensible than meeting the minimum legally referenced standard, and the additional criteria in 2.2 address patterns that AODA's enforcement focus has highlighted (particularly around mobile usability and authentication).

    Accessibility standards are moving targets, and keeping up while managing a website is a real challenge. Get in touch if you'd like help auditing your site against WCAG 2.2 or planning a remediation roadmap.

    Share this article

    More Articles