Web App Accessibility & WCAG 2.2 Compliance in 2026

Sophie Laurent Legal & Compliance Lead, YuSMP Group · GDPR, HIPAA, EU AI Act, EAA — guiding US & EU product teams through digital compliance since 2018

TL;DR — WCAG 2.2 & the law at a glance

Why is accessibility compliance urgent in 2026?

Accessibility used to be a UX nice-to-have. In two of the world's largest technology markets, it is now a hard legal requirement. The EU Accessibility Act (EAA) entered into force in June 2025, and it obliges private-sector web and mobile apps aimed at EU consumers to meet EN 301 549 — the European standard that points to WCAG 2.2 Level AA. The United States moved on a parallel track: in April 2024 the Department of Justice finalised rules that codify WCAG 2.1 Level AA as the ADA standard for state and local government sites, and federal courts keep extending ADA Title III liability to commercial web platforms.

None of this timing is accidental. Year after year, the WebAIM Million report has documented the same structural failures, and regulators on both continents have been reading it — over 95% of top-ranked websites carry at least one automatically detectable WCAG failure. The EAA and tougher ADA enforcement are the legislative answer to that inaction.

The risk isn't only regulatory. An inaccessible web app shuts out roughly 1.3 billion people with disabilities worldwide — a segment holding an estimated $13 trillion in disposable income. There's an SEO angle too: Google's Core Web Vitals and crawlability lean on the same semantic, keyboard-navigable markup that WCAG asks for. That is why teams working on custom web application development and web development services now bake accessibility in from sprint one — retrofitting it later costs three to five times more.

WCAG 2.2 and the POUR principles

The Web Content Accessibility Guidelines (WCAG) rest on four high-level principles, shortened to POUR. Every success criterion in WCAG 2.2 maps to one of these four pillars:

• Perceivable. Information and interface components must be presentable to users in ways they can perceive. This means providing text alternatives for non-text content, captions for video, sufficient colour contrast, and content that can be presented in different ways without losing meaning or structure.
• Operable. Users must be able to operate all interface components and navigation without requiring interaction that some users cannot perform — specifically mouse-driven interaction. All functionality must be available from the keyboard, with sufficient time for users to complete tasks, and without content that could trigger seizures.
• Understandable. Content and operation of the UI must be understandable. This covers readable text, predictable behaviour (no unexpected context changes), and input assistance (labels, error identification, suggestions) so users can avoid and correct mistakes.
• Robust. Content must be robust enough to be interpreted reliably by a wide variety of user agents, including current and future assistive technologies. This is primarily an ARIA and semantic-HTML concern: correct role, name, and state exposure so that screen readers, voice control software and braille displays can parse and relay the interface correctly.

WCAG 2.2 landed in October 2023. It added nine new Level A and Level AA success criteria on top of WCAG 2.1, and these are the ones that matter most for web applications:

• 2.4.11 Focus Appearance (AA): the keyboard focus indicator must have a minimum area of at least the perimeter of the focused component times 2 CSS pixels, with a contrast ratio of at least 3:1 between focused and unfocused states. This replaced the vague "some visual indicator" language of 2.4.7.
• 2.4.12 Focus Appearance Enhanced (AAA): stricter version, requiring the focus indicator to be at least 2 CSS pixels thick.
• 2.5.7 Dragging Movements (AA): any functionality that uses dragging must have a single-pointer alternative (tap, click, or other mechanism that does not require dragging).
• 2.5.8 Target Size Minimum (AA): the size of pointer input targets must be at least 24×24 CSS pixels, except where inline text links are used, where spacing compensates, or where an equivalent control exists.
• 3.2.6 Consistent Help (A): if a mechanism for getting help is available on multiple pages, it must appear in a consistent location.
• 3.3.7 Redundant Entry (A): information entered in a previous step of a process must not be requested again unless re-entering it is essential.
• 3.3.8 Accessible Authentication (Minimum) (AA): authentication processes must not rely on cognitive function tests (such as remembering a password or transcribing characters from a CAPTCHA) unless a method or alternative is provided that does not rely on that cognitive function.

Key success criteria at a glance

