Accessibility for Online Stores: What the European Accessibility Act Means for You

Reviewed June 2026. The EAA applied from 28 June 2025 and is enforced through national transpositions (Germany's BFSG and equivalents elsewhere), which can differ in detail and thresholds; the figures here are the published EU baselines, not a ruling on your situation. Technical paths apply to PrestaShop 1.7, 8 and 9 with the classic theme. This is not legal advice — confirm your scope, exemption status and national obligations with a lawyer in your country, and note that no module or theme makes a store "compliant" on its own.

Here is the fact most PrestaShop merchants only half-absorbed: as of 28 June 2025, the European Accessibility Act (EAA) makes web accessibility a legal obligation for most online stores selling to EU consumers — not a nice-to-have, not a 2030 problem. It is enforced at member-state level (BFSG in Germany, the transposed directive in each country), and the obligation falls on the trader, not on PrestaShop or your theme vendor. If your checkout can't be completed with a keyboard, that is now a compliance gap with your name on it.

This guide is specifically about what the EAA means for a PrestaShop store and how to close the gaps inside the software you actually run — the theme, the back office, the modules. It is the accessibility spoke of our compliance cluster, so where a topic belongs to a sibling (cookie banners, GDPR, terms) you'll get a one-line pointer rather than a rehash. For the wider legal picture of selling in the EU, start at e-commerce law in the EU.

Who the EAA actually covers (and who is exempt)

Before you spend a weekend on alt text, check whether the law applies to you in full — because the answer changes what you have to do.

• You sell B2C to EU consumers: you are in scope. "E-commerce services" are explicitly named in the Act.
• You are a microenterprise selling services: fewer than 10 staff and under €2M annual turnover or balance-sheet total — service providers at this size are exempt from the service obligations. This is the carve-out most small shops fall under, but read the next point before you relax.
• You sell products (the EAA's regulated product list — e-readers, hardware, terminals): the microenterprise service exemption does not cover products. Most clothing/cosmetics/homeware shops aren't selling regulated products, so this is rarely the catch — but verify rather than assume.
• Pure B2B: generally outside the consumer-facing scope, though accessibility is still good practice and may be contractually required by larger buyers.

So what? A two-person Polish boutique under the turnover threshold is likely exempt from the legal stick — but accessibility still widens its market and helps its SEO, so the work pays back regardless. A growing store loses the exemption once it no longer qualifies as a microenterprise under the applicable national rules. Treat the threshold as a deadline you're walking toward, not a permanent shield. This guide deliberately doesn't give legal advice on your specific status — confirm it with a lawyer in your country; the numbers here are the published EU thresholds, not a ruling on your case.

The standard behind the law: WCAG 2.1 AA, in plain terms

The EAA itself doesn't list pixel ratios. It points to the harmonised standard EN 301 549, which in turn adopts WCAG 2.1 Level AA as the web baseline. That's the bar your PrestaShop front office has to clear. The success criteria that bite a typical store are a short list, and every one of them maps to something concrete in your theme:

Notice the pattern: almost none of these are PrestaShop core bugs. They are decisions baked into your theme and your modules. That's good news — it means the fixes live in files you control.

Where PrestaShop helps you, and where it leaves you exposed

The default classic theme on PrestaShop 1.7 through 9 is built on Bootstrap and is a reasonable starting point: form fields use real <label> elements, the checkout has a logical heading order, and most native controls are keyboard-reachable. If you run close to stock classic, you are further along than you think.

The exposure comes from three predictable places:

• Your custom or purchased theme. Most paid themes restyle the focus outline away, add hover-only menus, and use thin grey type that fails 1.4.3. This is the single biggest source of real-world failures.
• Modules that inject front-office markup. Sliders, quick-view popups, cookie banners, wishlist hearts, live-search dropdowns — each adds interactive DOM that may not be keyboard-operable or announced. Every module you install is a new accessibility surface to test.
• Content you author. Product descriptions with images dropped in via the rich-text editor (no alt), CMS pages with skipped heading levels, PDFs linked as "click here." PrestaShop can't fix what you type.

A PrestaShop-specific remediation checklist

Generic "add alt text" advice is useless without knowing where. Here is the back-office and code map, in roughly the order of effort-to-payoff.

1. Product image alt text — fix it at the source and in bulk

In the product editor, the Catalogue → Products → [product] → Images tab has a Caption field per image — that value becomes the alt attribute on the front office. Filling it one product at a time across a real catalogue is where good intentions die. Two faster paths:

• SQL/bulk: image alt text lives in ps_image_lang.legend (keyed by id_image and id_lang). A controlled update there, or an import, beats hand-editing hundreds of rows — back up first.
• Stop creating the debt: make a useful caption part of your product-add routine so new images are never blank. Good alt text is also read by Google Images, so it's accessibility and discoverability in one move — our Smart SEO Revolution suite exists to keep that kind of on-page metadata clean at catalogue scale instead of product-by-product.

2. Focus visibility — usually a one-line theme fix

If your theme's CSS contains outline: none or outline: 0 on links, buttons or inputs without an equally visible replacement, keyboard users lose their place entirely. Search your theme's assets/css/ (and any custom.css) for it. The correct fix isn't to delete the rule blindly but to provide a clear :focus-visible style — a 2px high-contrast outline. This is the highest-payoff, lowest-effort change on the list.

Add this to your theme's custom.css (or a child-theme stylesheet, so a theme update doesn't wipe it) and it restores a visible focus ring across interactive elements without re-enabling outlines on mouse clicks:

/* Restore a visible keyboard focus indicator (WCAG 2.4.7) */
a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible,
[tabindex]:focus-visible {
  outline: 2px solid #1a1a1a;   /* pick a colour that hits 3:1 against its background */
  outline-offset: 2px;
}

The outline colour has to clear 3:1 contrast against whatever sits behind it, so adjust the hex to your palette rather than copying it blindly. If the theme set outline: none with !important, you may need to match that specificity — but prefer removing the offending rule at its source over stacking another !important on top.

3. Checkout and forms — the part with money attached

The checkout is both the most legally sensitive and the most commercially sensitive page you own. Tab through the entire order flow on PrestaShop's order controller — personal information, addresses, delivery, payment — using only the keyboard. Confirm every field has a visible label (not placeholder-only), that the carrier radio buttons are reachable, and that validation errors name the offending field rather than a generic banner. Third-party payment iframes (Stripe, PayPal, Adyen) carry their own accessibility — test the real, end-to-end submission, not just the page load. Because an accessible checkout and a high-converting checkout are largely the same checkout, this overlaps with everything in our payment security guide on getting that flow right.

4. AJAX status messages — the screen-reader blind spot

PrestaShop updates the cart total and the ps_facetedsearch product grid without reloading the page. A sighted user sees the number change; a screen-reader user hears nothing unless the updated region is marked aria-live="polite". This is WCAG 4.1.3, and it's the criterion automated tools miss most often. Check that the cart subtotal block and the faceted-search results container announce their updates — if a module replaced the native cart or search, the assertion is on that module.

5. Heading hierarchy and contrast — auditable in minutes

Confirm each page has exactly one <h1> and no skipped levels (a category page jumping H1→H3 confuses screen-reader navigation). For contrast, the usual offenders are the muted price/old-price colour, sale badges, and placeholder text — run them through any contrast checker against 4.5:1.

Testing your store the way regulators will

Automated scanners catch a minority of issues — commonly cited as roughly a third, though estimates vary by tool and site — so they are a starting line, not a finish line. Layer your testing:

• Automated first pass: Lighthouse (Chrome DevTools → Accessibility audit), the WAVE extension, and axe DevTools. Run them on your home page, a category, a product, the cart, and each checkout step — not just the home page.
• Keyboard-only run: unplug the mouse. Tab from the logo to a completed order. Anything you can't reach or activate is a failure, full stop.
• Screen-reader run: NVDA (Windows, free) or VoiceOver (Mac, built in). Listen to a product page and a checkout. This surfaces the alt-text, label, and aria-live problems no scanner will flag with confidence.
• Zoom to 200%: verify no content is clipped and nothing requires horizontal scrolling.

The accessibility statement — the document people forget

Several member-state transpositions expect a published accessibility statement: what standard you target (EN 301 549 / WCAG 2.1 AA), known limitations, and a contact channel for accessibility feedback. In PrestaShop this is simplest as a CMS page (Design → Pages) linked from your footer, sitting alongside your other legal pages. It belongs in the same shelf as your terms and conditions — and like them, it's a living document you update when you fix or discover an issue.

Where accessibility overlaps the rest of your compliance stack

Two pieces of accessibility work are really shared property with sibling topics, so handle them where they live rather than twice:

• The cookie consent banner. A banner that traps keyboard users or can't be dismissed without a mouse fails both accessibility and consent law. Get the banner itself right once — what it must do legally is in cookie consent for PrestaShop and GDPR and cookie compliance for PrestaShop — then test that same banner for keyboard operability.
• Data and forms. The accessible-forms work on your account and contact pages sits right next to your data-handling duties; the privacy side is covered in GDPR for online stores.

The business case beyond the fine

It's worth resisting the framing that accessibility is purely a tax. A meaningful share of the population — commonly cited as around one in seven globally, with national figures varying — has a disability, and far more people use accessibility features situationally: glare on a phone in sunlight, a sprained wrist, a sleeping baby that rules out audio. Every one of them is a customer you currently have a harder checkout for than you need.

The overlap with good engineering is real, too. Proper heading structure and alt text are the same signals search engines reward; clear labels and visible focus reduce form errors and abandonment for everyone, not only assistive-tech users. You are unlikely to ever fully separate "we did this for the EAA" from "this just made the store better." That's the honest reason to do the work even if your microenterprise exemption holds today.

Making it stick: accessibility as a routine, not a project

The stores that stay compliant don't run a heroic one-off audit and forget it — they fold a few checks into existing habits:

• Adding a product: caption every image, keep descriptions in real headings/lists rather than bolded fake-headers.
• Installing a module: tab through whatever front-office element it adds before it goes live; an inaccessible slider or popup is a regression you introduced.
• Changing theme or design: re-run the keyboard and contrast checks — restyles are where focus outlines and contrast quietly die.
• Quarterly: a 30-minute Lighthouse + keyboard sweep of the core funnel (home → category → product → cart → checkout).

Frequently asked questions

Does the EAA apply to my small PrestaShop shop?

It depends on size and what you sell. A microenterprise providing services — fewer than 10 staff and under €2M turnover or balance-sheet total — is generally exempt from the service obligations, which covers many small B2C shops. But the exemption does not extend to the EAA's regulated product list, and pure B2B sits largely outside consumer scope. These are the published EU thresholds, not a ruling on your case; confirm your status with a lawyer in your country, because national transpositions vary.

Which accessibility standard do I actually have to meet?

The EAA points to the harmonised standard EN 301 549, which adopts WCAG 2.1 Level AA as the web baseline. That is the bar your storefront has to clear. The criteria that bite a typical PrestaShop store are a short list — alt text, contrast, keyboard operability, visible focus, real form labels, and announced AJAX updates — and almost all of them are theme or module decisions, not core bugs.

Is the default PrestaShop classic theme accessible out of the box?

It's a reasonable starting point, not a guarantee. Classic uses real <label> elements, a logical checkout heading order, and mostly keyboard-reachable controls. The failures usually arrive from a custom or purchased theme that removed the focus outline and uses thin grey type, from modules that inject interactive markup, and from content you author without alt text. The closer you run to stock classic, the less remediation you face.

Will an automated scanner tell me if I'm compliant?

No. Automated tools (Lighthouse, WAVE, axe) catch only a minority of issues — commonly cited as around a third, though it varies by tool and site — so they're a starting line. You still need a keyboard-only run (unplug the mouse, tab from logo to completed order), a screen-reader pass (NVDA or VoiceOver), and a 200% zoom check. The criteria scanners miss most are exactly the ones regulators and real users hit: aria-live announcements, label quality, and keyboard traps.

Do I need an accessibility statement, and where does it go in PrestaShop?

Several member-state transpositions expect one: the standard you target (EN 301 549 / WCAG 2.1 AA), known limitations, and a contact channel for accessibility feedback. The simplest home for it in PrestaShop is a CMS page under Design → Pages, linked from your footer next to your other legal pages. Treat it as a living document you update whenever you fix or discover an issue.

The EAA didn't invent a new kind of work; it put a legal deadline on UX work you'd benefit from anyway. On PrestaShop specifically, that work is unusually tractable because the failures cluster in your theme, your modules, and your authored content — all of which you can see and change from your own back office. Start with the checkout (the page where inaccessibility and lost revenue are the same problem), fix the focus outline your theme deleted, get alt text under control at the source, and you've cleared most of the bar before you've touched anything exotic.