Since mid-2025 clients have been asking me the same thing: does my WordPress site fall under the new accessibility rules, and what exactly has to change. It usually starts with someone typing “european accessibility act wordpress” into a search box, reading for an hour, and coming away with legal references and not one concrete task to do in the admin panel.
This post is that missing list. I am not going to settle who the obligation covers - I am a developer, not a lawyer, so confirm the legal scope with a lawyer rather than with a blog article. What I can handle is the layer you can actually repair: the theme, the blocks, the forms, the media, the WooCommerce checkout and the plugins.
The European Accessibility Act and WordPress - who it covers and what gets checked
The European rules on the accessibility of products and services have applied since 28 June 2025, and in Poland they were implemented by the act of 26 April 2024. Exactly who they cover, including the exemptions for the smallest companies, I break down in the piece on who the accessibility obligation applies to.
From a WordPress point of view, something else matters more: the rules say nothing about WordPress, themes or plugins. They point to a European technical standard, and that standard carries the WCAG 2.1 guidelines at level AA. Nobody is going to check whether you run Elementor or blocks. What gets checked is whether your site can be used without a mouse and without sight - and that comes down to decisions made in the theme and in plugin settings, not to the engine itself.
Second point: WordPress in itself is neither accessible nor inaccessible. The core and the default themes are decently built. The trouble starts one layer up, in the purchased theme, in the builder, and in the plugins someone switched on years ago.
The WordPress fix list: theme, forms, media, WooCommerce checkout
Element by element, with what I see at clients most often.
Theme and templates
This is where most of the problems come from, because the theme decides colours, headings and navigation all at once.
- Text and button contrast. Light grey text on white, and buttons in a pastel brand colour, are the classic. The change usually sits in theme settings or in one stylesheet, so it is cheap - as long as someone walks through text over photos and in the footer too.
- A visible focus ring. The outline around whatever element you are standing on while tabbing through the page. It is very often switched off in the styles because it “looked ugly” - one line to remove and one to add, and the difference between a site you can traverse and one you cannot.
- Heading order. One H1 per page, then H2 and H3 in sequence. In builder-driven themes headings tend to be picked by font size, so a page ends up with three H1s and no H2 at all.
- A skip-to-content link. The first Tab on the page should reveal it. Without it a keyboard user walks the entire menu again on every single page.
- Drop-down menus. If a submenu only opens on mouse hover, it simply does not exist for the keyboard or for a screen reader.
Blocks, the builder and everything clicked together
The block editor produces sound markup right up until someone starts building buttons out of coloured containers. An icon made from a div is not a button - the keyboard cannot reach it and a screen reader will not announce it. The same goes for accordions, tabs and carousels from builder add-ons: either keyboard support is built in, or the element has to be replaced.
Contact forms
A form is where accessibility and conversion are exactly the same problem.
- Every field needs a visible label that stays on screen once typing starts. The grey hint inside the field disappears precisely when it becomes useful.
- Error messages spelled out in words, not by a red border alone, and placed next to the field they concern.
- Address and email fields marked up so the browser can offer saved details.
- Anti-spam that can be passed without recognising images. The classic picture puzzle shuts the door on a group of people and is one of the most common blockers I run into.
The popular form plugins can all be configured properly here. The catch is that the defaults and the ready-made templates are rarely set up with accessibility in mind, so someone has to go through them by hand.
Media, images and video
An image alt text is one short sentence about what is in the picture, not a slot for keywords. Purely decorative images should carry an empty description so the screen reader skips them instead of reading out a file name. The WordPress media library lets you fill this in in bulk, so it is dull work but simple work. A homepage video that carries the whole message in the soundtrack needs captions, which also serve everyone watching with the sound off.
WooCommerce checkout and the customer account
WooCommerce store accessibility is not the same job as a brochure site, because several things happen dynamically.
- Messages that appear in silence. Add to cart, shipping cost recalculated, coupon applied - visually there is a toast or a refreshed total, and the screen reader says nothing. A blind customer has no idea whether the action worked, so they click again.
- Filters and product variants. A size or colour picker rebuilt as coloured squares usually loses keyboard support along the way.
- Checkout validation. The same problem as in the contact form, except here it costs orders directly - I go into it in the piece on a shorter WooCommerce checkout.
- Login and the customer account. Often forgotten because it is “not a sales page”. For a returning customer it is exactly the opposite.
Plugins, pop-ups and the cookie bar
The discount pop-up, the consent bar and the chat widget in the corner are the three most common keyboard traps I see. The test is simple: open the site, press Tab a few times, then Escape. If the pop-up will not close and you cannot get out of it while Tab keeps cycling through the content underneath, you have a blocker - and one that applies to every page at once.
What helps: before you commission anything, walk one path - from the homepage to a submitted form or a placed order - using the keyboard only. Write down the keystroke where it broke. That single sheet of paper is worth more than a full set of automated warnings, because it says where the site stops being usable rather than where it breaks a rule.
Why an accessibility widget does not replace the fixes
The question comes up in every other conversation: can this not be handled by the plugin with the little person icon in the corner? The answer is no, and it is worth knowing why before you pay for a subscription.
An overlay works on top of a finished page. It can enlarge the font, invert the colours, underline the links. What it cannot do is write an alt text that does not exist, tie a label to a form field, turn a div into a button, or make the add-to-cart confirmation reach a screen reader. Everything that decides whether a purchase can be completed sits in the markup underneath.
There is also a side effect the overlay vendors do not mention: some of them get in the way of screen readers themselves and scramble the tab order. Removing that plugin is sometimes the first step of the repair. None of which makes overlays worthless - a contrast toggle can be convenient. It only means they are an addition to a fixed site, not a substitute for one.
What an audit and the fixes cost, and in what order
The honest answer is that it depends on the number of unique templates and on how much of the site is interactive, not on how many pages it has. What drives the cost and scope of a WCAG audit I have written up separately, along with how to tell a real offer from a scanner printout. If you would rather walk the site yourself first, the step-by-step WCAG audit takes you through it.
The order of work that serves my clients best looks like this:
- The one path that earns money. From the homepage to a submitted form or a placed order. Blockers here go first, because they cost money regardless of any regulation.
- Theme-level fixes. Contrast, focus, headings, skip link. They work globally, so one change closes hundreds of pages at once.
- Forms and checkout. Labels, error messages, anti-spam, announcing changes.
- Media. Alt texts and captions, done in bulk in the media library.
- Plugins and overlays. Replace or remove whatever configuration cannot fix.
On money: on a new build, bringing a site to WCAG 2.1 level AA is not a separate line item but part of the craft, and it fits inside a normal fixed-bid project, which I quote in writing after a conversation, billed in stages. On a site that has been standing for years it can be a renovation, and then the quote starts with looking at the site, not with a price list.
If the site is alive and changes every month, watching it continuously is cheaper than one big campaign every three years. That is why accessibility folds naturally into ongoing care: every new page and every new plugin goes through the same keyboard test before it reaches production. Plans and prices are on the support page.
What helps: do not order a full audit of the whole site up front if the budget is tight. One path plus theme-level fixes usually make a bigger difference than two hundred notes about the footer and the terms page, at a fraction of the cost.
Summary
The European Accessibility Act does not ask you to abandon WordPress or rewrite the site from scratch. It asks that the site be usable without a mouse and without sight - which in practice means a concrete list: contrast and focus in the theme, correct headings, labels and error messages in forms, alt texts on images, keyboard support in the checkout, and the removal of plugins that block the path. An icon in the corner will not cover it.
The cheapest order is: the earning path first, then the theme, then the forms, cosmetics last. And if you are not sure where you stand, send me the address. I will walk the most important path with the keyboard and tell you what actually blocks people on your site and what is only a scanner warning.
Frequently asked questions
Does my WooCommerce store fall under these rules? The rules target services sold to consumers electronically and include exemptions for the smallest companies, so the answer depends on what you sell and to whom. That is a question for a lawyer, not a developer - what I can tell you is which parts of the store technically fail the requirements, whether you must fix them or simply want to.
Is switching to a theme advertised as accessible enough? It helps, but it does not close the subject. The theme covers contrast, focus and heading structure, while forms, plugins, pop-ups and image descriptions stay on your side. I have seen sites on an “accessible” theme with a keyboard trap in the newsletter pop-up.
How long does it take to bring a typical company site up to standard? With a handful of templates and one form it is usually days rather than months, provided the theme does not need parts replaced. A store with a cart, filters and a customer account is a multiple of that, because every interactive element has to be tabbed through separately.
Will accessibility fixes ruin the look of my site? No. Alt texts, labels and a correct heading structure change nothing visually. What changes is contrast and a visible focus ring, two design decisions - and both can be made in line with the brand identity rather than against it.
Would rather not watch over it every month yourself? I take sites and stores under ongoing care - backups, updates, monitoring, and priority when something breaks. Tell me what you run and I will send back scope and price.