Accessibility Compliance Governance

Accessibility gets treated as a checkbox until the demand letter arrives, and by then the fix is reactive, expensive, and usually still wrong. UsableNet's year-end tracking put full-year 2025 digital accessibility lawsuits above 5,000, a roughly 20% increase over 2024, and its mid-2026 trend data projects continued growth into 2026. Ecommerce is not an incidental target — it accounts for the large majority of these suits, and repeat litigation against previously-sued companies is common. This is a governance problem, not a design-polish problem, and it has to be engineered the same way any other production requirement is: as code, tested continuously, owned by an accountable team.

The Legal Baseline: WCAG 2.1 AA, With 2.2 AA as the Working Standard

ADA Title III complaints most commonly cite WCAG 2.1 AA as the benchmark, and the EU's harmonized standard for the European Accessibility Act (EN 301 549) also points to WCAG 2.1 AA. We build to WCAG 2.2 AA as the internal engineering standard because it is a strict superset — full 2.2 AA conformance satisfies the 2.1 AA legal baseline used in litigation and in EAA enforcement, while covering newer criteria that plaintiffs' firms are starting to cite. Six additions in 2.2 matter specifically for commerce UX:

• Target Size (Minimum) — pointer targets need at least 24×24 CSS pixels of tappable area, or sufficient spacing. This hits filter chips, quantity steppers, and mobile nav icons directly.
• Dragging Movements — any drag-based interaction (image carousels, range sliders, map panning) needs a non-drag alternative like tap-to-advance buttons.
• Focus Not Obscured (Minimum) — a keyboard-focused element can't be hidden behind a sticky header, cookie banner, or promo bar.
• Consistent Help — if you offer chat, phone, or an FAQ link, it needs to live in the same place across every step of checkout.
• Redundant Entry — a returning customer shouldn't have to retype shipping info already captured at account creation or an earlier checkout step.
• Accessible Authentication (Minimum) — login can't rely purely on solving a cognitive puzzle; password managers, paste, passkeys, or magic links must work.

Underneath the new criteria, the WCAG 2.x fundamentals still carry the most litigation weight: 4.5:1 text contrast, full keyboard operability, visible focus indicators, labeled form fields, and layouts that reflow at 320px width without loss of content or horizontal scrolling.

Why Overlays Don't Work — And Why We Don't Sell Them

Widget-based "quick fix" overlays sit on top of a page and try to patch accessibility issues at runtime via injected JavaScript, without touching the underlying markup. The litigation data is unambiguous about the outcome: UsableNet's monthly tracking shows overlay-running sites getting sued in steady volume throughout 2025, and accessiBe itself is defending a class action (filed by Tribeca Skin Care in the Southern District of New York) alleging its accessWidget product is ineffective and can actively conflict with screen readers and other assistive technology. Complaints increasingly cite the presence of an overlay as evidence the defendant was aware of accessibility problems and chose a cosmetic fix over remediation — which is a worse legal position than doing nothing.

Real remediation happens in the codebase: semantic HTML elements instead of <div> soup, correct ARIA roles and states only where native HTML can't express the interaction, managed focus on route changes and modal open/close, and keyboard event handlers that mirror what a mouse user can do. None of that is achievable by a script injected after the page loads.

The Governance Framework We Build

• CI-gated automated scanning. axe-core (the engine behind axe DevTools) runs in the pipeline on every pull request touching templates, catalog pages, or checkout. A build that introduces a new critical or serious violation doesn't merge — this is the same bar as a failing unit test.
• Manual audits on the flows automation can't validate. Automated tools catch roughly half of WCAG violations; Deque cites axe-core coverage around 57%. The rest — tab order logic, whether a screen reader announcement actually makes sense in context, whether a custom-built product filter is operable without a mouse — needs a human tester on NVDA (Windows) and VoiceOver (macOS/iOS), walking the real purchase path: search, PDP, cart, checkout, account.
• Semantic integrity baked into the component library. Accessible components (accordions, modals, comboboxes, carousels) get built once, correctly, and reused — not re-litigated per page.
• A published accessibility statement. Required under the EAA for EU-facing sites, and good practice regardless: what standard you conform to, known gaps, and a remediation timeline. It also signals to a plaintiff's firm that this is an actively managed program, not a static site nobody's touched since launch.

What Changed on June 28, 2025

The European Accessibility Act (Directive (EU) 2019/882) became enforceable for consumer-facing digital products and services placed on the EU market, and it explicitly names ecommerce. If a brand sells product or services to EU consumers — not just brands headquartered in the EU — the storefront needs to meet EN 301 549, which incorporates WCAG 2.1 AA, and publish an accessibility statement. Enforcement and penalty structure are set at the member-state level, so the exact consequence of non-compliance varies by which EU country the transaction touches, but the technical bar (WCAG 2.1 AA) is consistent across the bloc. A narrow exemption exists for micro-enterprises under 10 employees and €2M turnover providing services — most ecommerce operations of any real scale don't qualify.

Testing Tools We Actually Use

Litigation Reality Check

UsableNet's 2025 year-end figures put digital accessibility lawsuits above 5,000 for the year, with ecommerce representing the substantial majority of targets and roughly a third of the top 500 US ecommerce retailers receiving at least one suit. Repeat litigation against previously-sued defendants is common — being sued once and settling without fixing the underlying code is not a resolution, it's an invitation. This is not legal advice, and any specific litigation exposure should be reviewed with counsel — but from an engineering standpoint, the fix is the same regardless of jurisdiction: real code-level remediation, tested continuously, on the flows that actually generate revenue.

Accessibility governance done right expands addressable market, reduces legal exposure across two overlapping regulatory regimes, and — because semantic, keyboard-operable, well-labeled interfaces tend to be faster and clearer for every user, not just assistive-technology users — it usually improves conversion on the way to reducing risk.