Web Accessibility in 2026: WCAG 2.2 for Every Development Team

What’s New in WCAG 2.2

WCAG 2.2, finalised in September 2023, adds nine new success criteria at Level A and AA. The most impactful for typical web projects:

• 2.4.11 Focus Not Obscured (Minimum) — AA: Focused UI components must not be entirely hidden by sticky headers, cookie banners, or other overlaid content
• 2.4.12 Focus Not Obscured (Enhanced) — AAA: Focused component must be fully visible
• 2.5.7 Dragging Movements — AA: All functionality achieved by dragging (e.g., sliders, sortable lists) must have a single-pointer alternative
• 2.5.8 Target Size (Minimum) — AA: Interactive targets must be at least 24×24 CSS pixels, or have sufficient spacing around smaller targets
• 3.2.6 Consistent Help — A: If help mechanisms (chat, phone, FAQ) appear on multiple pages, they must be in a consistent location
• 3.3.7 Redundant Entry — A: Don't ask users to re-enter information they've already submitted in the same session

Most Commonly Failed Checkpoints in Practice

Beyond the new 2.2 criteria, our accessibility audits consistently find these failures across commercial sites:

• Colour contrast (1.4.3): Text against background below 4.5:1 ratio — most frequently on light grey text on white, and reversed text on brand-colour backgrounds
• Form labels (1.3.1): Input fields with placeholder text substituting for visible labels — placeholder text disappears and is not accessible to screen readers as a label
• Keyboard navigation (2.1.1): Custom dropdown menus, date pickers, and modals that cannot be operated by keyboard alone
• Image alt text (1.1.1): Decorative images that should have alt="" instead have descriptive text; informative images lack meaningful alt text
• Focus visible (2.4.7): Focus outline removed with outline:none in CSS — never do this without providing a custom visible focus style

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

The Business Case for Accessibility

Accessibility is commonly treated as a compliance cost. The organisations that treat it as a product quality investment consistently see measurable returns. Accessible sites perform better in search: Google’s crawlers interact with content similarly to assistive technologies, meaning strong heading hierarchy, descriptive alt text, and keyboard-navigable interactive elements directly improve technical SEO. Sites with high accessibility scores in Lighthouse consistently show stronger Core Web Vitals, lower bounce rates, and higher organic CTR — all downstream of the same engineering practices that deliver WCAG compliance.

The market size argument is compelling: 1.3 billion people live with some form of disability globally, with aggregate spending power estimated at $13 trillion annually. Excluding this audience through inaccessible design is not a minor rounding error — it’s a structural revenue gap. For e-commerce specifically, each additional checkout step that requires mouse precision, small tap targets, or visual-only cues eliminates a percentage of users with motor impairments, low vision, or ageing-related accessibility needs. The Baymard Institute’s checkout research consistently shows that reducing friction for accessibility-constrained users improves conversion rates across the entire user base.

Customer support overhead is also materially reduced by accessible design: when interfaces are self-explanatory, navigable by keyboard, and readable by screen readers, users with varying abilities can self-serve at higher rates, reducing inbound support volume for the customer segment most likely to need clarification or alternative pathways through complex forms.

Legal Risk and Enforcement in 2026

The legal landscape for web accessibility has shifted decisively in the past five years. The US ADA Title III now has substantial case law establishing that websites serving the public are “places of public accommodation” subject to accessibility requirements. Federal agency rule-making in 2024 explicitly adopted WCAG 2.1 AA as the enforceable standard for certain categories of government-funded organisations and their digital properties. Class-action lawsuits against retailers, hospitality chains, and SaaS companies have resulted in settlements ranging from $50,000 to several million dollars, plus the ongoing cost of mandated accessibility remediation programs.

In the UK, the Equality Act 2010 covers websites under “reasonable adjustments” for service providers. The Public Sector Bodies Accessibility Regulations 2018 apply WCAG 2.1 AA requirements to all public sector websites and apps with mandatory monitoring and enforcement by the Cabinet Office. In the EU, the European Accessibility Act comes into full effect across member states in 2025–2026, applying to a broad set of digital products and services with fines that vary by country but can reach 6 figures for systematic non-compliance.

For any business selling to government, healthcare, education, or enterprise clients: WCAG 2.2 AA compliance is increasingly a procurement requirement, not just a legal risk mitigation. Tenders and RFPs now routinely include accessibility conformance statements as part of vendor qualification. Non-compliance is a disqualifier, not a risk to be managed.

Integrating Accessibility into Your Dev Workflow

Accessibility is cheapest to fix at design and development time — retrofitting an inaccessible site typically costs 5–10x more than building it right initially. Embed these practices into your standard workflow:

• Automated scanning: Add axe-core or Lighthouse accessibility audit to your CI pipeline — catches 30–40% of issues automatically without manual effort
• Keyboard testing: Tab through every page and interactive component in your browser before each release — costs 10 minutes per page
• Screen reader testing: NVDA + Chrome (Windows), VoiceOver + Safari (macOS/iOS) — 15 minutes of screen reader testing reveals issues automated tools consistently miss
• Colour contrast tooling: Browser DevTools now show contrast ratio on hover; Figma plugins like "Stark" catch contrast issues in design before a single line of code is written
• Component-level accessibility docs: Document ARIA roles, keyboard interaction patterns, and focus management in your design system so every engineer implements consistently
• Accessibility acceptance criteria: Add explicit accessibility requirements to every ticket that touches UI — "keyboard navigable", "screen reader announced", "contrast ratio ≥4.5:1"

WCAG 2.2 AA Pre-Launch Checklist

Before launching any new page or feature, verify these most commonly failed checkpoints:

• All text meets 4.5:1 contrast ratio against its background (3:1 for large text ≥18pt)
• All form inputs have a visible, persistent label — not placeholder-only
• All interactive elements are keyboard accessible and have a visible focus indicator
• All images have appropriate alt text (descriptive for informative, empty for decorative)
• Focus is not obscured by sticky headers, overlays, or cookie banners (WCAG 2.4.11)
• All interactive targets are at least 24×24 CSS pixels (WCAG 2.5.8)
• All drag-and-drop interactions have a single-pointer alternative (WCAG 2.5.7)
• Page has a logical heading hierarchy (H1 → H2 → H3) and landmark regions
• axe-core or Lighthouse accessibility audit returns zero critical violations