25 September 202613 min read

Fix Six WCAG 2.2 AA Gaps: Developer Checklist with Tests & Fixes

Accessibility tester checking a web interface

WCAG 2.2 is the current W3C Recommendation, and Level AA conformance means meeting every Level A and Level AA success criterion, including six of the nine newly added ones (2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7, and 3.3.8). Start with an automated scan to clear the well-known Level A and AA issues, then run manual tests on the new behavioral criteria, since most of them can’t be caught by a crawler.

TL;DR:

Six of the nine new WCAG 2.2 criteria are required for Level AA conformance, focusing on focus visibility, drag alternatives, target size, help placement, authentication, and redundant input.

Automated tools cover over half of the existing WCAG 2.1 issues, but manual testing is essential for behavioral criteria like focus clarity and drag accessibility.

Running tests involves both quick automated scans for structural issues and manual keyboard, screen reader, and visual checks on sampled pages using a defined methodology.

Upgrading from WCAG 2.1 to 2.2 mainly requires addressing six new AA criteria, with three optional AAA standards, making the transition more manageable for already compliant sites.

Clear, precise documentation of scope, testing methodology, and sample pages is critical for contractual and compliance claims, especially when referencing the exact WCAG version and level.

What’s Actually New in the WCAG 2.2 Checklist?

WCAG 2.2 doesn’t replace WCAG 2.1. It builds on it. Every success criterion from 2.1 carries forward unchanged, except one that got removed entirely (more on that later), and the new version adds nine success criteria on top. Depending on how you count grouped criteria, that puts the total at 86 or 87 success criteria across Levels A, AA, and AAA.

The nine additions aren’t random. They target three groups accessibility teams have historically underserved: people with motor impairments who struggle with small click targets and drag gestures, people with cognitive disabilities who lose track of where they are in a multi-step process, and people with low vision who need consistent, predictable navigation. If your last audit was built around WCAG 2.1, this is the gap you’re closing.

Here’s the breakdown that matters most for compliance work:

Six new criteria are Level A or AA and required for AA conformance: Focus Not Obscured (Minimum) 2.4.11, Dragging Movements 2.5.7, Target Size (Minimum) 2.5.8, Consistent Help 3.2.6, Accessible Authentication (Minimum) 3.3.7, and Redundant Entry 3.3.8.
Three are AAA-only, meaning they’re best practice but not required for standard AA conformance: Focus Not Obscured (Enhanced) 2.4.12, Focus Appearance 2.4.13, and Accessible Authentication (Enhanced) 3.3.9.
One older criterion was removed: 4.1.1 Parsing no longer applies, because modern browsers handle malformed markup in ways that made the original test obsolete.

If you’re building a checklist for a client or an internal audit, the practical takeaway is this: don’t treat all nine new items as equal weight. Six of them decide whether you pass AA. The other three are a stretch goal.

The Nine New WCAG 2.2 Success Criteria, One Test Each

This is the working checklist. Each item gets a one-line test you can run yourself, plus the fix that usually clears it. Six of these are required for AA; three are AAA and marked accordingly.

