European Accessibility Act: Making Your SaaS Compliant Before the Enforcement Gap Closes

A Berlin-based B2B SaaS company serving mid-market retailers across the EU received a single-page email from a procurement team in early 2026. The attachment was a supplier accessibility questionnaire with sixteen questions tied to the European Accessibility Act and WCAG 2.2 level AA. The product had been in market since 2019, had a modern React/Next.js front end, and had never been through a formal accessibility audit. The CTO's first instinct was to argue the SaaS was B2B and therefore out of scope. It was not. Within three weeks the team had an accessibility statement, a remediation backlog, and a deal that had stopped moving was moving again.

This is now a repeated pattern across the EU software market. The European Accessibility Act (Directive (EU) 2019/882, known as the EAA) became enforceable on 28 June 2025, and the enterprise procurement machinery has started to catch up. Most B2B SaaS platforms still fail basic WCAG 2.2 level AA checks — missing alt text, unlabelled form inputs, keyboard traps in modal dialogs, insufficient colour contrast on bronze-on-white CTAs, focus states disabled for aesthetic reasons. The transition arrangements for products placed on the market before June 2025 run only until 2030, and every procurement cycle between now and then is a chance for a compliance gap to cost you a deal or a regulator's attention. This post is a practical guide for CTOs, product owners, and engineering leads on what European Accessibility Act compliance actually requires for B2B SaaS, how to remediate a React/Next.js codebase without derailing the roadmap, and what a defensible accessibility statement looks like in 2026.

Who the European Accessibility Act Actually Covers — Scope for SaaS

The EAA lists specific categories of products and services that fall under its obligations. On the product side that includes consumer computer hardware, self-service terminals (ATMs, ticketing machines, check-in kiosks), consumer devices used for electronic communications, and e-readers. On the services side the scope reaches electronic communications services, audiovisual media service access, elements of passenger transport, consumer banking services, e-books and dedicated software, and — the category that pulls in most SaaS — e-commerce services. E-commerce is defined broadly in the directive as "services provided at a distance, through websites and mobile-based services, by electronic means and at the individual request of a consumer, with a view to concluding a consumer contract."

The common misreading is that "consumer" means the EAA stops at B2C. In practice, any SaaS that embeds ordering flows, ticket booking, subscription checkout, booking widgets, or self-service purchase paths that can be used by consumers falls into scope, even when most customers are businesses. Banking and payment services draw the line even more aggressively. A B2B fintech SaaS that exposes consumer-facing account onboarding or statement views almost always inherits EAA obligations via its regulated clients. The same applies to platforms embedded inside banking, telecoms, or transport providers: the obligation flows down the stack as a contractual requirement, even where the directive itself does not name the vendor.

Microenterprises with fewer than ten employees and annual turnover below €2 million are exempt for services — but not for the product categories listed above, and not from the contractual demands of their customers. For everyone else, the only reliable posture is to assume in-scope for at least part of the product surface and document where exceptions apply.

What the Law Requires Beyond WCAG 2.2 Level AA

The EAA itself is functional in its language — it talks about perceivability, operability, understandability, and robustness without prescribing a specific technical standard. The harmonised standard that operationalises those requirements is EN 301 549, which in its current published version aligns tightly with WCAG 2.2 level AA for web content. If your product hits WCAG 2.2 AA, you are in the strongest defensible position under the directive. If it only hits WCAG 2.1 AA, you are close but not clean — 2.2 added nine success criteria including focus appearance, dragging movements, target size, consistent help, and redundant entry, all of which tend to be the rough edges in real React applications.

Beyond WCAG, EN 301 549 adds requirements that surprise teams who assume accessibility ends at the browser. Documentation provided with the service must itself be accessible — PDF user guides that fail tagging or heading order are a finding. Support channels must offer at least one accessible communication mode; a chat widget that is only usable by sighted mouse users is a gap. Training materials, onboarding videos, and any product embedded media need captions and, where content is primarily visual, audio description. Authoring tools — the parts of your SaaS where users create content — have their own clause: they must not only be accessible to the author but also help the author produce accessible output.

The EAA also imposes a conformity-assessment duty. In-scope services must document how they meet the accessibility requirements and make that documentation available to market surveillance authorities on request. A typed sentence in a wiki is not enough; the expected artefact is an accessibility conformance report (an ACR, often produced in the VPAT 2.x or similar format) that maps each applicable success criterion to a statement of conformance with evidence. For most SaaS teams this is the missing piece — they have tests but not a report, or a report that has not been refreshed since a major UI redesign.

Remediation in a React/Next.js Codebase — Where to Start

A full WCAG 2.2 AA audit of a medium-sized React/Next.js application will typically surface between sixty and two hundred issues. Triaging them without a method burns the engineering budget fast. The method that works is to remediate by user flow, not by issue category. A checkout flow that is fully accessible end-to-end is worth ten fixes scattered across the codebase — because EN 301 549 and WCAG both assess whether a complete task can be performed, not whether individual components pass in isolation.

