Accessibility statement for WordPress: template + EN 301 549 mapping

#Accessibility statement for WordPress: template + EN 301 549 mapping

An accessibility statement is a separate legal deliverable from a WCAG audit. You can pass every automated scan on a WordPress site and still be non-compliant with BFSG or the EU Accessibility Act, because both require the statement itself: a published conformance status, the standard you tested against, a list of known limitations, and a working feedback mechanism a visitor can use to file a complaint. This article is a supporting piece in the WCAG 2.2, BFSG, and EU Accessibility Act compliance stack, focused specifically on the statement document and how its sections map to EN 301 549, the European standard procurement teams actually cite.

#What you need to publish, in short

• A dedicated, footer-linked page, not a paragraph inside your privacy policy.
• A conformance status: full, partial with named exceptions, or non-conforming.
• The standard you tested against: WCAG 2.2 AA in practice, referenced against EN 301 549 for procurement audiences.
• A list of known limitations with, where possible, a remediation date.
• A feedback contact that actually reaches a monitored inbox, plus an enforcement or escalation path.
• A preparation date and review cadence, because “we tested this once in 2023” is not a current statement.

None of this replaces a technical audit. It documents the result of one. If you have not run a WCAG 2.2 AA audit yet, the statement will either overclaim conformance or read as a placeholder, and both outcomes attract more scrutiny than having no statement at all.

#When an accessibility statement is mandatory in the EU

Three overlapping legal bases put an accessibility statement on a WordPress operator’s obligation list, and they do not all apply to the same audience.

Directive (EU) 2016/2102, the Web Accessibility Directive, requires public-sector bodies to publish and regularly update an accessibility statement for every website and mobile app they operate. This predates the EU Accessibility Act and applies regardless of sector; a municipal WordPress site, a public university’s blog, a government agency’s press portal are all in scope, independent of anything discussed below.

The European Accessibility Act (Directive 2019/882), which applies from 2025-06-28, extends comparable obligations to private-sector operators of specific product and service categories: e-commerce, banking services, transport, e-books, and others enumerated in the directive’s Annex I. It does not mandate the exact statement format Directive 2016/2102 does, but member-state transpositions generally require conformity documentation and a functional complaint channel as part of market surveillance.

National transpositions fill in the operational detail. Germany’s BFSG requires businesses in scope to make accessibility information available, and its enforcement structure (market surveillance authorities plus the Schlichtungsstelle BGG at federal level) expects a documented process for handling complaints, which in practice means a published statement is the easiest way to demonstrate the process exists before a complaint ever arrives.

The exemptions worth knowing before drafting anything: microenterprises (fewer than 10 employees, annual turnover or balance sheet under EUR 2 million) are exempt from several EAA service obligations, though the exemption is narrower for product manufacturers. Public bodies get no size exemption under Directive 2016/2102. Disproportionate-burden claims exist under both regimes but require a documented assessment, not a footnote saying “not applicable.”

The pillar article on WCAG 2.2, BFSG, and the EU Accessibility Act covers the full compliance stack, including the audit cadence that produces the conformance status this statement documents.

#EN 301 549 vs WCAG 2.2 AA: what procurement actually asks for

WCAG 2.2 AA is what your development team tests against. EN 301 549 is what a procurement officer, tender document, or public-sector audit cites, because it is the harmonized European standard for ICT accessibility broadly, not only web content.

The version currently in legal effect is EN 301 549 V3.2.1, published in March 2021 and cited in the Official Journal of the EU under Directive 2016/2102 via Commission Implementing Decision (EU) 2021/1339. Its web chapter, Chapter 9, incorporates WCAG 2.1 Level A and AA success criteria by reference. A revision that incorporates WCAG 2.2 has been in drafting inside the joint ETSI/CEN/CENELEC technical body, with 2026 publication expected under the European Commission’s standardisation request M/587, but it is not yet the version cited in the Official Journal.

