TestParty

Blog

WCAG 2.2 Compliance: The Complete 2025 Guide for E-commerce Businesses

Michael Bervell
Michael Bervell
December 14, 2025

Last updated: December 2025

Digital accessibility is no longer optional. With over 4,000 ADA website lawsuits filed in 2024 alone—and a 37% surge in the first half of 2025—businesses that ignore web accessibility face mounting legal risk and lost revenue from the 61 million American adults living with disabilities.

WCAG 2.2, published in October 2023, is now the gold standard for digital accessibility compliance. This comprehensive guide covers everything you need to know about WCAG 2.2: what's new, how it differs from previous versions, legal requirements, and practical steps to achieve compliance.

What is WCAG 2.2?

The Web Content Accessibility Guidelines (WCAG) 2.2 is the latest version of the internationally recognized accessibility standard developed by the World Wide Web Consortium (W3C). It provides specific, testable success criteria for making web content accessible to people with disabilities, including those with visual, auditory, physical, speech, cognitive, and neurological disabilities.

WCAG 2.2 builds on WCAG 2.1 (published June 2018) and WCAG 2.0 (published December 2008), maintaining backward compatibility while adding nine new success criteria focused on:

  • Cognitive accessibility
  • Mobile usability
  • Low vision support
  • Motor disability accommodations

For a deeper dive into WCAG fundamentals, see our complete guide: What is WCAG 2.2? Complete Guide to Web Content Accessibility Guidelines.

The Four POUR Principles

All WCAG success criteria are organized under four foundational principles, remembered by the acronym POUR:

1. Perceivable

Information and user interface components must be presentable in ways users can perceive. This includes:

  • Text alternatives for non-text content (images, icons, buttons)
  • Captions and audio descriptions for multimedia
  • Sufficient color contrast between text and backgrounds
  • Adaptable content that can be presented in different ways

2. Operable

User interface components and navigation must be operable by all users:

  • Keyboard accessibility for all functionality
  • Adequate time to read and use content
  • Navigation aids like skip links and clear headings
  • No seizure-inducing content

3. Understandable

Information and operation of the user interface must be understandable:

  • Readable text at appropriate reading levels
  • Predictable behavior in navigation and functionality
  • Input assistance with clear labels and error messages

4. Robust

Content must be robust enough to work reliably with assistive technologies:

  • Valid, well-structured code
  • Proper ARIA implementation for custom components
  • Compatibility with current and future assistive technologies

WCAG 2.2 Conformance Levels: A, AA, and AAA

WCAG defines three conformance levels representing increasing degrees of accessibility:

Level A (Minimum)

Level A represents the most basic accessibility requirements. Failure at this level creates fundamental barriers that completely prevent some users from accessing content. Examples include:

  • 1.1.1 Non-text Content: All images need alternative text
  • 2.1.1 Keyboard: All functionality must work via keyboard
  • 3.3.1 Error Identification: Errors must be clearly identified

Level AA (Standard)

Level AA is the internationally accepted compliance target and the standard referenced by most accessibility laws, including ADA guidance, the European Accessibility Act, and Section 508. Level AA includes all Level A criteria plus additional requirements:

  • 1.4.3 Contrast (Minimum): Text must have 4.5:1 contrast ratio
  • 1.4.5 Images of Text: Real text preferred over images of text
  • 2.4.7 Focus Visible: Keyboard focus indicator must be visible

Level AAA (Enhanced)

Level AAA provides the highest accessibility but isn't typically achievable for all content types. While not legally required, implementing AAA criteria where practical strengthens your accessibility posture:

  • 1.4.6 Contrast (Enhanced): 7:1 contrast ratio for text
  • 2.1.3 Keyboard (No Exception): All functionality keyboard-accessible without exceptions

For detailed guidance on each level, see: WCAG Conformance Levels Explained: A, AA, and AAA Requirements.

What's New in WCAG 2.2: The 9 New Success Criteria

