The European Accessibility Act and your Shopify store

If you sell to consumers in the EU, the European Accessibility Act has applied to your store since 28 June 2025. Not a deadline approaching. A requirement that has been in force for over a year.

Most Shopify merchants we speak to have heard of it and believe one of three things: that it only applies to EU companies, that installing an accessibility widget handles it, or that nobody is enforcing it. All three are wrong, and the third one stopped being arguable within days of the date.

Who it actually applies to

It follows the market, not the company. A business headquartered in London, New York or Sydney that sells to consumers in the EU is in scope. Where your company is registered does not come into it.

The small-business exemption is narrower than people assume. A microenterprise means fewer than 10 employees and turnover under 2 million euros. Most stores that think they qualify do not.

E-commerce is named explicitly. This is not a case of general consumer law being stretched to cover websites. The directive lists e-commerce services in its scope.

Enforcement started immediately. Within days of the date, French disability organisations issued formal legal notices to four major grocery retailers over their e-commerce platforms. Penalties are set nationally and run into six figures in some member states.

One thing worth checking rather than assuming: there are transitional provisions running to 2030, and vendor blog posts routinely describe them as a blanket extension for existing websites. Read your national transposition before relying on that, because the transition applies to particular categories of service contract and hardware, not to "any store that already existed". If the extension is the thing your plan rests on, get a lawyer to confirm it in the countries you actually sell into.

What the standard asks for

The law points at EN 301 549, which points at WCAG 2.1 Level AA. That is the real specification, and it is the same one we audit against.

For a Shopify store, the places it bites are predictable:

The checkout. Every field needs a programmatically associated label, not a placeholder that disappears when you type. Error messages need to be announced, not only turned red. The whole path from cart to confirmation has to work from the keyboard alone.

Variant selection. Colour swatches and size pickers are where custom themes fail most often, because they are usually divs pretending to be radio buttons without the roles or the keyboard behaviour to match.

The cart drawer and every modal. Focus has to move into the dialog when it opens, stay inside it while it is open, and return to the trigger when it closes. Otherwise a keyboard user opens the cart and is stranded behind it.

Filtering and search. Results that update without a page load need to announce that they changed. Silence reads as a broken page.

Images and contrast. Product images need real alternative text, not the filename. Sale badges and low-contrast grey on white are the two things an automated scan finds in the first thirty seconds.

Why an overlay widget does not fix it

Search for this subject and the first page is dominated by companies selling a script you paste into your theme. The pitch is that it makes the store compliant. It does not, for a reason that has nothing to do with the quality of any particular product.

An overlay sits on top of the page and tries to repair, in the browser, what the markup failed to express. It cannot know that a div was meant to be a radio button. It cannot invent the relationship between a field and its label. It cannot make focus behave inside a dialog that was never built to trap it. What it can do is add a contrast toggle and a font-size control that the browser and the operating system already provide.

The practical problem is worse than the theoretical one: in the United States, where this market is more mature, plaintiffs have brought claims against sites that had overlays installed. Buying one does not end the exposure, and it can be evidence that you knew about the obligation.

Accessibility is a property of the markup. The fix is in the theme.

How to find out where you stand, this week

You do not need a procurement process to get an honest answer. Three steps, in this order.

Run an automated scan and understand what it did not tell you. Tools like axe or Lighthouse find roughly a third of WCAG issues: missing alternative text, unlabelled fields, contrast, duplicate ids, broken heading order. That third is worth clearing because it is cheap. The two thirds it cannot see are the ones that actually stop people buying.

Put the mouse away and buy something. Tab from the home page to an order confirmation using only the keyboard. Keep a note of every point where the focus ring vanishes, where you cannot reach a control, or where you cannot tell what is selected. This takes twenty minutes and finds more than any scanner.

Turn on a screen reader for the checkout. VoiceOver ships with macOS, NVDA is free on Windows. You are not trying to be an expert user. You are listening for whether each field says what it is, and whether an error is announced when you submit the form empty.

Anything you find in step two or three is the kind of thing that matters, and almost none of it appears in an automated report.

What we did on our own site

Before publishing this, we pointed the same checks at smart-ui.pro, because publishing an accessibility article from an inaccessible site would be embarrassing in a specific and deserved way.

It found 21 issues across 11 pages. Eight pages had a "view all projects" link with no accessible name at all: the label had been set on an inner component that never passed it through to the anchor, so a screen reader announced "link" and stopped. Three social links wrapped a bare icon with nothing to read. Fixing those exposed the real fault underneath, a button element rendered inside a link on thirteen pages, which is invalid HTML and makes a keyboard user tab through the same control twice.

One finding was our own checker being wrong. It flagged ten unlabelled form fields that turned out to be the spam honeypot, which is marked aria-hidden and is therefore not in the accessibility tree at all. We fixed the rule, because a checker that cries wolf gets switched off.

All of it is fixed, the script runs against the live site, and it fails if any of it comes back. We publish the checks we run rather than describing a process, and the same script is part of our audit.

Where this leaves a merchant

The obligation is live, it reaches you if your customers are in the EU, and the thing being sold hardest in search results does not discharge it.

The useful news is that the work is bounded. On a well-built theme this is days, not months, and most of it lands in the same places as conversion work: the checkout, the variant picker, the cart. A keyboard-navigable checkout is a faster checkout for everyone.

If you want to know where you stand, we audit Shopify stores against WCAG 2.1 AA as part of a fixed-price audit and fix what it finds as Shopify development work. Or run the three steps above yourself this week and you will know most of it by Friday.

This is not legal advice. Your obligations depend on the national law of each country you sell into, and a lawyer should confirm them.