How long does an accessibility audit take?

A manual accessibility audit takes one to two weeks for most small-to-mid-size websites, measured from kickoff to report delivery. Larger sites and complex web apps run two to four weeks. Add one to two days for the proposal up front, and plan on a separate remediation period afterward – typically two to eight weeks depending on how much is broken – followed by a retest that takes a few days. If a vendor promises a complete audit in 24 hours, you’re being sold an automated scan with a cover page.

That’s the answer most buyers are looking for, and the rest of this post breaks down where the time actually goes, what stretches a WCAG audit timeline from two weeks to six, and what to do when a legal deadline means you don’t have two weeks.

The full timeline, stage by stage

An accessibility audit isn’t one block of time. It’s four stages, and buyers who only budget for the middle one get surprised.

Scoping and proposal: 1 to 2 business days. You share your URL and describe the site, the auditor identifies unique templates and flows, and you get a fixed price and a start date. At Labrador Services the proposal lands within two business days of your request. Enterprise firms often take one to two weeks for this stage alone, because discovery calls have to be scheduled before anyone will name a number.

The audit itself: 1 to 2 weeks for most sites. This is the manual testing – a human working through your pages and flows with a keyboard, with screen readers, at 200% zoom, then documenting every failure against a specific WCAG 2.2 success criterion with severity ratings and remediation guidance. We covered what that deliverable looks like in what an accessibility audit actually includes.

Remediation: 1 to 6 weeks, sometimes more. The audit hands your developers a prioritized work order. How long the fixes take depends on your team’s capacity and how deep the problems go. A brochure site with 15 issues might be clean in two weeks; a web app with a custom component library and 60 findings can take a quarter.

Retest: 2 to 5 days. The auditor verifies your fixes with the same assistive technology that found the issues. Ours is included in the audit price. Skip this stage and you have a list of things someone intended to fix, which is not the same as evidence that they’re fixed.

So when someone asks how long the whole process takes, site broken to site verified, the honest answer for a typical small business is six to twelve weeks, and the audit itself is the shortest part.

What actually drives audit turnaround time

The same things that drive audit cost drive the timeline, because both are measures of human hours.

Unique templates and flows, not page count. A 500-page blog on three templates audits faster than a 12-screen app with checkout, account management, and a drag-and-drop interface. Auditors test experiences, not URLs.

Component complexity. A custom date picker has to be tested in every state it can reach – open, closed, focused, errored – with a keyboard and a screen reader. One complicated component can take longer than ten static pages.

Assistive technology coverage. Testing with NVDA alone is faster than testing across JAWS, NVDA, and VoiceOver on desktop and mobile. Broader coverage multiplies hours. Whether you need it depends on your audience and your risk.

How much is broken. Every failure gets reproduced, rated, and written up with a fix. A site with 40 issues takes meaningfully longer to document than a site with 8, even when the testing covers identical ground. Teams that run a free automated scan first and clean up the obvious failures – missing alt text, empty buttons, low-contrast text – shorten their own audit. The scan only catches about a third of WCAG failures, which is why manual testing exists, but that third is fast to fix and slow to document.

Auditor availability. The quoted timeline starts at kickoff, not at signature. Ask every vendor two separate questions: how long the audit takes, and when they can start. A two-week audit that starts in six weeks is an eight-week wait.

Why can’t it be faster?

It’s worth taking the question seriously, because the instinct behind it is reasonable. Automated scanners return results in minutes. If a tool can check your whole site before lunch, why does a human need two weeks?

Because the tool and the human are answering different questions. A scanner checks whether your code matches patterns it can parse – alt attributes present, contrast ratios above threshold, form fields labeled. It cannot tell you whether the alt text describes the image, whether the label makes sense, or whether a screen reader user can actually complete your checkout. Finding that out means a person navigating every flow the way your users do, and there’s no compression algorithm for attention.

The documentation is the other half of the time. A finding that just says “keyboard trap on checkout” starts an argument with your developers. A finding with the failing criterion, reproduction steps, a screen recording, and code-level guidance starts a fix. The second kind takes hours the first kind doesn’t, and it’s the difference between a report that gets acted on and one that sits in a drawer.