Start by instrumenting the codebase with an automated first pass. eslint-plugin-jsx-a11y catches the structural mistakes at author time — missing alt attributes, interactive elements without roles, labels not associated with inputs. @axe-core/react or an equivalent runtime checker can be wired into your development build to log issues in the browser console as components render. Both have near-zero false positives on the issues they flag, and both miss the majority of real accessibility defects — they cover around a third of WCAG success criteria.

The next layer is component-level. A design system that exposes Button, Input, Modal, Tabs, Combobox, and Menu components is where most remediation actually lives. Libraries like Radix UI, React Aria, or Reach UI implement the ARIA Authoring Practices Guide patterns correctly and expose unstyled primitives you can theme with Tailwind. Replacing hand-rolled modals and dropdowns with one of these libraries resolves a long tail of keyboard, focus, and screen reader issues in a single refactor. A minimal accessible button in Next.js looks unremarkable — that is the point:

import { forwardRef, ButtonHTMLAttributes } from 'react';

type ButtonProps = ButtonHTMLAttributes<HTMLButtonElement> & {
  loading?: boolean;
  loadingLabel?: string;
};

export const Button = forwardRef<HTMLButtonElement, ButtonProps>(
  ({ loading, loadingLabel = 'Loading', disabled, children, ...rest }, ref) => (
    <button
      ref={ref}
      disabled={disabled || loading}
      aria-busy={loading || undefined}
      aria-label={loading ? loadingLabel : undefined}
      className="inline-flex items-center rounded px-4 py-2 focus-visible:outline focus-visible:outline-2 focus-visible:outline-offset-2"
      {...rest}
    >
      {children}
    </button>
  ),
);

The details matter: focus-visible preserves the focus ring for keyboard users without cluttering the mouse experience, aria-busy announces the loading state, the disabled prop handles both user-driven and loading disablement, and the component forwards refs so form libraries can manage focus programmatically. Reproducing this discipline across the design system is usually the single biggest move an engineering team can make toward European Accessibility Act compliance.

The final layer is page- and route-level. In Next.js App Router, ensure every route has a unique, descriptive <title> and a visible <h1> that matches the task; wire next/link with sensible aria-current treatment for active navigation; and make sure client-side route transitions move focus to the new page's heading and announce the change to screen readers. This last step catches many teams by surprise — a SPA-style route change that does not move focus is a WCAG 2.4.3 failure on every single navigation.

The measurable targets to hit before an external audit: zero jsx-a11y ESLint errors in CI, zero axe violations on the top ten user flows under @axe-core/playwright, a documented keyboard-only walkthrough for each critical task, and a manual screen reader pass (NVDA or VoiceOver) on authentication, primary CRUD, and payment flows. A thorough code quality audit often folds this work into a broader quality baseline, and for older products a legacy code optimization engagement is usually where deeply embedded accessibility defects — inaccessible tables, image-rendered text, custom select widgets — get surfaced and retired.

What an EU Accessibility Statement Must Contain

The accessibility statement is the public-facing compliance artefact, and it is the first thing a regulator or a procurement auditor will look for. Under the EAA and aligned with the Web Accessibility Directive's well-established template, an accessibility statement needs to cover conformance status (typically "partially conformant with WCAG 2.2 level AA"), non-accessible content with reasons, the date the statement was prepared and last reviewed, the method used to evaluate (self-assessment, third-party audit, both), a feedback mechanism with a named contact, and an enforcement procedure pointing users to the competent national authority if unresolved.

The statement should be reachable from every page — a footer link labelled "Accessibility" is the conventional pattern, often paired with "Accessibility statement" as the pagetitle. It should be dated and versioned. It should name specific known issues rather than hand-wave — "the analytics dashboard's data table is keyboard-accessible but does not yet announce column headers" is stronger than "some complex widgets may not be fully accessible." And the feedback address must actually route to a human who can respond; under national transpositions, unanswered accessibility complaints are themselves a compliance violation.

For Germany the underlying transposition is the Barrierefreiheitsstärkungsgesetz (BFSG), with the supervising authorities organised at Länder level for market surveillance of services. Other member states have equivalent regimes — the AccessibleEU hub maintains a current list. For a multi-country SaaS, the accessibility statement should reference compliance against EN 301 549 and WCAG 2.2 level AA rather than any single national regulation, which keeps it portable across jurisdictions.

Closing

European Accessibility Act compliance for B2B SaaS is a roadmap item, not a regulatory side-quest. The products that move fastest through enterprise procurement in 2026 are the ones with a clean accessibility statement, a current WCAG 2.2 AA audit, and a design system where accessible components are the default. The ones that drag are the teams who argued their way out of scope, missed the 2025 enforcement date, and are now retrofitting a React codebase under deal pressure.

Wolf-Tech helps Berlin and EU-based product teams audit their React and Next.js applications against WCAG 2.2 level AA, refactor design systems toward accessibility-by-default, and produce the accessibility statements their customers and regulators expect. Contact us at hello@wolf-tech.io or visit wolf-tech.io for a free consultation.