Accessibility lawsuits against SMB websites have grown every year since 2018. 2026 is no different — plaintiffs’ firms have automated tools that scan SMB sites for WCAG violations and serve demand letters in bulk. Most lawsuits settle for $5k-25k. The cost of getting compliant up front is dramatically less. Here’s what the regulatory landscape actually requires in 2026 and the build practices we ship on every FH client site.
The legal frameworks
- ADA (US): Title III applies to public accommodations. Court rulings have established that ‘public accommodations’ includes commercial websites, even though the ADA predates the web. WCAG 2.1 AA is the de facto compliance bar.
- Section 508 (US): federal agency websites; usually doesn’t affect SMBs unless they sell to government.
- European Accessibility Act (EU): in effect from June 2025, requires WCAG 2.1 AA for commercial websites serving EU customers.
- AODA (Ontario), UK Equality Act, Australian DDA: similar frameworks in other markets.
The lawsuit pattern
Most SMB lawsuits go like this: an automated scan flags violations, a plaintiff’s firm sends a demand letter, the SMB has 30 days to remediate or settle. Settlements average $5k-25k. Plaintiff’s firms operate at scale — one firm can send 100+ demand letters per quarter. The math favors them: tools are cheap, demand letters cost nothing to send, settlements pay legal fees with a margin.
The four biggest violation categories
- Missing or wrong alt text on images. Every meaningful image needs descriptive alt; decorative images need alt="".
- Insufficient color contrast. Text on background must hit 4.5:1 (WCAG AA) or 3:1 for large text. Most brand color palettes fail somewhere on the site.
- Forms without labels. Every input needs an associated label (visible or aria-label, but present).
- Keyboard-inaccessible interactive elements. Custom dropdowns, modals, and tabs that work with mouse but not Tab/Enter/Esc.
The FH compliant-build posture
- Semantic HTML by default. Use real button elements, not divs with onClick. Real form elements with labels. Real heading hierarchy.
- Color contrast tested. Every text/background combination passes WCAG AA. We use a contrast checker (or our own design system tokens) to verify at design time.
- Alt text on every image. The CMS / content layer enforces it — empty alt is allowed only when explicitly marked decorative.
- Keyboard testable on every interactive component. We run a Tab-through audit on every page before shipping.
- Focus styles visible. Default browser focus rings are fine; custom focus styles are tested.
- Skip-to-content link at the top of every page.
- Reduced-motion respected. Every animation falls back to instant on `prefers-reduced-motion`.
- ARIA only when needed. Real semantic HTML beats ARIA-decorated divs. ARIA is for things that don’t have a native equivalent.
Tools for ongoing compliance
- axe-core in dev: catches violations in development.
- Lighthouse accessibility audit in CI: blocks PRs with new violations.
- Manual keyboard-only and screen-reader testing pre-launch: catches what automated tools miss.
- Quarterly accessibility review: re-audits the site as content evolves.
Overlay widgets are not a solution
Accessibility overlay widgets (AccessiBe, UserWay, etc.) are sold as one-line accessibility fixes. They’re mostly theater. Plaintiff’s firms specifically target sites using overlays, and courts have increasingly ruled that overlays don’t constitute compliance. Some overlays actively break the underlying site’s accessibility. We don’t install them on any FH client site.
What the lawsuits target most
Public service-business sites and ecommerce sites — anything where a member of the public might interact. B2B-only sites with no public-facing pages are at lower risk (no general public to be excluded). Personal portfolios are at lowest risk (not a public accommodation in most interpretations). Most FH clients are public service-businesses; we treat them as full-risk and build accordingly.
The accessibility statement page
Every accessible site has an /accessibility page documenting the standard followed (WCAG 2.1 AA), known limitations, and a contact method for users who hit accessibility issues. The page is part of compliance but more importantly a real channel — users with disabilities reach out via that channel and you get to fix issues directly instead of through legal.
When the lawsuit hits
Two options: (1) settle and remediate; (2) defend. Settling is usually cheaper but doesn’t solve the underlying problem (you’re vulnerable to the next plaintiff). Defending requires a real accessibility audit and a remediation plan with timelines. We help clients with the second when it’s feasible; we recommend settling fast and remediating fast when it isn’t.
ARIA: the right amount
Too much ARIA is worse than too little. `role="button"` on a `<button>` is redundant and can break screen readers. `aria-label` on a button with visible text overrides the visible text in announcement. ARIA is a precision tool for cases where semantic HTML can’t express what you need — not a decorator for every element.
Mobile accessibility specifically
Touch targets must be 44×44 px minimum (Apple HIG, WCAG AAA). Most SMB sites have tap targets too small on mobile, especially in navigation menus. We audit and fix. Mobile screen-reader testing (VoiceOver on iOS) catches issues desktop testing misses.
How this lands across FH client work
Every FH client site ships with WCAG 2.1 AA compliance and a documented accessibility statement. Lighthouse scores 95+ across the board. Zero accessibility lawsuits against any FH client in the last three years. If your site’s accessibility hasn’t been audited recently, book a consultation — the audit is a one-day engagement and the remediation is usually a one-week sprint.
