An accessibility statement and an accessibility audit are not two versions of the same thing, and neither one proves what people usually hope it proves. An audit is an inspection: someone or something examined specific pages on a specific date and recorded what was found. It proves that those pages were looked at and what state they were in at that moment. A statement is a public declaration: it tells visitors and regulators what standard you aim for, how you checked, what you know is broken and how to reach you. It proves that you made a claim and gave people a way to hold you to it. Put plainly, the audit is evidence and the statement is a claim about that evidence. Neither one, alone, proves a site is accessible, and neither one is a legal guarantee. The honest answer to "which one do I need" is both, in the right order, with the second written from the first.
We get asked this constantly, usually by an agency that has been told by a client to "make us compliant" and by a buyer who has been handed a glossy PDF and a footer link and wants to know whether that means they are safe. It does not, in either direction, and the confusion costs people money. It is also more common than it should be: when we benchmarked the front pages of 57 web agencies, every one of them had at least one accessibility finding, and 20 of the 57 had no accessibility statement link at all. A statement without an audit behind it is a claim nobody checked. An audit without a statement is evidence nobody can find. And both together, done once and never revisited, describe a site that no longer exists. This article pulls the two apart: what each one is for, what evidence each produces, how far each reaches, where each stops, and the loop that turns them into something that actually holds up.
What is an accessibility audit, and what does it prove?
An accessibility audit is an evaluation of a defined set of pages or screens against a named standard, almost always WCAG 2.1 or 2.2 at level AA, carried out on a known date using a described method. The method is the important part, because it decides what the audit can see. Automated testing reads the rendered page and checks the rules a machine can decide: missing alternative text, text that fails the contrast ratio, form fields without labels, invalid ARIA, headings out of order. Manual testing adds what a machine cannot judge: whether a keyboard user can complete the checkout, whether a screen reader user can make sense of the headings, whether an alt text that technically exists actually describes the image. A full audit uses both.
What an audit proves is narrow and solid. It proves that these pages, on this date, examined this way, had these findings. That is bounded, which is its strength. A finding in an audit is a fact about the site that someone can go and verify. "The newsletter signup on the homepage has no visible label, failing 3.3.2" is not an opinion; it is a reproducible observation with a location and a criterion attached.
What an audit does not prove is just as important. It does not prove the pages it did not look at are fine. A twenty-page audit of a five-hundred-page site says nothing about the other four hundred and eighty. It does not prove the site is accessible, even on the audited pages, because automated checks catch a fraction of real barriers and even careful manual testing is a sample of what a human tester tried. And it does not prove anything about next week. The moment a template is edited or a new component ships, the audit describes a site that has changed. An audit is a photograph. It is accurate, dated, and already aging.
What is an accessibility statement, and what does it prove?
An accessibility statement is the public page, conventionally at /accessibility and linked from every footer, that tells a visitor four things: the standard you are working toward and at what level, how you assessed the site, what you already know falls short, and how to report a barrier. It carries a date, and a good one names the assistive technologies and browsers it was tested with. If you want the structure laid out part by part with the wording that keeps it defensible, our step-by-step guide to writing an accessibility statement walks through assembling each section.
What a statement proves is also narrow, and different. It proves you made a claim, in public, on a date. It proves you told people what standard you aim for and gave them a route to complain before they reach a lawyer. Under the EU's Accessibility Act, that public declaration is required; under the ADA in the United States it is not, but courts and regulators treat a dated, honest statement as evidence of good-faith effort. The jurisdiction-by-jurisdiction picture is in our piece on whether accessibility statements are legally required, so here the point is only this: the statement's value is that it exists, is findable, is dated, and is true.
What a statement does not prove is that your site is accessible. It cannot, because it is a declaration, not an inspection. Nobody verified it on the way out. This is where the W3C is unusually direct: in WCAG 2.1's conformance section, conformance claims are explicitly optional, and a site can conform without ever publishing one. The claim changes nothing about the site. It only changes what you have asserted. And an assertion you cannot back is not neutral; in a dispute it becomes the first thing quoted back at you.
Statement versus audit: evidence, scope and reach, side by side
The clearest way to see the difference is to ask the same four questions of each.
On purpose: an audit exists to find barriers so they can be fixed. A statement exists to tell the public what you aim for, what you know, and how to reach you. One looks inward at the code; the other faces outward at the visitor and the regulator.
On evidence: an audit produces findings, each one a location, a criterion and an observation that someone else can reproduce. A statement produces a claim, which is only as strong as whatever evidence sits behind it. A statement that says "partially conformant, assessed by automated testing and manual review on 14 September, known limitations listed below" is backed by an audit. A statement that says "we are committed to accessibility" is backed by nothing.
On scope: an audit covers exactly the pages it examined and no more. A statement, by convention, covers a whole site, which is precisely why it can overreach. A conformance claim, in the W3C's own framing, asserts something about every page in scope, all or nothing, and is undermined by a single failure anywhere in that scope. A sampled audit cannot support that kind of claim. It can support a bounded one: these pages, this date, this method, these findings.
On reach in time: an audit is a snapshot and says so. A statement is a standing public page that people will read next month and next year, long after the audit that informed it has gone stale. That gap is the single most common way an honest statement becomes a dishonest one: not through any lie, just through nobody updating it.
The practical conclusion is that the two are not substitutes and not competitors. The audit supplies the facts. The statement publishes an honest summary of those facts. A statement written without an audit is guessing. An audit that never becomes a statement is evidence in a drawer.
Why neither one is a legal guarantee
Here is the thing both the agency and the buyer most need to hear: no document makes you safe. Accessibility law, in the US and the EU alike, is about whether the site works for people with disabilities, not about whether a PDF exists or a footer link is present. A plaintiff's tester does not read your statement and go home. They open your checkout with a screen reader. An EU market-surveillance authority does not accept a statement as proof; the statement tells them where to look.
So a statement can help you, as a dated record of effort and as a channel that lets a user report a barrier before escalating, and it can hurt you, if it claims a conformance level the site does not meet. An audit can help you, as the factual basis for fixes and for an honest statement, and it can hurt you, if it sits unactioned, because an audit that found forty barriers and a site that still has forty barriers is evidence that you knew and did nothing. Overclaiming is the fastest way to turn either document into a liability. Our analysis of what accessibility overlays actually prove in court is really a case study of the same principle: a confident public promise, unsupported by the underlying site, ages badly in front of a regulator.
None of this is legal advice, and for a specific site the question of what your obligations are belongs with a qualified attorney. What we can say from experience is that the documents that hold up are the ones that under-claim and over-deliver: a statement that honestly says "partially conformant," lists real known limitations, and sits on top of a site that is visibly being fixed.
What a scanner can and cannot contribute
Most teams start the audit with an automated scan, and that is the right first step as long as you know what you are holding. A scan is fast, repeatable, and covers every page rather than a hand-picked sample, which makes it the best tool for finding the high-volume, machine-detectable failures that make up most of the barriers on a typical site: contrast, labels, alt text, accessible names, structure. On our own benchmark of 57 agency front pages, every single one had at least one such finding, and low contrast alone appeared on 45 of them.
What a scan cannot do is finish the audit. Automated checks catch a portion of real issues and are blind to the rest: keyboard traps, focus order, whether a heading structure makes sense to a screen reader user, whether alt text that exists says anything useful. A perfect automated score is a floor, not a verdict, which is the whole argument of our piece on why a Lighthouse score of 100 is not WCAG compliance. So the scan's job in the audit is to clear the volume quickly and point a human at the judgement calls. It is also, not incidentally, the part of the audit that can run every week, which matters for the loop below.
One way to see what a scan's output honestly looks like, including its confidence labels and what it leaves for a person to decide, is our own public compliance report, where we scan our own site in the open and publish the result rather than describe it. A finding there carries a location, a criterion, a confidence level and a proposed fix. That is the shape of evidence an audit should hand to a statement.
The workflow: find, fix, then update the statement
The reason to be precise about what each document proves is that it tells you the order to do things in. Here is the loop that works, and the reason each step comes where it does.
First, find. Run an assessment of the site's actual state before writing a word of the statement. Start with a scan across the real pages so the machine-detectable failures are listed with locations, then add manual testing on the flows that matter most: sign-up, checkout, search, the core forms. Operate them with a keyboard and listen to them with a screen reader. Record what you find, including the things the scanner flagged for human review. If you want a compact version of what to check, our ADA website compliance checklist is built around exactly that pass. At the end of this step you have findings: dated, located, reproducible. That is your audit.
Second, fix. Correct the barriers at the source, in the templates and shared components, so one fix propagates everywhere the component is used. Prioritise by impact and by volume: the failures that block a task outright, and the failures that repeat across every page. Every barrier fixed here is one fewer line you have to write in the statement's known-limitations section, which is the most concrete argument for fixing before publishing. A statement written after a round of fixes is a better document than one written before, and not because the wording improved.
Third, write or update the statement from what remains. Now the inputs are true. The assessment method is the method you actually used. The known limitations are the barriers you actually found and have not yet fixed, with a workaround where you have one and a timeline where you can commit to one. The date is the date of the assessment. A generator is useful here for getting the W3C structure and the conformance wording right, and our free accessibility statement generator does that from a short form, in the browser, storing nothing you type. Treat its output as a draft assembled from your findings, not as a verdict on your site, because it has never seen your site.
Fourth, repeat. This is the step that separates a document that holds up from one that quietly rots. The site changes with every deploy, so re-run the scan on a schedule, re-test the key flows after any material change, fix what reappears, and update the statement's limitations and date each time. The statement should track the site, not the day it was first written. A dated statement with a visible history of updates is the strongest form of the document there is, because it proves the one thing a single audit never can: that someone is still looking.
Who is responsible for each one?
For an agency, the division of labour is usually clear once the documents are. The agency owns the audit's execution and the fixes: it runs the assessment, interprets the findings, and changes the code. It can draft the statement, but the statement is the client's public claim, made in the client's name, so the client should read it, understand what it asserts, and approve it. A statement the client has never read is a claim they cannot defend.
For a buyer evaluating an agency's work, the questions to ask map directly onto the two documents. Of the audit: which pages were examined, on what date, by what method, and where are the findings? Of the statement: what conformance level does it claim, is that level consistent with the audit's findings, does it list real limitations, and when was it last updated? An agency that can answer all of those has done the work. One that offers a statement with no audit behind it, or an audit with no plan to publish and maintain a statement, has done half.
Frequently asked questions
Is an accessibility statement the same as an accessibility audit?
No. An audit is an inspection of specific pages on a specific date that produces findings. A statement is a public declaration of the standard you aim for, how you assessed the site, what you know is broken and how to reach you. The audit is evidence; the statement is a claim that should be written from that evidence.
Do I need an audit before I write an accessibility statement?
In practice, yes. The statement has to say how the site was assessed and what the known limitations are, and you cannot fill those in truthfully without having done some assessment. A statement written with no audit behind it is a guess, and a guess that overclaims is a liability.
Does an accessibility audit make my site compliant?
No. An audit finds barriers; fixing them is a separate step, and even a fixed site is only as accessible as its next deploy. An audit that is never acted on can become evidence that you knew about barriers and left them, so the audit is the start of the work, not the end.
Does an accessibility statement protect me from a lawsuit?
Not by itself. A truthful, dated statement is treated as evidence of good-faith effort and gives users a way to report a barrier before escalating, but accessibility law is about whether the site works, not whether a document exists. A statement that overclaims can be quoted back at you. This is not legal advice; a qualified attorney can speak to your specific exposure.
Can an automated scan replace a manual audit?
No. A scan covers every page quickly and finds the high-volume, machine-detectable failures, which makes it the right first step and the right thing to repeat on a schedule. It cannot judge keyboard operability, focus order, meaningful alt text or coherent structure. Those need a human. A good audit uses both.
How often should the statement be updated?
Whenever the site changes materially and at least once a year, with the date refreshed each time and the known limitations updated to reflect what has been fixed and what has been found. A statement with a visible update history is stronger than any single audit, because it shows someone is still looking.
What should a statement say about conformance?
That you aim to conform to a named standard and level, and your honest status against it. For almost every real site that is "partially conformant," with the exceptions listed. Claiming full conformance is only defensible if every applicable criterion is met on every page in scope, which a sampled audit cannot establish.
The bottom line
An accessibility audit proves what specific pages looked like on a specific date, examined a specific way. An accessibility statement proves that you made a public claim, dated it, and gave people a way to hold you to it. Neither proves the site is accessible and neither is a legal guarantee, and treating either as one is how a well-meaning team ends up holding a document that works against them. The two are not rivals; they are the input and the output of a single loop. Find the barriers with a scan and a manual pass. Fix them at the source. Write the statement from what is actually left. Then keep looking, because the site will change and the statement has to follow. If you have not started, the first step is simply to collect findings you can review: run a scan, read what it surfaces, and let that be the audit your statement is built on rather than a template you hope is true.
Sources
W3C, Web Content Accessibility Guidelines (WCAG) 2.1, Section 5: Conformance
W3C WAI, Understanding Conformance
W3C WAI, Developing an Accessibility Statement
Sitejar, How Web Agency Front Pages Really Perform: A Six-Dimension Benchmark of 57 Sites
This article is educational and reflects Sitejar's point of view. It is not legal advice. For your specific situation, consult a qualified attorney.