European Accessibility Act: Dein SaaS konform machen, bevor sich die Durchsetzungslücke schließt

Ein in Berlin ansässiges B2B-SaaS-Unternehmen, das mittelständische Einzelhändler in der gesamten EU betreut, erhielt Anfang 2026 eine einseitige E-Mail von einem Einkaufsteam. Der Anhang war ein Lieferanten-Fragebogen zur Barrierefreiheit mit sechzehn Fragen, die an den European Accessibility Act und WCAG 2.2 Level AA geknüpft waren. Das Produkt war seit 2019 am Markt, hatte ein modernes React/Next.js-Frontend und war nie durch ein formales Barrierefreiheits-Audit gegangen. Der erste Instinkt des CTO war zu argumentieren, das SaaS sei B2B und damit außerhalb des Geltungsbereichs. Das war es nicht. Innerhalb von drei Wochen hatte das Team eine Barrierefreiheitserklärung, ein Backlog zur Behebung, und ein Deal, der ins Stocken geraten war, kam wieder in Bewegung.

Das ist mittlerweile ein wiederkehrendes Muster im EU-Softwaremarkt. Der European Accessibility Act (Richtlinie (EU) 2019/882, bekannt als EAA) wurde am 28. Juni 2025 durchsetzbar, und die Einkaufsmaschinerie der Unternehmen hat begonnen aufzuholen. Die meisten B2B-SaaS-Plattformen scheitern noch an grundlegenden WCAG-2.2-Level-AA-Prüfungen: fehlende Alt-Texte, nicht beschriftete Formulareingaben, Tastaturfallen in modalen Dialogen, unzureichender Farbkontrast bei bronzefarbenen CTAs auf Weiß, aus ästhetischen Gründen deaktivierte Fokus-Zustände. Die Übergangsregelungen für Produkte, die vor Juni 2025 in den Markt gebracht wurden, laufen nur bis 2030, und jeder Einkaufszyklus zwischen jetzt und dann ist eine Gelegenheit, bei der eine Compliance-Lücke dich einen Deal oder die Aufmerksamkeit einer Aufsichtsbehörde kosten kann. Dieser Beitrag ist ein praktischer Leitfaden für CTOs, Product Owner und Engineering-Leads dazu, was European Accessibility Act Compliance für B2B-SaaS tatsächlich verlangt, wie man eine React/Next.js-Codebasis behebt, ohne die Roadmap zu entgleisen, und wie eine verteidigbare Barrierefreiheitserklärung im Jahr 2026 aussieht.

Wen der European Accessibility Act wirklich erfasst: Geltungsbereich für SaaS

Der EAA listet bestimmte Kategorien von Produkten und Diensten auf, die unter seine Pflichten fallen. Auf der Produktseite gehören dazu Verbraucher-Computerhardware, Selbstbedienungsterminals (Geldautomaten, Ticketautomaten, Check-in-Kioske), Verbrauchergeräte für die elektronische Kommunikation und E-Reader. Auf der Diensteseite reicht der Geltungsbereich bis zu elektronischen Kommunikationsdiensten, dem Zugang zu audiovisuellen Mediendiensten, Elementen des Personenverkehrs, Bankdienstleistungen für Verbraucher, E-Books und dedizierter Software und, der Kategorie, die die meisten SaaS hineinzieht, E-Commerce-Diensten. E-Commerce ist in der Richtlinie weit definiert als "Dienstleistungen, die im Fernabsatz über Websites und über mobilgerätebasierte Dienste auf elektronischem Wege und auf individuelle Anfrage eines Verbrauchers im Hinblick auf den Abschluss eines Verbrauchervertrags erbracht werden."

