How to write an accessibility statement for a WordPress site

Last updated: 27 October 2026

An accessibility statement is a page that tells your visitors how accessible your website is, what does not work yet, and how to reach you when something gets in their way. This guide covers what goes in it, when EU law asks for one, a filled-in template you can adapt, the mistakes to avoid and how to publish it in WordPress.

We make an accessibility toolbar for WordPress, and its Pro add-on can generate a statement page, so weigh what we say with that in mind. Every fact below links to its source. This is general information, not legal advice: the rules that apply to you are in your country's law.

An accessibility toolbar helps some visitors; it does not make a website conform to WCAG or to the law. Fix your content and code first.

What an accessibility statement contains

The W3C's Web Accessibility Initiative (WAI), which publishes the Web Content Accessibility Guidelines (WCAG), says a statement should contain at least:

• a commitment to accessibility for people with disabilities;
• the accessibility standard you apply, such as WCAG 2.2;
• contact information in case visitors run into problems.

It also advises adding the known limitations, the measures you take to keep the site accessible, technical requirements such as supported browsers, the environments the site has been tested in, and the laws or policies that apply to you.

The W3C's free accessibility statement generator turns those parts into a page. Its conformance section offers four statuses, each with a fixed meaning:

• Fully conformant: "the content fully conforms to the accessibility standard without any exceptions";
• Partially conformant: "some parts of the content do not fully conform to the accessibility standard";
• Non conformant: the content does not conform to the standard;
• Not assessed: "the content has not been evaluated or the evaluation results are not available".

Two points from the W3C are worth keeping in mind as you write. First, the statement is for your visitors, so use plain language: "videos do not have captions" is more useful than "WCAG Success Criterion 1.2.2 was not met". Second, "accessibility statements are not technical assessments or declarations of conformity": the status you write should come from a check of your site, not replace one.

When you have to publish one

Many websites publish a statement voluntarily. In the EU, two laws ask for one, or for something close to it.

Public sector websites: Directive (EU) 2016/2102

The Web Accessibility Directive covers the websites and apps of public sector bodies. Article 7 requires them to "provide and regularly update a detailed, comprehensive and clear accessibility statement", using a model set by the European Commission and published on the website. The statement must include:

• the parts of the content that are not accessible, the reasons, and accessible alternatives where appropriate;
• a description of, and a link to, a way for anyone to report a problem or ask for content that is excluded;
• a link to the enforcement procedure the visitor can use if the answer is not satisfactory.

The model is in the annex of Commission Implementing Decision (EU) 2018/1523. Its required sections are: a commitment and the scope (which sites or apps the statement covers), the status against the standard (full, partial or none: there is no "not assessed" option), the non-accessible content, how and when the statement was prepared and last reviewed, feedback and contact information, and the enforcement procedure. The declarations must be based on an actual evaluation, such as a self-assessment or an assessment by a third party, or on other measures that the Member State accepts as giving equal assurance, and the statement must say which method was used (Article 3). The Decision encourages a review "at least annually", and a link to the statement on the homepage or on every page, "for example in a static header or footer".

Some bodies are outside the Directive, for example NGOs that do not provide services that are essential to the public or meant for people with disabilities (Article 1(3)). Your national law may also go further than the Directive.

Businesses: the European Accessibility Act, Directive (EU) 2019/882

The European Accessibility Act does not use the words "accessibility statement". What it asks is similar: providers of the services it covers, such as e-commerce, must "explain how the services meet the applicable accessibility requirements" and make that information public, including in an accessible form (Article 13(2)). Annex V says where and what:

• in the general terms and conditions, "or equivalent document";
• a general description of the service in accessible formats;
• the descriptions and explanations needed to understand how the service works;
• a description of how the service meets the accessibility requirements in Annex I.

Microenterprises that provide services are exempt from the accessibility requirements (Article 4(5)). For who else is covered and from when, see our guide to accessibility widgets and the EAA. A statement page built on the W3C or EU model is a common way to publish this information, but the Act does not prescribe a model: check what your national law and your authority expect.

A filled-in template

This example combines the W3C sections with the parts the EU model requires. Replace everything in [square brackets], delete what does not apply to you, and keep only what is true. Public sector bodies covered by Directive 2016/2102 must use the text of the EU model (or the version their national law provides), which says "compliant" rather than "conformant": for them this example is only a guide to what goes where. The example uses "partially conformant" only to show how known limitations fit with it; your status must come from your own check.

