European Accessibility Act for Online Stores: A Practical Checklist (2026)

The European Accessibility Act has applied to online stores since 28 June 2025. If you sell to consumers in the EU, it applies to you, and that includes stores run from Toronto, Singapore or anywhere else outside the Union. Most European Accessibility Act ecommerce questions we get boil down to two things: does it cover my store, and what exactly do I have to fix? This post answers both, then gives you the checklist we'd work through ourselves.

One plain caveat before we start. This is general information, not legal advice, and if you need a ruling on your own business you should speak to a lawyer who practises EU law.

What the law asks for, and since when

The EAA is Directive (EU) 2019/882. It sets accessibility requirements for a list of products and services, and e-commerce services offered to consumers are on that list. Member states turned the directive into their own national laws, and those laws started applying on 28 June 2025.

The directive itself is written in general terms. The detail comes from the harmonised standard, EN 301 549. For web content, EN 301 549 maps to WCAG 2.1 at level AA. So in practice, when someone asks what EAA compliance for an online store means, the working answer is: your storefront, account area and checkout should meet WCAG 2.1 AA.

That's a known target. WCAG has been around for years, and most of its success criteria are things a careful developer can test.

Who's covered, and the microenterprise exemption

Coverage follows the customer. A store selling to consumers in any EU member state is in scope, wherever the company is registered. The rules are about services offered to consumers, so if a store you think of as wholesale also takes orders from individuals, treat it as in scope.

Microenterprises that provide services are exempt from the service requirements. The test has two parts, and you need both: fewer than 10 staff, and an annual turnover or balance sheet total of no more than €2 million. A three-person team with €2.5 million in sales doesn't qualify. Neither does a 12-person shop turning over €800,000.

Our view: even if you qualify, build accessibly anyway. Exemptions change as companies grow, and a shopper using a screen reader can't buy from a checkout they can't operate, whatever your headcount.

What enforcement looks like so far

Each member state has its own enforcement authority, so there's no single EU regulator issuing penalties. Early enforcement has mostly meant notices and orders to fix problems.

The case that got attention came in June 2026, when a court in Caen ordered Carrefour France to make its online store and app accessible, with a penalty of €500 per day for delay. Daily penalties add up quickly. They also tell you what a court is likely to want: a working, accessible store, on a deadline.

The checklist

We've grouped this by the part of the store each item touches, since that's usually how the work gets split between people. It covers the problems that come up most often on online stores. The full WCAG 2.1 AA list is longer.

Product pages and images

• Every product image has alt text that says what the shopper would need to know: "Navy wool overcoat, front view, knee length" beats "IMG_4471" or the product name repeated.
• Decorative images (background textures, divider graphics) have empty alt text so screen readers skip them.
• Colour and size pickers announce their names and the selected state. A row of coloured circles with no labels is unusable without sight.
• Price, stock status and delivery estimates are real text, not baked into an image.
• Headings follow a logical order, with one h1 for the product name.

Contrast, keyboard and focus

Normal text needs a contrast ratio of at least 4.5:1 against its background, and large text needs 3:1. Pale grey prices and white text over busy product photos are the usual failures. Sale badges in light pink are another.

Then put the mouse away and try to buy something. Everything a mouse can do should work from the keyboard alone:

• Tab reaches every link, button, filter and form field, in an order that matches the page.
• There's a visible focus indicator on whatever is selected. Removing the browser's outline without replacing it is one of the most common accessibility bugs on the web.
• Mega-menus, image carousels and quick-view modals open, close and can be escaped with the keyboard.
• Focus doesn't get trapped behind a cookie banner or a newsletter pop-up.

Forms, checkout and CAPTCHAs

Checkout is where accessibility problems cost you an order directly. Each field needs a visible label tied to the input in code (placeholder text alone disappears once someone starts typing). Required fields should be marked in text; colour alone doesn't count.

