WCAG 2.1 AA vs. WCAG 2.2

WCAG 2.1 Level AA includes 50 success criteria across four principles:

Perceivable
Operable
Understandable
Robust

Level AA is the level most U.S. ADA settlements require. Not Level A alone. Not Level AAA.

Examples of WCAG 2.1 AA requirements:

Images need alt text (1.1.1).
Text contrast ratio must be at least 4.5:1 (1.4.3).
All functionality must work with a keyboard (2.1.1).
Focus indicators must be visible (2.4.7).
Forms must have labels (3.3.2).

Most ADA website lawsuits in California, New York, and Florida cite WCAG 2.1 AA specifically.

The U.S. Department of Justice adopted WCAG 2.1 AA for Title II state and local government websites in its April 24, 2024 final rule. That regulation does not reference WCAG 2.2.

So legally, WCAG 2.1 AA is still the anchor in the United States.

But technically, 2.2 is now the newer spec.

what wcag 2.2 adds

WCAG 2.2 adds nine new success criteria. One from 2.1 was removed (4.1.1 Parsing), but that removal doesn’t reduce obligations in practice because modern HTML validators already enforce parsing rules.

The nine new criteria focus heavily on cognitive disabilities and motor impairments.

Here are the ones that matter most in real audits.

2.4.11 focus appearance (minimum) – level aa

This is one of the most significant additions.

WCAG 2.1 required visible focus (2.4.7). It did not define how visible.

Developers could use a faint 1px outline that technically met the rule but was barely noticeable.

WCAG 2.2 now requires:

Focus indicators must have at least a 3:1 contrast ratio against adjacent colors.
They must cover a minimum area equivalent to a 2px border around the element.

In plain terms: the focus outline must be clearly visible.

In a 2024 audit of a regional bank website, the focus indicator was a thin gray glow. It technically existed. Under WCAG 2.1 AA, that often passed. Under 2.2 AA, it failed.

The redesign required thicker outlines and higher contrast.

That took one developer about three hours to fix site-wide.

Small change. Clear standard.

2.4.12 focus not obscured (minimum) – level aa

This addresses sticky headers and popups.

If a user tabs to a link, the focused element cannot be hidden behind a fixed header or cookie banner.

This is common on e-commerce sites.

In 2023, I tested a large car dealership platform where tabbing through inventory filters caused the focused checkbox to scroll under a sticky navigation bar. The user could not see where focus was.

Under WCAG 2.1, this was not clearly defined. Under 2.2, it fails.

Fixing it required adjusting scroll margin and focus management in JavaScript.

2.5.7 dragging movements – level aa

If functionality requires dragging, there must be a single-pointer alternative.

Example: a slider that requires dragging a knob.

Users with motor impairments may not be able to drag precisely.

Now, arrow buttons or text input must be provided as an alternative.

A public transit site I reviewed in early 2024 used a drag-only time selector. Under 2.1, it passed keyboard requirements. Under 2.2, it failed because no non-drag alternative existed.

The fix required adding numeric input fields.

2.5.8 target size (minimum) – level aa

Interactive targets must be at least 24 by 24 CSS pixels, with some exceptions.

Small text links placed close together often fail this.

Mobile-heavy sites are most affected.

A city utility payment portal had tiny “edit” and “delete” icons next to saved addresses. They were 16x16 pixels. Under 2.2, they fail unless sufficient spacing exists.

This criterion increases design constraints.

Designers don’t always like it.

what wcag 2.2 changes at level a

Some of the nine new criteria are Level A, including:

3.2.6 consistent help
3.3.7 redundant entry
3.3.8 accessible authentication (minimum)

Accessible authentication is the most discussed.

If a login system uses cognitive function tests, like memorizing a password without help from a password manager, that may fail.

WCAG 2.2 requires that authentication not rely solely on memory, unless alternatives exist.

This affects banking sites and government portals that block paste functionality in password fields.

Blocking paste can now create compliance issues.

In 2024, several financial institutions quietly removed “no paste” restrictions after internal accessibility reviews.

what wcag 2.2 removes

Success criterion 4.1.1 Parsing was removed.

It required valid HTML.

In practice, accessibility testing tools already flag parsing errors.

Its removal does not relax requirements.

It simplifies duplication with modern browser standards.

No one lost compliance obligations in real-world terms.

what did not change

All WCAG 2.1 AA requirements remain in WCAG 2.2 AA.

Alt text rules did not change.
Contrast ratios did not change.
Keyboard access did not change.
Form labeling did not change.
Captioning did not change.

If a site fails WCAG 2.1 AA, upgrading to 2.2 does nothing until 2.1 issues are fixed.

In real audits, most failures are still basic:

Missing alt text.
Low contrast text.
Empty links.
Unlabeled buttons.
Inaccessible PDFs.

The new 2.2 criteria rarely represent the majority of violations.

They refine edge behavior.

legal adoption: where wcag 2.2 stands

As of early 2025:

The DOJ Title II rule references WCAG 2.1 AA.
Most ADA Title III settlements reference WCAG 2.1 AA.
No federal regulation mandates WCAG 2.2 yet.

However, new procurement contracts increasingly reference “WCAG 2.2 AA or latest version.”

Large universities and healthcare systems are starting to update internal policies to 2.2.

There is a lag between standard publication and legal enforcement.

That lag may last years.

a real case comparison

In late 2023, I audited two similar municipal websites.

City A aimed for WCAG 2.1 AA.
City B adopted WCAG 2.2 AA proactively.

