Does the EAA apply to my SaaS if my company is based outside the EU?

Yes. The European Accessibility Act follows the market, not your headquarters. If you sell a SaaS subscription to consumers in any EU member state, you are an economic operator in scope, whether you are based in the US, UK, or anywhere else. The deciding factor is where your service is offered, not where your servers or staff sit.

Is purely B2B SaaS exempt from the EAA?

Not automatically. The EAA focuses on products and services offered to consumers, but the boundary is rarely clean. If your SaaS is also sold to or used by consumers, or if it provides services explicitly listed in the directive such as banking, e-commerce, or e-books, plan for WCAG 2.2 AA conformance rather than assume a B2B carve-out. Enterprise buyers also impose accessibility terms in contracts regardless of the law.

We are a startup with six people. Are we exempt as a microenterprise?

Possibly, for the service itself. Microenterprises that provide services, meaning fewer than 10 staff and under €2,000,000 annual turnover, are largely exempt for services under the EAA. But the exemption is narrow, it disappears the moment you cross either threshold, and enterprise buyers will still ask for a VPAT or accessibility statement during procurement regardless of your headcount.

What standard do we actually have to meet?

In practice, WCAG 2.2 Level A and AA, referenced through the European harmonised standard EN 301 549. Meeting all Level A and AA success criteria gives you a strong presumption of conformity. Our [WCAG reference](/wcag) breaks each criterion down with pass and fail examples.

EAA SaaS Compliance: Scope, WCAG 2.2 AA & Auth

The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025, and it reaches more software companies than most founders expect. EAA SaaS compliance is not a niche concern for assistive-technology vendors. If your web app is sold to anyone in the EU, the question is no longer whether accessibility applies, but how much of your product is in scope and what you fix first.

This guide gets concrete. We cover which SaaS products fall under the act, the WCAG 2.2 AA baseline you are measured against, and the three areas that trip up product teams most often in real audits: authentication, status messages, and data-dense dashboards. For the regulatory backbone, see our deeper explainer on the European Accessibility Act.

Which SaaS products are actually in scope

The EAA covers products and services placed on the EU market, and it deliberately follows the customer rather than your company's location. A US-based SaaS billing EU subscribers is just as in scope as a Berlin startup. The act lists specific service categories, and a large share of SaaS touches at least one of them:

E-commerce and any product with a checkout — subscription sign-up, plan upgrades, and in-app purchases all count as e-commerce functionality.
Banking, payments, and consumer finance — consumer-facing financial services carry stricter expectations.
Telecoms and electronic communication features — chat, video, and messaging inside your app.
E-books, ticketing, and access to audiovisual media services where your SaaS delivers them.

There is one genuine carve-out worth knowing precisely. Microenterprises that provide services, meaning fewer than 10 staff and under €2,000,000 annual turnover, are largely exempt for services. The conjunction matters: cross either threshold and the exemption is gone. Even while exempt, you will still face accessibility clauses in enterprise contracts and public-sector tenders, so treating conformance as optional is a short-lived strategy.

The WCAG 2.2 AA baseline, via EN 301 549

The EAA states outcomes, not line-by-line technical rules. The bridge to concrete requirements is the European harmonised standard EN 301 549, which for web content points to WCAG 2.2 Level A and AA. Conform to every applicable A and AA success criterion and you earn a presumption of conformity.

WCAG is organised around four principles, often abbreviated POUR: content must be Perceivable, Operable, Understandable, and Robust. For SaaS interfaces, a handful of criteria do the heaviest lifting. Colour contrast requires 4.5:1 for normal text and 3:1 for large text — 18pt or 14pt bold and above (WCAG 1.4.3) — and 3:1 for UI components and meaningful graphics (WCAG 1.4.11). That last clause catches a lot of modern SaaS design: a 2:1 grey icon button or a faint focus ring on a clean white dashboard fails even when your body text passes. Run your live product through the free AccessScan scanner to flag contrast and structural issues before a manual review.

Accessible authentication: the first thing a screen reader hits

Every SaaS user passes through auth, which makes it the worst place to have a barrier. WCAG 2.2 added Accessible Authentication (3.3.8, AA), which prohibits cognitive function tests, such as transcribing a distorted CAPTCHA or solving a puzzle, unless an accessible alternative exists. Allowing the browser or a password manager to paste into the password field satisfies the requirement, so do not block paste.

Label every field with a real <label> or aria-label; placeholder text alone disappears on focus and fails for screen readers.
Expose validation errors with aria-describedby tied to the input, not just a red border, which relies on colour alone.
Make multi-factor flows keyboard-operable end to end, and never auto-advance focus between OTP digit boxes in a way that traps or skips for assistive tech.
Keep a visible focus indicator on every interactive element (WCAG 2.4.7), including custom social-login buttons.

Our accessible forms guide and keyboard accessibility guide walk through the exact markup.

Status messages and live regions

SaaS apps are full of asynchronous feedback: "Saved," "Payment failed," "3 records imported," toasts that fade after a few seconds. A sighted user sees these instantly. A screen-reader user hears nothing unless you mark them up correctly. This is WCAG 4.1.3 Status Messages (AA), one of the most commonly missed criteria in single-page apps.

The fix is an ARIA live region. Use role="status" (which maps to aria-live="polite") for confirmations and non-urgent updates, and role="alert" (aria-live="assertive") for errors that need immediate attention. The container must already exist in the DOM when the page loads; injecting a brand-new live-region node at the same moment you insert the text often means nothing is announced. Update the text content of the existing region instead. Avoid wrapping a whole results table in aria-live — announcing every cell on each filter change is far worse than silence.

Dashboards, tables, and data-dense views

Dashboards are where SaaS accessibility is won or lost, because they concentrate every hard pattern: data tables, charts, filters, drag-and-drop, and modals. Practical, high-impact moves:

Use real semantic <table> markup with <th scope> headers, not a grid of <div>s, so screen readers can navigate rows and columns.
Never encode meaning in colour alone (WCAG 1.4.1). A red-versus-green status pill needs a text label or icon too — colour-blind users and grayscale displays lose the distinction otherwise.
Give charts a text alternative: a visually-hidden summary or an accessible data table behind a toggle. Decorative chart flourishes can take empty alt text.
Ensure every control reachable by mouse is reachable by keyboard, including row-action menus, sortable column headers, and custom dropdowns.
Respect prefers-reduced-motion for auto-refreshing widgets and animated transitions.

Test by unplugging your mouse and navigating a core workflow with Tab, Enter, and arrow keys, then repeat with VoiceOver or NVDA running. The gaps surface fast.

A pragmatic path to conformance

You do not need to fix everything at once. Sequence the work by user impact: auth first, then primary workflows, then settings and admin. Pair an automated scan, which reliably catches contrast, missing labels, and structural errors, with manual keyboard and screen-reader testing for the things tooling cannot judge.

Then document what you have done. The EAA expects an accessibility statement, and enterprise buyers will request one during procurement. Work through the accessibility checklist, generate a public statement with the accessibility statement generator, and if you are weighing overlapping regimes, our ADA vs WCAG vs EAA comparison clarifies how they relate. Penalties vary by member state and can reach tens of thousands of euros, but the stronger motivation is commercial: accessible SaaS clears procurement faster and serves more of the market.

EAA SaaS Compliance: Which Web Apps Are in Scope and How to Conform