A manual web accessibility audit costs between $1,500 and $25,000 for most businesses. Small marketing sites sit at the bottom of that range and complex web apps at the top. Anything dramatically cheaper is usually an automated scan being sold as an audit.

That range should be easy to find. Go to the websites of the five biggest accessibility firms, though, and try to find a price – any price, even a starting-at number. What you’ll find instead is a “Contact Sales” button, a discovery call, and a quote two weeks later that you have no real way to evaluate.

I understand why firms price this way. Audits genuinely vary in scope, and nobody wants to be held to a number before seeing the site. The problem, though, is that the cost of all that opacity lands on the buyer. Every week a business spends collecting mystery quotes is another week its site stays broken for the roughly one in four American adults with a disability.

---

Here are our numbers.

The short answer

For a manual WCAG 2.2 AA audit of a typical website:

• Single-page (homepage) audit: $495, credited in full if you go on to a complete audit
• Small business site (brochure sites, small stores, modest set of templates): from $3,000
• Mid-size site or small web app (accounts, forms, search, checkout): from $5,500
• Large site or SaaS product (authenticated flows, complex components): from $9,500
• VPAT/ACR documentation, added to an audit: $750–$1,500 depending on edition

Those are our actual prices at Labrador Services, the same ones on our pricing page. Every engagement is fixed-fee, and the floors above become an exact number in your proposal within 2 business days.

Industry-wide, the shape is similar: small firms publish prices between $1,500 and $5,000 for small-to-mid sites, while enterprise firms quote $10,000 to $75,000+ for large engagements. If someone quotes you $300 for a “complete audit,” you’re buying a scan. More on that in a minute.

What actually drives the cost

An audit is priced on human hours, and six things move the number.

1. Scope – unique templates and flows, not page count. A 500-page blog built on three templates is a smaller job than a 12-screen app with drag-and-drop, data tables, and a multi-step checkout. Good auditors price by unique experiences. If a vendor quotes you by raw page count alone, ask why.

2. Manual vs. automated testing. Automated tools catch roughly a third of WCAG failures. They’re useful – we built one – but they can’t tell you whether your alt text actually describes anything, or whether a screen reader user can get through your checkout. Finding that out takes a person navigating your site with a keyboard and a screen reader, at 200% zoom, and that’s where most of the hours in an audit go.

3. Assistive technology coverage. Testing with one screen reader is a start. Testing across JAWS, NVDA, and VoiceOver, on desktop and mobile, multiplies the hours – and for some audiences it’s necessary.

4. Component complexity. A page of headings and paragraphs tests quickly. A custom date picker, a drag-and-drop board, a live-updating data table, or a chart with no text alternative each take real time, because the auditor has to work through every state the component can reach – open, closed, focused, errored – with a keyboard and a screen reader. One complicated component can take longer to test than ten static pages, which is part of why two sites with the same page count can get very different quotes.

5. How much is already broken. Auditors can usually tell within an hour whether a site was built with accessibility in mind. If it wasn’t, every finding still has to be documented – reproduced, rated for severity, written up with remediation guidance. A site with 40 issues takes meaningfully longer to report on than a site with 8, even if the testing covers the same ground. Teams that run an automated scan and clean up the obvious problems before the audit tend to pay less, because the hours go into judgment calls instead of cataloging missing alt text.

6. Documentation depth. A spreadsheet of issues is cheap to produce. A report your developers can act on – severity ratings, code-level remediation guidance, accessible screen recordings of failures – takes longer, and it’s the difference between fixing things and arguing about them. If you need a VPAT for procurement, that’s additional structured documentation on top.

The $49/month trap

You’ve seen the ads: full ADA compliance from one line of JavaScript. I get the appeal. If a widget could actually do that, paying $49 a month instead of $5,000 for an audit would be the obvious call, and I’d tell you to make it.

It can’t, though. The FTC fined accessiBe $1 million in 2025 for deceptive compliance claims, and roughly a quarter of digital accessibility lawsuits now target sites that were running an overlay when they got sued.

An overlay doesn’t fix your inaccessible form labels. It papers over them while real users hit the same walls they always did. You end up paying for the remediation you skipped anyway, plus whatever the lawsuit costs you in the meantime.

What should you get for your money?

At any price point, a real audit includes:

• Manual testing by a human using keyboard navigation and at least one screen reader
• An explicit WCAG version and conformance level (in 2026, that should be WCAG 2.2 AA)
• Issues mapped to specific success criteria, with severity ratings
• Remediation guidance specific enough that a developer can act without guessing
• A path to retest after fixes, so you can verify the work rather than hope

If a quote is missing any of those, the two quotes you’re comparing aren’t for the same product, whatever the invoices say.

So why do we publish our prices?

Because buyers with no pricing information make bad decisions. Some overpay an enterprise firm for a small job. Some pay $300 for a scan dressed up as an audit and find out during procurement that it doesn’t hold up. Plenty just stall, and their site stays broken while they wait for a quote that tells them nothing.

I’ve watched all of this happen, and the people it hurts most aren’t the buyers – it’s the disabled users stuck on an inaccessible site for months longer than they needed to be.