WCAG 2.2 introduces nine new success criteria addressing gaps identified since WCAG 2.1. Six are at Level AA (the legal compliance target), and three are at Level AAA.

Level A Criteria (2)

3.2.6 Consistent Help

Help mechanisms (contact information, FAQ links, chat widgets) repeated on multiple pages must appear in the same relative location on each page.

Why it matters: Users with cognitive disabilities rely on consistent placement to find help. A chat button that moves around the screen creates confusion and barriers.

Implementation example:

<!-- Good: Help always in footer, same position -->
<footer>
  <nav aria-label="Help">
    <a href="/contact">Contact Us</a>
    <a href="/faq">FAQ</a>
    <button id="chat-trigger">Live Chat</button>
  </nav>
</footer>

3.3.7 Redundant Entry

Information previously entered by users in a process must be auto-populated or available for selection. Users shouldn't have to re-enter the same information twice.

Why it matters: Re-entering information creates barriers for users with cognitive disabilities, motor impairments, or anyone using assistive technology where data entry is time-consuming.

Implementation example:

<!-- Checkbox to copy billing address to shipping -->
<fieldset>
  <legend>Shipping Address</legend>
  <input type="checkbox" id="same-address">
  <label for="same-address">Same as billing address</label>
</fieldset>

For e-commerce checkout implementations, see our guide: E-Commerce Checkout Accessibility: Complete WCAG Compliance Guide.

Level AA Criteria (4)

2.4.11 Focus Not Obscured (Minimum)

When an element receives keyboard focus, it must not be entirely hidden by other author-created content like sticky headers, footers, or modal dialogs.

Why it matters: Keyboard users rely on visible focus to navigate. When focused elements disappear behind sticky banners, users lose their place and can't complete tasks.

Implementation tips:

  • Use scroll-padding CSS to account for sticky elements
  • Ensure modals don't trap focus obscured behind overlays
  • Test tab navigation through your entire site
/* Account for 80px sticky header */
html {
  scroll-padding-top: 100px;
}

2.5.7 Dragging Movements

Any functionality that uses dragging (sliders, drag-and-drop, carousels) must provide a single-pointer alternative.

Why it matters: Users with motor disabilities, hand tremors, or those using assistive technology often cannot perform dragging movements reliably.

Implementation example:

<!-- Slider with button alternatives -->
<div role="slider" aria-valuenow="50">
  <button aria-label="Decrease">−</button>
  <input type="range" min="0" max="100" value="50">
  <button aria-label="Increase">+</button>
</div>

2.5.8 Target Size (Minimum)

Interactive targets (buttons, links, form controls) must be at least 24×24 CSS pixels, with exceptions for inline text links, spacing offsets, and user agent controls.

Why it matters: Small touch targets are difficult for users with motor impairments, hand tremors, or anyone using a mobile device.

Implementation example:

button, 
a.button,
input[type="submit"] {
  min-width: 44px;  /* Best practice exceeds minimum */
  min-height: 44px;
  padding: 12px 24px;
}

3.3.8 Accessible Authentication (Minimum)

Cognitive function tests (remembering passwords, solving puzzles, transcribing codes) must not be required for authentication unless alternatives are provided.

Why it matters: CAPTCHAs and complex password requirements create barriers for users with cognitive disabilities. Authentication should focus on security without requiring memorization or puzzle-solving.

Acceptable alternatives:

  • Password managers (allowing paste)
  • Biometric authentication
  • Magic links sent to email
  • OAuth/social login
  • Security keys
<!-- Allow password paste for password managers -->
<input type="password" 
       autocomplete="current-password"
       aria-describedby="password-help">
<p id="password-help">
  Password managers supported. You can paste your password.
</p>

Level AAA Criteria (3)

2.4.12 Focus Not Obscured (Enhanced)

The AAA version of 2.4.11—no part of the focused element may be hidden by author-created content (versus "not entirely hidden" at AA).

