Brief History: Why WCAG Keeps Evolving
Web accessibility standards evolve as technology changes and our understanding of disability improves. Legal reality: The ADA doesn't specify which WCAG version organizations must follow. However, accessibility professionals and legal observers often reference WCAG 2.1 Level AA as a reasonable standard. As WCAG 2.2 becomes more established, it may increasingly be recognized as current best practice. The question isn't "must we adopt WCAG 2.2?" It's "when should we start planning for it?"
WCAG 1.0 (1999): First official guidelines. Very desktop-focused. Outdated now.
WCAG 2.0 (2008): Major rewrite. Technology-neutral principles. Still used widely.
WCAG 2.1 (2018): Added mobile accessibility, low-vision design, cognitive considerations. This is what most companies target today.
WCAG 2.2 (2023): NEW. Focuses on target sizing, persistent user controls, and improved cognitive accessibility. This is emerging as a new standard.
What's New in WCAG 2.2: The 9 New Success Criteria
WCAG 2.2 adds 9 new success criteria (accessibility requirements). Here are the ones that will likely impact your website:
What it means: Clickable targets (buttons, links, form fields) must be at least 24×24 CSS pixels, with exceptions for inline links and targets next to other targets.
Why it matters: Affects users with motor disabilities, tremors, or anyone on a mobile device. This is the most impactful new requirement.
Your action: Audit your buttons and links. Many sites use 18-20px targets. You'll need to expand them to 24px or document exemptions.
Implementation difficulty: Medium. May require redesign of compact layouts.
What it means: If your site uses drag-and-drop interactions (reordering lists, moving files), provide keyboard-accessible alternatives.
Why it matters: Keyboard users and switch control users can't use drag-and-drop alone.
Your action: If you have drag-and-drop, add buttons or keyboard shortcuts (e.g., "Move Up," "Move Down").
Implementation difficulty: Low to Medium. Most modern frameworks support this.
What it means: Navigation, search, and other persistent UI controls (that appear on multiple pages) must appear in the same relative order each time.
Why it matters: Users with cognitive disabilities rely on consistency. Randomized layouts are confusing.
Your action: Make sure your navigation, search box, and other repeated elements are in the same place on every page. No randomization.
Implementation difficulty: Very Low. Most sites already do this.
What it means: When keyboard users tab through your site, focus indicators must be visible (not hidden or covered by other elements).
Why it matters: Keyboard users rely on seeing where they are on the page.
Your action: Check that your focus indicators aren't hidden behind sticky headers or other elements. Don't use `outline: none` without providing an alternative visual indicator.
Implementation difficulty: Very Low. Usually CSS only.
What it means: Focus indicators must meet specific design criteria: 2px minimum thickness, sufficient contrast, etc.
Why it matters: This is a more rigorous version of visible focus indicators. The focus indicator itself must be well-designed.
Your action: Review your focus indicators. If they're thin, low-contrast lines, upgrade them to at least 2px thick with high contrast.
Implementation difficulty: Very Low to Low. CSS refinement.
What it means: Authentication mechanisms should not rely solely on cognitive function tests. Provide alternatives to CAPTCHAs or memory-based authentication.
Why it matters: Users with cognitive disabilities may struggle with traditional CAPTCHAs.
Your action: If you use CAPTCHAs, provide alternatives like email verification or authentication apps.
Implementation difficulty: Medium. Depends on current authentication approach.
Redundant Entry (Level A) - 3.3.7: If users enter information previously provided, don't make them re-enter it.
Accessible Authentication (Minimum) (Level A) - 3.3.8: Basic authentication accessibility requirements.
Accessible Authentication (Enhanced) (Level AAA) - 3.3.9: Enhanced authentication accessibility requirements.
Impact by Site Type: What This Means for You
Most affected by: Target size (24×24 buttons), persistent checkout flow
Action required: Audit checkout buttons, review cart controls, ensure consistent checkout flow
Estimated effort: 20-40 hours
Most affected by: Drag-and-drop alternatives, target size for data table controls, focus appearance
Action required: Add keyboard alternatives to drag-and-drop, audit button/icon sizes, verify focus indicators
Estimated effort: 40-80 hours
Most affected by: Persistent navigation order, focus appearance
Action required: Ensure navigation is consistent across pages, audit focus indicators
Estimated effort: 5-15 hours
Most affected by: ALL of the above. Government and healthcare sites often have higher accessibility expectations.
Action required: Complete WCAG 2.2 Level AA audit and remediation
Estimated effort: 100-200+ hours depending on site size
When Should You Consider WCAG 2.2?
There's no immediate federal mandate requiring WCAG 2.2. However, momentum is building toward recognizing it as current best practice.
Accessibility professionals increasingly reference WCAG 2.2 as the current standard
Some accessibility audits and lawsuits have begun citing WCAG 2.2 criteria
Several states are reviewing their accessibility standards
Federal contractors and healthcare organizations are evaluating adoption timelines
2025-2026: WCAG 2.2 Level AA may increasingly be recognized as current best practice
2026-2027: WCAG 2.2 Level AA may become commonly referenced in accessibility discussions
2027-2028: Federal standards updates may formalize WCAG 2.2 references
If your site is not yet compliant: Consider targeting WCAG 2.2 Level AA
If your site is WCAG 2.1 compliant: Plan a WCAG 2.2 evaluation over the next 2 years
If you're starting a new site: Consider building for WCAG 2.2 from day one
Is WCAG 2.1 Still Valid?
You might wonder: "We're WCAG 2.1 compliant. Is that still acceptable?" Yes, for now. WCAG 2.1 is still a valid, respected standard. Compliance with WCAG 2.1 Level AA represents a solid accessibility foundation. Most accessible websites currently target WCAG 2.1. However: As WCAG 2.2 becomes more established, accessibility professionals and organizations may increasingly reference it as current best practice.
If your site is not yet compliant: Consider targeting WCAG 2.2 Level AA instead of 2.1
If your site is WCAG 2.1 compliant: Plan a WCAG 2.2 evaluation over the next 2 years
If you're starting a new site: Consider building for WCAG 2.2 from day one
Quick Reference: Major Changes for Your Team
Target sizes matter more: 24×24 CSS pixels minimum (enhanced from previous recommendations)
Focus indicators must be visible: No hiding or low-contrast outlines
Drag-and-drop needs keyboard alternatives: Must support keyboard input
Consistent navigation: UI controls must appear in the same order on all pages
Authentication accessibility: Provide alternatives to cognitive tests like CAPTCHAs
Your WCAG 2.2 Evaluation Plan
Run a WCAG 2.2 accessibility audit
Document specific gaps and remediation effort
Identify high-priority issues (target size, focus visibility, drag-and-drop)
Create a remediation roadmap
Estimate effort and budget
Decide: New build with WCAG 2.2 vs. retrofitting existing site
Address high-priority issues (target size, focus appearance)
Add keyboard alternatives for complex interactions
Test thoroughly with assistive technology
Get an independent WCAG 2.2 audit to verify compliance
Document compliance efforts
Update your accessibility statement
Is Your Site Ready for WCAG 2.2?
Find out which WCAG 2.2 requirements your site addresses and what you may want to consider updating. Get a detailed roadmap for enhanced accessibility.