Skip to content

How to Publish a WCAG Accessibility Statement

If you run a website or app in the EU, UK, or Canada, an accessibility statement isn't optional — it's the law. Even where it isn't legally required, publishing one is the single cheapest way to reduce your ADA litigation risk and signal to users that you take inclusion seriously.

An accessibility statement is a public declaration of your conformance level, what you've done to meet it, and how users can contact you if they encounter barriers. This guide covers what to include, which jurisdictions require one, and how to keep it from going stale (which is where most organisations fall down).

Who Needs an Accessibility Statement

The short answer: most organisations with a digital presence. Public sector bodies in the EU, UK, Switzerland, Norway, and Australia must publish one. Private companies selling digital products in the EU have been required to since June 2025 under the European Accessibility Act. US federal agencies need one under Section 508. Canadian federally regulated organisations need one under the Accessible Canada Act.

For US private companies, it isn't explicitly mandated — but the ADA litigation landscape makes it strongly advisable. A published statement with a clear feedback mechanism is one of the best defences against demand letters.

Even where not legally required, a statement signals to users and procurement teams that accessibility is taken seriously. That alone can be the difference between winning and losing a contract.

What to Include

A comprehensive accessibility statement covers the following elements. Some are legally required in specific jurisdictions; others are best practice.

1. Commitment Statement

A clear, unambiguous statement that your organisation is committed to making its digital services accessible to all users, including people with disabilities.

2. Conformance Level

State the standard you are targeting — typically WCAG 2.2 Level AA — and the date of your most recent conformance evaluation. If some content does not meet the stated level, be honest about the gap.

3. Accessibility Features Implemented

List the key accessibility features your site or app includes. This helps users understand what to expect and signals that accessibility was considered during development.

Examples: keyboard navigation, screen reader compatibility, resizable text, colour contrast meeting WCAG thresholds, skip-to-content links, descriptive alternative text for images, captions on video content.

4. Known Limitations

No site is perfectly accessible. Being transparent about known barriers — and what you are doing to fix them — builds trust. Users would rather know about a limitation than discover it when they cannot complete a task.

Examples: older PDF documents may not be fully accessible, third-party embedded content may have variable accessibility, live-streamed video may have delayed captions.

5. Testing Methodology

Explain how you evaluate accessibility. Reference automated tools used, manual testing processes, assistive technology testing, and any user testing conducted. Include the date of the last evaluation.

6. Feedback Mechanism

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

  • An email address or contact form dedicated to accessibility feedback
  • A telephone number (where applicable)
  • A response time commitment (typically within 5 business days)

7. Enforcement and Escalation

In jurisdictions where accessibility is a legal right (EU, UK, Canada), you must explain how users can escalate if they are unsatisfied with your response. This typically means contacting the national enforcement body — for example, the relevant equality commission or ombudsman.

8. Date of Last Update

An accessibility statement is not a static document. It must be reviewed and updated whenever significant changes are made to the site or when the conformance level changes. The statement must include the date of the most recent review.

Accessibility Statement Template

# Accessibility Statement for [Organisation Name]

## Commitment
[Organisation Name] is committed to ensuring digital accessibility for people with disabilities. We are continually improving the user experience for everyone and applying the relevant accessibility standards.

## Conformance Status
The [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/) define requirements for designers and developers to improve accessibility for people with disabilities. This website [partially conforms / conforms] to WCAG 2.2 Level AA. [Partially conforms] means that some parts of the content do not fully conform to the accessibility standard.

## Accessibility Features
- Keyboard navigation and visible focus indicators
- Alternative text for all meaningful images
- Captions and transcripts for video content
- Sufficient colour contrast throughout
- Resizable text up to 200% without loss of content
- Skip-to-content navigation links
- Semantic heading structure for screen reader navigation

## Known Limitations
- [List specific known issues and planned remediation dates]
- PDF documents published before [date] may not be fully accessible
- Third-party embedded content may have variable accessibility

## Assessment Methodology
Accessibility is assessed through:
- Automated testing using [tool name] — run on every deployment
- Manual keyboard and screen reader testing — per major release
- Annual expert audit by [external auditor name]

## Feedback
We welcome your feedback on the accessibility of this website. Please contact us:

- Email: [accessibility@example.com]
- Phone: [number]
- We aim to respond within 5 business days.

## Enforcement (EU/UK public sector)
If you are not satisfied with our response, you may contact:

- [National enforcement body name and contact details]

## Last Updated
This statement was last reviewed on [date].

Keeping Your Statement Current

Here's the thing most organisations miss: an outdated statement is worse than none at all. A page that says "we conform to WCAG 2.1 AA" without a recent evaluation date — or that lists features the site dropped years ago — undermines trust and, in regulated jurisdictions, counts as a compliance failure in itself.

  • Review after every major site release — Update the conformance status and feature list
  • Re-evaluate at least annually — Run a full expert audit and update testing dates
  • Update when standards change — When you adopt a new WCAG version or when legal requirements shift
  • Remove outdated claims — If a feature is dropped or a limitation is fixed, reflect that in the statement

Going Beyond the Statement

An accessibility statement is the minimum. Organisations serious about inclusion also:

  • Publish accessibility metrics or an annual accessibility report
  • Provide accessibility documentation for their product (VPAT / Accessibility Conformance Report)
  • Train all design, development, and content teams on WCAG requirements
  • Integrate accessibility checks into their CI/CD pipeline
  • Include accessibility requirements in procurement and vendor evaluation

The most effective accessibility programmes treat the statement not as a compliance checkbox but as a public commitment to an ongoing process of improvement.

Hosting Your Accessibility Statement

Where you publish your statement matters. A static page buried in your site footer that goes years without updates is common but counterproductive. Some organisations now host their accessibility statement on a dedicated compliance page alongside other public declarations — product safety, GDPR, sustainability — keeping all compliance documentation in one verifiable place with a single URL that can be linked from the footer, site map, and accessibility shortcuts.

This approach makes it easier to maintain, audit, and reference in procurement responses and legal proceedings.