Back to Blog

Legal Compliance

Does the EAA Apply to Your B2B SaaS? The Honest Scope Guide (and the Grey Zones)

Most B2B SaaS is NOT in EAA scope by default — the directive targets specific consumer-facing services. But self-serve checkout, freelancer/sole-trader customers, and sector overlays can pull you in. Here's where the line actually sits.

15 May 2026

Updated 31 May 2026

12 min read

Ravid, Webply

Also in:

EN

DE

Default: most B2B SaaS is NOT in EAA scope

The European Accessibility Act (Directive 2019/882) is not horizontal accessibility law. It does not apply to every digital service. It targets a specific list of products and services set out in Annex I and Annex II of the directive.

For services — which is what SaaS companies care about — the listed categories are:

• Electronic communications services for consumers
• Access to audiovisual media services (AVMS)
• Air, bus, rail, and waterborne passenger transport services
• Consumer banking services and e-money services
• E-books and dedicated software for reading them
• E-commerce services — defined as services provided remotely, electronically, at the individual request of a consumer

That last category is the one B2B SaaS vendors usually reach for. But the directive defines "consumer" precisely: a natural person acting outside their trade, business, craft, or profession. A company signing a multi-seat enterprise licence is not a consumer. A procurement team negotiating a contract via a sales-led demo is not a consumer. The EAA "e-commerce services" category is explicitly about consumer contracting, not about the digital nature of software delivery.

A plain B2B SaaS — think Salesforce, HubSpot Enterprise, Workday, or any vertical SaaS sold sales-led to company buyers — where contracts are negotiated, signed by procurement, and onboarded by a vendor implementation team does not fit any listed category. It is out of EAA scope by default.

"Out of scope" does not mean "should not be accessible." It means the EAA enforcement framework — statements, conformance deadlines, regulatory complaints, Abmahnungen via BFSG — does not directly apply. Other obligations may still exist (see below).

The grey zones — when "B2B" SaaS gets pulled in

The word "B2B" on your marketing page does not determine your EAA scope. What matters is how contracting actually works and who your real customers are. These are the common patterns that pull a nominally B2B product into EAA scope:

1. Self-serve checkout. If a natural person can visit your pricing page, enter card details, and start a paid subscription online — without speaking to sales, without a countersigned contract — you are almost certainly providing an "e-commerce service" under the EAA's definition. The individual completing the checkout is likely acting as a consumer in that moment, regardless of what they intend to do with the product. A $20/month starter tier where freelancers, indie hackers, and sole traders are real customers is a clear example.

2. Prosumer, creator, and freelancer SaaS. Tools like Substack, Beehiiv, ConvertKit, Webflow, Carrd, Framer, and Notion (personal tier) have customer bases that are largely natural persons — even if some buy under a company name. The consumer-facing self-serve tier of these products is almost certainly EAA-covered, even if there is also a separate enterprise tier that is not.

3. Mixed-use SaaS with a single signup flow. If your signup does not distinguish between consumer and business customers, and the same online flow serves both, the consumer-facing portion drags the whole signup experience into compliance posture. A regulator examining your signup cannot cleanly separate which path was intended for whom.

4. Free-trial-to-paid flows that individuals can self-complete. Even if your marketing says "for teams," if a single individual can move from free trial to paid subscription entirely online with no human intervention from your side, that is the consumer e-commerce pattern.

5. B2B2C SaaS. Embedded checkout flows, hotel booking engines, white-label e-commerce platforms, embedded media players. Your direct customer is a business, but the end-consumer interaction is the trigger for EAA scope — and the B2B contracting layer does not shield you from it.

If any of these patterns match your product, treat yourself as in scope or get a written legal read before assuming otherwise.

Sector overlays — when industry pulls you in

Even if your product's contracting model is entirely B2B, operating in a listed sector can still bring you within EAA scope — or at minimum create contractual pressure from customers who are directly in scope.

• Consumer banking and fintech SaaS — neobanks, consumer banking platforms, BNPL providers, and payment service UIs selling into EU markets are in scope as consumer banking services.
• Transport ticketing and mobility SaaS — booking engines for air, bus, rail, and waterborne passenger transport are in scope, even if your direct customer is a transport operator rather than a traveller.
• Audiovisual media access SaaS — streaming UIs, subtitle and dubbing services, and smart-TV apps that provide access to AVMS content are in scope.
• E-books and dedicated reading software — e-reader apps, e-book stores, and dedicated reading software are in scope.
• Electronic communications services — VoIP providers, consumer messaging platforms, and telecom service software are in scope.