City A passed 2.1 but failed 2.2 on focus appearance and target size.

City B redesigned buttons and navigation spacing early.

City A later had to revisit its CSS after updating procurement language to reference 2.2.

City B avoided that second round of work.

The trade-off: City B spent more on initial design adjustments.

Short-term cost vs. long-term alignment.

target size tension in dense interfaces

Target size minimum (24x24 pixels) affects admin dashboards and data tables.

In a county property tax system, table rows had small icon buttons for edit and delete.

Enlarging them reduced visible rows per page.

Staff complained about scrolling more.

Accessibility increased physical space usage.

Design trade-offs are real.

WCAG 2.2 does not eliminate layout density issues. It forces prioritization.

focus appearance impact on design systems

Design systems that relied on subtle outlines must update.

Some corporate style guides intentionally minimized focus styling to look “clean.”

WCAG 2.2 makes that approach risky.

In early 2024, a SaaS company revised its design tokens to include a 2px high-contrast focus ring across all components.

It required retesting 130 UI components.

Cost: roughly 80 developer hours.

But it standardized behavior across products.

accessible authentication controversy

Banks often disable paste in password fields to prevent fraud.

Under WCAG 2.2, this may violate accessible authentication unless alternatives exist.

Allowing password managers is now expected.

A regional credit union removed paste restrictions in January 2024 after internal legal review tied to WCAG 2.2.

Security teams initially objected.

Accessibility requirements prevailed.

This shows real internal friction.

overlays and wcag 2.2

Accessibility overlays rarely address new 2.2 criteria.

Focus appearance depends on CSS styling, not JavaScript overlays.

Target size depends on layout, not toolbar widgets.

Dragging alternatives require UI redesign.

Sites relying on overlays for WCAG 2.1 AA will likely fail WCAG 2.2 AA in several areas.

Overlays do not resize targets or redesign layouts automatically.

This widens the gap between marketing claims and actual compliance.

how automated tools handle 2.2

As of mid-2024, major accessibility testing tools began adding checks for:

Focus contrast ratios.
Minimum target size.
Obscured focus detection.

Automated detection for some 2.2 criteria is limited.

Dragging movements often require manual review.

Accessible authentication requires logic analysis.

Automated scans still miss many real barriers.

Manual testing remains necessary.

practical audit differences

In a typical WCAG 2.1 AA audit, I might flag 40–80 issues on a mid-sized site.

With 2.2 AA, that number might increase by 5–15 percent due to:

Focus styling updates.
Target size adjustments.
Authentication logic.

The majority of work still involves traditional 2.1 issues.

But new design system updates often affect every page at once.

That can be disruptive.

mobile design pressure

Target size minimum matters most on mobile.

Small icon links in footers or filter menus now trigger failures.

Designers sometimes rely on dense filter chips.

Under WCAG 2.2, spacing must increase or alternative input methods must exist.

Mobile-first designs must allocate more touch area.

This slightly increases vertical space usage.

Users with motor impairments benefit. So do users with large fingers.

government adoption timing

The DOJ’s Title II rule currently references WCAG 2.1 AA.

Public entities complying for April 2026 deadlines are working toward 2.1.

Some accessibility consultants recommend adopting 2.2 immediately to avoid rework.

Others argue that staying aligned with the regulation avoids scope creep.

Both positions have merit.

If a government entity finishes 2.1 remediation in 2026 and a 2.2 update becomes required later, it may need another round of adjustments.

If it implements 2.2 now, it may exceed legal minimum but reduce future updates.

Budget constraints shape that decision.

cognitive accessibility improvements

WCAG 2.2 emphasizes cognitive accessibility more than 2.1 did.

Redundant entry prevents forcing users to re-enter data already provided.

Consistent help requires support mechanisms to remain in consistent locations.

These changes are subtle but affect large forms and multi-step workflows.

A healthcare portal I reviewed in 2024 required patients to re-enter insurance numbers across steps.

Under 2.2, that workflow required revision.

Reducing redundant entry improves usability beyond disability contexts.

But refactoring multi-step forms can be complex.

the business risk calculation

Today, most ADA lawsuits cite WCAG 2.1 AA.

A site compliant with 2.1 AA but not 2.2 AA is unlikely to face immediate legal exposure solely due to 2.2 gaps.

However, procurement contracts and RFP language increasingly reference the latest WCAG version.

A vendor bidding on a state contract in 2024 lost points for referencing 2.1 instead of 2.2 in its accessibility statement.

The legal system lags. Procurement practices move faster.

the upgrade decision

Upgrading from WCAG 2.1 AA to 2.2 AA is not a rebuild.

It is an incremental design and interaction update.

Typical upgrade tasks:

Enhance focus styles.
Increase interactive target sizes.
Add non-drag alternatives.
Review authentication logic.
Test sticky headers for focus obstruction.

Most codebases can adapt in weeks, not months.

Large legacy systems take longer.

The largest burden remains document accessibility and media captioning, which are unaffected by 2.2.

what stays misunderstood

WCAG 2.2 is not a radical overhaul.

It is evolutionary.

It clarifies visual focus.
It improves motor accessibility.
It reduces cognitive friction.

But it does not rewrite the foundation.

If a site cannot pass 2.1 AA, discussing 2.2 is premature.

Most litigation risk still centers on basic failures: alt text, keyboard access, form labels, captions.

The difference between 2.1 AA and 2.2 AA is real but narrower than marketing materials suggest.

WCAG 2.2 refines compliance. It does not redefine it.