European Accessibility Act for WordPress: Is Your Site Compliant in 2026?

European Accessibility Act for WordPress: Is Your Site Compliant in 2026?

If you sell online to customers in the EU, the European Accessibility Act (EAA) probably applies to your WordPress site, and it doesn't matter where your business is based. The law has been in force since June 28, 2025, so the "we'll deal with it later" window has closed.

The good news is that this is fixable, and most of the work is plain good web practice. Here's what the law asks for, what's at stake, and the checklist I'd use on a WordPress site. (I'm a developer, not a lawyer, so treat this as practical guidance, not legal advice.)

1. Does It Apply to You?

Probably, if you answer yes to these:

• You sell products or services to consumers in the EU (a shop, bookings, subscriptions, online banking tools).
• Your customers can order, pay or sign up through your website or app.

Where you're located doesn't matter. A WooCommerce store in India or the US that ships to Germany is in scope.

The micro-business exemption is narrow. You must have fewer than 10 employees and turnover or a balance sheet of no more than €2 million. Both conditions, not one. It also covers services only, so a business that sells products doesn't get a free pass. And it disappears the day you cross either limit.

If you're on the fence, assume you're covered until a lawyer tells you otherwise.

2. What the Law Actually Requires

The Act itself doesn't name WCAG. It points to the European standard EN 301 549, which for websites follows WCAG 2.1 Level AA. That means things like meaningful alt text, keyboard-friendly navigation, readable colour contrast, clearly labelled forms with helpful error messages, and consistent navigation.

There's a wrinkle. In September 2026, a new version (EN 301 549 v4.1.1) was published, written for the Act and based on WCAG 2.2 AA. Sources differ on whether it's formally cited yet. The practical answer is simple: build to WCAG 2.2 AA, because it covers the 2.1 requirements too. WCAG 2.2 adds sensible checks such as minimum tap-target sizes, focus indicators that aren't hidden behind sticky headers, and logins that don't rely on remembering or retyping puzzles.

It's not only about code, either. Businesses are also expected to publish an accessibility statement, offer a way for users to report problems, and keep checking compliance over time.

3. What's the Real Risk?

Penalties depend on the country, so there's no single number. A few examples from published guides:

Enforcement is still early. In September 2026, a European Commission page noted that accessibility complaints remained rare. But it's no longer theoretical: on June 4, 2026, a court in Caen ordered Carrefour to make its website and app accessible within six months, with daily penalties for delay.

My honest take: the fine is only part of the risk. Inaccessible sites also lose customers and are harder for search engines and AI tools to read, which is why accessibility overlaps so much with the AI SEO audit checklist I published recently.

4. Where WordPress Sites Usually Fail

WordPress gives you a decent base, but most accessibility problems come from what gets added on top.

• Themes and page builders. Many produce messy heading order, missing landmarks and weak focus states. Look for themes carrying the "Accessibility Ready" tag, but still test them.
• Sliders, popups and mega menus. These often trap keyboard users or can't be closed without a mouse.
• Forms. Missing labels, placeholder-only fields and vague error messages are the most common checkout and contact-form failures.
• WooCommerce checkout. Payment fields, coupon boxes and address forms need clear labels and keyboard access.
• Images, PDFs and video. Missing alt text, untagged PDFs and uncaptioned videos.
• Colour contrast. Light grey text on white is the classic one. Normal text needs a 4.5:1 ratio.
• Cookie banners. Frequently the first thing a keyboard user hits, and frequently broken.

A word on overlays: Those "one-click accessibility" widgets modify the page in the browser but don't fix the underlying code. They aren't enough to reach EN 301 549 conformance on their own. Think of them as a nice extra, never the solution.

A clean, well-structured page also tends to load faster and rank better. If you're cleaning up your theme anyway, my slow WordPress troubleshooting guide covers the performance side.

6. What Goes in an Accessibility Statement?

Keep it short and honest: which standard you're working to, what's currently compliant and what isn't (with dates for fixes), how to contact you about a problem, and when the statement was last reviewed. Don't claim full compliance unless you've actually verified it. An inaccurate statement can be a problem of its own in some countries.

Frequently Asked Questions