The European Accessibility Act Has Teeth Now: What Your Website Needs

The European Accessibility Act became applicable on 28 June 2025. For the first year, most companies watched to see whether anyone would actually enforce it. That question has been answered.

A French court ordered Carrefour to reach full compliance under a penalty of 500 euros per day. Market surveillance authorities across Member States moved from information requests to targeted audits during 2026. Complaint mechanisms exist in every Member State, and disability organisations have been using them.

If you sell to consumers in the EU and your site is not accessible, this is no longer a reputational question. It is a supervised one.

What the Act Actually Covers

Directive 2019/882 applies to a defined list of products and services, not to the whole web. The services in scope include:

E-commerce, defined broadly as any service allowing a consumer to conclude a contract at a distance. If someone can browse, select and buy on your site, you are in scope.
Consumer banking services, including online banking and payment interfaces.
Passenger transport services, including websites, apps and ticketing.
Electronic communications services.
Access to audiovisual media services.
E-books and dedicated software.

Products in scope include self-service terminals, payment terminals, e-readers and consumer computing hardware.

Two boundaries matter in practice. First, the directive applies to services provided to consumers. Purely business-to-business platforms, internal tools and services not offered to the public sit outside it. Second, there is a micro-enterprise exemption for services: fewer than ten employees and annual turnover or balance sheet total not exceeding two million euros. That exemption applies to services only, not to products, and you do not apply for it, you either fall under the threshold or you do not.

The exemption is narrower than people hope. A twelve person online retailer is in scope. So is a company with eight employees selling a physical product covered by the products annex.

The Technical Standard

The Act sets functional requirements. The technical benchmark is the harmonised European standard EN 301 549, which is where the actual testable criteria live.

The current published version, V3.2.1 from March 2021, incorporates WCAG 2.1 Level AA. A revision aligning with WCAG 2.2 is expected, which adds a small number of success criteria around focus appearance, dragging movements, target size, consistent help and redundant entry. None of those are dramatic, but if you are remediating now, building to WCAG 2.2 rather than 2.1 avoids doing the work twice.

Conformance with the harmonised standard gives you a presumption of conformity with the directive. That is the practical target: WCAG 2.1 AA today, WCAG 2.2 AA if you want headroom.

What This Means in the Codebase

Accessibility guidance tends to be written at the level of principles. Here is what it looks like as work, based on what we find in almost every audit.

Semantics and structure

Most accessibility failures are structural. A page built from nested divs with click handlers gives a screen reader nothing to work with.

Use real elements. A button is <button>, not a div with an onClick. A link that navigates is <a href>. This one change fixes keyboard operability, focus behaviour and announcement in a single move.
Landmarks: header, nav, main, footer. One main per page.
Headings in order, describing structure rather than chosen for their font size.
Lists as lists, tables as tables with proper header cells and scope.
Language declared on the html element, and changed inline where content switches language. On a multilingual site this matters more than people assume, because a screen reader will otherwise read French with an English voice.

Forms

Forms are where transactions fail, so they get scrutiny.

Every input has a programmatically associated label. Placeholder text is not a label.
Errors are identified in text, associated with the field, and announced. A red border alone communicates nothing to a non-sighted user.
Required fields are marked in a way that is exposed to assistive technology.
Autocomplete attributes on personal data fields, which is an explicit WCAG criterion and also improves conversion.
Grouped controls use fieldset and legend.

Keyboard and focus

Everything interactive is reachable and operable by keyboard, in an order that matches the visual layout.
Focus is always visible. Removing outlines without replacing them is a straight failure.
No keyboard traps. Modals trap focus deliberately, return it on close, and close on Escape.
Skip link to main content.

Visual design

Text contrast of at least 4.5 to 1 for normal text and 3 to 1 for large text.
Non-text contrast of 3 to 1 for interface components and meaningful graphics, which catches a lot of low contrast borders on form fields.
Content reflows at 320 CSS pixels wide without horizontal scrolling.
Text resizes to 200 percent without loss of content.
Colour never carries meaning on its own.

