Writing a Website Accessibility Statement

Why publish a statement

The W3C Web Accessibility Initiative (WAI) page on developing an accessibility statement gives three reasons: to show users "that you care about accessibility and about them", to give them information about the accessibility of your content, and to demonstrate commitment to accessibility. It adds that "In some situations, you may be required to provide an accessibility statement", such as public bodies in countries that implement the EU Web Accessibility Directive.

A statement is not a substitute for fixing problems. W3C is clear that statements "are not technical assessments or declarations of conformity", though they ideally refer to one. Our guide to website accessibility basics covers the fixing; this guide covers telling people where you stand.

What to include

W3C says an accessibility statement should contain at least:

• a commitment to accessibility for people with disabilities;
• the accessibility standard applied, "such as WCAG 2.2";
• contact information in case users encounter problems.

It also advises including any known limitations, the measures your organisation takes, technical prerequisites such as supported browsers, the environments the content has been tested in, and references to applicable laws and policies.

W3C's free accessibility statement generator walks you through these fields and lets you download the result to edit and brand. Its minimal example fits on one screen: a commitment, a conformance status ("partially conformant with WCAG 2.1 level AA"), contact details and a target response time.

On tone, W3C advises writing "in simple language" for users rather than "the language of developers and lawyers". Its example: rather than "WCAG Success Criterion 1.2.2 was not met", say "videos do not have captions".

UK public sector: the model statement

If you run a website or app for a UK public sector body, the statement is a legal requirement with set wording. GOV.UK's guidance to make your website or app accessible and publish an accessibility statement says you "must meet accessibility standards and publish an accessibility statement" and "need to review and update your statement regularly". It describes checking a representative sample of pages against WCAG 2.2 AA.

GOV.UK's sample accessibility statement is based on the model statement, which it calls "the minimum legal wording". Notes in the sample mark several passages, including the enforcement procedure and the compliance status, as "legally required" wording that "must not be changed". The compliance status must be one of fully compliant, partially compliant or not compliant with WCAG 2.2 AA, and anything short of full compliance has to be explained as either non-compliance or an exemption (including where fixing it would be a "disproportionate burden").

Even outside the public sector, the sample is a useful model, because its structure came partly from GOV.UK's research "into what's useful to disabled website users".

EU businesses: the European Accessibility Act

The European Accessibility Act (Directive (EU) 2019/882) covers certain products and services offered to consumers, including many online services. Our guide to website accessibility laws covers who it applies to and when. For services in scope, Article 13 says providers "shall prepare the necessary information in accordance with Annex V and shall explain how the services meet the applicable accessibility requirements". That information must be made available to the public "in written and oral format, including in a manner which is accessible to persons with disabilities", and kept "for as long as the service is in operation".

Annex V says the information goes "in the general terms and conditions, or equivalent document" and should, where applicable, contain:

• "a general description of the service in accessible formats";
• "descriptions and explanations necessary for the understanding of the operation of the service";
• "a description of how the relevant accessibility requirements set out in Annex I are met by the service".

One practical approach is an accessibility page, referred to from your terms and conditions, built on the W3C structure above. Article 4(5) exempts microenterprises providing services from the service accessibility requirements. National laws implement the Directive, so check the rules in each country where you sell.

Writing the known-issues list honestly

The known-issues section is the most useful part of a statement for disabled visitors, because it lets them decide quickly whether to use a feature or ask for an alternative. GOV.UK's sample says to list issues "in order of most impact to least impact" and to describe things a user can act on. Its examples include "most older PDF documents are not fully accessible to screen reader software" and "live video streams do not have captions".

Its advice on claims is just as useful: "If you're not confident that something is accurate, leave it out." Do not claim full conformance unless an audit supports it, and give a date for each planned fix only if you mean to keep it. A statement that promises more than the site delivers can do more harm than an honest list of gaps.

The contact route

Every statement needs a working way to report problems and to ask for content in another format. GOV.UK's sample offers email and phone, lists alternative formats such as accessible PDF, large print, easy read, audio recording and braille, and states how many days a reply will take. Use a monitored address, offer more than one channel, and make sure the form or page you send people to is itself accessible. Our guide to contact forms covers forms people can finish.

Where to put it and when to update it

W3C says statements "should be easy to find" and suggests linking from the footer, help menu, sitemap, about page and other prominent areas, with the same link name everywhere. GOV.UK's sample asks for a normal HTML page, linked from the homepage or from every page in a consistent place such as the footer. For mobile apps, it says to make the statement available in the app store, on your website or both, and advises that users can reach it from within the app; see our guide to mobile app accessibility.

Date the statement and review it when the site changes significantly, after each audit, and on a regular schedule. Keep it alongside your other legal pages.

Frequently asked questions

Does a private business need an accessibility statement?

It depends where you operate and what you sell. UK public sector bodies must publish one. Under the European Accessibility Act, providers of services in scope must publish information on how their service meets the accessibility requirements, while microenterprises providing services are exempt from those requirements. Elsewhere, a statement is good practice that W3C recommends.

Can we say our site is fully accessible?

Only if an audit supports it. W3C suggests stating the standard you apply, such as WCAG 2.2, and a conformance status such as partially conformant. GOV.UK's sample advises leaving out anything you are not confident is accurate.

How often should we update the statement?

GOV.UK says public sector bodies need to review and update their statement regularly. In practice, review it after audits, after significant changes to the site, and on a regular schedule, and show the date it was last reviewed.

Can we use the W3C generator for an EU or UK statement?

Yes, as a starting point. W3C says the generator is designed for different contexts and jurisdictions and that you can download and customise the result. UK public sector bodies must still include the legally required wording from GOV.UK's model statement.

Planning a new website? We build to the W3C WCAG guidelines and check accessibility before launch, so your statement can describe a site that works. See our website development service and all our services, or email [email protected].