The Complete EU Accessibility (EAA) Guide for PrestaShop Merchants (2026)

Since 28 June 2025, accessibility has stopped being a “nice to have” for European online shops and become a legal requirement. The European Accessibility Act (EAA) — formally Directive (EU) 2019/882 — obliges a wide range of consumer-facing products and services, including e-commerce services, to be accessible to persons with disabilities. If you run a PrestaShop store that sells to consumers anywhere in the European Union, that almost certainly means you. This guide explains, in plain British English, what the EAA asks of you, whether you are in scope, and — crucially — exactly what to change in your PrestaShop shop to comply. It is written for merchants and their developers, not lawyers, and it is deliberately practical: you will find room-by-room audits, contrast values, checkout form fixes, testing workflows and PrestaShop-specific implementation notes.

Accessibility is not only a compliance exercise. Roughly one in four adults in the EU lives with some form of disability, and many more experience temporary or situational impairments — a broken arm, bright sunlight on a phone screen, a noisy train. An accessible shop is easier for everyone to use, converts better, ranks better in search, and is more robust across devices. The EAA simply makes the baseline mandatory. For the legal overview of this law on our site, see our Accessibility law page; for the scope question specifically, see the FAQ on who must comply.

What the EAA is and what it covers

The European Accessibility Act is an EU directive that harmonises accessibility requirements across member states so that businesses face one common set of rules rather than 27 different national regimes. It was adopted in 2019 with a long lead-in time, and its core requirements apply from 28 June 2025. Being a directive, it is transposed into national law by each member state, which is why enforcement and penalties are set nationally even though the substance is common — see for example our country notes for Germany and France.

The EAA covers both products and services. It is worth understanding the distinction because the obligations and exemptions differ between the two.

Category	Examples covered by the EAA
Services	E-commerce services (consumer-facing online sales of goods and services), consumer banking, e-books, electronic communications, websites and mobile apps for air/bus/rail/waterborne passenger transport (including ticketing), and access to audiovisual media services.
Products	Computers and operating systems, smartphones, self-service terminals (ATMs, ticketing and check-in machines), payment terminals, and e-readers.

For most readers of this guide the relevant category is e-commerce services. The EAA is explicit that online shops must make the purchasing journey accessible — that means the product information, the identification and authentication steps (registering, logging in), the payment functionality, and everything the consumer needs to complete a purchase. It is not enough for the homepage to look tidy; the whole path from landing to confirmation must work for someone using a screen reader, navigating by keyboard, or relying on high contrast.

It is also worth being clear about who in the supply chain carries the obligation. On the service side, the accessibility duty falls on the service provider — the merchant operating the shop — not on your hosting company or your theme vendor. You cannot contract the legal responsibility away, even though you may rely on third-party themes, modules and payment providers to deliver it. That is precisely why the practical sections of this guide focus on what you can verify and control. Where a component you did not build (say, a hosted payment iframe) is inaccessible, the obligation to find an accessible alternative, or to press the vendor to fix it, still rests with you.

Territorially, the EAA bites wherever the service is offered to consumers in the EU. If you are established outside the EU but sell and ship to EU consumers, you should assume you are within reach of the rules for those customers — geography of the business is less decisive than geography of the market you serve. Combined with the fact that a single accessible build serves every market at once, this is a strong argument for treating WCAG 2.1 AA as your global baseline rather than maintaining a separate “EU version” of the shop.

Am I in scope? The microenterprise exemption explained

The most common question merchants ask is simply: “Does this apply to me?” For services, the EAA contains a microenterprise exemption. A business that provides services is exempt from the EAA’s service accessibility requirements if it is a microenterprise, defined as a business that has:

• Fewer than 10 persons employed; and
• An annual turnover or annual balance-sheet total not exceeding €2 million.

Both conditions must be met — the headcount test and the financial test. Note the “and”: a business with 6 staff but €5 million turnover is not a microenterprise and is therefore in scope. Note too that this exemption applies to the service side of the EAA (which is where e-commerce sits). The product-side exemption works differently, so a manufacturer of covered products cannot simply rely on the same test.

Worked example

Business	Staff	Turnover	In scope for EAA services?
Solo founder + part-time helper	2	€180,000	Exempt (microenterprise) — both tests passed
Growing niche brand	8	€3.1 million	In scope — fails the €2m test
Established retailer	14	€900,000	In scope — fails the <10 staff test
Mid-sized shop	25	€6 million	In scope — fails both tests

