E-commerce and the EAA
Your checkout, tested the way a screen-reader user shops.
Suretto tests every step a shopper takes, from search to returns, with NVDA, JAWS, VoiceOver and a keyboard alone. Defects are fixed in your storefront code, and each fix is verified by a system that did not write it.
The EAA applies to EU shoppers, wherever you are based.
The European Accessibility Act (Directive 2019/882) has applied since 28 June 2025. It covers e-commerce sold to EU consumers, and it covers the whole customer journey on websites and apps. Where the company is based does not matter: a store in the US, the UK or India that sells to shoppers in the EU is in scope.
Service providers with fewer than 10 employees and €2 million or less in turnover are exempt. Service contracts agreed before 28 June 2025 may run unchanged until they expire, for at most five years, so until 28 June 2030. New contracts must comply now.
The technical standard is EN 301 549, which incorporates WCAG 2.1 AA, with an update aligning to WCAG 2.2 under way. We test against WCAG 2.2 AA, which covers both.
Enforcement is national. Germany's market-surveillance body has been operating since September 2025, with correction orders first and fines up to €100,000. French courts issued the first compliance orders in 2026, including one that gave a major retailer six months to make its site and app accessible.
This is a summary, not legal advice. Dates and sources are on the compliance page.
- 28 Jun 2025
- The Act applies to e-commerce sold to EU consumers
- New contracts
- Must comply from the day they are agreed
- 28 Jun 2030
- The final transition period ends
- €100,000
- Maximum fine in Germany, after correction orders
Six journeys, every state.
A scanner sees the page that loads. A shopper opens drawers, picks a size, mistypes a postcode and comes back to return a parcel. We test each journey in the states a shopper reaches, with automated rules, recorded NVDA, JAWS and VoiceOver runs, and a keyboard-only run. Contrast is calculated from browser-derived colours. Third-party checkout components may require provider changes rather than source-code fixes.
| Journey | States we exercise | What is checked | WCAG criteria |
|---|---|---|---|
| Search | Search field, autocomplete suggestions, results page, filters and sort, the no-results message | The field has a label that matches its visible text. Suggestions are announced and can be chosen by keyboard. The result count is announced when a filter changes, without moving focus. Filters work by keyboard and keep the shopper’s place. | 1.3.1, 2.1.1, 2.4.3, 2.5.3, 4.1.2, 4.1.3 |
| Product page | Image gallery and zoom, variant pickers for size and colour, price and stock, add to cart, reviews | Product images have alt text that describes them. Swatches announce their name and selected state, and stock is never shown by colour alone. Carousels can be paused and operated by keyboard. Adding to cart is confirmed to screen-reader users. Text and controls meet contrast; targets meet the minimum size. | 1.1.1, 1.4.1, 1.4.3, 1.4.11, 2.2.2, 2.5.8, 4.1.2, 4.1.3 |
| Cart | Mini-cart drawer, quantity changes, removing an item, discount codes, totals | Focus moves into the drawer when it opens and returns when it closes. Escape closes it, and focus is never trapped. Quantity steppers have names. Changes to quantity and totals are announced. A rejected discount code is identified in text. | 2.1.1, 2.1.2, 2.4.3, 3.3.1, 4.1.2, 4.1.3 |
| Checkout | Guest and signed-in paths, address forms and lookup, shipping options, payment fields, express-pay buttons, validation errors, order review, confirmation | Every field has a programmatic label and the right autocomplete value. Errors are identified in text, tied to their field and paired with a suggestion. The shopper can review and correct the order before paying. Details already given are not asked for again. Embedded payment fields and express-pay buttons have accessible names. Time limits can be extended. Focus is placed on each new step. | 1.3.1, 1.3.5, 2.2.1, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.7, 4.1.2 |
| Account | Sign-in, registration, password reset, order history, saved addresses | Sign-in does not depend on a memory or puzzle test, and password managers and paste both work. Password rules and errors are given in text. Order-history tables have header cells. Help is in the same place on every page. | 1.3.1, 3.2.6, 3.3.1, 3.3.8, 4.1.2 |
| Returns | Order lookup, choosing items, reason picker, photo upload, return label, confirmation | Item checkboxes and reason pickers are labelled and work by keyboard. Date pickers work by keyboard. The upload control has a name and announces its result. The confirmation and the return label can be reached and are announced. | 1.3.1, 2.1.1, 3.3.2, 4.1.2, 4.1.3 |
We test on a staging copy with test accounts, so no recording contains a real customer's data. Payment steps are tested through to payment where your staging environment has a test payment mode, and up to it where it does not.
Platform notes.
The standard is the same on every platform. Where the fix goes, and who can make it, is not. Suretto holds no certification or partner status with any of these platforms; these notes describe how the work fits each one.
Shopify themes and apps
Theme code lives in Liquid templates, sections and snippets. Connect the theme to a GitHub repository and fixes arrive there as pull requests.
Installed apps add their own markup and scripts, such as review widgets and upsell pop-ups. We test them as part of the page. When a defect sits in an app's code, the report names the app, because the fix belongs to its developer or to a replacement. Shopify's checkout runs on Shopify's code and can be customised only within the platform's limits; we test and report on it the same way.
WooCommerce
A WooCommerce store is a WordPress theme plus WooCommerce templates and plugins. We put fixes in a child theme or in template overrides, so a theme or plugin update does not overwrite them.
Cart and checkout can be built from blocks or from the older shortcode templates. They produce different markup, so we test the one you run. Defects inside a plugin are reported against that plugin.
Magento
Magento Open Source and Adobe Commerce storefronts are built from layout XML, PHP templates and JavaScript components. Fixes go into your theme or a custom module, not into core files, so an upgrade does not undo them.
The default checkout is rendered in the browser by JavaScript components. We test its changing states, such as a new shipping method or a payment error, with screen readers as they happen, not only on first load.
Headless storefronts
Front ends built with React, Next.js, Vue or a similar framework on a commerce API. Fixes go into your components, often once in the design system and then everywhere that component is used.
Client-side navigation needs checks a full page load does not: the page title changes, focus moves to the new content, and the change is announced. We test these on every route.
Selling into the US: lawsuit exposure.
Courts treat the websites and apps of businesses open to the public as covered by ADA Title III, and usually take WCAG 2.1 AA as the benchmark. Enforcement is by private lawsuit, and plaintiffs' firms test sites with screen readers before they file.
A fix that does not hold is the common failure. Nearly half of federal cases in 2025 named a company that had been sued before. That is why we re-verify after every release, not only at the audit.
Source: Seyfarth Shaw, 2025 lawsuit filings. More on the compliance page.
- 3,117
- Web accessibility lawsuits filed in US federal court in 2025
- +27%
- Rise in federal filings on 2024
- 5,000+
- Filings in 2025 including state courts
See the report before you apply.
The sample report covers a demo store we built and filled with known defects. It shows every criterion, the method used, the result, and the recording or data behind it. Every product, person and result in it is fictional.
Pilot programme
Bring one store.
We are working with a small group of e-commerce brands through early 2027. Start with a scoped assessment and repairs for one agreed shopping journey at no cost. We get your feedback on the report, the fixes and the workflow.
To ask a question first, write to hello@suretto.com.