Skip to content
wcagc
←Back to blog
EAASaaSB2BEN 301 549accessibility-statement

EAA compliance for SaaS and B2B software

Does the EAA apply to your SaaS or B2B software? What's in scope, what's exempt, and how to check and document your product.

P

Pavel Charkasau

EAA compliance for SaaS depends on one question: does a consumer ever use your product? The European Accessibility Act is written around the consumer, defined as a person acting outside their trade or profession (Directive (EU) 2019/882, Article 3). A product used only by other businesses, through interfaces that only professionals ever touch, sits outside the Act's service obligations. But most software sold as "B2B" is not that pure. If members of the public can sign up, buy a plan, read a help center, or reach a customer-facing screen your software renders, those parts are in scope, and the standard is WCAG 2.1 Level AA through EN 301 549.

So treat "are we B2B?" as the wrong first question. The right one is: which surfaces does a consumer reach, and can those surfaces be used with a keyboard and a screen reader? An automated scan finds the machine-detectable issues on those pages quickly. Keyboard operation, focus order, and screen-reader output need a person. No plugin makes a SaaS product conformant on its own.

Here is how to work out what applies to you and what to do about it.

Does the European Accessibility Act apply to SaaS and B2B software?

It depends on who uses the product, not on how you label it. The EAA is Directive (EU) 2019/882, in force across member states since 28 June 2025 (European Commission). It covers a defined set of consumer services: electronic communications, access to audiovisual media, certain transport services, consumer banking, e-books, and e-commerce (Article 2). E-commerce is defined broadly, as services provided at a distance through a website or mobile app, at the individual request of a consumer, to conclude a consumer contract (Article 3(30)).

That definition is where most SaaS gets caught. A self-serve product with a public pricing page, an online sign-up, and card checkout is concluding a contract with whoever completes it. When some of those people are consumers, buying a plan for personal use rather than for a business, the transaction and the interfaces around it fall under the e-commerce provisions.

A genuinely closed B2B tool is different. If your interfaces are only ever reached by users acting in a professional capacity, through contracts negotiated with companies and accounts provisioned by an administrator, the consumer definition is not met and the Act's service duties do not bite. The practical test is not the sales motion. It is whether a member of the public can arrive at, and operate, any part of what you ship.

Two more things narrow or widen the picture:

  • The microenterprise carve-out is narrow. A microenterprise providing a service, fewer than 10 people and turnover or balance sheet total of €2 million or less, is exempt from the service accessibility requirements (Article 4(5) and Article 3(23)). Both conditions must hold. A funded SaaS company almost always sits above that line.
  • Location does not exempt you. The Act follows the EU market, not the vendor's address. A US or UK company offering an in-scope service to consumers in the EU is covered.

Which parts of a B2B SaaS product are actually in scope?

Split the product into surfaces and judge each one. Most "B2B" SaaS is a mix, and the mix is where the real answer lives.

Public and consumer-reachable surfaces (usually in scope). The marketing site, the pricing page, the public sign-up and checkout, password reset, the help center and documentation, and any status or billing portal a member of the public can open. These behave like the e-commerce and information surfaces the EAA targets, and they are the ones a consumer touches first.

Embedded, consumer-facing output (in scope, and often contractual). If your software renders screens that your customers put in front of their own consumers, a booking widget, a checkout component, an embedded chat, a customer portal you white-label, then those screens are part of a consumer service. Even where the legal duty formally sits with your customer, they need those screens to be accessible to meet their own EAA obligations, so it lands in your contract whether or not the Act names you.

