WCAG 2.2 Compliance Checklist: What Changed and How to Meet It

The Web Content Accessibility Guidelines 2.2 became a W3C Recommendation in October 2023, and three years later most teams we audit still have not addressed the new criteria. Real users with disabilities encounter real friction. Legal exposure has grown sharply, especially in the United States. This is a working checklist, not a policy document. Use it before you ship.

What changed in WCAG 2.2

WCAG 2.2 added nine new success criteria on top of 2.1 and removed one (4.1.1 Parsing). The new criteria target gaps that affected mobile users, users with cognitive disabilities, and users who navigate by keyboard or touch only. None of the changes require you to throw away your existing accessibility work. They extend it.

The new success criteria are:

• 2.4.11 Focus Not Obscured (Minimum), AA. When a user tabs to an element, it cannot be completely hidden by sticky headers, cookie banners, or floating widgets.
• 2.4.12 Focus Not Obscured (Enhanced), AAA. The focused element must not be obscured at all.
• 2.4.13 Focus Appearance, AAA. The focus indicator must meet a minimum size and contrast ratio.
• 2.5.7 Dragging Movements, AA. Any functionality that uses dragging must offer a single pointer alternative. Map panning, sortable lists, and signature pads are common offenders.
• 2.5.8 Target Size (Minimum), AA. Interactive targets must be at least 24 by 24 CSS pixels, with limited exceptions for inline links.
• 3.2.6 Consistent Help, A. If you offer help mechanisms (contact link, chat, FAQ), they must appear in the same relative location across pages.
• 3.3.7 Redundant Entry, A. Do not ask users to re-enter information they already provided in the same session, unless legally required.
• 3.3.8 Accessible Authentication (Minimum), AA. Cognitive function tests (remembering a password, solving a puzzle) cannot be the only path to authenticate. Password managers must work.
• 3.3.9 Accessible Authentication (Enhanced), AAA. Even with object recognition exceptions, no cognitive test can be required.

For most commercial sites targeting AA conformance, the criteria that bite hardest in practice are 2.4.11, 2.5.7, 2.5.8, and 3.3.8.

The US legal context

The Department of Justice has been clear since 2022 that Title III of the Americans with Disabilities Act applies to public-facing websites, even though the ADA itself predates the modern web. In 2024, the DOJ finalized a rule under Title II requiring state and local government websites to meet WCAG 2.1 AA, widely read as a signal of where Title III enforcement is heading.

Private sector lawsuits under Title III continue to be filed in significant volume, particularly in New York, Florida, and California. Most settle. Remediation under duress costs more than building accessibly from the start.

The Canadian legal context

Canadian organizations face two overlapping regimes. The Accessibility for Ontarians with Disabilities Act (AODA) requires private sector organizations with 50 or more employees to make their websites conform to WCAG 2.0 Level AA, with compliance reports filed periodically.

Federally, the Accessible Canada Act applies to federally regulated entities (banks, telecoms, interprovincial transport, the federal government itself) and requires accessibility plans, progress reports, and feedback mechanisms.

If you operate in both Canada and the US, build to WCAG 2.2 AA. It satisfies the higher of the two bars in most scenarios and gives you headroom as standards evolve.

The pre-launch checklist

Run through this before any significant release. It catches the issues that come up most often in production audits.

• Every image that conveys meaning has a descriptive alt attribute. Decorative images use alt="".
• Color contrast meets 4.5:1 for normal text and 3:1 for large text and UI components. Verify with a contrast checker, not your eyes.
• All interactive elements are reachable by keyboard alone. Tab through the entire page and confirm focus order is logical.
• The focus indicator is visible on every interactive element and is not obscured by sticky headers, modals, or cookie banners (2.4.11).
• Touch targets are at least 24 by 24 CSS pixels, with adequate spacing (2.5.8).
• Any drag interaction has a click or tap alternative (2.5.7).
• Form fields have associated labels, not just placeholder text. Errors are announced to screen readers.
• Forms do not require users to re-enter information already provided in the same session (3.3.7).
• Authentication does not rely solely on cognitive tests. Password managers can autofill fields (3.3.8).
• Help links and contact mechanisms appear in consistent locations across the site (3.2.6).
• Headings follow a logical hierarchy. There is one H1 per page and headings are not used for styling alone.
• Page language is declared on the html element. Language changes within content are marked up.
• Video content has accurate captions. Audio-only content has a transcript.
• The site is usable at 200 percent zoom without horizontal scrolling on standard desktop widths.
• Motion can be reduced or disabled for users who prefer reduced motion. Respect the prefers-reduced-motion media query.

Tools we actually use

No automated tool catches more than about 30 to 40 percent of accessibility issues. They are necessary but not sufficient.

• axe-core, run in CI on every pull request. Fails the build on new violations.
• Lighthouse accessibility category, for a quick sanity check during development.
• Keyboard only testing, by an actual human. Hide your mouse and complete the primary user flows.
• Screen reader spot checks with VoiceOver on macOS or NVDA on Windows. You will catch label and landmark issues no automated tool will flag.
• Browser zoom and reflow testing, at 200 and 400 percent.

For a fast first pass, run your URL through our accessibility scanner and check your brand palette in our contrast checker. Both are free.

Treat accessibility as a product property

The teams that consistently meet WCAG do not have a heroic accessibility specialist who fixes everything at the end. They have designers who pick accessible color palettes, engineers who write semantic HTML by default, and a CI pipeline that fails on new violations. The work is distributed, and it is much cheaper than retrofit.

If you want a structured audit and a remediation plan against WCAG 2.2 AA, reach out. We will tell you honestly which fixes are quick wins and which require design changes.