If your site has an accessibility toolbar or another widget, say what it does and that it is an extra, not a fix: for example, "This website offers an accessibility toolbar that lets visitors adjust contrast, text size and spacing. It does not make the website conform to WCAG."

Mistakes to avoid

• Claiming more than you checked. "Fully conformant" means no exceptions at all. The EU model allows full status "only if all requirements … are fully met without exceptions". If you have not checked, "not assessed" is the honest status.
• Treating a widget or a scanner as the check. No toolbar, overlay or automatic scanner can tell you the site conforms, and a statement that says otherwise is a promise you cannot keep. In 2025 accessiBe settled with the US Federal Trade Commission, which alleged that the company had claimed its widget could make any website conform to WCAG (details in our EAA guide).
• Writing for lawyers instead of visitors. Say what does not work and what to do instead, in plain words. A list of success criterion numbers helps nobody who is stuck on your checkout.
• Leaving the template in place. Placeholders, an example company name or limitations that are not yours tell visitors that nobody read the page.
• A contact nobody answers. The feedback address is the most useful part of the statement for a visitor. Use one that someone reads, and reply.
• Forgetting the date. Without a date of the last review, visitors cannot tell whether the statement is still true. Review it after big changes to the site, and at least once a year.
• Hiding the page. Link it from the footer of every page, with the same name everywhere.

How to publish it in WordPress

WordPress has no built-in accessibility statement, but a normal page works well:

1. Check first. Go through your main pages with the keyboard, check images, forms, headings, contrast and zoom (our WordPress accessibility checklist walks through nine checks with free tools), and write down what does not work. That list becomes your known limitations, and it decides your status.
2. Create the page. In the dashboard, open Pages and add a new page called "Accessibility statement". Use a short address such as /accessibility-statement/.
3. Write it with real headings. Use Heading blocks for the sections and List blocks for the limitations, so screen reader users can move through the page. You can start from the template above or from the W3C generator, which lets you download the result as HTML.
4. Publish and link it. In a block theme, open Appearance → Editor, edit the footer and add a link to the page. In a classic theme, add the page to the footer menu under Appearance → Menus, or wherever your theme puts footer links.
5. Plan the review. Put the next review date in your calendar, and update the page when you fix a limitation or add a feature such as a new form or a shop.

If you serve more than one language, translate the statement too: it is most needed by the visitors who find the site hardest to use.

With Quicksloth Accessibility Toolbar Pro

The Pro add-on for our free toolbar builds the page from your answers. What it does, and what it does not:

• In Settings → Accessibility Toolbar Pro you enter the site or organisation name, the standard (WCAG 2.2 level AA, WCAG 2.1 level AA or EN 301 549), the status, the date of your last assessment, how you assessed the site, the known limitations and a contact address.
• No status is pre-selected. Until you choose one, the page shows no status, and only administrators see a reminder. The status sentences use the W3C generator's wording.
• A button creates a draft page with the shortcode [qsab_accessibility_statement]. You review it and publish it yourself, and you can add your own blocks around the shortcode, for example the scope or the enforcement procedure, which the generated sections do not include.
• The fixed text is shown in the language of each page where a translation is available; with Polylang, your own texts can be translated too.
• The page always includes a sentence saying that the toolbar helps some visitors and does not, on its own, make the site conform to WCAG or to the law.
• The plugin does not test your site. Checking the site is still your work, or an auditor's.
• If you delete the Pro, every page that contains the statement keeps it as a static copy, which you can then edit as normal page content.

The free Quicksloth Accessibility Toolbar is in the WordPress.org Plugin Directory; the Pro is coming soon.

Sources

All read on 27 October 2026.

• W3C WAI, Developing an Accessibility Statement (updated 11 March 2021): minimum and advised content, plain language, where to link it.
• W3C WAI, Generate an Accessibility Statement (updated 20 May 2025): sections and the four conformance statuses.
• Directive (EU) 2016/2102 on the accessibility of the websites and mobile applications of public sector bodies, EUR-Lex: Articles 1, 7, 9 and 12.
• Commission Implementing Decision (EU) 2018/1523 establishing a model accessibility statement, EUR-Lex: Articles 3 and 4, recitals 3 and 4, and the Annex.
• Directive (EU) 2019/882 (European Accessibility Act), EUR-Lex: Articles 4(5) and 13(2), Annex V.

Found something out of date? Tell us at support@quicksloth.dev and we will correct this page.