Last updated on

Accessibility Statement vs Audit: Which Protects You?

When a small business owner gets their first ADA demand letter, 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, and the reason is worth understanding before you publish anything. A statement is a public claim about the state of your website. An audit is the evidence that the claim is true. Publishing the claim without the evidence does not just fail to protect you — it hands the other side a written admission to measure your site against. This guide covers what each document actually is, why the order matters, and what to do first if you have neither. (Nothing here is legal advice.)

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:

  1. Automated scan, run by tools like axe DevTools, WAVE, or Lighthouse. The commonly cited estimate is that these catch something like a third of WCAG issues; treat that as a rough industry figure rather than a measured one, because it depends heavily on the site. 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).

  2. 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 reaches the majority of WCAG that automated tools cannot evaluate at all — anything requiring a judgement about whether something is correct rather than merely present.

  3. 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.

The mechanism is straightforward. A statement claiming “this site conforms to WCAG 2.1 AA” is a documented assertion by you about your own site. Anyone alleging otherwise no longer has to establish what standard applies or what you were aiming at — you supplied both. All that is left to show is a single failure against the level you named, and a keyboard-inaccessible checkout control is not a hard thing to demonstrate.

In the EU, the European Accessibility Act and EN 301 549 expect accessibility statements to be accurate, and member-state market-surveillance authorities can review them. Enforcement structures vary by country and we are not going to list authorities we cannot verify are the right ones for your case. The principle holds regardless: a statement claiming full conformance on a site with obvious failures is a problem in its own right, separate from the failures.

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 monitored contact channel turns a potential complaint into a bug report — the person who cannot check out has somewhere to go that is not a lawyer. That is a practical argument, not a legal one, and we are not going to dress it up as case law we have not read.

What both documents look like together

The right pattern is:

  1. Run an audit (automated, manual, or both, depending on budget).
  2. Fix every critical and serious issue you can.
  3. 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.
  4. 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:

  1. 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.

  2. 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.

  3. Get a manual audit when you can. Automated scans miss the issues most likely to trigger a complaint, because those issues live in flows — checkout, booking, contact — rather than in markup a scanner can grade. A manual pass over just your highest-traffic pages is worth more than a full-site automated scan.

  4. 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.

Want to know what is actually broken on your site? Get an accessibility report.