The European Accessibility Act for WooCommerce & Shopify stores: what actually applies and a 30-minute self-audit

Francisco C. Vazquez — Sun, 18 Oct 2026 12:34:42 +0000

I recently ran automated accessibility scans on four EU online stores, three on Shopify and one on WooCommerce, checking four pages on each: home, a collection, a product page and the cart. They scored between 56 and 65 out of 100. Every store had at least one "serious" issue, and three of the four had a "critical" one. None of them were badly built. They were well-designed, popular shops on mainstream themes.

The European Accessibility Act (EAA) has applied to e-commerce since 28 June 2025, and most of what I found is fixable in an afternoon. Here is what applies to you, what "accessible" means in practice, and how to check your own store in about 30 minutes.

Not legal advice. I'm a developer, not a lawyer. This is my reading of the directive and the national guidance. If you're unsure whether you're in scope, check with your national authority or a lawyer.

Who is actually in scope

The EAA (Directive (EU) 2019/882) covers "e-commerce services", which in practice means selling to consumers online. A few points matter for store owners:

It has applied since 28 June 2025. It isn't a future deadline.
Microenterprises that provide services are exempt. Under the directive, a microenterprise has fewer than 10 employees AND an annual turnover or annual balance sheet total of â‚¬2 million or less. You need both: the small team and one of the two financial figures under the cap. If you have 12 staff, or 6 staff and â‚¬3M in both turnover and balance sheet, you're not exempt.
The exemption covers services, not products. If you also make covered products, such as e-readers or certain hardware, the product rules are separate.
Selling into the EU counts. If you sell to EU consumers, being based outside the EU doesn't automatically take you out of scope.
Enforcement is national. Each member state passed its own law and appointed its own authorities. In Germany it's the BFSG (BarrierefreiheitsstÃ¤rkungsgesetz), which entered into force on the same date. Penalties and procedures differ from country to country.

What "accessible" means in practice

The directive's requirements are written in general terms ("perceivable, operable, understandable, robust"). In practice, everyone measures websites against EN 301 549, the European ICT accessibility standard, which applies WCAG 2.1 Level AA to web content.

One nuance: a new version, EN 301 549 v4.1.1, was published in September 2026 and moves to WCAG 2.2. It hasn't yet been cited in the EU Official Journal under the EAA, so for now WCAG 2.1 AA is the reference that counts. WCAG 2.2 is clearly where this is going, though, so it makes sense to aim for it.

For a store, that boils down to a few things. A keyboard user can find a product, pick a variant, add it to the cart and pay. A screen reader user hears what every button does. Text is readable. Errors are explained.

The theme issues I keep finding, with fixes

In my four scans, the same handful of rules came up again and again. Links or buttons with no accessible name showed up in 3 of 4 stores, low colour contrast in 3 of 4, and images missing alt text in 2 of 4. Here are those issues plus the ones that automated tools often miss.

1. Icon buttons with no name

The cart, search, wishlist, close (Ã—) and carousel arrow buttons usually contain only an SVG. A screen reader just says "button".

<!-- Before -->
<a href="/cart"><svg>â€¦</svg></a>

<!-- After -->
<a href="/cart" aria-label="Cart (2 items)">
  <svg aria-hidden="true" focusable="false">â€¦</svg>
</a>

A related problem showed up in two of the stores: the visible label says one thing and the aria-label says another (for example, the visible text is "Shop now" but aria-label="Banner link"). Voice-control users say what they see, so the accessible name should start with the visible text, or you can just drop the aria-label.

2. Alt text

Product images need alt text that describes the product, not the filename. Purely decorative images get an empty alt.

<img src="tee-navy.jpg" alt="Organic cotton t-shirt, navy, front view">
<img src="divider.svg" alt="">

In Shopify Liquid, fall back to the product title when the merchant left the alt empty:

{{ image | image_url: width: 800 | image_tag: alt: image.alt | default: product.title }}

In WooCommerce, fill in the "Alternative Text" field in the media library. Most themes output it automatically.

3. Contrast

The usual culprits are light grey prices, "sale" badges, placeholder text and white text on photo banners. AA requires 4.5:1 for normal text and 3:1 for large text and for UI components like input borders.

