The European Accessibility Act — Directive (EU) 2019/882 — brought a broad range of consumer-facing digital products and services into scope of accessibility requirements, with obligations applying from 28 June 2025. It is implemented through national law in each member state, so the detail and the enforcement differ, but the substance is consistent across the EU.
This is a plain summary for people commissioning software, not legal advice. Where it matters to your business, get it from a lawyer in your jurisdiction.
Who is covered
The Act reaches products and services offered to consumers, including e-commerce, consumer banking services, e-books, electronic communications, elements of passenger transport services, computers and operating systems, and self-service terminals such as ticket machines and payment terminals.
"E-commerce" is the clause that catches most companies by surprise. If you sell to consumers online, the website or app through which you sell is in scope — including the parts around the purchase, such as identification, payment and the information you provide about the product.
There are exceptions. Microenterprises providing services — fewer than ten people and turnover or balance sheet total not exceeding two million euro — are exempt from the service obligations, though not from the general expectation that follows from every other pressure in this direction. There is also a disproportionate-burden provision, which requires a documented assessment rather than an assertion.
Business-to-business software is outside the consumer scope. In practice it is drifting in anyway, because covered organisations increasingly require conformance from their suppliers.
What conformance actually means
The technical benchmark is the European standard EN 301 549, which for web content aligns with WCAG at level AA. That is the target to build against and the level to write into a contract.
Concretely, level AA requires things like these:
- Everything operable by keyboard alone, with a visible focus indicator — no functionality that requires a mouse.
- Sufficient colour contrast for text and interface components, and never using colour alone to convey meaning.
- Text alternatives for images, and captions for video.
- Form fields with real labels, and errors identified in text rather than only by turning a border red.
- Correct semantic structure — headings in order, landmarks, lists that are lists — so screen readers can navigate.
- Content that survives 200% zoom and reflows on a narrow viewport without loss of function.
The service also has to publish accessibility information describing how it meets the requirements.
Why leaving it late is the expensive path
Accessibility built in from the design stage adds a modest amount to a project — better markup, contrast checked at design time, focus states designed rather than inherited. Most of it is work a careful team does anyway.
Retrofitting is a different exercise, because the fixes are structural. A custom dropdown built from styled divs has to be rebuilt to be operable and announced correctly. A colour palette failing contrast affects every screen. A single-page application that never announces navigation needs its routing reworked. Estimates for retrofitting an established product routinely run several times what building it in would have cost.
Automated tools find perhaps a third of the issues. The rest needs manual testing — keyboard navigation, a screen reader, zoom — which is why "we ran a scanner and fixed the errors" is not conformance.
What to do about it
If you have an existing consumer-facing product, start with an audit against EN 301 549 that combines automated scanning with manual testing, and produces a prioritised list rather than a raw dump of violations. Fix the blocking issues first: things that make a task impossible to complete are a different order of problem from a suboptimal heading level.
If you are commissioning something new, put WCAG 2.1 AA in the specification and make it part of the definition of done. It costs very little at that point and removes the entire question.
Either way, get it tested by someone who uses assistive technology daily. It is the fastest way to find the difference between technically conformant and actually usable, and that gap is where most of the real barriers live.
The part that is not about compliance
Somewhere between a tenth and a fifth of the population has a disability, and the measures overlap heavily with things that help everyone: clear structure, readable contrast, forms that explain their errors, interfaces that work on a phone in bright sunlight or on a laptop with a broken trackpad.
The regulation is the reason this is now scheduled work rather than deferred work. It is not the only reason to do it, and organisations that treat it as a checklist tend to produce the minimum that passes an audit and still turns customers away.