European Accessibility Act

How to Write an EAA-Compliant Accessibility Statement (Article 13 + Annex V)

Last updated May 24, 2026

An accessibility statement is a public, dated declaration of how accessible a digital service is, what it does not yet do well, how users can report problems, and what they can do if you do not respond. Publishing one is good practice everywhere, and for any private-sector service in scope of the European Accessibility Act (Directive 2019/882) it is also a legal expectation. Article 13 of the EAA requires economic operators to provide information on how their service meets the accessibility requirements, and to make that information available to the public in written and oral format, in a manner accessible to persons with disabilities. Annex V § 1 adds that this information should be included in the general terms and conditions, or equivalent document: a dedicated public accessibility statement page (e.g. at /accessibility) is the cleanest and most discoverable implementation, but the statute does not prescribe a URL or page name. Annex V § 1 itself is narrow — it lists only three required elements: (a) a general description of the service in accessible formats, (b) descriptions and explanations necessary for the understanding of the operation of the service, and (c) a description of how the relevant accessibility requirements set out in Annex I are met by the service. Many additional fields commonly seen in modern accessibility statements — conformance standard, economic-operator identification, non-conformity reporting procedure, and the relevant supervisory authority — come from national transpositions or from the older Web Accessibility Directive 2016/2102 for public-sector bodies, not from Annex V itself. (For the same reason, the obligation to publish a formal statement on a website at a fixed URL is a WAD pattern, not an EAA requirement.) Build the additional fields in anyway — supervisory authorities and the broader market expect them — just do not present them as bare-minimum EAA requirements.

Three statement regimes get conflated in practice and they are not interchangeable. The EAA statement under Article 13 + Annex V is the one most private B2C services in the EU now need. The WAD statement under the older Web Accessibility Directive (2016/2102) and Implementing Decision 2018/1523 applies to public-sector bodies and has its own model template prescribed by the Commission. The voluntary statement common in US private-sector practice is not legally required, but it is repeatedly cited as evidence of good-faith remediation in demand-letter responses (see our demand-letter playbook). The fields overlap heavily; the obligations do not. This guide focuses on the EAA flavour, with notes where WAD or voluntary practice diverges.

When you need one (and what kind)

If you place a service covered by the EAA on the EU market — most B2C ecommerce, banking, transport booking, e-readers, and consumer telecoms qualify — you should publish an EAA-aligned statement that satisfies Article 13 and Annex V. See the EAA scope guide for whether your service is in scope and for the micro-enterprise carve-out. If you are a public-sector body in the EU, you fall under the WAD instead and must use the model statement set out in Implementing Decision 2018/1523. If you are a US private-sector operator, no statute requires a statement, but publishing one strengthens defensible-remediation evidence and is treated as a credible signal by plaintiffs' counsel.

The EU's own institutional statements are useful worked examples here, since they were drafted by the regulator's drafters. Compare the European Commission statement and the broader European Union statement of EU institutions linked in the sources below: same field set, similar phrasings, slightly different enforcement-route wording per institution.

The fields every EAA statement should contain

1. Identification of the service and economic operator.Legal entity name, registered address, company number, and the URL(s) the statement covers. For groups, name the operator that places the service on the market — not just the brand.
2. Statement of conformance. Most honest statements declare partial conformance with WCAG 2.1 Level AA via EN 301 549 v3.2.1. The EU institutions use exactly this language. Do not claim full conformance unless you have a recent third-party audit that supports it.
3. Known accessibility limitations and why. A specific, honest list of issues users will hit, plus the reason: technical constraint, third-party dependency, or a documented disproportionate-burden assessment. Vague language here is the most common red flag.
4. Dates.Date of publication and date of last review. Annex V itself does not require dates, but supervisory authorities and the WAD pattern for public-sector statements both expect a current statement — a stale date is itself a signal of non-conformance.
5. Feedback / complaint mechanism. A named contact (email address that is monitored, plus an alternative such as a phone number), and a stated response timeframe. The EU Commission targets fifteen business days; W3C suggests five. Pick a number you will hit.
6. Enforcement / escalation route.The national market-surveillance authority for the EAA in the member state that hosts your statement. In Belgium that is the FPS Economy; in Germany the MLBF AöR (the joint Länder authority in Magdeburg, operational since September 26, 2025); in Spain the relevant Ministry channel under Ley 11/2023.
7. Scope statement for paid-for or third-party content. Make clear what is in and out of scope (third-party PSP pages, user-generated content, embedded widgets), and what conformance evidence you have requested from those providers.
8. Alternative formats.Where an accessible alternative exists (tagged PDF on request, plain HTML invoices), say so. This is consistent with Annex V (a) — a general description of the service in accessible formats — and is also a common WAD-style addition that supervisory authorities expect.
9. EAA-specific service information.A description of how the service supports assistive technology and the accessibility features built into the service. These fields support an Annex V (c) description — how the relevant Annex I requirements are met — without being literal Annex V minima themselves; they are good practice and align with the information regulators ask for.