Two practical cautions. First, being exempt today does not make you exempt forever — the moment you cross either threshold you are in scope, and retrofitting accessibility onto a mature shop is far more expensive than building it in. Even exempt microenterprises are encouraged to follow best practice, and doing so protects your growth. Second, the microenterprise exemption is for services; if you also manufacture or place covered products on the market, review those obligations separately. When in doubt about your specific numbers, count “persons employed” using the EU’s usual method (which includes owner-managers and counts part-timers proportionately) and take professional advice.

EN 301 549 and WCAG 2.1 AA explained plainly

The EAA sets out accessibility requirements but does not, in its own text, list every technical rule for a web page. Instead, conformity is demonstrated through harmonised standards. The relevant EU standard is EN 301 549 (“Accessibility requirements for ICT products and services”). For web content, EN 301 549 aligns with the Web Content Accessibility Guidelines (WCAG) 2.1 at level AA. In practice, then, “make my PrestaShop accessible for the EAA” translates to “meet WCAG 2.1 AA across the purchasing journey.”

WCAG is organised around four principles, remembered by the acronym POUR: Perceivable, Operable, Understandable, Robust. Every success criterion sits under one of these. Understanding them makes the detailed rules far easier to reason about.

Principle	Plain meaning	What it means for your shop
Perceivable	Users must be able to perceive the content through some sense.	Alt text on product images, sufficient colour contrast, captions on videos, content that doesn’t rely on colour alone.
Operable	Users must be able to operate the interface.	Everything works by keyboard, focus is visible, no keyboard traps, links and buttons are reachable, carousels can be paused.
Understandable	Content and operation must be understandable.	Clear labels and instructions on forms, predictable behaviour, helpful error messages at checkout, page language declared.
Robust	Content works with current and future assistive technologies.	Valid, semantic HTML; correct name/role/value on custom widgets; status messages announced to screen readers.

The A, AA and AAA conformance levels

WCAG defines three conformance levels. Level A is the minimum — failing an A criterion makes content inaccessible to whole groups of users (for example, images with no text alternative at all). Level AA adds a stronger, more realistic baseline that most organisations and laws target; it includes contrast minimums, resize/reflow and visible focus. Level AAA is the highest bar and is generally not required wholesale because it is not achievable for all content types. The EAA/EN 301 549 target is AA, which by definition means you must also satisfy all the A criteria. Everything in this guide is calibrated to A and AA.

A room-by-room accessibility audit of your PrestaShop store

Rather than tackle WCAG as an abstract checklist, it helps to walk through a shop page by page and note which criteria “bite” in each place. This mirrors how a real user moves through a purchase and how an auditor will test you.

Homepage

• Page titled (2.4.2) — the <title> must describe the page.
• Language of page (3.1.1) — the <html lang> attribute must be set correctly for each shop language.
• Info & relationships (1.3.1) — banners, promos and sections use real headings and landmarks, not just styled <div>s.
• Pause/stop/hide (2.2.2) — hero carousels and sliders must be pausable and not auto-advance in a way users can’t control.
• Link purpose (2.4.4) — “Shop now” links repeated across tiles need context so a screen-reader user knows where each leads.

Category / listing pages

• Meaningful sequence (1.3.2) — the reading and tab order matches the visual order of products and filters.
• Use of colour (1.4.1) — “Sale” or “Out of stock” must not be signalled by colour alone; add text or an icon with a label.
• Name, role, value (4.1.2) — faceted-search filters (colour swatches, checkboxes, sliders) expose their state to assistive tech.
• Status messages (4.1.3) — when AJAX filtering updates the grid, announce “24 results” without moving focus abruptly.

Product page

• Text alternatives (1.1.1) — every product image needs meaningful alt text; decorative thumbnails get empty alt.
• Info & relationships (1.3.1) — price, availability, variant selectors and tabs (description, reviews) are marked up semantically.
• Labels or instructions (3.3.2) — size and colour selectors have visible, programmatically-associated labels.
• Status messages (4.1.3) — “Added to cart” confirmation is announced, not only shown visually.

Cart

• Info & relationships (1.3.1) — the cart is a real table or a well-structured list with row/column relationships.
• Name, role, value (4.1.2) — quantity steppers and “remove” buttons have accessible names (“Remove Blue T-shirt, size M”).
• Status messages (4.1.3) — updating quantity announces the new subtotal.

Checkout and forms (the highest-risk area)

• Labels or instructions (3.3.2) — every field has a persistent visible label (placeholder text is not a label).
• Error identification (3.3.1) — errors are identified in text and the field in error is indicated programmatically.
• Error suggestion (3.3.3) — where the fix is known, suggest it (“Enter a valid postcode, e.g. SW1A 1AA”).
• On input (3.2.2) — selecting an option must not unexpectedly submit or reload without warning.
• Keyboard (2.1.1) — card fields, date pickers and the “Place order” button all work without a mouse.

