For most small business websites in the US, ADA website compliance costs roughly $1,500 to $3,500 if your own developers make the fixes, according to Accessible.org's 2026 pricing guide. If you pay outsiders for both the audit and the fixes, budget roughly $2,750 to $13,000: a manual audit at about $1,250 to $5,000 (Accessible.org, AudioEye) plus remediation at $100–$200 an hour for 15–40 hours. The fixes are the part that swings with your platform and how the site was built, and an overlay widget doesn't replace either.
I build on WordPress (Elementor, Bricks and Oxygen) and Next.js, which is where most of these fixes end up. Below I split out the two bills you'll get, show where the cost hides on each platform, and give you a free way to triage your site before you pay anyone. This is general advice, not legal advice. If a demand letter has already arrived, call a lawyer before you call a developer.
94.8%
Home pages with detectable WCAG failures (WebAIM, 2025)
51
Average detected errors per home page
5,000+
US digital accessibility lawsuits filed in 2025
46%
Share of federal cases against repeat defendants
Sources: WebAIM Million 2025 and UsableNet's review of 2025 filings.
What does ADA website compliance mean?
In practice it means meeting WCAG 2.1 Level AA. The ADA itself doesn't name a technical standard for websites, so US courts and the Department of Justice point to WCAG 2.1 AA instead, and audits and fixes are priced against it (Accessible.org). WCAG 2.2 AA is the newer version and adds a few criteria. If you're paying for an audit now, ask for 2.2 so you aren't re-testing in a year.
Who gets sued matters for your budget. In UsableNet's analysis of 2025 lawsuits, e-commerce made up nearly 70% of ADA web cases and food service about 21%. 64% of companies sued had less than $25 million in annual revenue. Small businesses get these letters too. Plaintiff firms also come back: 46% of federal cases involved companies that had been sued before. If your site sells, books or takes orders, your risk is higher, and a half-done fix won't lower it much.
How much does an ADA website audit cost?
A manual ADA audit for a small US business website typically costs $1,250 to $5,000. A mid-size site runs $5,000 to $20,000, and an enterprise site $20,000 or more. In an audit, an expert tests your pages with a keyboard, a screen reader and automated tools, then writes a report listing each issue, the WCAG criterion it fails and how to fix it. That report becomes your developer's work order. Don't pay for a scan dressed up as an audit. Scans only flag about 25% of WCAG success criteria.
| Audit type | Typical US price | Source |
|---|---|---|
| Automated scanning (small site) | $50–$300 per month | AudioEye |
| Manual audit, most small sites | $1,250–$2,750 | Accessible.org |
| Manual audit, small site | $1,500–$5,000 | AudioEye |
| Manual audit, mid-size site | $5,000–$20,000 | AudioEye |
| Manual audit, enterprise site | $20,000–$50,000+ | AudioEye |
| Enterprise audit bundled with software | From $15,000 | Accessible.org |
Two things move the price more than page count. The first is unique templates. A 500-page site built on ten templates gets priced like a ten-page audit, because the same issues repeat (Accessible.org). The second is interactivity. Checkout, booking flows, filters, forms and modals take far longer to test than a brochure page. And audit quotes usually exclude remediation, so the fixes are a separate bill.
How much does it cost to fix accessibility issues in code?
If you hire outside developers, Accessible.org puts remediation at $100–$200 per hour, with most sites needing 15–40 hours, which works out to roughly $1,500 to $8,000. The same guide puts a full small business project at $1,500–$3,500 when your own developers make the fixes, and a mid-size e-commerce site at $2,500–$6,000.
What decides the bill is where each problem lives:
- Content: alt text, vague link text, skipped heading levels, PDFs. Cheap per item but tedious, and your own team can usually handle it. Outsourced document remediation starts at $7 per page.
- Templates and components: menus, focus styles, forms, sliders, popups, product and checkout templates. Fix one and every page that uses it is fixed.
- Third-party embeds: booking engines, chat widgets, review carousels, CAPTCHAs. You often can't touch their code, so either the vendor fixes it or you swap it out. WebAIM found pages with reCAPTCHA had 12.1 more errors than average.
Where the fixes land on each platform
| Platform | Where issues usually hide | How the fix is applied |
|---|---|---|
| WordPress theme or WooCommerce | Mobile menu toggles, missing skip link, removed focus outlines, form plugin labels, sliders, cart and checkout notices | In a child theme or template override, so it survives updates |
| Elementor | Heading tags chosen for size not structure, icon-only buttons with no label, carousels, popups that trap focus, deep div nesting | Widget settings per instance, global styles for contrast, small custom code for what the widget can't do |
| Bricks or Oxygen | Mostly whatever the original developer built, since tags and attributes are set by hand | Per template or component, usually cleaner than Elementor |
| Next.js or React | Clickable divs instead of buttons, modals without focus management, custom dropdowns, icon buttons without names | In the shared component, so one fix covers every page |
Elementor sites tend to need more fixes per page, because so much is set on each widget instance rather than in one template. Next.js and React fixes are usually fewer but deeper. A broken modal or dropdown component is one fix, but it needs proper keyboard and screen reader testing before you can call it done. If you're weighing builders, my Bricks vs Elementor vs Oxygen comparison looks at the code each one outputs.
WebAIM's data shows the same pattern across a million home pages:
- All home pages51 errors
- wpBakery63.5 errors
- Elementor51.1 errors
- WordPress50 errors
- React42.4 errors
- Drupal41.9 errors
- Next.js38.6 errors
I'd read that as a rough signal and nothing more. WebAIM itself says an absence of detected errors doesn't mean a page is accessible, and the averages don't account for who built each site or how big the team was.
Why don't accessibility overlays replace real fixes?
Because your underlying code stays broken, and that code is what screen readers and keyboard users depend on. An overlay is a script that adds an accessibility toolbar and claims to repair your site automatically. It runs on top of your markup. It doesn't change it.
The record on overlays isn't good:
- In January 2025 the FTC ordered accessiBe to pay $1 million over claims that its AI product could make websites compliant with accessibility guidelines. The order was later finalized (Lainey Feingold's write-up).
- UsableNet's 2025 data shows lawsuits against companies using widgets stayed steady all year, peaking above 150 in a single month. Some complaints say the widget itself got in the way of screen readers.
- Accessible.org notes plaintiffs' lawyers have filed hundreds of complaints that mention a widget and call it insufficient.
- The Overlay Fact Sheet sets out why many accessibility practitioners reject them.
A widget is not a fix
Overlays add a toolbar on top of your code but leave the code itself broken. Lawsuits in 2025 kept naming sites that had one installed, and the FTC fined one overlay vendor $1 million over its compliance claims.
If you already pay for one, you don't have to rip it out on day one. Just don't let it stand in for the audit and the code fixes.
Which accessibility issues should you fix first?
Start with the six most common errors, then the journeys that make you money: checkout, booking and your contact form. According to WebAIM, 96% of detected errors fall into six categories, and the list hasn't changed in five years: low contrast text (79.1% of home pages), missing image alt text (55.5%), missing form labels (48.2%), empty links (45.4%), empty buttons (29.6%) and missing page language (15.8%).
- 1
Run a free check
Paste the HTML of your home page, a product or service page and your contact or checkout page into the Accessibility Checker. It flags WCAG 2.2 issues by severity with corrected code.
- 2
Tab through your key journeys
Put the mouse away and use only the keyboard to buy, book or send an enquiry. If you lose the focus outline, get stuck in a popup or can't reach a button, that's a priority fix.
- 3
Clear the six common errors
Contrast, alt text, form labels, empty links, empty buttons and page language. Most are cheap, and your team can do the content ones.
- 4
Fix templates and components
Menus, modals, sliders, forms and checkout get fixed once at the template or component level so every page inherits the fix.
- 5
Audit, then re-test
Get a manual audit against WCAG 2.1 or 2.2 AA, fix what it finds, then have the fixes validated against the report.
- 6
Keep it fixed
Publish an accessibility statement with a contact route, train editors on alt text and headings, and re-check before each release.
Keeping it fixed is part of ongoing upkeep, and my US WordPress maintenance cost guide covers what that typically runs to.
I built a free Accessibility Checker for this first pass. Paste in HTML, JSX or a component and it reviews it against WCAG 2.2: labels, alt text, heading order, keyboard and focus problems, misused ARIA and contrast risks. Each issue gets a severity and corrected code. It won't replace a manual audit. What it will tell you, before you ask anyone for a quote, is whether you've got a content problem or a template problem.
Should you fix your current site or redesign it?
Fix what you have if the theme is reasonably modern and the problems are mostly content plus a handful of components. Think about a redesign if the site runs on an old theme, stacks several page builders or depends on plugins nobody maintains. Otherwise you may end up paying to fix code you'll throw away within a year.
If a redesign is already happening, put WCAG 2.2 AA in the brief and make it a sign-off condition, not a later phase. Building accessible components from the start is far cheaper than retrofitting them. My US website redesign cost guide covers what a rebuild runs to.
How long does ADA remediation take?
On a small website, usually weeks rather than months. The code work is typically 15–40 hours according to Accessible.org, with the audit before it and validation after. When timelines drag, it's rarely the code. It's waiting on a booking or chat vendor to fix their widget, or grinding through a backlog of PDFs and old blog images.
What should you ask a developer before hiring?
The three that matter most: which WCAG version they test against, whether they test manually, and whether they fix at template level. The full list:
- Which standard will you test and fix against: WCAG 2.1 AA or 2.2 AA?
- Do you test manually with a keyboard and a screen reader, or only run scans?
- Will you fix issues in templates and shared components, or page by page?
- What happens with third-party widgets you can't change?
- Will you re-test against the audit report and hand over a list of what's fixed and what's outstanding?
- How do we keep it accessible after launch: editor training, linting, checks before releases?
If anyone promises "100% ADA compliance" or a "lawsuit-proof" site, walk away. No honest developer or auditor can guarantee either. For the wider checks, see my guide to hiring a WordPress developer in the US.
What should you do next?
Run your home page and your most important conversion page through the Accessibility Checker today. If the problems sit in your theme or page builder, that's the code I work in every day through my WordPress builds on Bricks, Elementor and Oxygen. If you're on React or Next.js, see Next.js and React websites. Then send me your checker results or audit report and I'll tell you which items are content fixes, which need code and which belong to a vendor.