A short, honest example statement

The W3C's minimal-example model is the smallest viable structure that still maps to Annex V. The template below is deliberately spare: copy it, replace the bracketed fields, and publish at a stable URL such as /accessibility.

<!-- /accessibility -->
<h1>Accessibility statement</h1>

<p>
  [Legal entity name] is committed to making
  <a href="https://[your-domain]">[your-domain]</a> accessible to as many
  people as possible, including users with disabilities.
</p>

<h2>Compliance status</h2>
<p>
  This website is <strong>partially conformant</strong> with the
  <a href="https://www.w3.org/TR/WCAG21/">Web Content Accessibility
  Guidelines (WCAG) 2.1, Level AA</a>, which is the technical reference
  for EN 301 549 v3.2.1 and therefore for the
  <a href="https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en">
  European Accessibility Act</a>. "Partially conformant" means that some
  parts of the content do not yet fully conform to the standard.
</p>

<h2>Known accessibility limitations</h2>
<ul>
  <li>
    <strong>Checkout step 3 keyboard trap:</strong> the date picker is
    not operable with a keyboard alone. We plan to fix this by
    [YYYY-MM-DD].
  </li>
  <li>
    <strong>Some PDF invoices:</strong> documents issued before
    [YYYY-MM-DD] are not tagged for screen-reader use. Accessible
    alternatives are available on request.
  </li>
</ul>

<h2>Preparation of this statement</h2>
<p>
  This statement was prepared on [YYYY-MM-DD] and last reviewed on
  [YYYY-MM-DD]. It is based on an automated scan of [N] pages plus a
  manual review of the critical user journeys (registration, search,
  product detail, checkout, account).
</p>

<h2>Feedback</h2>
<p>
  We welcome your feedback on the accessibility of this site. If you
  encounter a barrier, please contact <a href="mailto:accessibility@[your-domain]">
  accessibility@[your-domain]</a> or +32 [phone]. We aim to respond
  within 15 business days and to provide an accessible alternative
  where the original content is not usable.
</p>

<h2>Enforcement procedure</h2>
<p>
  If we do not respond within a reasonable time, you may contact your
  national market-surveillance authority for the European
  Accessibility Act in [member state]. Contact details are published
  by your government.
</p>

A fuller ecommerce example

A Belgian online store will typically need to be more explicit about scope, the standard targeted, and the supervisory authority. The example below is sized for a mid-market merchant and is written in the same calm, specific tone the Commission's own statement uses.

Accessibility statement for shop.example.be

Last reviewed: 2026-05-24
Next scheduled review: 2026-08-24

Operator
  Example BV, Rue de la Loi 1, 1000 Brussels, Belgium
  Company number: BE0123.456.789
  Email: accessibility@example.be
  Phone: +32 2 000 00 00

Scope of this statement
  This statement covers the consumer-facing online store at
  https://shop.example.be, including the product catalogue, search,
  product detail pages, account area, basket, and checkout. It does
  NOT cover:
    - third-party payment pages hosted by our PSP after redirect
    - the supplier portal at https://suppliers.example.be (B2B)
    - downloadable user-generated PDFs published by third parties

Standard targeted
  EN 301 549 v3.2.1, which references WCAG 2.1 Level AA. This is the
  harmonised European standard cited by the European Accessibility
  Act (Directive 2019/882).

Conformance status
  Partial conformance. Most pages and templates conform to WCAG 2.1
  Level AA. The known exceptions are listed below. Conformance is
  assessed combining automated scanning (axe-core + IBM Equal Access
  via SweepHound) and manual keyboard + screen-reader spot checks on
  five critical journeys.

