Open source ecommerce for the European Accessibility Act: what applies to your shop
If you sell to EU consumers online, the European Accessibility Act already applies to your shop. Directive (EU) 2019/882 lists e-commerce services among the covered services (Article 2(2)), and its measures have applied since 28 June 2025 (Article 31(2)). For a self-hosted store, the function in scope is the storefront, the checkout and the customer account flows: product browsing, search, cart, payment steps, login, registration and order history. Your platform choice (Magento Open Source, WooCommerce, Saleor, Medusa or a custom headless build) does not change whether the duty applies, only how much remediation work your theme, plugins and checkout need.
Three provisions decide how the Act reaches your business. Article 4(5) exempts microenterprises providing services from its service requirements, so a shop that qualifies should confirm its headcount and turnover against the Directive's definition with its legal adviser before relying on the exemption. Article 32(1) lets a service provider keep using products already in use to deliver similar services until 28 June 2030, which can cover an existing storefront, but new components, redesigned checkout flows and replacement themes you deploy now should be assumed to meet the requirements from the start. Confirm with counsel how the transition applies to your specific stack.
DeployOpen prepares the systems, controls and evidence that support your accessibility position, including remediation against WCAG 2.2 and test records. It does not issue audit reports, attestations or certifications. Ask any implementation partner, DeployOpen included, to state in writing which parts of the work are engineering and testing and which assessment, if any, you still need from an independent body. The EUR-Lex text of Directive (EU) 2019/882 is the reference to share with your legal team before scoping the work.
Which WCAG 2.2 criteria the storefront, checkout and account must meet
This table maps the European Accessibility Act e-commerce duties to the WCAG 2.2 criteria that most often fail on storefronts, checkout and customer accounts, and shows how each is handled on Magento Open Source, WooCommerce or a headless build. Read each row as a starting checklist for a page-by-page audit, not as proof of conformance. WCAG 2.1 criteria still apply alongside the new 2.2 criteria, so every template must be tested, not assumed to pass.
| Requirement | What the function must do | How to configure it on Magento Open Source, WooCommerce or headless |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | Keep the focused control visible when sticky headers, cookie banners, chat widgets or mini-carts overlay the page during keyboard navigation. | Magento: review sticky header and minicart CSS in the theme and cookie module. WooCommerce: check theme sticky elements and consent plugin layers. Headless: test fixed overlays in the storefront framework with keyboard-only runs. |
| 2.5.8 Target Size (Minimum) | Give interactive controls such as quantity steppers, remove-item links and filter chips a target area large enough to activate without precision pointing. | Magento: set minimum sizes for cart and filter controls in the theme. WooCommerce: adjust block theme and cart block styles. Headless: enforce in the component library so every checkout and product component inherits the rule. |
| 3.3.8 Accessible Authentication (Minimum) | Do not require a cognitive function test, such as remembering a password or solving a puzzle, to log in, unless an alternative or helper exists. Password managers and paste must work in login and registration forms. | Magento: confirm customer login and one-time code flows allow paste and password managers. WooCommerce: review login plugins and magic-link or CAPTCHA settings. Headless: confirm the identity provider offers passkeys, email links or autofill-friendly fields. |
| 4.1.1 Parsing (removed in WCAG 2.2) | No longer a standalone conformance requirement, but valid markup and correct ARIA still affect assistive technology. Auditors commonly still test it under other criteria, so keep the markup valid. | Magento: validate checkout and theme templates after extension installs. WooCommerce: run markup checks after each plugin or block update. Headless: validate rendered HTML in CI, not only source components. |
| WCAG 2.1 criteria still in force | Text alternatives, captions, color contrast, keyboard operation, meaningful form labels, error identification and status messages still apply to the full purchase path. | Confirm each template against the 2.1 criteria in addition to 2.2. Test cart, checkout, order confirmation, account pages and error states with screen readers, not only product pages. |
| Verification of each template | Evidence that the storefront, checkout and account pages were tested, with defects tracked and retested. Extensions and third-party payment widgets count as part of the page. | Ask the partner for a page inventory, the test method (automated plus manual with assistive technology), and a retest log. Confirm which payment and fraud widgets the partner can change and which the provider must fix. |
How remediation differs on Magento, WooCommerce and headless storefronts
On Magento Open Source 2.4.9, most storefront accessibility defects sit in the theme layer (Luma-based or custom themes), in layout XML, and in third-party extensions that inject markup into product pages, cart and checkout. The core is licensed under OSL-3.0, so you can modify it, but changes to core files make later patches harder to apply, which is why remediation should prefer theme overrides and extension replacements. Adobe documents Content Security Policy support from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages, so inline scripts added during remediation can be blocked and break checkout controls.
- Theme and template fixes: Override templates and styles in the theme rather than editing core, then test focus order, labels, contrast and error messages on each template you touch.
- Extension audit: Inventory every module that renders storefront HTML, and record which ones need a fix, a replacement or a vendor statement.
- CSP and scripts: Check that accessibility widgets and consent tools comply with restrict mode before release, since blocked scripts can disable form controls.
- Upgrade exposure: Pin the 2.4.9 patch level, confirm that PHP 8.5, OpenSearch 3 and the other listed components are supported together, and re-run accessibility tests after each patch.
- Cache layer: Varnish is the full-page cache for self-managed installs, so verify that cached pages still carry correct states such as cart counts and error messages.
Before release, confirm with your implementation partner which extensions are in scope and who owns the fix for each one.
WooCommerce 11.2.1 runs inside WordPress, so storefront remediation touches the active theme, block templates, the plugins that add checkout fields, and the WordPress core layer. WooCommerce is licensed under GPL version 2 or later, which allows you to change and redistribute it, but the practical risk is in customizations that override WooCommerce templates. When WooCommerce updates a template, an override that was fixed by hand may drift and reintroduce defects, so template overrides need a version check on every release.
- Template overrides: Track each file copied into the theme's woocommerce folder, and compare it with the upstream template after each WooCommerce update.
- Checkout and account pages: Test the classic and block checkout, field labels, inline validation and the account login flow, including accessible authentication and error recovery.
- REST API consumers: The wc/v3 REST API is used by many integrations, so changes to front-end markup should not touch endpoints that a mobile app or kiosk depends on, and the API keys should be scoped to what each consumer needs.
- Plugin inventory: Extensions that add banners, sliders or pop-ups are frequent sources of focus traps and contrast failures, so review them before adding them to the remediation scope.
- Hosting baseline: Confirm PHP 8.3 or greater, MySQL 8.0 or MariaDB 10.6 or later, and WordPress 6.9 or later, because legacy environments fall outside the supported baseline.
Ask the partner to list every template override and plugin with its version, and to state which WordPress releases were tested against the final fixes.
On a headless build, the commerce engine (Saleor 3.23.42 or Medusa v2.21.2) serves data through APIs, and the storefront is a separate application that you build and own. This moves accessibility responsibility almost entirely into the front-end code, design system and component library. Saleor is BSD-3-Clause licensed and extends through webhooks and apps rather than in-process plugins, and Medusa is MIT licensed except for materials covered by its Enterprise Edition license, so the backend changes less often than a plugin-heavy monolith. Remediation therefore focuses on components, routing, and how checkout steps are rendered and announced.
- Component library: Fix shared buttons, form fields, modals and cart drawers once, then test them in every page that uses them.
- Checkout flow: Confirm that step changes, payment errors and address validation are announced to assistive technology, and that the payment provider's embedded fields are tested with keyboard and screen readers.
- Client-side routing: Manage focus and page titles on route changes, since single-page navigation often leaves focus at the top of the document.
- API contract checks: Validate that error payloads from Saleor or Medusa contain the messages the front end needs to render accessible error text.
- Upgrade path: Saleor deploys through Docker Compose or Saleor Cloud, and Medusa is versioned separately, so test storefront components against each commerce release before rollout.
Ask for the accessibility test report per component, the test environments used, and who maintains the storefront after handover.
Which open-source commerce platforms fit an accessibility remediation program
The Accessibility Act applies to the storefront and checkout whichever platform you run, so the platform choice shapes where the remediation work lands. The cards below show who owns the theme, the extensions and the front end on each option, and where accessibility effort concentrates. No platform is accessible out of the box, so every option needs its own audit against WCAG.
Magento Open Source
Licensed under OSL-3.0, with 2.4.9 as the latest stable tag. Storefront remediation sits in the theme layer, checkout templates and any third-party extensions, all of which your team or partner must own and retest on each upgrade. Check whether your Adobe-supplied and extension components keep accessible markup after patches, and confirm the 2.4.9 support window with Adobe before you plan a multi-year program.
WooCommerce
Licensed under GPL-2.0 or later, built on WordPress themes and plugins. Accessibility depends heavily on the active theme and on each extension, because the core checkout is only one part of what shoppers touch. Inventory every plugin that renders on product, cart or checkout pages, and confirm with each vendor whether its markup has been tested against WCAG 2.2.
Saleor
Licensed under BSD-3-Clause and exposed as a GraphQL API with a separate Dashboard. In a headless build, the storefront is custom code, so the accessibility work is your front-end engineering and the components you build, not the commerce core. Confirm which parts of the Dashboard your staff use and whether they need the same review as the public storefront.
Medusa
Licensed under MIT for its core, with materials under its Enterprise Edition license excluded, and built as a headless commerce backend. As with Saleor, the storefront is typically a custom Next.js or similar application, so most WCAG work lands in components, forms and checkout flows you write. Confirm which Medusa storefront starter and modules you adopt, and check their accessibility before you inherit them.
Sylius
Licensed under MIT and built on Symfony, with v2.3.1 as the latest release. Sylius gives you a code-level storefront that your team owns, so accessibility fixes are standard templating and component work, but the quality depends on your own front-end discipline. Ask your partner which Twig templates and UI bundles are in scope and how they will be tested with assistive technology.
PrestaShop
Core is licensed under OSL-3.0 and its modules under AFL-3.0, with 9.2.0 published on September 30, 2026. Theme choice drives most of the remediation scope, and marketplace modules vary widely in accessibility quality. Before buying a theme or module, request its WCAG test results and confirm whether the vendor will fix findings on updates.
How a WCAG remediation of a self-hosted store runs in order
The sequence turns a general accessibility concern into a scoped, tested and documented set of storefront, checkout and account fixes that the store owner can maintain after each platform update. Each step ends with an output the next step depends on.
Scope the audited journeys and templates
The store owner and the implementation partner agree which journeys are in scope: product discovery, cart, checkout, account creation and login, order history, and customer service pages. They list every theme template, custom block, checkout step and installed extension that renders those journeys, including payment widgets that the store does not fully control. The output is a written scope document with a page and component inventory, signed off before testing starts, so that gaps are visible to both parties.
Run automated scans on each journey
The partner runs automated accessibility scanning against the storefront, checkout and account pages in a staging copy that matches production theme, extensions and platform version. Automated tools catch a large class of machine-detectable issues, such as missing form labels, color contrast failures and invalid ARIA use, but they do not cover every WCAG 2.2 success criterion. The output is a defect log tied to URLs, templates and WCAG 2.2 criterion IDs, such as 2.4.11 Focus Not Obscured and 3.3.8 Accessible Authentication.
Complete manual testing with assistive technology
Testers work through each journey using only the keyboard, a screen reader and zoomed layouts, and they check target sizes, focus order, error messages and time-limited steps. Manual results cover what automated scanning misses, especially in checkout and login flows that depend on custom JavaScript. The output is a combined findings register that marks each issue as automated, manual or both, with a reproduction note a developer can follow.
Prioritize fixes by owning code
The team sorts findings by where the fix must land: the theme's templates and stylesheets, custom modules, third-party extensions, or the platform core. Checkout and account defects usually come first because they block purchases and sign-in. Core and extension issues are handled by upgrade or vendor request rather than by editing vendor files, which keeps later patches applicable. The output is a backlog where each item names the owner, the file or extension involved, and the retest step required to close it.
Implement and retest fixes in staging
Developers apply fixes in version-controlled theme and custom code, then the tester repeats the affected journey with the same scanner and assistive technology setup used in the baseline. Each fix is closed only when the retest passes for that criterion and no new defect appears in the same template. The output is a retest report that compares the baseline and current defect counts and lists any issue that depends on a third-party vendor response.
Retest checkout after every platform patch
Each time the store applies a security or minor platform patch, or updates the theme or an extension, the checkout and account journeys are retested before production release. Platform releases can change markup and scripts that the accessibility fixes depend on, so a patch can reopen a closed defect. The partner confirms the supported platform, PHP and database versions from the vendor's current requirements before the patch is applied. The output is a dated regression checklist signed off for each release.
Document the statement and evidence
The team publishes an accessibility statement that describes the scope, the conformance status against WCAG 2.2, known exceptions and a contact route for reporting barriers. It also files the evidence pack: scope document, scan and manual test results, fix records and retest reports. The evidence supports the store's own compliance file. DeployOpen prepares this material, but independent auditors or certification bodies make any formal conformance determination, and the store owner should confirm with counsel what the statement must contain for each EU market.
What auditors and market surveillance ask to see as accessibility evidence
This table maps the evidence items an assessor or market surveillance authority is likely to request for an online shop to the component that produces each item. Read it as a preparation checklist: DeployOpen assembles and documents this evidence, while the independent assessor or authority decides whether the shop conforms.
| Evidence item | Component that produces it | What the reader should confirm |
|---|---|---|
| Accessibility statement and conformance claim | Storefront and checkout documentation, owned by the shop operator | Which WCAG version and level is claimed, and which pages or flows are in scope |
| Theme and template code with accessible markup | Storefront theme, checkout templates and custom components | Version-controlled source showing semantic markup, labels and focus handling |
| Automated and manual test reports | Test runs against staging and production-like builds | Reports cover key journeys: search, product page, cart, checkout and account login |
| Keyboard and assistive technology test records | Manual testing by the implementation team or an independent tester | Who tested, which browsers and screen readers were used, and what defects were fixed |
| Platform and extension version records | Composer lock files, package manifests and deployment records | Every accessibility-relevant extension is listed with its version and upgrade history |
| Content Security Policy configuration | Web server and platform CSP settings, including payment page rules | Policy files and mode settings, confirmed against the platform version in use |
| Change logs and remediation tracking | Issue tracker, release notes and deployment history | Each accessibility defect has an owner, a fix reference and a retest result |
| Consumer complaint and feedback handling | Support process, contact channel and ticket records | Where complaints are received, how they are triaged and how long responses take under internal policy |
What tooling alone does not satisfy under the European Accessibility Act
A scanner, a theme update or a compliant platform version does not make a shop accessible on its own. The cards below cover the gaps that remain after tooling, and each one needs an owner, a check and a record kept by the business.
Automated scanners miss many WCAG issues
Automated checks catch problems such as missing alt attributes or low contrast in code, but they cannot judge whether alt text is meaningful, whether focus order makes sense in checkout, or whether an error message helps a customer recover. Use a scanner as a first filter, then run manual tests with keyboard only navigation and a screen reader across product listing, cart, checkout and account pages against WCAG 2.2 success criteria such as 2.4.11 Focus Not Obscured and 3.3.8 Accessible Authentication.
Extensions and payment widgets sit outside control
Third-party modules, theme add-ons and embedded payment or fraud widgets often inject markup, scripts and focus traps into the storefront. The shop owner remains responsible for the result even though a vendor wrote the component. Before launch, list every extension that renders in the storefront or checkout, request each vendor's accessibility statement or conformance evidence, and test the rendered output rather than the module's documentation.
Platform upgrades can regress fixes
A minor or security upgrade of Magento Open Source, WooCommerce or a headless storefront can change templates, JavaScript or component libraries and silently reintroduce barriers that were fixed. Keep an accessibility regression suite that runs in staging on every upgrade, and record which fixes live in theme overrides so they survive a patch cycle. Confirm with your partner who owns the regression run and who signs off before production.
The 2030 transition does not cover new products
Article 32(1) of Directive (EU) 2019/882 lets service providers keep using products already in use to deliver similar services until 28 June 2030. That allowance does not extend to a storefront, theme, checkout or payment flow built or bought after the Act applied. Any new platform build, redesign or replacement needs to meet the requirements from the start, so record the date each component entered service and treat new work as in scope.
Accessibility statement and feedback process
Shops must be able to show how they assess accessibility, what is still open and how customers report barriers. A statement is an organizational document, not a plugin setting. Assign an owner, name the conformance target, publish a contact path and log every report with a date, a page and a fix or workaround. Ask your partner to draft the statement from the test evidence, and have legal review it before publication.
How much effort, time and internal work does an accessible storefront need?
What drives the cost of making an online store accessible?
The biggest driver is who owns the storefront theme and checkout code, because that code is where most WCAG-based fixes land. Cost rises with the number of third-party extensions or modules that render visible pages, with custom checkout flows, and with the number of storefront templates, languages and product page variants that need testing. Costs fall when the theme is maintained in one codebase, when extensions are few and well documented, and when the checkout is a standard flow. Ask any quote to split the work into theme remediation, extension review, checkout testing, accessibility statement and evidence, and ongoing regression checks, so you can see which parts recur.
Can our internal team fix storefront accessibility without a partner?
Often yes for the parts that are routine, such as colour contrast, alt text, labels and focus styles, but the work usually needs developers who know the platform's theme layer and an tester who can run assistive technology checks. Your team should own content quality, product data and the accessibility statement, since those change daily. Consider a partner when the theme is custom, when extensions block keyboard use, or when checkout needs rework. Ask a prospective partner which of these tasks they would hand back to your staff and what knowledge transfer is included in the written scope.
What does the work need from our internal staff?
Plan for named people in four roles: a product owner who can accept or defer fixes, a developer who knows the theme and deployment pipeline, a content or merchandising lead who controls product pages and images, and someone responsible for compliance evidence. Access is needed to a staging copy of the store, test accounts for every customer journey, a list of installed extensions with their vendors, and the current accessibility findings if any exist. Without staging access and test data, the work will stall at review. Confirm these inputs in the scope before the timeline is agreed.
How long does storefront remediation take?
Duration depends on scope rather than on a fixed rule. The main variables are the number of page templates, the number of extensions that change the interface, whether the checkout is standard or custom, and how many languages the store publishes. Discovery, remediation, retesting and documentation are separate phases, and retesting usually takes longer than teams expect because each fix can expose another issue. Ask for a phase plan with milestones and acceptance criteria. Treat any single number without a stated scope as a sales estimate, and check it against the list of templates and extensions in the written proposal.
Does the microenterprise exemption remove the need for this work?
It may, but only for some providers and only for the service requirements. Directive (EU) 2019/882 exempts microenterprises providing services from its service requirements under Article 4(5), so the test is whether your business qualifies as a microenterprise under the directive's definition and how your national rules apply it. Confirm that status with your legal adviser before you rely on it. Even where the exemption applies, customers still expect a usable store, and the same WCAG-based fixes often cost less than the risk of losing buyers or facing a complaint.
How do platform upgrades affect accessibility fixes?
Upgrades can overwrite theme files, change markup or add scripts, so accessibility fixes need to be tracked as code changes, not as manual edits in the admin. Keep fixes in a child theme or a custom module, store them in version control and add automated and manual regression checks to the release pipeline. For Magento Open Source, Adobe publishes a lifecycle policy with end-of-support dates for each 2.4.x release, so plan upgrades against those dates. For WooCommerce, confirm which WordPress and PHP versions the theme and extensions support before each upgrade. Ask the partner how fixes survive a platform patch.
What should we request in a fixed-scope quote for accessibility work?
Ask for a written scope that lists the storefront templates, the extensions in scope, the checkout flow, the target WCAG version and level, the browsers and assistive technologies used for testing, and the retesting rounds included. Request the deliverables in plain terms: a remediation log, a list of open issues with reasons, updated theme code, an accessibility statement draft and evidence of testing. Confirm what is excluded, such as content rewriting, third-party vendor fixes and future releases. Also ask for the support terms after handover, because ongoing testing is typically a separate retainer. DeployOpen does not publish a price list, so compare quotes against this written scope.
What to ask an implementation partner before signing a scope
Start with the testing method, because it decides what the scope actually covers. Ask whether the partner tests the storefront, product pages, cart, checkout, account pages and the order confirmation flow against WCAG 2.2 at Level AA, and whether they combine automated scans with manual testing using keyboard-only navigation and at least one screen reader. Ask which success criteria they check beyond the nine added in WCAG 2.2, such as 2.4.11 Focus Not Obscured (Minimum), 2.5.8 Target Size (Minimum) and 3.3.8 Accessible Authentication (Minimum), since sticky cookie banners, mini-cart drawers and login walls are where storefronts usually fail them. Confirm in writing which browsers, assistive technologies and devices are in the test matrix and who signs off each finding as closed.
Next, pin down ownership of remediation. A theme defect in a Magento Open Source or WooCommerce theme can sit in the vendor theme, a third-party extension, a child theme or custom templates, and the fix path differs for each. Ask who edits which layer, how extension patches are kept upgradable, and whether the partner will record each change against the scope so that a later vendor update does not silently reintroduce a defect. For headless builds on Saleor or Medusa, ask who owns the storefront components, the design tokens and the checkout UI. Ask whether the partner will fix or only report issues in the payment provider's hosted fields, because those usually sit outside your control.
Then ask how checkout and payment pages are retested after a platform patch. Magento 2.4.x patch releases and WooCommerce releases can change markup, scripts and the Content Security Policy behavior, so a checkout that passed in one release may fail in the next. Ask for a regression checklist covering the full purchase path, the retest trigger (every security patch, every minor release, or each change to the theme), and who pays for retesting if an upstream update breaks a control. Request the evidence format as well: dated test records, the environment and version tested, the defects found and their closure, and the retained artifacts. DeployOpen prepares that evidence for compliance assessments but does not issue audit reports or certifications, so ask how the partner separates its test results from any independent review you may need. Finally, ask about the support retainer: response times in writing, who monitors release notes, and whether accessibility retesting is included or billed per cycle.
How DeployOpen scopes, remediates and supports an accessible storefront
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source commerce inside your own cloud accounts, data centers or air-gapped networks. For European Accessibility Act work, we start from a written scope that names the storefront, checkout and account pages in play, then remediate and document them against the accessibility requirements that apply to your organization.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We confirm which storefront templates, checkout steps, account pages and third-party widgets fall within the written scope.
- We confirm whether your business relies on the microenterprise exemption or the transition provisions before sizing any remediation.
How we build
- We test storefront and checkout pages against WCAG 2.2 Level AA criteria and record each finding with its success criterion.
- We remediate theme, template and checkout code on your chosen platform, including Magento, WooCommerce or a headless storefront.
- We retest fixed pages and keep extension and theme changes upgradable so accessibility fixes survive platform updates.
How we hand over
- You receive the test results, remediation log and a list of known gaps with owners and suggested next steps.
- Documentation covers the configuration, theme changes and accessibility statement inputs your team needs to maintain the store.
- We prepare evidence for your own assessment, while independent auditors and certification bodies make any formal determination.
How we support
- Ongoing support, platform upgrades and continuous testing are available as retainers after handover.
- Retainers can cover re-testing after platform, theme or extension upgrades, including new WCAG-based checks.
- Ask any partner to confirm response times, security patch ownership and who fixes regressions in writing.
