How to Add an Accessibility Statement to Your Site

An accessibility statement is a short page that tells visitors what you have done about accessibility, what you know is still a problem, and how to reach you when something does not work. It is not a legal shield, and it is not a marketing page. It is a contact point and a record. A good statement is short, dated, and honest about its limits. A bad statement claims more than the site behind it can show, and that gap is what gets a statement quoted back at its owner.

Start with what you actually tested

Before writing a word, gather the facts the statement will state: which pages were tested, against which standard and level, on what date, with which tools, and by whom. A statement that names WCAG 2.2 AA, a test date, and a set of pages can be checked. A statement that says only "accessible" cannot. The W3C's own evaluation method, WCAG-EM, follows the same shape: define the scope, select a sample of pages, evaluate the sample, and report the findings. Use that shape for your statement, even if your testing was a scan plus a keyboard check rather than a full evaluation.

Run a scan first if you have not run one recently. Axeazy's free scan runs in 60 seconds with no signup and no card, and the scan on the homepage covers the page you enter. A scan plus a keyboard check of your homepage and contact form gives you enough to write an honest first statement: what was checked, what was found, and what was fixed. The United States Department of Justice guidance says automated checkers can help, but a clean report does not mean everything is accessible, so pair a manual check with automated checks, and say in the statement that you did both.

The five sections every statement needs

First, scope: which website or part of a website the statement covers, named plainly. Second, standard and level: the version and level you tested against, such as WCAG 2.2 AA, with the test date. Third, status, scoped to the site and the date: what the testing found, in plain words, rather than an absolute claim about the whole site for all time. Fourth, known limitations: the barriers you already know about, described so a visitor can recognise them, with workarounds where one exists, such as an alternative way to complete a form or read a document. Fifth, feedback: a way to report a problem, naming who receives it and how quickly you aim to reply, plus a way to request content in another format.

The W3C Accessibility Statement Generator walks through these sections as questions: site and organisation details, the standard and level, the status, known limitations, and a feedback mechanism. Use it as a worksheet even if you write the final page by hand. It keeps a statement from drifting into vague promises, because each section asks for a fact, not a feeling.

What to leave out

Leave out any claim you cannot back with a test and a date. Leave out absolute words about the whole site. Leave out a statement for pages you did not test, such as third party widgets or documents hosted elsewhere, unless you name them as out of scope. Axeazy does not scan PDFs, so if your site links to PDF documents, name documents as a known limitation or as out of scope, and give visitors another way to get the same content. Leave out a date you will not keep: a statement dated a year ago, never updated, tells a visitor the work stopped. Put a review date in your calendar, and update the statement after each round of fixes.

Axeazy's own accessibility statement, at Axeazy's accessibility statement page, is a useful example of the shape: a statement page on a live site, written for visitors rather than for search engines. Read it for structure, then write your own facts into the same five sections.

Where to put it, and how to keep it current

Link the statement from the footer of every page, so a visitor who hits a barrier can find it without hunting. Keep the page short: one screen of sections, not a legal document. After each fix round, update three things: the test date, the list of known limitations, and the list of fixes made since the last version. Axeazy records every scan and fix with a date and time, and weekly monitoring on paid plans catches new problems after updates, so a site on a monitoring plan can update its statement from its reports rather than from memory. Check the plan figures on Axeazy's pricing page if monitoring is part of your routine.

Related reading

For the monitoring routine that keeps a statement current, read what to look for in accessibility monitoring, and for weekly reports, read weekly accessibility reports for your site. For the buyer checklist, read accessibility tool buyer checklist.

• remove an accessibility overlay from wordpress

FAQ

Do I need a lawyer to write an accessibility statement?

No, but do not write legal claims in it. Write facts: what was tested, when, against what standard, what is still a problem, and how to contact you. If you have received a demand letter or been sued, talk to a qualified attorney about the letter itself, and keep the statement factual.

How often should I update the statement?

After each round of fixes, and at least after any template change or redesign. A statement with an old date and a list of limitations that no longer match the site is worse than no statement, because it shows work that stopped.

Can a statement cover only part of a site?

Yes, if it says so plainly. Name the pages and content in scope, and name what sits outside it, such as third party tools or documents. A scoped statement a visitor can trust beats a broad statement nobody can check.

Last checked: October 31, 2026 Sources: W3C WAI planning statements pages; W3C conformance evaluation pages; W3C WCAG 2.2; ADA.gov web guidance; Axeazy capabilities, pricing, and accessibility statement pages.

Start with Axeazy's free scan on your homepage, then fill the five sections above with what the scan and a keyboard check actually found.