How to Write an Accessibility Statement

An accessibility statement is a public page that explains how accessible your website or app is, which parts fall short of the standard and how people can get help or report a problem. UK public sector bodies are legally required to publish one. The GOV.UK model statement sets out the sections and wording it must contain. For organisations that rely on accessible website design for the public sector, the statement is often the first page an auditor, a complainant or a procurement panel reads, so it has to be both accurate and complete.

Most of the work happens before a single sentence is written. A statement can only describe what testing has found, so an organisation that has not checked its website against the current standard has nothing reliable to say.

What an Accessibility Statement Must Include

A public sector accessibility statement must say how far the website meets the accessibility standard, list the content that is not accessible with the reasons and give people a way to report problems and ask for alternatives. In law these requirements sit in regulation 8 of the accessibility regulations. The GOV.UK guidance turns them into the elements below.

• The website, domain or app the statement covers.
• A compliance status of fully, partially or not compliant with WCAG 2.2 AA.
• The content that is not accessible and the reason for each gap.
• Any accessible alternatives, such as large print or easy read versions on request.
• Contact details for reporting problems and requesting other formats.
• The enforcement procedure, with a link to the EASS or the ECNI.
• When the statement was prepared, when it was last reviewed and how the website was tested.

Private organisations are not bound by that list, but following it gives users the same reliable information. The W3C makes a similar point in its guidance on developing an accessibility statement, which says every statement should contain at least a commitment to accessibility, the standard applied and contact details for users who run into problems.

Who Legally Needs an Accessibility Statement

Every UK public sector body that runs a website, intranet, extranet or public mobile app needs an accessibility statement, apart from a small number of exempt organisations. The duty comes from the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, which came into force on 23 September 2018.

The GOV.UK page on accessibility requirements for public sector bodies lists central government, local government and some charities and other non-government organisations as covered. Mobile apps built for the public are in scope but apps for defined groups such as employees or students are not. The cards below summarise where different organisations stand.

Outsourcing the website does not move the responsibility. The guidance states that a public sector body remains legally responsible when a supplier builds or runs its website, so the statement should be agreed with the supplier.

Monitoring is active rather than theoretical. The Government Digital Service tests a sample of public sector websites and apps every year. Where a body has failed to publish a statement or published an incorrect one, the Central Digital and Data Office can publish the name of the body and a copy of its decision.

Why Private Sector Organisations Publish One Too

Private companies in the UK have no legal duty to publish an accessibility statement, but many choose to for practical reasons. Section 20 of the Equality Act 2010 sets out the duty to make reasonable adjustments. Where information is involved, reasonable steps include providing it in an accessible format. A statement with a clear route for requesting alternative formats is a simple way to show how a business meets that duty online.

Procurement is the other driver. Public sector and large enterprise buyers often ask suppliers for an accessibility statement and evidence of WCAG compliance during tenders. A B2B website without one can lose marks before anyone looks at the product. The legally required wording only applies to public sector bodies, so a private company can use plainer language and keep the same structure.

Test the Website Before Writing the Statement

An accessibility statement can only report what testing has found, so the first step is checking the website against WCAG 2.2 AA. The GOV.UK guide to making your website accessible and publishing a statement says you do not need to check every page, but you do need to test a sample that reflects the range of content and functionality across the website.

The guide describes three routes. A team with the technical skills can carry out a detailed audit in house, an organisation without those skills can commission a third party and a body that cannot reasonably afford a detailed audit can carry out a basic accessibility check after assessing that a full audit would be a disproportionate burden. Automated scans pick up issues such as missing alt text and low contrast. Manual testing with screen readers and keyboard navigation finds the problems software cannot. Our guide to what a web accessibility audit tests explains how the two approaches fit together.

The version of WCAG matters. GOV.UK guidance and the model statement now refer to WCAG 2.2 AA. The WCAG 2.2 specification adds new AA criteria such as 2.4.11 Focus Not Obscured (Minimum) and 2.5.8 Target Size (Minimum). A statement that still cites WCAG 2.1 is out of date. Our article on the latest version of WCAG covers what changed.

