European Accessibility Act 2025: Ein Sanierungsplan für SaaS-Teams nach Ablauf der Frist

Die Durchsetzungsfrist des European Accessibility Act ist im Juni 2025 abgelaufen. Wenn dein SaaS-Produkt Verbraucher oder B2B-Nutzer in der EU bedient und du noch kein Accessibility-Audit durchgeführt hast, dann bist du über der Frist, nicht kurz davor. Das ändert die Rechnung. Das Ziel ist jetzt keine theoretisch perfekte WCAG-2.2-AA-Umsetzung, sondern ein glaubwürdiger, belegbarer Verbesserungsplan, der zeigt, dass du die Lücken kennst und sie aktiv schließt.

Dieser Beitrag liefert dir den Sanierungsansatz nach Triage-Prinzip: worauf Auditoren tatsächlich testen, welche Probleme das größte rechtliche und nutzerseitige Risiko tragen und wie du eine Barrierefreiheitserklärung veröffentlichst, die belastbar statt bloß aspirativ ist.

Was der EAA tatsächlich verlangt

Der European Accessibility Act gilt für Produkte und Dienstleistungen, die nach dem 28. Juni 2025 auf dem EU-Markt bereitgestellt werden, und setzt WCAG 2.1 AA als technischen Mindeststandard. In der Praxis ergänzen nationale Umsetzungsgesetze (etwa die deutsche BFSGV, die französische RGAA und das österreichische WZG) weitere Details, doch der gemeinsame Nenner bleibt: Digitale Produkte, einschließlich Webanwendungen und mobiler Apps, müssen für Menschen mit Behinderungen wahrnehmbar, bedienbar, verständlich und robust sein.

Für B2B-SaaS hängt der Anwendungsbereich davon ab, was dein Produkt tut und wen es bedient. Interne Werkzeuge, die ausschließlich von Mitarbeitenden genutzt werden, sind teilweise ausgenommen, aber jede kundenseitige Oberfläche fällt in den EAA-Anwendungsbereich. Wenn dein Produkt sowohl Geschäftskunden als auch deren Endkunden bedient, sind die kundenseitigen Teile mit hoher Wahrscheinlichkeit erfasst.

Der Durchsetzungsmechanismus unterscheidet sich je nach Land, involviert aber in der Regel nationale Marktüberwachungsbehörden und verpflichtet Unternehmen ab zehn Mitarbeitenden dazu, eine Barrierefreiheitserklärung zu veröffentlichen und einen Meldeweg für Barrieren bereitzustellen. Verstöße können Bußgelder nach sich ziehen, und Einkaufsabteilungen im Enterprise-Umfeld nehmen EAA-Konformität zunehmend als Lieferantenanforderung auf.

Das Triage-Framework: vier Schweregrade

Bevor du anfängst, wahllos Dinge zu reparieren, brauchst du eine Triage-Karte. Barrierefreiheitsprobleme reichen von kritischen Blockern, die Menschen mit Behinderungen an zentralen Aufgaben hindern, bis zu kleinen Verbesserungen, die die Erfahrung anheben, ohne den Zugang zu blockieren.

Stufe 1 - kritische Blocker. Diese verhindern, dass ein Nutzer mit Behinderung einen Kern-Workflow überhaupt abschließen kann. Beispiele: ein Formular, das sich nicht allein per Tastatur absenden lässt, eine reine Bild-Fehlermeldung ohne Textalternative, ein Modal, das den Tastaturfokus einsperrt, sodass der Nutzer nicht mehr herauskommt, oder ein Videoplayer ohne Untertitel bei Schulungsinhalten. Behebe diese zuerst. Es sind die Probleme, die am ehesten Beschwerden auslösen und in einem Auditbefund zitiert werden.

Stufe 2 - erhebliche Barrieren. Diese machen Kern-Workflows deutlich schwerer, aber nicht unmöglich. Beispiele: schwacher Farbkontrast bei Fließtext und interaktiven Elementen, fehlende Formularfeld-Labels (visuell vorhanden, im DOM aber nicht), Fokusindikatoren, die auf interaktiven Elementen verschwinden, oder interaktive Komponenten, die Screenreadern falsch angesagt werden. Behebe diese im laufenden oder im nächsten Sprint.

