The European Accessibility Act for B2B SaaS: what changed, what to ship, and how to audit

Key takeaways

• The European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025 (EUR-Lex). It targets consumer-facing products and services, so whether it touches your B2B SaaS depends on the specifics.
• The legal floor is WCAG 2.1 Level AA via EN 301 549, but the current W3C standard is WCAG 2.2, published October 2023 (W3C). Ship to 2.2 AA and the gap disappears.
• Automated tools are necessary but not sufficient. Deque's study found automated testing detects about 57% of issues (Deque); the rest needs human judgment.
• The baseline is poor everywhere: 94.8% of the top million home pages had detectable WCAG failures in 2025, averaging 51 per page (WebAIM, 2025). Fixing yours is a differentiator, not just compliance.

TL;DR

The European Accessibility Act became applicable on 28 June 2025, and it's aimed at consumer-facing digital products and services. Whether it reaches your B2B SaaS is genuinely fact-specific: a closed internal tool with no consumer-facing surface is likely out of scope, but a public sign-up, an e-commerce checkout, or any consumer use can pull you in, and the details vary by member state. The technical bar is WCAG 2.1 AA (via the EN 301 549 standard), though the current W3C version is 2.2, so build to 2.2 AA and stop worrying about the gap. Audit with automated tools plus real keyboard and screen-reader testing, because automation catches only about half the problems. This is a lawyer-adjacent topic; treat what follows as an engineering playbook, not legal advice.

What actually changed on 28 June 2025?

The EAA's compliance date arrived, turning years of "coming soon" into "in effect." Directive (EU) 2019/882, the European Accessibility Act, sets accessibility requirements for a defined set of products and services and applies from 28 June 2025 (EUR-Lex). It's the EU's move to harmonize a patchwork of national rules into one baseline, and the motivation is large: around 87 million people in the EU have some form of disability (European Commission).

Crucially, the Act is scoped to consumer-facing things. Its in-scope service list includes consumer banking, e-books, e-commerce, telephony, and access to audiovisual media services; its product list covers computers, smartphones, payment and self-service terminals, and e-readers (EUR-Lex summary). If your product sells to and is used by consumers, the deadline has already passed. The harder question for B2B SaaS is whether "consumer-facing" describes you at all.

Does the EAA actually apply to your B2B SaaS?

Maybe, and the honest answer is that it depends on whether any part of your product faces consumers. This is the section people want a clean yes/no for, and there isn't one. The Act targets products and services for consumers, so a genuinely closed B2B tool, one with no consumer-facing interface, that's sold and used strictly business-to-business, is likely outside its core scope. But that line is thinner than it looks, and getting it wrong is expensive.

Three things commonly pull a "B2B" product into scope. First, any consumer-accessible surface: a public marketing site with a sign-up, a checkout, or a self-service portal an individual could use. Second, e-commerce specifically, which is named in the directive, so if you sell online in a way consumers can reach, that matters. Third, member-state transposition: because this is an EU directive, each country writes it into national law and can vary the details and penalties, so "am I in scope" can have different answers in different markets. There is one clear carve-out: microenterprises providing services are exempt, defined as fewer than 10 people and annual turnover or balance sheet of €2 million or less (EUR-Lex). Note that's for services and doesn't extend to products.

So treat scope as a legal question to confirm, not a box to self-tick. The pragmatic move: if any consumer could plausibly reach an interface you ship, assume you're in scope, get a proper legal read for your specific markets, and build accessibly regardless. Which brings us to the part engineering actually controls.

What standard do you have to meet, and what's the WCAG 2.2 gap?

The legal reference is WCAG 2.1 Level AA, but the current best-practice standard is WCAG 2.2, and the smart move is to build to 2.2. Europe's accessibility requirements are expressed through the standard EN 301 549, which incorporates the Web Content Accessibility Guidelines at Level AA. EN 301 549's web chapter tracks WCAG 2.1 AA. Meanwhile, WCAG 2.2 became a W3C Recommendation on 5 October 2023, adding nine new success criteria over 2.1, and W3C encourages using the latest version (W3C). That's the gap: the legal floor references 2.1, while the living standard is 2.2.

For engineers, WCAG is organized under four principles, remembered as POUR: Perceivable, Operable, Understandable, and Robust, across three conformance levels, A, AA, and AAA (W3C). AA is the target that matters. The practical guidance is simple: build to WCAG 2.2 AA. The 2.2 additions, like better focus-appearance and target-size requirements, are things you'd want anyway, and meeting 2.2 AA means you comfortably clear the 2.1 AA legal floor with future-proofing built in. Chasing the exact minimum is false economy when the delta is small and improving.

How do you audit conformance without fooling yourself?

Run automated tools for coverage, then test with a keyboard and a screen reader for everything automation can't see, because that's most of the hard stuff. Automated scanners are essential and fast, but they have a ceiling. Deque's large study, across more than 13,000 page states, found automated testing detected about 57% of accessibility issues, leaving roughly 43% that require human judgment (Deque). A commonly cited older industry baseline put automatic detection even lower, around 20 to 30%. Either way, a green automated report is a floor, not a pass.

That the baseline is bad industry-wide should motivate you rather than comfort you: 94.8% of the top million home pages had detectable WCAG failures in 2025, averaging 51 errors each (WebAIM, 2025). Here's a workable audit loop:

1. Automated scan. Run axe (via axe-core, Lighthouse, or your test suite) across key flows. Fix everything it flags; it's the cheap 57%.
2. Keyboard-only pass. Unplug the mouse. Tab through every flow. Can you reach and operate everything? Is focus visible and in a sensible order? Are there keyboard traps?
3. Screen-reader pass. Navigate a critical flow with a screen reader (VoiceOver, NVDA). Are controls announced with meaningful names? Do errors get announced?
4. Contrast and zoom. Check color contrast and that the layout survives 200% zoom and reflow.
5. Document conformance. Record what you tested and any known gaps. The EAA framework expects providers to be able to demonstrate conformance, not just assert it.

