WCAG 2.2 Compliance Checklist: What Developers Need to Know Before the EU Accessibility Act Deadline

Web accessibility compliance is no longer optional. With the EU Accessibility Act (EAA) enforcement date of June 28, 2025 now here and ADA website accessibility lawsuits in the US surging 37% year over year, developers who ignore WCAG are building liability into their products.

This is a practical, complete guide to WCAG 2.2 compliance written for developers who need to understand what changed, what's required, and how to audit their web applications. No fluff, no legal jargon — just the essential checklist you need to ship accessible software.

Why WCAG 2.2 Matters Right Now

Three things happened that make this urgent:

1. WCAG 2.2 became a W3C Recommendation in October 2023, adding nine new success criteria focused on cognitive accessibility, mobile usability, and keyboard navigation.
2. The European Accessibility Act (EAA) took effect June 28, 2025, requiring all digital products and services sold to EU consumers to meet accessibility standards aligned with WCAG 2.2 Level AA.
3. ADA lawsuits in the US are accelerating. Over 2,000 federal cases were filed in the first half of 2025 alone, and AI tools are making it easier for plaintiffs to identify violations and file complaints.

If your web app serves users in the EU or the United States, WCAG 2.2 Level AA conformance is the practical minimum standard you should target.

What's New in WCAG 2.2 vs. 2.1

WCAG 2.2 builds on WCAG 2.1 — it does not replace or remove existing criteria (with one exception). If you already conform to WCAG 2.1, you are most of the way there. The update adds nine new success criteria and removes one obsolete criterion.

Removed: 4.1.1 Parsing

The Parsing criterion from WCAG 2.0 has been marked obsolete. Modern browsers are tolerant of HTML parsing errors, so this criterion no longer serves its original purpose. You can stop worrying about it.

New Level A Criteria (Must-Have)

3.2.6 Consistent Help — If your site includes help mechanisms (contact info, chatbots, FAQ links) on multiple pages, they must appear in the same relative position on each page. Users should not have to hunt for help every time they navigate to a new screen.

3.3.7 Redundant Entry — If a user has already entered information during a multi-step process, do not force them to re-enter it. Auto-populate fields or let users select previously entered values. This applies to forms like checkout flows, multi-page registrations, and survey wizards.

New Level AA Criteria (The Legal Standard)

These four criteria are the ones that matter most for compliance, because Level AA is the standard referenced by the EAA and most ADA-related legal guidance.

2.4.11 Focus Not Obscured (Minimum) — When a UI element receives keyboard focus, it must not be entirely hidden behind sticky headers, footers, cookie banners, or other overlapping content. At least part of the focused element must remain visible. This is a common failure on sites with fixed navigation bars and persistent notification banners.

2.5.7 Dragging Movements — Any functionality that relies on drag-and-drop must also be achievable with a single pointer action (click or tap) that does not require dragging. Think of Kanban boards, sortable lists, map panning, and sliders. You need to provide an alternative like click-to-select-then-click-to-place, arrow buttons, or direct track clicking for sliders.

2.5.8 Target Size (Minimum) — Interactive targets must be at least 24x24 CSS pixels, or have sufficient spacing between them. This is a relaxed version of the Level AAA requirement (44x44 pixels) from WCAG 2.1. It primarily affects mobile touch targets but also applies to desktop click targets like small icon buttons and inline links in dense text.

3.3.8 Accessible Authentication (Minimum) — Authentication flows must not require cognitive function tests (like CAPTCHAs, memorizing passwords, or solving puzzles) unless an alternative method is available, a mechanism assists the user (like a password manager), or the test uses object recognition or personal content. In practice, this means you should support password managers (do not block paste in password fields), offer passkeys or biometric login, and avoid text-based CAPTCHAs.

New Level AAA Criteria (Recommended, Not Required)

These are aspirational targets. Most legal frameworks require Level AA, not AAA, but implementing these demonstrates strong commitment to accessibility.

• 2.4.12 Focus Not Obscured (Enhanced) — The entire focus indicator must be visible, not just part of it.
• 2.4.13 Focus Appearance — Focus indicators must be at least 2 CSS pixels thick with a 3:1 contrast ratio between focused and unfocused states.
• 3.3.9 Accessible Authentication (Enhanced) — Same as 3.3.8 but without exceptions for object recognition and personal content.