Stufe 3 - mittlere Reibung. Diese erzeugen unnötige Hürden, doch Nutzer mit Workarounds kommen weiter. Beispiele: inkonsistente Überschriftenhierarchie, fehlende Sprungnavigation auf Seiten mit umfangreichen Menüs, Timeout-Warnungen ohne ausreichende Vorwarnzeit oder Tabellen ohne <caption> und Header-Zuordnung. Plane diese innerhalb des laufenden Quartals ein.

Stufe 4 - Verbesserungen. Best-Practice-Optimierungen jenseits der Mindestkonformität. Diese können ins Backlog und über die folgenden zwei Quartale abgearbeitet werden.

Das Triage-Audit erfordert an Tag eins keinen vollständigen WCAG-2.2-AA-Durchlauf. Es erfordert genug Abdeckung, um deine Probleme der Stufen 1 und 2 zu finden, damit du richtig priorisieren kannst.

Worauf Auditoren tatsächlich testen

Zu verstehen, wonach ein EAA-Audit oder eine Beschwerdeuntersuchung sucht, hilft dir, den Sanierungsaufwand dorthin zu lenken, wo er zählt. Nationale Marktüberwachungsbehörden und Accessibility-Auditoren arbeiten strukturiert und decken üblicherweise diese Bereiche zuerst ab:

Tastaturbedienbarkeit. Öffne deine Anwendung und zieh die Maus ab. Navigiere mit Tab, Shift-Tab, Enter, Leertaste und Pfeiltasten. Wenn du an einen Punkt kommst, an dem es nicht weitergeht, oder wenn du aus den Augen verlierst, wo der Fokus steht, hast du ein kritisches Problem. Tastaturtests brauchen weniger als eine Stunde pro Kern-Workflow und legen die schwerwiegendsten Barrieren offen.

Screenreader-Kompatibilität. Teste mit VoiceOver unter macOS und iOS, mit NVDA oder JAWS unter Windows. Navigiere durch deinen Registrierungsablauf, das Haupt-Dashboard und eine typische Aufgabe wie das Absenden eines Formulars oder das Filtern einer Datentabelle. Hör zu, was angesagt wird. Fehlende Labels, falsche Rollen und kaputte Live-Regions zeigen sich im Screenreader-Test sofort.

Farbkontrast. Führe automatisierte Kontrastprüfungen mit den Browser-Devtools oder Werkzeugen wie der axe-Browser-Erweiterung durch. Fließtext braucht ein Verhältnis von 4,5:1 gegenüber dem Hintergrund, große Schrift und Icons brauchen 3:1. Das ist einer der häufigsten Mängel und einer der am leichtesten zu behebenden, wenn du CSS Custom Properties oder ein Design-Token-System nutzt: Du änderst den Token-Wert und die Korrektur propagiert.

Fehlerkennzeichnung. Wenn die Formularvalidierung fehlschlägt, benennt die Fehlermeldung dann das Feld und beschreibt, was korrigiert werden muss? "Ungültige Eingabe" fällt durch. "Die E-Mail-Adresse muss ein @-Zeichen enthalten" besteht. Fehlermeldungen müssen außerdem programmatisch mit ihrem Feld verknüpft sein: Ein <div> mit rotem Text neben einem <input> reicht nicht, das Eingabefeld braucht ein aria-describedby, das auf das Fehlerelement zeigt.

Alternativtexte. Alle bedeutungstragenden Bilder brauchen beschreibenden alt-Text. Dekorative Bilder brauchen alt="". Bilder von Text brauchen den Text im alt-Attribut reproduziert. Diagramme und Infografiken brauchen entweder eine Textalternative im umgebenden Inhalt oder eine verlinkte Langbeschreibung.

Dokumenttitel und Sprache. Jede Seite braucht einen aussagekräftigen <title> und ein lang-Attribut am <html>-Element. Das sind Basisanforderungen, die automatisierte Werkzeuge sofort erkennen.

