WCAG 2.2 Compliance: What U.S. Companies Must Know in 2026

WCAG 2.2 is now the de facto legal standard for web accessibility in the United States. The Web Content Accessibility Guidelines 2.2, published by the W3C in October 2023 and announced by the U.S. Access Board as the new international benchmark, adds nine new success criteria that specifically address mobile usability, cognitive accessibility, and low-vision user needs. For U.S. companies, this matters because the Department of Justice and plaintiffs' attorneys increasingly reference WCAG 2.2 as the benchmark for ADA compliance—making outdated 2.0 or 2.1 conformance a legal liability.

The numbers make the urgency clear. According to Seyfarth Shaw's 2024 Year-End Report, 8,800 ADA Title III lawsuits were filed in federal courts in 2024—a 7% increase from 2023. TestParty research based on Court Listener data shows that 40%+ of digital accessibility lawsuits target repeat defendants who failed to adequately remediate after initial suits. The WebAIM Million 2024 analysis found that 95.9% of homepages had detectable WCAG failures, with an average of 56.8 errors per page—and many of these map directly to WCAG 2.2's new requirements around focus visibility, target sizes, and authentication flows.

For engineering and product teams, WCAG 2.2 represents a manageable upgrade rather than a complete overhaul. If your site already meets WCAG 2.1 AA, you're addressing a handful of additional criteria. But if you've been operating on outdated standards, the gap has widened significantly—and plaintiffs' firms know exactly how to identify it.

Key Takeaways

Understanding WCAG 2.2 requirements helps U.S. companies avoid legal exposure while delivering better user experiences.

• Nine new success criteria – WCAG 2.2 adds requirements for focus visibility, dragging alternatives, target sizes, consistent help, and accessible authentication that weren't covered in 2.1
• Legal benchmark shift – While the ADA doesn't codify a specific standard, DOJ guidance and court precedent now treat WCAG 2.2 as the expected conformance level for websites
• Backward compatible – Content meeting WCAG 2.2 also satisfies 2.1 and 2.0 requirements, with one exception: the removal of the obsolete 4.1.1 Parsing criterion
• Mobile and cognitive focus – The new criteria specifically address smartphone users, people with cognitive disabilities, and low-vision users—populations underserved by previous guidelines
• Engineering integration required – These requirements cannot be addressed by overlays or automated widgets; they require changes to source code, design systems, and CI/CD workflows

What WCAG Is (and Is Not)

The Web Content Accessibility Guidelines are an internationally recognized set of technical standards developed by the W3C's Web Accessibility Initiative. They define how to make websites, web applications, and digital content usable by people with disabilities—covering everything from alternative text for images to keyboard navigation patterns.

WCAG is not a law itself. Instead, laws like the Americans with Disabilities Act (ADA), Section 508, and the European Accessibility Act use WCAG as their technical benchmark. Think of WCAG as the rulebook that regulations reference: it provides the specific, testable criteria that determine whether a digital experience meets accessibility requirements.

The guidelines are organized around four principles known as POUR: content must be Perceivable, Operable, Understandable, and Robust. Each principle contains success criteria at three levels—A (minimum), AA (standard), and AAA (enhanced). Most legal requirements and industry standards target Level AA conformance, which balances usability improvements with implementation feasibility. For a complete breakdown, see our guide to What Is WCAG 2.2?

What Changed from WCAG 2.1 to 2.2

WCAG 2.2 introduces nine new success criteria while removing one outdated requirement. According to W3C's official summary, the additions address real-world gaps that 2.1 didn't fully cover, particularly for mobile users and people with cognitive disabilities.

The removed criterion is 4.1.1 Parsing, which required HTML to be well-formed. Modern browsers have become sophisticated enough to handle parsing errors gracefully, making this criterion obsolete for practical accessibility. This is the only case where 2.2 is less restrictive than 2.1.

The new success criteria focus on three major areas. First, visibility and focus indicators—ensuring users can always see where they are on a page. Second, interaction alternatives—providing non-drag options and adequate touch targets. Third, cognitive load reduction—making authentication easier and help consistently available.

For organizations already compliant with WCAG 2.1 AA, the 2.2 upgrade requires addressing five new AA-level criteria. Teams starting from 2.0 or lower face a larger implementation scope, as they must also incorporate the AA criteria introduced in 2.1. For a detailed comparison, see WCAG 2.2 vs 2.1: What Changed.

New Success Criteria Explained in Plain English

