The European Accessibility Act and your website: what it actually requires

The European Accessibility Act has applied since 28 June 2025. Most of the coverage it generated was written before that date and framed accessibility as a deadline, which is the least useful way to think about it — the deadline has passed, and what remains is a standing obligation with a technical definition attached.

This is what the Act covers, which standard actually sets the bar, and where the work lands in a build and a test plan.

What the Act actually covers

The Act is Directive (EU) 2019/882. Member States had to write it into national law by June 2022, and its requirements have applied since 28 June 2025. It does not cover the entire web — it names a specific list of products and services, including computers and operating systems, smartphones, ATMs and ticketing machines, television equipment, telephony and audio-visual media services, air, bus, rail and waterborne passenger transport, banking services, e-books, and e-commerce.

E-commerce is the entry that catches most teams. Read broadly, it covers selling goods or services to consumers online, which is a much larger population of websites than the rest of the list combined. If a consumer can buy from you on the web, the reasonable planning assumption is that you are in scope.

Two carve-outs are worth knowing, and neither is a general escape hatch. Services provided by microenterprises — broadly, fewer than ten people and turnover or balance sheet total not above €2 million — are exempt from the service obligations. And there is a disproportionate-burden provision, which is not a judgement you simply assert: it has to be assessed, documented and revisited. Penalties are set by each Member State, so the consequence of getting it wrong varies considerably depending on where your customers are.

Enforcement here is not only regulatory. A consumer who cannot complete a purchase has a complaint route, and that is the mechanism most likely to reach you first.

Which standard sets the bar — and which one does not, yet

The Act itself states functional requirements rather than technical ones. The technical detail comes from the harmonised standard EN 301 549: build to it, and you get a presumption of conformity, which is the closest thing to a defensible position available.

This is where a lot of current advice is subtly wrong. The version of EN 301 549 in force today is v3.2.1, and for web content it points at WCAG 2.1 Level AA. A newer version incorporating WCAG 2.2 has been through drafting and is expected to be cited in the Official Journal later in 2026, but until that citation lands, WCAG 2.1 AA remains the yardstick.

The practical advice is unchanged by any of that: build to WCAG 2.2 AA now. It is a superset of 2.1, the additional criteria are cheap to satisfy at build time and expensive to retrofit, and it removes the need to revisit the question when the citation changes. The nine criteria WCAG 2.2 adds are mostly about interaction rather than markup — visible focus appearance, alternatives to dragging, avoiding cognitive tests in authentication, and not asking a user to re-enter information they have already given you.

What an automated checker finds

Automated tooling is genuinely worth running, in the build and in CI, because it is fast and it never gets bored. It reliably catches:

• Insufficient colour contrast against a computed background.
• Images with no alternative text attribute at all.
• Form inputs with no associated label.
• A missing or wrong language declaration on the document.
• Duplicate element IDs, and ARIA attributes that are invalid or applied to roles that do not accept them.

That is a real and useful set. It is also, in our experience, the minority of what an accessibility review turns up — and it skews heavily toward things a competent developer would not have got wrong in the first place.

What only a person finds

The failures that actually stop someone completing a purchase are judgement calls, and a checker has no way to make them:

• Whether alternative text is meaningful. "product-image-4.jpg" passes the presence check and communicates nothing.
• Whether focus order matches reading order. Every element can be reachable and the sequence still be nonsense — a common outcome of a modal, a sticky header or a CSS grid reordering the visual layout away from the DOM.
• Whether a keyboard user can escape. Custom dropdowns, date pickers, cookie banners and carousels are where keyboard traps live, and the tool sees a focusable element rather than a dead end.
• Whether an error tells you how to fix it. "Invalid input" is announced correctly and helps nobody; the requirement is that the user can identify and correct the problem.
• Whether a custom component behaves the way its role promises. Anything with role="button" that a checker accepts, but that ignores the space bar, is a failure only a person will notice.
• Whether the page survives 200% zoom and a narrow viewport without content being lost or requiring two-dimensional scrolling.

The method is unglamorous: traverse the primary journeys with the keyboard alone, repeat with a screen reader, then repeat zoomed in. It takes an afternoon per journey and it finds the things that matter.

Where the work actually lands

Most of it belongs in the build, not the test pass. Semantic markup, a visible focus style, targets large enough to hit, labelled controls and respect for reduced-motion preferences are build-time decisions that cost nothing when made early and require rework when made late. The site you are reading applies exactly those rules — every focus style comes from one shared utility, interactive targets carry a minimum hit area, and all motion is gated on the reduced-motion preference.

What belongs in the test pass is verification on the journeys that matter commercially — registration, search, checkout, payment, account management — and re-verification when they change. Accessibility regresses the same way anything else does: quietly, in a component someone swapped out.

Where to start if you have not

1. 01Establish whether you are in scope, and write the reasoning down. For most consumer-facing commerce the answer is yes and the exercise takes an hour.
2. 02Run an automated check across your main templates. It is a free floor, and it tells you whether you are dealing with hygiene problems or something structural.
3. 03Keyboard-traverse your revenue path end to end. If you cannot complete a purchase without a mouse, nothing else on this list matters yet.
4. 04Fix at the component level rather than the page level. A design system with one accessible input, one accessible dialog and one accessible menu fixes every page that uses them, which is the only version of this work that stays fixed.
5. 05Decide who re-checks it, and when. Accessibility is a property of the current build, not a certificate — the same reason a security assessment describes the application on the dates it was tested.

The sectors where this bites hardest are the ones selling directly to consumers at volume — e-commerce above all, where an inaccessible checkout is simultaneously a legal exposure and a measurable amount of lost revenue.