The question arrives in a procurement questionnaire from a retailer in Rotterdam, row 47, between the SOC 2 question and the data-residency one: "Is your product compliant with the European Accessibility Act? Yes / No / Partially." The CTO reading it runs a B2B platform from Austin. Nobody on the team has read the Directive, and there are three vendor webinars in the inbox saying the answer had better be yes.
The webinars are too broad about the European Accessibility Act, and the people ignoring it are too casual. The text is narrower than the webinars: it lists specific consumer services, and a B2B SaaS product isn't one of them. It's also stricter than the people ignoring it assume, because its escape hatches are paperwork, not exits.
The European Accessibility Act is Directive (EU) 2019/882 of 17 April 2019 "on the accessibility requirements for products and services" [R1]. It sets common accessibility requirements for a closed list of products and consumer services, and Member States have had to apply them since 28 June 2025 [R2] [R3] [R4].
What follows is a reading of the published text, not legal advice. Where a conclusion is mine rather than the Directive's, I say so.
Key takeaways
The European Accessibility Act is an EU directive that has applied since 28 June 2025. It requires listed consumer-facing products and services to meet common accessibility requirements, and it covers non-EU businesses that offer those services to consumers in the Union [R2] [R3] [R7].
The dates are two separate paragraphs, and people mix them up. Article 31(1) gave Member States until 28 June 2022 to "adopt and publish" their national laws; Article 31(2) says "They shall apply those measures from 28 June 2025" [R2]. Because it's a directive, the obligation you actually face is your target country's transposing law, not the Directive itself. Read the Directive to learn the shape. Read the national law before you sign anything.
Where your company is incorporated doesn't matter. A "service provider" is "any natural or legal person who provides a service on the Union market or makes offers to provide such a service to consumers in the Union" [R7]. An Austin company running a checkout for Dutch shoppers is a service provider. The same Austin company selling a warehouse-management tool to a Dutch retailer, on the Directive's own terms, may not be. That's the next section.
The Directive covers two lists, and neither of them is "digital products".
Products placed on the market after 28 June 2025: consumer general-purpose computers and their operating systems; payment terminals, ATMs, ticketing machines, check-in machines and interactive information kiosks; consumer terminal equipment used for electronic communications or for accessing audiovisual media; and e-readers [R4]. If you make hardware or an operating system, that's you. Application software isn't on this list.
Services "provided to consumers after 28 June 2025" [R3]:
| Article 2(2) | Service |
|---|---|
| (a) | Electronic communications services (excluding machine-to-machine transmission) |
| (b) | Services providing access to audiovisual media services |
| (c) | Air, bus, rail and waterborne passenger transport: websites, mobile apps, electronic tickets and ticketing, travel information, interactive kiosks |
| (d) | Consumer banking services |
| (e) | E-books and dedicated software |
| (f) | E-commerce services |
Two definitions decide whether your software is in or out.
"Consumer" means "any natural person who purchases the relevant product or is a recipient of the relevant service for purposes which are outside his trade, business, craft or profession" [R5]. And "e-commerce services" means "services provided at a distance, through websites and mobile device-based services by electronic means and at the individual request of a consumer with a view to concluding a consumer contract" [R6].
Read those together and the e-commerce hook is specific. It isn't "has a website" or "takes payments". It's a service that lets a consumer conclude a consumer contract at a distance.
Does the European Accessibility Act apply to B2B SaaS? Not directly, on the text. A platform sold to businesses, used by employees at work, is not a service provided to consumers, and it isn't on the Article 2(2) list [R3] [R5]. Say that to the procurement team plainly, because it's true.
But it's not the whole answer, and this part is my reading rather than anything the Directive says. If your product is the storefront, checkout, booking flow or banking front end that your customer puts in front of consumers, your customer is the service provider with the obligation, and your code is where that obligation lands. They can't meet the requirement without you, so row 47 is how it reaches you: through contracts and questionnaires, not through the Directive. "We're B2B, it doesn't apply" is correct as law and useless as a sales answer.
Five content types sit outside the Directive even for in-scope services: pre-recorded video and office documents published before 28 June 2025, third-party content "neither funded, developed by, or under the control of" the operator, and archives not updated after that date [R19]. The marketplace listings your sellers upload may fall under the third-party carve-out. Your own product pages don't.
This is the claim that gets compressed into something false. The version you'll hear is "small companies are exempt". The text says something narrower.
A microenterprise "employs fewer than 10 persons and … has an annual turnover not exceeding EUR 2 million or an annual balance sheet total not exceeding EUR 2 million" [R8]. Headcount under ten and one of the two financial ceilings.
The exemption itself, Article 4(5): "Microenterprises providing services shall be exempt from complying with the accessibility requirements referred to in paragraph 3 of this Article and any obligations relating to the compliance with those requirements." [R9] Paragraph 3 is the services paragraph.
Microenterprises dealing with products get something much smaller. Under Article 14(4) they're only "exempted from the requirement to document their assessment", and a market surveillance authority can still ask them for "the facts relevant to the assessment" [R10]. The recitals spell out the asymmetry: requirements "should therefore not apply to microenterprises providing services", while for microenterprises dealing with products they "should be lighter in order to reduce the administrative burden" [R11]. Lighter, not absent.
And the thresholds are policed. To benefit, microenterprises "must genuinely fulfil the requirements of Commission Recommendation 2003/361/EC … and the relevant case law, aimed at preventing the circumvention of its rules" [R12]. Splitting a 40-person company into four entities is the obvious move, and recital 53 is aimed at exactly that.
Two practical consequences. A nine-person startup running an e-commerce service in the EU is exempt from the service requirements. A nine-person startup that has just closed a round and hired its eleventh engineer isn't, and nothing in the Directive tells it the day that happens. Put the headcount check in the same place you track your other size-triggered obligations.
The Directive's requirements for services are written as outcomes, not as a checklist, and it helps to see the actual words.
For in-scope services generally, websites and apps must be made "accessible in a consistent and adequate way by making them perceivable, operable, understandable and robust" [R20]. The same annex asks for information presented "using sufficient contrast, as well as adjustable spacing between letters, lines and paragraphs" [R20]. Those four words, perceivable, operable, understandable, robust, are the "four principles of accessibility of websites and mobile applications" the Directive takes from the public-sector web directive [R37].
Some services get extra, specific duties. E-commerce services must provide accessibility information about the products being sold where the responsible operator supplies it, and must make "the functionality for identification, security and payment" perceivable, operable, understandable and robust [R21]. In checkout terms: the login, the fraud check and the pay button. Consumer banking information must not exceed "level B2 (upper intermediate)" of the Common European Framework of Reference for Languages [R21]. That one's a copywriting requirement, not an engineering one, and it's in the law.
Article 13(2) requires service providers to "prepare the necessary information in accordance with Annex V and … explain how the services meet the applicable accessibility requirements", made available "in written and oral format, including in a manner which is accessible to persons with disabilities" [R22]. Annex V says where it goes: "in the general terms and conditions, or equivalent document" [R22].
So conformance isn't only a property of the UI. It's also a published statement of how the UI conforms, in your terms, and it has to be kept current. Article 13(3) requires "procedures … in place so that the provision of services remains in conformity", and Article 13(4) says that where a service isn't compliant, providers "shall immediately inform the competent national authorities" [R23]. A one-off remediation project doesn't satisfy a duty to stay in conformity. That's a release process.
Search the Directive's text for "WCAG" or "EN 301 549" and you get nothing [R24]. What it has instead is Article 15(1): services that conform to "harmonised standards or parts thereof the references of which have been published in the Official Journal" are "presumed to be in conformity" [R24].
The standard you'll see cited is EN 301 549 v3.2.1. Be precise about its status. The Commission published its reference under Implementing Decision (EU) 2021/1339, which ties it to Directive (EU) 2016/2102, the web accessibility directive for public-sector bodies, not to the EAA [R26]. In the Publications Office records I queried, I could not find a decision publishing a harmonised standard under the EAA itself; check that before you rely on it, because it's the kind of thing that changes.
What EN 301 549 gives you in practice is a concrete target: "Conformance with W3C Web Content Accessibility Guidelines (WCAG 2.1) [5] Level AA is equivalent to conforming with all of clauses 9.1 to 9.4 and the conformance requirements of clause 9.6" [R27]. WCAG 2.1 AA is the sensible engineering yardstick for the European Accessibility Act, but on the evidence I found it is a yardstick, not a legal safe harbour.
Article 14 is where "we'll just say it's too expensive" goes to die.
The defence is real. The accessibility requirements apply "only to the extent that compliance" does not fundamentally alter a service's "basic nature" and does not impose "a disproportionate burden on the economic operators concerned" [R13]. But claiming it is a process with four parts.
And one condition that can remove the option entirely: if you receive outside funding "provided for the purpose of improving accessibility", you can't rely on the disproportionate-burden limb at all [R15].
Annex VI is where it gets uncomfortable. The criteria are ratios: net compliance costs against your overall operating and capital costs of providing the service; estimated costs and benefits "in relation to the estimated benefit for persons with disabilities, taking into account the amount and frequency of use"; and net compliance costs against net turnover [R16]. The listed cost elements include "additional human resources with accessibility expertise", "the design of the accessibility features" and "testing the product or service for accessibility" [R16].
Notice what that means. You can't write an honest Annex VI assessment without first knowing what's broken and what fixing it costs. The disproportionate-burden defence doesn't let you skip the audit; it requires one. "Our checkout fails 40 checks and fixing them is two engineer-weeks" is a burden assessment. "Accessibility is expensive" is not.
The date that circulates as "you have until 2030" is Article 32(1). Here it is in full:
"Member States shall provide for a transitional period ending on 28 June 2030 during which service providers may continue to provide their services using products which were lawfully used by them to provide similar services before that date. Service contracts agreed before 28 June 2025 may continue without alteration until they expire, but no longer than five years from that date." [R17]
Two things are protected: products a service provider was already using to deliver the service, and service contracts agreed before 28 June 2025, capped at five years. Self-service terminals can, at a Member State's option, run longer, up to 20 years after entering use [R18].
What it doesn't say is that services get until 2030. The service obligation in Article 2(2) runs from 28 June 2025 [R3]. The Directive defines "product" as "a substance, preparation, or good produced through a manufacturing process" [R4], and the product list in Article 2(1) is hardware, terminals and operating systems [R4]. My reading, and it is only that: the 2030 transitional covers the ATM in the branch and the kiosk in the station, not the checkout you redeployed last Tuesday. If someone is relying on 2030 for a website or app, ask them which clause, and get a lawyer to confirm it for your Member State.
If you've never measured your product, the base rate isn't encouraging.
WebAIM has now run its automated evaluation of the home pages of the top 1,000,000 websites for the eighth consecutive year, using the WAVE engine; the 2026 results are from February 2026 [R28]. The headline: "95.9% of home pages had detected WCAG 2 failures", up from 94.8% in 2025, "reversing a trend of small improvements each of the previous 6 years" [R30]. Across the million pages, WebAIM detected 56,114,377 distinct errors, "an average of 56.1 errors per page", up 10.1% from 51 errors per page in 2025 [R31].
The failures are boring, which is the useful part. Low-contrast text was detected on 83.9% of the million home pages, missing image alt text on 53.1%, missing form labels on 51%, empty links on 46.3%, empty buttons on 30.6%, and missing document language on 13.5% [R32]. "96% of all errors detected fall into these six categories", and they "have been the same for the last 7 years" [R32]. None of those needs a specialist to find. All of them need someone whose job it is to fix them.
The category closest to the Directive's e-commerce hook is near the bottom. WebAIM's Shopping category, second-worst of its 29 categories, 95,039 home pages, averaged 71.0 detected errors, 26.6% worse than the 56.1 average; Travel, 128,711 pages, averaged 61.9, 10.4% worse; Personal Finance, 33,383 pages, averaged 45.4, 19.0% better [R33]. (WebAIM notes its categories were assigned using AWS Bedrock, so treat the boundaries as approximate.) By platform, Shopify home pages averaged 75.1 errors across 42,516 pages, 33.9% worse than average [R34].
WebAIM's own explanation for the reversal is growing page complexity, with the average home page now at 1,437 elements, 14.3% more than a year earlier, and it suggests the trend "likely reflect[s] broader shifts in web development including increased reliance on 3rd party frameworks and libraries and automated or AI-assisted coding practices ('vibe coding')" [R35]. That's WebAIM's hypothesis, not a measured finding, but it matches what happens when an MVP looks done and isn't.
Now the limit, and WebAIM states it first. "All automated tools, including WAVE, have limitations—not all conformance failures can be automatically detected. Absence of detected errors does not indicate that a page is accessible or conformant." [R29] Which is why its own conclusion is phrased as a ceiling: full WCAG 2 A/AA conformance "was certainly lower than 4.1%" [R30]. These are home pages, not checkouts, measured against WCAG 2.2 A/AA [R36]. An automated scan tells you where you're certainly failing. It can't tell you that you pass, and it's exactly why the manual-versus-automated split matters more here than almost anywhere.
There's a respectable argument for a B2B software company to close the tab here, and it deserves a straight hearing.
It's out of scope. For a product sold to businesses and used at work, the text supports that: the service list is closed and the services must be provided to consumers [R3] [R5]. A lawyer who tells you the EAA doesn't apply to your HR platform may well be right.
Enforcement is national. The Directive leaves enforcement mechanics and penalties to Member States, requiring only that penalties be "effective, proportionate and dissuasive" [R25]. I haven't seen data on enforcement actions to date, and this post doesn't claim any. If you want to wait for the first cases, the text doesn't stop you.
There's a defence built in. Article 14 exists precisely so that compliance isn't unlimited [R13].
Each is true, and each has a catch. Out of scope for the Directive doesn't mean out of scope for your customers. And Article 29 requires Member States to let consumers act under national law, and to let "private associations, organisations or other legal entities which have a legitimate interest" engage on a complainant's behalf or in support of them [R25]. Waiting for enforcement is a bet on the least predictable part of the regime. And the Article 14 defence, as the previous sections showed, can only be claimed by someone who has already measured the gap and written it down [R14] [R16].
The honest version of "do nothing" is "decide, in writing, that we're out of scope, and why". That's cheap, and it's the same document you'd want if row 47 comes back with a follow-up question. The CRA Article 14 post makes the same move for a different regulation: settle whether you're in scope before arguing about what's required.
Five steps, in order. The first two are free.
Step 3 is also where design debt stops being a style complaint and becomes a line item. Contrast, labels and focus order are design-system problems before they are code problems.
The cheap first move is a conformance check against WCAG 2.1 AA on the consumer journeys the Directive actually names, and UX On Demand lists exactly that brief, "Bring the app to AA": contrast, focus order, semantics and labels, as an audit with fixes designers and developers can action, on a $3,495/mo single stream with a 3-day task cycle and cancel any time. The fixes then ship as ordinary briefs, and QA On Demand re-verifies them across browsers and devices in regression so the next release doesn't quietly undo them. An audit isn't a legal opinion or a certificate of conformity; it's a list of what's broken and what fixing it takes, which is also the evidence an Annex VI assessment needs.
So before you answer row 47: can anyone at your company say, today, which of your screens a consumer in the EU uses to conclude a contract, and whether a keyboard alone can get them through it?
Yes, if they provide an in-scope service to consumers in the EU. The Directive 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", with no requirement to be established in the EU [R7]. Whether a US company is caught depends on what it provides, not where it's incorporated: the services must be on the Article 2(2) list, such as e-commerce or consumer banking, and must be provided to consumers [R3].
Not directly, on the text. The Directive's services list is closed and covers services "provided to consumers", and a consumer is a natural person acting "outside his trade, business, craft or profession" [R3] [R5]. A platform sold to businesses and used at work isn't on the list. However, if your software powers a consumer-facing checkout, booking or banking journey for an in-scope customer, that customer carries the obligation and will expect your product to help meet it, which in practice reaches you through contracts (that last point is my reading, not the Directive's).
Only microenterprises providing services. Article 4(5) exempts "Microenterprises providing services" from the service accessibility requirements, where a microenterprise has fewer than 10 staff and annual turnover or balance sheet total not exceeding EUR 2 million [R8] [R9]. Microenterprises dealing with products are not exempt from the requirements; they're only excused from documenting a disproportionate-burden assessment [R10]. The size thresholds must be "genuinely" met under Recommendation 2003/361/EC, which is designed to prevent circumvention [R12].
Probably not for a website or app. Article 32(1) sets a transitional period to 28 June 2030 during which service providers may keep using "products which were lawfully used by them to provide similar services before that date", and lets service contracts agreed before 28 June 2025 continue for up to five years [R17]. The service obligations themselves apply to services provided to consumers after 28 June 2025 [R3]. Whether a given piece of software counts as a transitional "product" is a legal question for your Member State.
The Directive doesn't name WCAG or any specific standard; it gives a presumption of conformity to harmonised standards whose references are published in the Official Journal [R24]. EN 301 549 v3.2.1, which treats WCAG 2.1 Level AA as equivalent to its web clauses 9.1 to 9.4 plus 9.6, is referenced under the separate public-sector web accessibility directive [R26] [R27]. WCAG 2.1 AA is therefore the practical engineering target, but check whether a harmonised standard has been published under the EAA before treating it as a safe harbour.
You can rely on it only after a documented assessment against the Annex VI criteria, which compare net compliance costs with your operating costs and turnover and weigh them against the benefit to disabled users [R14] [R16]. The assessment must be kept for five years, renewed when the service changes and at least every five years, and notified to the authority unless you're a microenterprise [R14] [R15]. If you receive outside funding for improving accessibility, the defence isn't available [R15].