2.4.11 Focus Not Obscured (Minimum), AA. Test: tab through every interactive element on the page and check whether a sticky header, cookie banner, or chat widget ever fully covers the focused item. Fix: add scroll-margin-top or scroll-padding-top in CSS so focused elements scroll clear of fixed headers, and set a lower z-index or dismiss overlays on focus.
2.5.7 Dragging Movements, AA. Test: find every feature that relies on drag (sliders, drag-and-drop reordering, map panning) and confirm each one also works with a single click or tap. Fix: add explicit up/down or left/right buttons next to sliders, or a “move to position” menu as an alternative to drag reordering.
2.5.8 Target Size (Minimum), AA. Test: measure clickable targets that aren’t inline text links. Anything under 24 by 24 CSS pixels fails unless it has enough spacing from neighboring targets or an equivalent-sized invisible hit area. Fix: pad small icon buttons with CSS (padding or a larger min-width/min-height) rather than shrinking the visual icon.
3.2.6 Consistent Help, AA. Test: if a help mechanism (chat link, contact info, help page) exists on more than one page, check that it appears in the same relative position in the navigation order across all of them. Fix: put help links in a shared header or footer component instead of hand-placing them per page.
3.3.7 Accessible Authentication (Minimum), AA. Test: try to log in using only a password manager and browser autofill. If the form blocks paste, strips autocomplete attributes, or forces a manual CAPTCHA-style puzzle with no alternative, it fails. Fix: keep autocomplete="current-password" and similar attributes intact, allow paste into password fields, and offer at least one authentication method that doesn’t rely on solving a cognitive puzzle.
3.3.8 Redundant Entry, AA. Test: walk through any multi-step form and check whether information you already entered (name, address, email) gets asked for again without being pre-filled. Fix: carry form data across steps in state or session storage and auto-populate repeat fields.
2.4.12 Focus Appearance, AAA. Test: check whether the focus indicator has sufficient contrast and size against its background across every component. Fix: use a visible outline at least 2 CSS pixels thick with strong contrast against adjacent colors.
2.4.13 Focus Not Obscured (Enhanced), AAA. Test: same as 2.4.11, but stricter, no part of the focused element can be hidden, not even partially. Fix: same remediation as 2.4.11, applied more strictly.
3.3.9 Accessible Authentication (Enhanced), AAA. Test: confirm login never requires remembering, transcribing, or manually recalling information (no “type the characters you memorized” steps). Fix: rely entirely on paste-friendly, autofill-friendly authentication with no cognitive recall step.

Pro Tip: Target Size (2.5.8) trips up more teams than any other new criterion, because design systems built years ago often used 20px icon buttons as a standard. Run a quick script that measures every button, a, and clickable div on your site against the 24px floor before your manual review even starts. It saves hours.

Clearing the Carried-Forward Checklist Before You Claim Conformance

Before you even think about the nine new criteria, you need the WCAG 2.1 backlog clean. This is the part of the WCAG 2.2 checklist that automated tools handle well, and the part that trips up teams who assume a green scan means they’re done.

Automated scanners are reliable for a specific category of problems: missing alt attributes, unlabeled form fields, missing form-field associations, insufficient color contrast on static text, missing document language attributes, and duplicate IDs. Run a scanner across your whole site first and you’ll usually clear 50 to 70 percent of your total issue count in an afternoon.

What automation consistently misses is anything that requires judgment. Does the alt text actually describe the image, or does it just exist? Does the tab order match the visual reading order, or does it jump around in a way that only a human tester would notice? Is the heading structure logical, or does it skip from an H2 straight to an H4 because a developer picked font sizes instead of semantic levels? These need a person clicking through with a keyboard and a screen reader.

Automated tools catch a meaningful share of issues by volume, but most of the WCAG 2.2 additions require manual verification precisely because they test behavior, not markup. A scanner can tell you a button exists. It can’t tell you whether dragging is the only way to operate it.

For prioritization, work in this order:

Fix blockers first: anything that prevents task completion entirely, like an unlabeled required form field or a keyboard trap.
Fix high-traffic pages next: your homepage, checkout flow, and primary conversion paths matter more than a rarely visited archive page.
Fix contrast and labeling issues in bulk: these are usually systemic (one bad CSS variable, one component template) so one fix clears dozens of instances.
Leave cosmetic AAA nice-to-haves for last: enhanced focus appearance and similar AAA items are worth doing, but not at the expense of AA blockers.

A typical remediation backlog after a first pass looks like: 40 missing alt attributes, 12 unlabeled inputs, 8 low-contrast text instances, 3 keyboard traps, and a handful of heading-order violations. None of that is new to WCAG 2.2. It’s just the floor you need clear before the nine new criteria are worth testing.

What Testing Workflow Actually Works for WCAG 2.2?

Run automation first, then manual testing, in that order, every time. Reversing the order wastes hours on issues a scanner would have caught in seconds.