2.4.13 Focus Appearance

Focus indicators must meet specific size (at least 2px outline) and contrast requirements (3:1 against adjacent colors).

3.3.9 Accessible Authentication (Enhanced)

The AAA version of 3.3.8 with stricter requirements—no cognitive tests at all for authentication, even with alternatives.

WCAG 2.2 vs. WCAG 2.1: Key Differences

+------------------------+----------------------------------+-------------------------------------------+
| Aspect                 | WCAG 2.1                         | WCAG 2.2                                  |
+------------------------+----------------------------------+-------------------------------------------+
| Publication Date       | June 2018                        | October 2023                              |
+------------------------+----------------------------------+-------------------------------------------+
| Total Success Criteria | 78                               | 86 (77 from 2.1 + 9 new)*                 |
+------------------------+----------------------------------+-------------------------------------------+
| Focus                  | Mobile accessibility, low vision | Cognitive accessibility, motor disabilities|
+------------------------+----------------------------------+-------------------------------------------+
| Legal Status           | Current DOJ standard             | Recommended best practice                 |
+------------------------+----------------------------------+-------------------------------------------+
| Backward Compatible    | With 2.0                         | With 2.0 and 2.1                          |
+------------------------+----------------------------------+-------------------------------------------+

* Note: WCAG 2.2 removed criterion 4.1.1 Parsing as obsolete, then added 9 new criteria.

*Note: WCAG 2.2 removed criterion 4.1.1 Parsing as obsolete, then added 9 new criteria.

Key point: Content conforming to WCAG 2.2 also conforms to WCAG 2.1 and 2.0, meaning you can meet any legal requirement referencing earlier versions while providing better accessibility.

United States

ADA Title III (Private Businesses)

The Americans with Disabilities Act prohibits discrimination by places of public accommodation. Courts consistently interpret this to include websites, with WCAG as the technical standard.

Key statistics:

  • Over 4,000 ADA website lawsuits filed in 2024 (UsableNet)
  • 77% of lawsuits target e-commerce businesses
  • 25% of lawsuits in 2024 cited accessibility widgets as barriers
  • Average settlement costs $25,000–$100,000+

ADA Title II (Government Entities)

The DOJ's April 2024 final rule establishes WCAG 2.1 Level AA as the mandatory standard for state and local government websites:

  • April 24, 2026: Compliance deadline for entities with populations of 50,000+
  • April 26, 2027: Compliance deadline for smaller entities and special districts

For detailed information, see: The DOJ's New Web Accessibility Rule: What You Need to Know.

Section 508 (Federal)

Federal agencies and their contractors must meet Section 508 requirements, which incorporate WCAG 2.0 Level AA (updates to 2.1 expected).

European Union

European Accessibility Act (EAA)

Effective June 28, 2025, the EAA requires digital products and services sold in the EU to meet accessibility standards aligned with WCAG 2.2. This affects any business serving European customers.

EN 301 549

The European standard EN 301 549 incorporates WCAG 2.1 Level AA, with updates expected to reference WCAG 2.2.

United Kingdom

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 requires public sector websites to meet WCAG 2.1 Level AA minimum, with language referencing "as amended" indicating WCAG 2.2 adoption.

Other Jurisdictions

For a comprehensive legal overview, see: ADA Website Compliance 2025: Complete Legal Requirements Guide.

Common WCAG Failures and How to Fix Them

According to the WebAIM Million annual analysis, 96.3% of home pages have detectable WCAG failures. The most common issues are predictable—and fixable.

1. Low Contrast Text (81% of sites)

WCAG Criterion: 1.4.3 Contrast (Minimum)

The problem: Text with insufficient contrast against backgrounds is difficult or impossible to read for users with low vision.

The fix: Ensure minimum 4.5:1 contrast ratio for normal text, 3:1 for large text (18pt or 14pt bold).

