Our website failed an accessibility audit. What happens now?

A failed accessibility audit does not trigger a fine or a lawsuit by itself. It means someone tested your site against a standard, usually WCAG 2.1 or 2.2 at Level AA, and found places where people with disabilities cannot use it. What happens next is up to you: sort the findings by how badly they block people, fix the underlying code, retest, and keep a written record of the work.

This is general information, not legal advice. If the audit arrived alongside a demand letter or a complaint, speak to a lawyer before you reply to anyone.

What does "failed" actually mean?

Almost every audit measures a site against the Web Content Accessibility Guidelines (WCAG), published by the W3C. Under WCAG's conformance requirements, a page meets Level AA only if it satisfies every Level A and Level AA success criterion. One missing form label on the checkout page is enough for that page to fail.

So "failed" is a strict word. A site with forty problems and a site with four both fail. The number and the kind of problems matter far more than the headline result, and a good report will say which ones stop someone from finishing a task and which ones are irritations.

Who else will see the report?

That depends on who asked for it. An audit you commissioned yourself is your document. An audit requested by a customer's procurement team, a partner, or a plaintiff's lawyer is already in someone else's hands, and they will expect to see progress.

If a lawyer's letter is involved, let your own counsel handle the reply. Everything below still applies to the technical side.

Could we be fined or sued?

It depends on where you operate and who you serve.

In the United States, the Department of Justice says that businesses open to the public must make their websites accessible under Title III of the ADA, while giving them flexibility in how they do it. There is no Title III regulation naming a WCAG version. Private lawsuits are common. UsableNet, which tracks these cases, counted more than 5,000 digital accessibility lawsuits in US federal and state courts in 2025 in its year-end report, and 1,427 of them were against companies that had been sued before.

State and local governments in the US have a specific rule. It requires WCAG 2.1 Level AA, and an April 2026 interim final rule moved the compliance dates to April 26, 2027 for entities serving 50,000 people or more and April 26, 2028 for smaller ones and special districts.

In the European Union, the European Accessibility Act has applied to e-commerce and several other consumer services since 28 June 2025. Each member state sets its own penalties. Germany's implementing law, for example, allows fines of up to 100,000 euros for the most serious breaches.

How do we read the findings?

Start by grouping them. Audit reports are often long because the same problem shows up on every page. A missing label in a site-wide search box might appear two hundred times in an automated export and needs one fix in one template.

Useful groupings:

By template or component. Header, footer, navigation, product card, form fields. A fix here repairs every page that uses it.
By user journey. Can someone using only a keyboard, or a screen reader, find a product, add it to the cart and pay? Can they send the contact form? Journeys that earn money or generate leads go first.
By severity. Many auditors rate each issue, for example as blocking, serious or minor. If yours did not, ask them to.

Also check what method the audit used. The W3C notes that evaluation tools cannot determine accessibility on their own, and that human judgement is required. A report produced only by a scanner will miss keyboard traps, confusing focus order and unclear link text, and it may flag things that are fine. If you received a scanner export, a manual review of your key pages is worth adding before you plan the work.

What should we fix first?

A sensible order for most sites:

Anything that stops a task outright on a key journey. Keyboard traps, buttons that cannot be reached without a mouse, forms with no labels, error messages a screen reader cannot hear, captchas with no alternative.
Shared components and templates, because each fix clears many findings at once.
Colour contrast, heading structure and link text across the site.
Content: image descriptions, captions on video, PDFs.

Fix the problems in the site's own code and content. Third-party widgets that sit on top of a page do not change the underlying markup. In January 2025 the US Federal Trade Commission announced a $1 million settlement with one such vendor over claims that its tool could make any website WCAG-compliant.

How long will it take, and what will it cost?

That depends entirely on the findings, the platform and who built the site. A WordPress or Webflow site built on a sound theme may need mostly template work. A site with a custom checkout, heavy scripting and years of uploaded PDFs can take much longer. Ask whoever quotes the work to price it against the actual report, grouped the way described above, so you can see what each part costs.

If you want a rough first look before commissioning anything, GladLoop has a free page check that reads a page's HTML and explains each problem in plain language. Like any automated scan, it cannot see keyboard behaviour or colour contrast.

What do we do once the fixes are in?

Retest the same pages with the same method, ideally with the same auditor, so the before and after can be compared. The W3C's evaluation methodology, WCAG-EM, describes how to define the scope, pick a representative sample of pages and report results. It is a good reference when you agree the scope of a retest.

Then publish an accessibility statement. The W3C recommends that it include your commitment, the standard you target (for example WCAG 2.2) and a way for people to report problems, and it offers a free generator. Keep the audit, the fix log and the retest together. If anyone questions your site later, a dated record of real work carries weight.

Finally, build the checks into how the site is maintained. New pages, new plugins and new campaigns bring new problems, and one audit covers the site as it was on the day it was tested.

Questions people also ask

Do we need to take the website offline until it is fixed?

Usually no. Taking a site down removes it for everyone, including disabled visitors who could use most of it. Keep it live, fix the blocking issues first, and offer an alternative channel such as phone or email in the meantime.

If we fix everything in the report, are we protected from lawsuits?

No fix guarantees that. It does reduce the barriers a complaint would point to, and a documented record of remediation helps in any dispute. UsableNet's 2025 figures show that companies sued once are often sued again, which is a good reason to finish the work properly.

Can our own team do the fixes?

Content fixes such as alt text, headings and link wording are often within reach of whoever edits the site. Template, form and scripting fixes need a developer who knows WCAG. Either way, have someone independent retest the result.

How often should we audit the site?

Retest after any redesign, platform change or new checkout or sign-up flow. Many organisations also run a lighter review every year, with automated checks running between audits.