The European Accessibility Act (EAA) has been in force since 28 June 2025 across all EU member states. In Sweden it is implemented through the Act (2023:254) on the accessibility of certain products and services. For ecommerce businesses, this means your website, checkout, and customer service channels must meet accessibility requirements defined by WCAG 2.2 AA and the European standard EN 301 549. The requirements apply to all businesses selling products or services to consumers online — with an exemption only for microenterprises (fewer than 10 employees and under €2 million annual turnover).
Most guidance about the directive explains what it is. This guide focuses on what it means for your ecommerce delivery: which parts of your site need attention, how platform choice affects compliance, and how to build accessibility into your development workflow rather than treating it as a one-time audit.
What the directive requires from ecommerce
The law requires that ecommerce services are perceivable, operable, understandable, and robust — the four WCAG principles. In practical terms for an ecommerce site: all images need meaningful alt text, videos need captions, the entire site must be navigable by keyboard alone, forms and checkout must work with screen readers, colour contrast must meet minimum ratios, and error messages must be clear and programmatically associated with the fields they relate to.
The requirements extend beyond the storefront. Customer service channels must also be accessible — if you offer live chat it must work with assistive technology. PDF documents such as order confirmations and invoices should be accessible. Emails triggered by the site should follow basic accessibility practice.
Third-party components on your site are your responsibility. If your payment provider’s checkout widget, your cookie consent banner, or your review system is not accessible, that is a compliance gap on your site.
How platform choice affects compliance
Your ecommerce platform provides the foundation, but accessibility depends on how the site is built on top of it.
Shopify themes have improved significantly in accessibility, and Shopify’s native checkout is generally well-tested for WCAG compliance. The risk areas are third-party apps and custom theme changes — each needs accessibility testing.
Shopware offers a flexible frontend where accessibility largely depends on the theme implementation. Shopware’s standard Storefront theme covers basic accessibility, but custom themes require explicit accessibility work during the build phase.
Norce with a headless frontend (via Frntkey or a custom build) gives full control over HTML output, meaning the development team owns accessibility entirely. That is both an opportunity and a responsibility — there is no platform default to fall back on, but equally no platform constraint to work around.
Magento / Hyvä in its Hyvä frontend variant produces clean, lightweight HTML that provides a good starting point for accessible markup. Luma-based Magento themes often have more accessibility issues due to complex JavaScript-driven UI components.
Regardless of platform, the common risk areas are the same: custom navigation menus, product filters, modal windows, image carousels, and checkout flows. These interactive components need explicit ARIA attributes, keyboard handling, and focus management.
Checkout and payment accessibility
The checkout is where accessibility failures have the highest business impact — a customer who cannot complete a purchase because of an inaccessible form has failed at the worst possible moment.
Key requirements: every form field needs a visible label and a programmatic association (not just placeholder text), error messages must identify the problem and appear near the relevant field, the entire checkout must be completable by keyboard, and payment method selection must work with screen readers. If you use payment providers like Klarna or Adyen, their embedded checkout widgets should be evaluated for accessibility as part of your compliance work.
Content and product data
Product pages have specific requirements. Every product image needs descriptive alt text — not just the product name, but enough detail for someone who cannot see the image to understand what is shown. Product videos need captions. Specification tables need correct header markup. Size guides and comparison tools must be keyboard-navigable.
If you use a PIM system, accessibility metadata (alt text, caption fields) should be part of the product data model from the start. Retrofitting alt text across hundreds or thousands of products later is significantly more expensive than including it in the enrichment workflow from day one.
Testing and ongoing compliance
Accessibility is an ongoing requirement. Every new feature, every theme update, and every new third-party integration can introduce accessibility issues. The sustainable approach is to build accessibility testing into the development workflow: automated scanning tools (like axe or Lighthouse) catch structural issues, but manual testing with keyboard navigation and a screen reader is necessary to catch interaction and context problems that automated tools miss.
PTS (Post- och telestyrelsen) is the supervisory authority in Sweden and can investigate complaints about inaccessible ecommerce services. Sanctions are possible if non-compliance is not addressed after notice. Products and services already on the market before June 2025 have until 2030; anything launched or substantially updated after that date must comply immediately.
Build accessibility into delivery
The most cost-effective approach is to include accessibility requirements in the project from the start — in the design phase (contrast, typography, interaction patterns), in the build phase (semantic HTML, ARIA, keyboard handling), in QA (accessibility test cases alongside functional tests), and in content workflows (alt text, heading structure, plain language). Retrofitting accessibility after launch typically costs several times more than building it in, and the results are rarely as good.
For ecommerce projects already live, the practical starting point is an accessibility audit of the most critical user paths: homepage, category pages, product pages, search, cart, and checkout. Fix the issues with the greatest impact first — those that block users from completing core tasks — and build from there.
