Audit vs Accessibility Statement: Which One Actually Protects You?

#a11y #webdev

When a small business owner gets their first ADA demand letter or EAA enforcement notice, the panic question is almost always the same: "Don't I just need to put up an accessibility statement and call it a day?"

The short answer is no. The longer answer is that an accessibility audit and an accessibility statement do completely different things, and only one of them tends to hold up when a regulator or a plaintiff's lawyer starts asking pointed questions. This guide explains the difference, what each one is good for, and why most sites benefit from having both.

What an accessibility statement actually is

An accessibility statement is a public document, usually linked from the footer, that tells visitors three things: what conformance level your site claims (WCAG 2.1 AA is the standard floor in 2026), what known issues exist, and how someone can contact you to ask for help or report a barrier.

The European Accessibility Act, EN 301 549, the EU's Web Accessibility Directive, the United Kingdom's PSBAR rules for public bodies, and Section 508 in the United States all expect or require some version of this document. Many ADA settlement agreements also impose one as part of remediation.

A good statement includes:

The name of the standard you target (for example, WCAG 2.1 Level AA)
The current conformance status (full, partial, or non-conformant) with examples of known gaps
A real human contact channel for accessibility complaints, with a commitment to respond within a stated number of business days
The date the statement was last reviewed
A description of the testing approach, including any third-party audit and the assistive technologies tested

A bad statement -- and most are bad -- says something like "We are committed to accessibility and conform to WCAG 2.1 AA" with no contact channel, no date, and no description of what testing was actually done. That kind of statement is worse than no statement at all, because it makes a claim that the site cannot back up.

What an accessibility audit actually is

An audit is the work behind the claim. It is a structured examination of the site against a specific standard, performed either by an internal team using documented methodology or by a third-party expert. The output is typically a report that lists every barrier found, the WCAG success criterion it violates, the severity, and a remediation recommendation.

There are three common kinds in 2026:

Automated scan, run by tools like axe DevTools, WAVE, or Lighthouse. These catch roughly 30 to 40 percent of WCAG issues. They are fast, cheap, and useful for catching regressions, but they cannot evaluate context (whether an alt text is actually accurate, whether a heading hierarchy makes sense, whether a form's error messages are clear).
Manual expert audit, performed by an accessibility specialist who walks through the site using a keyboard, a screen reader (VoiceOver, NVDA, or JAWS), and tools that simulate low vision or color blindness. This is the only kind of audit that catches the 60-plus percent of WCAG that automated tools miss.
User testing with disabled testers, where people who actually use assistive technology in daily life try to complete real tasks on the site. This catches usability problems that pass technical conformance but still fail real users.

A serious audit produces a written report with screenshots, code snippets, the WCAG success criterion each issue violates, and a severity rating. It also includes the methodology -- which pages were tested, which assistive technologies were used, which automated tools were run -- so the report can be reproduced.

Why a statement without an audit is dangerous

Here is the part most small business owners do not realize: when you publish an accessibility statement, you are making a public legal claim about the state of your website. If a regulator or a plaintiff's lawyer can show that the claim is false, you are now in worse legal shape than if you had published nothing.

In the United States, ADA Title III lawsuits often quote the defendant's own accessibility statement back at them. "Defendant's website states it conforms to WCAG 2.1 AA, but plaintiff was unable to complete a checkout because the cart's quantity selector is not keyboard accessible." That sentence appears in real complaints. The plaintiff did not have to prove the site failed; the defendant claimed it passed.

In the EU, the European Accessibility Act and EN 301 549 explicitly require accessibility statements to be accurate. Member-state enforcement bodies (DOS in Germany, DSAA in France, DGT in Italy, ANED in Spain) audit these statements as part of their compliance reviews. A statement that claims full conformance on a site with obvious failures is, in itself, a regulatory violation.

So the rule is simple: do not publish a statement that claims more conformance than your audit can support.

Why an audit without a statement is also a problem

Conversely, there are organizations that have done thorough audits, fixed the issues, and never publish a statement. This is also a mistake, for two reasons.

First, both EAA and Web Accessibility Directive compliance regimes expect a statement. Without one, the audit work does not show up in the compliance review, and the organization gets penalized for documentation gaps that have nothing to do with whether the site is actually accessible.

Second, a statement is what gives users a path to report problems. Even a perfectly audited site has issues that emerge after launch, especially as content is updated. A clear statement with a contact channel turns potential lawsuits into bug reports. Several court rulings in 2024 and 2025 considered whether the defendant offered a "reasonable accommodation channel" -- in most cases, the answer turned on whether there was a working accessibility statement and whether the contact email had been monitored.

What both documents look like together

The right pattern is:

Run an audit (automated, manual, or both, depending on budget).
Fix every critical and serious issue you can.
Publish a statement that honestly describes the current conformance level, including known issues you have not yet fixed and a target date for fixing them.
Re-audit on a fixed schedule (we recommend quarterly for active sites and annually for low-change sites) and update the statement after each audit.

Notice that the statement does not have to claim full conformance. A statement that says "We target WCAG 2.1 AA, conform on most pages, and have known issues on the booking page (target fix: Q3 2026)" is honest, legally defensible, and gives users a clear picture. A statement that claims full conformance when the site has obvious issues is dishonest and legally risky.

What a non-developer can do today

If you are running a small business and reading this, here is the practical version:

Run a free audit yourself. Open your site in Chrome, run a Lighthouse accessibility scan, install the axe DevTools extension and run it on your top five pages, and tab through your site with the keyboard. Write down every issue you find.
Publish a draft statement. Use a template that includes the name of the standard you target (WCAG 2.1 AA is the right floor in 2026), what tests you ran, what issues are known, when you last checked, and a real email address for accessibility complaints. Keep it honest -- "partial conformance, with known issues being addressed" is a fine claim.
Hire a manual audit when you can afford it. Automated scans miss the issues most likely to trigger lawsuits or regulatory action. A few hundred dollars on a manual audit, even of just your highest-traffic pages, is the cheapest insurance you will buy.
Treat the statement as a living document. Update it after every site redesign, every audit, and every batch of remediation. Date it. The single most powerful thing you can do, legally, is show that you took accessibility seriously over time and kept the statement aligned with reality.