How to Achieve WCAG 2.2 Compliance Step-by-Step

WCAG 2.2 became the W3C Recommendation in October 2023. It's now the standard referenced in most accessibility regulations worldwide - ADA lawsuits, Section 508 requirements, and EU accessibility directives all point to WCAG 2.1 or 2.2 Level AA. This guide walks through the complete process from initial assessment to ongoing compliance.

The Problem

Most organizations approach accessibility backwards. They build features, launch products, then scramble to fix accessibility issues after receiving a legal demand letter. This reactive approach costs 10-30x more than building accessibility in from the start.

The alternative: systematic compliance integrated into your development process.

Step 1: Establish Your Baseline

Before fixing anything, understand where you stand.

Run Automated Scans

Automated tools catch approximately 30-40% of WCAG issues. Start here for quick wins:

Recommended tools:
• axe DevTools (browser extension) - free
• WAVE (browser extension) - free
• Lighthouse (Chrome DevTools) - free
• pa11y (command line) - free

Run scans on your key pages:
• Homepage
• Login/registration
• Main user flows (checkout, forms, dashboards)
• Content-heavy pages

Document baseline metrics:
• Total automated violations
• Violations by WCAG criterion
• Pages with most issues

Manual Keyboard Testing

Spend 30 minutes navigating your application with keyboard only:

• Unplug your mouse
• Use Tab to move forward, Shift+Tab backward
• Use Enter/Space to activate buttons and links
• Use Arrow keys for menus and complex widgets
• Use Escape to close modals

Document:
• Can you reach all interactive elements?
• Is focus visible at all times?
• Are there any keyboard traps?
• Does focus order make sense?

Screen Reader Spot Check

Test critical flows with a screen reader:

• Windows: NVDA (free) + Chrome
• Mac: VoiceOver (built-in) + Safari
• Mobile: VoiceOver (iOS) or TalkBack (Android)

Listen for:
• Page title announced on load
• Headings create navigable structure
• Form fields announce their labels
• Buttons and links describe their purpose
• Error messages are announced

Step 2: Prioritize by Impact

Not all WCAG violations are equal. Prioritize by user impact:

Critical (Fix First)

High Priority

Medium Priority

Lower Priority

Step 3: Fix Systematic Issues First

Some fixes cascade across your entire application:

Design System Updates

If you use a component library, fix accessibility at the source:

Button components:
• Ensure minimum 44x44px touch targets (WCAG 2.5.8)
• Include visible focus states
• Support keyboard activation

Form components:
• Associate labels programmatically
• Include error states with clear messaging
• Support autocomplete attributes (WCAG 1.3.5)

Modal/dialog components:
• Trap focus within modal
• Return focus to trigger on close
• Include close button and Escape key support

Global CSS Fixes

Focus indicators: ```css :focus-visible { outline: 2px solid #005fcc; outline-offset: 2px; } ```

Color contrast: Audit your color palette. Ensure:
• Normal text: 4.5:1 contrast ratio
• Large text (18px+ or 14px+ bold): 3:1
• UI components and graphics: 3:1

Text resizing: Use relative units (rem, em) not pixels for font sizes. Test at 200% zoom.

Semantic HTML

