Quick answer, so you can act on it right away: an accessibility statement is a page on your website that names the accessibility standard you are working toward, explains how you checked your site against it, lists what you already know falls short, and gives people a way to report a barrier. To write one, you gather five pieces of information (your standard and level, how you assessed the site, known limitations, a contact route, and the date), then assemble them in the order a reader and a regulator both expect. This guide walks through every step, shows you the exact wording that keeps you safe, and gets you to a finished, published statement by the end.
We have written and reviewed a lot of these while building accessibility tooling, and the same two mistakes come up over and over: people either claim more than they can back up, or they leave the document so vague it says nothing. Both are avoidable. By the end of this tutorial you will have a statement that is honest, standards-aligned, and genuinely useful to the people who read it. If you would rather not hand-assemble the wording, we will also show you exactly how to produce one in about a minute with our own free tool.
What is an accessibility statement, and why do you need one?
An accessibility statement is a public declaration of intent and effort. It is not a certificate, and it does not prove your site is accessible. What it does is tell a visitor, an auditor, or a regulator four things: which standard you aim to meet, how you assessed yourself against it, what you already know is broken, and how to reach you when they find something you missed.
That last function matters more than people expect. A real feedback route turns a frustrated user into a report instead of a lawsuit. Someone who hits a barrier and can immediately tell you about it is far less likely to escalate than someone who hits the same wall and finds no way to be heard.
There are three reasons to publish one, and they stack. First, in a growing number of places it is legally expected or required, which we cover in detail below. Second, it is the first artifact an auditor or a plaintiff's lawyer looks for, because it signals whether you take the obligation seriously at all. Third, and most overlooked, it is simply good practice: it forces you to actually assess your site, which is where the real accessibility work begins. The statement is the visible output of a process that has value on its own.
Before you write: what you need to gather
A good statement is assembled, not invented. Before you write a word, collect these five inputs, because every sentence in the final document comes from one of them.
The first is your conformance target: the WCAG version and level you are working toward. For almost everyone in 2026 the answer is WCAG 2.1 Level AA, because that is the level most laws name, though WCAG 2.2 is the current W3C recommendation and is worth targeting if you can. Without a named target, every other claim in the document is unmeasurable.
The second is your assessment method: how you actually checked the site. Honest options are self-assessment by your own team, automated testing tools, an external audit by a specialist, or a combination. A reader weighs your claim by the method behind it, so the method is part of the claim. "We ran an automated scan" and "an external specialist audited every template" are very different levels of assurance, and pretending otherwise is how statements lose credibility.
The third is your known limitations: the parts you already know fall short. This is the section most people get wrong by leaving it empty. Counterintuitively, naming your barriers is what makes the whole document trustworthy. A statement with nothing to admit reads as one nobody checked. Write each limitation plainly, and where you can, add why it exists and a workaround, for example that a legacy video player lacks keyboard volume control and you are replacing it next quarter.
The fourth is your contact route: a real address, email, or form a person can use to report a barrier. Under the European Accessibility Act this is not optional decoration; the statement must tell people how to report a problem.
The fifth is the date the statement was prepared. Not when the page was last rebuilt, but when the assessment behind it actually happened. An undated statement tells a reader nothing about whether it still describes the site in front of them.
How to write an accessibility statement, step by step
With those five inputs gathered, here is the assembly process. Follow it in order and you will have a complete, standards-aligned document.
Step 1: State your conformance status honestly
Open with a single sentence naming your target and your honest status against it. WCAG allows exactly three declarations, and choosing the right one is the most important decision in the document. "Fully conformant" means the site meets every criterion at your chosen level with no exceptions, which almost no real site can truthfully claim. "Partially conformant" means most criteria are met with some known exceptions, which is the honest answer for the overwhelming majority of websites. "Non-conformant" means the content does not yet meet the standard.
The safe pattern, and the one the W3C model uses, is to say you aim to conform to a named target rather than that you do. Something like "We aim to conform to WCAG 2.1 Level AA. Citylights WebStore is partially conformant, meaning some parts of the content do not fully meet the standard." That phrasing is defensible because it is a statement of intent and effort, not a certification you would have to prove.
Step 2: Describe how you assessed the site
Follow the status with one or two sentences on your method, using the assessment input you gathered. Name it plainly: self-assessment, automated tooling, external audit, or a combination. If an outside specialist was involved, say so, because it strengthens the claim. If it was a quick internal check, say that too, because overstating it is exactly the kind of documented claim that is easy to disprove later.
Step 3: List your known limitations, with workarounds
This is the credibility engine of the whole document, so give it real content. For each barrier you are aware of, write what it is, and where you can, why it exists and what a user can do in the meantime. A strong example reads like this: "Some PDF documents published before 2024 are not fully tagged for screen readers. We are re-tagging them and can provide an accessible version on request." That single sentence does more for your credibility than three paragraphs of general commitment, because it proves you actually looked.
Step 4: Add your feedback and contact route
State clearly how someone reports a barrier, and set an expectation for response. The W3C example commits to responding within a set number of business days, which is worth copying because it turns a passive address into a promise. Put a real email or form here, monitored by a real person. This is the line that most often prevents a complaint from becoming something worse.
Step 5: Name your technical setup and assistive-technology compatibility
Two shorter additions round out a serious statement. First, name the assistive technologies, browsers, and operating systems you tested with and aim to support, because a conformance claim with no test environment behind it cannot be reproduced by anyone. Second, if you rely on specific technologies such as JavaScript or WAI-ARIA for the site to work, say so, so users can prepare their setup.
Step 6: Date it, and commit to a review cycle
Close with the preparation date and a commitment to review. The date is part of the claim, so state it explicitly, and add that you review the statement at least once a year or whenever the site changes materially. Then keep that promise: update the known-limitations section as you fix things, so the document tracks the live site rather than the day it was first written.
The fastest way: use a free accessibility statement generator
Assembling all six parts by hand is doable, but you do not have to. We built a tool that does the structuring for you, so you can focus on the honest inputs rather than the wording and formatting. You give it your details and it produces a clean, standards-aligned document you can publish immediately. For the reasoning behind each part, see what an accessibility statement should include.
Here is exactly how to use our Free Accessibility Statement Generator. You open the page and fill in one short form: your organisation or site name, your website address, your WCAG version (2.1 or 2.2), and your conformance level (A, AA, or AAA, with AA being the usual answer). You then pick how the site was assessed from the same four honest options above, and you type your known limitations one per line, which is the field that makes your statement credible. You add a contact address for feedback and choose the date prepared.
When you generate, you get the document in three ready-to-use forms. There is a clean HTML fragment that starts at a level-two heading with no classes or inline styles, so it inherits your own site's design when you paste it in. There is a plain-text version with no markup at all, for a CMS or a form that refuses HTML. And there is a downloadable text file named after your organisation, ready to hand to whoever owns the page. One useful detail for the privacy-conscious: the generator runs entirely in your browser, so nothing you type is sent anywhere, stored, or logged.
The tool writes the first six parts of the W3C model for you. The two shorter additions from Step 5, your tested assistive-technology environment and any technologies you rely on, are worth adding by hand afterward, because only you know what you actually tested with.
Where to publish your statement, and how to keep it alive
Writing the statement is most of the work, but two placement details decide whether it does its job.
Give the statement its own page at a stable, predictable URL, conventionally /accessibility, and link it from your site footer on every single page. That is where users look for it, and it is the first place an auditor or regulator checks. Do not bury it inside your privacy policy or your terms of service, because it answers a different question and it needs to be findable by someone who is already having difficulty navigating.
Then treat it as a living document, not a plaque. Review it whenever you ship a material change and at least once a year, and update the known-limitations section as you actually fix things. A statement dated three years ago quietly tells every reader that nobody has checked since, which undermines the trust the document was supposed to build.
Which laws require or expect an accessibility statement?
Whether any specific law binds you depends on your sector, size, and where you operate, and none of this is legal advice. But it helps to know the landscape, because your statement often names the very standard these instruments cite. Our separate guide explains when an accessibility statement is required under the ADA and the EAA.
In the European Union, the European Accessibility Act became enforceable on 28 June 2025 and applies to a broad set of consumer services including e-commerce, banking, and transport. It requires a published accessibility statement that includes how to report a barrier. The older Web Accessibility Directive already requires one from public-sector bodies, following a set model. Both point at the harmonised standard EN 301 549, which incorporates WCAG 2.1 Level AA.
In the United States, the Americans with Disabilities Act is widely applied to digital services, and the Department of Justice's Title II rule sets WCAG 2.1 Level AA for state and local government sites on fixed deadlines. The ADA does not mandate a statement, but publishing one is standard practice and evidence of effort. Section 508 binds federal agencies and their vendors and expects a conformance claim. It is worth being clear-eyed here: in California, the Unruh Civil Rights Act ties ADA violations to statutory damages, which is why so much US web-accessibility litigation is filed there, and a statement is not a defence, though a dated one with a remediation plan is evidence of good-faith effort.
In the UK, the Equality Act 2010 requires reasonable adjustments, and the public-sector accessibility regulations add a mandatory published statement on top. In Canada, Ontario's AODA requires WCAG 2.0 Level AA for designated organisations with periodic compliance reporting that a maintained statement feeds directly.
The honest part: a statement is a claim, not compliance
Here is the thing every good accessibility professional will tell you, and it is the most important paragraph in this guide. Everything in your statement is something you assert about your own site. Writing it does not make your site accessible, and a generator, ours included, cannot check your pages for you: it has never seen them. That is precisely why the correct wording says you aim to conform rather than that you do.
This creates a real risk worth naming. A statement that claims a target your site actually misses is worse than no statement at all, because it is a documented, public claim that is straightforward to disprove. The way to make your statement safe is not softer language. It is to find out where your site genuinely stands, fix what is broken, and write the statement from the result.
That is the natural next step after you publish. If you want to understand why a paper claim alone is thin protection, our analysis of whether accessibility overlays and quick fixes actually shield you from lawsuits makes the point with data, and the broader 2026 accessibility statistics show how common real barriers are. Once you know what to fix, our step-by-step guide to fixing low color contrast, the single most common failure, is a good place to start closing the gap between what your statement claims and what your site delivers.
The best statements are written last, not first: you assess, you fix, and then you describe a site you can actually stand behind. If you want that assessment to be real rather than assumed, you can produce a statement grounded in an actual scan of your pages instead of a blank template. Start by seeing where you stand with a free scan of your site, up to five pages with no account, and when you are ready, the accessibility statement generator turns your honest inputs into a publishable document in about a minute.
The bottom line
An accessibility statement names your standard, explains how you assessed your site, admits what falls short, and tells people how to reach you, all dated and reviewed at least yearly. Write it in six steps: state your conformance status honestly, describe your method, list real limitations with workarounds, give a monitored contact route, name your tested environment, and date it. Publish it at /accessibility, link it in your footer, and keep it current. You can assemble it by hand from the W3C model, or produce it in about a minute with our free generator and add the two technical details by hand. Above all, remember what the document is: an honest claim, not a certificate. Make the claim true by measuring your site and fixing what you find, and the statement stops being a liability and becomes exactly what it should be, proof that you did the work.
Sources
W3C WAI, Developing an Accessibility Statement
W3C WAI, Generate an Accessibility Statement (tool)
W3C WAI, Example of a Complete Accessibility Statement
This guide is educational and reflects Sitejar's point of view. It is not legal advice. For your specific situation, consult a qualified professional.