The accessibility statement, written so it survives scrutiny

By the end of this page you will be able to write an accessibility statement for a WordPress or WooCommerce store that a customer can use at the moment they hit a barrier, that a regulator would recognise as the information EU law asks a service provider to publish, and that you will still be willing to defend in a year — then publish it two ways: as a page you keep by hand, or as a statement served from the fixes that have actually landed.

Hold one framing before the detail. A statement is a declaration of effort and status at a date. It is not a certificate. W3C’s own guidance on the genre says accessibility statements are not technical assessments or declarations of conformity, though they ideally refer to such background to provide verification and increase credibility. Everything below follows from that sentence.

The statement has two readers, and only one of them is a regulator

W3C’s Web Accessibility Initiative gives three reasons to publish one: to show your users that you care about accessibility and about them, to give them information about the accessibility of your content, and to demonstrate commitment to accessibility and to social responsibility. In that order. The first reader is not an auditor. It is someone who has just failed to add a product to a basket and wants to know three things — whether the fault is theirs or yours, whether there is another way to buy, and whether telling you will achieve anything.

That reader decides how you write. WAI’s guidance is to explain functionality and known limitations in common terms: rather than “WCAG Success Criterion 1.2.2 was not met”, write “videos do not have captions”, because technical and jurisdictional language is more likely to cause confusion and frustration than to help. Success-criterion numbers belong in your internal ledger, not in the reader’s way.

The second reader — a national authority, a complainant’s advocate, a procurement team — wants something else: scope, standard, date, method, known gaps, escalation route. One document can serve both if it is written plainly and structured so the formal elements are easy to find.

What a statement cannot do is stand in for a conformance claim. In WCAG, a conformance claim is a distinct and optional artefact: you are not required to make one in order to conform, but if you do make one, all of the information a claim requires must be provided — among it the date of the claim, the version and level of the guidelines satisfied, a description of the pages the claim covers, and the technologies the content relies upon. Most shop statements should not attempt one. They should describe status and effort honestly and leave the strong claim to the thing that can carry it: no scan and no plugin can certify conformance, and only a human audit can — against a named standard, at a defined scope, on a stated date. That is what our audit tier exists to do.

The six elements a credible statement contains

Whatever jurisdiction you are writing for, a statement worth publishing answers six questions. The mandatory content of the EU model statement maps onto them almost exactly, which is why it is worth borrowing even though it was drafted for public bodies.

The last row is the one shops skip and the one law is most specific about. Article 7(1) of the Web Accessibility Directive requires a statement to include an explanation of those parts of the content that are not accessible and the reasons for that inaccessibility, with the accessible alternatives provided where appropriate; a description of, and a link to, a feedback mechanism enabling any person to notify the body of a failure to comply; and a link to the enforcement procedure to which recourse may be had in the event of an unsatisfactory response. The model statement carries contact details for accessibility enquiries and for the enforcement body. A feedback route with nothing behind it is a suggestion box.

What the EAA actually asks a shop to publish

The European Accessibility Act is the instrument that reaches private stores, and what it asks for is less like a template than like a file you must be able to produce on request.

E-commerce is in scope by name. Article 2(2) applies the Directive to the listed services provided to consumers after 28 June 2025, and point (f) of that list is e-commerce services; Article 3(30) defines them as services provided at a distance, through websites and mobile device-based services, by electronic means and at the individual request of a consumer with a view to concluding a consumer contract. Member States apply their transposing measures from 28 June 2025, under Article 31(2).

What the store itself has to do sits in Annex I. Section III(c) requires making websites, including the related online applications, and mobile device-based services, including mobile applications, accessible in a consistent and adequate way by making them perceivable, operable, understandable and robust — the four WCAG principles in EU drafting. Section IV(g) adds the e-commerce specifics, in three limbs: providing the information concerning accessibility of the products and services being sold when that information is provided by the responsible economic operator; ensuring the accessibility of the functionality for identification, security and payment when it is delivered as part of a service instead of a product, by making it perceivable, operable, understandable and robust; and providing identification methods, electronic signatures, security and payment services that are perceivable, operable, understandable and robust.

