ADA Lawsuits Are Up 37%. Is Your Website the Problem?

Over 2,000 ADA-related website lawsuits were filed in the first six months of 2025, a 37% jump over the same period in 2024. Law firms that specialize in this work have refined their process: automated scanners identify non-compliant sites, demand letters go out in bulk, and small businesses that assumed they were too small to matter end up settling for four- or five-figure amounts just to make the problem disappear. If your website has not been evaluated for accessibility, that assumption is worth revisiting now.

The legal standard most courts apply is WCAG 2.1 Level AA, a set of technical guidelines covering keyboard navigation, color contrast ratios, descriptive alt text, form label associations, heading structure, focus states, and interactive behavior. These are not cosmetic concerns. They determine whether assistive technologies like screen readers, voice control software, and switch access devices can actually navigate and understand your site. When those interactions fail, users with disabilities are excluded. That exclusion is what increasingly creates liability under Title III of the Americans with Disabilities Act, regardless of whether a business operates a physical storefront.

What changed is not the existence of accessibility standards, but the consequences of ignoring them.

Accessibility Went From “Nice to Have” to Immediate Priority

The technical side of accessibility has existed for years, but the business urgency around it has changed dramatically in a short period of time. Historically, many small businesses prioritized visual design, SEO, speed, integrations, or marketing functionality long before they asked questions about WCAG compliance. Accessibility reviews were often deferred, reduced in scope, or pushed into a future phase that never happened.

At Concepcion Design, that shift has become impossible to ignore. Clients who previously viewed accessibility as a secondary concern are now asking whether their sites are fully WCAG AA compliant before launch, during redesigns, and sometimes only after receiving legal notices themselves. The urgency changed almost overnight, but the technical work required to meet compliance standards did not suddenly become simpler.

That reality has forced a change in how we approach development. Accessibility can no longer be treated as a final checklist item layered onto a finished design. It has to be integrated into the entire lifecycle of a site or application: planning, design systems, component architecture, frontend development, QA testing, and ongoing iteration.

Every new build now starts with the assumption that accessibility is part of the specification itself, not an enhancement to consider later if budget allows. The practical reality is that retrofitting accessibility into an older codebase is substantially harder than building with accessibility in mind from the beginning. When semantic structure, keyboard interaction, focus management, and screen reader behavior are treated as foundational requirements, the resulting codebase is cleaner, more maintainable, and significantly easier to audit over time.

Why WordPress Themes Become a Compliance Liability

This is where the problem compounds for many small business websites. A WordPress theme ships with much of its HTML structure already predetermined. Accessibility attributes like aria-label, role, and aria-expanded are either implemented correctly or they are not, depending on what the original theme developer prioritized years ago. Page builders frequently generate layers of generic div containers with little semantic meaning, making remediation difficult and inconsistent.

Plugins marketed as accessibility fixes, particularly overlay tools that promise one-click WCAG compliance, have been heavily criticized by accessibility advocates and have even been named in lawsuits alongside the sites using them. Organizations like the National Federation of the Blind have published formal positions against overlay technology, arguing that overlays do not reliably fix the underlying code or user experience problems. Installing one does not guarantee compliance, and in some cases may suggest that a site owner recognized accessibility issues but opted for a superficial workaround instead of remediation.

Custom-built sites developed in frameworks like Astro or Next.js start from a different baseline entirely. Every HTML element, interactive component, landmark region, and heading level is intentional. Semantic structure, focus management, ARIA implementation, and keyboard behavior are defined during development rather than inherited from a third-party theme. When developers control the architecture directly, accessibility becomes part of the system design instead of a patch applied afterward.

That distinction matters when the alternative is inheriting years of technical debt alongside a prepackaged visual design.

What a Compliance Audit Actually Involves

A meaningful accessibility review requires both automated and manual testing. Tools like axe, WAVE, and Lighthouse can identify a substantial number of WCAG violations automatically, but they only catch part of the problem. Keyboard traps, improper focus order, inaccessible modal behavior, missing context on dynamic components, and unclear screen reader announcements often require manual testing to uncover.

If a site includes forms, dropdowns, accordions, modals, sliders, or JavaScript-powered interactions, those components need to be evaluated the way an assistive technology user would actually encounter them. That means keyboard-only navigation testing, screen reader validation, focus visibility checks, and behavioral testing across responsive layouts.

This is not a one-afternoon exercise, but it is substantially less expensive than responding to a demand letter after the fact.

If you are rebuilding or commissioning a new site, the best time to address accessibility is during construction, not after launch. A codebase built on semantic HTML, accessible interaction patterns, and deliberate component standards is easier to maintain, easier to audit, and easier to defend if compliance questions ever arise.

The sites most exposed right now are often the ones built years ago on visually appealing themes, managed through page builders that prioritize layout flexibility over semantic markup, and treated as static assets rather than actively maintained software.

Websites are no longer static marketing brochures. They are software products, and accessibility expectations are increasingly being enforced like software requirements.