WCAG & Web Accessibility
What is WCAG 2.2? Complete Breakdown of the 9 New Success Criteria
The Web Content Accessibility Guidelines (WCAG) serve as the foundation for international digital compliance laws, including ADA Title III, Revised Section 508, and the European Accessibility Act (EAA). Published by the W3C, WCAG 2.2 introduces official updates that specifically address modern mobile interaction patterns, cognitive accessibility barriers, and improved low-vision navigation.
For CTOs, Lead Developers, Product Managers, and Business Owners, adapting to WCAG 2.2 requires expanding your testing practices beyond legacy 2.0 and 2.1 frameworks.
Understanding the WCAG 2.2 new success criteria, how they impact your codebase, and why manual engineering audits are required will help your organization maintain full digital compliance.
What Changed in WCAG 2.2?
WCAG 2.2 adds 9 new success criteria (spread across Levels A, AA, and AAA) and officially deprecates 4.1.1 Parsing (which modern browsers now handle natively).
Because WCAG 2.2 is fully backwards-compatible, conforming to WCAG 2.2 Level AA automatically covers all requirements from WCAG 2.1 AA and 2.0 AA.
Success Criteria | Conformance Level | Target Persona | Core Requirement |
2.4.11 Focus Not Obscured (Minimum) | Level AA | Keyboard Users / Low Vision | Focused components must not be completely hidden by sticky headers, footers, or banners. |
2.4.12 Focus Not Obscured (Enhanced) | Level AAA | Keyboard Users / Low Vision | No portion of a focused element may be hidden by author-created overlays. |
2.4.13 Focus Appearance | Level AAA | Low Vision / Keyboard Users | Focus indicators must meet strict thickness (min 2px) and 3:1 contrast ratios. |
2.5.7 Dragging Movements | Level AA | Motor Impairments | Drag-and-drop actions must have a single-pointer alternative (e.g., tap or click buttons). |
2.5.8 Target Size (Minimum) | Level AA | Mobile / Motor Impairments | Clickable pointer targets must be at least 24x24 CSS pixels or have equivalent spacing. |
3.2.6 Consistent Help | Level A | Cognitive / Learning Needs | Help options (chat, contact links) must sit in the same relative position across pages. |
3.3.7 Redundant Entry | Level A | Cognitive / Motor Impairments | Don't make users re-enter previously provided information in the same session. |
3.3.8 Accessible Authentication (Minimum) | Level AA | Cognitive / Learning Needs | Logins must not require cognitive function tests (like memorizing passwords or solving CAPTCHAs) without alternatives. |
3.3.9 Accessible Authentication (Enhanced) | Level AAA | Cognitive / Learning Needs | Strict authentication that prohibits object recognition or user-supplied image identification. |
Technical Breakdown: Real-World Code Examples & Criteria
Six of the nine new criteria sit at Levels A and AA, making them mandatory targets for legal compliance and B2B procurement.
1. WCAG 2.4.11: Focus Not Obscured (Minimum) — Level AA
When keyboard users tab through a website, sticky headers, fixed cookie banners, or floating support widgets often obscure the focused element. Under 2.4.11, the focused element cannot be completely covered.
CSS
/* FIX: Use CSS scroll-padding so sticky headers don't hide focused elements */
html {
scroll-padding-top: 5rem; /* Matches height of fixed navigation header */
}
:focus-visible {
outline: 3px solid #005fcc;
outline-offset: 2px;
}
2. WCAG 2.5.7: Dragging Movements — Level AA
Interfaces that rely exclusively on click-and-drag interactions (such as Kanban boards, drag-and-drop file uploaders, or price range sliders) exclude users with fine motor control limitations.
The Code Fix: Provide explicit single-click controls (e.g., "Move Up", "Move Down", or number input fields) alongside drag features.
3. WCAG 2.5.8: Target Size (Minimum) — Level AA
Touch targets and clickable buttons must be at least 24x24 CSS pixels or provide sufficient offset spacing. Small 16px icon buttons packed closely together in mobile navigation bars trigger high failure rates.
Incorrect — Target is too small
button style="width: 16px; height: 16px;" aria-label="Delete"
The button uses a 16 × 16px target, which is too small for WCAG 2.5.8.
Correct — Accessible target size
button style="min-width: 24px; min-height: 24px; padding: 8px;" aria-label="Delete"
Inside the button:
svg aria-hidden="true" width="16" height="16" ...
4. WCAG 3.3.7: Redundant Entry — Level A
Users should never be forced to re-type information previously entered during a multi-step workflow (e.g., shipping vs. billing addresses during checkout).
The Code Fix: Offer a "Same as shipping address" checkbox or auto-populate previously entered data into subsequent form fields.
5. WCAG 3.3.8: Accessible Authentication (Minimum) — Level AA
Authentication flows must not force users to pass a cognitive function test (e.g., memorizing passwords, solving visual CAPTCHA puzzles, or typing one-time passcodes without paste support).
The Code Fix: Allow password managers, enable copy-and-paste on OTP/password fields, or support WebAuthn/passkeys and magic login links.
Why Automated Scanners and Overlay Widgets Fail WCAG 2.2
Achieving WCAG 2.2 AA compliance requires testing human interaction patterns. Automated tools and free client-side overlay widgets cannot verify the new 2.2 standards.
Automated Scanners Miss 70% of WCAG 2.2 Criteria
Automated testing tools (axe-core, WAVE, Lighthouse) inspect static DOM nodes.
Automated scanners miss up to 70% of real-world WCAG violations:
Cannot Test Cognitive Login Requirements (3.3.8): Scanners cannot evaluate whether a CAPTCHA puzzle or password field blocks copy-paste functionality.
Cannot Evaluate Drag Alternatives (2.5.7): Automated tools cannot determine if a complex drag-and-drop workflow offers single-pointer button alternatives.
Cannot Verify Focus Obscuration (2.4.11): Scanners do not simulate physical keyboard tab events to check if fixed headers cover focused form controls.
The Risk of Overlay Widgets
Third-party JavaScript overlay widgets attempt to alter visual pages dynamically. Overlays do not alter underlying application source code, fail to fix broken DOM focus states, and cannot remediate backend authentication barriers. Enterprise buyers and regulatory authorities explicitly reject overlay widgets.
Automated Scanners vs. Manual Audits for WCAG 2.2
WCAG 2.2 Evaluation Criteria | Automated Scanning Scripts | Manual Expert Engineering Audit |
Static HTML Syntax Checking | ✅ High Speed & Accuracy | ✅ Verified during review |
Minimum Target Size (2.5.8) | ⚠️ Static CSS checks only | ✅ Evaluates dynamic touch & offset spacing |
Focus Not Obscured (2.4.11) | ❌ Cannot simulate keyboard tab focus | ✅ Manually tested with keyboard flows |
Dragging Alternatives (2.5.7) | ❌ Cannot test drag gesture logic | ✅ Manually verified across pointer interactions |
Accessible Authentication (3.3.8) | ❌ Cannot test login mechanisms | ✅ Tested across passkeys, paste, & OTP flows |
Procurement VPAT Acceptance | ❌ Fails legal verification | ✅ High (backed by certified expert ACR) |
Prepare Your Codebase for WCAG 2.2 Compliance
Adopting WCAG 2.2 AA standards protects your platform from legal liability while improving conversion rates and user experience across desktop and mobile devices.
At accessibilitywebtest.com, our certified web accessibility engineers perform manual keyboard, screen reader, and code-level audits to guide your engineering team through WCAG 2.2 remediation.
Auditing web platforms or SaaS applications for WCAG 2.2? Explore our Web Accessibility Testing Services.
Testing native iOS and Android apps? Learn about our Mobile Accessibility Testing Services.
Updating your VPAT / ACR documentation to WCAG 2.2? Review our VPAT Audit & ACR Services and Section 508 Compliance Testing Services.
Targeting Indian public sector requirements? See our specialized GIGW 3.0 Compliance Services.
Building a fully compliant platform from scratch? Work with our team on Accessible Website Development Services.
Learn more about our team: Visit our About Us Page.
Ready to upgrade your platform to WCAG 2.2? Contact our lead auditors today to schedule a comprehensive audit.