Ecommerce Accessibility in 2026: Audit Your PrestaShop Journey
Ecommerce accessibility means customers can find, understand and buy products using different ways of interacting with a website. A working checkout for someone using a mouse does not demonstrate a working checkout for someone navigating with a keyboard or screen reader.
The European Accessibility Act has applied since 28 June 2025 and covers ecommerce services within its scope, with exemptions and transitional provisions. Check the applicable national implementation and your business's position; this practical audit is not a legal conformity assessment. The EUR-Lex summary explains the framework.
Start with one complete buying journey in your PrestaShop store. You will create reproducible findings, assign fixes and retest the customer task after changes.
1. Define a Buying Task and Its Boundaries
Choose a task that a real customer can complete: find a blue notebook, select the required size, understand delivery and place a test order using an approved test payment route.
List every interface involved. Include navigation, search, filters, product options, the cart, consent controls, address entry and the payment handoff.
Record the theme, relevant module versions, browser, device and date. Accessibility can change when a payment or consent component updates even if your product template remains unchanged.
Start with the normal route, then add a return visit, a form error and an unavailable variant. Those states often reveal obstacles that a screenshot of the first page cannot show.
2. Prepare a Findings Sheet With Observable Results
Write down the exact action, what happened and what should happen for the customer. Avoid vague reports such as “checkout is not accessible.”
| Field | Example |
|---|---|
| Page and state | Address form after submitting an empty required field |
| Input method | Keyboard only |
| Reproduction | Tab to Continue and activate it |
| Observed result | Error appears, but focus remains far from the affected field |
| Customer impact | Shopper cannot easily identify how to continue |
| Owner | Checkout module maintainer |
| Retest | Repeat the same action after the fix |
Use screenshots or short recordings where they help, but include written steps. A video without the browser and starting state can be difficult for a developer to reproduce.
Prioritise barriers that prevent completing the task. Cosmetic inconsistencies can wait behind a payment dialog that traps the customer.
3. Walk the Journey Using Only the Keyboard
Put the mouse aside and navigate from the page entry point. Observe where focus moves, whether you can see it and whether you can activate the same meaningful controls available to mouse users.
Test menus, filters and product options deliberately. A visually attractive colour swatch is not usable through the keyboard if it cannot receive focus or communicate which option is selected.
Open and close dialogs, including the cart preview and consent panel. Check that leaving a dialog returns you to a sensible place and that no component strands you inside it.
W3C's keyboard focus guidance provides a useful starting reference. Document the exact interaction that failed rather than assuming all keyboard problems share one technical cause.
Repeat the exercise after adding an item to the cart. Dynamic changes can alter focus behaviour in ways that the empty-cart version does not reveal.
4. Check Product Choices and Form Instructions
Make the decision information available alongside the control. A customer needs to know the option name, current selection, required information and any relevant constraint.
For the notebook example, inspect how the size choice is identified and how the selected colour is communicated. Do not rely on colour alone to indicate an unavailable or selected option.
On the address form, check that instructions remain understandable after typing. A placeholder that disappears may not provide enough persistent context for someone reviewing their entries.
Create an invalid postcode or omit a required field in the test. The resulting message should explain what needs correction, identify the field and preserve the useful information already entered.
Use the W3C forms tutorial as a technical reference for the implementation owner. Your merchant acceptance test is whether the shopper can recover from the error without guessing.
5. Test Enlarged Content and Small Screens
Increase browser zoom and review the same task. Look for text or controls hidden behind fixed banners, clipped prices and horizontal movement that makes a form difficult to follow.
Check the product specification table, not only the introduction. A customer deciding whether an item fits needs access to the dimensions at their preferred text size.
Then test on a small screen with the on-screen keyboard open. Sticky buttons and chat widgets can cover fields that looked fine before text entry began.
Record the viewport and zoom level with the finding. Ask the implementation owner to assess the applicable technical criteria; the purpose of your test is to expose a concrete buying obstacle.
Avoid a fix that simply disables zoom. The successful result is a usable layout when content is enlarged.
6. Review Images, Headings and Reading Order
Read the page without relying on its decorative layout. The product name, price, options, delivery information and action should form a meaningful sequence.
Check whether image alternatives convey the information needed for the task. A photograph showing the exact contents of a set needs different treatment from a purely decorative background.
Use a screen reader with someone who understands the tool, or involve an accessibility specialist. A novice's difficulty operating assistive technology should not be confused with a confirmed website defect.
W3C's first-review guidance covers useful initial checks and explicitly explains their limits. Passing a short checklist does not establish that the whole service meets every requirement.
Add findings about meaningful content to the catalogue owner's work, not just the developer's queue. Missing product information can remain a barrier even after the HTML is improved.
7. Include Third-Party Payment and Support Components
Test the actual payment route in a suitable test environment, including authentication, cancellation and return to the shop. A usable address form is only part of a successful purchase.
Record where responsibility changes between your theme, checkout module and payment provider. Send each maintainer the smallest reproducible example affecting their component.
Include any customer-support chat that covers the page or takes focus. Provide an accessible alternative contact route when evaluating a new support tool.
Use the payment failure workflow to check recovery messages after an unsuccessful payment. Accessibility and operational accuracy must hold together: the customer should understand both what happened and what to do next.
Do not approve a component solely because its vendor publishes a broad accessibility statement. Verify the configuration and journey your customers actually use.
8. Retest Fixes and Keep the Journey in Release Checks
Assign an owner, priority and expected result to each finding. After a fix, rerun the original steps and confirm the customer can proceed.
Check adjacent states as well. Fixing focus in one dialog should not remove it from the next payment step or break the mobile layout.
Keep a short recurring test set for changes to the theme, consent manager, product options and checkout. Record when the tests ran and which versions were involved.
For a broader assessment, plan specialist evaluation and participation by people with relevant disabilities. Your initial audit creates useful evidence and priorities; it does not replace that expertise.
9. Common Accessibility Audit Problems
| Problem | Likely cause | What to check or change |
|---|---|---|
| A colour option cannot be selected by keyboard | Custom control lacks a usable interaction model | Reproduce the option selection for the component owner |
| Errors appear but customers cannot locate them | Error feedback and focus are disconnected | Test the submitted invalid form and recovery path |
| A banner covers the payment button | Fixed elements conflict at small sizes or zoom | Check the actual viewport with all widgets open |
| Automated scan passes but buying fails | The scan did not exercise interactive states | Add manual task-based testing |
| A module update reintroduces a barrier | Accessibility checks were absent from release review | Retest the saved journey after relevant changes |
10. Buying-Journey Audit Checklist
- The task includes discovery, options, cart and payment.
- Browser, device and relevant versions are recorded.
- Keyboard navigation reaches and operates essential controls.
- Selected options and errors are understandable.
- Enlarged content remains usable.
- Product information has a meaningful reading order.
- Third-party dialogs and payment recovery are included.
- Findings have owners and reproducible retest steps.
Frequently Asked Questions
Does the European Accessibility Act apply to every online shop identically?
No. Scope, exemptions, transitional provisions and national implementation need to be assessed for the business and service. Use the official framework and appropriate local advice rather than assuming a single rule fits every merchant.
Is an automated accessibility score enough?
No. Automated checks can identify some issues, but they do not demonstrate that someone can complete every interactive shopping task. Combine them with manual testing and suitable specialist assessment.
Can I solve accessibility by installing one widget?
Do not treat a widget as proof that the buying journey is accessible. Test the underlying theme, forms, product controls and third-party components using the same customer tasks.
Should I test only the checkout?
Test the route that allows the customer to reach and use checkout. Search, filters, product choices and delivery information can prevent a purchase before the payment page appears.
Who should fix a problem inside a payment dialog?
Identify the component owner and provide a reproducible case with the configuration details. Your shop still needs to assess the overall customer journey and coordinate the resolution.
What can a small team do first?
Run one complete keyboard journey and one enlarged-content journey, then document the barriers that block progress. Use those findings to prioritise work and determine where specialist help is needed.