Accessibility that holds up to the EAA, not an overlay that doesn't.

For years, digital accessibility in Europe was a patchwork. The Web Accessibility Directive set firm rules for public-sector sites, while private business faced a different rule in every member state or, often, no clear rule at all. The European Accessibility Act, Directive (EU) 2019/882, closes that gap for a defined set of consumer products and services, setting one baseline across the single market for the things people use every day: buying online, banking, reading an e-book, using a ticket machine, making a call.

The date that matters has passed. Since 28 June 2025 the requirements apply, so for most organisations the question is no longer whether to act but how to prove their digital services meet the bar and how to keep meeting it as the product changes. The directive serves two purposes at once. It removes a trade barrier, because a business no longer has to navigate twenty-seven national accessibility regimes to sell across the EU, and it widens access for the roughly 87 million people in the EU who live with a disability, a figure that grows as the population ages and a fifth of Europeans pass sixty-five.

Enforcement is not the slow, complaint-driven model some expected. National authorities run market surveillance, which means they can look at a service without waiting for someone to sue. Through 2025 and into 2026 several have started: in the Netherlands the consumer authority set a reporting deadline and moved to audits, in Sweden the telecom regulator began surveying e-commerce sites for the mandatory accessibility statement, and the first court actions were filed in France. The practical message is that a wait-and-see posture is now the riskier one.

The EAA covers a specific list rather than the whole economy, but the list captures most consumer-facing digital business. On the services side it reaches e-commerce, consumer banking, e-books and dedicated e-reading software, electronic communications services, access services for audiovisual media, and passenger transport for air, bus, rail and waterborne travel, including the websites, mobile apps, ticketing and real-time information that go with them. On the products side it covers consumer hardware such as computers and operating systems, smartphones, payment terminals, and self-service terminals like ATMs and ticketing and check-in machines.

Two points decide whether it lands on you. First, the obligation follows the market: a company based outside the EU that sells covered products or services to EU consumers is in scope, in the same way GDPR reaches data processing wherever it happens. Second, there is a narrow exemption. Microenterprises that provide services, meaning fewer than ten people and under two million euro in turnover, are exempt for those services, though the exemption is narrower than people assume and does not extend to products in the same clean way.

If you are unsure whether a particular service is caught, that scoping question is the first thing to settle, because the cost and the deadline pressure of the work depend entirely on it.

The EAA itself is written in terms of outcomes, in its essential requirements, rather than a checklist of technical rules. To make conformity assessable, it relies on a harmonised European standard, EN 301 549. Meeting that standard gives a presumption of conformity with the directive, which is why it, rather than the directive text, is what an audit measures against.

Here the timing matters. The current published version, EN 301 549 v3.2.1, incorporates WCAG 2.1 level AA for web content, so WCAG 2.1 AA is the operative benchmark for a website or app today. A newer version, v4.1.1, is expected in 2026 and will move the reference up to WCAG 2.2 and refresh other requirements, including real-time text. WCAG 2.2 became a W3C Recommendation in 2023, adds nine success criteria, and is backwards-compatible with 2.1, which means anything you build to 2.2 already satisfies 2.1. The sensible position is to target WCAG 2.2 now and avoid doing the work twice when the standard updates.

One detail is easy to miss: EN 301 549 is broader than WCAG. WCAG governs web content, but the European standard also sets requirements for mobile applications, non-web software, electronic documents, and hardware, plus functional performance statements that describe what a user with a given disability must be able to do. For a service that is more than a website, a passenger app with a ticket machine behind it, for instance, the relevant requirements reach past the web pages into the rest of the product.

For anything on a screen, the working content of EN 301 549 is WCAG, organised under four principles. Content has to be perceivable, which covers text alternatives for images, captions for media, and enough colour contrast that a person with low vision can read it. It has to be operable, which means everything works by keyboard and not only by mouse, nothing flashes in a way that triggers seizures, and people have time to complete tasks. It has to be understandable, with predictable navigation and clear language and error messages. And it has to keep working with assistive technology such as screen readers as browsers and tools evolve, the compatibility principle WCAG places last.

Most failures are mundane and fixable: form fields without labels, a focus indicator you cannot see, contrast that looks fine to a designer but not to a user, controls that respond only to a click. WCAG 2.2 adds nine criteria that target newer, common barriers, and they are worth knowing because they are where many otherwise-decent sites now fall short. They cover a visible and unobscured focus indicator, a minimum target size so small controls are tappable, an alternative to dragging gestures, help that stays in a consistent place, not forcing users to re-enter information they already provided, and authentication that does not hinge on a memory or puzzle test. Designed in from the start, these cost almost nothing; bolted on afterwards, they mean rework.