The nine new WCAG 2.2 success criteria translate into specific technical requirements that engineering teams can implement and test.

Focus Not Obscured (Minimum) — Level AA

When keyboard users Tab through interactive elements, the focus indicator must not be completely hidden by other page content. This commonly fails when sticky headers, cookie banners, or chat widgets cover the currently focused element. The fix requires adjusting z-index values, scroll behaviors, or positioning logic to ensure the focus ring remains visible.

Focus Not Obscured (Enhanced) — Level AAA

The stricter version requires that focus indicators are entirely visible, not just partially exposed. While AAA conformance isn't typically required for legal compliance, this criterion reflects best practices for users who rely entirely on keyboard navigation.

Focus Appearance — Level AAA

This criterion specifies minimum size and contrast requirements for focus indicators themselves. Focus rings must have sufficient area and contrast against adjacent colors. Though AAA level, many organizations implement this for improved usability.

Dragging Movements — Level AA

Any functionality that requires dragging (reordering lists, moving items on a canvas, drag-to-upload) must have a single-pointer alternative. Users who cannot perform drag operations need another method—such as up/down buttons or a select-and-place interaction. This criterion is essential for motor-impaired users and those on touch devices where dragging is unreliable.

Target Size (Minimum) — Level AA

Interactive targets like buttons, links, and form controls must be at least 24×24 CSS pixels, or have sufficient spacing from adjacent targets. This addresses the frustration of tapping tiny links on mobile devices and benefits users with limited dexterity. The fix typically involves increasing padding, adjusting touch target areas, or spreading out interactive elements.

Consistent Help — Level A

If a page provides help mechanisms (contact links, chat support, FAQ links), those mechanisms must appear in the same relative location across all pages. Users shouldn't have to hunt for assistance on each new page. This is a straightforward implementation requiring consistent placement in headers, footers, or navigation.

Redundant Entry — Level A

When users have already provided information in a process, that information should be auto-populated or selectable rather than requiring re-entry. This reduces cognitive load during multi-step forms like checkout or account creation. Implementations include auto-fill for shipping addresses when billing matches, or dropdowns pre-populated with previously entered data.

Accessible Authentication (Minimum) — Level AA

Authentication processes should not rely solely on cognitive function tests like remembering passwords or solving puzzles. Users must have alternatives: copy-paste support for verification codes, "show password" toggles, authentication apps, or biometric options. This criterion specifically addresses CAPTCHAs, which frequently exclude users with cognitive or visual disabilities.

Accessible Authentication (Enhanced) — Level AAA

The stricter version prohibits cognitive tests entirely in authentication flows. While AAA level, many organizations implement this by offering passwordless authentication or passkey support.

For a complete technical breakdown, see our guide to WCAG 2.2 New Success Criteria.

Who Is Now at Legal Risk

WCAG 2.2 creates specific exposure for organizations that haven't updated their accessibility practices since the standard's October 2023 publication.

Legal Risk Assessment

The ADA doesn't explicitly mandate WCAG 2.2, but enforcement patterns have evolved. The DOJ's web accessibility guidance references WCAG as "helpful" for compliance, and subsequent settlements have incorporated WCAG 2.2 requirements. Plaintiffs' attorneys now specifically cite 2.2 failures—particularly focus visibility and target size issues—as evidence of accessibility barriers.

E-commerce companies face elevated risk. TestParty research based on Court Listener data shows that 77% of website accessibility lawsuits target e-commerce businesses, with Shopify stores representing 30%+ of platform-identified lawsuits. The combination of complex interactive elements (carousels, filters, checkout flows) and high traffic volumes makes e-commerce a preferred target for serial litigators.

Financial services and healthcare organizations face both ADA exposure and sector-specific regulations. The DOJ's Title II Final Rule requires state and local government entities to meet WCAG 2.1 Level AA by April 2026 or 2027, depending on population size. Banks must consider WCAG 2.2 requirements alongside existing compliance frameworks, while healthcare providers operating under DOJ oversight have explicit accessibility mandates.

Product and Engineering Impact

Product teams should map WCAG 2.2 criteria to their component libraries and design systems. Organizations using design systems need to audit buttons, form fields, navigation patterns, and modal dialogs against the new requirements. Common gaps include focus indicators that disappear behind sticky elements, touch targets under 24px, and authentication flows requiring password memorization.

Engineering teams need updated acceptance criteria for user stories. A button isn't complete until it has adequate target size and visible focus. A drag-and-drop feature isn't shippable without a keyboard/pointer alternative. These requirements should be part of definition-of-done checklists, not afterthought audits.

