Schedule a Conversation
27 Feb 2026 Compliance & Governance 9 min read

Accessibility Statement Template for Nonprofit Websites

Key takeaways

  • An accessibility statement declares your site's status, known issues, and how barrier-hit users can get help.
  • Public sector bodies must publish one by law; other charities are still expected to by funders.
  • Claim only the compliance you have actually tested, and list known issues specifically, not vaguely.
  • Automated tools catch only about 30 to 40 percent of WCAG failures, so manual testing is essential.
  • Publish it at a consistent URL like /accessibility and link it from the footer of every page.
  • Review the statement at least annually and update it after any significant accessibility change.

Summary

A ready-to-use accessibility statement template for nonprofit and charity websites — including what to include, how to structure it, and how to keep it current.

Why an Accessibility Statement Matters

An accessibility statement is a published declaration of your website's current accessibility status — what standards it meets, what known issues remain, and how users who encounter barriers can get in touch.

For public sector bodies and organisations receiving public funding, a published accessibility statement is a legal requirement under the Public Sector Bodies Accessibility Regulations. For all other nonprofits and charities, it is not strictly required by law — but it is expected by institutional funders conducting due diligence, good practice under the Equality Act 2010, and a visible signal of commitment to inclusion that is consistent with most organisations' stated values.

An accessibility statement also serves a practical governance function: it documents what testing has been done, when, and by whom. If an accessibility complaint is made or a funder asks for evidence of compliance, the statement is the starting point for that conversation.

This post provides a template that covers all required and recommended elements. The template is written in plain language, which is the appropriate register for an accessibility statement — it needs to be readable by the people it most directly serves.

What an Accessibility Statement Must Cover

A complete accessibility statement should address:

  1. Which accessibility standard the site aims to meet and at what level
  2. Which parts of the site are accessible and which have known issues
  3. What testing has been conducted and when
  4. How users who encounter barriers can contact the organisation
  5. What the organisation will do if it cannot immediately fix a barrier
  6. Where to direct a complaint if the response is unsatisfactory (for public bodies, this is typically the Equality Advisory Support Service)
  7. When the statement was last reviewed

The Template

The template below is written for a registered charity aiming for WCAG 2.2 AA compliance. Adapt the bracketed sections to reflect your organisation's actual situation.

Accessibility Statement for [Organisation Name]

Last reviewed: [Month Year]

Our Commitment

[Organisation Name] is committed to ensuring this website is accessible to everyone, including people with disabilities. We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA.

Compliance Status

This website is [partially / fully] compliant with the Web Content Accessibility Guidelines version 2.1 AA standard.

[Choose one of the following and delete the others:]

If fully compliant:We are not aware of any pages or content on this website that fail to meet WCAG 2.2 AA. We continue to monitor and test accessibility as content is updated.

If partially compliant:Some pages or content on this website do not currently meet WCAG 2.2 AA. Known issues are listed below under "Known Accessibility Issues."

If not yet assessed:We have not yet completed a full accessibility assessment of this website. We are actively working to improve accessibility and will update this statement as assessments are completed.

Known Accessibility Issues

[If you are partially compliant, list specific known issues here. Be precise — vague statements are not useful to users or to anyone reviewing your compliance. Examples:]

  • PDF documents: Some older PDF documents linked from this site have not been made fully accessible. We are working to replace or remediate these. If you need an accessible version of a specific document, please contact us using the details below and we will provide it within [X working days].
  • Video captions: Some videos published before [date] do not have closed captions. We are adding captions to these progressively. New videos published after [date] include closed captions.
  • Third-party content: Some content embedded from third-party providers — including [name any: donation forms, video platforms, event booking systems] — may not meet the same accessibility standards as the rest of this site. We cannot directly control the accessibility of third-party platforms, but we will raise issues with providers and provide alternatives where possible.

[Delete this section entirely if your site is fully compliant and has no known issues.]

{{cms-cta}}

How We Tested This Website

This website has been assessed for accessibility using the following methods:

  • Automated testing using [WAVE / Axe DevTools / Lighthouse — list the tools you actually used]
  • Manual keyboard navigation testing
  • Screen reader testing using [NVDA / VoiceOver — list what you used]
  • Colour contrast checking for all text elements

Testing was last completed: [Month Year]

Testing was carried out by: [Socialectric / your internal Digital Manager / an external accessibility auditor — specify who conducted testing]

We test accessibility before significant content updates and at a minimum annually.

Technical Information

This website is built using Webflow and the Lumos framework, which provides a WCAG AA compliant baseline including skip navigation, ARIA landmark roles, and consistent focus indicators.

The following technologies are relied on for conformance:

  • HTML
  • CSS
  • JavaScript

What to Do If You Cannot Access Part of This Website

If you experience difficulties accessing any part of this website, please contact us:

Email: [accessibility@yourcharity.org.uk or your general contact email]Phone: [phone number, if applicable]