Dynamic content

Live regions announce changes that happen without a page load, such as cart updates or validation summaries.
Custom components carry correct roles, states and properties. If you are building a combobox by hand, follow the ARIA authoring practices rather than improvising.
Respect the reduced motion preference.
Nothing that auto-plays audio, and no auto-advancing carousels without a pause control.

Documents and media

PDFs in scope need to be tagged and readable. An invoice or terms document delivered as a scanned image fails.
Video needs captions. Pre-recorded audio needs a transcript.
Images need alt text that conveys purpose. Decorative images take an empty alt attribute.

The Accessibility Statement

Service providers have to publish information about how the service meets the requirements. Missing or incomplete accessibility statements are one of the most common findings, and it is a strange thing to fail on because it costs an afternoon.

A usable statement includes the conformance target, the date of the last assessment, the method used, a candid list of known limitations with a timeline, a feedback channel that a real person monitors, and details of the national enforcement body for complaints.

Do not overclaim. Stating full conformance when a known gap exists is worse than stating partial conformance with a remediation plan, both legally and practically.

Penalties

Penalties are set nationally and vary considerably. Published figures include up to 90,000 euros in the Netherlands, ranges from 10,000 to 100,000 euros per violation in Germany, tiers from 75,000 to 300,000 euros per violation in France, and up to 60,000 euros in Ireland. Some Member States allow turnover-based calculations for repeat or serious cases.

The financial exposure is often not the biggest cost. Being ordered to remediate under a daily penalty means doing the work under deadline pressure, with an auditor, which is far more expensive than doing it deliberately.

Overlay Tools Do Not Work

Accessibility overlays, the JavaScript widgets that promise instant compliance, do not deliver it. They cannot fix missing semantics, they cannot write meaningful alt text, and they frequently interfere with the assistive technology a user has already configured. Disability advocacy organisations have been consistent on this, and litigation in other jurisdictions has repeatedly involved sites running an overlay.

Treat them as a tax, not a fix.

A Realistic Remediation Path

Here is the sequence we use, which tends to remove most of the risk in the first two phases.

Phase 1: automated scan plus manual audit. Automated tools catch roughly a third of issues, which is useful but nowhere near sufficient. Pair the scan with manual keyboard testing and screen reader testing on the critical paths: home, category, product, cart, checkout, account, contact.

Phase 2: fix the transaction paths. Checkout, sign up, log in, search. These are where an inaccessible site stops being an inconvenience and becomes exclusion, and they are what a complaint will be about.

Phase 3: fix the component library. Most sites are built from a limited set of components repeated everywhere. Fixing the button, input, modal, dropdown, tab and table components once fixes hundreds of pages at once. This is where the leverage is.

Phase 4: content and documents. Alt text, headings, PDFs, captions. Slow but not technically difficult.

Phase 5: prevent regression. Automated accessibility checks in CI, linting rules for JSX or templates, and accessibility criteria in the definition of done. Without this you will pay for the audit again in eighteen months.

The Adjacent Benefit

Everything above also improves search visibility, Core Web Vitals and conversion. Proper heading structure, semantic markup, real labels and sufficient contrast are the same things that help crawlers parse a page and help ordinary users complete a purchase on a phone in bad light.

There is also an overlap with newer obligations. The AI Act's transparency rules require information to be provided in a clear, distinguishable manner conforming to applicable accessibility requirements, which means an AI disclosure buried in an inaccessible tooltip fails twice. We covered that in the AI Act transparency article.

Where to Start

If you have not been audited, start with a keyboard. Unplug your mouse and try to complete a purchase on your own site. Most teams find their first three issues within five minutes, and it is a more persuasive demonstration to management than any report.

We run accessibility audits and remediation programmes for companies operating in the EU, including component library work and CI integration so the fix holds. There is more detail on our accessibility remediation service page, and the wider regulatory context is in our 2026 EU digital compliance map.

Get in touch at office@c9group.dev if you want an honest read on where you stand.