/* Good contrast */
body {
  color: #333333; /* Dark gray */
  background-color: #ffffff; /* White */
  /* Contrast ratio: 12.6:1 ✓ */
}

/* Poor contrast - DON'T */
body {
  color: #767676; /* Medium gray */
  background-color: #ffffff;
  /* Contrast ratio: 4.5:1 - barely passes, avoid */
}

Tools: WebAIM Contrast Checker, browser DevTools accessibility panels

2. Missing Image Alt Text (54% of sites)

WCAG Criterion: 1.1.1 Non-text Content

The problem: Screen reader users cannot access image content without text alternatives.

The fix: Add meaningful alt text describing the image's purpose, not just its appearance.

<!-- Good: Describes purpose -->
<img src="blue-nike-air-max.jpg" 
     alt="Nike Air Max 270 running shoes in blue, side view">

<!-- Good: Decorative image -->
<img src="decorative-line.png" alt="" role="presentation">

<!-- Bad: Missing alt -->
<img src="product.jpg">

<!-- Bad: Unhelpful alt -->
<img src="product.jpg" alt="image" >

3. Missing Form Labels (45% of sites)

WCAG Criterion: 3.3.2 Labels or Instructions

The problem: Form inputs without programmatically associated labels leave screen reader users guessing what information to enter.

The fix: Every input needs a visible, associated label.

<!-- Good: Label with for/id association -->
<label for="email">Email Address</label>
<input type="email" id="email" name="email" required>

<!-- Good: Label wrapping input -->
<label>
  Email Address
  <input type="email" name="email" required>
</label>

<!-- Bad: Placeholder only (not accessible) -->
<input type="email" placeholder="Email">

For comprehensive form guidance, see: Form Accessibility Guide: Labels, Errors, and WCAG Compliance.

4. Empty Links (48% of sites)

WCAG Criterion: 2.4.4 Link Purpose (In Context)

The problem: Links without accessible names (icon-only links, empty anchor tags) don't communicate their purpose.

The fix: Ensure all links have meaningful accessible names.

<!-- Good: Descriptive link text -->
<a href="/cart">View Shopping Cart (3 items)</a>

<!-- Good: Icon with visually hidden text -->
<a href="/cart" aria-label="Shopping cart, 3 items">
  <svg aria-hidden="true"><!-- cart icon --></svg>
</a>

<!-- Bad: Empty link -->
<a href="/cart"><img src="cart.png"></a>

<!-- Bad: Vague link text -->
<a href="/cart">Click here</a>

5. Missing Document Language (17% of sites)

WCAG Criterion: 3.1.1 Language of Page

The problem: Without a declared language, screen readers may use incorrect pronunciation.

The fix: Simple one-line fix in your HTML.

<!DOCTYPE html>
<html lang="en">
<!-- For multilingual content, use lang on specific elements -->
<p lang="es">Hola, ¿cómo estás?</p>

For current statistics and benchmarks, see: WCAG Compliance Statistics 2025: How Many Websites Are Accessible?

Why Accessibility Overlays Don't Work

Accessibility overlays—tools like AccessiBe, UserWay, and AudioEye that promise "one-line" compliance—have become a significant risk factor for businesses.

The Data

  • 1,023 businesses with accessibility widgets were sued in 2024 (UsableNet)
  • 25% of all ADA lawsuits cited overlay widgets as barriers
  • In January 2025, the FTC fined accessiBe $1 million for misleading claims

Why Overlays Fail

  1. They don't fix the code: Overlays add a JavaScript layer on top of broken HTML. Screen readers still encounter the underlying accessibility barriers.
  2. They can create new barriers: Overlay widgets themselves often have accessibility issues—modal dialogs that trap focus, buttons with poor contrast, or features that conflict with assistive technology.
  3. They're not legally defensible: No court has accepted an overlay as evidence of ADA compliance. In fact, overlay use is increasingly cited as evidence of inadequate accessibility efforts.
  4. They impact performance: Loading additional JavaScript degrades page speed, affecting SEO and user experience.

