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.
Agree the legal scope and technical assessment criteria
The Act sets functional accessibility requirements. Article 15 provides a presumption of conformity for requirements covered by harmonised standards whose references are published in the EU Official Journal. A standard being published is different from its being cited for a particular directive. Confirm the applicable national law, citation and assessment scope before making a legal conformity claim.
The technical guidance has moved on: W3C’s WCAG overview states that the 2026 version of EN 301 549 uses WCAG 2.2. That does not by itself establish which version is legally referenced for your product. Record the exact version and applicable clauses in the assessment plan.
Use WCAG 2.2 AA as the web engineering target, then check additional applicable EN 301 549 requirements for documents, software and support. Include keyboard access, unobscured focus, target size, alternatives to dragging and accessible authentication in acceptance criteria. Those criteria need verification in real journeys; selecting a target alone does not establish conformance.
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.
Traverse the primary journeys with the keyboard alone, repeat with a screen reader, then repeat zoomed in. Allow time for the complexity of each journey and the assistive technologies in scope; record steps, outcomes and reproducible failures.
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 are easier to plan early than to retrofit. 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
- 01Establish whether you are in scope, and write the reasoning down. For most consumer-facing commerce the answer is yes and the scope decision needs a recorded basis.
- 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.
- 03Keyboard-traverse your revenue path end to end. If you cannot complete a purchase without a mouse, nothing else on this list matters yet.
- 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.
- 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.
