Accessibility Statement

A WCAG accessibility statement that states what you actually meet, names known issues, and gives people a route to report problems.

100% free. Runs entirely in your browser - your files and data never leave your device and nothing is uploaded to any server.

Template, not legal advice. This is a template, not legal advice. It only describes what you tell it, so the conformance level you claim must be one you can evidence - an overstated claim is a liability rather than a shield. If you are a public sector body in the UK or EU, the required wording and the enforcement route are prescribed by regulation, and you should check the current government guidance against what this produces.

Start from an example

Fills every answer with a worked example you can edit. Pick the one closest to your business.

0 of 8 details filled
Your organisation
What you are measuring against
Claim "fully conforms" only after an audit. An untrue claim here is worse than no statement, because it is a representation you can be held to.
How you know

Claim only what you can evidence. An overstated claim here is a liability rather than a shield.

What is not right yet

Naming real problems with a fix date is what makes a statement credible.

Name them. A statement that lists real issues and a fix date is credible; one that claims none is not.
Where you operate
Public sector bodies in the UK and EU have a legal duty to publish a statement in a prescribed form. This adds the enforcement paragraph that duty requires.

Accessibility Statement

8 sections · 577 words · updates as you type

Accessibility Statement

Last updated: 12 November 2026

Our commitment

[Your organisation] wants [your website] to be usable by as many people as possible. That means you should be able to:

  • navigate the whole site using a keyboard alone
  • use it with a screen reader such as NVDA, JAWS, VoiceOver or TalkBack
  • zoom to 200% without text being cut off or overlapping
  • change colours, contrast and text spacing in your browser without breaking the layout
  • read text that contrasts sufficiently with its background

We treat accessibility as part of building the site rather than as a task that finishes, which is why this statement lists what is not right yet as well as what is.

How accessible this site is

This site partially conforms to the Web Content Accessibility Guidelines version 2.2, Level AA.

"Partially conforms" means most of the site meets the standard but some parts do not. The problems we know about are listed in the next section. We would rather tell you about them than let you find them.

Known problems

We are not currently aware of any part of the site that fails the standard above. That is not the same as there being none, so if something does not work for you, please tell us.

Content we do not control

Some parts of the site are supplied by third parties - embedded maps, video players, payment forms and similar. We choose which of these to use and we raise accessibility problems with the suppliers, but we cannot change their code ourselves.

If one of these blocks you from doing something, tell us what you were trying to do. We can usually offer another way to do it, and knowing which embed caused the problem helps us push the supplier or replace them.

If something does not work for you

Email [your contact email] and tell us:

  • the page you were on
  • what you were trying to do
  • what happened instead, and what you were using at the time (browser, screen reader, magnifier)

We reply within five working days. If you need something the site cannot give you - a document in large print, a form completed over the phone, information in another format - ask, and we will find another way to provide it.

Technical information

[Your organisation] is committed to making this site accessible in accordance with the Web Content Accessibility Guidelines version 2.2, Level AA.

The site relies on HTML, CSS and JavaScript. It is built to work with current versions of Chrome, Edge, Firefox and Safari, and with the assistive technology those browsers support. Accessibility depends partly on the browser and assistive technology you use, and a very old combination may not work as intended even where the site itself conforms.

How we tested this

This site was last reviewed in [date of last review] using automated accessibility testing tools, supported by manual keyboard checks.

Automated tools catch roughly a third of accessibility problems. They cannot judge whether alt text is meaningful, whether a heading structure makes sense, or whether a custom control behaves correctly with a screen reader. We are honest about that limit, and we plan to arrange a fuller assessment.

What we are doing next

Accessibility is checked as part of building anything new here, not audited afterwards: new components are tested with a keyboard and a screen reader before they ship, and contrast is checked at design stage.

The items listed above are prioritised by how much they block someone from completing a task, not by how easy they are to fix.

This statement is reviewed whenever the site changes substantially, and at least once a year.

Generated from a template. Not legal advice - read it before you publish or sign it.

Other documents you can generate

Most sites need more than one. A privacy policy without terms, or terms without a refund policy, leaves the obvious gap.