When you don’t have two weeks

Legal deadlines change the math. An ADA demand letter usually gives you 10 to 30 days to respond, and your attorney needs a factual read on the claims well before that.

An expedited accessibility audit is a real option, though it means the auditor is reprioritizing their queue rather than skipping steps, so expect a rush premium and say what your deadline is upfront. We can scope and start within days when a client is on a legal clock.

There’s also a faster first move: a single-page audit. Our $495 homepage audit turns around quickly, gives your attorney an early factual read, and the fee is credited in full if you continue to a complete audit. If the letter names specific pages, a scoped audit of those pages does the same job. We wrote a full playbook for responding to an ADA demand letter if that’s what brought you here.

What a deadline doesn’t justify is the 24-hour “compliance” shortcut. A widget installs in an afternoon and fixes nothing underneath, and roughly a quarter of accessibility lawsuits now target sites that were running one when they got sued.

A worked example

Say you run a mid-size e-commerce site: product catalog, search, cart, checkout, customer accounts. You request a quote on a Monday. The proposal arrives Tuesday with a fixed fee and a kickoff the following Monday.

The audit runs two weeks, because checkout and account flows have to be tested end to end with a keyboard and two screen readers. You get the report on a Friday: 34 findings, 6 critical, sequenced into a remediation plan. Your two developers work through the criticals in three weeks and the rest over the next four, alongside their normal sprint work. The retest takes three days and verifies 32 of 34 fixed, with two sent back with notes.

Total elapsed time: about ten weeks from first email to verified fixes. The audit was two of those weeks. Budgeting ten weeks from the start is what keeps this process calm; discovering it in week six is what makes it expensive.

Frequently asked questions

How long does an accessibility audit take for a small website?
One to two weeks from kickoff to report for a typical small-business site, plus a day or two for the proposal up front. A single-page homepage audit turns around in days.

How long does a WCAG audit take for a large site or web app?
Two to four weeks for most large sites and SaaS products with authenticated flows and complex components. Very large engagements with broad assistive technology coverage can run longer, which is one reason to scope by unique templates and flows rather than raw page count.

Can I get an accessibility audit done in a week?
Sometimes. Expedited audits exist for legal deadlines and procurement crunches – expect a rush premium, and mention the deadline when you request a quote. A scoped single-page or few-page audit is the fastest legitimate option. Anything promising full-site results in 24 hours is an automated scan.

How long does accessibility remediation take after an audit?
One to six weeks for most sites, depending on your developers’ capacity and the number of findings. Complex web apps with many critical issues can take a quarter. A good audit report shortens this by sequencing fixes and including code-level guidance.

Does the audit timeline include the retest?
Ask, because it varies by vendor. Ours includes a retest after remediation at no extra cost – it typically takes two to five days and verifies fixes with the same assistive technology that found the issues.

How soon can an audit start after I sign?
That’s a separate question from how long the audit takes, and worth asking every vendor. Queues of two to six weeks are common at larger firms. We typically kick off within days, and faster when a legal deadline is involved.

Playbook for “I received an ADA demand letter for my website. What do I do?”

If you’ve received an ADA website demand letter, here’s what to do: don’t panic, don’t reply to the letter yourself, don’t install an accessibility widget, and don’t delete anything. Preserve a copy of your site as it exists today, get the letter to an attorney with ADA Title III experience, and start an independent accessibility audit so you know whether the claims are real. Most of these letters settle for between $5,000 and $25,000, and how you handle the first two weeks has a lot to do with where in that range you land.

That’s the compressed version, and the rest of this post walks through each step: what the letter actually means, what order to do things in, and the mistakes that make these situations more expensive than they need to be.

One thing up front: I run an accessibility auditing firm, not a law firm. Nothing here is legal advice. It’s the practical playbook we walk clients through when they show up with a letter in hand, and it’s meant to make your first conversation with an actual attorney faster and cheaper.

First, understand what you’re holding

An ADA demand letter is a formal notice, usually from a law firm representing a plaintiff with a disability, alleging that your website violates Title III of the Americans with Disabilities Act. It typically lists specific barriers (missing alt text, keyboard traps, unlabeled form fields), references WCAG as the measuring stick, and demands two things: that you fix the site, and that you pay a settlement to avoid a lawsuit.

