On 28 June 2025, the European Accessibility Act (EU Directive 2019/882) came into force for most consumer-facing e-commerce products and services across the EU. One year later, the field reality is clear: the majority of PrestaShop stores serving European customers are still non-compliant — and most merchants don’t yet realise it.
The issue is no longer just ethical. It is now a legal risk, a commercial one (loss of public tenders, B2B framework contracts, marketplace listings), and a reputational one. This article maps the actual legal framework in 2026, the penalties effectively being applied across EU member states, and the technical roadmap to bring a PrestaShop 8 or 9 store into compliance without rebuilding the theme.
The legal framework that applies to PrestaShop stores in 2026
The EAA has been transposed into national law across all 27 EU member states by mid-2025. Implementations vary but the substance is uniform: any e-commerce service targeting EU consumers is in scope — website, mobile app, checkout flow, post-sale communication.
For UK-based merchants, the picture is split. Post-Brexit, the EAA does not apply directly in Great Britain, but two parallel obligations remain: (a) any UK store actively selling to EU consumers must still comply with the EAA’s substantive requirements; (b) domestically, the Equality Act 2010 and the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 create equivalent expectations, though enforced through different channels (Equality and Human Rights Commission, Trading Standards).
Two structural exemptions matter EU-wide:
- Microenterprises (fewer than 10 employees AND turnover or balance sheet under €2M) are exempt for services. Note: the threshold is assessed at group level.
- Third-party content not controlled by the merchant (raw user comments, for example) is out of scope — but the merchant remains responsible for the structure that hosts such content.
The technical reference standard across the EU is EN 301 549 V3.2.1, which incorporates WCAG 2.1 Level AA. In practice the standard guiding day-to-day work is WCAG 2.2, published October 2023, which adds nine new success criteria — notably focus visible (2.4.11), target size minimum (2.5.8), and consistent help (3.2.6). A WCAG 2.2 AA-compliant store is compliant with EN 301 549 and therefore with the EAA’s technical requirements.
Penalties actually being applied across the EU since 2025
Enforcement is split among national market surveillance authorities, consumer protection agencies, and accessibility commissioners depending on the country. After twelve months of operation:
- Predominantly pedagogical phase initially. Most early 2025 inspections resulted in formal notices and corrective commitments rather than firm fines.
- Hardening from Q1 2026. Administrative fines have started landing — ranging from €5,000 to €75,000 depending on operator size and severity of the breach (most often: complete absence of an accessibility statement).
- Statutory ceilings are high. In Germany the BFSG provides for fines up to €100,000 per violation; France caps administrative penalties at €250,000 for legal entities in case of repeated or serious breach; Spain operates under Real Decreto 193/2023 with similar magnitudes.
- Indirect risk likely higher than direct fines. Exclusion from public tenders, refusal of B2B listing by central purchasing bodies, customer signals on review platforms.
The most systematically inspected visible obligation is the accessibility statement, which must be published on the site, dated, and indicate the level of compliance reached (fully / partially / non-compliant) along with a multi-year remediation plan. A store missing this page is identified within minutes.
Field audit: what actually fails on PrestaShop
Based on audits across Classic, Hummingbird, Warehouse and custom themes, the recurring non-conformities cluster into six families:
1. Insufficient contrast (WCAG 1.4.3 / 1.4.11)
The light grey on white used for crossed-out prices, “VAT included” mentions, or reassurance icons almost systematically fails the 4.5:1 ratio (normal text) or 3:1 (large text and interfaces). A single Lighthouse or axe-core audit typically surfaces 15 to 40 contrast defects on a standard product page.
2. Broken keyboard navigation
Top dropdown menu, faceted filters, custom quantity selector, newsletter popup — these components are frequently inaccessible with the keyboard alone (Tab + Enter + Space). Visible focus disappears in half of premium themes. This is a blocking criterion.
3. Improperly labelled checkout form
Fields without associated label attribute, error indication in colour only (red), no aria-describedby for constraints (such as “8 characters minimum”), order summary inaccessible to screen readers. The PrestaShop 8 native one-page checkout has improved but remains incomplete, especially once a payment module or third-party address selector is added.
4. Images without structured alternative text
The classic problem: every product visual has an empty alt attribute or the same product name copied across. The correct logic: empty alt for purely decorative visuals (alt=””), descriptive and differentiated alt for secondary views (“back view”, “stitching detail”). PrestaShop doesn’t do this automatically — the merchant must supply it at catalogue import.
5. Auto-playing videos and carousels
Homepage carousel scrolling on its own without a pause button, autoplay product video: direct violation of criterion 2.2.2 (Pause, Stop, Hide). Technically, for a visitor with a vestibular disorder, automatic scrolling can trigger a physical reaction.
6. Blocking captcha and intrusive popups
reCAPTCHA v2 “tick the box” with no alternative for screen reader users, newsletter popup without focus trap, cookie modal impossible to close with the keyboard. Three classics that any market surveillance inspection picks up in minutes.
Compliance roadmap — without rebuilding the theme
Good news: most stores can reach substantial WCAG 2.2 AA compliance in 4 to 8 weeks of focused work, without a complete rebuild. The working sequence:
Week 1 — Quantified audit
Run an automated audit (axe DevTools, WAVE, Lighthouse) on 10 representative pages: home, category, product, basket, delivery step, payment step, order confirmation, blog, contact, legal declarations. Pair with manual keyboard-only testing and a screen reader test (NVDA on Windows, VoiceOver on Mac). Output a matrix “criterion / page / severity” with scores.
Weeks 2 to 3 — High-impact surface fixes
- Adjust the colour palette to meet contrast ratios — often one or two CSS variables.
- Add a global, readable focus indicator (2-pixel outline with a contrasting colour).
- Fix alt labels on the catalogue — often automatable via SQL script or a dedicated module.
- Remove autoplay and add a pause control on the carousel.
Weeks 4 to 5 — Critical components
- Rework the main menu with full keyboard handling (Tab, Enter, Escape, arrows).
- Correct ARIA labelling on faceted filters, quantity selector, basket notifications.
- Fix forms: associated labels, error indications in text AND colour, focus on the first errored field.
Weeks 6 to 7 — Editorial compliance and statement
- Audit CMS pages and blog posts (heading structure, image alt).
- Draft and publish an accessibility statement matching the official template (state of compliance, justified derogations, user feedback channel, escalation route).
- Multi-year remediation plan published on the same page.
Week 8 — User test and documentation
A test with a real user with a disability (visual or motor impairment) remains the only way to validate that no subtle criterion has been missed. It is also an argument in case of inspection: demonstrating continuous improvement.
The third-party module trap
The major blind spot: third-party modules constantly add unaudited elements. A wishlist popup, a cross-sell module with carousel, a third-party reviews widget — each addition can break compliance just acquired. The sensible rule: audit each new module with axe-core before deployment, and require a WCAG 2.2 AA compatibility statement from the developer.
At DataFirefly, all recent modules (side basket, alerts, live search, page builder) are tested with axe-core and screen readers before publication. A technical compliance statement is supplied on request for merchants under inspection.
Conclusion: the risk is no longer theoretical
The “no one is enforcing it” argument no longer holds one year after EAA enforcement. Fines have started landing, accessibility statements have become the visible minimum, and B2B pressure is rising — central purchasing bodies, public tenders, and major buyers now require WCAG commitments in their framework contracts.
The strategically right angle for a PrestaShop merchant is not cosmetic minimum compliance, but using remediation as a general UX audit: most accessibility fixes also improve conversion (readability, contrast, keyboard navigation appreciated by power users, better semantic structure for SEO and AEO). A 4 to 8 week investment that serves several objectives at once.
