Table of contents
- Why Accessibility in PrestaShop is an obligation and an opportunity
- WCAG 2.1 AA requirements: Key criteria for Online stores
- PrestaShop Store Availability Audit: process, tools, and scope of testing
- Practical fixes in PrestaShop: themes, modules, and specific changes
- Legal compliance, declaration of availability and estimated costs
- Accessibility as a long-term advantage for the store
Why Accessibility in PrestaShop is an obligation and an opportunity
94% of online stores have significant barriers to usability, and at the same time 15% of the world’s population lives with a disability; in Poland, this is > 4 million people. For e-commerce, this means real lost demand and legal risks. In PrestaShop, where competition is high, accessibility is no longer a ‘good addition”.
94% of stores with barriers • 15% of the population • >4 million in Poland
WCAG 2.1 AA is an international standard for the accessibility of digital content that regulates the expectations of online stores. Since 28.06.2025 , electronic stores in the EU must comply with the requirements of the European Accessibility Act (EAA). It’s not a matter of theory-it’s a legal requirement that also includes PrestaShop-based sales platforms.
Business benefits and legal risks
Accessibility is about growth, not cost. Better content structure and navigation support SEO, which can lead to +12% organic traffic. Clearer forms and the purchase process improve conversion rates for all users, not just for people with disabilities. It also has a lower bounce rate and fewer abandoned buckets.
On the other hand, enforcement of laws is increasing. In Poland, there are fines and adjustment orders, and proceedings can result in financial sanctions (even from PLN 1,490) and an obligation to publish an Accessibility Declaration. Reputational risks are just as serious as the penalty.
Next, we’ll show you how to approach the audit, which fixes in PrestaShop (theme, modules, code) are key, and how to prepare an availability declaration and estimate costs.
WCAG 2.1 AA requirements: Key criteria for Online stores
WCAG 2.1 AA principles are based on the POUR model: perceptibility, functionality, legibility, and reliability. For online stores, this means specific, measurable technical criteria that affect access to the offer, shopping cart, and purchase process for all users.
Perceptible: images, audio, and contrast
The content should be perceived independently of the senses. In e-commerce practice, this includes:
- Alternative text for non-decorated images that describes the product and option, such as ‘ red dress model X”’
- Subtitles or transcripts for audio and video materials (product presentations, instructions).
- Text scalability up to 200% without loss of functionality or the need for horizontal scrolling.
- Color contrast: ≥4.5: 1 for normal text and ≥3: 1 for large text and interface elements (icons, buttons).
Operated: keyboard and interactive elements
The interface must be supported without a mouse. Key requirements:
- Full keyboard navigation using Tab, Enter, Space and arrows in all areas of the store.
- No keyboard traps and proper support for sliders and modals.
- The visible focus display is at least 2 pixels thick.
- Prohibits flickering of elements more than 3 times per second.
The rest of the POUR rules complement everything else:
- Understandable: logical header structure (one h1, consecutive h2-h6), easy-to-read form labels, and clear error messages, such as those related to the ‘invalid email” description, and consistent navigation.
- Robust: semantic HTML5, correct ARIA roles (for example, role= ‘navigation’, aria-label for icons), compatibility with NVDA, VoiceOver, and JAWS readers, and no W3C validation errors.
Meeting these criteria creates a solid foundation for further audit of the store’s availability.
PrestaShop Store Availability Audit: process, tools, and scope of testing
Availability audit is the starting point for WCAG 2.1 AA compliance and secure implementation solutions. This results in a reproducible result that is legally and technically protected. Below you will find a practical plan: the scope of testing, tools, and how to document it without going into implementation.
What exactly should I test in the store
The audit scope should include key user paths and interface components:
- home page, product lists, product card
- shopping cart and full Flow checkout
- forms (registration, login, contact)
- titles, menus, search engine
- dynamic elements: sliders, modals, built-in validation
Also check error states, messages, keyboard focus, and text alternatives. Run tests on the desktop and mobile phone, in the main browsers, to identify differences in the behavior of components.
Tools: automata + manual testing
Using a combination of automatic and manual. WAVE tests helps you visually determine contrast, structure, and labels. axe DevTools and Lighthouse (Chrome) will quickly point out software errors. Then perform manual keyboard tests with both NVDA and VoiceOver readers. Complete the audit with a code review in W3C validator and mobile tests.
Report and prioritize errors (blockers, critical ones, minor ones). Each entry must include a URL, description, WCAG criteria, playback steps, and screenshots or recordings.
| URL | Problem | WCAG criterion |
|---|---|---|
| /checkout | Lack of focus | 2.4.7 |
This report becomes a checklist for the next stage: planning fixes in PrestaShop.
Practical fixes in PrestaShop: themes, modules, and specific changes
The purpose of this section is to show you specific technical settings that you can implement without having to rebuild the entire store. We focus on theme editing, ARIA usage, CSS styles, and conscious module selection in PrestaShop, according to WCAG 2.1 AA.
Changes to the theme and templates
Start with theme files such ashead.tpl and product card templates. Make sure that each subpage has a single logical h1, and that lower-order headers are not skipped. Non-decorative images should have alternative descriptions. In PrestaShop, you can add them to backoffice for products and categories. You should also replace extra divs with HTML5 elements, such. as nav, main, and footer, which improves readability for screen readers.
Arias and semantic elements
Use ARIA only where HTML semantics are insufficient. In the main menu, selectroles = 'navigation', and for icons without text, add an aria-label, for example, for the shopping cart. In forms, use aria-descripedbyto associate the field with an error message or tooltip. Example: The email field indicates an error description identifier that the reader will read at the appropriate time, without duplicating the visual content.
Focus, Contrast, and Style
Visible keyboard focus is a quick win. In CSS, add a rule in the style of: focus { outline: 2px solid # 000;} or another contrasting color. Check the contrast of the text relative to the background-at least ≥4.5: 1 for the main content. Also take care of scaling: the text should not ‘break” at 200% magnification, and the layout should remain responsive on mobile.
In the add-ons area, consider accessibility modules as support. Tools for PLN 499 net or manual fixes starting from PLN 1490 help, but overlays (accessiBe, UserWay) do not replace changes in the theme and code that actually improve accessibility.
Legal compliance, declaration of availability and estimated costs
WCAG 2.1 AA compliance is not only a matter of usability, but also a legal obligation for online stores operating in the EU. In this section, you will learn who the rules apply to, what elements the accessibility declaration should include , and what actual costs should be considered.
Who needs to adapt and when
Since 28.06.2025 , e-shops are subject to the EAA (Directive 2019/882), which means the requirement to ensure digital accessibility and publish a public declaration. In Poland, non-compliance carries the risk of administrative sanctions of up to 10 timesthe average salary, as well as operating costs associated with complaints and inspections. Microenterprises are an exception, but even these can be covered by obligations if they offer cross-border services or use public funding.
The accessibility ad should be easily accessible (for example, in the footer). and contain:
- WCAG 2.1 AA compatibility level,
- date of the test,
- evaluation method (manual / automatic),
- contact information for comments,
- information about the exceptions used.
Costs: audit, modules, services
The budget depends on the size of the store and the exit status. Market meets:
- availability audit and basic implementation: from several hundred to several thousand PLN,
- basic services of the ‘starter package’ type: about 1 900 PLN.,
- modules that support accessibility: from PLN 499 net.
There are also free overlays, but they do not guarantee full compliance and do not replace auditing. Reasonable cost planning reduces legal risks and promotes further development of the store.
Accessibility as a long-term advantage for the store
Holistically perceived accessibility combines legal compliance with mature UX and visibility in SEO, creating a consistent foundation for online store profitability in business practice. This is not a one-time cost, but a mindset that stabilizes sales, reduces friction across the entire shopping funnel, and systematically builds brand confidence. In the reality of Polish e-commerce, where competition and customer expectations are growing, such a standard meets long-term market and consumer trends.
By treating accessibility as an investment in the quality of the experience, you create a change-resistant store that is closer to users and more reliable in the eyes of the market, which over time naturally leads to quiet growth, brand stability, and a sustainable competitive advantage in the long run.

![[:pl]Prestashop WCAG 2.1 AA[:]](https://i0.wp.com/balcerzak.it/wp-content/uploads/2026/02/wcag2-1.png?fit=1536%2C1024&ssl=1)