For years, digital accessibility sat in a comfortable grey zone: nice to have, easy to defer, quietly dropped when a deadline loomed. That zone closed on 28 June 2025, when the European Accessibility Act (EAA, Directive (EU) 2019/882) began to apply across the Union. The Act reframes accessibility from a matter of goodwill into a condition of market access. If your product or service is in scope and placed on the EU market, meeting the requirements is no longer a stretch goal you can trade away — it is part of being allowed to sell.

I want to treat this the way I treat any other non-functional requirement a serious client hands me: soberly, as an engineering-quality problem with a defined standard, a testable definition of done, and an ongoing maintenance cost. Not as charity, and not as a compliance panic.

What the Act actually requires

The EAA harmonises accessibility rules that were previously fragmented across member states, so a single design can be sold Union-wide rather than re-argued country by country. It covers a specific list of products and services. On the product side: consumer computers and operating systems, payment terminals, ATMs, ticketing and check-in machines, and e-readers. On the service side — where most of my readers live — it covers e-commerce, consumer banking, electronic communications, e-books, access to audiovisual media services, and elements of passenger transport information.

The obligation is not "add a widget" or "run one scanner". It is that the covered functionality must be perceivable, operable, understandable and robust for people with disabilities: keyboard operability, sufficient contrast, text alternatives, captions, predictable focus, forms that announce their errors, content that survives being zoomed or read aloud. For a web service, that means the whole purchase-and-support journey, not just a marketing landing page. Note that the Act regulates the product or service itself; it is distinct from the older Web Accessibility Directive, which targets public-sector bodies.

WCAG 2.2 and EN 301 549: the technical yardstick

The Directive states goals in plain language and deliberately does not hard-code a version number. The bridge from those goals to something an engineer can test is the harmonised European standard EN 301 549, which in turn leans on the Web Content Accessibility Guidelines (WCAG) at conformance level AA. Meeting the standard gives you a presumption of conformity — a legally useful shortcut that shifts the burden of proof in your favour.

One nuance worth stating precisely, because a lot of vendor copy blurs it. As of early 2026, the version of EN 301 549 formally cited in the Official Journal is the v3.2.x line, which incorporates WCAG 2.1 AA. An update aligning the standard with WCAG 2.2 AA has been in draft and public review and is expected to be referenced later; the practical timeline has slipped before, so treat any exact date as provisional. My advice for anyone building today is unchanged: target WCAG 2.2 AA. It is a superset of 2.1, its additions (focus appearance, dragging alternatives, accessible authentication, consistent help) are exactly the things real users struggle with, and building to it now means you are ahead of the harmonisation curve rather than chasing it.

Who is in scope, and the microenterprise carve-out

Scope follows the market, not the passport. A company established outside the EU is still bound if it places covered products or offers covered services to EU consumers — the roles of manufacturer, importer, distributor and service provider each carry duties. So a US or UK SaaS selling to European buyers is squarely in the frame.

The one meaningful relief is the microenterprise exemption, and it is narrower than people hope. A microenterprise — fewer than 10 staff and annual turnover or balance-sheet total not exceeding roughly €2 million — is exempted from the Act's obligations for services only. Microenterprises that make or handle products get no such pass. And "we have nine people" is not a strategy: cross the threshold and the obligation lands, usually at the worst possible moment. Separately, any operator can invoke disproportionate burden or fundamental alteration under Article 14, but that is a documented, evidence-based assessment you must keep (broadly, for around five years) and hand to a market-surveillance authority on request — not a checkbox you tick to opt out.

The accessibility statement

Being conformant and being seen to be conformant are different obligations. In-scope services must publish an accessibility statement: a public document, itself accessible, that describes how the service meets the requirements, records known limitations and any burden claims, and — critically — gives users a feedback mechanism to report barriers. Treat it as a living artefact tied to your actual audit results, not boilerplate copied from a competitor. A statement that promises full conformance while your checkout traps keyboard focus is worse than none: it is a documented, self-authored admission of the gap.

A pragmatic route to conformance

The good news for engineers is that this decomposes into a familiar pipeline. Four steps, in order.

  • Audit. Establish the real baseline against WCAG 2.2 AA / EN 301 549. Automated tools (axe, Lighthouse, Pa11y) catch perhaps a third to a half of issues — enough to be useful, not enough to be sufficient. The rest needs manual keyboard-only passes, a screen reader (NVDA, VoiceOver), zoom and reflow checks, and ideally testing with actual assistive-technology users. Prioritise the journeys that generate revenue and support load.
  • Remediate. Fix by impact, not by scanner line count. Semantic HTML and native controls solve more than any overlay ever will — and be wary of "accessibility overlay" widgets that promise instant compliance; they are widely criticised and do not deliver conformance. Bake fixes into components so a corrected date picker or modal is corrected everywhere at once.
  • Publish the statement. Write it from the audit, honestly, with the feedback channel wired to a real inbox someone reads.
  • Keep it in CI. This is the step that separates a one-off cleanup from durable conformance. Accessibility regresses like any other quality attribute the moment it stops being measured. Wire axe-core into your component and end-to-end tests, fail the build on new violations, and add accessibility to your definition of done and pull-request review. It becomes cheap once it is continuous and ruinous when it is a periodic fire drill.

What this means for you: if you sell digital products or services to EU consumers and you are not a microenterprise offering only services, the EAA already applies to you. The framing I would keep is the one I opened with — this is quality and market access, not virtue. An accessible product is more robust under automation, more resilient to device and input variety, and reaches customers your competitors are quietly turning away. Run the audit, fix by impact, publish an honest statement, and put the guardrails in CI so it stays fixed. That is the kind of unglamorous, durable engineering work I take on — and it is far cheaper to do deliberately now than reactively after a complaint lands.