WCAG 2.1 vs 2.2: Which Standard Should You Follow in 2026?

🇺🇸 United States — ADA Title II (Government)

The DOJ's April 2024 rule explicitly requires WCAG 2.1 Level AA for state and local government websites. Deadlines: April 24, 2026 for large agencies (50,000+ population), April 26, 2027 for smaller agencies. This is the first time ADA regulations have named a specific WCAG version.

For more details, see our ADA Website Compliance Guide.

🇺🇸 United States — ADA Title III (Private Sector)

No regulation specifies a WCAG version for private-sector websites yet. However, courts and settlement agreements consistently reference WCAG 2.1 Level AA as the benchmark. DOJ statements and amicus briefs also point to 2.1 AA as the expected standard for "places of public accommodation."

🇺🇸 United States — Section 508 (Federal)

Section 508 was refreshed in 2018 to incorporate WCAG 2.0 Level A and AA by reference. The Access Board has signaled potential updates to reference WCAG 2.1 or 2.2, but no rule change has been published yet. Federal agencies should plan for WCAG 2.1 AA minimum.

🇪🇺 European Union — European Accessibility Act (EAA)

The EAA took effect June 28, 2025, requiring accessibility for products and services sold in the EU. The harmonized standard EN 301 549 references WCAG 2.1 Level AA. EN 301 549 is expected to update to reference WCAG 2.2, but the timeline is unclear. Companies serving EU customers should target WCAG 2.1 AA as the legal floor.

🇬🇧 United Kingdom

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require WCAG 2.1 Level AA for public-sector sites. The Equality Act 2010 applies broadly to private-sector sites, with WCAG 2.1 AA as the de facto standard.

🇨🇦 Canada — Accessible Canada Act

Federal organizations must meet WCAG 2.1 Level AA. Provincial standards vary: Ontario's AODA references WCAG 2.0 Level AA but is expected to update.

If you use a shared layout component (header, footer, sidebar) for help mechanisms, you likely pass already. Verify that help links, chat widgets, and contact info appear in the same position across all pages.

Effort: 1-2 hours audit + fix. Most modern sites pass naturally.

Audit multi-step forms: checkout flows, registration wizards, application forms. Wherever the user enters data in step 1 that's needed again in step 3, auto-populate it or offer a selection.

<!-- Good: HTML autocomplete attributes -->
<input type="text" name="shipping-city" autocomplete="shipping locality" />

<!-- Good: "Same as shipping" checkbox -->
<label>
  <input type="checkbox" id="same-address" />
  Billing address same as shipping
</label>

Effort: 2-8 hours depending on form complexity.

Check your login, signup, and password reset flows:

• •Password managers work (no autocomplete="off" on password fields, no paste blocking)
• •CAPTCHAs have alternatives (invisible reCAPTCHA, audio challenges, email verification)
• •You don't require transcribing a code from one device to another without copy-paste support

Effort: 2-4 hours if you just need to remove paste-blocking. More if you need to replace CAPTCHAs.

Tab through every page and check if focused elements get hidden behind sticky headers, footers, cookie banners, or chat widgets. The fix:

/* Account for sticky header when scrolling to focused elements */
html {
  scroll-padding-top: 80px; /* Match your header height */
  scroll-padding-bottom: 60px; /* Match any sticky footer */
}

/* Ensure cookie banners don't block focus */
.cookie-banner {
  /* Position at bottom but don't cover content */
  position: fixed;
  bottom: 0;
  z-index: 1000;
}

/* When cookie banner is visible, add body padding */
body.has-cookie-banner {
  padding-bottom: 80px;
}

Effort: 2-6 hours. Mostly CSS adjustments and testing.

Audit all interactive elements for 24×24px minimum size. Pay special attention to icon buttons, close buttons, pagination links, and mobile navigation toggles. Best practice is 44×44px per Apple/Google HIG, even though 24px is the WCAG minimum.

/* Global baseline for interactive elements */
button, a, [role="button"], input, select, textarea {
  min-height: 44px;
  min-width: 44px;
}

/* For inline links in text, use padding instead */
p a, li a {
  min-height: auto;
  min-width: auto;
  padding: 2px 0; /* Exempt from target size per WCAG 2.2 */
}

Effort: 4-16 hours depending on how many small interactive elements exist.

Inventory every dragging interaction on your site — sliders, sortable lists, kanban boards, map widgets, drag-and-drop uploads — and ensure each has a non-dragging alternative.

• •Range sliders: Add a text input or +/− stepper buttons
• •Sortable lists: Add "Move up / Move down / Move to position" controls
• •File upload: Keep drag zone, ensure the file picker button always works
• •Map widgets: Add keyboard pan controls or address search

Effort: Highly variable — 0 hours if you have no drag interactions, 20+ hours for complex apps with kanban boards or custom editors.

What is the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 adds 9 new success criteria on top of WCAG 2.1 and removes one (4.1.1 Parsing). The new criteria focus on mobile usability, cognitive accessibility, and better keyboard support — including focus visibility, dragging alternatives, target size minimums, consistent help, redundant entry prevention, and accessible authentication.

Which WCAG standard is legally required in 2026?

Most laws reference WCAG 2.1 Level AA. The DOJ's ADA Title II rule and the European Accessibility Act both use WCAG 2.1 AA as their benchmark. No law currently mandates WCAG 2.2, but it is the W3C's current recommendation and the direction standards are heading.

Is WCAG 2.2 backward-compatible with 2.1?

Yes. WCAG 2.2 includes all WCAG 2.1 criteria plus 9 new ones. A site conforming to WCAG 2.2 Level AA automatically conforms to WCAG 2.1 Level AA. The only change is that 4.1.1 Parsing was removed (it's obsolete with modern HTML5 parsing).

Should I follow WCAG 2.1 or 2.2?

If you're starting fresh or redesigning, target WCAG 2.2 Level AA. If you're already 2.1 compliant, upgrading to 2.2 is incremental — only 6 new criteria at A/AA. Since 2.2 is a superset of 2.1, meeting 2.2 satisfies both standards simultaneously.

How long does it take to upgrade from WCAG 2.1 to 2.2?

For a typical content website that already meets WCAG 2.1 AA, the upgrade takes 1-3 weeks of focused effort. The main tasks are: auditing touch target sizes, adding alternatives to any drag interactions, checking focus visibility with sticky elements, and reviewing authentication flows. Complex web applications with custom editors or kanban-style interfaces may need more time.

What about WCAG 3.0?

WCAG 3.0 is under development but won't be finalized for several years (earliest estimates: 2028-2030). It will be a significantly different approach — new scoring system, new conformance model — but is not yet stable enough to plan around. WCAG 2.2 is the standard to target through at least 2028.