The EU Accessibility Act: What Developers Need to Know

The European Accessibility Act (Directive 2019/882) is the most significant accessibility law to affect the private sector globally. Here are the facts:

• Enforcement date: June 28, 2025
• Who it applies to: Any business selling products or services to consumers in the EU, regardless of where the business is headquartered. If you have EU customers, it applies to you.
• What it covers: Websites, mobile apps, e-commerce platforms, banking services, transportation services, e-books, and consumer electronics.
• Technical standard: The EAA aligns with EN 301 549, which references WCAG 2.1 AA and is being updated to incorporate WCAG 2.2 AA.
• Penalties: Member states set their own fines. Germany allows up to 100,000 euros per violation. France can impose fines up to 75,000 euros or 4% of annual revenue.
• Exemptions: Micro-enterprises (fewer than 10 employees, under 2 million euros annual turnover) are exempt. An "undue burden" exception exists but requires documentation.
• Required documentation: Businesses must publish an accessibility statement describing how they meet the requirements.

The bottom line: if you operate a SaaS product, e-commerce site, or any web application with EU users, you need to conform to WCAG 2.2 Level AA.

ADA Compliance in the United States

In the US, the landscape is different but equally pressing:

• Title II of the ADA now explicitly references WCAG 2.1 Level AA for state and local government websites, with compliance required by April 2026.
• Title III of the ADA covers private businesses but has no explicit technical standard yet. However, courts consistently use WCAG 2.1 AA as the benchmark in litigation.
• Lawsuit volume is increasing. Over 4,000 federal ADA website accessibility lawsuits were filed in 2024, and 2025 is on pace to exceed that by 20%.
• Common targets: E-commerce sites, restaurants, healthcare providers, and financial services. Sites using accessibility overlay widgets are specifically targeted by plaintiffs' attorneys.
• Settlements typically range from $5,000 to $50,000 plus attorney fees and remediation costs.

The safest approach: target WCAG 2.2 Level AA. It covers everything in 2.1 and addresses the criteria most likely to appear in future regulations.

The Complete WCAG 2.2 Accessibility Checklist for Developers

This checklist covers both the existing WCAG 2.1 criteria that cause the most failures and the new 2.2 criteria. Use it as a practical audit guide for your web application.

Perceivable

• All images have meaningful alt text (or alt="" for decorative images)
• Videos have captions and audio descriptions where needed
• Color is never the sole means of conveying information (e.g., error states use icons or text in addition to red coloring)
• Text has a contrast ratio of at least 4.5:1 against its background (3:1 for large text)
• Non-text UI components and graphical objects have a contrast ratio of at least 3:1
• Content is readable and functional at 200% zoom without horizontal scrolling
• Content reflows properly at 320 CSS pixels wide (mobile viewport) without loss of information
• Text spacing can be adjusted (line height, paragraph spacing, letter spacing, word spacing) without loss of content

Operable

• All interactive elements are reachable and operable via keyboard alone
• There are no keyboard traps — users can always tab away from any element
• A skip navigation link is present to bypass repeated blocks of content
• Page titles are descriptive and unique
• Focus order follows a logical reading sequence
• Link text is descriptive (no "click here" or "read more" without context)
• [NEW 2.2] Focus is not entirely obscured by sticky headers, footers, or overlays when tabbing through the page
• [NEW 2.2] All drag-and-drop functionality has a single-pointer alternative
• [NEW 2.2] Touch targets are at least 24x24 CSS pixels or have adequate spacing
• Users can extend, adjust, or disable time limits (with exceptions for real-time events)
• No content flashes more than three times per second

Understandable

• The page language is declared with a lang attribute on the html element
• Form inputs have visible, associated labels (using <label> elements or aria-labelledby)
• Error messages are descriptive and suggest corrections
• Error prevention is in place for legal, financial, or data-critical submissions (confirmation step, ability to review and correct)
• [NEW 2.2] Help mechanisms appear in a consistent location across pages
• [NEW 2.2] Users are not required to re-enter information they already provided in a multi-step process
• [NEW 2.2] Authentication does not require cognitive function tests unless alternatives are provided