Automatisierte Tools wie axe-core, Lighthouse und WAVE finden zuverlässig etwa 30 bis 40 Prozent der WCAG-Verstöße. Der Rest erfordert manuelle Tests und Tests mit assistiven Technologien. Verlass dich zur Einschätzung deines Konformitätsgrades nicht allein auf automatisierte Werkzeuge.

Was du in diesem Sprint behebst

Da du die Durchsetzungsfrist bereits überschritten hast, liegt die Priorität für den laufenden Sprint darauf, deine kritischen Blocker der Stufe 1 zu schließen. Ein realistischer Sprint-Umfang für ein Engineering-Team aus vier bis sechs Personen:

Führe automatisierte axe-core-Tests über deine fünf meistbesuchten Seiten und deinen wichtigsten Nutzer-Workflow aus (typischerweise Registrierung, Login und die Kernfunktion deines Produkts). Dokumentiere jeden Fehler. Exportiere die Ergebnisse.

Priorisiere Korrekturen nach Wirkung: zuerst Tastaturfallen, dann fehlende Formular-Labels und Fehlerzuordnungen, dann fehlende Alternativtexte bei bedeutungstragenden Bildern, dann Kontrastmängel bei primären interaktiven Elementen.

Wenn deine React-Komponenten auf einer UI-Bibliothek aufsetzen (Radix, Headless UI, MUI, Chakra), sieh im Accessibility-Changelog der Bibliothek nach. Viele verbreitete Barrierefreiheitsprobleme in React-Anwendungen entstehen durch falsche Verwendung von Komponentenbibliotheken und nicht durch eigenen Code. Radix UI hat besonders gut dokumentierte ARIA-Muster. Wenn du nicht dem empfohlenen Kompositionsansatz folgst, überschreibst du womöglich die barrierefreien Voreinstellungen.

Speziell für Next.js-Anwendungen: Stelle sicher, dass clientseitige Routenwechsel den neuen Seitentitel an Screenreader melden. Der App Router tut das nicht in allen Konfigurationen automatisch. Ein einfacher Ansatz ist eine visuell versteckte Live-Region, die bei Navigation aktualisiert und mit dem Seitentitel befüllt wird.

Die Barrierefreiheitserklärung

EU-Mitgliedstaaten verpflichten erfasste Organisationen dazu, eine Barrierefreiheitserklärung zu veröffentlichen. Die Erklärung erfüllt zwei Zwecke: Sie legt bekannte Konformitätslücken ehrlich offen und stellt einen Rückmeldeweg für Nutzer bereit, die auf Barrieren stoßen.

Eine belastbare Barrierefreiheitserklärung enthält:

Den Konformitätsstatus, also vollständig konform, teilweise konform oder nicht konform, bezogen auf den einschlägigen Standard (WCAG 2.1 AA). Behaupte keine vollständige Konformität, solange du keinen Nachweis aus einem vollständigen Audit hast. "Teilweise konform" mit einer Liste bekannter Ausnahmen ist rechtlich weit besser als eine falsche Vollkonformitätsbehauptung, die ein Nutzer sofort widerlegen kann.

Eine Liste bekannter Nichtkonformitäten. Das ist kein Schuldeingeständnis, sondern der Nachweis, dass du dein Produkt bewertet hast und die Lücken kennst. Ein Auditor, der Nichtkonformitäten findet, die du nicht aufgeführt hast, ist schlimmer, als sie selbst zu nennen.

Das Datum der letzten Überprüfung der Erklärung. Aufsichtsbehörden achten auf Belege dafür, dass die Erklärung gepflegt und nicht nur einmal veröffentlicht wurde. Prüfe sie quartalsweise.

Einen Rückmeldeweg, typischerweise eine E-Mail-Adresse oder ein Formular, über den Nutzer Barrieren melden und alternative Formate anfordern können. Auf solche Anfragen musst du in angemessener Frist reagieren, die meisten nationalen Gesetze nennen einen Zeitraum um zwei Wochen.