Die häufige Fehlinterpretation ist, dass "Verbraucher" bedeutet, der EAA ende bei B2C. In der Praxis fällt jedes SaaS, das Bestellabläufe, Ticketbuchung, Abo-Checkout, Buchungs-Widgets oder Self-Service-Kaufpfade einbettet, die von Verbrauchern genutzt werden können, in den Geltungsbereich, selbst wenn die meisten Kunden Unternehmen sind. Bank- und Zahlungsdienste ziehen die Linie noch aggressiver. Ein B2B-Fintech-SaaS, das verbrauchergerichtetes Konto-Onboarding oder Kontoauszugsansichten bereitstellt, erbt fast immer EAA-Pflichten über seine regulierten Kunden. Dasselbe gilt für Plattformen, die in Bank-, Telekommunikations- oder Verkehrsanbieter eingebettet sind: Die Pflicht fließt als vertragliche Anforderung den Stack hinunter, selbst wo die Richtlinie selbst den Anbieter nicht namentlich nennt.

Kleinstunternehmen mit weniger als zehn Beschäftigten und einem Jahresumsatz unter 2 Millionen Euro sind für Dienste ausgenommen, aber nicht für die oben genannten Produktkategorien und nicht von den vertraglichen Anforderungen ihrer Kunden. Für alle anderen ist die einzig verlässliche Haltung, von zumindest teilweiser Erfassung der Produktoberfläche auszugehen und zu dokumentieren, wo Ausnahmen gelten.

Was das Gesetz über WCAG 2.2 Level AA hinaus verlangt

Der EAA selbst ist in seiner Sprache funktional: Er spricht von Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit, ohne einen bestimmten technischen Standard vorzuschreiben. Der harmonisierte Standard, der diese Anforderungen operationalisiert, ist EN 301 549, der sich in seiner aktuell veröffentlichten Fassung eng an WCAG 2.2 Level AA für Webinhalte anlehnt. Wenn dein Produkt WCAG 2.2 AA erreicht, bist du unter der Richtlinie in der stärksten verteidigbaren Position. Wenn es nur WCAG 2.1 AA erreicht, bist du nah dran, aber nicht sauber. 2.2 hat neun Erfolgskriterien hinzugefügt, darunter Fokus-Erscheinung, Ziehbewegungen, Zielgröße, konsistente Hilfe und redundante Eingabe, die allesamt typischerweise die rauen Kanten in echten React-Anwendungen sind.

Über WCAG hinaus fügt EN 301 549 Anforderungen hinzu, die Teams überraschen, die annehmen, Barrierefreiheit ende am Browser. Die mit dem Dienst bereitgestellte Dokumentation muss selbst barrierefrei sein. PDF-Benutzerhandbücher, die an Tagging oder Überschriftenreihenfolge scheitern, sind ein Befund. Support-Kanäle müssen mindestens einen barrierefreien Kommunikationsweg bieten. Ein Chat-Widget, das nur von sehenden Maus-Nutzern bedient werden kann, ist eine Lücke. Schulungsmaterialien, Onboarding-Videos und jede ins Produkt eingebettete Medien brauchen Untertitel und, wo der Inhalt primär visuell ist, Audiodeskription. Autorenwerkzeuge, die Teile deines SaaS, in denen Nutzer Inhalte erstellen, haben ihre eigene Klausel: Sie müssen nicht nur für die Autorin barrierefrei sein, sondern ihr auch helfen, barrierefreie Ausgaben zu produzieren.

Der EAA erlegt auch eine Konformitätsbewertungspflicht auf. Erfasste Dienste müssen dokumentieren, wie sie die Barrierefreiheitsanforderungen erfüllen, und diese Dokumentation den Marktüberwachungsbehörden auf Anfrage zur Verfügung stellen. Ein getippter Satz in einem Wiki reicht nicht. Das erwartete Artefakt ist ein Accessibility Conformance Report (ein ACR, oft im Format VPAT 2.x oder ähnlich erstellt), der jedes anwendbare Erfolgskriterium auf eine Konformitätsaussage mit Nachweis abbildet. Für die meisten SaaS-Teams ist das das fehlende Stück: Sie haben Tests, aber keinen Report, oder einen Report, der seit einem größeren UI-Redesign nicht aktualisiert wurde.

Behebung in einer React/Next.js-Codebasis: Wo man anfängt

