Accessibility Statement — What It Is and How to Write One

What is an accessibility statement?

An accessibility statement is a dedicated page on your website that tells visitors how accessible your site is. It is part transparency, part legal compliance, and part user support.

A good accessibility statement does four things:

1. States your conformance level — which version of WCAG you target and whether you meet it fully, partially, or not at all
2. Lists known issues — specific barriers users may encounter, and what you are doing to fix them
3. Provides contact information — so users can report problems they experience
4. Names the enforcement authority — where users can file a formal complaint if issues are not resolved

The concept is simple: be honest about where you stand, and make it easy for people to get help.

Why do you need one?

Legal requirements

For EU public sector bodies, an accessibility statement is mandatory. The Web Accessibility Directive (EU) 2016/2102 requires all public sector websites and mobile apps to publish one. The European Commission has defined a model accessibility statement that member states can adopt.

For private sector organisations covered by the European Accessibility Act (Directive 2019/882), the situation is different. The EAA does not require a specific accessibility statement. However, economic operators must be able to demonstrate conformity with the accessibility requirements (Article 7). An accessibility statement is the most practical way to do this.

In the UK, the Public Sector Bodies Accessibility Regulations 2018 require public sector organisations to publish an accessibility statement. The Government Digital Service (GDS) provides guidance on the required format.

Trust and reputation

Beyond legal compliance, an accessibility statement shows your users that you take inclusivity seriously. It tells users with disabilities that they are welcome and that you are working to remove barriers. For organisations that serve the public — government, healthcare, education — this matters.

Practical benefits

An accessibility statement also helps your own team. Writing one forces you to assess your current state. Listing known issues creates accountability. Setting a review date ensures accessibility does not become a one-time project.

What to include in your accessibility statement

1. Conformance status

State which standard you target and how well you meet it. Use one of three levels defined by WCAG:

Status	Meaning
Fully conformant	The site meets all applicable WCAG success criteria with no exceptions
Partially conformant	The site meets most criteria but has known gaps
Non-conformant	The site does not yet meet the standard

Most organisations are "partially conformant" — this is honest and normal. What matters is that you list the specific gaps and have a plan to fix them.

Example: "This website is partially conformant with WCAG 2.1 Level AA. The non-conformances are listed below."

2. Known accessibility issues

List the specific issues your users may encounter. Be concrete — do not write vague statements like "some pages may have issues." Instead:

• Describe the issue — what is the barrier?
• Name the WCAG criterion — which success criterion fails?
• State the impact — which users are affected?
• Give a timeline — when do you plan to fix it?

Example:

Issue	WCAG criterion	Impact	Target fix date
Some images lack descriptive alt text	1.1.1 Non-text Content	Screen reader users cannot understand the content of these images	Q2 2026
Colour contrast is below 4.5:1 on some buttons	1.4.3 Contrast (Minimum)	Users with low vision may have difficulty reading button text	Q1 2026
Keyboard focus is not visible on dropdown menus	2.4.7 Focus Visible	Keyboard-only users cannot see where they are on the page	Q1 2026

3. Technologies relied upon

List the technologies your website depends on to work accessibly. This typically includes:

• HTML
• CSS
• JavaScript
• WAI-ARIA
• PDF (if you publish accessible PDFs)

4. Feedback and contact information

Provide a way for users to report accessibility barriers. Include:

• A named contact or team (e.g., "Accessibility Team" or a specific person)
• An email address
• A phone number (important for users who cannot use email)
• Expected response time (e.g., "We aim to respond within 5 working days")

5. Enforcement procedure

Tell users where they can escalate complaints if you do not resolve their issue. This depends on your country:

Country	Enforcement body	Link
UK	Equality and Human Rights Commission (EHRC)	equalityhumanrights.com
Sweden	DIGG (Myndigheten för digital förvaltning)	digg.se
Finland	AVI (Etelä-Suomen aluehallintovirasto)	saavutettavuusvaatimukset.fi
EU (general)	National enforcement body designated under the Web Accessibility Directive	Varies by member state

6. Date and review cycle

State when the accessibility statement was last updated and when it will next be reviewed. For public sector bodies under the Web Accessibility Directive, annual review is required.

Accessibility statement template

Here is a template you can adapt for your organisation:

Accessibility statement for [Your Organisation]

[Your Organisation] is committed to making its website accessible to everyone, including people with disabilities.

Conformance status: This website is [fully / partially / non]-conformant with WCAG 2.1 Level AA.

Known issues:

• [Issue 1] — affects [user group] — target fix date: [date]
• [Issue 2] — affects [user group] — target fix date: [date]

Technologies relied upon: HTML, CSS, JavaScript, WAI-ARIA

Assessment method: This statement is based on [a self-assessment / an external audit by [auditor name] / automated monitoring by [tool name]].

Feedback: If you encounter an accessibility barrier on this website, please contact us:

• Email: [accessibility@example.com]
• Phone: [+44 xxx xxx xxxx]
• We aim to respond within [5] working days.

Enforcement: If you are not satisfied with our response, you can contact [enforcement body and link].

This statement was last updated on [date] and will be reviewed by [date].

How to write your statement: step by step

Step 1: Assess your current state

Before you can write an honest statement, you need to know where you stand. Run a free accessibility scan to get an automated overview of your WCAG compliance. This identifies the most common issues — contrast failures, missing alt text, empty links, missing form labels — in minutes.

For a complete picture, combine automated scanning with manual testing. Automated tools catch about 30-40% of WCAG issues. The rest requires human judgement.

Step 2: Document your findings

Create a list of all known issues. For each one, record:

• The WCAG success criterion that fails
• Where on the site it occurs (specific pages or templates)
• The severity (critical, major, or minor)
• Your planned fix date

Step 3: Write the statement

Use the template above. Be specific and honest. Avoid vague language like "we strive to be accessible" without concrete details. Users and regulators want to see what you have checked, what you found, and what you are doing about it.

Step 4: Publish and link it

Place the statement in your website footer so it is accessible from every page. Use a clear link label — "Accessibility" or "Accessibility Statement."

Step 5: Review regularly

Set a calendar reminder to review the statement at least once per year. Update it whenever you fix an issue, discover a new one, or redesign part of your site. Continuous monitoring with Askem helps you catch new issues as they appear, so your statement stays accurate.

Common mistakes

• Claiming full conformance without evidence — if you have not tested thoroughly, say "partially conformant"
• No contact information — the whole point is to give users a way to get help
• No specific issues listed — "we are working on it" is not enough
• Never updating it — a statement from 2021 on a site redesigned in 2025 is worse than no statement
• Hiding it — put it in the footer, not buried in a submenu

Further reading

• W3C WAI — Developing an Accessibility Statement
• W3C WAI — Accessibility Statement Generator
• GDS — Publishing an Accessibility Statement (UK)
• European Commission — Model Accessibility Statement
• Web Accessibility Directive (EU) 2016/2102
• European Accessibility Act — Complete Guide
• WCAG 2.2 — Practical Guide