What Works Instead

Source code remediation—actually fixing your HTML, CSS, and JavaScript—is the only path to genuine accessibility compliance. This involves:

  • Writing semantic HTML
  • Ensuring keyboard accessibility
  • Providing text alternatives
  • Maintaining color contrast
  • Testing with actual assistive technology

For a complete breakdown, see: E-commerce Accessibility Compliance: The Complete Guide 2025.

WCAG 2.2 Compliance Checklist

Use this checklist to assess your current accessibility status:

Quick Wins (Implement Today)

  • [ ] Add lang attribute to HTML element
  • [ ] Add alt text to all product images
  • [ ] Ensure form inputs have associated labels
  • [ ] Fix low-contrast text (minimum 4.5:1 ratio)
  • [ ] Make all functionality keyboard accessible
  • [ ] Ensure focus indicators are visible

Critical Path (High Priority)

  • [ ] Audit and fix checkout flow accessibility
  • [ ] Add skip navigation links
  • [ ] Implement proper heading hierarchy (H1 → H2 → H3)
  • [ ] Ensure error messages identify problems and suggest fixes
  • [ ] Add captions to video content
  • [ ] Make modals and dialogs keyboard accessible

WCAG 2.2 Specific (New Requirements)

  • [ ] Verify help mechanisms appear in consistent locations (3.2.6)
  • [ ] Implement auto-fill or selection for redundant entry (3.3.7)
  • [ ] Ensure focused elements aren't hidden behind sticky content (2.4.11)
  • [ ] Provide alternatives to dragging interactions (2.5.7)
  • [ ] Verify touch targets are at least 24×24 pixels (2.5.8)
  • [ ] Review authentication for cognitive function barriers (3.3.8)

Ongoing Maintenance

  • [ ] Set up continuous accessibility monitoring
  • [ ] Integrate accessibility into CI/CD pipeline
  • [ ] Train content creators on accessible content
  • [ ] Establish accessibility review process for new features

How to Achieve WCAG 2.2 Compliance

Step 1: Audit Your Current State

Start with a comprehensive accessibility audit combining:

  • Automated scanning: Tools like axe DevTools, WAVE, or TestParty's Spotlight catch 30-40% of issues instantly
  • Manual testing: Keyboard navigation, screen reader testing, and cognitive review
  • User testing: Testing with people who actually use assistive technology

Step 2: Prioritize Remediation

Focus on impact:

  1. Critical paths first: Checkout, account creation, core functionality
  2. Template-level fixes: Fixing headers, footers, and navigation fixes issues across all pages
  3. High-volume pages: Homepage, category pages, top product pages
  4. Legal risk areas: Issues most commonly cited in lawsuits

Step 3: Implement Fixes

Choose your approach based on resources:

  • Internal remediation: Train your dev team, implement fixes incrementally
  • Expert remediation: Partner with accessibility specialists who deliver source code fixes
  • Hybrid approach: Handle simple fixes internally, outsource complex ARIA patterns

Step 4: Establish Continuous Monitoring

Accessibility isn't a one-time project—it's an ongoing process. Websites change constantly through:

  • Content updates
  • Theme/template changes
  • Third-party app installations
  • Feature launches

Implement monitoring that catches regressions before they reach users.

For resource-constrained teams, see: ADA Compliance for One-Person E-commerce Teams.

The Business Case for WCAG 2.2 Compliance

Beyond legal risk mitigation, accessibility drives business value:

Market Expansion

  • 61 million American adults have disabilities (CDC)
  • $490 billion annual spending power in the U.S. alone
  • 13% of the global population has some form of disability (WHO)

Improved SEO

Accessibility and SEO share significant overlap:

  • Proper heading structure
  • Descriptive link text
  • Image alt text
  • Clean HTML structure
  • Page speed optimization

Better User Experience for Everyone