Ein vollständiges WCAG-2.2-AA-Audit einer mittelgroßen React/Next.js-Anwendung fördert typischerweise zwischen sechzig und zweihundert Probleme zutage. Sie ohne Methode zu priorisieren verbrennt das Engineering-Budget schnell. Die Methode, die funktioniert, ist, nach Nutzerfluss zu beheben, nicht nach Problemkategorie. Ein Checkout-Fluss, der durchgängig barrierefrei ist, ist zehn über die Codebasis verstreute Fixes wert, denn EN 301 549 und WCAG bewerten beide, ob eine vollständige Aufgabe ausgeführt werden kann, nicht ob einzelne Komponenten isoliert bestehen.

Beginne damit, die Codebasis mit einem automatisierten ersten Durchlauf zu instrumentieren. eslint-plugin-jsx-a11y fängt die strukturellen Fehler zur Autorenzeit ab: fehlende Alt-Attribute, interaktive Elemente ohne Rollen, Labels, die nicht mit Eingaben verknüpft sind. @axe-core/react oder ein äquivalenter Laufzeitprüfer kann in deinen Entwicklungs-Build eingebunden werden, um Probleme in der Browser-Konsole zu protokollieren, während Komponenten rendern. Beide haben nahezu null falsch-positive bei den Problemen, die sie melden, und beide übersehen die Mehrheit echter Barrierefreiheitsdefekte. Sie decken rund ein Drittel der WCAG-Erfolgskriterien ab.

Die nächste Ebene ist auf Komponentenebene. Ein Design-System, das Button-, Input-, Modal-, Tabs-, Combobox- und Menu-Komponenten bereitstellt, ist der Ort, an dem die meiste Behebung tatsächlich stattfindet. Bibliotheken wie Radix UI, React Aria oder Reach UI implementieren die Muster des ARIA Authoring Practices Guide korrekt und stellen ungestylte Primitive bereit, die du mit Tailwind themen kannst. Selbstgebaute Modals und Dropdowns durch eine dieser Bibliotheken zu ersetzen löst in einem einzigen Refactoring einen langen Schwanz von Tastatur-, Fokus- und Screenreader-Problemen. Ein minimaler barrierefreier Button in Next.js sieht unspektakulär aus, und das ist der Punkt:

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>
  ),
);

Die Details zählen: focus-visible erhält den Fokusring für Tastaturnutzer, ohne die Maus-Erfahrung zu überladen, aria-busy kündigt den Ladezustand an, die disabled-Prop behandelt sowohl nutzergesteuerte als auch ladebedingte Deaktivierung, und die Komponente leitet Refs weiter, damit Formularbibliotheken den Fokus programmatisch verwalten können. Diese Disziplin im gesamten Design-System zu reproduzieren ist meist der größte einzelne Schritt, den ein Engineering-Team in Richtung European Accessibility Act Compliance machen kann.

Die letzte Ebene ist auf Seiten- und Routen-Ebene. Stelle im Next.js App Router sicher, dass jede Route einen eindeutigen, beschreibenden <title> und eine sichtbare <h1> hat, die zur Aufgabe passt. Verdrahte next/link mit sinnvoller aria-current-Behandlung für aktive Navigation, und stelle sicher, dass clientseitige Routenwechsel den Fokus auf die Überschrift der neuen Seite verschieben und den Wechsel an Screenreader ankündigen. Dieser letzte Schritt überrascht viele Teams: Ein SPA-artiger Routenwechsel, der den Fokus nicht verschiebt, ist bei jeder einzelnen Navigation ein Verstoß gegen WCAG 2.4.3.