If your SaaS sells into one of these sectors as infrastructure — for example, you are the white-label booking engine that powers a transport operator's site — the EAA can reach you contractually. Your B2B customer is directly on the hook and will push those obligations downstream in their supplier agreements.

Why competitor Abmahnungen matter for SaaS

In Germany, the BFSG (the German EAA implementation) feeds into the unfair competition framework. A competitor can issue an Abmahnung — a cease-and-desist with legal fee demands — for EAA non-compliance. They do not need to be a disabled user or an accessibility organisation.

This mechanism has already been active since June 2025. For SaaS companies selling into the German market that are in scope, this is the most immediate risk channel. German businesses have a long history of using Abmahnungen in competitive markets (GDPR, cookie consent, price transparency) and the EAA adds a new vector. See the German fine regime for the statutory penalty ranges.

One important hedge for non-covered B2B SaaS: an Abmahnung under UWG §3a requires the underlying law to be marktverhaltensregelnd — a norm that regulates market conduct. For EAA-covered services, this characterisation is widely accepted. For B2B SaaS that is clearly out of EAA scope, the legal hook is much weaker. The Abmahnung risk does not transfer automatically just because the BFSG exists.

See our BFSG Abmahnung risk guide (in German) for the specific statutes and documented cases.

National anti-discrimination law overlay

The EAA is not the only EU accessibility law. National anti-discrimination frameworks exist independently of EAA scope and apply more broadly.

In Germany, the BGG (Behindertengleichstellungsgesetz) and AGG create obligations in specific contexts. In Austria, the BGStG (Bundes-Behindertengleichstellungsgesetz) creates civil-litigation exposure for barriers that exclude disabled persons. In France, the Loi du 11 février 2005 imposes broader non-discrimination requirements. These laws are not limited to the Annex II service categories — they apply on wider civil-rights grounds, even to organisations whose digital services are not EAA-covered.

The practical risk from national anti-discrimination law is lower than from the EAA enforcement framework: the bar for proving discrimination as a legal matter is higher than proving technical non-conformance with a harmonised standard. But it is not zero, and it is worth knowing the exposure exists independently of your EAA scope determination.

Even if not in scope, accessibility still has commercial value

If you have worked through the analysis above and concluded that your B2B SaaS is clearly not in EAA scope, that is the correct answer — and you should not sell yourself a false obligation. But accessibility still has real commercial weight for out-of-scope products:

• Public-sector contract eligibility — many EU public-sector tenders require WCAG 2.1 AA conformance from technology suppliers, regardless of whether the supplier's own product is EAA-covered. An inaccessible product can be disqualified at procurement stage.
• Employee accommodation — disabled employees of your customers need to use the product. Inaccessible SaaS creates HR and legal friction for your buyers and can become a procurement blocker, especially with larger enterprise clients who have internal accessibility policies.
• Customer reach — approximately 15% of people have a disability of some kind. Accessibility is a usability and reach play, not only a compliance one.
• ESG and procurement filters — accessibility is increasingly an ESG checkbox in enterprise procurement scoring. Being out of EAA scope today does not mean an inaccessible product will not become a deal-killer in two to three years.

Quick scope check

Before you plan a compliance project, answer these four questions honestly:

The touchpoints that matter most for SaaS

If you have determined that you are in scope — or that you want to invest in accessibility for procurement and commercial reasons — these are the areas that matter most. The sections below apply equally to in-scope SaaS facing EAA obligations and out-of-scope SaaS investing in accessibility for other reasons.

1. Login and authentication flows

Your login page is a form. If it has unlabelled inputs, relies on colour alone for error states, or breaks under keyboard-only navigation, it fails WCAG at the first user touchpoint. This is also the highest-visibility failure: it is what an enforcement officer or competitor would check first.

Common failures:

• Password field labelled visually but not programmatically (<input type="password"> with no <label> or aria-label)
• "Invalid password" error not associated with the input via aria-describedby
• "Remember me" checkbox with no accessible name
• "Sign in with Google" button that loses focus outline on click

2. Onboarding wizards and multi-step forms

Step indicators that only use colour ("step 3 of 5" shown as coloured circles with no text) violate 1.4.1 (Use of Colour). Progress bars with no text alternative violate 1.1.1. Inline validation that announces errors before the user has finished typing can violate 4.1.3 (Status Messages).

