WordPress and the European Accessibility Act

First: is your site covered?

The EAA applies to a defined list of products and services, not to every website. On the services side it covers e-commerce, consumer banking services, e-books, telecommunications services and passenger transport information, among others. A WordPress site that sells to consumers is covered by the e-commerce obligations. A company site that only describes what the company does may fall outside them.

There is also the microenterprise exemption: businesses with fewer than 10 staff and an annual turnover or balance sheet total of €2 million or less are exempt from the service obligations, though not from product obligations. Our exemptions page covers both cases, and your country page lists how your member state transposed them. Getting this question right first saves a great deal of work.

What WordPress itself guarantees

WordPress sets a clear internal standard: code integrated into the WordPress ecosystem, including WordPress core, the WordPress.org websites and official plugins, is expected to conform to WCAG version 2.2 at level AA. The accessibility team maintains coding standards and reviews core patches against them.

That standard is real, and its scope is narrow. It covers the software WordPress publishes. It says nothing about the theme you installed, the plugins you added from a directory with no accessibility gate, or the posts and pages your team wrote. On a real site, those three account for nearly everything a scan will report.

Source: WordPress accessibility coding standardsand WordPress.org accessibility.

The accessibility-ready tag, read carefully

Themes in the WordPress.org directory can carry an accessibility-ready tag, which requires a manual review by the accessibility team rather than an automated check. The requirements were updated in May 2026, with several former recommendations promoted to requirements.

The team is unusually direct about the tag's limits:"Accessibility Ready" does not mean that the theme meets the WCAG guidelines AA-level.It means the theme reaches the minimum standards the review team set. That makes it a good filter when choosing a theme, and not something to cite as evidence of conformance. Most commercial themes sold outside the directory carry no such review at all.

Where WordPress sites actually fail

Headings chosen for size

The most common structural failure on a WordPress site comes from the editor. An author picks a heading level because it looks right, so a page ends up with no h1, or jumps from h2 to h4. Screen reader users navigate a long page by jumping between headings, and a broken outline removes that. It costs nothing to fix and nobody notices it visually, which is exactly why it persists.

Alt text and link text

Alt text belongs to the image in the media library. Bulk imports and migrations leave the field empty at scale. Link text is the twin problem: a blog index where every entry links through the words "Read more" produces a list of identical links, useless to anyone reading them out of context.

Plugins

Sliders, popup builders, contact forms, cookie banners and booking widgets inject their own markup. The plugin directory applies no accessibility review. Contact forms are worth singling out, because a form whose error messages appear only in red text, with no programmatic association to the field, fails both the colour-alone rule and the requirement that errors be identified in text.

Page builders

Visual builders generate markup you did not write and rarely inspect. Common results: buttons built from div elements with no accessible name, tab and accordion widgets with no keyboard support, and decorative background images carrying content that exists only as an image.

PDFs

Menus, price lists, annual reports and forms uploaded as PDFs are outside the reach of any theme fix. A scanned PDF with no text layer is unreadable to a screen reader. If the document is part of a covered service, it is in scope, and the usual answer is to publish the content as a web page and keep the PDF as a secondary download.

What to do, in order

1. Settle whether you are covered, using theexemptions page and your country page. If you are not, the rest is a quality decision rather than a legal one.
2. Scan the home page and one content page of the type you publish most. Template issues repeat across every page built from the same template.
3. Audit alt text in the media library, where it lives, rather than page by page.
4. Fix heading structure in your most-visited pages and tell whoever writes content that heading levels are structure, not size.
5. Test every form with the keyboard only, including the error state. Submit it empty and see whether the errors are announced or only coloured.
6. Publish an accessibility statement if you are covered. Thestatement generator fills in the enforcement authority and complaint route for your country.

What a scan cannot tell you

Automated testing typically catches an estimated 20–50% of real accessibility issues. A scan can tell you an image has no alt attribute. It cannot tell you whether the alt text you wrote describes the image, whether your headings describe the sections under them, whether a video needs captions, or whether a custom widget makes sense when announced aloud. A clean scan is a floor, not a certificate.