Then comes the information obligation, which is the statement in all but name. Article 13(2) requires service providers to prepare the necessary information in accordance with Annex V and to explain how the services meet the applicable accessibility requirements; that information shall be made available to the public in written and oral format, including in a manner which is accessible to persons with disabilities, and kept for as long as the service is in operation. Annex V says the assessment belongs in the general terms and conditions, or equivalent document, and lists what it must contain where applicable: a general description of the service in accessible formats; descriptions and explanations necessary for the understanding of the operation of the service; and a description of how the relevant accessibility requirements set out in Annex I are met by the service. Point 3 requires information demonstrating that the service delivery process and its monitoring ensure compliance.

Read those together and the shape of the obligation is unmistakable. The EAA does not ask for a badge. It asks for a written, public, accessible, maintained document explaining how your store meets the requirements, plus evidence that you monitor it — which is an accessibility statement doing an honest job, and nothing else on a shop’s site fits the description.

Three details change how you write it. The oral format limb of Article 13(2) is the one nobody notices: a phone number that reaches a person who can describe a product or take an order is not a nicety, it is part of the obligation, and it doubles as the alternative route your known-gaps section ought to offer. Article 13(3) requires procedures so that provision of the service remains in conformity, with changes in the service, in the applicable requirements and in the referenced standards adequately taken into account. Article 13(4) requires corrective measures where a service does not conform and, where it is not compliant, immediately informing the competent national authorities of the Member States in which the service is provided, with details of the non-compliance and any corrective measures taken. Article 13(5) adds that on a reasoned request you must provide a competent authority with all information necessary to demonstrate the conformity of the service.

Enforcement is national. Article 29 requires adequate and effective means to ensure compliance, including provisions whereby a consumer may take action before the courts or competent administrative bodies, and whereby organisations with a legitimate interest may act on a complainant’s behalf with their approval; Article 30 requires penalties that are effective, proportionate and dissuasive, taking into account the extent of the non-compliance and the number of persons affected. Microenterprises providing services — Article 3(23)‘s test is fewer than ten persons employed, with turnover or balance sheet total no more than EUR 2 million — are exempt under Article 4(5).

Which standard to name, and why EN 301 549 does not change the answer

EN 301 549 is where the EU machinery points. Article 6(1) of the Web Accessibility Directive builds a presumption of conformity: content meeting harmonised standards, or parts of them, whose references have been published in the Official Journal is presumed to conform to the accessibility requirements those standards cover. Commission Implementing Decision (EU) 2021/1339 is the act that put the current reference in place, listing EN 301 549 V3.2.1 (2021-03), Accessibility requirements for ICT products and services, in relation to Directive (EU) 2016/2102.

For web content, that standard and WCAG are the same target in two vocabularies. W3C’s policy listing for the European Union records that EN 301 549 includes WCAG 2.1 level AA verbatim without modifications for web content. So naming “WCAG 2.1 level AA” in your statement is not a dodge — it is the technical target written in the form your developers and your test tools can act on, and it is what a European assessor will read you against.

Three practical rules follow. Name the guidelines with version, level and URI, not as an initialism. Add “which EN 301 549 incorporates for web content” if you sell into the EU or into public procurement. And never name a version you have not tested against: the spec’s backwards-compatibility statement — content conforming to WCAG 2.2 also conforms to WCAG 2.0 and 2.1 — means building to 2.2 and claiming 2.1 is safe, while claiming 2.2 on a 2.1 test is an overclaim you cannot substantiate.

Why an overclaiming statement is worse than no statement at all

A statement is a dated, public, written assertion by you about your own service. It is precisely the artefact a complainant, an authority or a claimant’s solicitor will quote back to you.

There is a market price for getting this wrong. In January 2025 the FTC announced that a vendor of an AI-powered web accessibility plug-in would pay $1 million to settle allegations that it misrepresented the tool’s ability to make any website compliant with WCAG; according to the complaint the product did not make all user websites WCAG-compliant, so the claims were false, misleading or unsubstantiated. The proposed order — accepted on a Commission vote of five to nil — would bar the company from representing that its automated products can make any website WCAG-compliant, or can ensure continued compliance with WCAG over time, unless it has the evidence to support such claims. That order binds a vendor. The same standard of evidence applies to the sentence you publish on your own shop, and no supplier’s marketing transfers to you as a defence.

