Accessibility Statement Examples: What a Good One Actually Contains

A statement that satisfies regulators and actually helps users has six building blocks. The EU model for public-sector statements (under the Web Accessibility Directive, 2016/2102) formalises most of them, and they map cleanly onto private-sector obligations too. Here is each part with wording you can lift and edit.

1. A commitment and scope statement

Name the organisation, name the site or app it covers, and state the intent. Example: "Northwind Retail is committed to making www.example.com accessible to everyone, including people with disabilities. This statement applies to the public website; it does not cover our legacy partner portal at partners.example.com." Defining scope matters because a single statement rarely covers every property you own.

2. The conformance standard and level

Be specific about the standard. The defensible baseline is WCAG 2.2 at Level A and AA, referenced through EN 301 549, the harmonised European standard. Example: "This website aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, as referenced in EN 301 549." Avoid the empty "WCAG compliant" with no version or level — it tells a tester nothing and is impossible to verify.

3. A conformance status, stated honestly

Use one of three honest positions: fully conforms, partially conforms, or does not yet conform. "Partially conforms" is the most common and the most credible. Example: "This website partially conforms with WCAG 2.2 Level AA. 'Partially conforms' means most content meets the standard, but some parts described below do not yet fully meet it."

4. Known limitations (the non-accessible content)

This is the section that proves your statement is real. List specific, current barriers and, ideally, a remediation intent. Example: "We are aware of the following issues and are working to fix them: some older PDF brochures are not fully tagged for screen readers; the date picker in our booking form is difficult to operate with a keyboard alone (target: Q3 2026)." If you list nothing while claiming partial conformance, the section looks evasive.

5. Feedback and contact information

Give a real, monitored channel and a response expectation. Example: "If you encounter a barrier or need information in an accessible format, email access@example.com. We aim to respond within five working days." A contact route is not optional under EU rules — it is the mechanism users rely on when something blocks them.

6. Enforcement route and statement date

Tell users what to do if your response is inadequate, and date the statement. Example: "If you are not satisfied with our response, you can contact the national authority responsible for accessibility enforcement in your country. This statement was prepared on 26 June 2026 following a self-assessment, including an automated scan and a manual review against WCAG 2.2 Level AA." Each EU member state designates a body to handle complaints, so point to the national authority generally rather than naming a single regulator.

Here is how the six parts read as a single, compact statement — short enough to publish, specific enough to be credible:

"Northwind Retail is committed to making www.example.com accessible to people with disabilities. This statement covers the public website. We aim to conform to WCAG 2.2 Level AA, as referenced in EN 301 549, and we currently partially conform. Known issues: some archived PDF brochures are not fully tagged; the booking-form date picker is hard to use with a keyboard alone (target: Q3 2026). To report a barrier or request content in another format, email access@example.com — we respond within five working days. If you are not satisfied, you can contact the national accessibility-enforcement authority in your country. Prepared 26 June 2026 after an automated scan and a manual review against WCAG 2.2 Level AA."

Notice what makes it credible: a named level and standard, two concrete and current barriers, a real monitored address, an escalation route, and a date. Swap in your own organisation, URL, issues, and contact, and you have a publishable draft.

• Overclaiming. "Our site is 100% accessible" or "fully WCAG compliant" is almost never true and is the easiest claim to disprove. A partial-conformance statement with named issues is stronger than a perfect-sounding one.
• Naming no standard version. "WCAG compliant" without 2.2 and Level AA is meaningless. WCAG 2.2 added criteria such as 2.4.11 Focus Not Obscured (Minimum) (AA), 2.5.7 Dragging Movements (AA), 2.5.8 Target Size (Minimum) (AA), 3.2.6 Consistent Help (A), 3.3.7 Redundant Entry (A) and 3.3.8 Accessible Authentication (Minimum) (AA), and obsoleted 4.1.1 Parsing — so a statement that still cites WCAG 2.1 is now out of date.
• An empty known-issues section. Claiming partial conformance but listing zero limitations signals you never actually tested.
• A dead or generic contact. "Contact us" linking to a marketing form is not an accessibility feedback channel. Use a dedicated, monitored address.
• Never updating it. An undated statement, or one dated three years ago, suggests the page is decorative. Re-review after any significant redesign.
• Confusing an overlay widget with a statement. An accessibility toolbar is not a statement and does not establish conformance.

If you want the structure handled for you, the accessibility statement generator produces all six sections from a few inputs, including the EN 301 549 and WCAG 2.2 references and an enforcement paragraph.

The European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025 and covers many private-sector products and services — e-commerce, banking, e-books, transport ticketing and more. Its technical baseline is the same EN 301 549 standard that points to WCAG 2.2 Level A and AA, built on the four principles that content be Perceivable, Operable, Understandable and Robust.

A statement does not make you compliant on its own — the underlying site has to meet the criteria, including the basics like 4.5:1 contrast for normal text and 3:1 for large text (at least 18pt, or 14pt bold) and UI components. But the statement is the documented, public evidence that you assessed your site against the right standard, that you know your gaps, and that users have a route to report problems and escalate. Enforcement bodies look for exactly that paper trail; its absence is itself a red flag, and penalties for non-compliance vary by member state.

Treat the statement as the visible output of real work. Run a scan to find concrete issues, fix what you can, then document the rest. You can start a free check at AccessScan, review the criteria on the WCAG overview, and see how the standard fits the law on the European Accessibility Act page before you publish.

Publish the statement at a stable, predictable URL — /accessibility is the convention — and link to it from the footer of every page so users and assistive-technology testers can reach it from anywhere. A statement buried in a help centre that nobody can find does not give users the route the EAA expects.

Keep it current. Re-review after any significant redesign, new feature, or audit, and at least once a year. Each time, update three things together: the statement date, the conformance status, and the known-issues list. A statement that still names barriers you fixed months ago is as misleading as one that hides barriers that remain. The goal is a page that always reflects the site as it is today, not as it was at launch.