Developer Playbook: Fix WCAG 2.2 AA’s 4 New Criteria Fast

WCAG 2.2 AA means satisfying every Level A and Level AA success criterion in the WCAG 2.2 specification, not just the newest additions. The immediate step is simple: run an automated scan today, then schedule manual keyboard and assistive-technology checks to confirm what the scan cannot see. Organizations combine both methods because real conformance depends on it.

TL;DR:

• Most accessibility failures involve contrast, keyboard focus, or labels, which can be fixed quickly with targeted CSS and content adjustments.
• Automated scans are effective for catching many issues but must be complemented by manual and assistive technology testing to ensure real-world usability.
• Address new WCAG 2.2 AA criteria, such as unobstructed focus, larger target sizes, non-drag alternatives, and accessible authentication, through straightforward design and development changes.
• Regular re-checks and detailed documentation, including scan reports and test logs, are crucial for maintaining up-to-date compliance evidence.
• Implement accessibility criteria early in sprints and integrate testing into regular workflows to prevent regressions and support ongoing conformance efforts.

Table of Contents

• What WCAG 2.2 AA covers and how it builds on 2.1
• The new AA success criteria and how to fix them
• Top checklist: common AA failures and quick fixes
• How to test: automated scans, manual review, and assistive technology
• Legal and policy context: ADA, Section 508, and your obligations
• A shift-left workflow your team can run in sprints
• Documenting conformance and keeping it current
• Why pragmatic compliance beats perfect compliance
• Where AccessWiser fits into your compliance plan
• Sources
• FAQ

What WCAG 2.2 AA covers and how it builds on 2.1

WCAG 2.2 is backward compatible with 2.1, so any site already meeting 2.1 AA is most of the way there. Full AA conformance under 2.2 means meeting every Level A and Level AA success criterion in the specification, including the criteria carried over from earlier versions and the ones added in this release.

The guidelines apply to web pages and web applications, and the W3C extends most requirements to non-web documents and software with minor wording adjustments for those contexts. In practice, that covers everything from a marketing site to a single-page app built on React or Vue, plus PDFs and native apps where the equivalent criteria apply.

The new criteria in 2.2 exist because earlier versions left gaps for people with motor and cognitive disabilities. Sticky navigation bars hiding a focused field, drag-only interactions with no alternative, and tiny tap targets were all technically passable under 2.1 while still shutting people out. Closing those gaps changes real design decisions: layout, spacing, and how interactive controls respond to input all need a second look under 2.2.

The new AA success criteria and how to fix them

Four new success criteria affect AA conformance directly, and each maps to a concrete, fixable pattern:

• 2.4.11 Focus not obscured (minimum): when a user tabs to an element, no sticky header, cookie banner, or modal should fully cover it; test by tabbing through every page with a fixed header and confirming the focused element stays visible.
• 2.5.7 Dragging movements: any drag-and-drop interaction, like reordering a list or a slider, needs a non-drag alternative such as up and down buttons; test by completing the same task using only keyboard or single taps.
• 2.5.8 Target size (minimum): interactive controls need a large enough tappable area, which usually means adjusting CSS padding and hit areas rather than the visible icon size; test by measuring actual clickable regions, not just what’s drawn on screen.
• 3.3.8 Accessible authentication (minimum): login and password recovery flows can’t rely solely on a visual CAPTCHA or a cognitive test like solving a puzzle; offer alternatives such as email or push-based verification.

For target size and dragging, the fix is rarely a redesign. Increasing clickable padding and adding an alternative control, like plus and minus buttons next to a draggable handle, satisfies the target size and dragging criteria without touching the visual layout. For authentication, the intent is to keep security intact while removing exclusive reliance on tests that are hard for some users to complete under time pressure or without full vision.

Top checklist: common AA failures and quick fixes

Most AA gaps trace back to a short, repeatable list of issues rather than exotic edge cases. Triage in this order:

1. Contrast: confirm 4.5:1 for normal text and 3:1 for large text and UI components; a designer can usually fix this in an afternoon.
2. Visible focus indicators: make sure every interactive element shows a clear outline when focused, not just on hover.
3. Keyboard operability: every button, menu, and custom widget must work without a mouse, which is a developer task that often surfaces hidden keyboard traps.
4. Heading structure and skip links: headings should follow a logical order, and a skip-to-content link should exist on every template.
5. Accessible labels and captions: form fields need programmatic labels, and video content needs captions, both quick wins once flagged.
6. Minimum target sizes and drag alternatives: covered above, typically a CSS and component-logic fix.
7. Accessible authentication: a product and engineering decision, often the most involved item on this list.
8. Correct ARIA usage: misapplied ARIA roles can make a page worse than no ARIA at all, so QA should verify with a screen reader, not just an automated rule.

Contrast, labels, and focus indicators are quick wins a small team can close in days. Navigation, forms, and heading structure take a sprint or two. Complex interactions like custom drag components and authentication flows deserve dedicated engineering time, since they touch both design and security logic.

How to test: automated scans, manual review, and assistive technology

Automated tools are fast and repeatable, and they’re genuinely good at catching contrast failures, missing alt text, unlabeled form fields, and misused ARIA attributes. What they can’t do is confirm that a screen reader user can actually complete a task, because usability with assistive technology depends on how elements behave together, not just whether each one is individually valid. The Access Board’s ICT guidance is explicit that automated tools alone are insufficient and recommends pairing them with manual and assistive-technology testing.

A practical audit combines both:

