Accessibility Policy Template: How to Write an Effective Accessibility Statement

This article provides a practical Accessibility Policy Template and step-by-step instructions to write an effective accessibility statement for UK websites and digital services. It includes short and full templates, a testing checklist, common mistakes to avoid, and examples you can copy and adapt.

Accessibility Policy Template: what this page gives you

This page includes an Accessibility Policy Template and a step-by-step guide to write an effective accessibility statement for a website or digital service. Use the templates below and adapt the examples to your organisation, your technical constraints, and your legal obligations in Great Britain.

Why publish an accessibility policy or statement?

An accessibility policy explains how your organisation approaches digital access for people with disabilities. It sets expectations for users, staff and regulators. In practice it helps you:

show which accessibility standard you follow, such as WCAG 2.1 AA
give users a clear route to report problems
set a timetable for fixes and reviews
reduce legal and reputational risk by recording steps you take

Standards and law to reference

State which standards and laws your policy addresses. Common references in the UK are:

WCAG 2.1 with the target level (for example, AA)
Equality Act 2010 as the relevant UK legislation for services and reasonable adjustments
WAI-ARIA for accessible dynamic content and widgets

Do not conflate standards and laws. Standards tell you how to test and build. Laws set legal duties. Be precise: name the WCAG version and level your work targets.

Core sections every accessibility policy should have

Include these headings so readers find key information quickly.

Scope — which websites, apps or documents the policy covers
Standard and conformance level — e.g., WCAG 2.1 AA
Current status — fully conformant, partially conformant, or work in progress
Known limitations — specific pages or components that are not yet accessible
How we test — automated tools, manual testing, assistive technology used
Feedback and contact — how users report barriers and expected response times
Accessibility roadmap — planned fixes and target dates
Review date — when the policy was last updated and when it will be reviewed

Accessibility Policy Template (short)

Use this short version for a concise statement on a help or footer page.

We aim to make [organisation name] and our website [site URL] accessible to everyone. We follow WCAG 2.1 AA where possible. If you find an accessibility problem, please contact us at [email or phone] with details. Last updated: [date].

Accessibility Policy Template (full)

Use the full template for a dedicated accessibility statement page. Replace bracketed items with your organisation’s details.

Scope
This policy covers [site URL], mobile apps [list], and digital documents published by [organisation name].

Standard and conformance
We aim to meet WCAG 2.1 at level AA. Where content does not meet this level we list known issues below.

Current status
[Organisation name] is currently [fully conformant / partially conformant / not conformant]. The table of exceptions below gives details.

Known limitations
- [Page or feature]: [description of issue], planned fix: [date]

How we test
We use automated tools such as [tool names], keyboard testing, and manual checks with screen readers including NVDA and VoiceOver. We test critical user journeys monthly.

Feedback and contact
If you experience barriers, email [accessibility@domain] or call [phone number]. Please include the web address, device and browser used, and a description of the problem. We aim to respond within [X] working days.

Accessibility roadmap
- Short-term fixes: [items and dates]
- Medium-term work: [items and dates]
- Long-term goals: [items and dates]

Third-party content
Some content is provided by third parties. We will contact providers about accessibility, and note exceptions below.

Review
Policy last updated: [date]. Next review: [date].

How to write an effective accessibility statement: step-by-step

Decide the scope. Name the domains, apps and document formats you cover.
Choose the target standard and level. Prefer a stable version, for example WCAG 2.1 AA.
Run a baseline audit. Use one automated scan and a short manual test of main journeys.
Draft the policy using the full template. Be specific about known limitations and dates.
Set a clear feedback route and measurable response time.
Publish the statement in plain English and add a link in the footer and accessibility page.
Assign owners and a review cadence, for example quarterly or annually.

What good statements include that many miss

Competitors often write vague or optimistic statements. Make yours useful by doing these things:

List concrete exceptions with pages and dates for fixes
State which assistive technologies you test with, such as NVDA and VoiceOver
Explain how third-party content is handled
Publish a short roadmap so users see progress

Common mistakes to avoid

Saying “fully accessible” without evidence from testing
Giving only a generic contact form without expected response times
Hiding the statement so users cannot find it from the footer
Using legal language that confuses users instead of clear steps

Testing: practical and repeatable checks

Testing should combine automated and human checks. A quick routine:

Run an automated scan on a representative page for obvious issues
Keyboard test: try the main flows without a mouse
Screen reader test: open a page with NVDA or VoiceOver and try to complete a task
Colour contrast check with a contrast tool on headings and buttons
Document the errors and assign them to sprints

Decision framework: short vs long statement

Use this quick guide to pick the right statement length.

Small site with limited content: short statement plus contact details
Large public service or ecommerce site: full policy with roadmap and exceptions
Sites with many third-party embeds: full policy and a third-party exceptions list

Example short statement

We aim to make [organisation name] accessible to all users. If you find an accessibility issue, please contact accessibility@[domain] with the page URL and a description. We will respond within [X] working days. Last updated: [date].

Example detailed statement (short excerpt)

Scope: This statement covers the website at [site URL] and files published as PDFs on that site. Standard: We aim to comply with WCAG 2.1 AA. Known limitations: Some older PDFs do not meet WCAG. Planned fixes: conversion of critical PDFs by [month year]. How to report issues: email accessibility@[domain] with the URL, device, browser and a short description. We will reply within [X] working days.

Accessibility statement checklist

Statement linked from footer and accessibility page
Scope and standards named clearly
Known limitations listed with dates
Testing methods and assistive tech named
Feedback contact and response time listed
Roadmap and review date included

Real-world scenario: small charity with limited budget

Start with a short, honest statement. Run simple tests on the donation and contact flows. Fix keyboard and focus issues first. Publish a small roadmap with realistic deadlines. Use free tools for initial scans and plan manual testing with volunteers who use assistive tech.

How often to update the policy

Update the statement whenever you change scope, after a major redesign, or when you fix a known limitation. At minimum, add a review date and update it yearly.

Final notes

Keep language plain and concrete. Users need to know what you are doing and how to get help. An accessibility policy is a practical record of effort, not a legal shield. Use the templates here as a starting point and adapt them to your service.