Back to Blog

Legal Compliance

Does the European Accessibility Act Apply to Your SaaS? What B2B Software Companies Need to Know

Many B2B SaaS companies assume EAA is a B2C problem. It is not. If you sell software to EU businesses with ≥10 employees, your login page, billing portal, and admin panel are all in scope. Here is what you actually need to fix.

15 May 2026

10 min read

Ravid, Webply

Also in:

EN

DE

What the EAA actually covers

The European Accessibility Act (Directive 2019/882) lists categories of products and services in scope. Software falls under two:

"Services" — The directive defines services as activities covered by EU service law, which includes SaaS, web applications, mobile apps, and digital services sold to both businesses and consumers.

"Products" — Physical products with digital interfaces (terminals, kiosks, self-service machines) have separate obligations. Most SaaS companies care about the services track.

For services, the key obligation is: your service must meet the functional accessibility requirements in Annex I of the directive, which maps to WCAG 2.1 Level AA in practice (this is the standard that EN 301 549 references, which the EAA points to).

What is explicitly NOT in scope:

• Content on intranets used only by employees (though some member states are extending this voluntarily)
• Archived content not updated after June 2025
• Live streaming (limited obligations apply)
• Microenterprise services — but you still need to be able to prove you qualify

The touchpoints that matter most for SaaS

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 B2B 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.

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, 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.

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

The documentation you need

Beyond fixing the interface, the EAA 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 B2B SaaS product (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. You are almost certainly in scope. The microenterprise threshold is lower than most teams assume.
2. The highest-risk touchpoints are forms, tables, and notifications — areas where SaaS products have systematically poor accessibility because visual design did not consider non-visual users.
3. Germany's Abmahnung system creates immediate competitive risk, not just regulatory risk.
4. An automated audit is the right first step, not a full manual audit. Start there.
5. An accessibility statement is required documentation, not optional. Publish one before an enforcement officer asks for it.

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.