Accessibility that holds up — to users, to standards, to lawyers.

You don’t, with certainty. ADA in the US doesn’t yet define a specific technical standard, but courts have consistently treated WCAG 2.1 AA (and increasingly 2.2 AA) as the practical standard for whether a digital experience is accessible. The honest answer is that accessibility is a continuum, not a binary, and what compliance means is “meeting recognized standards plus having a defensible practice if a complaint arises.” An accessibility audit gives you a current-state baseline; ongoing remediation work keeps you on the right side as your site changes.

No, and assuming they do is the most common mistake. Automated scanners (axe, WAVE, Lighthouse) catch roughly 30-40% of WCAG issues: missing alt text, contrast violations, missing form labels, ARIA misuse. They miss the rest because they can’t evaluate context: whether alt text actually describes the image, whether a button’s label makes sense to a screen reader, whether keyboard navigation flow is logical, whether content reads in the right order with assistive tech. The combination is automated scanning + manual testing + screen-reader testing, not one in place of the others.

Real, and growing. ADA web-accessibility lawsuits in US federal court have grown every year since 2017. The plaintiffs are usually serial litigators who file dozens or hundreds of cases per year, hitting any site that’s both inaccessible and large enough to make settlement economically attractive. The pattern is straightforward: they identify accessibility violations, file the complaint, and settle for low-to-mid five figures plus a remediation commitment.

WCAG (Web Content Accessibility Guidelines) is the international standard for digital accessibility, published by the W3C. Version 2.2 is the current published version; AA is the conformance level used as the practical benchmark for legal defensibility in most jurisdictions. AAA is the more stringent level (suitable for sites where accessibility is a primary mission, like government or healthcare), but isn’t usually required. AA is what we build to by default and what we understand most courts to consider the standard for “reasonable accessibility.”

It depends on how much the site changes. For a static site where content rarely updates and plugins don’t change, a single thorough remediation engagement can hold up for a long stretch. For sites with active content publishing, regular plugin updates, or ongoing development, accessibility state drifts as the site evolves, and the maintainable pattern is recurring remediation cycles that audit recent changes, fix what’s broken, and update the audit trail. Standards themselves also evolve (WCAG 2.2 moved past 2.1, and 3.0 is in draft), so even static sites may need periodic re-audits as the benchmark shifts.

The current-state issues, yes, that’s a standard remediation engagement. But “fixed” is a snapshot in time. As soon as the engagement ends and your team starts publishing new content, the accessibility state of the site starts changing again. The valuable engagement model is: remediation upfront to clear the backlog, then ongoing work to keep the state from drifting back. One-time engagements are useful but they’re rarely a permanent solution.

It’s testing your site using the actual screen-reader software (VoiceOver on macOS/iOS, NVDA or JAWS on Windows, TalkBack on Android) the way a visually impaired visitor would. It catches issues automated scans miss entirely: confusing navigation order, content that announces wrong, interactive elements that don’t communicate their state, dynamic content that updates silently. Manual screen-reader testing is the difference between technically passing automated checks and being actually usable for people with visual impairments. We do it on every accessibility engagement.