The European Accessibility Act has been in force since June 2025. It applies to businesses selling online to EU consumers regardless of where the business is, which includes UK companies. Enforcement has started. Most of the teams it applies to have not heard of it.
A directive harmonising accessibility requirements across all twenty-seven member states, covering e-commerce, banking, transport and a range of digital services. All member states have transposed it into national law, and the compliance date was 28 June 2025.
The technical standard is EN 301 549, which for web interfaces means WCAG 2.1 Level AA. That is a specific, testable standard rather than a statement of intent, which is the useful part: you can measure where you are against it today.
The trigger is selling to EU consumers, not being established in the EU. A UK company shipping to Ireland, Germany or anywhere else in the single market is in scope.
There are two carve-outs worth knowing:
Penalties are set nationally and run up to around one hundred thousand euros, or a percentage of annual revenue, depending on the member state. The first cases were filed in France in November 2025, and enforcement activity has been expanding across other member states through 2026.
The pattern will be familiar to anyone who has read the piece on merchant ID withdrawals. A rule existed, enforcement was light, businesses operated without challenge, and then enforcement arrived without the rule having changed. The response is the same in both cases: find out where you actually stand before someone tells you.
Most accessibility failures in e-commerce are not exotic. They cluster in a small number of places, and they are almost all fixable.
Checkout is where it matters most and fails most. Custom-built form controls, date pickers and card fields are the usual offenders, because they replace native elements that were accessible by default with divs that are not. Error messages that appear visually but are never announced are the single most common blocker to completing a purchase.
Keyboard operability is the fastest test you can run. Put the mouse down and try to complete a purchase. If you cannot reach a control, cannot see where focus is, or get trapped inside a modal, neither can a substantial number of your customers.
Anything that appears without a page load needs announcing. Added to basket, validation errors, filter results, live totals. If the change is only visual, it did not happen for anyone using a screen reader.
Contrast and text sizing are cheap wins and they are what an automated scan will flag first, which also makes them what a complainant will point at first.
Third-party components are still your responsibility. A cookie banner, a review widget, a chat launcher or a payment iframe that traps focus fails the whole journey. Your obligation does not stop at code you wrote.
The instinct is to buy an overlay: a script that promises to fix accessibility at runtime. They are heavily marketed and they are largely not a defence. They do not remediate the underlying markup, they are widely disliked by the people they claim to serve, and in several jurisdictions their presence has featured in complaints rather than deflecting them.
The work is in the markup and the interaction design. There is no script that substitutes for it.
That last step is the one that separates a remediation project from a standard. Everything else on this site argues the same thing: if it is not enforced by machinery, it is not a convention, and it will not survive contact with a deadline.
We audit e-commerce journeys against WCAG 2.1 AA and remediate, with regression tests so it stays fixed. If you sell into the EU and have not looked at this, an audit will tell you in days whether you have a problem.