PrestaShop and the European Accessibility Act

What PrestaShop requires of themes

PrestaShop's developer documentation states thataccessibility is a hard requirement for new themes, not an optional enhancement, and aligns theme guidelines with WCAG 2.2 level AA. That is a stricter and more specific commitment than the other major platforms publish, and it is worth knowing in detail because it tells you what to expect from a current theme and what to raise with its developer.

• Keyboard operation. Every interactive element must be reachable and operable without a mouse, with skip links, a logical tab order and visible focus indicators.
• Focus management. Opening a modal or overlay must move focus inside it and trap it there. Focus must be restored after AJAX updates, and the page must not reset unexpectedly to the top.
• Contrast. 4.5:1 for normal text, 3:1 for large text at 18 px and above, and never colour alone to carry meaning.
• Forms. Every control needs an associated label or ARIA equivalent, and required fields must be marked both visibly and programmatically.
• Content alternatives. Alt attributes on images, captions on video and audio.
• Headings. h1 to h6 in order with no skipped levels, because the heading outline is how screen reader users move through a page.
• ARIA last. Semantic HTML first, ARIA for states and accessible names where HTML cannot express them.

Source: PrestaShop developer documentation — accessibility requirements.

The gap: those rules apply to new themes

The requirements govern new themes and contributions to the ecosystem. They do not retroactively audit the theme your shop is running today. Most PrestaShop shops of any age are on a customised Classic derivative or a commercial theme bought years ago, neither of which was reviewed against guidelines that did not exist at the time.

Use the list above as an audit checklist rather than as a guarantee. Each line is a concrete thing you can test on your own shop in a few minutes, and the keyboard ones need no tooling at all.

AJAX is the PrestaShop-specific trap

PrestaShop leans on AJAX for the parts of the shop customers use most: faceted search filters, the cart, quantity changes, variation selection. PrestaShop's own guidelines call out focus restoration after AJAX updates specifically, which is a good sign about the platform and a warning about the modules bolted onto it.

The failure looks like this. A customer filters a category by size using the keyboard. The module replaces the product list. Focus is lost, the customer lands back at the top of the document, and nothing announces that the results changed. Visually it is obvious that something happened. Without sight of the screen, nothing happened at all. Test it by applying a filter using only the keyboard and seeing where focus ends up.

Where PrestaShop shops fail

Modules

The module marketplace is the main source of third-party markup in a shop: sliders, cookie banners, popups, live chat, faceted search, review blocks. There is no accessibility gate comparable to the theme guidelines, and modules routinely inject their own controls. Disable modules one at a time when a finding matches nothing in your theme.

Product data

Alt text is a field on the image in the back office. Catalogs imported from a supplier feed or migrated from another platform arrive with it empty, and no theme fix reaches product data. Combination names matter too: a variation selector that announces only a code is not usable by someone who cannot see the swatch.

Multi-language shops

PrestaShop's multi-store and multi-language features are a strength and a trap. Every language version needs the correct language attribute on the page, and alt text and link text have to be translated along with everything else. A shop that switches language while leaving the page language attribute on the default makes a screen reader read French copy with an English voice.

The back office

Worth remembering that if you have employees, the administration interface is a workplace tool. It is outside the EAA's consumer service scope, but employment accessibility obligations exist separately in most member states.

What to do, in order

1. Scan the home page, a category page and one product page. Category pages matter here because that is where the faceted search module lives.
2. Filter a category using only the keyboard and watch where focus goes when the results update.
3. Audit alt text in the back office, at the source, across the catalog.
4. Check the language attribute on each language version of the same page.
5. Walk the full purchase journey with the keyboard, including the cart update and the checkout validation errors.
6. Publish an accessibility statement. Thestatement generator fills in the enforcement authority and complaint route for your country.

What a scan cannot tell you

Automated testing typically catches an estimated 20–50% of real accessibility issues. On a PrestaShop shop the untestable part is mostly behaviour over time: where focus goes after an AJAX update, whether a filter change is announced, whether the variation selector makes sense aloud, and whether a cart error explains what to do. Those need a person with a keyboard. A clean scan is a floor, not a certificate.