European Accessibility Act for SaaS: who is in scope and what to fix first

The European Accessibility Act applies to your SaaS if the service is provided to consumers in the EU and falls into one of the categories the directive lists, with e-commerce the one most software companies hit. A SaaS sold only to businesses is usually outside its direct scope, but its customers, and public buyers, increasingly require the same standard by contract. In both cases, the practical target is the same: WCAG 2.2 level AA, built into the product rather than bolted on.

This article reads the directive itself, not vendor summaries. Many pages on the subject claim that every SaaS reachable from Europe is covered. The text is narrower than that, and the commercial pressure is broader. Both matter for your roadmap.

The EAA in five facts

• The text: Directive (EU) 2019/882 of 17 April 2019 on accessibility requirements for products and services.
• The date: member states had to apply their national laws from 28 June 2025 (Article 31). The obligations are live.
• The method: it is a directive, so each country transposed it into its own law, with its own enforcement authority and penalties (Article 30).
• The requirements: functional requirements in Annex I, built around the four principles familiar from WCAG: perceivable, operable, understandable and robust.
• The technical reference: the harmonised European standard EN 301 549, which itself relies on WCAG for web content and software.

Is your SaaS in scope?

The services the directive lists

Article 2(2) covers a closed list of services provided to consumers:

• electronic communications services;
• services providing access to audiovisual media services;
• elements of air, bus, rail and waterborne passenger transport services (websites, mobile apps, electronic tickets, real-time travel information);
• consumer banking services;
• e-books and dedicated software;
• e-commerce services.

E-commerce services are defined in Article 3 as services provided at a distance, through websites and mobile apps, by electronic means and at the individual request of a consumer, with a view to concluding a consumer contract. In plain terms: if a consumer can buy, book or subscribe through your product, you are probably in scope.

Where your company is incorporated does not change the analysis. The test is whether the service is provided to consumers in the EU. A US, UK or Swiss SaaS selling subscriptions to European consumers is in the same position as a French one.

Common SaaS situations

Two cautions. First, scope is assessed service by service, not company by company: a B2B SaaS that adds a consumer checkout brings that part into scope. Second, national transpositions differ at the edges. If you sell in several member states, check the law and authority of each one, or ask counsel for the markets that matter most.

The microenterprise exemption

Article 4(5) exempts microenterprises providing services from the accessibility requirements. A microenterprise employs fewer than 10 people and has an annual turnover, or a balance sheet total, of no more than EUR 2 million (Article 3). Many early-stage SaaS companies qualify. Few stay there long, and the exemption disappears the year you cross the thresholds, often at the moment a large customer is evaluating you.

The transition period

Article 32 gives service providers some time: products lawfully used to deliver a service before 28 June 2025 may keep being used until 28 June 2030, and service contracts agreed before that date may continue unaltered until they expire, for at most five years. This is breathing room for existing contracts, not a pass for new features. Anything you ship or sell today should be designed to comply.

Disproportionate burden

Article 14 allows a provider to skip a requirement when it would impose a disproportionate burden or fundamentally alter the service. It is not a blanket exemption. You must document the assessment using the criteria in Annex VI, renew it periodically (recital 67 says at least every five years), keep it, and be able to show it to the authority. Lack of planning is not a burden the directive recognises.

Why B2B SaaS should care anyway

Even outside direct scope, accessibility reaches B2B products through three doors.

• Public procurement. Directive 2014/24/EU, Article 42, requires public buyers to take accessibility into account in technical specifications for anything intended for use by people. In practice, tenders ask for EN 301 549 conformance and an accessibility report.
• Contract flow-down. A bank, retailer or transport operator in scope cannot comply if the software behind its consumer journey does not. Its procurement team will put the requirement, and the liability, in your contract. Our guide to SaaS agreement clauses covers how to negotiate that kind of warranty.
• Your users' staff. Employment equality law in most countries requires reasonable accommodation for employees with disabilities. A tool that cannot be used with a screen reader becomes a problem for your customer's HR team, then for your renewal.

What the requirements mean in a SaaS product

The standard and its versions

EN 301 549 V3.2.1, harmonised in 2021, refers to WCAG 2.1 level AA for web content and software. On 2 September 2026, ETSI, CEN and CENELEC published EN 301 549 V4.1.1, the first version written with the EAA in mind, which moves the baseline to WCAG 2.2 levels A and AA, according to an analysis by Davis Wright Tremaine (September 2026). It gives a presumption of conformity only once cited in the Official Journal of the EU, which the Commission tracks on its standards page.

The practical decision is simple: target WCAG 2.2 AA now. It includes what 2.1 AA asks for, plus criteria that matter in SaaS, such as minimum target size, focus not hidden behind sticky headers, accessible authentication without memory puzzles, and no redundant entry of the same information. The W3C WCAG 2.2 page is the reference text.

