A client calls on a Monday morning. Their end-customer just received an ADA demand letter, and they want to know why the website you built isn’t compliant. You’ve never tested it for accessibility. You don’t have a good answer.
Most web agencies don’t handle ADA compliance at all. The majority either ignore accessibility entirely and exclude it from contracts, outsource to a specialist firm when a client asks, or scramble reactively after a demand letter arrives. Only a small percentage of agencies have embedded WCAG checks into their development workflow or CI/CD pipeline.
TL;DR: Most agencies fall into three camps: ignore accessibility, outsource it when forced, or scramble after a legal scare. The top trigger for accessibility work is a client demand letter, not proactive planning. Automated tools only catch 30-40% of WCAG issues. The fix starts with assigning a clear owner and monitoring continuously.
What Are the Three Approaches Agencies Take to Accessibility?
Kris Rivenburgh of Accessible.org describes three agency archetypes. The first group ignores accessibility entirely. They write it out of contracts and hope nobody asks. The second outsources to a specialist firm when a client brings it up. The third has started integrating accessibility into their process, usually after a legal scare or losing a deal to a competitor who offered it.
The first group is the majority, especially among small agencies with fewer than 15 people. That’s a serious problem when 94.8% of the top one million websites fail basic WCAG conformance (WebAIM Million 2025). The odds that any given client site has violations aren’t just high. They’re near-certain. Most agencies are sitting on compliance gaps they’ve never measured, across every single client in their portfolio.
Who Actually Does Accessibility Work Inside an Agency?
When agencies do address accessibility, the work gets distributed without clear ownership. Here’s what the landscape looks like in practice:
| Role | What They Do | How Common |
|---|---|---|
| Front-end developers | Run browser extensions (axe DevTools, WAVE) to catch missing alt text and label issues | Common in agencies that care at all |
| QA testers | Run Lighthouse or axe scans pre-launch; rarely trained in screen-reader testing | Moderate, usually superficial |
| Dedicated specialist | IAAP-certified staff who review designs, write ARIA patterns, conduct manual audits | Rare; mostly agencies with 50+ staff |
| Outsourced firm | Third-party auditors (Equalize Digital, Level Access) provide audits the agency white-labels | Growing |
| Overlay vendor | Agency installs accessiBe or UserWay and considers the site “compliant” | Still common despite legal action |
| Nobody | Accessibility is not addressed; contract excludes compliance responsibility | The silent majority |
The core process gap: accessibility is almost never assigned to a single owner. It falls between design, development, and QA with no accountability.
What Triggers an Agency to Start Caring About Accessibility?
The number-one trigger is reactive, not proactive. A client receives a demand letter or gets served with an ADA lawsuit. They panic. They call the agency and ask, “Is our site compliant?” For the first time, someone at the agency has to answer that question honestly. Nobody wants to be in that meeting.
ADA website lawsuits surged 37% year-over-year in the first half of 2025, with 2,014 federal cases filed between January and June alone (EcomBack Mid-Year 2025). Over 5,000 ADA web lawsuits were filed for the full year. And those are just the filed cases. Demand letters, which get resolved privately without a court filing, outnumber lawsuits by an estimated 7-to-10x. The actual volume of legal pressure on businesses is significantly higher than the headline lawsuit numbers suggest.
What Other Events Push Agencies Toward Accessibility?
Beyond the demand letter scramble, a few other triggers come up regularly. Clients occasionally ask proactively, usually after reading about ADA lawsuits or seeing a competitor get sued. Government RFPs require Section 508 compliance, and the new ADA Title II rule mandates WCAG 2.1 AA for state and local government entities with populations over 50,000 by April 24, 2026 (ADA.gov). Some agencies add accessibility as a service line after losing a deal where a competitor offered it. New project kickoffs for healthcare, education, or government clients sometimes include accessibility in the initial scope. Major site redesigns also create a natural entry point. But the overall pattern is clear: most agencies only act after the threat materializes, not before it arrives.
What Tools Are Agencies Currently Using for Accessibility?
The tool landscape for agencies breaks into a few categories, each with real limitations. Here’s what most agencies reach for and what each actually covers:
| Tool | Type | Automated Coverage | Agency Use Case |
|---|---|---|---|
| axe DevTools (Deque) | Browser extension + CI | ~30-40% of WCAG issues | Most popular among devs; 3B+ npm downloads |
| WAVE (WebAIM) | Browser extension + API | Similar to axe | Preferred by QA; visual overlay shows errors |
| Google Lighthouse | Built into Chrome | Subset of axe-core rules | Already used for performance; a11y score often ignored |
| Pa11y | CLI / CI tool | Automated WCAG checks | Used by technical agencies for pipeline integration |
| Siteimprove | Enterprise SaaS | Automated + content quality | $500+/mo; overkill for most small agencies |
| accessiBe / UserWay | Overlay widgets | Claims full; delivers partial | Controversial; courts reject as compliance |
How Much Do Automated Tools Actually Catch?
The critical number: automated tools catch only 30-40% of WCAG issues by volume (Deque Automated Coverage Report). axe-core itself covers roughly 32% of WCAG 2.1 A+AA success criteria. The remaining 60-70% of real accessibility barriers require manual testing with assistive technology like screen readers, and almost no agency does this work in-house. Running Lighthouse and seeing a score of 90+ makes teams think the site is accessible. In reality, that score reflects a narrow subset of axe-core rules, not the full WCAG spec. Issues like keyboard traps in modal dialogs, incorrect screen reader announcements on dynamic content, and logical reading order problems are completely invisible to automated scans. The gap between “we passed Lighthouse” and “we’re actually WCAG-conformant” is exactly where demand letters and lawsuits find their targets.
Why Did Overlay Widgets Fail Agencies?
Overlay widgets promised a simple fix: install a JavaScript snippet, let it inject CSS and ARIA changes at runtime, and call the site “compliant.” Agencies bought in because it was easy to install and easy to bill for. Then reality caught up.
The FTC fined accessiBe $1 million in January 2025 for false advertising claims about its product’s compliance capabilities (FTC enforcement action). UserWay faces its own legal trouble after BloomsyBox was served an ADA lawsuit just six months after installing the overlay (Lainey Feingold). And 25% of ADA lawsuits filed in 2024 targeted sites that had overlay widgets installed (EcomBack 2024). Overlays don’t rewrite source code. They don’t fix keyboard navigation. They don’t make complex widgets like date pickers or modal dialogs accessible. Courts don’t accept them as a compliance defense.
What Are the Biggest Pain Points in the Current Agency Workflow?
The pain points stack up fast. No clear owner means nobody is accountable, so accessibility gets deprioritized sprint after sprint. The knowledge gap is real: WCAG 2.1 AA has 50 success criteria, and most agency developers can name three to five at best. Agencies struggle to scope and price the work because manual audits cost $100-$250 per page (Accessible.org), and nobody knows how many hours to budget. Clients push back on paying for something invisible to sighted users.
Then there’s the monitoring gap. Even agencies that do a one-time audit rarely set up continuous monitoring. Sites regress as new content is added, CMS updates break ARIA patterns, and third-party widgets introduce new barriers. A quarterly manual scan leaves a 90-day blind spot. Tools like PageAudit run daily automated scans across all client sites and flag the moment a deploy breaks compliance, closing that gap between manual audits.
How Can Agencies Build a Better Accessibility Process?
The fix isn’t buying another tool. It’s building a process. Start by assigning a single owner for accessibility inside the agency, even if it’s a developer who spends 20% of their time on it. Clear ownership eliminates the “nobody’s job” problem that lets issues slide.
Next, embed automated checks into your CI/CD pipeline. axe-core or Pa11y running on every pull request catches regressions before they ship. Layer continuous monitoring on top. Tools like PageAudit scan client sites on a schedule and alert you when new violations appear, so you’re not blind between quarterly manual audits. Supplement all of this with periodic manual audits from a specialist for the 60-70% of WCAG criteria that automation can’t reach. Retroactive remediation costs 5-10x more than building accessibly from the start, so catching issues early saves real money. The WebAIM Million 2025 report found an average of 51 errors per homepage. Start there. Run a scan on your top 10 client sites today and see what you’re sitting on.
Frequently Asked Questions
How Often Should Agencies Audit Client Sites for ADA Compliance?
At minimum, agencies should run automated scans continuously or weekly, with a manual audit by a qualified specialist at least once per year. The gap between audits is where risk lives. A quarterly manual scan means you’re blind for roughly 90 days. During that window, developer deploys, CMS content updates, and third-party widget changes can introduce new accessibility barriers that nobody catches until a demand letter arrives. Automated monitoring tools can fill this gap by scanning on a schedule and alerting teams when violations appear. Annual manual audits cover the 60-70% of WCAG criteria that automated tools miss, including keyboard navigation, screen reader compatibility, and complex interactive widget behavior. For high-risk sites (e-commerce, healthcare, government), semi-annual manual audits plus continuous automated scanning is the strongest posture.
Can Automated Accessibility Scans Replace Manual Audits?
No. Automated tools catch roughly 30-40% of real-world WCAG issues by volume (Deque Automated Coverage Report). axe-core, the engine behind most popular scanners including Google Lighthouse, covers approximately 32% of WCAG 2.1 A+AA success criteria. That means the majority of accessibility barriers, including keyboard trap issues, screen reader announcement problems, logical reading order, and focus management in dynamic content, require a human tester using assistive technology. Automated scans are excellent for catching high-frequency violations like missing alt text, insufficient color contrast, and missing form labels. They also excel at monitoring for regressions between manual audits. But they cannot replace the judgment a trained specialist brings to evaluating whether a complex checkout flow or interactive component is truly usable by someone navigating with a keyboard or screen reader.
What Triggers Most ADA Website Lawsuits Against Agency Clients?
The most common trigger is a serial plaintiff or their attorney systematically scanning websites for detectable WCAG violations and filing demand letters or lawsuits. E-commerce sites are the primary target: 77% of ADA web lawsuits in 2024 targeted online retail (EcomBack 2024 Annual Report). Common violations that trigger suits include missing alternative text for images, inaccessible forms without proper label associations, insufficient color contrast ratios, and keyboard-inaccessible navigation or checkout flows. The demand letter typically alleges that a person with a disability was unable to use the website and requests a settlement. Settlement costs range from $30,000 to $150,000 all-in (Accessible.org). Agencies rarely get named directly in suits, but clients may seek indemnification through contract clauses, especially if the agency was responsible for the site’s design and development.
Are Overlay Widgets Like accessiBe a Valid Compliance Approach?
No. Courts have not accepted overlay widgets as a valid defense in ADA lawsuits. The FTC fined accessiBe $1 million in January 2025 for making false claims about its product achieving compliance (FTC enforcement). Twenty-five percent of ADA lawsuits filed in 2024 targeted websites that had overlay widgets installed (EcomBack 2024). Overlays work by injecting JavaScript that attempts to modify the page at runtime, adding ARIA attributes, adjusting colors, and changing font sizes. But they cannot fix structural issues in the underlying HTML: broken heading hierarchies, inaccessible custom components, keyboard traps, and missing form associations. They also frequently interfere with screen readers rather than helping them. The most effective approach combines proper source-code remediation, automated monitoring for regressions, and periodic manual audits by a qualified accessibility specialist.
Who Inside the Agency Should Own Accessibility?
Assign a single person. The title matters less than the accountability. In small agencies (under 15 people), this is typically a senior front-end developer who allocates 15-20% of their time to accessibility. They review designs for contrast and touch target sizes, check pull requests for common WCAG violations, and maintain the agency’s accessibility testing checklist. In larger agencies, a dedicated accessibility specialist with IAAP certification (CPACC or CPWA) is ideal. The key insight from agencies that have made this transition: when accessibility is everyone’s job, it’s nobody’s job. A single owner who is responsible for the process, not for personally fixing every issue, creates the accountability that prevents accessibility from being deprioritized. This person sets standards, trains the team, and ensures monitoring is in place.