What should you actually ship in a React app?

Fix the handful of issues that account for most real failures, most of which are about semantics and focus, not exotic ARIA. Component-based React apps fail accessibility in predictable ways, and the high-leverage fixes are unglamorous:

• Use semantic HTML first. A real <button>, <a>, <label>, and heading structure get you keyboard operability and correct announcement for free. A <div onClick> gets you a bug. Reach for ARIA only to fill gaps semantics can't, not as a default.
• Give every control an accessible name. Icon-only buttons need a label; inputs need an associated <label>. This is the single most common category of failure in the wild.
• Manage focus in the SPA. Route changes, modals, and dynamically revealed content need deliberate focus handling: move focus to the new content or dialog, trap it in modals, and return it on close. React's client-side routing breaks the browser's default focus behavior, so you own it now.
• Make focus visible. Don't remove focus outlines; style them. WCAG 2.2 tightened focus-appearance expectations specifically because so many apps hide it.
• Announce dynamic changes and errors. Use live regions for async updates and tie form-validation messages to their fields so a screen reader announces them.
• Meet contrast and target size. Verify text contrast, and give interactive targets enough size, another WCAG 2.2 emphasis.

None of that requires a rewrite. It requires treating accessibility as part of component definition-of-done, the same way you treat a component not shipping without its states handled.

What are the penalties, and how is this being enforced?

Penalties exist but are set nationally, and real-world enforcement was still ramping up through 2025. The directive itself doesn't fix penalty amounts; like most EU directives, it leaves penalties and enforcement to each member state's national law (EUR-Lex). That means the consequences of non-conformance, and the appetite to pursue them, genuinely vary by country. Because the Act only became applicable on 28 June 2025, mature enforcement case data was thin as of mid-2025; anyone quoting a precise EAA lawsuit count so soon should be treated with suspicion.

That doesn't make it safe to ignore. Beyond fines, the real levers are market access and procurement: enterprise and public-sector buyers increasingly require an accessibility conformance statement, and "we're not accessible" quietly loses deals long before any regulator calls. Given the baseline failure rates, shipping an accessible product is a competitive edge, not just a compliance chore.

What we got wrong: On a React app we once "added accessibility" late by layering ARIA roles onto a tree of clickable <div>s, trying to bolt semantics onto markup that had none. It was fragile, verbose, and still failed keyboard testing, because ARIA describes elements, it doesn't make a div focusable or operable. We eventually ripped the ARIA back out and rebuilt the interactive pieces on real semantic elements and proper focus management. It was less code and it actually worked. The lesson stuck: accessibility is a property of how you build components, not a layer you spray on at the end.

An EAA readiness checklist for B2B SaaS

Work through this before you conclude you're either done or exempt.

1. Scope: confirm with legal counsel whether the EAA applies to your product in each EU market you serve; don't self-certify a "we're B2B" exemption.
2. Target: build to WCAG 2.2 AA (which clears the 2.1 AA legal floor).
3. Automated: integrate axe or equivalent into CI; fix all findings.
4. Manual: keyboard-only and screen-reader passes on every critical flow.
5. React specifics: semantic HTML, accessible names, SPA focus management, visible focus, announced errors, contrast and target size.
6. Documentation: maintain a conformance statement you can hand a buyer or regulator.
7. Process: add accessibility to definition-of-done so you don't regress.

Frequently asked questions

Is my B2B-only SaaS exempt from the European Accessibility Act?

Possibly, but don't assume it. The EAA targets consumer-facing products and services, so a strictly closed B2B tool with no consumer interface is likely outside its core scope, while a public sign-up, checkout, or any consumer use can bring you in (EUR-Lex summary). Scope also varies by member-state transposition. Confirm it with legal counsel for your specific markets rather than self-certifying.

Does the EAA require WCAG 2.1 or WCAG 2.2?

The legal reference standard, EN 301 549, incorporates WCAG 2.1 Level AA, but WCAG 2.2 has been the current W3C Recommendation since October 2023 (W3C). Building to 2.2 AA satisfies the 2.1 AA floor and future-proofs you, so target 2.2 AA rather than chasing the exact minimum.

Can I just run an automated accessibility scanner and call it done?

No. Automated tools catch roughly 57% of issues in Deque's study, leaving about 43% that need human review (Deque). A passing automated scan is necessary but not sufficient; add keyboard-only and screen-reader testing to catch what automation can't.

What are the penalties for non-compliance?

They're set by each member state, not by the directive itself, so they vary across the EU (EUR-Lex). Enforcement was still maturing after the June 2025 application date. In practice the bigger near-term risk for B2B vendors is commercial: buyers increasingly require an accessibility conformance statement before they'll purchase.

Accessibility is table stakes now, so build it in

The European Accessibility Act turned accessibility from a nice-to-have into a market requirement, and the deadline is behind us. For B2B SaaS the first job is honest scoping: confirm whether it applies to you rather than assuming a B2B pass. The second job is entirely in your control: build to WCAG 2.2 AA, audit with tools plus real keyboard and screen-reader testing, and treat semantic, focus-aware components as definition-of-done. With 94.8% of sites failing basic checks, doing this well isn't just compliance, it's a way to stand out to every buyer who has started asking.

If you need your product audited against WCAG 2.2 AA, or your React components rebuilt to pass a real keyboard and screen-reader test rather than just an automated scan, that's exactly the kind of work we take on with clients.