WCAG’s own structure makes certain popular sentences false by construction. Conformance is for full pages only, and cannot be achieved if part of a page is excluded. Where a web page is one of a series of pages presenting a process, all web pages in the process conform at the specified level or better — and W3C’s worked example is an online store, whose pages from start to finish through checkout conform in order for any page in the process to conform. “Our site meets WCAG 2.1 AA” while the quantity field on the basket page has no label is not an exaggeration. It is untrue in the standard’s own terms.

Compare the two failure modes honestly. No statement is a gap: it tells a customer nothing and gives an authority nothing to work with. An overclaiming statement is evidence: it records that you asserted a status you had not established, in writing, on a date, in a document you control. The version that costs you least is the specific, partial, dated one that names its gaps — and it happens to be the only version a disabled customer can actually use.

A skeleton you can adapt

Write the known-gaps section first. It is the hardest part, it determines what your honest status is, and everything else is bookkeeping arranged around it. Then fill in this shape, which is deliberately plain text — paste it into a page and edit it down.

Accessibility statement

[Store name] wants [store URL] to work for as many people as possible,
including people who use screen readers, keyboard-only navigation, speech
input, or screen magnification.

Scope
This statement applies to [store URL], including product pages, the basket
and every step of checkout. It does not cover [named exclusion — e.g. the
hosted payment page provided by our payment processor, or reviews submitted
by customers].

Standard
We work to the Web Content Accessibility Guidelines (WCAG) 2.1 level AA,
https://www.w3.org/TR/WCAG21/ — the level EN 301 549 incorporates for web
content.

Status
[Store name] is partially compliant with WCAG 2.1 level AA: most of the
standard is met, and the exceptions below are not.

Known problems
- Some older product images have no text description, so a screen reader
  announces a file name instead. Ring [number] and we will describe any
  product to you. We expect descriptions across the catalogue by [month].
- Two filters on the collection pages cannot be operated by keyboard alone.
  Use the search box instead, or ring [number] and we will find it for you.

How this statement was prepared
Prepared on [date] by [self-assessment / an assessment carried out by
[third party]], using [automated testing across N page templates, plus
manual keyboard and screen-reader testing of the full checkout].
Last reviewed [date].

Feedback
If something blocks you, email [monitored address] or ring [number].
[Name or role] is responsible for accessibility here. We reply within
[N] working days. Tell us the page, what you were trying to do, and what
happened.

Escalation
If our reply does not resolve it, you can escalate to [the competent
authority or consumer body for your market].

Three rules while you edit. Keep the plain-language register the whole way through. Never publish a known problem without deciding who owns it, because an unowned gap will still be there at the next review and will now be minuted. And if you cannot honestly complete the “how this was prepared” line, do not publish a status at all — publish the commitment, the feedback route, the phone number and the date, then add the status once you have tested.

Publishing it on WordPress

As a page you maintain by hand

WordPress’s own documentation describes Pages as content that is not time-dependent, living outside the normal blog chronology, and lists “Accessibility Statement” among its examples of a Page alongside About, Contact and Privacy Policy. So: create a Page, title it “Accessibility statement”, give it the slug accessibility-statement, and add it to the footer navigation.

Link it from more than one place. WAI’s guidance is to make the statement easy to find from the footer, help menu, sitemap, about page and other prominent areas, using a consistent link name so people learn to recognise it; the EU model statement asks for a link prominently placed on the home page of the website, or made available on every web page, for example in a static header or footer.

Then make the statement page itself pass the checks it describes, because a statement nobody can read is its own punchline. Two things break most often on a hand-built page. First, the page has to declare its language: technique H57 is satisfied by a lang attribute on the html element whose value conforms to BCP 47 and reflects the primary language used by the page. It matters most on exactly this page, which is often the one you have had translated. That is document language, and in a WordPress theme it is one function call:

<!doctype html>
<html <?php language_attributes(); ?>>

Second, the footer link has to sit inside a real landmark region rather than floating after the closing element, or the region shortcuts screen-reader users navigate by will not find it — see landmark structure. While you are there, check the small print you have just written against colour contrast, and make the escalation link say where it goes rather than “click here” (link purpose).

As a statement served from the fix record

The hand-built version has one structural weakness: the date. It is maintained by the person least likely to remember, and a stale review date is worse than none, because it asserts something specific and false. The remedy is to stop typing the date.

