WCAG 2.2 vs WCAG 2.1: What's New and What You Need to Update

<p>More than 96% of homepages still fail basic WCAG requirements, according to WebAIM's 2024 accessibility analysis — and that's against a standard that was already five years old. On October 5, 2023, the W3C published WCAG 2.2 as an official web standard, raising the bar with nine new success criteria and retiring one criterion that had become obsolete. If you manage a website, build digital products, or oversee compliance, this update isn't something you can defer indefinitely. Regulations in the EU, UK, and increasingly U.S. states are already moving to reference WCAG 2.2 as their benchmark.</p> <h2>A Quick History: From WCAG 2.1 to WCAG 2.2</h2> <p>The Web Content Accessibility Guidelines have evolved steadily since WCAG 2.0 launched in December 2008. WCAG 2.1 arrived in June 2018, adding 17 new success criteria with a particular focus on mobile users and people with low vision or cognitive disabilities. For five years, it served as the de facto compliance benchmark for laws like the ADA, Section 508, and the EU Web Accessibility Directive.</p> <p>WCAG 2.2 picks up exactly where 2.1 left off. The W3C initiated it with the explicit goal of continuing to improve accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices. That lineage matters because it means the update is evolutionary, not revolutionary — but it is still meaningful enough to require action on your part.</p> <p>One of the most important things to understand structurally is that WCAG 2.2 is fully backwards compatible with WCAG 2.1. Conforming to WCAG 2.2 automatically means you conform to WCAG 2.1 and WCAG 2.0 as well. If your organisation is currently compliant with WCAG 2.1 AA, you only need to address the new criteria introduced in 2.2 — you're not starting over. The W3C also advises that while WCAG 2.0 and 2.1 remain valid recommendations, organisations should use WCAG 2.2 to maximise the future applicability of their accessibility work.</p> <p>WCAG 2.2 is also widely expected to be the final dot-release of the WCAG 2.x family. The next major version, WCAG 3.0, is an entirely different beast — a ground-up rethink of how accessibility guidelines are structured. That makes WCAG 2.2 the definitive endpoint of a lineage stretching back to 2008, and the one you need to get right now.</p> <h2>The Numbers: What Actually Changed</h2> <p>Let's be precise about the scope of change. WCAG 2.1 contained 78 success criteria across three conformance levels (A, AA, and AAA). WCAG 2.2 adds nine new success criteria while removing one — Success Criterion 4.1.1 Parsing — leaving the total at 86 active criteria. Of those nine additions, two are at Level A, four are at Level AA, and three are at Level AAA.</p> <p>For the vast majority of organisations targeting Level AA compliance — the level referenced in most laws and regulations — the practical impact is six new criteria to implement. The three Level AAA additions are considered best practice and are often recommended for government and healthcare contexts, but they are not a hard legal requirement in most jurisdictions today.</p> <p>The new criteria primarily address four problem areas that real-world accessibility audits had repeatedly flagged as underserved by the existing standard: keyboard focus visibility, touch and pointer interactions, cognitive accessibility, and authentication barriers. These aren't theoretical concerns. They are the kinds of barriers that regularly prevent people with disabilities from completing everyday tasks like logging in, filling out a form, or navigating a page with a sticky header.</p> <h2>The Nine New Success Criteria Explained</h2> <p>Here is a breakdown of each new criterion, what it requires, and why it matters in practice. The criteria are presented by conformance level so you can prioritise your remediation work.</p> <h3>Level A (Minimum — Required for All)</h3> <ul> <li><strong>2.4.11 Focus Not Obscured (Minimum):</strong> When a UI component receives keyboard focus, it must not be entirely hidden by author-created content. The most common culprits here are sticky headers, floating cookie banners, and live chat widgets that sit on top of the page. If a user pressing Tab lands on a button that is completely covered by your sticky navigation bar, this criterion is violated. Note that <em>partially</em> obscured is acceptable at Level A — the element just can't be 100% hidden.</li> <li><strong>2.5.7 Dragging Movements:</strong> Any functionality that requires a dragging motion — think drag-and-drop file uploads, sortable list items, or slider controls — must also be operable with a single pointer action (such as a click or tap) without dragging. This is critical for users with motor impairments who cannot reliably execute controlled drag gestures. The requirement applies to author-created content; native browser behaviours are exempt.</li> </ul> <h3>Level AA (Required for Standard Compliance)</h3> <ul> <li><strong>2.4.12 Focus Not Obscured (Enhanced):</strong> A stricter version of 2.4.11. At Level AA, no part of the focus indicator may be hidden by author-created content when an element receives keyboard focus. This closes the loophole in the Level A version and requires that focused elements are fully visible — not just partially so.</li> <li><strong>2.5.8 Target Size (Minimum):</strong> The clickable or tappable area of interactive elements must be at least 24×24 CSS pixels, with specific exceptions for inline text links, user-agent-controlled elements, and cases where an equivalent 24×24 target exists nearby. This is a significant change from WCAG 2.1, where a 44×44 pixel target size was only recommended at the AAA level. Now a minimum baseline is enforceable at AA. Note that while 24×24px is the floor, the AAA criterion (2.5.5) still recommends 44×44px, and that remains the gold standard for touch-friendly design.</li> <li><strong>3.2.6 Consistent Help:</strong> If a website provides any help mechanisms — human contact details, self-help tools, automated chat, or a contact form — and those mechanisms appear on multiple pages, they must appear in the same relative position across those pages. Users who need help, especially those with cognitive disabilities, should always be able to find it in the same place without hunting.</li> <li><strong>3.3.7 Redundant Entry:</strong> Information that a user has already entered in a previous step of the same process must either be auto-populated for them or available to select, so they don't have to type it again. Think of multi-step checkout flows that ask for a billing address and then ask again for a shipping address — users should be offered a way to copy what they already entered. Exceptions are allowed when re-entering information is essential for security (like confirming a password) or when the previously entered data is no longer valid.</li> <li><strong>3.3.8 Accessible Authentication (Minimum):</strong> Cognitive function tests — such as solving a puzzle, memorising a password, or transcribing characters from an image CAPTCHA — must not be required as the sole means of authentication. An alternative method must be available, or a mechanism must assist the user (such as a password manager being permitted, or copy-paste being allowed into the password field). This criterion does not ban CAPTCHAs outright, but it does require that they are never the only option for users who cannot complete them.</li> </ul> <h3>Level AAA (Enhanced — Recommended but Not Mandatory for Most)</h3> <ul> <li><strong>2.4.13 Focus Appearance:</strong> When the keyboard focus indicator is visible, it must meet specific minimum size and contrast requirements: the focus area must be at least as large as a 2 CSS pixel thick perimeter around the element, and there must be a contrast ratio of at least 3:1 between the focused and unfocused states. This criterion was originally planned for Level AA but was moved to AAA due to its complexity. It means that for AA-only compliance, there is still no normatively defined minimum size for a focus indicator — only that one must be visible.</li> <li><strong>2.5.9 Dragging Movements (Enhanced):</strong> Wait — there is no 2.5.9 in this release. The AAA dragging enhancement is captured within 3.3.9 below.</li> <li><strong>3.3.9 Accessible Authentication (Enhanced):</strong> A stricter version of 3.3.8. At Level AAA, object recognition and personal content tests (like "click all the traffic lights" or "select photos from your account") are also prohibited, not just the exceptions carved out at Level AA. Only two exceptions remain instead of four.</li> </ul> <h2>What Was Removed: 4.1.1 Parsing</h2> <p>WCAG 2.2 removes one success criterion that had been in place since WCAG 2.0: 4.1.1 Parsing. This criterion originally required HTML to be well-formed, with complete start and end tags, proper nesting, and no duplicate attributes. The intent was to ensure that browsers and assistive technologies could reliably parse markup and present content correctly to users.</p> <p>The removal isn't controversial — it reflects a genuine shift in the technical landscape. Since 2008, browsers have become extraordinarily good at gracefully handling malformed HTML, following a consistent, standardised error-correction algorithm. Assistive technologies like screen readers now rely on the browser's Document Object Model (DOM), not raw HTML source code. The W3C concluded that the criterion no longer provides any meaningful accessibility benefit in the modern environment. Accessibility issues that used to be caught by 4.1.1 are still covered by more specific criteria like 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value).</p> <p>The practical implications for your team: if your automated testing tools have been flagging 4.1.1 Parsing failures, those are no longer WCAG 2.2 issues. You may see a reduction in reported failures purely from the version upgrade, not because anything was fixed. That said, writing valid, well-structured HTML remains a strong best practice — it's just no longer a compliance requirement on its own.</p> <h2>Regulatory and Legal Implications</h2> <p>Understanding the new criteria is one thing. Understanding what they mean for your legal exposure is another. The short answer is: WCAG 2.2 is becoming the law of the land across multiple jurisdictions, and the timeline is moving faster than many organisations realise.</p> <p>In the United Kingdom, public sector bodies are already required to meet WCAG 2.2 Level AA under the Public Sector Bodies Accessibility Regulations. In the European Union, EN 301 549 — the technical standard that underpins the European Accessibility Act — is in the process of adopting WCAG 2.2 as its baseline. The EAA itself has a June 2025 enforcement deadline for most private sector organisations offering products and services in the EU. Several U.S. states, including Colorado, have also expressed intent to update their state accessibility laws from WCAG 2.1 to WCAG 2.2.</p> <p>In the United States, ADA Title II currently references WCAG 2.1 AA as the technical standard for state and local government websites. However, U.S. courts have increasingly cited WCAG 2.2 in accessibility lawsuits, and the trajectory is clear. Waiting for a formal federal mandate before acting is a compliance strategy that carries growing legal risk, particularly for e-commerce, financial services, and healthcare organisations that are high-value targets for accessibility litigation.</p> <blockquote> <p>Even if your organisation is not yet legally obligated to conform to WCAG 2.2, meeting the new success criteria sooner rather than later will ensure you stay ahead of changing regulations — and, more importantly, ahead of real accessibility barriers facing your users today.</p> </blockquote> <h2>How to Audit and Update Your Site</h2> <p>If you are already WCAG 2.1 AA compliant, the upgrade path to WCAG 2.2 is manageable. Here is a practical framework for approaching it.</p> <p><strong>Start with a targeted audit of the six new Level AA criteria.</strong> These are the ones that carry legal weight for most organisations. Focus especially on 2.4.11 and 2.4.12 (focus obscured), 2.5.8 (target size), 3.2.6 (consistent help), 3.3.7 (redundant entry), and 3.3.8 (accessible authentication). A skilled accessibility engineer can typically audit these criteria manually in a few hours for a site of moderate complexity.</p> <p><strong>Audit your sticky/fixed-position elements first.</strong> The focus obscured criteria (2.4.11 and 2.4.12) are violated by some of the most common UI patterns on the web — sticky headers, floating action buttons, cookie consent bars, and chat widgets. Walk through your entire site using only the Tab key and observe whether any focused element ever disappears beneath a fixed layer. A CSS fix is usually straightforward:</p> <pre><code>/* Prevent sticky header from covering focused elements */ :focus { scroll-margin-top: 80px; /* match your sticky header height */ }</code></pre> <p><strong>Audit every interactive element's tap target size.</strong> This is often a quick win in terms of both compliance and user experience. Buttons, links, form controls, and icons all need a 24×24 CSS pixel minimum. Many design systems already exceed this threshold, but small icon buttons — close icons, social share buttons, and inline action links — are frequent offenders. Inspect your components and add padding or adjust dimensions where needed.</p> <p><strong>Review your authentication flows carefully.</strong> SC 3.3.8 (Accessible Authentication) has real teeth. If you use a CAPTCHA that cannot be bypassed or solved via an alternative method, you are likely non-compliant. Evaluate whether your login, registration, and two-factor authentication flows permit password managers to autofill, allow copy-paste, offer an alternative verification method (like a magic link or one-time code), or provide any other accommodation for users who cannot complete a cognitive challenge.</p> <p><strong>Audit multi-step forms for redundant entry.</strong> Map out any processes that span multiple steps — checkouts, onboarding flows, applications — and identify every instance where a user is asked to provide information they already supplied. Add auto-population logic or a "same as above" toggle where applicable. This is typically a back-end or form-state management change rather than a complex architectural overhaul.</p> <p><strong>Verify that help mechanisms are consistently positioned.</strong> If you have a chat widget, a help link, or a phone number that appears in a footer or sidebar across multiple pages, check that its relative position doesn't shift. This is usually a template or layout issue rather than a page-by-page problem — fix it in your component library or CMS template and it propagates everywhere.</p> <p><strong>Use automated tools for initial discovery, but don't stop there.</strong> Automated scanners can detect roughly 40% of WCAG 2.2 issues — they are useful for catching target size violations and obvious focus management problems, but they cannot evaluate whether a CAPTCHA is the only authentication option or whether a help mechanism is consistently positioned. Manual testing, including keyboard-only navigation and screen reader testing, remains essential. Testing with real users who have disabilities will catch issues that no automated tool ever will.</p> <h2>WCAG 2.2 and Overlay Widgets: What You Should Know</h2> <p>Accessibility overlay widgets and SDKs — tools like Accsible — can provide meaningful assistance in surfacing and remediating certain categories of accessibility issues, particularly for users who need real-time adjustments like increased font size, contrast changes, or keyboard navigation enhancements. It is worth being clear-eyed about what overlays can and cannot do in the context of WCAG 2.2 compliance.</p> <p>Overlays can help address certain focus visibility issues, provide alternative navigation modes, and offer user-side customisation that compensates for some design-level shortfalls. They are a useful layer of the accessibility stack, especially for teams that need to improve the user experience quickly while longer-term remediation work is underway. However, they are not a substitute for fixing the underlying code. The new WCAG 2.2 criteria — particularly around authentication (3.3.8), redundant entry (3.3.7), and dragging movements (2.5.7) — require structural changes to how your application is built, not just how it is presented.</p> <p>The most effective approach combines a well-implemented overlay for user-facing adaptability with proper code-level fixes for the new 2.2 criteria. Think of an overlay SDK as a force multiplier: it extends your reach, improves the experience for more users, and fills gaps — but the foundation still has to be sound.</p> <h2>Key Takeaways</h2> <ul> <li><strong>WCAG 2.2 adds nine new success criteria and removes one obsolete rule (4.1.1 Parsing).</strong> It is fully backwards compatible with 2.1, so your existing compliance work is not wasted — you only need to layer on what's new.</li> <li><strong>For Level AA compliance, focus on six specific new criteria:</strong> Focus Not Obscured (2.4.11 and 2.4.12), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7), and Accessible Authentication (3.3.8). These are the legally relevant ones for most organisations.</li> <li><strong>Regulatory adoption is accelerating.</strong> The UK public sector already enforces WCAG 2.2, the EU is transitioning to it under the European Accessibility Act, and U.S. courts are increasingly citing it. Don't wait for a formal mandate in your jurisdiction before acting.</li> <li><strong>Automated tools only catch about 40% of WCAG 2.2 issues</strong> — manual testing, keyboard-only navigation walkthroughs, and real-user testing are essential to achieving genuine compliance, especially for the new criteria around authentication and cognitive accessibility.</li> <li><strong>The most common quick wins are fixing sticky headers that obscure focused elements, enlarging small tap targets, and auditing your login/authentication flows</strong> for CAPTCHA dependency. These changes are often lower effort and high impact — a good place to start your WCAG 2.2 remediation sprint.</li> </ul>