The EU's accessibility act has been enforceable for over a year, and it probably covers your app

A founder sells a subscription app, or runs an online store. The business is registered in Cairo, Austin, or Dubai. Someone on the team mentions "the European accessibility law" and the room decides it is an EU-institution problem, or a bank problem, or a problem for companies with offices in Frankfurt. Nobody looks it up.

The law is Directive (EU) 2019/882 ↗, the European Accessibility Act. Member states had to write it into national law by June 28, 2022, and the obligations have applied since June 28, 2025. That is over a year of enforceable national law, and the directive's definitions reach further than most owners expect. This post goes through what it actually says, in its own text, and ends with the checklist we run with clients.

What it covers, and who it counts as a service provider

Article 2 lists the services in scope: electronic communications (machine-to-machine transmission aside), access to audiovisual media, the customer-facing elements of passenger transport, consumer banking, e-books and their dedicated software, and e-commerce. The e-commerce definition is the one that catches people. It means a service provided at a distance, through websites or "mobile device-based services", by electronic means, at a consumer's individual request, with a view to concluding a consumer contract. A subscription app, a paid booking flow, an online shop: if a consumer can buy something from you through your site or app, that is the category you are in.

Mobile apps are not implied, they are named. Annex I Section III requires covered services, the carve-out being urban, suburban and regional transport, to make "websites, including the related online applications, and mobile device-based services, including mobile applications" accessible.

Then the exemptions everyone assumes they have, in order of how wrong they are:

• "We are not in the EU." Article 3 defines a service provider as anyone who provides a service on the Union market "or makes offers to provide such a service to consumers in the Union". No office, subsidiary, or establishment required. If EU consumers can sign up and pay, you are in scope on paper.
• "We are too small." The microenterprise exemption is real but narrow: fewer than 10 employees and annual turnover or balance sheet not exceeding EUR 2 million, and it exempts you for services only. Microenterprises that deal with products stay in scope.
• "We are B2B." The services chapters cover what is "provided to consumers", and a consumer is a person acting outside their trade or profession. A genuinely B2B-only product is out. A product where any individual can register and pay is not B2B-only.
• "We predate the law." Products placed on the market before June 28, 2025 are outside it. Services are not grandfathered the same way: the obligation attaches to services provided to consumers after that date. Service contracts agreed before it can run to expiry, capped at five years, so June 28, 2030 at the latest. Self-service terminals already in use can finish their economically useful life, up to 20 years after entry into use, if the member state allows it.
• "Our content is old." Partially true. Article 2(4) excludes pre-recorded media and office documents published before June 28, 2025, archived content untouched since then, online maps where the essential information is accessible another way, and third-party content you neither fund, develop, nor control. User reviews on your store stay exempt; your checkout does not.

The product list matters if you ship hardware: computers and their operating systems, smartphones and TV equipment as "consumer terminal equipment with interactive computing capability", e-readers, and self-service terminals (payment terminals, ATMs, ticketing and check-in machines). Most of our readers sell services, so the rest of this post stays on the services side.

What it actually asks for

The requirements are functional, not a conformance badge. Annex I Section III says covered services must be provided so as to "maximise their foreseeable use by persons with disabilities", which for websites and mobile applications means making them, in the directive's own words, "perceivable, operable, understandable and robust". Those are the WCAG POUR principles written into law.

Article 13 adds the paperwork most providers are missing:

• Prepare and publish information explaining how the service meets the accessibility requirements (Annex V details it: a general description in accessible formats, explanations needed to understand the operation, and a description of how the requirements are met), in the general terms and conditions or an equivalent document, in written and oral format, kept for as long as the service runs.
• Keep procedures in place so the service stays in conformity as the service, the requirements, and the standards change.
• If the service is not compliant, take corrective measures and "immediately inform" the competent national authorities in the member states where it is provided.

That last one deserves a second read. Non-compliance is not just a state you quietly fix; the directive makes telling the regulator part of the procedure.

What the directive pointedly does not do is name WCAG or EN 301 549 anywhere in its text. Conformity is presumed when you follow a harmonised standard cited in the Official Journal (Article 15). As of November 2026, no standard has been cited under this directive yet. The candidate is EN 301 549 V4.1.1, published by ETSI in September 2026, the first edition written for the EAA, and it maps its web, document, and software clauses to WCAG 2.2. Its citation is expected before the end of the year, so by the time you read this the picture may have moved. The practical target does not change either way: WCAG 2.2 at level AA is the benchmark the whole system points at. WCAG 2.2 has been a W3C Recommendation since October 2023, with the current version dated December 2024.

Two more clauses people reach for and get wrong. The "disproportionate burden" defence is real, but Article 14 makes it a documented assessment against Annex VI criteria, kept for five years, and service providers must renew it when the service changes, when an authority asks, or at least every five years. It is paperwork, not a wave-through. And enforcement is deliberately decentralized: the directive fixes no fine amounts, it requires member states to set penalties that are "effective, proportionate and dissuasive". Germany's transposition, the BFSG, sets fines up to EUR 100,000 for offering a non-conforming service. Products carry CE marking; services do not get a mark at all, they get market surveillance.

Our position

Treat WCAG 2.2 AA as the spec now, not when the Official Journal catches up. The functional requirements already bind, the harmonised standard heading to citation points at the same target, and retrofitting accessibility onto a finished product always costs more than scoping it at the start.

Three line items go in every scope we write for a consumer-facing product: accessibility criteria in the definition of done, an accessibility statement in the product's legal pages describing how it meets the requirements (Article 13 plus Annex V, in substance), and a channel for accessibility reports that reaches a human. On the consumer products we build and run ourselves, like CashTaq, that is how the checklist reads. If your product is genuinely B2B-only this law may not reach you, but that is a scoping fact to verify, not an assumption to make, and the same criteria are what enterprise procurement asks for anyway.

The takeaway

The whole obligation for a service provider fits on one card. Run yours against it.

If any SCOPE line describes your product, the work is not optional and has not been for over a year. Building accessibility in from the start is what our design and development work scopes for by default. If you want a read on where your site or app stands against the card, send us the link.

← the journal