You are not alone in receiving one. Plaintiffs filed 3,117 website accessibility lawsuits in federal court in 2025, up 27% from the year before, and lawsuits are the visible tip. Industry estimates put demand letters at roughly 7 to 10 for every suit actually filed – somewhere between 35,000 and 50,000 letters in 2025 alone.

The letters are also concentrated. In the first half of 2025, just 31 plaintiffs accounted for more than half of all filings, and a small group of law firms files the overwhelming majority of cases. This matters for your response, because a serial filer’s economics run on volume: they generally want a fast, predictable settlement, not a court fight.

Knowing that shouldn’t make you dismissive, though. For what it’s worth, I think the volume-filing model is ugly, and I say that as someone who tests websites for a living. But the model only works because most of the sites getting letters genuinely fail WCAG, and ignoring the letter is the single most reliable way to turn an $8,000 problem into a $40,000 one.

The playbook

Step 1: Preserve everything, change nothing (today)

Before you touch your site, capture it. Save the letter and its envelope or email headers. Take full-page screenshots of every page the letter mentions. If you can, archive the pages with the Wayback Machine or a crawl tool.

This feels backwards – your instinct is to start fixing immediately. Your attorney, though, will need an accurate record of what the plaintiff actually encountered. If the letter’s claims don’t match your site (they tested an old version, or relied on a bad automated scan), that mismatch is negotiating leverage, and you can only prove it with evidence from before you changed anything.

The fixes can start next week. The record of what your site looked like before them can only be made today.

Step 2: Do not respond to the letter yourself (this week)

Anything you write to the plaintiff’s firm can be used in the negotiation or in court. Business owners who fire off an indignant reply, or an apologetic one promising fixes by Friday, hand the other side ammunition either way.

The same goes for silence, though. Most letters include a response deadline, often 10 to 30 days. Missing it doesn’t automatically trigger a lawsuit, but it tells a volume-based firm that suing you is the faster path to getting paid.

Step 3: Get an attorney with ADA Title III experience (this week)

Not your cousin who does real estate closings. ADA website defense is a niche, and lawyers who work in it know the specific plaintiff firms, their settlement patterns, and which arguments actually move numbers. Your attorney can pull the plaintiff’s filing history on PACER in minutes; a plaintiff who has filed 200 identical suits negotiates differently than a first-time filer, and typically settles for less.

A few hours of the right lawyer’s time is one of the cheaper line items in this whole process. Settlement demands are opening positions, and represented defendants consistently pay less than unrepresented ones.

Step 4: Get an independent audit, not a widget (week one to two)

You need to know whether the claims in the letter are accurate, and how deep the problems actually go. The letter will list maybe five to ten issues; when we audit a site that’s received one, we almost always find more, and the plaintiff’s firm is counting on that.

So what does an audit actually buy you here? Verification, mostly. If the letter says your checkout can’t be completed with a keyboard and your auditor confirms it can, your attorney now has a factual defense on that claim.

It also tells you what remediation will really involve before you sign a settlement agreement committing to it, and nearly every settlement agreement includes that commitment. Signing one without an audit is agreeing to a renovation before anyone has inspected the house.

The audit does one more quiet job: it documents good faith. Dated evidence that you hired a professional and started fixing things is persuasive in negotiation, and in front of a judge if it gets that far. Proof that you acted early often counts for more than the current state of the site.

What you should not do is install an overlay widget and call it handled. The FTC fined accessiBe $1 million in 2025 for deceptive compliance claims, and roughly a quarter of accessibility suits now target sites that were running a widget when they got sued. Plaintiff firms can detect overlays, and some appear to treat them as a signal that the underlying site was never actually fixed. We wrote about this at length in our post on the FTC fine and what it means for widget customers.

If you’re on a legal clock, say so when you contact an auditor. We can scope and start within days when a response deadline is bearing down – ask about expedited timelines when you get a quote. A $495 homepage audit can also serve as a fast, cheap first read on how bad things are while the full engagement gets scoped.