The pattern that works:

<!-- Step indicator with programmatic state, not just visual -->
<ol aria-label="Setup progress">
  <li aria-current="step">
    <span class="sr-only">Current step: </span>Domain configuration
  </li>
  <li>Team setup</li>
  <li>Billing</li>
</ol>

3. Dashboard tables and data grids

Data-heavy SaaS products frequently have complex tables — analytics dashboards, user management grids, billing history. These need:

• <th scope="col"> on column headers
• <th scope="row"> on row headers
• caption or aria-label on the table itself
• Sort controls announced as buttons with current sort state (aria-sort="ascending")
• Pagination with aria-label="Pagination" on the nav and clear current-page indication

Tables built with <div> grids instead of <table> require explicit ARIA grid roles and keyboard navigation implementation. The native element is almost always the right choice.

4. Billing and subscription management

This is the highest legal-risk area for in-scope SaaS. If a disabled employee of your customer cannot upgrade their subscription, downgrade before renewal, or access an invoice, you are blocking a commercial transaction.

Specific patterns to fix:

• Stripe Billing Portal is largely accessible out of the box — but your upgrade prompts and pricing tables may not be
• PDF invoices must be tagged PDFs (not image-only scans) — WCAG 1.1.1 applies to PDFs
• "Cancel subscription" flows that rely on hover-only menus or JS-only interactions need keyboard paths

5. Notifications and status messages

Toast notifications, alerts, and in-app banners are a systematic failure in most SaaS products. A notification that appears visually but is not announced by screen readers fails WCAG 4.1.3 (Status Messages).

The fix is simple:

<!-- ARIA live region — screen readers announce changes automatically -->
<div role="status" aria-live="polite" aria-atomic="true">
  <!-- Inject notification text here dynamically -->
</div>

<div role="alert" aria-live="assertive" aria-atomic="true">
  <!-- For urgent errors that need immediate announcement -->
</div>

Most component libraries (Mantine, Radix UI, shadcn/ui, MUI) have accessible notification components. The problem is usually custom implementations built before the team knew about aria-live.

The documentation you need

Beyond fixing the interface, if you are in EAA scope the directive requires accessibility statements — documented declarations of your compliance status, what you have tested, what gaps remain, and a contact for accessibility feedback.

For SaaS products, this typically lives at /accessibility and covers:

• Which standard you target (WCAG 2.1 AA)
• Date of last assessment and method used
• Known issues with planned remediation dates
• Feedback / contact mechanism
• Enforcement body in the relevant member state

France and Germany are already asking for this document in enforcement actions. Use our free accessibility statement generator to create a compliant one in under 5 minutes.

What a practical compliance project looks like

For a typical SaaS product determined to be in scope (5–20 core screens), here is a realistic timeline:

Week 1 — Automated audit Run an automated WCAG scanner across your core user flows. Prioritise: login, signup, main dashboard, billing, settings. This catches 60–70% of automatable issues. Fix the straightforward ones (missing labels, contrast failures, empty button names) immediately.

Week 2 — Keyboard + screen reader pass Tab through every flow from keyboard only. Use NVDA (Windows, free) or VoiceOver (macOS, built-in). This catches focus management failures, missing skip links, broken modals, and aria-live gaps that automated tools miss.

Week 3 — Fix and document Implement fixes from weeks 1–2. Write and publish your accessibility statement. Document known outstanding issues with target dates.

Ongoing — Regression prevention Add axe-core to your test suite (Playwright, Cypress, Vitest) for critical flows. One failing test per user flow is enough to catch regressions before they ship.

The bottom line for B2B SaaS teams

1. Most B2B SaaS is not in EAA scope by default. The directive targets specific consumer-facing categories. Don't sell yourself an obligation you don't have.
2. The grey zones are real. Self-serve checkout, prosumer/freelancer customers, sector overlays (banking, transport, audiovisual, e-books, telecom), and B2B2C patterns can all pull you in.
3. If you're in scope or in a grey zone, the technical work is the same. WCAG 2.1 AA, accessibility statement, ongoing regression checks.
4. If you're clearly out of scope, accessibility still matters commercially. Public-sector procurement, employee accommodation, customer reach, ESG.
5. Don't conflate microenterprise exemption with scope. Different questions. The exemption only applies after you've established you would otherwise be covered.

For country-by-country fine ranges across all 27 EU member states, see our EAA fines guide. For the most common WCAG failures to fix first, see Top 10 EAA violations and fixes.