Robust

• HTML is valid and well-structured (headings in order, landmark regions used properly)
• Custom components use appropriate ARIA roles, states, and properties
• Status messages are announced to screen readers using role="status" or aria-live regions
• The interface works correctly with assistive technologies (screen readers, switch access, voice control)

Common Accessibility Failures (and How to Fix Them)

According to the WebAIM Million report, 95% of the top one million websites have detectable accessibility barriers. These are the failures that show up most often.

1. Missing or Meaningless Alt Text

The problem: Images without alt attributes, or images with generic alt text like "image" or "photo."

The fix: Write alt text that describes the purpose of the image in context. If the image is decorative, use alt="" so screen readers skip it. If the image contains text, the alt text should include that text.

2. Insufficient Color Contrast

The problem: Light gray text on white backgrounds, or colored text on colored backgrounds that fail the 4.5:1 ratio.

The fix: Use a contrast checker during design. Tools like the WebAIM Contrast Checker or the browser DevTools contrast picker make this straightforward. Pay special attention to placeholder text, disabled states, and small text on gradient backgrounds.

3. Keyboard Traps

The problem: Modal dialogs, dropdown menus, or custom widgets that capture keyboard focus and do not allow users to tab out.

The fix: Ensure all modals can be closed with the Escape key. Trap focus inside modals while they are open, but return focus to the trigger element when closed. Test every interactive component by navigating with Tab and Shift+Tab.

4. Missing Form Labels

The problem: Input fields that rely on placeholder text as their only label, or inputs with no programmatic association to a label.

The fix: Use the <label> element with a for attribute matching the input's id. If a visible label is not possible, use aria-label or aria-labelledby. Placeholder text is not a substitute for a label — it disappears on focus and is not reliably announced by all screen readers.

5. No Skip Navigation

The problem: Users who navigate by keyboard must tab through an entire navigation bar on every page before reaching the main content.

The fix: Add a "Skip to main content" link as the first focusable element in the DOM. It can be visually hidden until focused. Link it to an id on your <main> element.

6. Focus Indicators Removed or Hidden

The problem: CSS that removes the default focus outline with outline: none without providing a custom focus style.

The fix: Never remove focus indicators without replacing them. Use :focus-visible to show custom focus styles only for keyboard navigation. Ensure the focus indicator has at least a 3:1 contrast ratio against adjacent colors.

Automated Accessibility Testing Tools

Automated tools catch approximately 30% of WCAG issues — primarily the ones that can be detected through DOM analysis. The remaining 70% require manual testing with assistive technologies. But that 30% covers many of the most common and impactful failures, so automated testing is an essential first step.

axe-core

The industry-standard accessibility testing engine, maintained by Deque Systems. It powers most other tools on this list. You can integrate it directly into your test suite with @axe-core/playwright, @axe-core/puppeteer, or jest-axe. It checks for WCAG 2.0, 2.1, and 2.2 violations with near-zero false positives.

Best for: Developers who want to add accessibility checks to their existing Playwright or Cypress test suites.

Google Lighthouse

Built into Chrome DevTools. Run an accessibility audit on any page and get a score out of 100 with specific failure details. It uses axe-core under the hood. Lighthouse is great for quick spot checks but less suited for comprehensive site-wide audits.

Best for: Quick one-page audits during development.

WAVE (Web Accessibility Evaluation Tool)

A browser extension from WebAIM that overlays accessibility errors, alerts, and structural information directly on your page. It provides a visual representation of issues that makes it easy to identify problems in context.

Best for: Visual learners and designers who want to see accessibility issues in the page layout.

Plaintest

Plaintest runs built-in WCAG accessibility audits as part of its AI-powered app exploration. When the AI explores your application, it automatically runs axe-core checks on every screen it discovers, capturing accessibility violations alongside functional test generation. This means you get an accessibility audit of your entire application without writing any test code or manually navigating to every page. The results include violation severity, affected elements, and WCAG criteria references.