Privacy PolicyA privacy policy written from what your site actually does - GDPR and CCPA sections included only where they apply.Terms and ConditionsTerms of service built around what you actually sell - goods, subscription, downloads or services.Cookie PolicyA cookie policy with a real table - each cookie named, with its purpose and how long it lasts.Cookie Consent BannerGenerates a working consent banner - blocks tagged scripts until consent, Google Consent Mode v2, no dark patterns.Refund and Return PolicyA refund policy customers can follow and payment processors accept - windows, exclusions and statutory rights in plain words.Website DisclaimerA disclaimer that names the actual risk your site carries, plus affiliate and sponsorship disclosures.Non-Disclosure AgreementA mutual or one-way NDA with a real purpose clause, standard carve-outs and a defined term.Freelance ContractAn independent contractor agreement that pins down scope, revisions, IP ownership and what happens when payment is late.Data Processing AgreementA GDPR Article 28 processor agreement with the eight mandatory clauses and a filled-in processing schedule.W-9 FormFills a substitute Form W-9 in your browser - your TIN is never uploaded, stored or sent anywhere.1099-NEC Contractor SummaryPrepares a 1099-NEC recipient statement and a payer summary - with a straight answer about what you can and cannot print yourself.Shipping PolicyA shipping policy Shopify and Amazon sellers can publish - origin, times, tracking, duties and who pays.DSAR Form GeneratorA data-delete and access request page you can host - GDPR and CCPA wording, no upload, no signup.

Jump to the next useful tool without leaving your flow.

See more

About this tool

An accessibility statement is the one legal document where claiming less protects you more. An unaudited claim of full WCAG 2.2 AA conformance is a statement that can be used against you; a statement that lists three known problems with a fix date is credible, and it is what the regulations actually ask for. This generator is for public sector bodies, suppliers to them and any business preparing for accessibility duties, and it builds the statement from your answers: the WCAG version and level you are working towards, known issues and planned fixes, a contact route with a response time, and when and how the site was last reviewed. Write it after testing the site, so it reports findings rather than intentions. Nothing is uploaded.

How to use this tool

  1. Describe what the statement coversEnter the organisation name, the website or app covered and the accessibility contact email.
  2. Record your test resultsState the WCAG level you aim for, list the known issues you found and the date you plan to fix each one.
  3. Publish and keep it datedDownload the statement, link it from the footer and update the review date after each new test.

Writing an honest accessibility statement

An accessibility statement says which standard you aim for - usually WCAG 2.1 or 2.2 at level AA - how far your site meets it, which parts do not yet, and how people can get content in another format or report a problem. UK public sector bodies are legally required to publish one, and the European Accessibility Act is extending accessibility duties to many private businesses selling to EU consumers.

The statement that builds trust is the honest one. Listing known issues with dates for fixing them, and giving a real contact who answers, does more for users - and for any regulator - than claiming full compliance nobody has tested.

Key features

  • States the WCAG version and level you are working towards.
  • Lists known issues and planned fixes instead of claiming full compliance.
  • Gives users a contact route and response time for reporting barriers.
  • Includes the date of the last review and how it was carried out.

Common uses

  • A UK public sector website that must publish a statement.
  • A business preparing for European Accessibility Act duties.
  • An agency handing over a site with an audit report attached.
  • A tender or procurement form that asks for an accessibility statement.

Tips for better results

  • Test with a keyboard and a screen reader before writing - the statement should report what you found.
  • Give a real response time for accessibility requests, and keep it.
  • Attach the statement to tenders and procurement forms that ask for one.

Mistakes to avoid

  • Publishing a statement with no contact route, which fails the only test that matters to the person reading it.
  • Claiming full conformance without an audit to back it up.
  • Leaving the review date years out of date after the site has changed.

Frequently asked questions

No - and you should not unless it has been tested. Statements can say a site is partially compliant and list the exceptions; that is what UK public sector guidance expects.

Combine an automated checker with manual tests: keyboard-only navigation, a screen reader such as NVDA or VoiceOver, zoom to 200% and colour-contrast checks. Automated tools catch only part of the problems.

At least once a year, and after major redesigns. Update the list of known issues as you fix them so the statement stays accurate.

No. It assembles a draft from standard clauses, and every page says so above the preview. US web accessibility lawsuits run into the thousands per year, and the first thing a plaintiff firm checks is whether the site claimed conformance it did not have.

Broadly, public sector bodies, anyone selling to them, and any business that would rather answer an accessibility complaint than an ADA demand letter. The best time to do it is after you have tested the site, not before - the statement reports findings rather than intentions.

Publishing a statement with no contact route. The entire mechanism assumes a person who hits a barrier can tell you, and a statement that ends without an email address fails the only test that matters to the person reading it.

Most people need Disclaimer and Privacy Policy as well. They cover the gaps this one does not.

Related guides