It is tempting to drop in a widget that promises instant compliance. Overlays do not deliver it. They sit on top of the underlying problems rather than fixing them, can interfere with the assistive technology a user already relies on, and have been rejected by courts and by disability advocates. An overlay can make a site less usable for the very people it claims to help, while giving the owner a false sense of safety that lasts exactly until the first real audit.

A market-surveillance authority assessing conformity against EN 301 549 looks at the underlying experience, not the marketing of a plugin. Genuine accessibility is structural. It lives in the semantic markup, the focus order, the contrast tokens and the components, which is why it cannot be sprayed on at the end and why we treat it as part of building the front-end correctly.

No single method is enough, and any audit that relies on one is incomplete. Automated scanning is fast and finds the mechanical failures, missing alt text, missing labels, low-contrast pairs, but it catches only a fraction of real problems, commonly put at around a third to a half. The rest are things a machine cannot judge: whether the keyboard journey through checkout actually works, whether a screen reader announces each step in a sensible order, whether an error message makes sense, whether the focus is visible as you move through a custom component.

So we run both. The automated pass narrows the field quickly; the manual pass against EN 301 549 and WCAG is where the substance is, done with keyboard-only navigation, real screen-reader walkthroughs of the journeys that matter, and contrast and focus checks across states. The output is a list of specific failures tied to specific criteria, prioritised by user impact and legal exposure, rather than a score with no path attached.

# automated scan catches the mechanical failures (a fraction of the total)
$ npx axe-core https://shop.example.eu
  98 elements checked  ·  7 violations
  [serious]  color-contrast   12 nodes   text on brand colour below 4.5:1
  [serious]  label             4 nodes   inputs without an accessible name
  [moderate] link-name         3 nodes   links with no discernible text

# automated tools find ~1/3 to 1/2 of issues — the rest is manual
$ argus a11y manual --against EN-301-549
  [pass] keyboard      full journey completed without a mouse
  [warn] focus-visible focus ring missing on the custom dropdown
  [fail] screen-reader checkout step 2 is not announced

  target: WCAG 2.1 AA (EN 301 549 v3.2.1)
  advise: build to WCAG 2.2 now — v4.1.1 expected 2026

Because each member state runs its own enforcement, the penalty depends on where you sell. National regimes set their own ceilings, and reported figures span a wide range, from the low tens of thousands of euro in some countries to several hundred thousand in others, with a handful providing for criminal penalties in serious cases. Treat any single number as country-specific and verify it against the national authority rather than assuming a uniform fine across the EU.

The fine is rarely the sharpest cost. Authorities can order corrective action on their timeline, restrict a non-compliant product or service on the market, and require public disclosure. Some have run their early surveillance specifically on whether a business has published the mandatory accessibility statement, which makes a missing statement an easy and visible first finding. And underneath the legal exposure sits the commercial one: an inaccessible checkout or banking app turns away paying customers, including an ageing population that is a growing share of the market. The statement, done honestly, is also a useful artefact: a clear description of how the service meets the requirements, with known limitations and a remediation timeline, is more defensible than a blanket claim of full compliance that the first audit contradicts.

For a product that already exists, we audit it against EN 301 549 and WCAG using the automated-then-manual method above, prioritise the fixes by user impact and legal exposure, and implement them, then produce the accessibility statement and the evidence behind it so you can show a regulator how you reached conformance rather than just asserting it. The remediation is sequenced so the highest-impact barriers fall first, which matters when a large application cannot be fixed all at once.

For a new build, accessibility is a design input from the first component, where it costs a fraction of a later retrofit. Our Astro front-end work targets WCAG 2.2 AA by default: semantic HTML rather than a soup of unlabelled containers, focus management that is visible and logical, contrast that meets the ratio in every theme, full keyboard support, and components tested with a screen reader before they ship. The accessible version is simply the version we build, which is the cheapest place accessibility can ever live.

If a requirement sits outside our competence, a specialist hardware terminal assessment, say, we will tell you and bring in the right partner rather than stretch our remit to cover it. The goal is a product that a person with a disability can actually use and that you can defend to a market-surveillance authority, not a badge that survives only until someone tests it with a keyboard.