Account and search

• Headings and labels (2.4.6) — order history, addresses and settings use descriptive headings.
• Focus visible (2.4.7) — tabbing through account menus shows a clear focus indicator.
• Search — labels/instructions (3.3.2) — the search box has a label; autocomplete suggestions are exposed as an ARIA listbox and are keyboard-navigable.

Colour contrast and the numbers that matter

Contrast is one of the most common — and most easily fixed — failures. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 between normal text and its background, and at least 3:1 for large text (roughly 18pt, or 14pt bold, and above). The same 3:1 minimum applies to meaningful graphical objects and user-interface components such as input borders and button outlines (1.4.11), so a pale-grey field border on white will often fail. Contrast is expressed as a ratio between the relative luminance of the lighter and darker colour, running from 1:1 (identical) to 21:1 (pure black on pure white); the AA thresholds sit deliberately in the range where the great majority of users with low vision or age-related sight loss can still read comfortably.

Two further AA criteria travel with contrast and are easy to overlook. Resize text (1.4.4) requires that text can be enlarged to 200% without loss of content or function — so avoid fixed pixel heights on buttons and containers that clip text when it grows. Reflow (1.4.10) requires that content reflows into a single column at the equivalent of a 320px-wide viewport (400% zoom) without a two-dimensional scroll, which in practice means your responsive breakpoints and mobile menu must genuinely work rather than forcing horizontal scrolling. A shop that is only tested at desktop width frequently fails reflow on data tables and wide product galleries.

Content	Minimum ratio (AA)
Normal body text (1.4.3)	4.5:1
Large text — ~18pt / 14pt bold (1.4.3)	3:1
UI components and graphical objects (1.4.11)	3:1

Watch out for the places brands most often trip: light-grey “muted” helper text, placeholder text used as instructions, white text on pastel promo banners, disabled-looking-but-active buttons, and low-contrast focus rings. Test the actual rendered colours (including any opacity), not the hex you think you used. A quick tip: your primary brand colour on white frequently fails at 4.5:1 for body text even when it looks fine to you — reserve it for large headings or darken it for text.

Keyboard access and visible focus

A large share of assistive-technology users, and many people with motor impairments, navigate entirely by keyboard. WCAG requires that all functionality is available from a keyboard (2.1.1), that there is no keyboard trap (2.1.2) — you must be able to tab into and out of every component — and that the focus indicator is visible (2.4.7).

• Every interactive element (links, buttons, form fields, custom widgets) must be reachable and operable with Tab, Shift+Tab, Enter, Space and arrow keys as appropriate.
• Modals must trap focus while open and return focus to the trigger when closed — and be closeable with the Escape key.
• Never remove the focus outline with CSS (outline: none) unless you replace it with something at least as visible.
• Provide a “Skip to content” link so keyboard users can bypass the header on every page.

Forms and error handling at checkout

Checkout is where accessibility failures cost real money, because an inaccessible form is an abandoned sale. It is also where the WCAG 3.3.x criteria concentrate. Treat this section as your priority.

• Labels or instructions (3.3.2) — associate a visible <label> with every field via for/id. Required fields are marked in text, not by colour or asterisk alone.
• Error identification (3.3.1) — when validation fails, describe the error in text, link to or move focus toward the field, and set aria-invalid="true" with aria-describedby pointing at the message.
• Error suggestion (3.3.3) — tell users how to fix it, with an example format where relevant.
• Status messages (4.1.3) — announce “3 errors found” in an ARIA live region so screen-reader users hear it without losing their place.
• On input / on focus (3.2.1, 3.2.2) — do not auto-submit or navigate away when a select changes; warn first.
• Identify input purpose (1.3.5) — use correct autocomplete tokens (name, email, address) so autofill works.

The single most valuable test you can run today: try to complete a purchase on your own shop using only the keyboard, with your eyes closed for the checkout step. If you can’t, neither can a large group of your customers.

Two design patterns deserve special mention because they routinely cause failures on PrestaShop checkouts. The first is the floating-label / placeholder-only field, where the label disappears once the user starts typing. This looks elegant but violates 3.3.2 if the label is not programmatically present at all times; keep a real, persistent <label> even if it is visually compact. The second is inline validation that fires on every keystroke and announces an error before the user has finished typing — this can bombard screen-reader users with repeated interruptions. Validate on blur or on submit, keep the live region aria-live="polite" rather than assertive, and only announce the final state.