A must-use plugin is a good home for the plumbing. Must-use plugins are installed in wp-content/mu-plugins, are automatically enabled on all sites in the installation, do not show in the default list of plugins on the Plugins page — they get their own Must-Use section — and cannot be disabled except by removing the file from the directory. So the statement link cannot be switched off by accident during a theme migration. Three caveats from the same documentation: files there do not appear in update notifications, activation hooks are not executed, and WordPress only reads PHP files sitting directly in the directory, not in subdirectories.

<?php
/**
 * Plugin Name: Accessibility statement — link and freshness
 * Description: Links the statement from every page and prints the page's own
 *              modified date, so the review date cannot drift from the content.
 */

const KA_STATEMENT_PATH = '/accessibility-statement/';

/**
 * Put the link inside the theme's footer landmark, not after it. Most block
 * themes fire wp_footer inside the footer template part; if yours does not,
 * add the link to the footer navigation block instead.
 */
add_action( 'wp_footer', static function () {
	printf(
		'<p class="ka-statement-link"><a href="%s">Accessibility statement</a></p>',
		esc_url( home_url( KA_STATEMENT_PATH ) )
	);
} );

/**
 * [ka_statement_reviewed] — the statement page's real last-modified date, in the
 * site's timezone and date format. Use it instead of hand-typing "Last reviewed …".
 */
add_shortcode( 'ka_statement_reviewed', static function () {
	$page = get_page_by_path( trim( KA_STATEMENT_PATH, '/' ) );

	if ( ! $page instanceof WP_Post ) {
		return '';
	}

	return esc_html(
		wp_date( get_option( 'date_format' ), get_post_timestamp( $page, 'modified' ) )
	);
} );

That is the cheap version of a served statement: one source of truth for the URL, one for the date. The version worth having takes the body from the record of what was actually scanned and fixed, which is how Klarvo Access serves it, and the division of labour is worth knowing even if you build your own.

Our engine assembles the statement from your latest completed scan: that scan’s date becomes the as-of date, the pages it covered become the scope, and its unresolved findings become the known-problems list. It reads records — it does not re-scan to publish. The plugin then renders that payload server-side into a fixed, accessible template at its own URL, escaping every value, rather than into an editable page whose wording can drift from the evidence behind it. Publishing stays a human decision, and it needs one thing from you that no scan can supply: a monitored feedback contact, without which publishing is blocked rather than fudged. Each publish is retained as a new version instead of overwriting the last, so you keep the history of what you asserted and when; and the monitoring cycle re-issues the statement off its newest scan, which is what stops the date drifting from the store. The posture it reports is the honest automated one, and it will not use certified wording unless a human audit backs it. A served statement is just the public face of the detect, fix, prove, keep loop.

What automated evidence can support, and what it cannot

Being specific here is the whole exercise. Here is the real coverage of the 55 success criteria our engine tracks — 31 at level A, 24 at level AA, across WCAG 2.0, 2.1 and 2.2 — grouped by what each lets you write.

Thirty-nine of the fifty-five have at least partial automated coverage; sixteen have none. Even for those thirty-nine the coverage is partial by nature: an automated check can prove a specific failure exists on a specific element, and can never prove a criterion passes, because most criteria turn on meaning. Of our ten fix families, seven are applied automatically — including document language — and three route to human review, among them landmarks, because the correct structure depends on what the page is for.

Automation cannot certify conformance, and ours does not pretend to. What it can do is give a statement its factual spine: a dated scan of your real pages, a record of which fixes were applied and when, and an honest list of what is still open. Where a criterion sits in the audit-only row, the truthful sentence is that it has not been assessed yet — or you buy the assessment, and the strong claim becomes available at a defined scope and on a date.

Keeping it true

Conformance drifts. A theme update reorders your headings, a new checkout plugin adds three unlabelled fields, a seasonal banner arrives with text set over a photograph. None of that touches the statement, which sits there asserting a status that was true in March.

So write the maintenance into the document: a review date, a review cadence, a named owner. Annual review is the floor — the implementing decision behind the EU model encourages review and update regularly and at least annually — and Article 13(3) makes any substantive change to the store a trigger in its own right. Re-testing after every deploy is not a caveat on the product; it is the product.

Start from the truth of your current position. The free scan tests your real pages — home, product, populated basket, hydrated checkout — and the findings are yours whether or not you buy anything, which is enough to write the known-problems section honestly today. Then fix, re-test, and let the date on your statement mean what it says.