If you build and look after websites for public-sector clients, you probably ship an accessibility statement with every build. When you run dozens or hundreds of sites, that statement may start life as one template. Sooner or later a client asks whether it is right, often after a monitoring email from the Government Digital Service (GDS).
This guide is for the agency or platform supplier in that position. It covers what GDS allows, what has to change from site to site, and a process you can run across a whole portfolio.
The Short Answer
One statement or many is your choice. GDS guidance allows a single statement that covers several domains, or a separate statement for each one.
What GDS flags is a statement that does not describe the site it covers. Each statement needs that site's own scope, test date, test method and list of failures, and it has to stay current. A template can supply the fixed legal wording. It cannot supply the rest.
The legal duty to publish the statement sits with your client, not with you. But the facts the statement depends on, such as what was tested and what still fails, are often things the supplier is best placed to know. That is why the question keeps landing in your inbox.
One Statement or Many: What GDS Allows
The regulations themselves do not settle this. Regulation 8(opens in new tab) of the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 says "A public sector body must provide an accessibility statement", "and keep that statement under regular review". It speaks of "a website" and "a mobile application". It does not say "each".
The clearer answer comes from GDS's sample accessibility statement(opens in new tab). It says "you can have a single accessibility statement that covers multiple domains", or "a separate statement for each domain or subdomain". There is one condition: the statement works "as long as the user can access relevant accessibility information easily from any page on your website".
That is GDS guidance, not the regulations. It is the clearest guidance we found, and it means a client with a main site and several subdomains can choose either approach.
One honest limit. Every example in the sample is about one organisation's own domains. We found no guidance on a single statement covering several different organisations' sites. So this post does not treat that as an option.
What Has to Change From Site to Site
The sample statement mixes two kinds of content. Some of it is fixed wording. Some of it only makes sense for one site.
The site-specific fields are:
- Who runs the site. The name of the organisation.
- What the statement applies to. The sample's line is "This accessibility statement applies to [scope]".
- When the site was tested, and against what. "This website was last tested on [date] against the WCAG 2.2 AA standard." WCAG is the Web Content Accessibility Guidelines; see what changed in WCAG 2.2.
- How it was tested, and who did the testing. Your client's own team, or the organisation that carried out the test.
- What is not accessible. Each problem, the WCAG success criterion it fails, and a date for the fix.
- When the statement was prepared and last reviewed.
The compliance status wording and the enforcement wording are different. They are legally required text, and the sample tells you not to change them. The enforcement wording names the Equality and Human Rights Commission (EHRC) as the body that enforces the regulations in Great Britain.
So the line is simple. The fixed wording can come from your template. The scope, the dates, the method and the failures cannot, because they describe one site at one point in time. A shared template cannot hold another site's test date or another site's failures.
GOV.UK's guidance on publishing an accessibility statement(opens in new tab) asks for a review "when there are major changes and at least once a year". The sample's notes add a rule worth putting on the wall: "If you're not confident that something is accurate, leave it out."
Where Template Statements Go Wrong
GDS checks statements as part of its monitoring of public-sector websites. Its sampling covers sites on public-sector domains such as .gov.uk, .ac.uk and .nhs.uk.
Its monitoring report for January 2022 to September 2024(opens in new tab) describes four problems with statements:
- Copied template text. GDS found "organisations directly copying and pasting text from the sample statement template".
- Out-of-date statements. Many were "out-of-date and have not been reviewed in the last 12 months".
- Fix dates in the past. Statements listed "future fixes for issues where the dates have now passed".
- Missing failures. GDS reported "issues being found in our tests which are not included in the statement".
These are qualitative findings. The report gives no count of how many statements were copied or out of date, so we do not give one either.
It does give figures on whether statements existed and were complete.
When first checked, 85% of the websites and mobile apps GDS monitored had published a statement. After the monitoring process, 97% had one, and 65% included all the necessary information (GDS monitoring report, January 2022 to September 2024).
The copying GDS describes is from its own sample. A supplier template reused across many sites carries the same risk on a larger scale: every site that shares it can show the same test date, the same failures and the same review date, whether or not they are true for that site.
Whose Job Is It?
The duty is your client's. Regulation 8 puts it on the public sector body. On third-party content, GDS tells the body "it is your responsibility to make sure that it is accessible".
We found no law that puts the statement duty on a supplier. Nor did we find one in a search of Crown Commercial Service (CCS), G-Cloud (the government's framework for buying cloud services) or Department for Education (DfE) framework terms. Your part is whatever your contract with each client says.
Lexdis(opens in new tab), an independent sector guide on digital accessibility, describes a good statement as "a joint effort between a public sector body and a supplier". In its view, the body owns the legally required content, and the supplier is "best placed to provide practical accessibility and technical information". That is advice, not a rule, but it matches how the work tends to split.
For the fuller answer on liability, using GP practices as the example, see our guide to GP practice website accessibility statements. It also sets out what regulation 8 requires a statement to contain.
What to agree with each client, in writing:
- Who tests the site, and against which standard.
- How often it is tested, including after major changes.
- Who updates the statement when a test, a fix or a new failure changes it.
- Who signs it off before it is published, since it is the client's statement.
A Process That Scales
A portfolio of statements stays true when each one is built from that site's own results. A process you can run across every client site:
- Test each site against WCAG 2.2 AA. Not a sample site standing in for the rest. A website accessibility audit covers how.
- Record the failures per site. Each one with the page, the WCAG criterion and a planned fix date.
- Build each statement from that site's results. Fixed wording from your template; scope, dates, method and failures from the test.
- Fix and retest. Remove what is fixed from the statement and keep what is not.
- Update the dates. The test date and the review date should match what actually happened.
- Review at least once a year and after major changes. Put the review date in your client calendar, site by site.
The point is not more paperwork. It is that when a client or GDS asks whether a statement is right, you can show the test it came from.
How AUDITSU Helps
Your clients own their sites and their statements. You own the work that keeps them true. AUDITSU helps you do that work the same way for every site.
AUDITSU takes you through an audit of each site against WCAG 2.2 AA. A person reviews every finding, and nothing counts until they accept it. Each site's accessibility statement is built from that site's own results, so when you fix something and recheck it, that site's statement updates with it. You run the same process for every client site from one account. If you or your client would rather an independent tester did the checking, a manual audit is available too.
If you want to talk through how this would work across your client sites, book a call.