Where SaaS products usually fail

Marketing sites are relatively easy. The application behind the login is where audits find most issues.

• Keyboard access in complex components: data grids, drag and drop boards, date pickers, custom dropdowns, rich text editors. Each needs a keyboard path and correct roles.
• Focus management in single-page apps: after a route change, a modal or an inline save, focus must land somewhere sensible, and return when a dialog closes.
• Forms and errors: visible labels, errors tied to their field and announced to screen readers, no information conveyed by colour alone.
• Dashboards and charts: a chart needs a text equivalent or an accessible data table, and contrast must hold for lines and legends.
• Authentication: CAPTCHAs, one-time codes with short timeouts and copy-paste blocked in password fields all create barriers.
• Time limits and live updates: session timeouts need a warning and a way to extend; notifications must be announced without stealing focus.
• Generated documents: PDF invoices, exports and reports are content too, and need structure.
• Third-party components: chat widgets, payment forms, cookie banners and video players are part of your service. Their accessibility is your problem.
• Mobile apps: EN 301 549 also covers native apps, with platform accessibility APIs to respect on iOS and Android.

What overlays cannot do

Accessibility overlays, scripts that promise compliance with one line of code, do not change how your components behave. They cannot give a data grid a keyboard model, or fix a form whose errors are not linked to its fields. The work happens in your design system and your code. That is better news than it sounds: fixing a shared button, input or dialog component once fixes it on every screen that uses it.

The documentation you must publish

Article 13 and Annex V require service providers to explain how the service meets the accessibility requirements, in their general terms and conditions or an equivalent document, available to the public in accessible form, for as long as the service operates. Most companies publish an accessibility statement: conformance level reached, known gaps and their fix dates, contact for users who meet a barrier, and the enforcement authority. For B2B sales, add a conformance report against EN 301 549, the document procurement teams ask for.

Enforcement and risk

Each member state designates market surveillance authorities that can check services, require corrective measures and, if non-compliance persists, restrict the service. Penalties are set nationally and must be "effective, proportionate and dissuasive" (Article 30). Article 29 also requires national law to let public bodies and private associations with a legitimate interest take action, which means complaints can come from users and disability organisations, not only from regulators.

For most SaaS companies, though, the first concrete consequence is commercial: a lost tender, a stalled enterprise deal, a security and compliance questionnaire that now includes an accessibility section.

A remediation plan that fits a product roadmap

Weeks 1 to 4: know where you stand

1. Map the scope: which services and journeys reach consumers, in which countries, and which customers will flow requirements down to you.
2. Audit the critical journeys: sign-up, login, purchase, the three or four screens used daily, and the documents you generate. Combine an automated scan with manual keyboard and screen reader testing.
3. Rank findings by impact: a blocker on the payment form comes before a contrast issue on a settings page.

Months 2 to 4: fix the foundations

1. Fix the shared components first: buttons, inputs, dialogs, menus, tables, notifications. One fix, many screens.
2. Add automated checks to the pipeline: an accessibility test that fails the build on serious violations stops regressions. We run axe checks in the end-to-end suite of this very website for that reason.
3. Replace or wrap problematic third-party widgets.

Ongoing: make it part of how you ship

1. Add accessibility to the definition of done and to design reviews.
2. Publish the statement and the conformance report, and update them at each major release.
3. Train the people who write content: alt text, headings, link labels and documents are written daily by non-developers.

If the product is old, built on a framework that makes keyboard and focus management hard, the audit may show that patching costs more than rebuilding the front end. Our guides on software audits before a takeover and legacy application modernization help make that call. Accessibility is also a design decision that fits naturally into an MVP scope: it costs far less to choose accessible components on day one than to retrofit them later.

Accessibility alongside your other EU obligations

The EAA rarely arrives alone. A SaaS selling in Europe also handles the GDPR, possibly the AI Act if it embeds AI features, and security requirements from enterprise customers. They overlap in practice: the same statement pages, the same procurement questionnaires, the same release process. Our GDPR checklist and our overview of the EU AI Act for business software cover the other two. For your specific situation and markets, legal advice remains necessary: this article explains the directive, it is not legal advice.

Where to start

Start with the journeys that bring in revenue and the components that appear everywhere. Measure, fix the foundations, then keep it from regressing.

If you are building a new product or rebuilding an old one, accessibility starts at the first screen. We build a free visual prototype, presented over video within 5 working days, with accessible components and contrast from the outset: you see the product, and how it behaves with a keyboard, before anything gets developed. Our comparison of prototype, MVP and proof of concept explains what that first step includes.