Best for: Teams that want accessibility auditing integrated into their automated testing workflow without additional setup.

Browser DevTools

Chrome, Firefox, and Edge all include built-in accessibility inspection tools. Chrome's DevTools includes a contrast ratio checker, accessibility tree viewer, and the ability to emulate vision deficiencies. These are free and already on your machine.

Best for: Debugging specific elements and verifying fixes during development.

pa11y

An open-source command-line accessibility testing tool. It can be integrated into CI/CD pipelines to run automated checks on every deploy. Supports WCAG 2.1 AA out of the box and can be configured for custom rule sets.

Best for: CI/CD integration and automated regression testing.

How to Run a WCAG 2.2 Audit on Your Web App

Here is a practical process for auditing your application:

Step 1: Automated Scan

Run an automated tool across your entire site. If you use Plaintest, this happens automatically during AI exploration — every discovered page is audited. Otherwise, use axe-core in your test suite or pa11y in your CI pipeline. Document every violation with its WCAG criterion reference.

Step 2: Keyboard Navigation Test

Put your mouse away. Navigate your entire application using only the keyboard. Check that:

• You can reach every interactive element with Tab
• You can activate every button and link with Enter or Space
• You can escape from every modal and dropdown
• Focus is always visible and follows a logical order
• No content is hidden behind sticky elements when focused

Step 3: Screen Reader Test

Test with at least one screen reader. VoiceOver (macOS/iOS) and NVDA (Windows, free) are the most common. Verify that:

• All images and icons are announced meaningfully
• Form labels are read correctly
• Error messages are announced
• Dynamic content changes (toasts, modals, loading states) are communicated
• Page structure (headings, landmarks) makes navigation logical

Step 4: Visual Inspection

Check color contrast ratios on every page. Verify that information is not conveyed by color alone. Test at 200% zoom and at a 320px viewport width. Ensure text spacing adjustments do not break the layout.

Step 5: New WCAG 2.2 Criteria Review

Walk through the new criteria specifically:

• Tab through the site and verify focus is never fully hidden behind sticky elements (2.4.11)
• Identify all drag-and-drop interactions and verify single-pointer alternatives exist (2.5.7)
• Measure touch target sizes on mobile viewports (2.5.8)
• Check that help links and contact info appear in the same position across pages (3.2.6)
• Walk through multi-step forms and verify previously entered data is auto-populated (3.3.7)
• Test the login flow — ensure password managers work and no CAPTCHA blocks authentication (3.3.8)

Step 6: Document and Prioritize

Create an accessibility statement for your site. Categorize violations by severity (critical, serious, moderate, minor) and prioritize fixes that affect the most users. Address Level A issues first, then Level AA.

Next Steps

Accessibility compliance is not a one-time project. It is an ongoing practice that needs to be part of your development workflow. Here is how to start:

1. Run an automated audit today. Use axe-core, Lighthouse, or Plaintest to get a baseline of your current violations. You cannot fix what you have not measured.

2. Fix the critical issues first. Missing alt text, keyboard traps, and absent form labels are the highest-impact failures and the easiest to fix.

3. Address the new WCAG 2.2 criteria. Focus Not Obscured, Dragging Movements, Target Size, and Accessible Authentication are the four Level AA additions that are most likely to affect your application.

4. Add accessibility checks to your CI/CD pipeline. Catch regressions automatically on every pull request. axe-core integrates with Playwright, Cypress, and Jest. pa11y works as a standalone CLI tool.

5. Test with real assistive technologies. Automated tools catch the low-hanging fruit. Spend 30 minutes navigating your app with a screen reader and keyboard to find the issues tools miss.

6. Publish an accessibility statement. The EAA requires it, and it signals to users (and potential plaintiffs) that you take accessibility seriously. Include your conformance target (WCAG 2.2 Level AA), known limitations, and contact information for reporting issues.

7. Make accessibility part of your design and development process. Review designs for contrast and target sizes before building. Write semantic HTML by default. Test keyboard navigation as part of your QA checklist.

The goal is not perfection on day one. The goal is continuous improvement toward a web that works for everyone — and compliance with the laws that are now requiring exactly that.