Step 5: Fix the real barriers (weeks two through eight)

Whatever happens with the settlement, the barriers that are real need fixing, both because the next demand letter is otherwise a matter of time and because there are actual people who can’t use your site right now.

Repeat targeting is not hypothetical, either. Roughly 45% of 2025 federal digital accessibility defendants had been sued before. Settling with one plaintiff does not immunize you against the next one, and plaintiff firms share target lists in practice if not in name. The only durable exit from this cycle is a site that holds up to testing.

Prioritize by severity: barriers that block a task entirely (can’t complete checkout, can’t submit the contact form, can’t close a modal) come before cosmetic issues. A good audit report hands you this priority order with code-level guidance, so your developers fix instead of guessing. If you don’t have developers, remediation is a service you can buy – we do it, and so do others.

Step 6: Settle or fight, with your eyes open (timeline varies)

Most of these matters settle, and settling is often the rational move. Defense through trial can run $30,000 to $175,000 in legal fees even if you win, because Title III fee-shifting means a losing defendant often pays the plaintiff’s attorneys too. Against a settlement demand of $10,000, the math usually points one direction.

Fighting makes sense in narrower cases: the plaintiff has standing problems, the claims are demonstrably false against your preserved evidence, or the demand is wildly out of line for your size. Some federal courts, especially in New York, have grown visibly less patient with serial plaintiffs, and your attorney will know whether your case sits in that current.

There are two negotiation details worth knowing going in. Settlements after a demand letter run cheaper than settlements after a filed complaint, so speed has monetary value. And small businesses that can document limited revenue routinely settle below $10,000; if that’s you, make sure your attorney knows the real numbers.

An example of how this goes wrong

A store owner gets a demand letter on a Monday alleging twelve WCAG failures. She’s furious – the letter is clearly a template, two of the claims describe pages her site doesn’t have, and the whole thing smells like a shakedown. So she ignores it.

Six weeks later she’s served with a federal complaint. Now she needs a lawyer under deadline pressure, the settlement number has roughly doubled because the plaintiff’s firm has filing costs to recover, and she’s making decisions about her website in a panic instead of on a schedule. She installs a widget because it promises overnight compliance, which becomes an exhibit in the plaintiff’s next filing.

The frustrating part is that her instinct about the letter was half right. It probably was a template from a volume filer, and the two false claims were real leverage. Handled in week one with counsel and an audit, that letter likely resolves for a modest settlement and a remediation plan she controls. Handled in month three under a federal docket number, it costs multiples of that.

Frequently asked questions

I received an ADA website demand letter. What should I do first?
Preserve evidence before changing anything: save the letter, screenshot the pages it mentions, and archive your site as it exists today. Then contact an attorney with ADA Title III experience and commission an independent accessibility audit. Don’t respond to the plaintiff’s firm yourself, and don’t install an accessibility widget.

Is an ADA demand letter the same as a lawsuit?
No. A demand letter is a pre-litigation notice offering to settle before a complaint is filed. No court is involved yet, and matters resolved at the letter stage generally settle for less than matters that reach a docket. The threat behind the letter is real, though – the firms sending them file thousands of suits a year.

How much does it cost to settle an ADA website demand letter?
Most settle between $5,000 and $25,000, with small businesses frequently under $10,000. Factors include your revenue, the plaintiff firm’s history, whether the claims hold up, and whether a complaint has been filed yet. Legal defense through trial costs far more, which is why most defendants settle.

Can a small business be sued over website accessibility?
Yes. There is no small-business exemption under ADA Title III, and the majority of web accessibility suits target companies under $25 million in revenue. Serial plaintiffs favor defendants likely to settle quickly, which often means smaller businesses without in-house counsel.

Will installing an accessibility widget protect me?
No. Roughly 25% of accessibility lawsuits now name sites that were running a widget at the time of filing, and the FTC fined accessiBe $1 million in 2025 for overstating what its overlay could do. Widgets don’t fix the underlying code that the plaintiff’s expert will test.

