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

Why accessibility compliance is urgent in 2026

Accessibility has shifted from a UX nice-to-have to a hard legal requirement across two of the world's largest technology markets. In June 2025, the EU Accessibility Act (EAA) entered into force, requiring private sector web and mobile applications offered to EU consumers to meet EN 301 549 — the European standard that references WCAG 2.2 Level AA. In the United States, the Department of Justice finalised rules in April 2024 codifying WCAG 2.1 Level AA as the ADA standard for state and local government sites, and federal courts continue to extend ADA Title III liability to commercial web platforms.

The timing is not coincidental. Regulators on both continents have been watching the WebAIM Million report document the same structural failures year after year — over 95% of top-ranked websites have at least one automatically detectable WCAG failure. The EAA and strengthened ADA enforcement are the legislative response to that inaction.

From a business perspective, the risk is not just regulatory. An inaccessible web app excludes approximately 1.3 billion people with disabilities globally — a market segment with an estimated $13 trillion in disposable income. Accessibility is also a search ranking signal: Google's Core Web Vitals and crawlability both benefit from the same semantic, keyboard-navigable markup that WCAG requires. Teams working on custom web application development and web development services increasingly build accessibility in from sprint one, because retrofitting it costs three to five times more.

WCAG 2.2 and the POUR principles

The Web Content Accessibility Guidelines (WCAG) are organised around four high-level principles, abbreviated 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, finalised in October 2023, added nine new Level A and Level AA success criteria on top of WCAG 2.1. The most impactful additions for web applications are:

• 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 maps the most business-critical WCAG 2.2 criteria to their conformance level and the most common failure pattern found in web apps. This is not an exhaustive list but covers the issues that generate the highest legal and audit risk in 2026.

The EU Accessibility Act: what changes for web apps

The European Accessibility Act (Directive 2019/882) reached its application deadline for most product categories on 28 June 2025. For businesses operating in the EU market, this is no longer a future planning exercise — it is a present compliance obligation.

The EAA applies to services and products placed on the EU market from that date. Web and mobile applications that enable consumers to access services — e-commerce, banking, transport, education platforms — fall squarely within scope. The key technical standard is EN 301 549 v3.2.1, which incorporates WCAG 2.2 Level AA as its web content requirement. Member states may adopt more stringent national measures, but the EU floor is now WCAG 2.2 AA.

Who is exempt? The EAA includes a microenterprise exemption for service providers with fewer than 10 employees and an annual turnover or balance sheet total not exceeding €2 million. This exemption does not apply to product manufacturers — only service providers. A US startup with three developers selling a SaaS product to EU enterprise clients would likely qualify as a microenterprise, but the moment it scales, the exemption evaporates. Planning accessibility from the outset is always cheaper than retrofitting under deadline pressure from a national enforcement authority.

Enforcement varies by member state. Some (Germany, France, the Netherlands) have mature digital accessibility oversight bodies with inspection power. Others are still building enforcement capacity. The safest assumption is that enforcement will intensify as member state agencies complete their setup phase, which the European Commission is actively monitoring. Non-conforming products risk being withdrawn from the EU market or fined under national implementing legislation — fines of up to €100,000 have been set in some member state laws.

For US companies selling SaaS to EU B2B clients, the EAA requirement often flows through procurement: enterprise clients' legal and procurement teams increasingly insert EN 301 549 VPAT (Voluntary Product Accessibility Template) requirements into vendor contracts. Failing to provide a current VPAT can disqualify a vendor during RFP evaluation.

US ADA exposure for web and SaaS products

The Americans with Disabilities Act Title III prohibits discrimination against people with disabilities in places of public accommodation. Federal courts have, with rare exceptions, held that websites and web applications are places of public accommodation covered by Title III — the Ninth and Eleventh Circuits being the most active circuits in this jurisprudence.

In April 2024, the US Department of Justice published a final rule under Title II of the ADA, setting WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile apps. Title II applies to government entities, not private companies — but the final rule signals DOJ's interpretation of the technical standard for the broader web, and it uses WCAG 2.1 AA as the floor. DOJ guidance and enforcement letters to private entities consistently reference WCAG 2.1 AA as the expected standard, with WCAG 2.2 now cited in newer guidance.

ADA web accessibility litigation has become a structured plaintiffs' bar practice. Approximately 4,000 lawsuits are filed annually in the US, primarily in the Southern District of New York and the Eleventh Circuit. Typical settlement amounts range from $10,000 to $50,000 for a first-time defendant, but attorney fee awards under the ADA fee-shifting provision can push total cost to $100,000–$150,000 per case. Serial plaintiffs (individuals or firms filing dozens of identical complaints against similar sites) target low-hanging-fruit failures: 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 reaching for ARIA, the most impactful accessibility investment is using semantic HTML correctly. Browsers expose the accessibility tree — the data structure that assistive technologies read — from the HTML semantic layer. Native elements carry built-in roles, names, and keyboard behaviours that custom elements require explicit ARIA to replicate.

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.

For teams building with React, Next.js, or other component frameworks, the semantic-HTML principle still applies at the rendered DOM level. Using as="nav" in Tailwind or styled-components, or ensuring that component libraries render semantic elements, is part of the framework-level accessibility hygiene that should be codified in your design system's contribution guidelines.

Keyboard navigation and focus management

Keyboard accessibility is one of the highest-impact accessibility requirements and one of the most commonly overlooked in web app development. The full keyboard-operability obligation under WCAG 2.1.1 means that every interactive element — tabs, accordions, data tables, modals, date pickers, tooltips, sliders, carousels, autocomplete fields — must be operable without a mouse.

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.

A useful technique for cross-team keyboard testing: test without looking at the screen. Tab through the entire application with your monitor off. If you cannot complete a primary task (log in, submit a form, navigate to a key section) solely via keyboard, you have a failure that affects real users daily.

ARIA and accessible forms

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes — roles, states, and properties — that supplement the accessibility information native HTML elements provide, specifically for dynamic content and custom interactive components. The first rule of ARIA is: do not use ARIA if you can use a native HTML element. A <button> is always preferable to a <div role="button">. ARIA is a corrective layer, not a replacement 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 testing tool or combination of tools catches 100% of accessibility issues. Automated scanning reliably catches approximately 30–40% of WCAG failures — the structural, measurable ones (missing alt text, contrast ratios, missing labels, empty buttons). The remaining 60–70% require human judgment: is this interaction pattern understandable to a first-time keyboard user? Does this modal sequence make sense to someone who cannot 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

If your application is already live and you are starting an accessibility programme from scratch, here is a structured remediation approach that works within normal Agile delivery cadences without requiring 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 with moderate accessibility debt, a senior accessibility engineer or front-end engineer with accessibility specialisation should budget 6–12 weeks to complete Phases 1 and 2. Phase 3 is ongoing maintenance, usually absorbed within normal sprint capacity (5–10% of front-end velocity).

For teams building with modern architectures, accessibility concerns extend to server-side rendering and hydration: ensuring that the initial HTML includes the correct semantic structure before client-side JavaScript enhances it is critical for screen readers that parse the DOM before scripts finish running. AI-assisted development workflows require particular attention here — LLM-generated component code frequently omits ARIA attributes and keyboard handlers, making post-generation accessibility review non-optional.

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.