/* #999 on white is about 2.8:1, which fails */
.price--compare { color: #6b6b6b; } /* about 5.3:1, which passes */
.hero__text { background: rgb(0 0 0 / .55); } /* scrim behind text on images */

4. Focus traps (and leaks) in drawers and carousels

Cart drawers and mobile menus are the worst offenders. Either focus stays behind the drawer, or the hidden drawer's links can still be tabbed to. One store had focusable links inside aria-hidden="true" containers, so they were invisible to screen readers but still reachable by keyboard.

// Open: move focus in, make the page behind inert
drawer.hidden = false;
document.querySelector('main').inert = true;
drawer.querySelector('button, a, input').focus();

// Close (also on Escape): restore
document.addEventListener('keydown', e => { if (e.key === 'Escape') closeDrawer(); });
function closeDrawer() {
  drawer.hidden = true;
  document.querySelector('main').inert = false;
  cartToggle.focus();
}

Use hidden or inert instead of aria-hidden on content that contains links. For carousels, every slide that's off screen should be inert. Scrollable rows also need to be reachable by keyboard, either with tabindex="0" and a label, or with focusable items inside.

5. Viewport zoom lock

One store still had this in its theme, on every page:

<!-- Before: blocks pinch-zoom -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

<!-- After -->
<meta name="viewport" content="width=device-width, initial-scale=1">

6. Cookie banners

The cookie banner is often the first thing a user hits, and often the first barrier. Check that it receives focus or sits first in the tab order, that it can be operated with the keyboard, that its buttons have real text and enough contrast, and that "Reject" is as reachable as "Accept". If it's a modal, it needs the same focus handling as the drawer above.

7. Form errors

At checkout, a red border alone doesn't tell anyone what went wrong. Tie the error text to the field and announce it.

<label for="email">Email</label>
<input id="email" type="email" autocomplete="email"
       aria-invalid="true" aria-describedby="email-err">
<p id="email-err" role="alert">Enter an email like name@example.com</p>

Add autocomplete attributes to address and payment fields too (WCAG 1.3.5). Shopify's hosted checkout handles most of this itself, but custom cart pages, newsletter popups and WooCommerce checkout customisations often don't.

Why overlays don't solve it

Accessibility widgets that add a toolbar or "AI fixes" with a single script tag are tempting, but they don't change your theme's HTML. They can't reliably write meaningful alt text for your products, fix a focus trap in your drawer's JavaScript, or know what an unlabeled icon button is for. Many disabled users already have their own tools and find overlays get in the way. A widget also doesn't produce the accessibility information the EAA asks you to publish. Fixing the source is less work than it sounds, because most of the issues live in a few theme components.

A 30-minute self-audit with free tools

Minutes 0â€“10: automated scan. Install axe DevTools (the free browser extension) and run it on your home page, a collection or category page, a product page and the cart. Then run Lighthouse â†’ Accessibility in Chrome DevTools for a second opinion. Fix the "critical" and "serious" items first. Remember that automated tools catch only part of what WCAG covers, which is why the next steps matter.

Minutes 10â€“20: keyboard-only purchase. Unplug the mouse. Using only Tab, Shift+Tab, Enter, Space, the arrow keys and Escape:

[ ] Can you see where focus is at all times?
[ ] Can you dismiss the cookie banner?
[ ] Can you open and close the menu, and does Escape work?
[ ] Can you choose a variant (size or colour) and add the product to the cart?
[ ] When the cart drawer opens, does focus move into it, and back out when it closes?
[ ] Can you get through checkout to the payment step?

Minutes 20â€“30: screen reader. Use NVDA (free, Windows), VoiceOver (built in on macOS/iOS: Cmd+F5) or TalkBack on Android. On a product page:

[ ] Do icon buttons announce what they do?
[ ] Do product images have a sensible description?
[ ] Are price, variant and stock status announced?
[ ] Is a form error read out when you submit an empty field?

Also, zoom to 200% and check that nothing overlaps or disappears. Write down everything you find. That list is your backlog, and it's also the input for the next step.

What to put in your accessibility statement

Annex V of the directive requires service providers to publish information on how the service meets the accessibility requirements. It must be available in an accessible format and kept up to date for as long as the service runs. Most stores do this with an "Accessibility" page linked from the footer and the terms. A practical structure:

What the service is and how it works: browsing, cart, checkout, account, customer support.
The standard you measure against: EN 301 549 / WCAG 2.1 AA.
Current status: what conforms, plus known issues and when you plan to fix them. Being honest here is better than claiming "fully compliant".
How you keep it compliant: when you test, for example after theme updates, and with what.
A contact for accessibility problems, plus alternative ways to order, such as phone or email.
The national enforcement authority customers can turn to (not spelled out in Annex V, but good practice).
The date of the last review.

Check your country's specific requirements. Some national laws or authorities spell out extra details.

Wrapping up

The EAA isn't about perfection on day one. It's about not shutting people out of buying from you, and being transparent about where you stand. For most WooCommerce and Shopify stores, the bulk of the work is a few theme components (icon buttons, the cart drawer, the cookie banner, contrast tokens) plus alt text and a statement page. Run the 30-minute audit, fix the critical issues, publish an honest statement, and re-test after every theme update.

I'm building a small scanner that does this check and drafts the accessibility statement for EU stores. If you want early access or a free scan, there's a waitlist: https://xfranv8.github.io/escaner-accesibilidad-ue/?ref=devto

DEV Community: Francisco C. Vazquez