Accessibility lawsuits against business websites have climbed for years, but the bigger reason to get WCAG 2.2 right is that a meaningful share of your visitors genuinely can't use a non-compliant site.
Roughly one in six people worldwide lives with some form of disability that can affect how they use a website — vision impairment, motor impairment, cognitive differences, hearing loss — and that number doesn't count the situational and temporary cases that hit everyone eventually: a broken arm making a mouse hard to use, a bright afternoon sun washing out a low-contrast screen, a noisy environment making a video's captions the only way to follow it. Web accessibility isn't a niche accommodation for a small population. It's the difference between a site that works under normal, imperfect, real-world conditions, and one that only works in the ideal conditions it happened to be tested under.
What WCAG actually is
The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the internationally recognized standard for web accessibility, and they're the standard referenced by most accessibility laws and regulations globally, including how courts and regulators typically interpret compliance with disability-rights legislation. WCAG 2.2 is the current version, published in 2023, adding several new success criteria on top of 2.1 while keeping everything from earlier versions intact — nothing from WCAG 2.1 was removed, only extended.
The guidelines are organized around four principles, often remembered by the acronym POUR:
- Perceivable — content must be presentable to users in ways they can perceive (text alternatives for images, captions for video, sufficient color contrast).
- Operable — interface components must be operable by any user (full keyboard navigation, no content that flashes in a way that could trigger seizures, enough time to read and act on content).
- Understandable — content and interface operation must be understandable (readable text, predictable navigation, clear error identification in forms).
- Robust — content must work reliably across current and future assistive technologies (valid, semantic markup that a screen reader can correctly interpret).
Each guideline within these principles has testable success criteria rated at three conformance levels — A (minimum), AA (the level virtually all regulations and reasonable business targets reference), and AAA (the highest, generally not expected site-wide even by regulators, since some AAA criteria are genuinely difficult to satisfy for certain types of content). WCAG 2.2 Level AA is the practical target for a business website — it's what's referenced in most accessibility legislation and what a reasonable legal or ethical standard actually asks for.
What's actually new in 2.2
For teams already working toward WCAG 2.1 AA, the criteria genuinely new in 2.2 worth knowing about include:
- Focus Not Obscured — a keyboard-focused element (a link or button a user has tabbed to) must not be completely hidden behind other content like a sticky header or cookie banner. This directly targets a common real bug: a sticky nav bar covering the exact element a keyboard user just tabbed to, leaving them unable to see what's selected.
- Dragging Movements — any functionality that requires a dragging motion (reordering a list, a custom slider) must also be operable with a single click or tap, not drag-only, since dragging is difficult or impossible for many users with motor impairments.
- Target Size (Minimum) — clickable targets (buttons, links, form controls) must generally be at least 24x24 CSS pixels, or have enough spacing from neighboring targets, so users with limited fine motor control can reliably tap the right one.
- Consistent Help — if a site offers a help mechanism (contact info, chat, FAQ link), it must appear in the same relative place across pages, rather than moving around and forcing users to relocate it each time.
- Accessible Authentication — login and sign-up processes can't rely solely on a cognitive test a user must solve from memory (like transcribing a CAPTCHA-style puzzle with no alternative), since this disproportionately blocks users with cognitive disabilities.
The most common real failures on business websites
Across most business websites, the same handful of issues account for the overwhelming majority of accessibility failures, and none of them require an accessibility specialist to fix — they require awareness and a bit of discipline during normal development:
Missing or meaningless alt text. Every meaningful image needs a text alternative describing its content or purpose; purely decorative images (background textures, spacers) should have an empty alt="" so screen readers correctly skip them rather than reading a distracting filename aloud. The common failure isn't total absence — it's alt text that's present but useless, like alt="image123.jpg" or alt="photo".
Insufficient color contrast. WCAG AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text against its background. Light gray text on a white background — a design choice that shows up constantly in the name of a "clean, minimal" aesthetic — routinely fails this and is one of the single most common violations found in automated audits, precisely because it looks fine to someone with typical vision testing on a calibrated monitor in good lighting.
Keyboard traps and missing focus indicators. Every interactive element on a page must be reachable and operable using only a keyboard — no mouse at all — with a clearly visible focus indicator showing which element currently has keyboard focus. A shockingly common failure is a custom dropdown, modal, or date picker built without keyboard support at all, making it completely inaccessible to anyone who can't use a mouse, and a nearly as common failure is a focus outline removed with outline: none in CSS for aesthetic reasons, with nothing put in its place — leaving keyboard users with no visual indication of where they are on the page at all.
Form fields without properly associated labels. A form input needs a <label> element correctly associated with it (via a for/id pair, or by wrapping the input) so a screen reader announces what the field is for. Placeholder text alone, disappearing the moment a user starts typing, is not a substitute for a label — it fails both sighted users trying to recall what a field was for, and screen reader users who may never hear it at all depending on how the form was built.
Non-semantic markup. A <div> styled to look like a button but built without proper semantics is invisible to a screen reader as an interactive element and unreachable by keyboard Tab navigation entirely unless developers manually reimplement all of a real <button> element's built-in behavior. Using the correct native HTML element for its purpose — <button> for actions, <a> for navigation, real heading tags in genuine hierarchical order — solves most of this automatically, which is also exactly the discipline progressive enhancement encourages (see our companion piece on progressive enhancement) — the two practices reinforce each other for reasons that aren't a coincidence.
What automated tools catch, and what they don't
Automated accessibility scanners (axe, Lighthouse, WAVE) are genuinely useful and worth running in CI on every deploy, but they typically catch somewhere around a third of real WCAG violations — the ones that are structurally detectable, like missing alt attributes, insufficient contrast ratios, and missing form labels. What they cannot catch: whether alt text actually describes the image meaningfully rather than just being present, whether a keyboard navigation path is logical and usable rather than technically functional, whether an error message is actually understandable, or whether a complex interactive widget behaves sensibly for a screen reader user navigating it in practice. Genuine compliance requires automated scanning as a first pass plus manual testing — actually navigating key flows with a keyboard only, and ideally with a screen reader (NVDA and VoiceOver are both free) — to catch what tooling structurally cannot.
Cognitive accessibility deserves more attention than it usually gets
Discussions of web accessibility skew heavily toward the visible and easily-tested criteria — contrast, alt text, keyboard access — while cognitive accessibility gets comparatively little attention despite affecting a wide range of users, including people with ADHD, dyslexia, memory-related conditions, and simply anyone reading a page while distracted or under time pressure, which describes a large share of all real usage. WCAG's guidance here is less about a specific measurable ratio and more about consistent, testable practices: clear, jargon-free language and plain error messages that state what went wrong and how to fix it rather than a generic "invalid input"; predictable navigation that doesn't rearrange itself between pages; avoiding time limits on forms or sessions without a way to extend them, since a strict timeout that silently discards a half-completed form is a genuine barrier for anyone who reads or types more slowly than the timeout assumed; and breaking long or complex processes (a multi-step checkout, a detailed application form) into clearly labeled steps with visible progress, rather than one overwhelming page. None of this requires specialized tooling to implement — it requires treating clarity as a design requirement rather than an afterthought polished in at the end.
Mobile accessibility is not automatically covered by a responsive layout
A site that's responsive — reflowing correctly across screen sizes — is not automatically accessible on mobile, and the gap between the two catches teams who've treated "mobile-friendly" and "mobile-accessible" as the same checkbox. Touch targets need to meet the same minimum size guidance WCAG 2.2 introduced for pointer targets generally, which matters more on mobile precisely because fingers are far less precise than a mouse cursor. Content that relies on hover states — a tooltip, a dropdown menu revealed on mouse-over — has no direct equivalent on a touchscreen at all, so anything conveyed only through hover needs a tap-accessible alternative or it's simply unavailable to touch users regardless of visual design quality. And mobile screen readers (VoiceOver on iOS, TalkBack on Android) have their own navigation conventions distinct from desktop screen readers, which is part of why manual testing on an actual mobile device, not just a resized desktop browser window, belongs in a genuine accessibility testing process rather than being assumed to follow automatically from desktop testing.
Where the legal exposure actually comes from
Website accessibility lawsuits and demand letters, particularly under disability-rights legislation like the ADA in the US, have been a steadily growing category for over a decade, and they disproportionately target exactly the failures listed above rather than obscure edge cases — missing alt text, keyboard traps, and low-contrast text are the most commonly cited issues in actual legal claims, precisely because they're also the easiest for a plaintiff's accessibility auditor to demonstrate. This is a real and growing business risk independent of the ethical case for accessibility, and it's worth stating plainly: no reputable agency should claim to make a site "fully ADA certified" or "100% compliant," because there's no official government certification body for this in most jurisdictions, and no automated tool can guarantee zero violations across an evolving site. What a genuinely reasonable engineering process can do is target WCAG 2.2 AA deliberately, test against it with both automated and manual methods, and treat it as an ongoing practice rather than a one-time checkbox — the same way security or performance are ongoing practices rather than launch-day tasks.
Building it in rather than bolting it on
Retrofitting accessibility onto a site built without it in mind is considerably more expensive than building it in from the start, because so many of the fixes touch fundamental structural decisions — markup semantics, component architecture, color system — rather than surface-level tweaks. Treating WCAG 2.2 AA as a baseline requirement from the first component built, rather than an audit performed after launch, is both the more thorough approach and, in almost every case, the cheaper one over a project's lifetime.
