What is an accessibility statement, and does my store need one?

An accessibility statement is a public explanation of your website or service’s accessibility. A useful statement says what it covers, which standard or goal you use, how it was assessed, what does not yet work and how a customer can report a barrier or request help.

EU public-sector websites and apps have a specific accessibility-statement regime. Private online stores are in a different position: the European Accessibility Act requires covered service providers to make information available about how their services meet applicable accessibility requirements, but the exact format and national obligations should be checked. Do not assume either that every store needs the public-sector template or that private stores have no information duty.

The primary reader is a person trying to use your store, not an auditor. They may need to know whether a feature works with a keyboard or screen reader, whether an alternative is available, or who can help them complete a purchase.

W3C’s guidance on developing accessibility statements (opens in a new tab) recommends explaining functionality and known limitations in ordinary language. It says statements should include a commitment to accessibility, the standard applied and contact information, with known limitations and measures taken also advisable.

A good statement creates a feedback route and an accountability record. It does not erase barriers. Publishing “we meet WCAG” without a suitable evaluation can make the information less useful and less credible.

These documents can refer to one another, but they serve different readers and purposes. The statement should translate current accessibility information into something customers can understand and act on.

• It is not a privacy policy, which explains how personal data is collected and used.
• It is not terms and conditions, which govern the commercial relationship.
• It is not an accessibility audit or the evidence behind a conformance assessment.
• It is not a VPAT or Accessibility Conformance Report used mainly in procurement.
• It is not a certificate, warranty or promise that no customer will encounter a barrier.

The Web Accessibility Directive (opens in a new tab) applies to websites and mobile applications of EU public-sector bodies. It requires an accessibility statement for each covered website and app, including information about non-accessible content, alternatives, feedback and enforcement.

The European Commission adopted a model statement for that regime. Its implementing-act overview (opens in a new tab) explains that the model shows the level of compliance and includes reasons for inaccessible content, alternatives, a feedback mechanism and enforcement information.

A normal private online store is not a public-sector body merely because customers can visit its website. Copying the public-sector model and its enforcement wording without checking the store’s position can therefore produce inaccurate information.

The EAA covers ecommerce services and sets obligations for service providers. Article 13 of Directive (EU) 2019/882 (opens in a new tab) requires providers to prepare information explaining how their services meet the applicable accessibility requirements and to make that information available to the public in accessible written and oral forms.

Annex V describes information about the service, how it operates and how it meets the requirements. This is a real information obligation for covered providers, but the Directive does not simply say that every private ecommerce website must publish the same document used by public bodies under the separate Web Accessibility Directive.

National law can specify implementation, supervision and penalties. Business size and exemptions also matter. Confirm the correct content and format in each relevant country rather than relying on a generic template as legal advice.

Even where the precise legal format is uncertain or an exemption applies, a concise and accurate statement can help customers and improve internal work. It gives support staff somewhere to direct accessibility questions and gives product teams a public reason to keep limitations current.

Transparency is more useful than perfection. “Our checkout was tested on this date; these two limitations remain; contact us for assistance” gives a customer actionable information. “This site is 100% accessible” rarely does.

• The organisation, website, app or service covered by the statement.
• A plain-language commitment to accessibility.
• The accessibility standard or technical target being used.
• An honest conformance status supported by the assessment.
• The assessment method, scope and most recent review date.
• Known limitations, their user impact and available alternatives.
• Measures being taken and realistic remediation information.
• An accessible feedback and support route, plus expected response time.
• Compatibility or technical information only where it helps users.
• Applicable enforcement or escalation information only when verified.

Link the statement consistently from the site footer so customers can find it from any page.

Use this structure to gather accurate information. It is an editorial outline, not a legal template.

1. 1Scope: “This statement applies to [website, app or service].”
2. 2Commitment: explain the organisation’s accessibility goal in plain language.
3. 3Current status: state only the conformance level supported by appropriate evidence.
4. 4Assessment: name the manual, automated, internal or external methods used and the date.
5. 5Known limitations: describe the affected feature, customer impact and available alternative.
6. 6Improvements: describe funded or scheduled work without promising dates you cannot meet.
7. 7Feedback: provide an accessible contact route and a realistic response target.
8. 8Preparation and review: give publication and last-review dates.
9. 9Legal information: add jurisdiction-specific wording only after confirming it applies.

Do not write “fully accessible” or “100% WCAG compliant” because an automated tool returned a high score. W3C says evaluation tools cannot check all accessibility aspects, and conformance requires evaluation of complete pages and processes.

• A conformance level that has not been assessed across the stated scope.
• A claim that an overlay or scanner makes the site compliant.
• A statement copied from another organisation with irrelevant contacts or enforcement routes.
• Vague promises to fix everything with no feedback option.
• A claim that no limitations exist when testing has covered only one page.

Review it after major redesigns, platform migrations, checkout changes, significant third-party app updates or a new accessibility assessment. Feedback from customers can also reveal that a limitation or workaround needs updating.

W3C treats accessibility as ongoing organisational work: set objectives, assign responsibilities, evaluate regularly, track progress and incorporate feedback. A stale statement with a recent-looking badge is not a substitute for that process.

Run a free one-page accessibility scan (opens in a new tab) to identify common machine-detectable issues that may belong in a remediation plan. Then test complete journeys manually and establish the actual scope before making a conformance statement.

AccessPeek cannot determine whether your store legally needs a statement or prove that the service conforms. It can give you a clear first set of findings while you build the wider evidence.