Skip to content
wcagc
←Back to blog
EAAWordPressEN 301 549accessibility-statement

EAA compliance for WordPress sites

How to make a WordPress site EAA compliant: what's in scope, why no plugin does it alone, and how to check your theme, plugins, and content.

P

Pavel Charkasau

EAA WordPress compliance comes down to the same work any website needs, with one platform-specific catch: no plugin does it for you. If your WordPress site sells to consumers in the EU, the European Accessibility Act, in force since 28 June 2025 (European Commission), expects it to meet WCAG 2.1 Level AA through the harmonized standard EN 301 549. WordPress powers roughly 41.5% of all websites (W3Techs, July 2026), so a large share of in-scope stores run on it.

The work happens in three layers: the theme that wraps your content, the plugins that add functionality, and the content you publish every day. An automated scan finds the machine-detectable defects across all three quickly. Keyboard operation, focus order, and screen-reader output still need a person. Any "accessibility widget" that claims to fix a WordPress site from a single toggle is overstating what software can do. Here is how the pieces fit and what to check.

Does the European Accessibility Act apply to my WordPress site?

It depends on what your site does, not on the fact that it runs WordPress. The EAA is Directive (EU) 2019/882, and it covers a defined set of consumer-facing services: e-commerce, consumer banking, e-books, electronic communications, access to audiovisual media, and certain transport services (Article 2, Directive (EU) 2019/882). E-commerce is defined broadly, as a service provided at a distance through a website, at the individual request of a consumer, to conclude a consumer contract (Article 3(30)).

That definition catches most commercial WordPress sites. A WooCommerce store, a membership site with online sign-up, a site selling downloads or bookings: each concludes a contract with whoever completes checkout. When some of those buyers are consumers, the store and the pages around it are in scope.

Two boundaries matter:

  • Location does not exempt you. The Act follows the EU market, not the vendor's address. A US or UK business selling to consumers in the EU is covered.
  • The microenterprise carve-out is narrow. A service provider with fewer than 10 people and annual turnover or balance-sheet total of €2 million or less is exempt from the service accessibility requirements (Article 4(5) and Article 3(23)). Both conditions must hold, and it applies to services, not to products.

A purely informational blog with no transaction is a different case, though many national laws and the Web Accessibility Directive already reach public-sector sites regardless.

What accessibility standard does a WordPress site have to meet?

WCAG 2.1 Level AA, for the pages in scope. The EAA states the goal, that a service be perceivable, operable, understandable, and robust, but it does not list the technical checks. For those it relies on the harmonized standard EN 301 549, and meeting the relevant parts gives a presumption of conformity with the law. The version cited today, EN 301 549 v3.2.1, incorporates WCAG 2.1 Level AA for web content (ETSI).

Worth noting: WordPress core aims higher than the current legal bar. The project's own coding standards require new and updated core code to conform to WCAG 2.2 at Level AA (WordPress Accessibility Coding Standards). That is good news, because it means the software under your content is built with accessibility in mind. It does not mean your finished site inherits that conformance, since your theme, your plugins, and your content sit on top of core and can undo it.

For a WordPress site, meeting 2.1 AA means the familiar things done correctly: every menu, button, and form control reachable and operable by keyboard; a visible focus indicator; form fields with real labels; text contrast of at least 4.5:1; images carrying meaningful alt text; and a heading structure that follows the page, not the visual design.

Will an accessibility plugin make my WordPress site compliant?

No. This is the single most important thing to understand about EAA WordPress compliance. Plugins that inject an overlay or a "compliance" toolbar do not fix the underlying HTML; they layer controls on top of it, and independent testing has repeatedly found they leave real barriers in place. The point is not academic. In April 2025 the US Federal Trade Commission approved a final order requiring the overlay vendor accessiBe to pay $1 million over claims that its widget could make any website WCAG compliant (FTC, April 2025).

Genuine accessibility plugins do exist and they help, but for a narrower job. A plugin can enforce alt-text fields, add skip links, or flag contrast problems in the editor. What no plugin can do is guarantee that your particular combination of theme, page builder, and content is operable end to end. WordPress accessibility is a property of the rendered page, and the rendered page is assembled from parts you chose.

Where WordPress accessibility actually breaks

Most WordPress problems trace to one of three layers. Checking them in order is the fastest route to a site that holds up.