The table below pairs the most business-critical WCAG 2.2 criteria with their conformance level and the failure pattern you'll most often meet in web apps. It isn't exhaustive. What it does cover are the issues that generate the highest legal and audit risk in 2026.

The EU Accessibility Act: what changes for web apps

For most product categories, the European Accessibility Act (Directive 2019/882) hit its application deadline on 28 June 2025. If you operate in the EU market, this stopped being a planning exercise a while ago. It is a live compliance obligation now.

From that date, the EAA covers services and products placed on the EU market. Web and mobile apps that let consumers reach a service — e-commerce, banking, transport, education platforms — sit squarely in scope. The technical standard to know is EN 301 549 v3.2.1, which folds in WCAG 2.2 Level AA as its web-content requirement. Individual member states can go stricter, but the EU floor is now WCAG 2.2 AA.

There is one carve-out. The EAA grants a microenterprise exemption to service providers with fewer than 10 employees and an annual turnover or balance-sheet total no higher than €2 million — and it reaches service providers only, not product manufacturers. So a US startup with three developers selling a SaaS product to EU enterprise clients would probably qualify today. Scale up, though, and the exemption evaporates. Building accessibility in from the outset always beats retrofitting under deadline pressure from a national enforcement authority.

Enforcement is uneven across member states. Germany, France and the Netherlands already run mature digital-accessibility oversight bodies with inspection powers; others are still standing theirs up. Assume the pressure grows as those agencies finish their setup phase — something the European Commission is actively tracking. A non-conforming product can be withdrawn from the EU market or fined under national implementing legislation, and some member-state laws set fines as high as €100,000.

For US companies selling SaaS to EU B2B clients, the requirement usually arrives through procurement. Legal and procurement teams on the buyer side increasingly write EN 301 549 VPAT (Voluntary Product Accessibility Template) clauses into vendor contracts, and a missing or stale VPAT can knock you out during RFP evaluation.

US ADA exposure for web and SaaS products

Title III of the Americans with Disabilities Act bars discrimination against people with disabilities in places of public accommodation. With rare exceptions, federal courts have read websites and web applications as exactly that — places of public accommodation under Title III. The Ninth and Eleventh Circuits have been the busiest in shaping this line of case law.

In April 2024 the US Department of Justice published a final rule under Title II of the ADA, naming WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile apps. Title II binds government entities, not private companies. Even so, the rule shows how DOJ reads the technical bar for the wider web, and that bar is WCAG 2.1 AA. DOJ guidance and enforcement letters to private firms keep pointing to WCAG 2.1 AA as the expected standard — with WCAG 2.2 now turning up in newer guidance.

By now, ADA web-accessibility litigation is a structured plaintiffs'-bar practice. Around 4,000 lawsuits land each year in the US, mostly in the Southern District of New York and the Eleventh Circuit. A first-time defendant typically settles for $10,000 to $50,000 — but attorney-fee awards under the ADA fee-shifting provision can drive the total to $100,000–$150,000 per case. Serial plaintiffs, filing dozens of near-identical complaints against similar sites, go after the easy targets: missing alt text, empty form labels, unlabelled buttons.

A practical ADA risk mitigation checklist for web app product teams:

• Publish an accessibility statement on your website disclosing your conformance level and providing a contact mechanism for users to report accessibility barriers. Courts have held that providing a remediation path reduces ADA exposure.
• Run automated scans on every release using axe-core in CI. Failing to catch detectable issues (which are trivially identifiable) weakens your defence.
• Maintain a VPAT / ACR (Accessibility Conformance Report) — the US federal procurement standard. Even for non-federal clients, a current VPAT demonstrates good-faith efforts toward compliance.
• Do not rely solely on an overlay widget (AccessiBe, UserWay, etc.) as your accessibility solution. Multiple federal courts have declined to find that overlay widgets satisfy ADA requirements because they inject corrective JavaScript at runtime without fixing underlying inaccessibility; the underlying DOM remains non-conformant.

Semantic HTML as the foundation

