The European Accessibility Act Made Accessibility Operational

A year after 28 June 2025, the interesting question is no longer whether the European Accessibility Act applies to you. Most organisations selling into the EU worked that out in 2025, usually late, usually with an agency and a spreadsheet. The interesting question is what happens on the Tuesday after the audit passes — when a marketing team ships a new landing page, a vendor auto-updates a chat widget, and a developer adds a pop-up that traps the keyboard inside it.

That is the shift. The Act did not raise the standard much. It changed who has to hold it, and for how long.

The law asks for a record that outlives the release

Read the obligations rather than the summaries and a pattern appears fast.

You have to write down how your service meets the requirements, publish that in a form disabled people can actually read, and keep it accurate for as long as the service is running. If you want to argue that some requirement is disproportionately expensive, you have to document that argument, keep it for five years, and revisit it — and the European Commission’s own guidance is blunt that lack of time, budget or expertise does not count as a reason. Enforcement is complaint-driven: member states appoint authorities that follow up complaints and check whether you actually fixed what you said you would.

None of that describes an audit. It describes a file that has to stay true while the product keeps moving.

This is where the commodity advice quietly fails. Audit, remediate, publish a statement, repeat annually — that sequence produces a photograph of a system that changes every fortnight. The statement is a claim about a live service. The moment it stops matching the code you have deployed, you have a documentation problem on top of an accessibility one.

Design review is where the cost gets decided

Almost every expensive accessibility fix started as a design decision nobody questioned. Colour pairs too faint to read. A tab order that follows the visual layout rather than the reading order. Error handling that changes a border colour and nothing else. Custom dropdowns and date pickers that only work with a mouse. A tap target sized for a cursor.

Caught in design review, each of those is a five-minute conversation. Caught in pre-launch testing, each is a redesign with a release date attached. The change that saves most is to add three questions to design review — how does this work without a mouse, what does it look like when it has keyboard focus, what happens when it fails — and to refuse the handoff without answers.

The component system is the only place the rule scales

Page-by-page accessibility does not survive contact with a content team. Component-level accessibility does. If the button, the field, the dialog and the table are correct once, every page assembled from them starts correct, and what is left to get wrong is composition and content.

This is why we build the baseline into the design system rather than bolting it on afterwards — an argument we make at length in the design system as a contract. WCAG 2.2 AA is our baseline on every build we originate, verified before launch. On a platform we inherit the position differs: we assess against it, report the gap, and close it on a schedule you can see. Nobody brings somebody else’s decade of decisions up to standard before their first release.

We learned this somewhere less obvious than the web. On a video product delivered across several TV app stores, conformance was never something we asserted at the end. A third party checked it before anything shipped, on a schedule we did not set. A television is driven by a five-key remote, so the highlight showing where you are is not decoration — it is the only thing telling a person where they are. A store reviewer who cannot navigate the app does not file a bug. They reject the release.

The lesson transferred. Teams that had genuinely solved the remote control had already solved most of the keyboard requirements, because they had stopped assuming a pointer. Accessibility is largely an input-independence problem wearing a compliance costume. Build for the input you did not design for, and the screen reader work gets substantially smaller.

Procurement is where compliance leaves the building

The obligation sits with you, the service provider. But the consent banner, the chat widget, the embedded player, the payment step and the kiosk are usually somebody else’s code. Two things follow.

First, choosing a vendor is now an accessibility decision. No standard question set circulates publicly, so here is the one we use. Six questions, and the answers matter less than whether the vendor can answer at all.

1. Which parts of the standard does your accessibility statement cover, and which does it explicitly exclude?
2. Which screen readers and browsers was it tested against, and on what date?
3. Who owns accessibility at your company, and what happens when we report a defect?
4. What happens to that statement when you ship a major version — is it re-tested, or just re-dated?
5. Can we see the underlying report rather than the summary?
6. If we report an accessibility defect, is fixing it a support ticket or a feature request?

Question six is the one that predicts the next two years. A vendor who answers all six is rare. A vendor who cannot answer any has told you something useful anyway.

Second, the transitional relief is finite. You may keep using non-conforming products until 28 June 2030, and inaccessible self-service terminals have until 28 June 2045. Those dates are a replacement schedule, not an exemption. They belong in a capital plan now.

The standard underneath is moving

The European standard in force today points at WCAG 2.1 AA. A draft revision moves it towards 2.2, and the EU’s own work programme still lists that as open with no completion date. We could not verify a date, so we will not give you one.

So, the separation. The legal reference point today is the older version. Building to 2.2 is our recommendation, not your obligation — its additions are mostly cheap at build time and awkward as retrofits, and we would rather not re-audit a platform when the law catches up.

It may not apply to you, or not all of it

This is the part most agency writing gets wrong, so we will be precise. The Act covers a defined list of sectors — e-commerce, banking, e-books, transport information, telephony, audiovisual media, computers, self-service terminals — not every business with a website. Small service providers are generally exempt. And any covered organisation can argue a specific requirement is disproportionate, though that argument is made requirement by requirement, documented, and revisited.

Reported enforcement in the first year has looked complaint-shaped and litigation-shaped rather than fine-shaped, at least according to vendors tracking it. We have not seen a primary dataset and are not going to invent one. We are not lawyers, this is not legal advice, and the question of what applies to you genuinely needs counsel in the member states you sell into.

What that objection does not get you is a design position. An exemption from a requirement is not an exemption from the user. If a checkout cannot be completed without a mouse, the person abandoning it does not care which article covered you.

An operating model, not an annual audit

Map accessibility onto the phases you already run, and give each one an owner.

• Gather. Name the services in scope. Decide who owns the accessibility statement, by name.
• Prototype. A design review gate: keyboard model, focus, error states, target size. No answers, no handoff.
• Build. Conformance at the component level. Page-level checks catch composition, not the building blocks.
• Verify. Automated checks in the pipeline, plus manual keyboard and screen reader passes on the journeys that earn money. Automation alone will not find a broken focus order — that is engineering work, not a scan.
• Care. This is how our own platform care retainers work: accessibility is re-checked whenever something ships that touches the interface, rather than on a calendar. A quarterly audit tells you what was true in a quarter you are no longer in.

Then ask the four questions that tell you whether the model is real. Who is accountable when the statement stops being true? What kinds of change trigger a re-check? Who gets told when a third-party component ships a major version? And if an authority asked today, what evidence could you produce this week?

If the honest answer to the last one is “we would have to commission an audit”, you do not have an operating model. You have a receipt from last year.