Kontaktdaten der zuständigen nationalen Durchsetzungsstelle, damit Nutzer wissen, wohin sie eskalieren können, wenn ihre Rückmeldung nicht bearbeitet wird.

Veröffentliche die Erklärung unter einer konstanten URL, typischerweise /accessibility oder /accessibility-statement, und verlinke sie aus dem Footer jeder Seite.

Barrierefreiheit in den Entwicklungsprozess integrieren

Eine Sanierung repariert eine Momentaufnahme. Ohne Prozessänderungen sammeln sich neue Barrierefreiheitsprobleme parallel zu neuen Features an. Der minimal tragfähige Prozess für ein kleines bis mittleres Team:

Nimm axe-core in deine CI-Pipeline auf. Die Integration @axe-core/playwright führt automatisierte Prüfungen bei jedem Pull Request aus und lässt den Build bei Verstößen der Stufe 1 fehlschlagen. Das ersetzt keine manuellen Tests, fängt aber Regressionen automatisch ab.

Ergänze deine Design-Review-Checkliste um einen Barrierefreiheitsteil. Bevor eine neue UI-Komponente in die Entwicklung geht, frage: Zeigt das Design Fokuszustände? Werden Fehlerzustände angesagt oder nur farblich codiert? Sind interaktive Ziele mindestens 24 mal 24 CSS-Pixel groß (Anforderung aus WCAG 2.2)?

Benenne eine verantwortliche Person für Barrierefreiheit. Keine Vollzeitrolle, aber jemand, der das Sanierungs-Backlog verfolgt, regelmäßig manuelle Tests durchführt und die Barrierefreiheitserklärung quartalsweise prüft. Diese Person sollte die Befugnis haben, Barrierefreiheitsprobleme als Blocker zu kennzeichnen.

Wenn du an einem Projekt zur individuellen Softwareentwicklung arbeitest oder eine Modernisierung von Legacy-Code angehst, ist es deutlich günstiger, Barrierefreiheit von der Komponentenebene an mitzubauen, als sie später nachzurüsten. Dasselbe Prinzip gilt für dein eigenes Produkt.

Externe Unterstützung holen

Für Teams, die ein strukturiertes Audit statt einer Selbstbewertung brauchen, deckt ein externes Accessibility-Audit durch Spezialisten sowohl automatisierte als auch manuelle Tests über assistive Technologien hinweg ab, liefert einen priorisierten Sanierungsbericht und kann eine unterstützende Stellungnahme für Beschaffungs- und Regulierungskontexte bereitstellen.

Wenn du dich auf Enterprise-Vertrieb vorbereitest, bei dem Beschaffungsfragebögen EAA-Fragen enthalten, überzeugt ein Auditbericht eines benannten Spezialisten mehr als eine Selbstbewertung. Wolf-Tech unterstützt bei der technischen Umsetzung von Barrierefreiheitsverbesserungen in React- und Next.js-Codebasen oder prüft die Auswirkungen architektonischer Entscheidungen auf Barrierefreiheit im Rahmen der Webanwendungsentwicklung. Für Auditmethodik und die vollständige WCAG-2.2-Testsuite bringt die Zusammenarbeit mit spezialisierten Accessibility-Fachleuten neben der Engineering-Arbeit die vollständigste Abdeckung.

Die Durchsetzungsfrist ist verstrichen. Am stärksten gefährdet sind gerade die Organisationen, die nichts getan haben und keinen Plan vorweisen können. Ein Sanierungsansatz nach Triage-Prinzip, eine veröffentlichte Barrierefreiheitserklärung, die ehrlich zu bekannten Lücken steht, und ein CI-Prozess, der Regressionen verhindert: Diese drei Dinge, geliefert innerhalb der nächsten zwei Sprints, bringen dich in eine deutlich stärkere Position, als untätig auf eine perfekte Umsetzung zu warten.

Fragen zur technischen Umsetzung kannst du an hello@wolf-tech.io richten. Das Ziel ist belegbarer Fortschritt, nicht unerreichbare Perfektion.