For years, digital accessibility was easy for e-commerce teams to treat as something to improve later. It mattered, but it competed with conversion work, new features, platform migrations and everything else on the roadmap.
That position has changed.
Since 28 June 2025, the European Accessibility Act has applied to covered products and services, including e-commerce services provided to consumers in the European Union. E-commerce is specifically defined to include services provided at a distance through websites and mobile services with a view to concluding a consumer contract.
We are also beginning to see what enforcement looks like in practice.
In June 2026, the Tribunal judiciaire de Caen ordered Carrefour France to bring its e-commerce website and mobile application into conformity with French accessibility requirements. The court imposed a €500-per-day coercive payment beginning six months after the order and awarded €10,000 in provisional damages to the claimant associations. The court did not order the website or app to be suspended.
Carrefour was not the first of these cases to reach court. In May 2026, the Tribunal judiciaire de Lille declined to order Auchan E-commerce France to remediate its website and app. However, the court still recorded substantial accessibility problems, including strong-to-major accessibility impacts across 13 of the 19 categories considered. The decision turned on the court’s interpretation of the interaction between France’s existing accessibility rules and newer e-commerce requirements, and the claimant associations have challenged that interpretation on appeal.
That distinction matters. Accessibility enforcement is no longer only a theoretical future risk, but neither should businesses reduce the European Accessibility Act to headlines about fines. The more useful question is simpler: can people actually use the digital service you provide?
Why UK e-commerce businesses should pay attention
The European Accessibility Act is EU legislation, but being established outside the EU does not automatically put a business outside its reach.
The Directive defines a service provider as someone who provides a service on the Union market or makes offers to provide such a service to consumers in the Union. E-commerce services are explicitly covered. For a UK retailer actively selling to EU consumers, that means the EAA may be relevant even without an EU headquarters.
However, scope is more nuanced than saying that any website visible from Europe must comply.
The Directive exempts microenterprises providing services from its accessibility requirements. Under the EAA definition, a microenterprise employs fewer than ten people and has annual turnover not exceeding €2 million or an annual balance-sheet total not exceeding €2 million. There are also provisions covering fundamental alteration and disproportionate burden, although relying on those provisions can require an assessment and supporting documentation.
There are transitional measures too. Service contracts agreed before 28 June 2025 may continue without alteration until they expire, but for no longer than five years from that date. The Directive also provides a transition ending on 28 June 2030 for certain products already being lawfully used to provide services. That is not the same as giving every pre-2025 website a blanket exemption until 2030.
A note on scope
This article focuses on the technical and practical side of digital accessibility. The European Accessibility Act contains exemptions, transitional provisions and requirements that can vary depending on the organisation, service and jurisdiction. Businesses should seek appropriate professional guidance when determining their specific obligations.
What the technical standard actually means
This is where the terminology can become confusing.
The European standard most commonly associated with digital accessibility is EN 301 549. It covers accessibility requirements for ICT products and services and draws heavily on the Web Content Accessibility Guidelines, or WCAG.
There has also been an important recent change.
In September 2026, EN 301 549 v4.1.1 was published. The new version adopts WCAG 2.2 as its accessibility benchmark and adds the newer WCAG 2.2 requirements. However, the updated standard has not yet been formally cited in the Official Journal of the European Union. Until that happens, the currently referenced version remains EN 301 549 v3.2.1, which is based on WCAG 2.1 Level AA.
At Lemon Hive, we target WCAG 2.2 AA in our accessibility engineering. That is a technical benchmark rather than a claim that passing WCAG 2.2 alone determines whether a business has met every obligation under the EAA.
WCAG is organised around four principles: content should be perceivable, operable, understandable and robust.
In practical terms, somebody should be able to understand and operate your interface without depending on a particular way of seeing, hearing or interacting with it. The underlying structure also needs to work with browsers, assistive technologies and different ways of navigating the web.
That sounds broad because it is. Accessibility is not one score or one attribute added to a website at the end of a build.
Where e-commerce sites commonly go wrong
Through accessibility testing and ongoing monitoring, we see certain technical problems recur across websites. None of these alone represents the entirety of WCAG or the EAA, but they are useful places to start looking.
Controls without useful accessible names are particularly easy to miss visually. An icon-only control may make perfect sense to someone looking at it while providing little or no useful information to a screen-reader user. Buttons for opening menus, changing quantities, removing products or moving through a checkout need a programmatically determinable purpose.
The same problem appears when visual design and semantic meaning drift apart. Something can look like a button without being implemented as one, or appear to have a label that assistive technology cannot actually associate with the control.
Colour contrast is another common failure. WCAG Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, with separate requirements covering visual information needed to identify active user-interface components and states. There are specific exceptions, including inactive controls, so contrast testing needs more precision than simply running every colour pair through a checker.
Forms can fail even when they look perfectly clear. A red outline or validation message may tell a sighted user what happened while providing inadequate information to someone using assistive technology. Labels, instructions and errors need to be programmatically connected to the fields they describe, and changes in the interface need to be communicated appropriately.
That becomes especially important in checkout. An inaccessible address form, payment step or account-creation process can prevent somebody from completing the purpose of the service entirely.
Keyboard accessibility and focus management are another frequent source of problems. Functionality should not depend on somebody being able to use a mouse or touchscreen. Menus, dialogs, filters, cookie controls and custom interface components all need sensible keyboard behaviour, while keyboard focus needs to remain visible and predictable.
A modal that opens but does not manage focus correctly can leave a user navigating content behind it. A component that responds to a click but cannot be operated from a keyboard creates a different version of the same problem: the interface works, but only for one method of interaction.
Finally, visual structure is not the same as semantic structure.
A heading may look large and bold without being marked up as a heading. A group of items may look like a list without using list semantics. Page regions may be obvious visually while being difficult to identify programmatically.
Sighted users can compensate for weak structure by scanning a page. Assistive technologies rely far more heavily on the structure provided in the underlying code.
Good accessibility engineering therefore starts below the visual layer.
Enforcement is becoming more visible
Carrefour is not the only indication that accessibility scrutiny is becoming more practical.
In March 2026, the Netherlands Authority for Consumers and Markets, the ACM, published the results of testing approximately 100 major Dutch online stores alongside major telecom and energy providers. It reported that 61% of the largest online stores tested were not digitally accessible, with 33% showing serious problems. The regulator said it would approach companies with the worst results and that businesses failing to make sufficient improvements could face enforcement action.
That also illustrates why transaction journeys deserve particular attention.
The ACM found cases where consumers using assistive technology could not place an order because of issues such as inaccessible controls or CAPTCHA mechanisms. Accessibility therefore cannot be judged by checking a homepage and assuming the rest of the experience behaves the same way.
Enforcement also differs across Europe. The EAA requires Member States to establish penalties under their national laws rather than setting one EU-wide fine. Those penalties must be effective, proportionate and dissuasive, and the Directive also requires effective remedial action where businesses do not comply.
For that reason, broad claims such as “the EAA fine is €X” are rarely useful. The relevant authority, process and potential consequences depend on the jurisdiction and circumstances involved.
Accessibility is more than passing an automated test
Automated testing is valuable because it can inspect large numbers of pages quickly and consistently.
It is particularly useful for identifying repeatable technical problems such as missing accessible names, certain contrast failures, invalid attributes and structural issues. On a large e-commerce estate, automation can expose patterns that would otherwise take a long time to find manually.
But an automated result is not a certification of accessibility.
A tool cannot reliably determine whether an entire customer journey makes sense to someone using a screen reader, whether keyboard focus behaves logically across a complex checkout, whether alternative text communicates the right meaning, or whether an interaction is understandable in context.
The practical approach is therefore to combine automation with manual testing.
Start with the high-value journeys: finding a product, choosing a variant, adding it to the basket, opening the basket, entering customer information, dealing with validation errors and progressing through checkout.
Use a keyboard. Test with representative assistive technologies. Look beyond whether an element technically exists and ask whether somebody can actually complete the task.
Then use automated monitoring to help catch repeatable issues and regressions as the site changes.
Accessibility does not end at launch
A site can pass an audit and develop problems again surprisingly quickly.
A new component can introduce a keyboard issue. A redesign can reduce contrast. A third-party integration can change its markup. A marketing team can publish an image without appropriate alternative text. A checkout provider can release an update.
That is why we treat accessibility as an ongoing engineering concern rather than a one-off remediation exercise.
The EAA itself reflects this idea. Service providers are required to have processes in place so that services continue to conform as the service, applicable requirements and relevant standards change. It also requires providers to prepare information explaining how their service meets applicable accessibility requirements.
Monitoring does not replace manual accessibility testing, but it can give teams visibility between deeper audits.
That matters particularly for e-commerce sites, where templates and reusable components can spread a single problem across hundreds or thousands of URLs.
What we would do first
If you are unsure where your site stands, begin by establishing a baseline rather than trying to fix individual issues from guesswork.
Run automated testing across a representative sample of the site and use it to identify recurring patterns. Then manually test the journeys that matter most to customers, particularly navigation, product discovery, forms, account flows and checkout.
Prioritisation should consider the severity of the accessibility barrier, how many users or pages it affects and whether it blocks somebody from completing an important task. Fixing the underlying component is usually more effective than repairing the same issue page by page.
Then keep measuring.
Accessibility requirements are not something a development team can permanently finish while the website continues to change around them.
Where Lemon Hive stands
We target WCAG 2.2 AA throughout our design and engineering process because it provides a strong current benchmark and reflects the direction of the updated EN 301 549 standard.
We also monitor accessibility alongside performance and digital sustainability with our own tool SiteBeacon because all three benefit from the same engineering discipline: understanding how a site behaves in the real world rather than judging it only by how it looks in a design file.
Our monitoring tools can help identify technical accessibility issues across a site, but we do not treat an automated score as proof of accessibility or as a determination of a business's legal position.
The objective is more practical than that.
Find the barriers. Understand which ones affect real journeys. Fix them at the right level of the system. Then make sure they do not quietly return six months later.
If you would like to understand what is happening across your own site, we can audit it and show you what we find.