Finally, do not forget the order confirmation and post-payment steps. A user who has fought through an inaccessible payment step and then cannot tell whether their order succeeded has, in practice, been denied the service. The confirmation page needs a clear heading, an announced success message, and order details in readable, structured text — not solely inside an image or a colour-coded badge.

Images, media and alt text

Text alternatives (1.1.1) are the foundation of a perceivable shop. The rule is simple to state but needs judgement to apply well:

• Informative images (product photos) need concise, descriptive alt text — describe what matters for the sale (“Navy wool overcoat, front view”).
• Decorative images (background flourishes, spacer graphics) take an empty alt (alt="") so screen readers skip them.
• Images of text (promo banners with the offer baked into a JPEG) should be avoided; if used, the text must be in the alt and meet contrast.
• Video and audio need captions for pre-recorded speech and, where relevant, a transcript or audio description.
• Avoid content that flashes more than three times per second (2.3.1) to protect users prone to seizures.

A frequent trap in e-commerce is the repeated product image where the alt simply repeats the product name that is already the adjacent link text — this creates verbose, duplicated announcements. Coordinate the link text and the alt so the user hears the product once, clearly.

Semantic structure and headings

Screen-reader users navigate by headings and landmarks the way sighted users skim by eye. Info and relationships (1.3.1) requires that the structure conveyed visually is also conveyed in the markup.

• Use one <h1> per page (the page’s main subject — usually the product name or category), then nest <h2>/<h3> logically without skipping levels for styling reasons.
• Use HTML5 landmarks — <header>, <nav>, <main>, <footer> — so users can jump between regions.
• Use real lists, tables and buttons — a <div> styled to look like a button is not a button to assistive tech.
• Reserve tables for tabular data (the cart, size charts), with proper <th> headers.

Accessible custom components

Custom widgets — dropdowns, modals, carousels, tabs, accordions — are where robustness (4.1.2 name, role, value) is most often lost, because JavaScript-built controls do not automatically expose their state. When you build or install these, ensure:

• Custom dropdowns / comboboxes — use native <select> where possible; if custom, apply the ARIA combobox/listbox pattern with arrow-key support and aria-expanded.
• Modals — role="dialog", aria-modal="true", an accessible name, focus trapped inside, Escape closes, focus returns to the trigger.
• Carousels — pause control (2.2.2), keyboard-operable next/previous, and slides that are not focus-hidden when off-screen mishandled.
• Tabs / accordions — correct roles (tablist, tab, tabpanel) and aria-selected/aria-expanded state.

Testing your shop

No single tool proves compliance. A credible test regime combines automated scanning, manual keyboard testing and real screen-reader use. Each catches things the others miss.

Automated tools (and their limits)

• axe (browser extension / DevTools) — excellent for contrast, missing labels, ARIA misuse.
• Lighthouse (built into Chrome) — a quick accessibility score plus performance and SEO.
• WAVE — visual overlay highlighting errors, alerts and structure on the page.

The crucial caveat: automated tools reliably catch only a minority of WCAG issues — typically the machine-detectable ones like contrast and missing alt attributes. They cannot judge whether alt text is meaningful, whether tab order makes sense, or whether an error message is helpful. Passing axe with zero errors does not mean you are compliant.

Manual keyboard test

Unplug your mouse. Using Tab, Shift+Tab, Enter, Space, arrow keys and Escape, complete a full journey: search, open a product, choose a variant, add to cart, open the cart, and check out. Watch for a visible focus ring at every step, logical order, no traps, and working modals.

Screen-reader testing

Test with at least one real screen reader: NVDA (free, Windows) or VoiceOver (built into macOS and iOS). Listen to how headings, images, form labels, errors and status messages are announced. This is the closest you can get to your disabled customers’ actual experience — and it surfaces problems no scanner will.

Writing an accessibility statement

Publishing an accessibility statement is good practice and signals a genuine commitment. It typically sets out the standard you aim for (WCAG 2.1 AA / EN 301 549), any known limitations you are working to fix, the date it was last reviewed, and — importantly — a way for users to report problems and request assistance. A reachable contact route for accessibility feedback also aligns with the complaint mechanisms member states operate under the EAA.

A useful statement is honest rather than aspirational. Rather than claiming perfect conformance, describe the standard you target, note the areas you know still fall short (for example, “a third-party review widget in our product pages is not yet fully keyboard-operable; a fix is scheduled”), and give a realistic review cadence. Include an accessible email address or form and commit to a response time. This transparency is both fairer to users and more defensible than a bald claim of full compliance that a single failing page would contradict.