Die messbaren Ziele, die du vor einem externen Audit erreichen solltest: null jsx-a11y-ESLint-Fehler in der CI, null axe-Verstöße auf den Top-Ten-Nutzerflüssen unter @axe-core/playwright, ein dokumentierter Tastatur-Walkthrough für jede kritische Aufgabe und ein manueller Screenreader-Durchlauf (NVDA oder VoiceOver) auf Authentifizierungs-, primären CRUD- und Zahlungsflüssen. Ein gründliches Code-Quality-Audit bezieht diese Arbeit oft in eine breitere Qualitätsbasis ein, und für ältere Produkte ist ein Projekt zur Legacy-Code-Optimierung meist der Ort, an dem tief eingebettete Barrierefreiheitsdefekte (nicht barrierefreie Tabellen, als Bild gerenderter Text, eigene Select-Widgets) zutage treten und ausgemustert werden.

Was eine EU-Barrierefreiheitserklärung enthalten muss

Die Barrierefreiheitserklärung ist das öffentlich zugängliche Compliance-Artefakt, und sie ist das Erste, wonach eine Aufsichtsbehörde oder ein Einkaufsauditor sucht. Unter dem EAA und im Einklang mit der gut etablierten Vorlage der Web-Barrierefreiheitsrichtlinie muss eine Barrierefreiheitserklärung Folgendes abdecken: den Konformitätsstatus (typischerweise "teilweise konform mit WCAG 2.2 Level AA"), nicht barrierefreie Inhalte mit Begründungen, das Datum der Erstellung und letzten Überprüfung der Erklärung, die verwendete Bewertungsmethode (Selbstbewertung, Drittprüfung, beides), einen Feedback-Mechanismus mit benannter Kontaktperson und ein Durchsetzungsverfahren, das Nutzer an die zuständige nationale Behörde verweist, falls etwas ungelöst bleibt.

Die Erklärung sollte von jeder Seite aus erreichbar sein. Ein Footer-Link mit der Beschriftung "Barrierefreiheit" ist das übliche Muster, oft gepaart mit "Barrierefreiheitserklärung" als Seitentitel. Sie sollte datiert und versioniert sein. Sie sollte konkrete bekannte Probleme nennen statt vage zu bleiben. "Die Datentabelle im Analytics-Dashboard ist tastaturzugänglich, kündigt aber noch keine Spaltenüberschriften an" ist stärker als "manche komplexen Widgets sind möglicherweise nicht vollständig barrierefrei." Und die Feedback-Adresse muss tatsächlich an einen Menschen führen, der antworten kann. Unter den nationalen Umsetzungen sind unbeantwortete Barrierefreiheitsbeschwerden selbst ein Compliance-Verstoß.

Für Deutschland ist die zugrundeliegende Umsetzung das Barrierefreiheitsstärkungsgesetz (BFSG), wobei die aufsichtführenden Behörden für die Marktüberwachung von Diensten auf Länderebene organisiert sind. Andere Mitgliedstaaten haben gleichwertige Regelungen. Der AccessibleEU-Hub pflegt eine aktuelle Liste. Für ein länderübergreifendes SaaS sollte die Barrierefreiheitserklärung auf Konformität mit EN 301 549 und WCAG 2.2 Level AA verweisen statt auf eine einzelne nationale Regelung, was sie über Rechtsräume hinweg portabel hält.

Schluss

European Accessibility Act Compliance für B2B-SaaS ist ein Roadmap-Punkt, kein regulatorischer Nebenschauplatz. Die Produkte, die sich 2026 am schnellsten durch den Enterprise-Einkauf bewegen, sind die mit einer sauberen Barrierefreiheitserklärung, einem aktuellen WCAG-2.2-AA-Audit und einem Design-System, in dem barrierefreie Komponenten der Standard sind. Die, die sich hinziehen, sind die Teams, die sich aus dem Geltungsbereich herausargumentiert, den Durchsetzungstermin 2025 verpasst haben und nun unter Deal-Druck eine React-Codebasis nachrüsten.

Wolf-Tech hilft Produktteams in Berlin und der EU, ihre React- und Next.js-Anwendungen gegen WCAG 2.2 Level AA zu auditieren, Design-Systeme in Richtung Barrierefreiheit-als-Standard zu refactoren und die Barrierefreiheitserklärungen zu erstellen, die ihre Kunden und Aufsichtsbehörden erwarten. Kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io für eine kostenlose Beratung.