This creates a practical gap that procurement documents rarely resolve cleanly: the legally referenced baseline is WCAG 2.1 AA, while the current best-practice target, and what most agencies (including ours) actually build to, is WCAG 2.2 AA. Because 2.2 is a strict superset of 2.1 with nine additional success criteria, testing and documenting against 2.2 AA also satisfies the 2.1 AA baseline EN 301 549 currently cites. There is no version-mismatch risk in building to the newer standard; the risk runs the other way, if you build only to 2.1 and the EN 301 549 revision publishes mid-contract.

Beyond the web chapter, EN 301 549 has eleven other chapters. The three that matter for a typical WordPress deployment beyond web content itself:

• Chapter 10, non-web documents. PDFs, spreadsheets, and presentations published through the site (price lists, annual reports, tender documents) need proper tagging, reading order, and accessible tables, independent of how accessible the surrounding page is.
• Chapter 11, software. Relevant when the WordPress admin itself is the product being assessed, for example a public-sector editorial team using the block editor as their authoring tool, or a custom plugin exposing a form interface to end users.
• Chapter 12, documentation and support services. Help pages, onboarding guides, and support channels linked from the site are expected to meet the same accessibility bar as the main content, and support communication itself needs to be available through more than one channel.

#Template sections with copy-ready headings

The section order below is the structure that appears across most EU accessibility statements built on the EN 301 549 / EAA / BFSG framework. It is illustrative: fill it with your actual audit results, not placeholder text, and have it reviewed by whoever handles compliance sign-off for your organisation before publishing.

# Accessibility statement for [site name]

## Conformance status
[Site name] is [fully conformant / partially conformant / not conformant]
with WCAG 2.2 level AA, assessed against the requirements referenced in
EN 301 549. [Choose one:]
- Fully conformant means the content fully conforms to the standard without
  exceptions.
- Partially conformant means some parts of the content do not fully conform
  to the standard, as listed under "known limitations" below.

## Applicable standard
This statement is based on a self-assessment / an assessment carried out by
[assessor name or role] on [date], against:
- Web Content Accessibility Guidelines (WCAG) 2.2, level AA
- EN 301 549, [version], Chapter 9 (Web)
[List Chapters 10, 11, 12 here only if non-web documents, software, or
support services were also assessed.]

## Known limitations
The following content is not yet fully accessible:
- [Specific limitation, e.g. "the embedded booking widget on /contact/
  cannot be operated by keyboard alone"], affecting [which success
  criterion], remediation target: [date or "under review"].
- [Repeat per known issue. Do not summarise multiple issues into one vague
  line; list them individually.]