Before you reach for ARIA, spend your effort on getting semantic HTML right — it pays back more than anything else. Browsers build the accessibility tree, the data structure assistive technologies read, straight from the HTML semantic layer. Native elements already carry roles, names and keyboard behaviours; custom elements have to rebuild all of that with explicit ARIA.

The accessibility tree equivalence rules:

• <button> exposes role="button", is keyboard focusable by default, fires on Enter and Space. A <div class="button"> exposes role="generic", is not focusable, and fires on click only — it requires role="button", tabindex="0", and a keydown handler to replicate the native behaviour.
• <nav> exposes role="navigation" as a landmark. Screen reader users can jump between landmarks without reading every element. A <div class="nav"> without role="navigation" is invisible to landmark navigation.
• <table> with <th scope="col"> headers gives screen readers the column header when reading each cell. A CSS-grid data display without table semantics offers no such association.
• <label for="input-id"> binds the label to the field. Clicking the label focuses the field (increases target size), and screen readers announce the label when the field receives focus. A placeholder does not substitute — it disappears when the user starts typing and is often too low-contrast to pass 1.4.3.

Working in React, Next.js or another component framework? The semantic-HTML principle still holds at the rendered DOM level. Reaching for as="nav" in Tailwind or styled-components, or checking that a component library outputs semantic elements, is basic framework-level hygiene — the kind of thing worth writing into your design system's contribution guidelines.

Keyboard navigation and focus management

Keyboard accessibility carries enormous impact, yet web app teams overlook it more than almost any other requirement. Under WCAG 2.1.1, full keyboard operability means every interactive element works without a mouse — tabs, accordions, data tables, modals, date pickers, tooltips, sliders, carousels, autocomplete fields, all of them.

The most frequent failure patterns in complex web applications:

• Focus traps in modals. When a modal or dialog opens, focus must move to the modal. When the user reaches the last focusable element inside the modal and presses Tab, focus must cycle back to the first element inside the modal — not escape to the page behind it. When the modal closes, focus must return to the element that triggered it. This is the standard described in the ARIA Authoring Practices Guide (APG) Dialog pattern.
• Invisible focus indicators. The single most widespread failure is outline: none or outline: 0 applied globally to remove the browser's default focus ring for visual design reasons. WCAG 2.4.11 now mandates a minimum visible focus indicator area. The correct approach is to use :focus-visible pseudo-class, which shows the focus ring only for keyboard navigation and not on mouse click, giving both design cleanliness and accessibility compliance.
• Skip navigation links. WCAG 2.4.1 requires a mechanism to skip repeated blocks of content (headers, navigation). A "Skip to main content" link as the first focusable element on the page satisfies this requirement. It is typically visually hidden until focused, using absolute positioning rather than display:none (which removes it from the focus order).
• Custom composite widgets. Dropdown menus, tab panels, tree views, and data grids each have specific keyboard interaction patterns defined in the APG. A tab panel, for example, uses the arrow keys to move between tab buttons and Enter/Space to activate. Implementing Home/End for jump-to-first/last is expected. Deviating from these patterns confuses assistive technology users who have learned the standard patterns.

Here's a cheap test any team can run: test without looking at the screen. Turn the monitor off and Tab through the whole application. If you can't finish a primary task — log in, submit a form, reach a key section — with the keyboard alone, that's a failure real users hit every day.

ARIA and accessible forms

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes — roles, states and properties — that top up the accessibility information native elements already give, mainly for dynamic content and custom interactive components. Its first rule is blunt: do not use ARIA if you can use a native HTML element. A <button> beats a <div role="button"> every time. Think of ARIA as a corrective layer, never a stand-in for semantic HTML.

Key ARIA patterns for common web app components:

• Alerts and live regions. Dynamic content updates (form submission success, server error, loading state change) must be announced to screen reader users. Use role="alert" (for assertive announcements) or aria-live="polite" (for non-urgent updates). Empty ARIA live regions injected at page load time will announce content when they are dynamically populated.
• Status messages. WCAG 4.1.3 (Status Messages) requires that messages about loading state, completion, error, or suggestion are announced without receiving focus. Use role="status" for polite announcements (e.g., "3 results found") and role="alert" for urgent messages.
• Expanded/collapsed states. Accordions, disclosure widgets, and expandable navigation items must expose their state via aria-expanded="true|false". The toggle button (the trigger) carries this attribute, not the content region.
• Form error handling. Error messages must be programmatically associated with their fields. Use aria-describedby pointing to the error message element ID, and aria-invalid="true" on the input when it is in error state. Announce the error message — move focus to the first field in error or inject the message into an aria-live region.
• Required fields. Mark required fields with aria-required="true" (or the native required attribute) and communicate this to visual users beyond just an asterisk, since asterisks are not universally understood.