Accessible design benefits all users:

  • Captions help in sound-sensitive environments
  • Larger touch targets reduce errors on mobile
  • Clear navigation helps everyone find content
  • Keyboard shortcuts speed up power users

Reduced Support Costs

Accessible interfaces reduce friction:

  • Fewer customer service inquiries
  • Lower cart abandonment rates
  • Better completion rates on forms

For ROI calculations and data, see: Accessibility ROI: Building the Business Case for WCAG Compliance.

WCAG 2.2 and the Future: Looking Toward WCAG 3.0

The W3C's Accessibility Guidelines Working Group is developing WCAG 3.0 (codenamed "Silver"), expected in 2026 or later. Key changes anticipated:

  • Outcome-based testing: Focus on user experience rather than just technical compliance
  • Severity ratings: Graded compliance instead of pass/fail
  • Broader scope: Guidelines for emerging technologies like AR/VR, voice interfaces
  • Simplified structure: More accessible guidelines about accessibility

What this means for you: Implementing WCAG 2.2 now positions you well for future standards. The principles remain consistent—WCAG 3.0 will evolve the measurement, not abandon the fundamentals.

Conclusion

WCAG 2.2 compliance isn't just about avoiding lawsuits—it's about building better digital experiences for everyone. The nine new success criteria address real barriers faced by people with cognitive disabilities, motor impairments, and low vision. Combined with the established requirements from WCAG 2.0 and 2.1, achieving Level AA conformance ensures your website works for the widest possible audience.

The path to compliance is clear:

  1. Audit your current accessibility status
  2. Prioritize fixes based on impact and legal risk
  3. Remediate through source code fixes, not overlays
  4. Monitor continuously to prevent regressions

With legal pressure increasing—over 4,000 lawsuits annually in the U.S. alone—waiting is the riskiest strategy. Start your accessibility journey today.

Frequently Asked Questions

Is WCAG 2.2 legally required?

WCAG 2.1 Level AA is the current legal standard referenced by the DOJ's 2024 rule and most ADA settlements. While WCAG 2.2 isn't yet mandated, it's backward compatible—meeting 2.2 means you meet 2.1 and 2.0 requirements while providing better accessibility.

How long does WCAG 2.2 compliance take?

Timeline depends on your current state and complexity:

  • Simple sites with moderate issues: 2-4 weeks
  • E-commerce with standard functionality: 4-8 weeks
  • Complex web applications: 2-3 months

TestParty delivers WCAG 2.2 Level AA compliance in as little as 14 days for many e-commerce sites.

What's the difference between WCAG 2.1 and 2.2?

WCAG 2.2 adds nine new success criteria focused on cognitive accessibility, mobile usability, and motor disabilities. It removes one obsolete criterion (4.1.1 Parsing). Content meeting WCAG 2.2 automatically meets 2.1 and 2.0.

Do accessibility overlays provide WCAG compliance?

No. Overlays do not fix underlying accessibility barriers and are increasingly cited in ADA lawsuits. In 2024, 25% of accessibility lawsuits involved sites with overlay widgets, and the FTC fined accessiBe $1 million for misleading claims in 2025.

What WCAG level should I target?

Target WCAG 2.2 Level AA. This is the standard referenced by ADA guidance, Section 508, the European Accessibility Act, and most international regulations. Level A is insufficient; Level AAA is aspirational but not achievable for all content.

TestParty is an AI-powered digital accessibility compliance platform that helps e-commerce businesses achieve WCAG 2.2 AA compliance through source code remediation. Book a demo to see how we can help your business achieve compliance in as little as two weeks.

Additional Resources

TestParty Guides

Official W3C Resources

Legal Resources

Testing Tools

Stay informed

Accessibility insights delivered
straight to your inbox.

Contact Us

Automate the software work for accessibility compliance, end-to-end.

Empowering businesses with seamless digital accessibility solutions—simple, inclusive, effective.

Book a Demo