EAA Accessibility Statement Requirements: What to Publish

A client sells online in the EU, someone has read that the European Accessibility Act needs "an accessibility statement", and the job lands on whoever looks after the website. Then the search starts for the official template, and there isn't one. The EAA tells a service provider what information to publish, not what the page has to look like.

This guide covers what the directive actually asks for, a structure you can reuse on any site, how to describe conformance without promising more than your testing supports, and how to keep the statement true after the next release.

What the EAA actually asks for

The obligation sits in two places in Directive (EU) 2019/882. Article 13(2) says service providers "shall prepare the necessary information in accordance with Annex V and shall explain how the services meet the applicable accessibility requirements." The same paragraph adds three conditions:

• the information is available to the public "in written and oral format";
• it is available "in a manner which is accessible to persons with disabilities";
• it is kept "for as long as the service is in operation".

Annex V then says where it goes and what it contains. The provider includes the information "in the general terms and conditions, or equivalent document". Where applicable, that information contains:

1. a general description of the service in accessible formats;
2. descriptions and explanations needed to understand how the service operates;
3. a description of how the relevant accessibility requirements in Annex I are met by the service.

Annex V point 3 adds one more thing that most published statements skip: the provider "shall provide information demonstrating that the service delivery process and its monitoring ensure compliance". In plain words, say how you keep it accessible, not only how accessible it was on the day you checked.

For a website, the Annex I requirement you are describing is the one in Section III: making websites and mobile apps "accessible in a consistent and adequate way by making them perceivable, operable, understandable and robust". Those are the four principles of WCAG, which is why every statement ends up talking about WCAG criteria.

Three things the directive does not do: it does not prescribe a page title, a fixed set of headings, or a conformance label. The measures have applied since 28 June 2025 (Article 31(2)), and each member state's transposing law can add its own detail, so check the national law for every country the service is provided in. Microenterprises providing services are exempt from the service requirements under Article 4(5); the guide to whether the EAA applies walks through that test.

Why people expect a template

Public sector sites in the EU do have one. Commission Implementing Decision (EU) 2018/1523 sets a model accessibility statement under the Web Accessibility Directive, with mandatory sections for compliance status, non-accessible content, how the statement was prepared, feedback and contact details, and the enforcement procedure. It was written for public bodies, not shops or banks, but its structure is sound, and borrowing it is the easiest way to cover everything Annex V asks for.

The sections a usable statement has

Combine Annex V, the public sector model and the W3C WAI guidance on accessibility statements and you get a structure that works for a store, a booking site or a SaaS app:

Link the statement from the footer of every page and from the terms and conditions, since Annex V names that document. The page itself has to be accessible: a statement published as a scanned PDF fails the very requirement it describes. If you do provide a PDF, run it through the PDF accessibility checker first.

W3C publishes a free accessibility statement generator. It makes a good first draft; add the Annex V service description and the monitoring section yourself.

How to state conformance without overclaiming

The most common mistake is one confident sentence: "This website is fully compliant with WCAG 2.2 AA." It is almost never supported by the testing behind it. Full conformance means every page and every criterion passes, and an automated scan cannot tell you that. Automated tools catch many failures, but a large share of WCAG criteria need a person to judge, such as whether alt text is meaningful or whether focus order makes sense. The accessibility audit checklist separates what tools catch from what needs a person.

Use the three levels from the public sector model, because they map honestly onto real sites:

• Fully conforms: only after a full audit, automated and manual, found no open failures in scope.
• Partially conforms: the right answer for most sites. Some content does not yet meet the standard, and you list it.
• Does not conform: most of the site fails, or you have not tested it. Say so and give a date for the work.

Also name what you tested and how. "Tested on 14 October 2026 with automated checks on 40 key pages and a manual keyboard and screen reader pass of checkout" is a claim someone can check. "Regularly audited by experts" is not.

A worked example with open failures

Here is honest wording for a fictional store with three known problems. Adapt the names, dates and findings to your own audit; do not copy the findings.