Working Through the GOV.UK Model Statement

The GOV.UK model accessibility statement contains the mandatory wording. The government’s sample accessibility statement shows how a fictional public sector website might fill it in. Some sentences are legally required and must not be changed, so use the model exactly as GOV.UK publishes it and replace only the text in square brackets. Copying wording from another organisation’s statement, or from a template that has been reworded, risks publishing a statement that does not meet the requirements.

The opening section names the organisation and the scope, such as a single domain or a group of websites. The sample statement for a fictional website then suggests a short summary of what disabled users can do, for example zooming in up to 400% without text spilling off the screen. It advises leaving that summary out entirely if you are not confident it is accurate.

Compliance status has to be expressed in fixed wording. You choose fully compliant if every WCAG 2.2 AA requirement is met without exception, partially compliant if most are met or not compliant if most are not. Partial compliance is the honest answer for most established websites. It is a legitimate status as long as the gaps are listed and there is a plan to fix them.

The non-accessible content section splits problems into three groups, each with a legally required heading. Non-compliance covers content in scope that fails WCAG, listed with the success criterion it fails and when you plan to fix it. Disproportionate burden covers fixes you have formally assessed as unreasonable for your organisation. Lack of time or knowledge cannot count towards that assessment. Content outside the scope of the regulations covers items such as PDFs published before 23 September 2018 that are not needed to use a service, live video and third party content you did not pay for or develop.

The final sections cover feedback, enforcement and preparation. You need contact details for reporting problems and requesting alternative formats with a stated response time, followed by the fixed enforcement wording that names the Equality and Human Rights Commission and the Equality Advisory and Support Service. Organisations in Northern Ireland refer users to the Equality Commission for Northern Ireland instead. The preparation section records when the statement was written and reviewed, when the website was last tested and who did the testing.

Describe each problem as a user would experience it, then name the success criterion it fails and give a date for the fix. A resident using a screen reader should be able to read the statement and know straight away which form will cause problems and how to get help another way. The W3C advises the same approach, describing limitations in everyday terms such as saying videos do not have captions rather than quoting a failed success criterion on its own.

Publish the finished statement as an HTML page rather than a PDF. Link to it from every page in a consistent place such as the footer. For a mobile app, GOV.UK guidance says the statement should be available in the app store, on your website or both.

Keeping the Statement Under Review

An accessibility statement must be reviewed at least once a year and updated whenever there are major changes to the website. The sample statement recommends a fresh audit after any substantial revision, such as a redesign or the launch of a new online service.

Statements tend to drift between reviews. New PDFs, embedded tools and third party widgets can all introduce barriers the statement does not mention. A statement that still lists problems fixed months ago is just as misleading, so building a check into the publishing workflow makes the annual review far quicker.

Ownership matters as much as timing. The statement should name a team or role with the authority to commission fixes and reply within the time the statement promises, not a shared inbox that nobody checks. Priority Pixels website accessibility audits and remediation come with a prioritised action plan and findings mapped to the sections your accessibility statement must cover. Ongoing monitoring then picks up issues introduced through content updates, which gives each review a reliable evidence base.

Common Mistakes in Accessibility Statements

Most weak accessibility statements fail in predictable ways. Nearly all of them come down to the statement not matching the website people use day to day. Our overview of accessibility requirements for public sector websites covers the wider obligations, but the statement is where errors are most visible to users and regulators.

Claiming full compliance without a recent audit is the most serious error, followed closely by copying another organisation’s statement or editing the legally required wording. Vague phrases such as “some content may not be accessible” give users nothing to act on. A missing review date suggests the page has been forgotten.

Fixing these is rarely a large job once testing is in place. A statement that is honest about its gaps, clear about alternatives and reviewed on schedule does more for users and for compliance than a polished page that promises more than the website delivers.