Testing tools and auditing workflow

No tool, and no combination of tools, catches 100% of accessibility issues. Automated scanning reliably finds about 30–40% of WCAG failures — the structural, measurable ones: missing alt text, contrast ratios, missing labels, empty buttons. The other 60–70% need human judgment. Would a first-time keyboard user follow this interaction pattern? Does this modal sequence make sense to someone who can't see the visual context?

A practical accessibility testing stack for web app teams:

• axe-core. The industry-standard accessibility rules engine, maintained by Deque. Available as a browser extension (axe DevTools), a Jest integration (jest-axe), and a Playwright/Cypress plugin. Integrate jest-axe into your component test suite to catch regressions at the unit level. Run axe in CI on critical user journeys (login, sign-up, checkout, key dashboard views).
• Lighthouse. Google's open-source auditing tool (available in Chrome DevTools and as a CLI) includes an accessibility audit scoring accessibility issues on a 0–100 scale. Useful as a quick health check and for tracking regression over time. Does not replace axe-core but has broader adoption and integrates easily into most CI pipelines.
• NVDA (Windows) / VoiceOver (macOS/iOS). Free screen readers that represent the most common assistive technology used by people with visual impairments. Test the primary user journeys with a screen reader to catch ARIA failures, missing announcements, and logical reading order issues that automated tools miss entirely.
• Keyboard-only testing. Assign each new feature a keyboard-only QA pass before sign-off. This is the simplest form of accessibility testing and the most reliable way to catch focus management failures.
• Colour contrast checkers. The Colour Contrast Analyser (by TPGi) and the browser-native contrast checker in Chrome DevTools let you verify contrast ratios against the WCAG thresholds (4.5:1 for normal text, 3:1 for large text and UI components) in design and in production.
• Pa11y / Deque WorldSpace Attest. For organisations running accessibility monitoring across many pages or at scale, Pa11y (open source) and commercial tools like WorldSpace Attest provide crawl-based scanning, issue tracking, and remediation workflow integration.

Remediation roadmap for existing apps

Say your application is already live and you're starting an accessibility programme from zero. The approach below fits normal Agile delivery cadences and spares you a "big bang" rewrite:

Phase 1: Audit and prioritise (2–4 weeks)

• Run axe-core and Lighthouse across all key templates and user journeys. Capture every issue in a centralised tracker (Jira, Linear, or a spreadsheet) with WCAG criterion, severity (blocker/major/minor), affected component, and reproduction steps.
• Conduct a keyboard-only walk-through of all primary user flows. Note every focus trap, invisible focus indicator, and keyboard-inaccessible component.
• Run a screen reader pass on the five highest-traffic pages or flows.
• Prioritise: Level A failures first (legal floor), then Level AA failures that appear on high-traffic paths, then everything else.

Phase 2: Foundational fixes (3–6 weeks)

• Establish a design-token system for contrast-safe colour values. Update your design system to encode the WCAG-required contrast ratios, so all future components inherit compliance by default.
• Fix globally failing patterns first: add skip-nav link, remove global outline:none and replace with :focus-visible styling, add document lang attribute, add alt attributes to all images.
• Fix form patterns: add visible <label> elements, wire aria-describedby for error messages, add aria-invalid states, remove placeholder-only identification.
• Replace custom interactive components with ARIA-conformant implementations (or switch to an accessible component library where ROI favours it).

Phase 3: Dynamic content and advanced patterns (ongoing)

