Barrierepruefung.de Web Accessibility Checker

Publishing the statement from WordPress

The whole way to your statement in the WordPress admin – manual checks, mandatory details, release – and who is responsible for it.

Diesen Artikel auf Deutsch lesen

The steps to the statement are the same as in the service (From scan to published statement) – in the same order and with the same names. The plugin only displays them: which steps exist, which details apply to your statement and which questions the applicability check asks all come from the service. Whatever you enter in WordPress is in the service at once, and vice versa.

Before you start

  • Plugin version 0.7.0 or later, connected to your account: Setting up and connecting the WordPress plugin.
  • The permission on the token. In the service under “Websites” → your website → “Embedding”: tick “May prepare and publish the statement from WordPress” when creating the token, or grant it to an existing token with “Allow publishing”. You do not have to enter the token in WordPress again.
  • The plan. Publishing is included from the Starter plan.

Without the permission, the plugin still shows the steps and tells you where to grant it when you save.

The overview

Under Tools → Accessibility there are two tabs: “Scan” with findings and quota, and “Accessibility statement”. The second one shows the state of the published version at the top – including a notice when it is out of date –, then the type of document and the steps with their state: “done”, “open” with the reason, or “filled in before you publish”. The highlighted button always leads to the next open step; after saving, you are taken there automatically.

The steps

  • Answer the manual checks. All open checks are on one page, each with “met”, “not met”, “not applicable” or “open” and a field for a note. For “not met” the note appears as the justification in the statement. “Save answers” saves all of them at once – or none, if the service rejects one. More: Answering the manual checks.
  • Who is making the statement. Name and type of the declaring body; left empty, the website uses your organization’s name.
  • Applicability check. The questions and their legal references come from the service: Which accessibility statement do I need?.
  • Verify the domain. One click; the plugin serves the proof itself.
  • Mandatory details of the statement. Contact for reports, accessible alternatives and – depending on the type of statement – the enforcement body, the description of the service or the address of the explanations in sign language and easy-to-read language. Only the fields that apply to your statement appear: Filling in the statement’s mandatory details.

If the service rejects an entry, “There is a problem” appears at the top with a list whose entries jump to the affected field, and the browser window title starts with “Error:”. Your entries are kept.

Publishing

Once every step is done, “Review and publish the statement” leads to the release screen. It shows the draft as it will be published, the conformance status determined from the scan and, under “Deviate from the determined statement”, the option to choose another one – only with a justification, and “fully compliant” only while nothing is open (From scan to published statement).

The field “Released by” holds your WordPress display name. Below it, the page lists what happens when you publish; “Publish version … now” does it.

Two safeguards are built in:

  • A double click does not create a second version. The form carries a key that the service accepts only once.
  • Only what you have seen is published. If the draft changed after you opened the release screen – for example because someone answered a manual check in the service –, the service does not publish, and the release screen shows the new state with the message “The draft has changed since your preview”.

Who is responsible

A token belongs to your organization, not to a person. The person responsible for a version created through the plugin is therefore whoever granted the token its permission. The version also records the token and the name of the person who released it in WordPress. In the service, this is shown on the publishing page below the current version, and for manual checks below the answer.

If the person who granted the permission loses their role, the permission lapses. The “Embedding” tab then shows “lapsed” for the token; another owner or administrator grants it again with “Grant again”.

Afterwards: the page on your website

After release, pages with the shortcode or the block show the new version right away – the plugin’s cache is cleared in the process. A page cache can still deliver the old version: WordPress doesn’t show the statement, or shows an old one.

Under “On your website” the tab lists the pages that contain the statement. If there are none, “Create a draft page with the statement” creates a page “Accessibility” with the block – as a draft, so you can look at it before it goes live. Then link to it from every page, usually in the footer: Showing the statement in WordPress: shortcode and block.

What stays in the service

Assessing findings – “no defect”, “won’t fix”, “disproportionate burden” – is only possible in the service (Reviewing findings). It does not block publication, but it shapes the text of the statement, and it needs the screenshots of the occurrences, which the plugin deliberately does not bring into WordPress. The tab links there.

The plugin’s German translation comes in both forms of address and follows the language of your WordPress account. Texts that come from the service – manual checks, questions, reasons – follow the language of the account as well.

Last checked against the product on September 21, 2026. As Markdown

Related articles

Still have a question?

Tell us which question is still open. Questions we hear more than once become new help articles.

Contact form All help articles