For teams facing tight timelines, our 90-day WCAG 2.2 implementation guide provides a prioritized remediation roadmap.

Mapping WCAG 2.2 to Engineering Workflows

Sustainable WCAG 2.2 compliance requires integration into existing development processes rather than periodic audit cycles.

Design System Updates

Component libraries should encode WCAG 2.2 requirements by default. Update button components to meet 24×24px minimum target sizes with appropriate padding. Ensure focus styles have adequate contrast and aren't overridden by theme customizations. Build dragging alternatives into any reorderable list or kanban-style component.

These changes benefit from documentation. Engineers implementing design system components should understand why focus indicators need specific contrast ratios, not just that they're required. This context prevents future regressions when developers modify styles.

CI/CD Integration

Automated testing catches many WCAG 2.2 violations before they reach production. Linters like eslint-plugin-jsx-a11y flag missing ARIA labels and improper role usage during development. Integration tests using axe-core or similar tools verify rendered components against WCAG criteria.

Specific checks for WCAG 2.2:

• Target size validation for interactive elements
• Focus order testing to ensure visible focus throughout user flows
• Form auto-fill support verification
• Keyboard alternative tests for drag interactions

These tests should run in CI pipelines on every pull request, catching issues before code review. Teams using TestParty can automate continuous monitoring against WCAG 2.2 criteria with source-code-level remediation.

Developer Training

Engineers need practical understanding of assistive technology usage. Having developers navigate their own features using only a keyboard reveals focus order problems. Screen reader testing (using NVDA on Windows or VoiceOver on macOS) exposes label and announcement issues that automated tools miss.

Training should cover the "why" behind requirements. Understanding that focus visibility helps keyboard-only users track their position makes the criterion memorable. Knowing that 24px targets benefit users with motor impairments—and according to CDC data, over 70 million U.S. adults have a disability—builds empathy that persists across projects.

Why Manual Audits Alone Fail at Scale

Relying exclusively on periodic manual audits leaves organizations vulnerable to compliance gaps and legal exposure.

The Scale Problem

Large websites accumulate thousands of pages and interactive states. A comprehensive manual audit covering every page, component, and user flow requires hundreds of hours. By the time auditors complete their review, new content has been published and features have shipped—potentially introducing fresh violations.

WCAG 2.2's criteria amplify this challenge. Testing focus visibility requires navigating through every interactive path while monitoring for obscured indicators. Verifying dragging alternatives means testing each drag-enabled feature for fallback options. Manual testing cannot scale to cover this breadth continuously.

The Temporal Problem

Point-in-time audits capture compliance status at a specific moment. Between audits, regressions accumulate. A developer removes a focus outline to address a design critique. A new modal component lacks keyboard trap handling. A marketing team publishes images without alt text. Each change potentially violates WCAG 2.2 criteria that passed in the previous audit.

The gap between audits creates legal exposure. If a plaintiff tests your site six months after your last audit and finds violations in recently published content, your audit report provides no defense.

The Continuous Alternative

Sustainable compliance requires automated continuous monitoring supplemented by periodic manual reviews. Automated tools scan for detectable violations across all pages daily or weekly, flagging regressions immediately. Manual testing by accessibility specialists covers judgment-dependent criteria (is this alt text actually descriptive?) and complex user flows.

This approach treats accessibility like security: ongoing vigilance rather than periodic assessments. For organizations managing WCAG 2.2 compliance at scale, continuous monitoring reduces risk while freeing specialists to focus on issues requiring human judgment.

How Continuous Testing Reduces Risk

Integrating accessibility testing throughout the development lifecycle catches issues early and prevents costly remediation backlogs.

Shift-Left Benefits

Fixing accessibility issues in development costs a fraction of post-deployment remediation. When a linter flags a missing form label during coding, the fix takes seconds. The same issue discovered in a legal demand letter triggers hours of developer time, legal consultation, and expedited deployment.

WCAG 2.2 criteria lend themselves to early detection. Target size violations appear in design reviews. Focus visibility issues surface in component testing. Authentication accessibility problems emerge during UX specification. Catching these upstream prevents them from reaching production.

Legal Risk Reduction

Serial plaintiffs' firms use automated scanning to identify targets. They look for obvious, easily provable violations: missing alt text, empty links, inadequate contrast. According to WebAIM's 2024 data, 54.5% of homepages have missing alt text and 81% have low-contrast text issues. Sites with continuous monitoring catch and fix these issues before they accumulate into lawsuit-worthy evidence.