• Audit all modals and dialogs for correct focus management. Implement the ARIA APG Dialog pattern across the codebase.
• Add aria-live regions for all dynamic state changes (loading, success, error notifications).
• Review all data tables for correct <th> scope and summary annotations.
• Conduct quarterly re-audits using the same tool stack as Phase 1 to catch regressions introduced by feature development.

Estimated effort: for a typical SaaS application carrying moderate accessibility debt, budget 6–12 weeks for a senior accessibility engineer — or a front-end engineer who specialises in it — to finish Phases 1 and 2. Phase 3 is ongoing maintenance, and most teams absorb it within normal sprint capacity, around 5–10% of front-end velocity.

With modern architectures, accessibility reaches into server-side rendering and hydration. The initial HTML has to ship the correct semantic structure before client-side JavaScript enhances it — screen readers often parse the DOM before scripts finish running. AI-assisted development workflows deserve extra scrutiny here: LLM-generated component code drops ARIA attributes and keyboard handlers all the time, which makes a post-generation accessibility review non-negotiable.

FAQ

What is WCAG 2.2 and how does it differ from WCAG 2.1?

WCAG 2.2 is the current W3C standard for web accessibility, published October 2023. It adds nine new success criteria to WCAG 2.1, focusing on cognitive accessibility, touch and pointer targets, and visible focus indicators. Key additions include 2.4.11 Focus Appearance (minimum visible focus ring), 2.5.7 Dragging Movements (alternatives for drag operations), and 2.5.8 Target Size Minimum (at least 24×24 CSS pixels). WCAG 2.1 Level AA remains the legal baseline in most jurisdictions, but the EU Accessibility Act and updated US DOJ guidance now reference WCAG 2.2.

Does the EU Accessibility Act apply to private companies?

Yes. The European Accessibility Act (EAA), Directive 2019/882, entered into force on 28 June 2025 for most product and service categories, including web and mobile applications offered to consumers in the EU market. It covers private sector companies of all sizes, with a microenterprise exemption for businesses with fewer than 10 employees and annual turnover below €2 million. US companies selling digital products in the EU must comply or risk market access restrictions and fines set by each EU member state.

What ADA exposure do web apps have in the United States?

Title III of the Americans with Disabilities Act (ADA) has been consistently interpreted by federal courts to cover websites and web apps as places of public accommodation. The US DOJ published a final rule in April 2024 codifying WCAG 2.1 Level AA as the ADA standard for state and local government websites. For private businesses, approximately 4,000 ADA web accessibility lawsuits are filed annually in the US. Courts have awarded settlements and legal fee awards ranging from $10,000 to over $100,000 per case.

What are the most commonly failed WCAG 2.2 criteria in web apps?

The WebAIM Million annual survey consistently finds the same six failures covering more than 95% of home pages: low colour contrast (81% of pages), missing alternative text on images (55%), empty form labels (48%), missing document language declaration (18%), absent link purpose descriptions (45%), and missing button accessible names (27%). Web apps additionally fail on: focus management after modal open/close, ARIA roles on custom interactive components, and keyboard traps in date pickers or rich-text editors.

Which testing tools are best for WCAG compliance?

No single tool catches all WCAG failures — automated scanning covers roughly 30–40% of issues. The recommended stack is: axe-core (browser extension or CI integration via jest-axe or Playwright) for automated scanning; Lighthouse in CI for quick scoring; NVDA or VoiceOver for screen reader testing; keyboard-only navigation testing by a real user; and Pa11y or Deque WorldSpace Attest for organisation-wide monitoring. Manual expert review remains essential for ARIA correctness, cognitive accessibility, and focus management in dynamic components.

How long does it take to remediate a non-compliant web app?

Remediation timeline depends on severity and breadth. A typical SaaS application with moderate accessibility debt takes 6–12 weeks for a senior accessibility engineer to bring from failing to WCAG 2.2 Level AA. This includes an initial audit (3–5 days), foundational remediation sprints (3–6 weeks), and a verification pass. Building accessibility in from the start during development costs 3–5x less than retrofitting — a pattern identical to security and GDPR compliance.

Last updated 15 June 2026. Legal information in this article reflects publicly available guidance and does not constitute legal advice. Consult qualified legal counsel for advice specific to your product and jurisdiction.