Publishing prices costs us some leverage in negotiations, and we know it. We’d rather give that up than make you sit through a discovery call just to learn what a homepage audit costs.

Frequently asked questions

How much does an accessibility audit cost for a small website?
From $3,000 for a manual WCAG 2.2 AA audit of a standard small-business website – or $495 for a single-page homepage audit if you want to see how we work first or get a temperature check on your site. Anything dramatically cheaper is almost certainly an automated scan, not an audit.

How much does a VPAT cost?
As an add-on to an audit, $750 for the WCAG edition, $950 for the 508 or EU editions, and $1,500 for the INT edition covering all three standards. A VPAT that isn’t backed by an actual audit won’t survive a procurement review.

Are free automated accessibility checkers enough?
No. They catch roughly 30% of WCAG failures and none of the usability context. Use them as a first pass – we do – but they can’t replace manual testing.

How long does an accessibility audit take?
Most small-to-mid engagements run 1 to 2 weeks from kickoff to report delivery. If you’re on a legal deadline, ask about expedited timelines.

Does an audit make me ADA compliant?
No. An audit tells you where you stand, and remediation is what gets you compliant. We offer both.

Manual vs automated accessibility testing: Which one do you actually need?

---

Automated accessibility testing catches roughly a third of WCAG failures – the deterministic ones, like missing alt text, empty links, and contrast values that fail the math. Manual testing with a keyboard and a screen reader catches the other two thirds, including almost every failure that actually stops someone from finishing a task. If you can only afford one, buy the manual testing. If you’re doing this properly, you use both.

That’s the answer most vendors won’t give you straight, because most vendors sell one or the other. We built an automated tool and we sell manual audits, so we don’t have a side to protect here.

What scanners are genuinely good at

I want to be fair to automation, because we use it on every engagement. A scanner will find missing alt text, form fields with no labels, empty buttons, bad heading structure, and low-contrast text across your entire site in a few minutes. It doesn’t get tired, it doesn’t skip pages, and it hands you a backlog you can start triaging the same day.

For a team that has never tested anything, that first scan is the highest-value hour in the whole process. It also makes the manual audit cheaper – every scan-level issue you fix beforehand is an hour the auditor spends on judgment calls instead of cataloging missing labels.

So what does the scanner miss?

Everything that requires knowing what the page is for.

A scanner can confirm your date picker has an accessible name. It cannot tell you that the date picker traps keyboard focus, or that VoiceOver reads the calendar grid as a wall of unlabeled numbers, or that the error message appears visually but is never announced, so a blind user submits the form three times before giving up.

Take a checkout flow. Every field has a label, every button has a name, the contrast passes – the scan comes back nearly clean. Then a screen reader user tries to buy something: the coupon field steals focus on page load, the shipping options are announced in a different order than they appear, and the “order confirmed” message is a visual toast that assistive technology never sees. That checkout passes automation and fails every customer the ADA exists to protect. Nothing in that paragraph is hypothetical, by the way – it’s a composite of things we find weekly.

The pattern holds across components: modals, drag-and-drop, live-updating tables, multi-step forms. The DOM can look fine while the experience is broken. Judgment is still a human job.

The two thirds are where the consequences live

The failures automation misses aren’t a rounding error – they’re the ones with legal and commercial weight.

Roughly two thirds of digital accessibility lawsuits now target sites that were running an automated overlay when they got sued, which tells you how far scan-level compliance gets you in court. And in procurement, nobody asks whether you ran a scanner. They ask whether someone using JAWS or VoiceOver can complete your critical paths, and they expect a VPAT backed by testing that can answer that question honestly.

How we split the work

Automation goes first and maps the surface: every template, every page type, the full backlog of deterministic issues. Then the bulk of the audit hours go where people actually get stuck – a human working through your real flows with a keyboard, with JAWS, NVDA, and VoiceOver, at 200% zoom, on desktop and mobile where the audience calls for it.

The scanner tells us where to dig. The person does the digging, because the person is the only one who notices when a flow is technically passable but exhausting – twelve tab stops to reach the one control that matters, announcements that are accurate but useless. Those never appear in a scan report, and they’re the difference between a site that conforms and a site a disabled person would willingly use twice.

Frequently asked questions

What percentage of accessibility issues can automated testing find?
Roughly 30-40% of WCAG failures, depending on the site and the tool. The remainder – keyboard traps, focus order, meaningful alt text, announcement behavior – requires a person using assistive technology.

Is automated accessibility testing enough for ADA compliance?
No. Automated testing alone leaves the majority of WCAG failures undetected, and courts have not treated scan results or overlay widgets as evidence of compliance. Manual testing against WCAG 2.2 AA is the standard that holds up.

Should I run an automated scan before a manual audit?
Yes, and fix what it finds first. Teams that clean up scan-level issues before the audit pay less, because the auditor’s hours go into judgment calls instead of documenting missing alt text.

What tools do manual accessibility testers use?
The same ones your users rely on: NVDA, VoiceOver, and JAWS for screen reading, keyboard-only navigation, zoom up to 200%, and mobile screen readers like TalkBack where the audience calls for it.