How fast can I get an accessibility audit if I’m facing a deadline?
Faster than the standard timeline if you say so upfront. We can start within days when a client is on a legal clock, and a single-page audit can be turned around quickly to give your attorney an early factual read. Most full small-to-mid-size audits run one to two weeks from kickoff to report.

Does fixing my website make the demand letter go away?
Not by itself. Remediation resolves the injunctive side of the claim, but the plaintiff’s attorney fees are the engine of these cases, and those get resolved through settlement. Prompt, documented remediation does strengthen your negotiating position and reduces the odds of the next letter

Sources

Accessibility.build lawsuit research – settlement and legal-cost benchmarks by resolution type, including defense fee ranges.

Seyfarth Shaw ADA Title III blog: Federal court website accessibility lawsuit filings bounce back in 2025 – 3,117 federal website accessibility lawsuits in 2025, up 27% from 2,452 in 2024.

UsableNet ADA lawsuit tracker and year-end reports – total digital accessibility filings across federal and state courts, repeat-defendant rate (45-46% of 2025 federal cases named a defendant already sued before), and defendant revenue breakdowns.

UsableNet 2025 Midyear Digital Accessibility Lawsuit Report – filing pace, industry targeting, and plaintiff concentration for the first half of 2025.

EcomBack 2025 Mid-Year ADA Website Lawsuit Report – 31 plaintiffs accounted for over half of H1 2025 filings; 22.6% of sued sites had an accessibility overlay installed; 16 law firms filed the large majority of cases. The 7-10 demand letters per filed lawsuit estimate comes from defense attorneys interviewed alongside this report’s data.

FTC press release: order requires accessiBe to pay $1 million for deceptive claims – the January 2025 complaint and order, finalized April 2025.

Seyfarth Shaw ADA Title III blog: New York federal courts and serial plaintiffs – judicial skepticism toward serial filers in New York.

Accessible.org: ADA website lawsuits – typical settlement ranges and defense cost estimates from a firm that works with defense attorneys.

Accessibility overlays and widgets in 2026: What the accessiBe FTC fine actually means for your business

In April 2025, the Federal Trade Commission did something the accessibility industry had been waiting years for someone to do. It looked at accessiBe – the largest, loudest seller of one-line-of-code “compliance” – and called the pitch what it was: false.

The order required accessiBe to pay $1 million and barred the company from claiming its automated tool could make any website WCAG-compliant unless it had the evidence to prove it. The specific claim the FTC went after is worth quoting, because you’ve almost certainly seen a version of it: installing “one line of code” makes a website compliant with 30% of WCAG requirements immediately, and an AI process handles the remaining 70% within 48 hours.

It doesn’t. It never did. And if you’re running an overlay on your site right now because someone sold you that promise, this post is for you.

What an accessibility overlay/widget actually is

An accessibility overlay (often referred to as a widget) is a piece of third-party JavaScript you drop onto your site that claims to detect and fix accessibility problems automatically – usually paired with a little floating icon that opens a menu of font-size and contrast controls. accessiBe, UserWay, AudioEye, EqualWeb, and a few dozen others all sell variations on this model.

Here’s the part the marketing leaves out. The overlay runs after your page loads. It injects its changes on top of your existing code rather than fixing the code itself. And that single architectural fact is the reason the whole category fails the people it claims to serve.

Screen readers like JAWS, NVDA, and VoiceOver build their understanding of your page from your HTML source. By the time an overlay’s script wakes up and starts rearranging things, the assistive technology has often already done its work – reading the broken version. The overlay is patching a wall the screen reader already walked through.

So, do accessibility overlays work?

For the question that actually matters – can a disabled person complete what they came to your site to do – the honest answer is: not reliably, and often not at all.

This isn’t one consultant’s grudge. The Overlay Fact Sheet, an open letter signed by contributors to the WCAG, ARIA, and HTML specifications, by code contributors to the JAWS and NVDA screen readers, and by internal accessibility experts at Google, Microsoft, Apple, and Shopify, lays out the technical case in detail. Automated repair of image alt text, form labels, error handling, and keyboard focus is – in their words – not reliable. Modern component-based frameworks like React, Angular, and Vue change the page out from under the overlay entirely.

