Most accessibility statements on the web are a paragraph saying the company is committed to accessibility, followed by a support email that goes nowhere. That paragraph is not a statement. Under the European Accessibility Act it is closer to a liability, because it makes a claim the site does not support and it demonstrates that nobody tested anything.
The statement is a separate obligation from conformance. You can be substantially conformant and still be non compliant for not publishing one properly. And unlike remediation, it is a document, which means it is the cheapest item on the list and the one most often skipped anyway.
The counterintuitive part
A statement that admits known gaps reads better to an authority than one claiming full conformance.
This surprises clients every time, so it is worth spelling out. An investigator who reads a claim of full WCAG 2.1 AA conformance and then finds an unlabeled search field in ninety seconds now has two findings: the barrier, and a false statement. A statement that says our product filters currently have keyboard navigation issues, scheduled for remediation in Q4, describes the same barrier as a known, owned, scheduled item.
One is a company that got caught. The other is a company doing the work. The underlying site is identical.
What has to be in it
The EAA framing expects a statement to cover, at minimum, the following. National transpositions vary, so check your target member states, but this set is the common core.
- The service provider’s name and contact details.
- A description of how the service meets accessibility requirements, in terms a non specialist can follow.
- Any aspects not covered, including anything excluded on grounds of disproportionate burden or fundamental alteration, with the reasoning.
- An accessible support route, meaning a channel that itself works for the people most likely to use it.
That last one catches people. A contact form that fails the same criteria as the rest of the site is not an accessible support route. Give a plain email address alongside whatever form you prefer.
A structure that works
This is the shape I use. Adapt the wording, keep the sections.
1. Scope
Name exactly what the statement covers. The web storefront at example.com, the iOS and Android apps, or only one of them. If your mobile app was never assessed, say so here rather than letting a reader assume it was included.
2. Conformance status
State the standard and the honest level. The accepted vocabulary is fully conformant, partially conformant, or not conformant. Most real sites are partially conformant, and writing that is not an admission of failure, it is the expected answer.
Reference EN 301 549 and the WCAG version and level it incorporates, since that is the standard an EU authority will measure against.
3. Known limitations
The section that does the actual work. For each item: what the barrier is, who it affects, what the workaround is if any, and when it will be fixed.
Write it in user terms, not in criterion numbers. Compare these two.
- Weak: Some content does not meet SC 1.4.3.
- Strong: Promotional banners on the home page use light grey text on white that is hard to read for people with low vision. Product and checkout pages are unaffected. Being corrected in the design system update planned for October 2026.
The second one tells a regulator you know your own site. The first tells them you ran a scanner and pasted the output.
4. Third party content
Payment iframes, review widgets, chat, embedded maps and video. Name them, state their status if you know it, and describe what you have asked the vendor for.
Being unable to fix a vendor’s iframe does not remove it from your scope, but documented pressure on a supplier is a materially different position from silence.
5. How the assessment was done
Say what you actually did. Automated scanning with a named tool, manual keyboard testing, screen reader testing with which software on which platform, and whether users with disabilities were involved. Include the date.
If it was scanner only, say scanner only. Overstating your methodology is the easiest thing in the entire document to disprove.
6. Feedback and escalation
A monitored email address, a response time you will actually meet, and the enforcement body a user can escalate to in the relevant country. Several member states require naming that route.
Route that mailbox to a real person. An unanswered accessibility complaint is frequently the first step of the case that follows.
7. Dates
When the statement was prepared, when it was last reviewed, and when the underlying assessment was done. A statement dated two years ago undermines everything above it.
Keeping it true
A statement is a claim about a system that changes weekly. Every theme update, new banner, plugin, and campaign landing page can break conformance, and the moment it does your published document becomes inaccurate.
Two habits keep it honest without much overhead. Put axe-core in CI so regressions surface as build failures rather than as discoveries months later. And review the statement on a fixed schedule, quarterly is reasonable, with a named owner rather than a shared responsibility that belongs to nobody.
Where to publish it
Linked from the footer of every page, at a stable URL, in plain HTML. Not as a PDF, which is an unhelpful format for exactly the audience the document exists for. And write it in the languages you sell in, since a Spanish speaking customer in Spain should not have to read your English statement to learn how to complain.
I am an engineer, not a lawyer. Requirements vary by member state and change over time. Use this as a technical structure and get local counsel on wording before publishing.
I run WCAG audits and write the findings up in a form you can publish. Write to me at serbeldiaz@gmail.com.
No responses yet