Known accessibility limitations
  1. Product-image zoom: the zoom overlay traps focus on touch
     devices using VoiceOver. We are migrating to a new viewer in
     Q3 2026.
  2. Variant swatches: some colour swatches do not announce the
     selected state to screen readers. A fix is scheduled for
     2026-06-30.
  3. Marketing emails: a small number of legacy templates do not
     meet contrast on the call-to-action button. New templates do.
  4. Historical PDF invoices issued before 2025-09-01 are not
     tagged. Accessible HTML alternatives are available within
     fifteen business days on request.

Disproportionate-burden claim
  None at this time.

Content not covered by EU law on accessibility
  Third-party widgets (PSP, chat) are out of scope of our control
  but we have requested conformance evidence from those providers.

Preparation of this statement
  Prepared on 2026-05-24 using SweepHound's monitoring archive and
  a manual review by our accessibility lead. Reviewed quarterly and
  after every major release.

Feedback and contact
  accessibility@example.be — typical reply within ten business days.
  We can also be reached by phone (above) or by post at the
  registered office.

Enforcement
  If we do not respond satisfactorily, contact the FPS Economy
  (SPF Economie) — the Belgian market-surveillance authority for
  the European Accessibility Act transposition (Loi du 9 octobre
  2022). Filing instructions: https://economie.fgov.be/

What NOT to say

The single biggest mistake is claiming WCAG conformance you cannot evidence. The FTC's April 2025 consent order against accessiBe turned on exactly that — representing that an automated product can make any site WCAG-compliant, without proof. See our overlays guide for why this matters. Avoid:

• “Fully WCAG 2.1 AA compliant” unless a recent independent audit supports it. Prefer “partially conformant with WCAG 2.1 Level AA”, the phrasing the EU institutions themselves use.
• Omitting known issues. A limitations list is not a literal Annex V field, but it is consistent with Annex V (b) — the descriptions and explanations necessary for understanding the operation of the service — and supervisory authorities expect it. An empty list on a non-trivial site is implausible and reads as evasive.
• Burying the contact email or routing reports through a generic web form with no human owner. The feedback channel is the most-checked field by regulators and disability-rights organisations.
• “We use an accessibility widget, so we are compliant.” The widget is not a substitute for source-level conformance, and saying so in a public statement is now actively cited in complaints.

How to keep the statement current

Treat the statement as a living artefact, not a one-off deliverable. Review on a fixed schedule (quarterly is a reasonable floor), after every major release or platform migration, and any time a third-party dependency changes its own accessibility posture. Tie the review to a recurring monitoring scan so the “last reviewed” date is always backed by fresh evidence. If you cannot point to a scan or manual review inside the last three months, the statement has effectively lapsed.

How automated checks vs manual review affect what you say

Per Deque's Automated Accessibility Coverage Report, axe-style automation identified 57.38% of issue instances by volumein their dataset (2,000+ audits across 13,000+ pages and ~300K issues). That is a dataset-specific volume measure, not a universal “automation catches 57.38% of all WCAG issues” rule, and the remainder is not automatically equivalent to “the issues that require manual review” — it just means the engine did not flag them. Your statement should reflect what you have actually done. If automation is all you have, say so — “conformance assessed by automated scanning of [N] pages with axe-core and IBM Equal Access” is honest and verifiable. If you have layered manual keyboard and screen-reader checks on the critical journeys, name them explicitly. Statements that quietly imply full manual audit when none has happened are the ones that fall apart fastest under scrutiny.

How SweepHound's auto-generated statement works

SweepHound generates an accessibility statement from the most recent dual-engine scan of your site. The conformance line is written from the actual finding set — never “fully compliant”, always the specific level the data supports. Known limitations are drawn from the live violation archive, so the list reflects what is actually on the site today rather than a template guess. Dates of publication and last review update automatically on each scheduled scan, and the statement is published at a stable URL you control. You can layer in manual notes — the journeys you have keyboard-tested, the third-party widgets you have requested evidence from, the disproportionate-burden assessments your counsel has signed off — without losing the auto-generated baseline. Combined with the EAA scope guide and an honest scan cadence, it supports your EAA readiness without making claims your data does not back.

To publish a first dated statement today, start a free scan and use the generated draft as the baseline for your manual review. Plans, scan cadences, and the recurring monitoring that keeps the “last reviewed” date credible are on the pricing page. When you are ready to maintain the statement as a living artefact rather than a one-off, create an account and schedule the first recurring scan.