Demonstrating continuous improvement also supports legal defense. Organizations that can show ongoing accessibility efforts, regular scanning reports, and responsive remediation present a stronger case than those with outdated audit reports and unchanged violations.

Business Benefits Beyond Compliance

Sites achieving continuous compliance differentiate themselves from the baseline where 95.9% of homepages have WCAG failures. Better accessibility correlates with improved SEO (search engines favor accessible markup), higher conversion rates (users complete tasks more easily), and expanded market reach. According to the World Economic Forum, the global disability community represents $13 trillion in annual spending power.

For detailed implementation guidance, see our guide to What's on a Complete WCAG Level AA Checklist.

FAQ

Is WCAG 2.2 legally required in the United States?

The ADA doesn't explicitly mandate WCAG 2.2, but it functions as the de facto standard. DOJ guidance references WCAG as a compliance benchmark, and courts consistently accept WCAG 2.2 as evidence of accessibility expectations. Organizations defending against ADA lawsuits without WCAG 2.2 conformance face an uphill battle explaining why they used outdated standards.

What's the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 adds nine new success criteria while removing one (4.1.1 Parsing). The additions focus on focus visibility, target sizes, dragging alternatives, consistent help placement, reduced redundant entry, and accessible authentication. Content conforming to WCAG 2.2 also meets 2.1 and 2.0 requirements. For a detailed comparison, see WCAG 2.2 vs 2.1: What Changed.

Can accessibility overlays make my site WCAG 2.2 compliant?

No. Overlay widgets cannot address WCAG 2.2's new criteria, which require source code changes. Target sizes must be increased in CSS. Dragging alternatives require JavaScript functionality. Focus visibility demands proper z-index management. The National Federation of the Blind's 2021 resolution explicitly opposes overlays, stating they "make misleading, unproven, and unethical claims." TestParty research based on Court Listener data shows 1,000+ businesses using overlays have still been sued for accessibility violations in 2023-2024.

How long does WCAG 2.2 compliance take?

Timeline depends on current compliance state and site complexity. Organizations already meeting WCAG 2.1 AA typically address 2.2's additional criteria within 30-90 days. Sites with significant technical debt may require 6-12 months for comprehensive remediation. The key is establishing continuous processes rather than aiming for one-time compliance.

Do small businesses need to comply with WCAG 2.2?

The ADA applies to businesses of all sizes operating as "places of public accommodation." E-commerce sites, regardless of revenue, have faced accessibility lawsuits. According to Seyfarth Shaw's data, 8,800 ADA Title III lawsuits were filed in 2024, targeting businesses across all size categories. Small businesses often become targets precisely because they're perceived as likely to settle quickly rather than litigate.

What's the penalty for non-compliance with WCAG 2.2?

There's no direct government penalty for WCAG non-compliance, but ADA lawsuits carry significant costs. Settlement payments typically range from $5,000 to $50,000, with legal fees often exceeding the settlement amount. Large organizations have paid settlements exceeding $500,000. Beyond direct costs, companies must fund remediation (often under court-mandated timelines) and may face repeat lawsuits if fixes prove inadequate—TestParty research shows 40%+ of lawsuits target previously sued defendants.

Related Resources

Internal Links

• What Is WCAG 2.2? Complete Guide to Web Content Accessibility Guidelines
• WCAG 2.2 New Success Criteria: Complete Implementation Guide
• WCAG 2.2 for Product Teams: What Changed and What to Do in 90 Days
• Accessibility Testing in CI/CD: A Complete Integration Guide
• What Is on the WCAG Level AA Checklist for 2026?
• What Is the Difference Between WCAG 2.2 and WCAG 2.1?

External Sources

• WCAG 2.2 Official Specification (W3C)
• What's New in WCAG 2.2 (W3C WAI)
• U.S. Access Board WCAG 2.2 Announcement
• DOJ Guidance on Web Accessibility and the ADA
• DOJ Title II Final Rule (April 2024)
• WebAIM Million 2024 Report
• Seyfarth Shaw ADA Title III 2024 Year-End Report
• CDC 2024 Disability Statistics
• NFB 2021 Resolutions on Accessibility Overlays
• World Economic Forum: Disability Spending Power

This article was written by TestParty's editorial team with AI assistance. All statistics and claims have been verified against primary sources. Last updated: January 2026.