The theme. The theme controls markup, landmarks, focus styles, and menu behavior. WordPress.org offers an "accessibility-ready" tag for themes that pass a basic review, and its requirements were tightened in 2026 to cover reflow, text spacing, content on hover or focus, and an accessibility statement (Make WordPress Accessible, May 2026). Useful signal, but read the tag for what it is. As the WordPress accessibility team puts it, "WCAG is a measurement for content, and themes are only a wrapper for your content." A tagged theme is a good starting point, not a compliant site.

Plugins. This is where accessibility most often slips, because plugins generate front-end HTML you did not write. Page builders can output non-semantic markup and skip heading levels. Slider, popup, and modal plugins are common sources of keyboard traps and missing focus management. Form plugins vary widely in whether fields get real labels and whether errors are announced to a screen reader. Every interactive plugin on an in-scope page is something to test, not assume.

Your content. Even on a clean theme, day-to-day publishing reintroduces the classics: images added without alt text, headings chosen for size rather than structure, link text that reads "click here," low-contrast brand colors in buttons, and uploaded PDFs that were never made accessible. Content is the layer you touch most, so it is the layer that drifts fastest.

How do I check and document a WordPress site's accessibility?

Work in two passes, because neither finds everything on its own.

Automated testing first. Run your in-scope pages, home, key category and product pages, cart, and checkout, through a scanner built on a real rules engine rather than a single home-page check. This clears the high-volume, machine-detectable defects fast: missing labels, low contrast, missing page language, duplicate IDs, and basic ARIA mistakes. A free scan is the quickest way to see where a WordPress site stands today.

Manual review second. A person checks what a machine cannot judge. Can you complete checkout with the keyboard alone? Does focus land somewhere sensible when a popup opens, and return when it closes? Does a screen reader announce a form error and a "loading" state? Is the mega-menu operable, or only clickable? Work through these with our WCAG checklist so nothing slips.

How much does each pass catch? Deque's analysis of more than 2,000 audits found automated testing identified about 57% of issues by volume; measured as a share of WCAG success criteria, automation lands closer to 30% (Deque, 2021). Either figure says the same thing: scanning is necessary and not sufficient. Much of conformance only shows up under human review.

Then document it. For an in-scope service the EAA expects you to explain how the site meets the accessibility requirements, and an honest accessibility statement is where that lives. It records your conformance level, lists known limitations, gives a plan and timeline, and offers a contact for feedback. Documented effort is what the law asks for, not a perfect score. No plugin can promise the score anyway.

Frequently asked questions

Does the EAA apply to a WooCommerce store?

Usually yes. WooCommerce sites conclude consumer contracts online, which fits the EAA's broad definition of e-commerce. If your store sells to consumers in the EU and you are above the microenterprise threshold, the store and its checkout are in scope and should meet WCAG 2.1 AA.

Can an accessibility plugin make my WordPress site EAA compliant?

No. No plugin or overlay can make a site conformant on its own, and claims that one can have drawn regulatory action, including the FTC's $1 million order against accessiBe in 2025. Plugins help with specific tasks; full conformance needs fixes in your theme, plugins, and content plus human review.

Is an "accessibility-ready" WordPress theme enough for the EAA?

No. The accessibility-ready tag means a theme passed WordPress.org's basic review, but the theme is only a wrapper. Your plugins and your content determine whether the finished page is accessible, so a tagged theme is a good start rather than proof of compliance.

Which WCAG version does my WordPress site need to meet?

WCAG 2.1 Level AA, because that is what the harmonized standard EN 301 549 v3.2.1 currently incorporates. WordPress core targets WCAG 2.2 AA in its own code, and building to 2.2 now keeps you ahead of an expected update to the standard.

Do I need an accessibility statement for a WordPress site?

For an in-scope service, yes. The EAA expects you to document how the site meets the requirements. A statement records your conformance level, known limitations, a remediation plan, and a feedback contact.

Check where your WordPress site stands

Start with a free accessibility scan of your key pages. It shows the machine-detectable issues across your theme, plugins, and content in minutes, then points you to what still needs a manual check. It is the honest first step toward EAA WordPress compliance, without any promise a single tool can finish the job.

Written by Pavel Charkasau, founder of WCAG Compliance. Last updated 12 July 2026.

Sources