• Run an automated scan first to catch the bulk of code-level issues quickly.
• Complete a keyboard-only walkthrough of every core user flow, from navigation to check out or form submission.
• Test key screens with a screen reader like NVDA or VoiceOver to catch labeling and reading-order problems automated tools miss.
• Check mobile flows for motor accessibility, including target size and gesture alternatives.
• Spot-check for cognitive readability: plain language, consistent navigation, and predictable interactions.

Once testing is done, turn the findings into a backlog with a ticket per issue, a link to the affected code, and a test log showing how it was verified. That record becomes your evidence package later.

Pro Tip: Keep every manual test log tied to a specific page URL and date, so a re-check six months later shows exactly what changed.

Legal and policy context: ADA, Section 508, and your obligations

U.S. Department of Justice guidance ties web accessibility obligations under the ADA to equal enjoyment of goods and services, and DOJ resources note that public-entity rules have adopted WCAG 2.1 Level AA as the technical standard in many cases, while treating newer WCAG versions as a defensible best practice. Public entities should check their specific obligations, since regulatory materials document compliance timelines and costs tied to that standard.

Private businesses under Title III don’t have one uniform federal WCAG version written into law, but courts and settlements increasingly reference 2.1 and 2.2 as the practical benchmark. Adopting WCAG 2.2 now, ahead of any formal requirement, is a reasonable way to reduce that exposure. Whatever your obligation, document the decision: keep dated scan records, publish an accessibility statement, and put re-checks on a calendar.

A shift-left workflow your team can run in sprints

Treat accessibility as part of the build, not a final gate:

1. Run a discovery scan to find the full list of issues.
2. Prioritize by user impact and fix effort, using the checklist above as a starting filter.
3. Add accessibility acceptance criteria to each sprint story before development starts.
4. Fix the code and write a unit test that guards against regression.
5. Verify manually with a keyboard and at least one assistive technology.
6. Update the evidence record with the ticket, code reference, and test result.

A product owner sets priority, a designer builds accessible patterns from the start, a developer implements and unit-tests, and a QA or manual tester confirms with real assistive technology before the story closes. A sample acceptance criterion: “All interactive controls are reachable and operable by keyboard, focus is visible at every step, and text contrast meets 4.5:1.”

Pro Tip: Write your acceptance criteria before development starts, not during QA, so fixes are built in rather than bolted on.

Documenting conformance and keeping it current

Compliance evidence needs a few specific pieces, kept up to date:

• Dated scan reports showing what was tested and when.
• A remediation ticket backlog with links to the actual code changes.
• Manual test logs recording which assistive technology was used and what passed.
• A clearly stated date of last verification.

Scheduled re-checks catch regressions before they become a legal or reputational problem, since a page that passed last quarter can break the moment a new component ships. An accessibility statement should name the scope of the site covered, the conformance level claimed, the date of the last audit, a contact method for reporting issues, and the plan for ongoing remediation. A published example, like the one from MySafeTherapy, shows how a simple statement can lay out that scope and contact information clearly.

Why pragmatic compliance beats perfect compliance

Automated scans catch a meaningful share of accessibility barriers, but they were never meant to stand alone. Some solutions pair scans with scheduled re-checks and plain-language guidance for fixing issues directly in a site’s code, because a runtime patch doesn’t hold up under real assistive-technology use. Combine automated coverage with developer-owned fixes and a documented trail, and conformance becomes something you can actually demonstrate.

— The AccessWiser Team

Where AccessWiser fits into your compliance plan

AccessWiser scans against WCAG 2.2 AA success criteria, with Section 508 and EN 301 549 mappings built in, and turns each finding into plain-language guidance your developers can act on directly in the code. Scheduled re-checks catch regressions, and dated records support the accessibility statement you publish. It fits the exact workflow above: discovery, remediation, verification, and ongoing monitoring in one place. See plans and pricing to find the right fit for your site.

Sources

• Guidance on Web Accessibility and the ADA
• Web-based Intranet and Internet Information and Applications (1194.22)

FAQ

What does WCAG Level AA mean?

Level AA is the middle of three conformance levels in WCAG (A, AA, and AAA), and it’s the level most legal and policy references point to. Meeting Level AA means satisfying every Level A and Level AA success criterion in the WCAG 2.2 specification, covering things like contrast, keyboard access, and clear labeling.

Is WCAG 2.2 mandatory?

There’s no single federal law naming WCAG 2.2 by version number for every organization. DOJ guidance notes that many public-entity rules currently reference WCAG 2.1 AA, while adopting WCAG 2.2 is treated as a defensible best practice ahead of any future requirement.

What are the newest WCAG success criteria?

WCAG 2.2 added several success criteria, with four affecting AA conformance directly: Focus not obscured, Dragging movements, Target size (minimum), and Accessible authentication (minimum). Each targets a specific gap for people with motor or cognitive disabilities that earlier versions left open.

Is WCAG 2.2 finalized?

Yes, WCAG 2.2 is a finalized W3C Recommendation, published in October 2023, and it remains backward compatible with WCAG 2.1. It also removed one older criterion, Parsing, since modern browsers handle the errors it addressed.

How does AccessWiser help with WCAG 2.2 AA compliance?

AccessWiser scans a site against WCAG 2.2 AA criteria, maps findings to Section 508 and EN 301 549, and provides plain-language guidance for fixing each issue in the site’s own code. Scheduled re-checks and dated records then support the documentation your accessibility statement needs.

Articles on this blog are general information about web accessibility, not legal advice. Laws change and their application depends on your specific situation — for decisions with legal consequences, consult a qualified legal professional.