WCAG 2.2 Compliance for Enterprise Platforms: Beyond the Automated Scanner

Accessibility overlays and automated scanner integrations sell an appealing promise: drop in a script tag, get WCAG-compliant, avoid ADA litigation. The evidence doesn't support the promise. Independent audits of automated accessibility tools consistently find they detect on the order of 30-40% of WCAG 2.2 success criteria violations, and overlay widgets in particular have drawn enough documented harm reports and even litigation of their own that we recommend against them outright for enterprise clients. Real compliance requires the parts a scanner structurally cannot evaluate: whether an interaction actually makes sense to someone using a screen reader, a switch device, or keyboard-only navigation.

What scanners catch, and why that's the easy third

Automated tools are genuinely good at detecting missing alt attributes, insufficient color contrast ratios, missing form labels, and invalid ARIA usage — anything expressible as a static property of the DOM. Wire axe-core into CI as a baseline gate; it's free signal and catches real regressions before they ship. But a scanner cannot tell you whether the alt text is accurate, whether a modal actually traps focus correctly when opened via keyboard, or whether a custom dropdown component announces its expanded/collapsed state to a screen reader in a way that's actually comprehensible — these require exercising the interaction, not inspecting the markup.

The failures that matter most are interaction failures

WCAG 2.2's new success criteria (2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size, among others) reflect where the standard has moved: away from static content correctness and toward interaction robustness. For enterprise applications — dashboards, data tables, multi-step forms, drag-and-drop interfaces — this is exactly where custom components tend to fail, because building a fully accessible custom <select>, date picker, or sortable data grid from scratch requires implementing keyboard interaction patterns (arrow-key navigation, Escape to close, Home/End to jump) and ARIA state management (aria-expanded, aria-activedescendant, live region announcements for dynamic updates) that a scanner will never flag as missing, because the markup can be syntactically valid ARIA and still communicate the wrong thing.

Our standard practice is to build data-heavy interactive components against the corresponding ARIA Authoring Practices Guide pattern rather than improvising, and to validate with actual assistive technology — NVDA and JAWS on Windows, VoiceOver on macOS/iOS — as a required step before a component ships to the shared design system, not as a post-launch remediation activity.

Keyboard-only testing surfaces problems visual review never will

Unplug the mouse and navigate the entire critical path — sign-up, checkout, the primary dashboard workflow — using only Tab, Shift+Tab, arrow keys, and Enter/Space. This single, low-cost exercise reliably surfaces the highest-severity failures: focus that visually disappears into an off-screen element, modals that don't trap focus and let a user tab behind them into the obscured page, custom controls that are entirely unreachable because they were built on a <div> with a click handler and no tabindex or keyboard event handling at all. We run this as a required manual gate before any new interactive component is approved for the design system, and it catches issues automated scanning misses on essentially every review.

Compliance is a floor; the legal exposure is real either way

WCAG 2.1 AA remains the most commonly cited legal standard in ADA Title III web accessibility litigation, and the volume of these suits filed against enterprises has stayed elevated year over year — this is genuine commercial risk, not a hypothetical. But treating WCAG solely as a legal-risk checklist misses the more durable argument: accessible interaction patterns (real focus management, adequate contrast, forgiving target sizes) measurably improve usability for every user, not just those using assistive technology. Build it as a core quality bar enforced in code review and design system governance, the same way you'd enforce performance budgets or security review — not as a compliance sprint you run once and hope holds.