Automated pass. Run a scanner like axe-core across every template and page type (not every individual page, templates repeat). This clears alt text, labeling, and contrast issues fast, and gives you a baseline issue count.
Manual pass with a small toolkit. A keyboard, browser dev tools, a contrast picker, a password manager, and a screen reader cover almost everything automation misses. Tab through every interactive flow. Check focus visibility against fixed headers. Test drag interactions with keyboard-only input. Try logging in with autofill and paste.
Sample-based site audit using WCAG-EM. For a full site, don’t test every page. WCAG-EM’s five-step method defines scope, explores the site structure, selects a representative sample (templates, forms, high-traffic pages, and edge cases like error states), audits that sample with both automated and manual checks, and reports findings against specific success criteria with pass/fail status and evidence.

Your toolkit doesn’t need to be expensive or exotic:

A browser’s built-in accessibility inspector (Chrome DevTools, Firefox Accessibility Panel) for focus order and ARIA attributes.
A contrast checker for the 2.4.11 and 2.4.13 focus-visibility checks.
Your actual operating system’s screen reader (VoiceOver, NVDA) rather than relying on automated output alone.
A password manager, since 3.3.7 is specifically about whether autofill and paste actually work.

The report you produce should record which pages or templates were sampled, which success criteria were tested, pass/fail status per criterion, and enough evidence (a screenshot, a specific URL, a reproduction step) that another tester could verify your finding without redoing the whole audit.

How Is WCAG 2.2 Different From WCAG 2.1 in Practice?

If your site is already WCAG 2.1 AA compliant, the jump to 2.2 is smaller than it sounds. Here’s what actually changes for teams doing that upgrade:

4.1.1 Parsing is gone. It used to require valid, well-formed markup for assistive technology to parse correctly. Modern browsers and assistive tech handle malformed HTML consistently enough that the criterion became redundant, so it was retired rather than carried forward.
Six new AA criteria apply, and they’re the ones covered in the checklist above: focus visibility, dragging alternatives, target size, consistent help placement, accessible authentication, and redundant entry.
Three new AAA criteria exist but aren’t required for standard AA conformance claims, unless your contract or regulatory context specifically requires AAA.

For a team already at 2.1 AA, the realistic scope of work is a focused project targeting the six new AA criteria, not a full re-audit. Budget accordingly, and check whether your contract or regulatory obligation names 2.1 or 2.2 specifically, since the exemptions and required scope differ slightly between versions.

How Should You Reference WCAG 2.2 in Contracts and Compliance Docs?

Vague language like “meets WCAG” is a liability, not a compliance claim. W3C’s own guidance on referencing WCAG 2.2 recommends citing the exact conformance level: “Level AA” means every Level A and every Level AA success criterion, no exceptions and no partial credit. Techniques documents are informative, not normative, so don’t cite a technique as if it were a requirement.

For Swiss organizations, the relevant public-sector standard, eCH-0059, currently cites WCAG 2.1 Level AA as the mandatory baseline for federal administration sites. That means a Swiss federal site is not legally required to meet WCAG 2.2 today. Practitioners generally recommend building to 2.2 anyway, since the standard tends to move in that direction and retrofitting later costs more than building it in now.

When you write requirements into a contract or an RFP, a few habits save disputes later:

Name the exact version and level (“WCAG 2.2 Level AA”), never just “WCAG compliant” or “accessible.”
List the specific pages, templates, or user flows the conformance claim covers, since claiming site-wide conformance without defining scope is unenforceable.
State whether AAA criteria are in scope or explicitly excluded.
Reference the testing methodology used (automated tool, manual pass, sample size) so the claim is auditable later.

Document your audit’s scope and sample pages the same way, so if a claim is ever challenged, there’s a defensible trail behind it rather than a marketing sentence.

Who’s Behind This Checklist?

This guide was written by Davide Morotti, drawing on hands-on accessibility remediation work across client projects at a Zurich-based software studio building websites, applications, and platforms for startups and established teams alike.

A few points worth knowing if you’re deciding whether to trust this checklist or hand the work to someone else:

