A good accessibility statement generator should produce a document with five things in it: the accessibility standard you are targeting and at which level, how you assessed your site against it, the barriers you already know about, a real way for people to contact you, and the date the statement was prepared. Anything that skips one of those is not a statement, it is a disclaimer. And one thing a generator should never do is tell you that your site is compliant, because it has never seen your site. A generator writes a draft from what you type into it. It does not certify anything, and the wording it produces should say so. This article explains what each of those parts is for, how to tell a good generator from a bad one, and how to make sure the draft you get is one you can actually stand behind.
We built one of these tools and we have read a lot of statements written by others, so this comes from both sides of the form. The pattern we see most is not a missing statement. It is a statement that says too much: "fully compliant with WCAG 2.1 AA," on a site that a five-minute check would contradict. That sentence is not a shield. It is a claim, and it is the easiest claim on the internet to disprove. So the question is not just which generator to use but what it should refuse to let you say.
What is an accessibility statement generator, and what is it not?
An accessibility statement generator is a form that turns a handful of inputs into a publishable page: a conformance target, an assessment method, known limitations, a contact route and a date. You fill in the fields, and it assembles them into the structure that the W3C's model recommends and that regulators expect, usually as HTML you can paste and plain text you can drop into a CMS.
What it is not is an audit. A generator has no idea what is on your pages. It cannot see a form with no label, a button with no accessible name, or body text that fails the contrast ratio. It writes exactly what you tell it, formatted well. That is useful, because assembling the structure by hand is fiddly and easy to get subtly wrong, but it means the honesty of the output depends entirely on the honesty of the inputs. A generator with a clean design and a confident tone can still produce a document that misrepresents your site if you type in a target you do not meet.
This is why the wording matters more than the layout. A generator built on the W3C model produces a sentence like "we aim to conform to WCAG 2.1 at level AA," which is a statement of intent you can defend. A generator that produces "this website is WCAG 2.1 AA compliant" has written a certification on your behalf, with no evidence, and you are the one who will have to answer for it.
What should an accessibility statement include?
There are five parts every statement needs, and a good generator asks for each one. Two more are worth adding by hand.
The first is a named conformance target. This is the standard and the level: WCAG 2.1 or 2.2, at level A, AA or AAA. For almost every site in 2026 the answer is WCAG 2.1 at level AA, because that is the level most laws name, though 2.2 is the current W3C recommendation and is a reasonable target if you can meet it. Without a named target, every other sentence in the statement is unmeasurable. "We are committed to accessibility" means nothing; "we aim to conform to WCAG 2.1 AA" is a claim someone can check.
The second is the assessment method. A statement should say how you checked the site: a self-assessment by your own team, automated testing tools, an audit by an external specialist, or a combination of automated testing and manual review. A reader weighs your claim by the method behind it. "We ran a scanner" and "an external specialist audited every template" are different levels of assurance, and pretending otherwise is how statements lose credibility. A good generator makes this a required field and puts it in the output, because it is part of the claim, not a footnote to it.
The third is known limitations, and this is the section most people leave empty. That is a mistake, and a good generator should make it feel like one. Naming what you know falls short is what makes the rest of the document believable. A statement with nothing to admit reads as one nobody checked. "Some older PDF documents are not fully tagged for screen readers" and "video published before 2024 has no captions" are the kind of lines that tell a reader you actually looked. If you have a scan or an audit, this section is where its findings go, in plain language, with what you are doing about them.
The fourth is a real feedback route. An address a person can write to when they hit a barrier. Under the European Accessibility Act this is required, not decorative: the statement has to tell people how to report a problem. It also does something practical for you. Someone who hits a barrier and can tell you about it directly is far less likely to tell a lawyer instead.
The fifth is the date it was prepared. Not when the page was last rebuilt, when the assessment behind it happened. An undated statement tells a reader nothing about whether it still describes the site in front of them, and a statement dated three years ago tells them nobody has checked since.
Two parts a generator usually cannot write for you, because only you know the answer, are the assistive technologies you tested with (the screen readers, browsers and operating systems you aim to support) and the scope the statement covers (which site, and which parts of it). Both are worth adding by hand. A conformance claim with no test environment behind it cannot be reproduced by anyone, and a statement that quietly covers the marketing pages while a visitor is stuck in the checkout is worse than none.
How do I tell a good accessibility statement generator from a bad one?
The quickest test is to read the sentence the tool writes about conformance. If it says you aim to conform, or that you are partially conformant, it is following the W3C model and producing a claim you can defend. If it says you are compliant, it has overclaimed on your behalf, and the whole document is now a liability rather than an asset.
A few other things separate the good ones. A good generator asks for the assessment method and puts it in the output rather than leaving you to sound more thorough than you were. It asks for known limitations and, ideally, nudges you to fill them in. It asks for a date and a contact route as required fields. It produces output that inherits your own site's design instead of forcing its own styling, which usually means clean HTML starting at a heading with no classes or inline styles. It gives you a plain-text version too, for the CMS or the form that refuses markup. And it is clear about what it is: a draft from your inputs, not an assessment of your site.
Privacy is worth a look as well, because some of these forms collect the details you type. Our own tool is built to run entirely in the browser, so nothing typed into the form is sent, stored or logged, and that is the behaviour we would look for in any generator that asks for an organisation name and a contact address.
If you want a worked example of what the output should look like, section by section, our step-by-step guide to writing an accessibility statement walks through assembling each part and shows the wording that keeps the document defensible. It is written for people doing it by hand, but it is also a good checklist to hold any generator's output against.
What should the conformance wording actually say?
This is the sentence that decides whether your statement helps you or hurts you, so it deserves its own section. WCAG allows three conformance declarations: fully conformant, partially conformant, and non-conformant. Fully conformant means every applicable criterion at your chosen level is met with no exceptions, which almost no real site can truthfully claim. Partially conformant means most criteria are met with 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 state a target and an honest status. "We aim to conform to WCAG 2.1 at level AA. This site is partially conformant, meaning some parts of the content do not fully meet the standard." That is defensible because it is a statement of intent and effort. It says what you are working toward and admits you are not all the way there, which is true of nearly everyone. A good generator defaults to this wording, and the output from ours is explicit that it is a statement of intent, not a certification.
Whether you are legally required to publish a statement at all depends on where your customers are. It is mandatory under the EU's Accessibility Act, enforceable since June 2025, and treated as good-faith evidence rather than a requirement under the ADA in the United States. We covered the jurisdiction-by-jurisdiction picture, including Section 508 and Canada's AODA, in our article on whether accessibility statements are legally required, and that piece also explains why an overclaiming statement can be turned against you. The short version is the same as here: the statement helps you only if it is true.
Why a generator is a draft, not a certificate
Everything a generator writes is something you asserted. Nobody checked it on the way out, and the tool cannot check it, because it has never loaded a single one of your pages. That is the whole reason its wording should say you aim to conform rather than that you do.
It helps to be concrete about what the tool does not know. It does not know that your contact form's fields have no labels. It does not know that the light grey caption text under every image fails the 4.5:1 contrast ratio, which is the single most common accessibility failure on the web and, on our own scan of 57 professional agency front pages, present on 45 of them. It does not know that the carousel cannot be operated from a keyboard. It knows the organisation name, the target, the method you claimed, the limitations you chose to admit, an email address and a date. If those inputs are accurate, the output is an honest draft. If you typed "combination of automated testing and manual review" when you ran nothing, the output is a lie in a nice font.
This is also why "our scanner gave us a perfect score" is not a basis for a stronger claim. Automated tools, ours included, catch a portion of real accessibility issues and structurally cannot see the rest: keyboard traps, alt text that exists but says nothing, headings that are technically valid but incoherent to a screen reader user. A clean automated result is a floor, not a certificate, and we wrote about that distinction at length in our piece on why a Lighthouse accessibility score of 100 is not WCAG compliance. A statement built on an automated scan should say "automated testing tools" as its method, and its known limitations should reflect what such tools miss.
There is a stronger version of the document, and it is worth knowing the difference. A statement built from a real scan of your site, where the assessment date is the actual date, the pages counted are the pages that were read, and the known limitations are the barriers that were actually found, is a different kind of claim. Every sentence in it is one you measured rather than one you asserted. That is the version worth working toward, and the way to get there is not softer wording in the generator. It is finding out where your site actually stands, fixing what is broken, and then writing the statement from the result.
How to use a generator so the result is honest
Here is the order of operations we would recommend, and it starts before you open the form.
First, find out where you actually stand. Run a scan of your site, or an audit if the stakes warrant it, before you write a word of the statement. You cannot fill in the assessment method or the known limitations truthfully without having done some assessment. If you have not, the honest method is "self-assessment by our own team" and the honest limitations section is going to be thin, and that is fine as a starting point as long as it is true.
Second, fix the obvious things. The most common failures, low contrast text, missing form labels, missing alt text, buttons and links with no accessible name, are usually cheap to correct at the source, and every one you fix is one fewer line you have to write in the limitations section. A statement written after a round of fixes is a better statement than one written before.
Third, fill in the generator with what is true. Pick the target you are genuinely working toward, choose the assessment method you actually used, and list the limitations you actually know about in plain language. Our free accessibility statement generator asks for exactly these inputs and writes the W3C model around them, with output as paste-ready HTML, plain text or a downloadable file, and nothing you type leaves your browser. The point of the tool is to get the structure and the wording right so you can spend your attention on the inputs.
Fourth, add the two parts by hand: the assistive technologies and browsers you tested with, and the scope the statement covers. Then give the statement its own page at a stable URL, conventionally /accessibility, and link it from your footer on every page. Do not bury it in your privacy policy.
Fifth, keep it current. Review it whenever the site changes materially and at least once a year, and update the known limitations as you fix things. The statement should track the site, not the day it was written.
Frequently asked questions
What should an accessibility statement include?
A named conformance target (the WCAG version and level), how the site was assessed, the known limitations, a real contact route for reporting barriers, and the date it was prepared. Adding the assistive technologies you tested with and the scope the statement covers makes it stronger.
Is an accessibility statement generator enough to make my site compliant?
No. A generator writes a document from what you type; it does not read your pages or find barriers. It produces a draft of a claim, not a certificate. Compliance comes from the site itself meeting the standard, which is a separate job the generator cannot do.
Can I say my site is WCAG compliant in the statement?
Only if you can back it, and an automated tool alone cannot. Large parts of WCAG need human judgement, including testing with assistive technology. The defensible wording is that you aim to conform to a named target and are partially conformant, with the exceptions listed.
Should I leave the known limitations section blank?
No. Naming what falls short is what makes the rest of the statement credible. A statement with nothing to admit reads as one nobody checked, and in a dispute an empty limitations section next to a real barrier looks like concealment rather than confidence.
Which conformance level should I choose?
WCAG 2.1 at level AA for most sites, because that is the level most accessibility laws name. Level A is the minimum and rarely enough; level AAA is the highest and is rarely met in full. WCAG 2.2 AA is a reasonable target if you can meet it.
Where should I put the statement on my site?
On a page of its own at a stable URL, usually /accessibility, linked from the footer on every page. It should be findable by someone who is already having difficulty navigating, which is why it does not belong inside your privacy policy or terms.
How often should I update it?
Whenever the site changes materially, and at least once a year. Refresh the date each time and update the known limitations as you fix things, so the document describes the current site.
The bottom line
A good accessibility statement generator gives you five things in the right structure: a named conformance target, your assessment method, your known limitations, a contact route and a date, written to the W3C model so the conformance claim says you aim to conform rather than that you do. The two things it should never give you are a certificate and a claim you cannot back, because it has never seen your site and cannot vouch for it. Use it in the right order: find out where your site actually stands, fix the cheap and obvious failures, then fill in the form with what is true and add the tested environment and scope by hand. Treat the output as a draft that describes your site honestly today, publish it where people can find it, and keep it current. A statement built that way is not a liability waiting to be disproved. It is a record of the work you actually did.
Sources
W3C WAI, Developing an Accessibility Statement
W3C, Web Content Accessibility Guidelines (WCAG) 2.1
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.