Error messages need to say what went wrong and how to fix it, and they need to be announced to screen readers. "Invalid input" in red under a field is two failures at once. "Enter a postcode with 5 digits" linked to the field is what you want.

Time limits catch people out. If a payment session or a reserved basket expires, the shopper should be warned and given a way to extend it. And CAPTCHAs that rely only on reading distorted text or picking images lock out blind shoppers; if you need bot protection, offer an alternative or use a method that doesn't ask the shopper to solve a visual puzzle.

Video, PDFs and your accessibility statement

1. Product and how-to videos have accurate captions. Auto-generated captions are a starting point and usually need editing.
2. Size guides, care instructions and invoices that you publish as PDFs are tagged for accessibility, or the same information is available as an HTML page.
3. You publish an accessibility statement explaining how your service meets the requirements, what isn't accessible yet, and how a shopper can contact you about a problem. Write it in plain language and link it from the footer.

Why a hand-coded store has an easier time

Accessibility is mostly about markup: the right HTML elements, labels, roles, focus handling and text alternatives. On a hand-coded store, the developer writes all of that directly. If a variant picker announces itself badly, we change the component and every product page gets the fix on the next deploy.

On a platform store, the same fix can sit in a theme file you're allowed to edit, or inside a third-party app you aren't. A reviews widget or a checkout extension ships its own markup, and if that markup fails WCAG you're waiting on the vendor. Good platforms do publish accessible themes, and a careful team can run an accessible Shopify store. The difference is how much of the code you control when something needs changing.

We build to WCAG accessibility guidelines on every store, in Next.js, React and TypeScript. That gives you a solid base to test against. It doesn't make a store compliant on its own, because content added later (new product images without alt text, a PDF uploaded by a merchandiser) can still break it. Accessibility is partly a code problem and partly a publishing habit.

How to audit your store

No single tool will tell you whether a store meets WCAG 2.1 AA. Automated scanners catch a share of the issues, and the rest need a person. This is the order we'd do it in:

1. Run an automated scanner such as axe DevTools, WAVE or the accessibility section of Lighthouse on the home page, a category page, a product page, the basket and each checkout step. Fix what it flags.
2. Do a manual keyboard pass. Unplug the mouse, start at the home page and buy a product. Write down every point where you get stuck or lose track of focus.
3. Test with a screen reader: NVDA on Windows is free, and VoiceOver is built into macOS and iOS. Listen to a product page from the top, then complete a checkout with the screen on.
4. Check colour contrast on prices, buttons, sale badges and form hints with a contrast checker.
5. Review your PDFs, videos and the accessibility statement against the list above.
6. Repeat after major releases. A new promotional banner can undo work you did six months ago.

If your shoppers include people who use assistive technology every day, paying a few of them to test the checkout will tell you more than any scanner.

Questions people ask

Does the EAA apply if my company is outside the EU?

It applies if you offer e-commerce services to consumers in the EU. Where your business is registered doesn't change that.

Is WCAG 2.1 AA the same thing as EAA compliance?

For web content, EN 301 549 maps to WCAG 2.1 level AA, so meeting it is the practical route most stores take. Treat it as the benchmark for your storefront, account pages and checkout, and publish an accessibility statement alongside it.

What happens if a store doesn't comply?

Enforcement sits with each member state's authority, and so far it has mostly meant notices and orders to fix. In June 2026 a court in Caen ordered Carrefour France to make its online store and app accessible, with a €500 per day penalty for delay.

We have eight staff. Are we exempt?

Possibly. A service provider counts as a microenterprise with fewer than 10 staff and an annual turnover or balance sheet total of no more than €2 million. You need to meet both conditions.

Will an accessibility overlay widget fix my store?

An overlay adds a toolbar on top of the page. The underlying markup stays the same, so unlabelled fields and keyboard traps in your checkout are still there for anyone using their own assistive technology. Fix the code.

Can EcomWeb help with this?

We build custom stores to WCAG accessibility guidelines and can review an existing build. Send us a message through the contact form with your store's address and the markets you sell into.