Professional-only application screens (often out of the EAA's direct scope). The authenticated admin console used only by your customer's staff, internal dashboards, back-office configuration. If no consumer ever reaches these, the EAA's consumer-service duties do not directly apply to them.

That last bucket is where "we're B2B, so we're exempt" quietly overreaches. The EAA may not reach an internal admin screen, but other obligations can. EU employment law prohibits disability discrimination at work and expects reasonable accommodation (Directive 2000/78/EC), and several member states impose their own accessibility duties on workplace and public-sector systems. An inaccessible admin tool can still be a problem for the employer who deploys it, which increasingly makes it a problem for the vendor who sold it.

What about public-sector and enterprise customers?

This is where accessibility reaches even a pure B2B product, through the contract rather than the EAA.

Public-sector buyers. EU public-sector bodies must make their websites and mobile apps accessible under the Web Accessibility Directive (Directive (EU) 2016/2102), and they meet it against EN 301 549. When a government agency procures software, that requirement flows down to what they buy. A vendor that cannot show conformance is often screened out before the demo.

Enterprise buyers. Large private buyers increasingly ask for the same thing, because they have their own EAA exposure and because accessibility has become a standard line in security and procurement reviews. The document they ask for is an accessibility conformance report, a clause-by-clause account of how the product measures against the standard. EN 301 549 Annex C provides the format, recording each applicable requirement as met, partially met, or not met.

So the honest answer for many B2B vendors is: the EAA may not name you, but your customers' obligations reach you anyway. Building against WCAG 2.1 AA and keeping a current conformance report is faster to do ahead of a deal than during one.

What accessibility standard does a SaaS product need to meet?

WCAG 2.1 Level AA, for the surfaces in scope. The EAA states the goal, that a service be perceivable, operable, understandable, and robust, but it does not list the technical checks. For those it relies on the harmonized standard EN 301 549, and meeting the relevant parts gives a presumption of conformity with the law.

The version cited today, EN 301 549 v3.2.1, incorporates WCAG 2.1 Level AA for web content (ETSI). For a web app that means the familiar things done correctly: every control reachable and operable by keyboard, a visible focus indicator, form fields with real labels, sufficient contrast, status messages announced to assistive technology, and no keyboard traps in modals or menus. A v4.1.1 update referencing WCAG 2.2 is expected, but until it is formally cited in the Official Journal, 2.1 AA is the legal bar. Targeting 2.1 AA now, while keeping an eye on the 2.2 additions such as focus appearance and target size, keeps the eventual switch small.

How do I check and document my SaaS product's accessibility?

Work in two layers, because neither covers the job alone.

Layer one: automated testing. Run your in-scope surfaces through a scanner built on a real rules engine, not a single home-page check. For SaaS that means the marketing and pricing pages, sign-up and checkout, and the main authenticated flows a user repeats every day. This clears the high-frequency, machine-detectable defects fast: missing labels, low contrast, missing page language, duplicate IDs, and basic ARIA mistakes. Single-page apps need particular care, because state changes after load, and a scanner has to test the rendered view, not just the initial HTML.

Layer two: manual review. A person checks what a machine cannot judge. Can you complete sign-up, and the core task, with the keyboard alone? Does focus land somewhere sensible when a dialog opens, and return when it closes? Does a screen reader announce validation errors and a busy state? Is a custom dropdown or data grid actually operable, or only clickable?

How much does each layer catch? Deque's analysis of more than 2,000 audits found automated testing identified about 57% of issues by volume; measured as a share of WCAG success criteria, automation lands closer to 30% (Deque, 2021). Either way, much of conformance only shows up under human review. Scan first to clear the obvious defects, then run a structured manual pass with our WCAG checklist so the rest does not slip through.

Then document it. For an in-scope service the EAA expects you to explain how it meets the accessibility requirements; enterprise and public-sector buyers will ask for the same in a conformance report. An honest accessibility statement records your conformance level, lists known limitations, gives a plan and timeline, and offers a contact for feedback. Documented effort is what the law asks for, not a perfect score, and no tool can promise the score anyway. In 2025 the US Federal Trade Commission approved a final order requiring the overlay vendor accessiBe to pay $1 million over claims that its widget could make any site WCAG compliant (FTC, April 2025). Full conformance needs human review and real fixes in your own code.

Frequently asked questions

Does the EAA apply to purely B2B software?

Not directly, if every interface is used only by people acting in a professional capacity, because the Act is built around the consumer. But most B2B SaaS has consumer-reachable surfaces, such as public sign-up, billing, or a help center, and those parts are in scope. Public-sector and enterprise contracts can also require accessibility regardless of the Act.

Is our internal admin dashboard covered by the EAA?

The EAA's consumer-service duties generally do not reach a screen only your customer's staff ever use. Employment law and some national rules can still apply to workplace tools, and buyers often require accessibility by contract, so "internal" is not the same as "exempt in practice."

Which WCAG version does a SaaS product need to meet?

The EAA points to EN 301 549 v3.2.1, which incorporates WCAG 2.1 Level AA. A v4.1.1 update referencing WCAG 2.2 is expected, but until it is formally cited in the Official Journal, 2.1 AA is the legal bar.

Do we need an accessibility statement for a SaaS product?

For an in-scope service, yes: the EAA requires you to explain how the service meets the accessibility requirements. Even where it is not strictly required, enterprise and government buyers routinely ask for a conformance report, so having one ready is practical either way.

We sell to businesses, not consumers. Can we ignore accessibility?

Rarely, in full. Even if the EAA does not name you, your business customers have their own obligations that flow into your contract, public-sector procurement expects EN 301 549 conformance, and any public sign-up or support surface you run can itself be in scope.

See where your SaaS product stands

The fastest way to turn EAA compliance for SaaS from a worry into a plan is to see your actual issues. Run a free scan of your public and sign-up surfaces to find the machine-detectable problems, then work through the manual checklist for the rest. You will know what to fix, in what order, and what to put in your conformance report.

Pavel Charkasau, founder, wcagc.com. Last updated 8 July 2026.

Sources