And the people these tools are supposedly for? In the survey cited by the Fact Sheet, just 2.4% of users with disabilities rated overlays as “very effective.” Many find them so disruptive they install browser scripts specifically to block them. Sit with that number for a second. The product is named after accessibility, and the disabled users it targets are building tools to make it go away.

The lawsuit problem nobody mentions in the sales call

Here’s where it stops being a philosophical debate and starts costing money.

The pitch for an overlay is fundamentally a legal one: install this, avoid a lawsuit. The data says the opposite is happening – and 2025 made that clearer than ever. According to UsableNet’s research team, more than 5,000 digital accessibility lawsuits were filed in 2025, and the cases targeting sites with a widget installed didn’t let up for a single month – they ranged from roughly 95 to more than 150 filings per month, totaling around 1,400 lawsuits against businesses that already had an overlay running. EcomBack’s year-end analysis put it at nearly one in four ADA web lawsuits filed against a site with an accessibility widget live on it.

This wasn’t a fluke year. The 2024 report found the exact same pattern – roughly 25% of that year’s web accessibility lawsuits hit sites already running an overlay. Two consecutive years, same story: the widget that was sold as lawsuit protection shows up in the complaint. And the overall trend is pointing up, not down, with ADA website accessibility filings climbing 37% in the first half of 2025 alone.

What we are seeing here is a market that monetized fear faster than it solved problems. A business owner hears “you could get sued,” panics, reaches for the cheapest, fastest-looking fix, and ends up with both an inaccessible site and a false sense of security. Courts have consistently declined to treat an installed overlay as evidence of compliance. The widget isn’t a shield. In a growing number of cases, it’s a flag.

If you’ve been sued while using an accessibility widget, you are not an unlucky outlier. You are the pattern.

What changed after the FTC fine – and what didn’t

Watch the language. After the April 2025 order, accessiBe’s marketing quietly shifted from “make your website fully compliant” to softer phrasing like “align with WCAG 2.1/2.2 Level AA standards.” That hedge is the FTC compliance position – it’s what a company says when it’s legally barred from promising the thing it used to promise.

The technology didn’t change. The architecture that makes overlays fail at the source-code level is exactly the same as it was in 2024. What changed is that one regulator finally made the biggest player stop saying the quiet part out loud. The marketing got more careful. The product did not get better.

What to do if you’re running an overlay right now

The instinct is to panic and rip the widget off your site this afternoon. Resist that for about a day – just long enough to do it in the right order. Here’s the sane sequence:

  1. Capture a baseline. Before you change anything, get a manual WCAG 2.2 AA audit – a human navigating your site with a keyboard and a screen reader, not a script – so you have a documented record of what’s actually broken underneath the overlay. This is the difference between an accessibility overlay and a manual audit: one hides the problems, the other documents them so they can be fixed. It also gives you evidence of good-faith effort if a demand letter is already in your inbox.
  2. Remove the overlay. Once you’ve got that baseline, take the widget down. Don’t keep treating it as protection – the data is clear that it isn’t, and every day it stays up is another day of false comfort, a possible privacy liability (overlays that auto-detect assistive technology can expose a user’s disability status, creating GDPR and CCPA exposure), and one more thing a plaintiff’s attorney can point to. You don’t need a finished remediation plan to pull it; you just need the baseline.
  3. Remediate at the source. Now do the real work: fix the actual HTML, ARIA, and component code your audit flagged. Those fixes are permanent, they work for every assistive technology, and they don’t depend on a script winning a race against a screen reader.

That’s the whole path. Baseline, remove the widget, fix the site for real.

The bigger picture

The reality is that accessibility was never going to have a one-line-of-code answer, because accessibility isn’t a bug to be patched – it’s a quality of how a thing is built. You can’t bolt inclusion on after the fact any more than you can bolt on trustworthiness or good design. The FTC fine didn’t reveal anything the disability community hadn’t been saying loudly since 2020. It just, for once, made it official.

The good news is that the alternative isn’t mysterious or out of reach. It’s the same thing it’s always been: test your site the way disabled people actually use it, fix what’s broken, and verify the fix. That’s not a widget. That’s just doing the work – and it’s the only thing that’s ever actually worked.

