If you run a PrestaShop store selling to customers in the EU, accessibility is no longer optional. Since 28 June 2025, the European Accessibility Act (EAA, Directive (EU) 2019/882) requires most consumer-facing e-commerce to meet WCAG 2.2 Level A and AA, referenced through the EN 301 549 standard. PrestaShop's default Classic theme gets you partway there, but the components that actually convert, product pages, faceted search, and checkout, are where most stores fail.
This guide works through the platform module by module, with concrete fixes you can apply in your theme templates and CSS rather than vague advice. Wherever a problem maps to a specific success criterion, it is named so you can verify the fix yourself.
Where PrestaShop accessibility usually breaks
PrestaShop themes are built on Smarty templates (.tpl files) and Bootstrap-derived markup. The Classic theme is reasonable out of the box, but most live stores run a paid theme or a heavily customized child theme, and that is where regressions creep in. The recurring offenders are low-contrast accent colors, icon-only buttons with no accessible name, decorative sliders that trap keyboard focus, and modules that inject markup without ARIA.
Before touching templates, run an automated scan to triage. A free tool like AccessScan surfaces the bulk issues, missing alt text, contrast failures, unlabeled controls, in minutes. Treat that as your starting backlog, then work through the manual checks below that automation cannot catch, such as keyboard order and screen-reader logic. The full picture lives in our accessibility checklist. You can start a free scan to build that backlog.
Themes: contrast, focus, and target size
Start with color. Many PrestaShop themes ship a brand accent (sale badges, the add-to-cart button, link hover states) that fails WCAG contrast. Body text needs a 4.5:1 ratio against its background; large text (18pt, or 14pt bold) and UI component boundaries need 3:1. A common failure is a light-grey price or a pale 'In stock' label on white. Audit your palette and fix the SCSS variables in your child theme rather than overriding inline.
Next, focus visibility. PrestaShop themes frequently strip the browser outline with outline: none for aesthetics, which breaks 2.4.7 Focus Visible (AA) and makes keyboard navigation impossible to follow. Restore a clear focus ring, a 2px solid outline with an offset works well, on every link, button, and form field. WCAG 2.2 also adds 2.4.11 Focus Not Obscured (Minimum) (AA): make sure your sticky header does not cover the focused element as a user tabs down the page.
Finally, target size. WCAG 2.2's new 2.5.8 Target Size (Minimum) (AA) requires interactive controls to be at least 24x24 CSS pixels (with documented exceptions such as spacing or inline text). The usual culprits in PrestaShop are the quantity +/- steppers on product and cart pages, the close 'x' on cart popups, and color/size swatches packed tightly in a row. Add padding so each tap target meets the minimum without overlapping its neighbor.
Product pages: images, variants, and 'on hover' content
Product images are the most visible alt-text gap. PrestaShop pulls the alt attribute from the image's legend field in the back office, and if that field is blank, the theme often outputs the file name or nothing. Write descriptive alternatives for primary product photos and combination images; mark purely decorative thumbnails as empty alt (alt="") so screen readers skip them.
Combinations (size, color) rendered as custom dropdowns or swatch buttons must expose state to assistive tech. A selected swatch needs more than a CSS border; use a real radio input or aria-pressed/aria-checked so a screen-reader user knows which variant is active. The price and availability text that updates via AJAX when a combination changes should sit in an aria-live="polite" region (4.1.3 Status Messages, AA), otherwise the change is silent.
Watch tooltips and quick-view popovers. Size guides or delivery-info bubbles that appear on hover must satisfy 1.4.13 Content on Hover or Focus (AA): dismissable, hoverable, and persistent. Headings on the product page should follow a logical order (one h1 for the product name, then h2 for description, reviews, and related products) so screen-reader users can navigate by structure; check that no heading levels are skipped.
Faceted search: the filter trap
PrestaShop's Faceted Search module (the layered navigation on category pages) is one of the biggest accessibility liabilities for most stores. It rewrites the product grid via AJAX as filters are applied, and by default nothing announces that the results changed. A sighted user sees the grid refresh; a screen-reader user hears silence. Wrap the results count in an aria-live="polite" region so a message like '24 products found' is announced after each filter change (4.1.3 Status Messages).
- Make every filter a real, labeled control: checkboxes and radios with associated
<label>text, not clickable<div>or<a>elements that keyboards cannot operate. - Ensure the price slider is keyboard-operable. 2.5.7 Dragging Movements (new in WCAG 2.2, AA) requires a non-drag alternative, so a range input that responds to arrow keys, or min/max number fields, must exist alongside the drag handle.
- Keep focus stable after a filter is applied. If the grid re-renders and focus jumps to the top of the page, keyboard users lose their place; return focus to the control they activated.
- Expose the active filter count and a clear 'remove filter' control with an accessible name, not a bare 'x' icon.
Because faceted navigation is essentially an accessible search-and-filter pattern, the same semantics, labeled controls, keyboard operation, and live result announcements, apply to any category or search results page on your store.
Cart and checkout: forms are where compliance is won or lost
Checkout is the highest-stakes flow because an inaccessible form means a customer literally cannot buy. PrestaShop's one-page checkout is a series of collapsible sections (address, delivery, payment), and each needs careful form semantics. Every input must have a programmatically associated label; placeholder text alone does not count and disappears on focus. Group related fields with <fieldset> and <legend>, and set autocomplete attributes (e.g. autocomplete="email", "postal-code") so browser and assistive-tech autofill works.
Error handling carries several criteria at once. When validation fails, identify the error in text next to the field (3.3.1 Error Identification, A), describe how to fix it (3.3.3 Error Suggestion, AA), and move focus to the first error or announce it in a live region. PrestaShop's default validation often only colors the field border red, which fails for colorblind and screen-reader users. For the final order step, 3.3.4 Error Prevention (Legal, Financial, Data) (AA) means the customer must be able to review and correct their order before it is submitted.
WCAG 2.2 adds three criteria that hit checkout directly: 3.3.7 Redundant Entry (A) (do not force re-typing the billing address if it equals shipping, offer a 'same as' option), 3.3.8 Accessible Authentication (Minimum) (AA) (if you require account login, do not block password managers or paste), and 3.2.6 Consistent Help (A) (keep contact or support links in a consistent location).
EAA implications and documenting compliance
The EAA sets WCAG 2.2 A and AA as the practical baseline for EU e-commerce via EN 301 549; PrestaShop merchants selling to EU consumers are generally in scope, though the directive provides limited exemptions (for example, certain microenterprises providing services). Enforcement is handled per member state, so the exact body and process depend on where your customers are, but the technical bar is the same standard everywhere. Background on the law is in our European Accessibility Act explainer.
Two things make a real difference for store owners. First, publish an accessibility statement describing your conformance level, known limitations, and a contact route for users who hit a barrier; you can produce one with our accessibility statement generator. Second, treat accessibility as ongoing rather than a one-time project: every theme update, new module, and promotional banner can introduce regressions, so re-scan after each significant change. The current criteria and levels are summarized in our WCAG reference.