Replace div-based layouts with semantic elements:
• `
  `, `
• `

  ` through `

  ` for heading hierarchy

• `` for clickable actions (not `
  `)
• `` for navigation (not ``)

Auditi by BetterQA automates journey-based testing. Define your critical user flows, test each step against WCAG criteria, and track compliance across releases. The pre-loaded healthcare portal demo shows this in action with 800+ real audit results.

Step 6: Document Everything

Compliance requires evidence:

Testing Documentation

Remediation Tracking

VPAT/ACR Generation

For government sales or enterprise procurement, you'll need a Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report (ACR).

Document for each WCAG criterion:
• Supports / Partially Supports / Does Not Support / Not Applicable
• Remarks explaining conformance or gaps

Auditi generates VPAT documentation automatically from your audit results, mapping findings to WCAG criteria and producing procurement-ready reports.

Step 7: Integrate Into Development Process

Compliance isn't a one-time project - it's an ongoing practice:

Design Phase

Development Phase

CI/CD Integration

Import automated results into Auditi: Auditi imports findings from axe, WAVE, Lighthouse, and pa11y, combining automated scanning with manual testing in a unified compliance dashboard.

Release Phase

Step 8: Maintain Compliance

Accessibility regresses without ongoing attention:

Regular Audits

Training

Feedback Channels

Common Pitfalls to Avoid

Relying solely on automated testing: Automated tools miss 60-70% of issues. Manual testing is essential.

Fixing symptoms instead of causes: One missing label is a bug. Missing labels everywhere is a systemic problem requiring design system fixes.

Ignoring user journeys: Pages can be individually accessible while multi-step flows fail.

Treating accessibility as a one-time project: Without ongoing process changes, you'll be back where you started within a year.

Using overlays or widgets: Accessibility overlays don't make sites accessible. They add another layer that can break with updates and often make things worse for assistive technology users.

Getting Help

BetterQA provides accessibility testing services for organizations that need expert assistance:

• Comprehensive audits covering WCAG 2.1, 2.2, and Section 508
• Journey-based testing through Auditi platform
• Remediation support with developer training
• Ongoing compliance monitoring

For self-service compliance testing, Auditi by BetterQA provides the tools to audit your application against WCAG, FDA 21 CFR Part 11, and EU accessibility standards.

Frequently asked questions

How long does it realistically take to achieve WCAG 2.2 AA compliance?

Timeline depends on the size and current state of your application. A small website with no prior accessibility work typically takes 4-8 weeks of focused effort: 1-2 weeks for initial audit, 2-4 weeks for remediation, and 1-2 weeks for verification. A large enterprise application with multiple user flows can take 3-6 months. The WebAIM Million 2025 report found that the average homepage has 56.8 detected accessibility errors - applications with this baseline should expect substantive remediation work before achieving conformance. Critical blocking issues (missing form labels, keyboard traps, missing page titles) can often be resolved within days; systemic issues like color contrast across a design system take longer because they require design decisions alongside technical fixes. Building accessibility into a CI/CD pipeline from the start takes 1-2 sprints but prevents the accumulation of technical debt.

What is the difference between WCAG 2.1 and WCAG 2.2, and which should you target?

WCAG 2.2 (published October 2023) adds 9 new success criteria to WCAG 2.1: Focus Appearance (2.4.11, 2.4.12), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7), Accessible Authentication (3.3.8, 3.3.9), and removes the Parsing criterion (4.1.1). For most new projects, WCAG 2.2 AA is the right target because it is the current W3C Recommendation. However, the DOJ's April 2024 rule specifies WCAG 2.1 AA for ADA compliance - meaning ADA lawsuits use WCAG 2.1 as the benchmark. Section 508 references WCAG 2.0 (via WCAG 2.0 Level A and AA). In practice, meeting WCAG 2.2 AA means you also meet 2.1 AA and 2.0 AA, since the standards are backward compatible - higher versions include all criteria from lower versions.

Do accessibility overlays and plugins make websites WCAG compliant?

No. Accessibility overlays - JavaScript widgets that claim to automatically fix accessibility issues - do not achieve WCAG compliance and often introduce new barriers. The National Federation of the Blind, the American Council of the Blind, and hundreds of disabled users have signed open letters against overlays including the Overlay Fact Sheet. Key problems: overlays cannot fix structural issues like missing form labels or incorrect heading hierarchy; screen reader users frequently report overlays make sites harder to use because the overlay layer conflicts with their assistive technology; overlays can be blocked by browser extensions or disabled by users. Multiple lawsuits have been filed against companies using overlays, with courts finding that overlays do not provide legal protection. Genuine WCAG compliance requires fixing the underlying HTML, CSS, and JavaScript - the work cannot be outsourced to a widget.

Built by BetterQA

© 2026 Auditi. A BetterQA project. | auditi.ro