Frequently asked questions

Do accessibility overlays make my website ADA compliant?
No. The FTC fined accessiBe $1 million in 2025 specifically for claiming its automated overlay could make sites WCAG-compliant. Overlays modify your page after it loads rather than fixing the underlying code, so they cannot guarantee compliance – and courts have repeatedly declined to treat an installed overlay as proof of it.

Can I still get sued if I have an accessibility widget installed?
Yes. In 2025, businesses running overlays were sued every single month – roughly 1,400 such cases across the year, and EcomBack found nearly 25% of all U.S. web accessibility lawsuits targeted sites that already had a widget installed. It was the same story in 2024. An overlay does not prevent a lawsuit and is not a legal defense.

What’s the difference between an overlay and a manual accessibility audit?
An overlay is automated JavaScript that attempts to patch issues at page load. A manual audit is a human testing your site with assistive technology, documenting real WCAG failures, and giving your developers code-level fixes. The overlay hides problems; the audit resolves them at the source.

Should I remove accessiBe (or another overlay) from my website?
Yes – and you don’t need to wait long to do it. Get a manual WCAG 2.2 AA audit first so you have a documented baseline of what’s broken underneath it, then take the widget down promptly. You don’t need a finished remediation plan to remove it – leaving it up just preserves the false sense of protection and the privacy and legal exposure that come with it. Once it’s off, fix the issues in your actual source code.

Are overlay font-size and contrast controls useful?
Rarely. Users who need larger text or higher contrast almost always already have those controls built into their operating system or browser, and they work across every site – not just yours. The overlay’s version is, at best, redundant.


Running an overlay and not sure what’s actually broken underneath it? Get a real audit – we’ll test your site the way your users do, and tell you the truth.

How much does an accessibility audit really cost?

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.

How does the European Accessibility Act affect me?

If your business sells products or services to consumers in the European Union, the European Accessibility Act (EAA) almost certainly affects you, even if your company is based outside the EU. The law has applied since 28 June 2025, so this is no longer a future deadline: it is the current rulebook.

Here is a plain-language look at what the EAA covers, who it applies to, and what to do next.

What is the European Accessibility Act?

The EAA (Directive (EU) 2019/882) sets common accessibility requirements for a wide range of everyday products and services, so that people with disabilities can use them on an equal basis. Every EU member state has written it into national law, which means the requirements, and the penalties for ignoring them, apply across the entire EU market.

Who does it apply to?

The EAA applies to businesses of any size that sell covered products or provide covered services to EU consumers, wherever the business itself is based. Covered categories include:

  • E-commerce: any website or app selling to EU consumers
  • Consumer banking and financial services
  • Smartphones, computers, and operating systems
  • E-books and e-readers
  • Audiovisual media services, such as streaming platforms and their apps
  • ATMs, payment terminals, ticketing machines, and other self-service terminals
  • Telephone, messaging, and emergency communication services
  • Consumer-facing parts of air, bus, rail, and waterborne transport: websites, apps, and e-ticketing

There is one significant carve-out: microenterprises that provide services (fewer than 10 employees and no more than €2 million in annual turnover) are exempt. The exemption only covers service providers, though. If you manufacture, import, or distribute covered products, size does not take you out of scope.

The deadlines that matter

  • 28 June 2025: the EAA applies to all new products placed on the EU market and all services provided to EU consumers from this date.
  • 28 June 2030: service contracts signed before June 2025 may run unchanged until they expire, but no later than this date.
  • Self-service terminals deployed before June 2025 may stay in service until the end of their economically useful life, up to a maximum of 20 years.

In practice: if your website or app is in scope and not yet accessible, you are already late. The transition periods cover pre-existing contracts and hardware, not websites and apps serving customers today.

What does compliance look like?

For websites and apps, conformity is judged against EN 301 549, the European standard harmonized for the EAA, which for web content maps to WCAG 2.1 Level AA (with WCAG 2.2 the sensible target for new work). The EAA also expects documentation: accessibility information in your terms and conditions, conformity documentation for products, and processes that keep things accessible as they change. A workable plan looks like this:

  1. Audit your product, website, or app against WCAG 2.1 AA and EN 301 549.
  2. Fix what the audit finds, prioritizing blockers for keyboard and screen reader users.
  3. Publish the required accessibility documentation.
  4. Build accessibility checks into your release process so you stay compliant.