We aim to respond to accessibility enquiries within [5 / 10] working days.

If you need information in a different format — for example, large print, easy read, audio, or a language other than English — please let us know and we will do our best to provide it.

Reporting Accessibility Problems

We welcome feedback on the accessibility of this website. If you find content that is not accessible and is not listed under Known Accessibility Issues above, please contact us using the details above.

Enforcement

[Include this section if you are a public sector body or receive substantial public funding:]

The Equality and Human Rights Commission (EHRC) is responsible for enforcing the Public Sector Bodies Accessibility Regulations 2018 in England, Scotland, and Wales. If you are not happy with how we respond to your complaint, contact the Equality Advisory and Support Service (EASS).

[For other charities, replace the above with:]

If you are not satisfied with our response to an accessibility concern, you may wish to contact the Equality Advisory and Support Service (EASS) for further guidance.

Date of This Statement

This accessibility statement was prepared on [Month Year] and last reviewed on [Month Year].

How to Use and Maintain This Statement

Where to publish it: Create a dedicated /accessibility page on your Webflow site. Link to it from the footer alongside the privacy policy and cookie policy. The footer link should use the text "Accessibility" — this is the expected location and label that screen reader users and accessibility-aware visitors will look for.

How to fill it in honestly: The most important principle is accuracy over aspiration. Don't claim full compliance if you haven't tested the site. Don't list known issues vaguely — name them specifically. An honest statement that acknowledges partial compliance and explains what's being done is more credible and more useful than a compliance claim that can't be substantiated. When I write accessibility statements as part of a Socialectric project, I won't claim full WCAG 2.2 AA compliance unless we've completed both automated and manual keyboard and screen reader testing. Partial compliance with a clear remediation note is always the honest starting point.

When to update it: Update the statement whenever you make significant changes to the site's accessibility — following a remediation project, when known issues are resolved, or when new known issues are identified. Review the statement at minimum annually even if nothing has changed, and update the "last reviewed" date.

The testing section is important: The statement should reflect testing that has actually been carried out, not aspirational testing that you intend to do. If you haven't yet done screen reader testing, say so and indicate when you will. If accessibility testing has only been automated (WAVE and Axe), say that — automated tools catch approximately 30–40% of WCAG failures, and an informed reader will know that automated testing alone is not sufficient for a full compliance claim.

Accessibility Statement Checklist

Before publishing your accessibility statement, confirm:

  • Compliance status reflects the actual tested state of the site — not aspirational
  • Known issues are listed specifically, not vaguely
  • Testing methodology and date are accurate
  • Contact information for accessibility enquiries is current and monitored
  • Response time commitment is realistic and will be met
  • The "last reviewed" date is current
  • The statement is published at /accessibility and linked from the footer
  • The statement page itself is accessible — readable by screen readers, with correct heading structure and sufficient colour contrast

Why You Need One

An accessibility statement serves three purposes. It demonstrates governance maturity to funders and regulators. It provides a clear channel for users to report accessibility barriers. And it creates institutional accountability by documenting the standard the organisation has committed to meeting.

Most nonprofit websites do not have one. This is a gap that is easy to close and disproportionately valuable for credibility with institutional funders and regulatory compliance.

Where to Publish It

The accessibility statement should be linked from the footer of every page on the site — the same way your privacy policy is. Use the link text ‘Accessibility’ or ‘Accessibility Statement’. Do not bury it inside another page or make it only accessible from the About section.

Create it as a standalone page at a consistent URL such as /accessibility or /accessibility-statement.

How to Write It

Write in plain English. The audience is not accessibility specialists — it is users who need to know whether the site will work for them and how to get help if it does not. Avoid jargon, acronyms (except WCAG, which you should define on first use), and legalistic language.

The statement should be accessible itself. Ensure it has proper heading structure, sufficient colour contrast, and is navigable by keyboard. An inaccessible accessibility statement is a credibility problem.

Using the W3C Generator

The W3C provides a free accessibility statement generator at w3.org/WAI/planning/statements/generator. It walks you through each required section and produces a structured statement you can adapt for your organisation. This is a good starting point, though you should review and personalise the output rather than publishing it verbatim.

Maintaining the Statement

The accessibility statement is a living document. Update it when: the site undergoes significant changes, an accessibility audit identifies new issues or confirms remediation, the compliance standard is updated (WCAG 2.2 is already published and the EU is expected to reference it in a future EAA revision), or a user reports a barrier that reveals a previously unknown limitation.

Include the accessibility statement review in your quarterly website governance cadence. See How to Create a Website Governance Policy for the broader framework.

For the accessibility audit that establishes your baseline, see How to Audit Your Nonprofit Website for WCAG AA Compliance. For the regulatory context, see What the European Accessibility Act Means for NGO Websites.

A Blueprint Audit maps this across your own site, as part of a full governance diagnostic.

Further Reading

Related resources