<!-- Broken: an overclaim the audit does not support -->
<h2>Conformance status</h2>
<p>Our website is 100% accessible and fully compliant
   with the European Accessibility Act.</p>

<!-- Fixed: a status the audit supports, with the gaps listed -->
<h2>Conformance status</h2>
<p>shop.example.com partially conforms to WCAG 2.2 Level AA.
   Partially conforms means some content does not yet meet
   the standard. The known problems are listed below.</p>

<h2>Known limitations</h2>
<ul>
  <li>The size guide opens in a pop-up that keyboard users
      cannot close without reloading the page (WCAG 2.1.2).
      The same table is on each product page under "Sizes".
      Planned fix: December 2026.</li>
  <li>Some older product photos have no text description
      (WCAG 1.1.1). We are adding descriptions to the
      remaining photos, newest products first.</li>
  <li>The delivery date picker cannot be used with a screen
      reader (WCAG 4.1.2). You can type the date instead,
      or choose a date with our support team.</li>
</ul>

Each item says what fails in plain words, gives the criterion, offers a workaround and says when it gets fixed. If you cannot commit to a date, say what you are doing instead. A dated promise you miss makes the statement untrue.

Avoid writing "compliant with the European Accessibility Act" at all. The law is met or not met by the service, and that is decided by the authorities responsible for checking services, not by your own page. Describe the standard you test against and the results, and let that speak.

The feedback and escalation route

The second common mistake is a statement with no way to report a problem, or one that sends people to a contact form that is itself inaccessible. A usable feedback section has:

• an email address that reaches a person, not only a form;
• a phone number, which also covers the "oral format" in Article 13(2) for people who cannot read the page;
• a stated response time, such as "we reply within five working days";
• an offer to provide information in another format on request.

Then name where people can escalate. Each member state designates authorities responsible for checking that services comply, and a user who gets no answer from you should be able to find them from your page. Look up the authority in the transposing law for each country you sell in and link it by name. Check the form you send people to with the form label checker and the keyboard and focus checker before you publish.

Decide who reads those messages. An unmonitored feedback address turns a fixable bug into a complaint to an authority.

Keeping the statement true after the next release

Article 13(3) requires procedures so the service "remains in conformity" as it changes, and it names changes to the service, to the requirements and to the harmonised standards. A statement is accurate for the build you tested. Every release, theme update and new plugin can make it false.

Standards are moving too. ETSI published EN 301 549 V4.1.1 in September 2026, and its web clauses now point at WCAG 2.2. As the EN 301 549 v4.1.1 guide explains, no version is cited in the Official Journal under the EAA yet. If a statement names WCAG 2.1 or EN 301 549 V3.2.1, review whether that is still the standard you test against.

Build the review into the work you already do:

• On every release: rescan the pages the release touched and check whether any new failure belongs in "Known limitations".
• When a limitation is fixed: remove it from the statement in the same deploy, so the list stays honest in both directions.
• At least once a year: repeat the manual pass, update the "last reviewed" date, and reread the national law for changes. The public sector model asks for a yearly review too.

Automated monitoring helps with the first item. AccessGuard, for example, rescans the pages you add on a daily, weekly or monthly schedule and alerts you to new failures, which tells you when the statement needs a new line. It runs automated WCAG 2.2 AA checks, so it cannot confirm conformance on its own; the manual pass still decides what the statement says.

Checklist before you publish

• Scope names every domain and app the statement covers, including third party checkout.
• The service is described in plain words (Annex V point 1).
• The standard and level are named, and the status matches the audit: usually "partially conforms".
• Every known failure is listed in plain words, with the criterion, a workaround and a plan.
• The testing method and date are stated, and so is the process that catches regressions (Annex V point 3).
• Email and phone reach a person, with a response time.
• The national authority for escalation is named and linked for each country.
• The page is linked from every footer and from the terms and conditions, and the page itself passes a scan.
• Someone owns the review on each release and once a year.

Before you write the limitations section, find out what is actually open. Run a free accessibility scan on the pages that matter most, then do the manual pass for what a scan cannot judge. The statement is only as honest as the testing behind it.