Each member state sets its own enforcement and penalties, and several allow substantial fines. Consumers and disability organizations can also file complaints directly with national authorities.

Not sure where you stand?

An accessibility audit will tell you exactly how your product or site measures up against the EAA’s requirements, and our consulting team can turn the findings into a remediation plan that fits your roadmap. If you need formal documentation for procurement, we prepareVPATs and ACRs as well.

Manual vs. automated accessibility testing

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.

What is a VPAT? A plain-English guide for teams that just got asked for one

A VPAT (Voluntary Product Accessibility Template) is a standardized document that reports how well a product conforms to accessibility standards like WCAG and Section 508. When you fill one out, the finished document is called an ACR – an Accessibility Conformance Report. Buyers, especially government agencies, universities, and large enterprises, request VPATs during procurement so they can compare the accessibility of competing products before signing a contract.

If you’re reading this, odds are a deal is sitting in your pipeline waiting on one. That’s how most vendors first encounter the VPAT: not through an accessibility initiative, but through a procurement email with a deadline.

Where the VPAT comes from

The template is published by the Information Technology Industry Council (ITI), and the current version is VPAT 2.5. It comes in four editions, and picking the right one matters:

  • WCAG edition – reports against WCAG only. The most common ask from commercial buyers.
  • Section 508 edition – for selling to US federal agencies, which are legally required to buy accessible technology.
  • EU edition – reports against EN 301 549, the European standard. Increasingly relevant now that the European Accessibility Act is in effect.
  • INT edition – covers all three. The safe choice if you sell internationally.

Inside, the document walks through each accessibility criterion and asks you to rate your product as Supports, Partially Supports, Does Not Support, or Not Applicable – with remarks explaining each rating.

The part vendors get wrong

The “V” stands for Voluntary, and some vendors treat the whole exercise that way: an intern fills in “Supports” down the column, someone slaps a logo on it, and off it goes to procurement.

That’s a mistake, and not just an ethical one. A VPAT is a written conformance claim. If a buyer relies on it and your product turns out to be inaccessible, that document becomes evidence against you – in a contract dispute or an ADA claim. The FTC’s $1 million fine against accessiBe in 2025 made it clear that overstated accessibility claims carry real consequences.

A credible VPAT is backed by actual testing. Not an automated scan – automated tools catch roughly a third of WCAG failures – but manual testing with a keyboard and a screen reader by someone who knows what the criteria mean. Honest “Partially Supports” ratings with specific remarks are more persuasive to procurement reviewers than a suspicious wall of “Supports.” Reviewers read a lot of these. They know what padding looks like.

What a VPAT costs

At Labrador Services, VPAT/ACR documentation runs $750–$1,500 on top of an audit, depending on the edition. The audit is the real work – the VPAT is the structured write-up of what the testing found. Industry-wide, standalone VPAT engagements typically land between $1,500 and $6,000 because the vendor has to do the underlying testing anyway.

If someone offers you a VPAT for $200 with no testing behind it, you’re paying for a liability, not a document.

Frequently asked questions

Is a VPAT legally required?
No. It’s voluntary. But if you sell to US federal agencies, Section 508 requires them to buy accessible technology, and a VPAT is the standard way to demonstrate it. In practice, no VPAT often means no deal.

How long is a VPAT valid?
There’s no official expiration, but buyers expect one that reflects your current product. Re-issue after major releases, or roughly annually.

Can I write my own VPAT?
Yes – the template is free from ITI. The risk isn’t the paperwork, it’s the testing behind it. If your team can competently test against WCAG 2.2 AA, you can self-author. Most teams can’t, which is why third-party ACRs carry more weight in procurement.

What’s the difference between a VPAT and an ACR?
The VPAT is the blank template. The ACR is the completed report. People use “VPAT” for both, and everyone will know what you mean.

Book a call

Pick whichever time zone suits you; the conversation is the same. Both options open Calendly in a new tab.