The studio has delivered accessibility-aware builds for clients including Arthouse Kinos, Zurich’s cinema group, where multi-step ticket purchase flows needed to hold up under keyboard and screen reader testing.
Their work on Repa Immobiliare involved bespoke, partially offline software, a context where automated scanning alone isn’t enough and manual edge-case testing matters more.
They have also built and maintained large-scale systems for Die Mitte, running over 600 websites for a Swiss political party from one platform, and count UBS and the City of Lugano among their client base.
Projects are led end-to-end by senior engineers from first consultation through handover, helping prevent accessibility requirements from getting lost between design handoff and implementation.

How Ampersand Labs Handles WCAG 2.2 Remediation

Running this checklist yourself is entirely doable if you have the time and a developer who can own it. If you’d rather hand it to someone who’s done it before, some studios run WCAG-EM style audits that produce a scoped, sampled report and a prioritized remediation backlog, not just a raw scanner export you have to interpret yourself.

A typical engagement starts with defining scope (which pages, which flows, which conformance level), sampling representative templates, running the automated and manual passes described above, and handing back a report ranked by impact rather than a flat list of hundreds of issues. When projects have senior engineering leadership from first call through delivery, fixes are implemented correctly the first time instead of bouncing between a designer’s intent and a developer’s interpretation, a common failure point on accessibility work handled piecemeal.

If remediation involves rebuilding components rather than patching them, that work falls under Ampersand Labs’s development services. For teams that just need pricing clarity before committing, current rates and engagement types are listed on the Ampersand Labs pricing page. If your accessibility gap is really a symptom of a larger legacy codebase problem, it’s worth a conversation before you spend a remediation budget patching a system due for replacement anyway.

Sources

For the normative text itself, read the W3C WCAG 2.2 Recommendation directly rather than relying on secondhand summaries, since techniques and exceptions matter in edge cases. The ACT Rules Format documents how automated test implementations are validated against the standard, useful if you’re evaluating whether your scanner’s results are trustworthy. For structuring a full-site audit, WCAG-EM 1.0 is the methodology auditors cite when a client asks how the sample was chosen. And for a criterion-by-criterion practical testing walkthrough specifically built around the nine new additions, wcag22aa.org’s testing guide is the most direct companion to the checklist above.

For teams evaluating whether their site is even crawlable before deeper accessibility work begins, a tool like BabyLoveGrowth’s crawlability audit can flag basic access issues worth ruling out first.

FAQ

What Are WCAG 2.2 Standards?

WCAG 2.2 is the W3C Recommendation defining success criteria for web accessibility across three levels: A, AA, and AAA. It carries forward every WCAG 2.1 criterion except 4.1.1 Parsing, which was removed, and adds nine new criteria targeting motor, cognitive, and low-vision needs.

Is WCAG 2.2 Mandatory?

WCAG 2.2 itself isn’t a law, it’s a technical standard that laws and regulations reference. In Switzerland, the federal public-sector standard eCH-0059 currently cites WCAG 2.1 Level AA as the baseline, not 2.2, though adopting 2.2 now is widely recommended to future-proof compliance work.

What Is a WCAG Check?

A WCAG check is a test against a specific success criterion to determine pass or fail, run through automated scanning for structural issues (missing labels, contrast ratios) and manual testing for behavioral issues (keyboard operability, focus visibility, drag alternatives). A full check typically follows the WCAG-EM methodology: define scope, sample pages, audit, and report.

What Are the New WCAG Standards Added in Version 2.2?

WCAG 2.2 added nine success criteria, six of which are required for Level AA conformance: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), Consistent Help, Accessible Authentication (Minimum), and Redundant Entry. The remaining three, Focus Not Obscured (Enhanced), Focus Appearance, and Accessible Authentication (Enhanced), are AAA-level and optional for standard AA compliance.

How Long Does a WCAG 2.2 Audit Usually Take?

It depends on site size and how much of the WCAG 2.1 backlog is already clear, but a focused audit covering the six new AA criteria on a site that’s already 2.1 AA compliant is typically a short, scoped project rather than a full rebuild. A comprehensive first-time audit combining automated scanning, manual testing, and a WCAG-EM sampling plan takes longer and scales with the number of distinct templates and user flows on the site.

Have a project this touches on?

A free 10-minute call is the fastest way to find out whether we are the right studio for it.

Book a free 10-min call

Keep reading