Federal web accessibility lawsuits under Title III of the ADA reached 3,117 in 2025, a 27% increase from 2024. Many organizations targeted made preventable mistakes. You're not getting sued because accessibility is complicated. You're getting sued because your compliance approach treats it like a project with an end date instead of an ongoing responsibility.
Why These Mistakes Keep Happening
Risk managers often inherit accessibility programs based on outdated assumptions: one audit fixes everything, automated tools catch all issues, and developers will "just handle it." Meanwhile, plaintiff firms track prior settlements and file again when the same barriers reappear. Over 300 businesses in Missouri and Minnesota were targeted in 2025 alone, many repeat defendants who settled once but never changed their process.
The gap isn't technical knowledge. It's governance. Organizations that document ongoing conformance work face significantly less legal risk than those treating accessibility as a one-time remediation sprint.
Mistake 1: Treating WCAG 2.1 AA as the Ceiling
Why it happens: Courts reference WCAG 2.1 Level AA as the compliance benchmark in ADA Title III cases, so legal teams stop there. Your outside counsel confirms you've met the standard cited in most settlements, and the program stalls.
The consequence: WCAG 2.2 introduced nine additional success criteria, including Accessible Authentication and Focus Not Obscured, that address real barriers for users with cognitive and visual disabilities. When the DOJ Final Rule (2024) or a future court ruling adopts WCAG 2.2 as the reference standard, you'll be playing catch-up while competitors who adopted it early demonstrate proactive compliance.
The fix: Conform to WCAG 2.1 AA now, but plan your roadmap to WCAG 2.2. Identify which of the nine new criteria affect your highest-traffic user flows, prioritize those, and document the timeline. Courts and plaintiff attorneys notice when your accessibility statement commits to current practices, not just the minimum cited in prior case law.
Mistake 2: Relying on Automated Tools Alone
Why it happens: Automated conformance testing tools are fast, scalable, and generate reports your auditors recognize. It's tempting to treat a clean axe-core scan as proof of compliance, especially when you're managing dozens of properties.
The consequence: Automated tools detect roughly 30-40% of WCAG violations. They can't evaluate whether your image alt text is meaningful, whether your heading structure makes sense to a screen reader user, or whether your custom dropdown works with keyboard navigation. Plaintiff firms know this. They hire testers who use actual assistive technology, find the issues your scanner missed, and file.
The fix: Integrate manual testing by accessibility specialists and user testing with native assistive technology users into every release cycle. Automated tools belong in your CI/CD pipeline to catch regressions, but manual review must validate the experience. If you're auditing annually, you're already six months behind on issues introduced since the last check.
Mistake 3: Skipping Role-Specific Training
Why it happens: You assume developers who know HTML and CSS can build accessible components without training. Accessibility gets framed as a specialist concern, not a core competency for every role that touches the user experience.
The consequence: Your developers don't know when to use aria-label versus aria-labelledby. Your designers spec color combinations that fail WCAG 1.4.3 Contrast (Minimum). Your content authors embed unlabeled form fields. Every sprint introduces new violations because the people building features don't recognize the patterns that create barriers.
The fix: Provide role-specific accessibility training for developers, designers, and content authors. Developers need to understand semantic HTML and ARIA. Designers need contrast checkers and focus indicator requirements. Content authors need alt text and heading hierarchy rules. Make training part of onboarding, not a one-time lunch-and-learn. Courts cite accessibility training programs in settlement agreements as evidence of institutional commitment.
Mistake 4: Treating Remediation as a One-Time Project
Why it happens: You get a demand letter, hire a firm to audit your site, fix the issues they flag, and close the ticket. Legal risk mitigated, budget spent, everyone moves on.
The consequence: You become a repeat defendant. New features ship without accessibility checks. Third-party integrations introduce inaccessible widgets. Content updates break keyboard navigation. Plaintiff firms actively track prior ADA compliance failures, and businesses that settle without changing their process are easy to find again. Consider a team that remediates their checkout flow in response to a settlement but doesn't update their development standards. Six months later, a redesign reintroduces the same keyboard traps, and the same firm files again.
The fix: Build accessibility into your development lifecycle. Require conformance testing before code review. Add accessibility acceptance criteria to your definition of done. Implement ongoing monitoring that flags regressions between audits. Document this process in your accessibility statement so you can demonstrate to a court that you treat compliance as an operational discipline, not a one-time response to legal pressure.
Mistake 5: Publishing a Vague Accessibility Statement
Why it happens: You know accessibility statements are cited in court rulings, so you add a generic page that says you're "committed to accessibility" without specifying the standard you follow, how users can report issues, or when you'll respond.
The consequence: A vague statement signals to plaintiff attorneys that accessibility isn't governed Assistive Technology your organization. Courts have cited accessibility statements in early-stage rulings, and a statement that commits to WCAG 2.1 AA, provides a contact method, and promises a response timeline demonstrates you're treating compliance seriously. A generic placeholder does the opposite.
The fix: Your accessibility statement must specify the standard you conform to (WCAG 2.1 AA, with a roadmap to WCAG 2.2 if applicable), provide a clear channel for users to report barriers, commit to a response time, and acknowledge known issues you're actively remediating. Update it when your conformance level changes. This isn't a legal disclaimer. It's evidence of governance.
Prevention Checklist
- Conform to WCAG 2.1 AA as the baseline; plan your WCAG 2.2 roadmap
- Integrate manual testing and assistive technology user testing into every release
- Provide role-specific accessibility training for developers, designers, and content authors
- Embed accessibility checks into your development lifecycle, not just post-launch audits
- Implement ongoing monitoring to catch regressions between formal reviews
- Publish an accessibility statement that specifies your standard, contact method, and response timeline
- Document your conformance work so you can demonstrate institutional commitment if a demand letter arrives
- Review third-party integrations and vendor accessibility conformance before deployment
The organizations that avoid repeat litigation don't just fix issues. They change the process that created them. ADA Title III