## Preparation of this statement
This statement was prepared on [date] and last reviewed on [date]. It was
prepared based on [self-assessment / third-party audit], covering [scope:
e.g. "the public-facing pages under example.com, excluding third-party
embedded content"].

## Feedback and contact information
If you encounter an accessibility barrier on this site, contact us:
- Email: [monitored address]
- [Optional: phone, contact form URL]
We aim to respond within [X] working days.

## Enforcement procedure
If you are not satisfied with our response, you can escalate to:
[National enforcement body or dispute-resolution body, with URL, relevant
to the jurisdiction the operator is based in or serving.]

## Technical specifications
This site relies on the following technologies for conformance:
HTML, CSS, JavaScript, WAI-ARIA.

Two sections deserve more care than a generic template can give them. Known limitations is the section most statements get wrong, either by omitting it entirely (claiming full conformance while an automated scan shows failures) or by writing it so vaguely it provides no evidence of an actual assessment. Enforcement procedure needs a real destination, not “contact your national authority,” because the point of the section is that a dissatisfied visitor can act on it without additional research.

#Mapping table: EN 301 549 requirement to WordPress implementation

EN 301 549’s Chapter 4 sets out functional performance statements (usage without vision, usage with limited manual dexterity, and similar) used when a specific success criterion does not map cleanly to a novel interface. For a standard WordPress front end, most of the mapping work happens in Chapters 9, 10, 11, and 12.

This table is the backbone of a VPAT-style conformance report if a public-sector client asks for one; each row becomes a line item with a pass, partial, or fail status once your audit has run.

#Where to publish the statement on WordPress: footer, dedicated page, schema

Footer link, every page. The single most checked signal in an enforcement review is whether the statement is reachable from anywhere on the site without search. A footer link, next to privacy policy and terms, satisfies this without extra development. If your theme’s footer is managed through a widget area or a global footer template part, add the link there once rather than per-page.

Dedicated page, its own URL. Do not fold the statement into the privacy policy or terms of service. Give it a standalone URL such as /accessibility-statement/, set through a normal WordPress page (or MDX content entry, on this stack) so it can be reviewed and versioned independently of other legal content.

Structured data, optional but useful for procurement audits. A WebPage JSON-LD block on the statement page, with the page’s dateModified matching your last review date, gives an automated crawler or a procurement checklist tool a machine-readable confirmation the statement exists and when it was last touched. This is not a substitute for the human-readable content; it is a small addition that removes ambiguity when someone runs an automated compliance scan against your domain.

Review cadence, documented in the statement itself. State how often the statement is reviewed (annually, or after any major redesign) and stick to the cadence. A statement dated three years ago, with a “last reviewed” field nobody has touched, is one of the first things an auditor or a competitor’s legal team will flag.

#Complaint and feedback workflow

The feedback mechanism is the part of BFSG and the EAA that a pure front-end audit cannot satisfy, because it is a process requirement, not a code requirement.

1. Intake. A monitored email address or contact form, distinct from general support, so accessibility complaints are not lost in a generic queue. Route it to whoever owns compliance, not only the webmaster.
2. Acknowledgement. Confirm receipt within a stated window (commonly a few working days). The acknowledgement should restate the reported barrier so the visitor knows it was understood correctly.
3. Investigation. Reproduce the barrier, check it against the relevant WCAG success criterion, and record the finding, whether it confirms a known limitation already listed in the statement or surfaces a new one.
4. Response and remediation plan. Tell the visitor what was found and, if it is a genuine barrier, when it will be fixed or why it cannot be (disproportionate burden, third-party content outside your control, and similar, documented rather than asserted).
5. Escalation path. If the visitor is not satisfied, point them to the relevant enforcement or dispute-resolution body. In Germany, that is the Schlichtungsstelle BGG for federal matters, with Land-level equivalents for regional public bodies; other member states designate their own market surveillance authority under the EAA.
6. Internal logging. Keep a record of every complaint received and its resolution. This log is what turns “we have a process” from a claim in the statement into evidence during an audit or an enforcement inquiry.

None of these steps require new software. A shared inbox, a simple spreadsheet or ticket tag, and a named owner cover the requirement for most WordPress operators. What matters is that the process is documented in the statement and actually followed when a complaint arrives, not invented retroactively after one does.

#How this fits the EU compliance audit deliverable

An accessibility statement is one output among several inside a broader EU compliance audit for WordPress, which also covers NIS2/DORA supplier mapping and AI Act content-labelling obligations where relevant. Inside the accessibility portion of that audit, the statement is the deliverable that turns a technical WCAG 2.2 AA report into something a compliance officer, a public-sector procurement reviewer, or an enforcement body can act on without reading the underlying scan output.

The sequence that produces a defensible statement, in the order we run it:

1. WCAG 2.2 AA technical audit, automated plus manual, covering the representative page sample described in the WCAG/BFSG/EAA compliance stack.
2. Gap list keyed to specific success criteria, not a generic “some issues found” summary, because the statement’s known-limitations section needs specific, named items.
3. Statement draft using the section structure above, filled with the actual audit result rather than a placeholder conformance claim.
4. Feedback workflow setup, wired to a real inbox and a named owner, tested with a dummy complaint before publishing.
5. Publication, footer-linked, on its own URL, with a review date set for the next cycle.

If you are running this as part of a broader EAA/WCAG readiness project, the European Accessibility Act and WCAG overview is the entry point for scope questions (who is exempt, what “placed on the market” means for a service contract), while this article covers the statement document specifically once the underlying audit is done.

#Cluster reading

• Pillar: WCAG 2.2, BFSG, and the EU Accessibility Act: the 2026 compliance stack for WordPress
• European Accessibility Act and WCAG 2.1: how to implement digital accessibility
• EU compliance audit for WordPress: accessibility, NIS2/DORA, AI Act