• The conformance target — WCAG 2.1 AA, aligned with EN 301 549 and the EAA.
• The scope — which parts of the shop the statement covers (ideally the whole purchasing journey).
• Known limitations and your plan and timeline to address them.
• A feedback and contact mechanism, with an expected response time.
• The date the statement was last reviewed or updated.

Enforcement, complaints and risk

Because the EAA is a directive, enforcement is national. Each member state designates market-surveillance and service-supervision authorities and operates complaint mechanisms so consumers can report inaccessible services. Where a service is found non-compliant, authorities can order the provider to bring it into conformity, and can impose penalties set at national level — these vary by country, so the specific figures depend on where your customers are. There are some transition arrangements: certain self-service terminals already in use may benefit from long transition periods (up to around 2045), but the core service application date remains 28 June 2025. In short, the safe assumption for an online shop is that the obligation is live now.

Beyond regulators, expect scrutiny from disability advocacy groups and individual consumers, and remember that accessibility overlaps with other duties — usable, understandable interfaces also support fair-trading and consumer-information expectations you can read about via our Omnibus coverage, and AI-driven features on your shop may additionally engage the AI Act.

PrestaShop implementation notes

Translating WCAG into a live PrestaShop shop comes down to a handful of concrete workstreams. PrestaShop’s default themes are a reasonable starting point but are not automatically fully compliant, and third-party themes and modules vary widely.

• Theme choice — audit your theme (or shortlist candidates) against the room-by-room criteria above before committing. A theme that fails on focus styles and contrast will cost more to fix than to replace.
• Template ARIA — in your .tpl templates, add correct labels, roles and states to custom navigation, off-canvas menus, quick-view modals and variant selectors. Prefer native HTML controls before reaching for ARIA.
• Checkout module accessibility — the one-page checkout and any payment modules are your highest-risk area. Verify field labels, error handling, keyboard operability of card/iframe fields, and live-region announcements. Test each payment method you actually offer.
• Colour tokens — centralise brand colours as SCSS/CSS variables (design tokens) and set them to pass 4.5:1 (text) and 3:1 (UI/large) from the outset, so every component inherits compliant contrast.
• Alt-text discipline for product images — enforce a rule that catalogue images carry meaningful alt text; use the image caption/alt fields in the back office and build it into your product-onboarding checklist.
• Testing workflow — bake axe/Lighthouse into your release checks, and run a manual keyboard + NVDA/VoiceOver pass on the homepage, a product page and the full checkout before every significant theme or module change.

Common mistakes to avoid

• Treating an automated scanner’s “0 errors” as proof of compliance.
• Using placeholder text as the only label on checkout fields.
• Removing focus outlines for “clean” design, stranding keyboard users.
• Signalling sale/stock status with colour alone.
• Auto-advancing carousels with no pause control.
• Custom <div> “buttons” and dropdowns with no role, name or keyboard support.
• Assuming an installed “accessibility overlay” widget makes the shop compliant — it generally does not, and can introduce new problems.
• Testing only the homepage and forgetting the payment step, where the risk is highest.

Mini-FAQ

I’m a small shop — am I automatically exempt?

Only if you meet both parts of the microenterprise test for services: fewer than 10 persons employed and annual turnover or balance-sheet total not exceeding €2 million. Fail either and you are in scope. See who must comply for detail.

Do I need WCAG 2.1 AA or AAA?

The EAA, via EN 301 549, targets WCAG 2.1 level AA (which includes all level A criteria). AAA is not required across the board. Aim for AA everywhere on the purchasing journey.

Will an accessibility overlay plugin make me compliant?

No. Overlays and “one-click” widgets do not fix the underlying HTML, often can’t address keyboard, structure or error-handling issues, and have themselves been the subject of complaints. Real compliance comes from fixing the code and content.

What is the single most important thing to fix first?

Your checkout and forms. It is the highest-risk area both legally and commercially: labels, keyboard operability, and clear error identification and suggestion. An accessible checkout protects revenue as well as compliance.

Since when does this apply?

The EAA’s core requirements apply from 28 June 2025. The obligation is already live, so treat accessibility work as current, not future.

This guide is educational and does not constitute legal advice. Accessibility law under the European Accessibility Act is transposed and enforced nationally, and your specific obligations depend on your size, the markets you sell to and your setup. For advice on your particular circumstances, consult a qualified professional. For the underlying law, see the official text at EUR-Lex and our overview at our Accessibility law page.