Der European Accessibility Act gilt: Was das für Ihre Software bedeutet

Der European Accessibility Act (EAA) gilt EU-weit seit dem 28. Juni 2025. Für viele digitale Produkte und Dienste ist Barrierefreiheit damit von 'nice to have' zur gesetzlichen Pflicht geworden, mit nationaler Aufsicht und echten Bussgeldern. Hier die praktische Sicht für Software-Teams. (Eine Orientierung, keine Rechtsberatung.)

Was der EAA ist

Der EAA (Richtlinie (EU) 2019/882) ist ein EU-weites Gesetz, das bestimmte Produkte und Dienstleistungen für Menschen mit Behinderungen zugänglich machen muss. Die Mitgliedstaaten haben ihn in nationales Recht umgesetzt: in Deutschland als BFSG, in Österreich als BaFG, jeweils mit eigener Marktüberwachung und Sanktionen. Die Pflichten gelten für Dienstleistungen, die seit dem 28. Juni 2025 für Verbraucher erbracht werden; für Bestandsdienste und Altverträge laufen Übergangsfristen bis längstens zum 28. Juni 2030; bereits eingesetzte Selbstbedienungsterminals dürfen bis zu 20 Jahre nach Inbetriebnahme weitergenutzt werden.

Wer betroffen ist

Im Fokus stehen verbraucherorientierte digitale Dienste und Produkte: E-Commerce (jeder Webshop, der an EU-Verbraucher verkauft), Bankdienstleistungen für Verbraucher, E-Books und Reader, elektronische Kommunikation, Teile des Personenverkehrs (Ticketing, Check-in) sowie Hardware wie Geldautomaten, Terminals, Smartphones und Betriebssysteme. Reine B2B-Software ist nicht direkt erfasst; B2B-Anbieter spüren es aber indirekt: Ihre Kunden müssen konform sein, und Accessibility-Klauseln tauchen zunehmend in Ausschreibungen auf. Kleinstunternehmen (unter 10 Beschäftigte und unter 2 Mio. Euro Umsatz) sind bei Dienstleistungen ausgenommen.

Die technische Messlatte: WCAG 2.1 AA

In der Praxis wird Konformität an der europäischen Norm EN 301 549 gemessen, die für Web- und Mobile-Inhalte auf WCAG 2.1 Level AA verweist. Die für den EAA aktualisierte Fassung der Norm wird WCAG 2.2 referenzieren; wer heute neu baut, orientiert sich am besten gleich daran. Typische Befunde aus Audits: zu geringe Farbkontraste, Oberflächen, die sich nicht rein per Tastatur bedienen lassen, fehlende Fokus-Indikatoren, Formularfelder ohne programmatische Labels, Bilder ohne aussagekräftigen Alternativtext, Videos ohne Untertitel und Custom-Widgets, die für Screenreader unsichtbar sind.

Warum automatisierte Scans nicht reichen

Automatische Checker (axe, Lighthouse, WAVE) sind ein guter Anfang, finden aber je nach Studie nur 30 bis 57 Prozent der WCAG-Probleme (GOV.UK-Toolvergleich, Deque-Studie). Ob eine Seite wirklich nutzbar ist, zeigt erst das manuelle Testen: Tastatur-Durchläufe, Screenreader-Sessions (NVDA, JAWS, VoiceOver), Zoom auf 200 Prozent, Lesereihenfolge und Fehlerbehandlung in echten Abläufen. Accessibility-Testing ist eine Disziplin, kein Plugin.

Pragmatisch starten

Zuerst die kritischen Journeys auditieren (Login, Suche, Checkout, Formulare), nicht jede Seite auf einmal.
Befunde nach Nutzer-Impact klassifizieren, nicht nach Tool-Severity; eine Tastaturfalle im Checkout wiegt schwerer als zwölf Kontrast-Warnungen im Footer.
Muster fixen, nicht Seiten: Die meisten Probleme stecken in geteilten Komponenten; eine reparierte Komponente heilt fünfzig Screens.
Checks in die Pipeline einbetten: automatische Regeln bei jedem Commit, manuelle Audits je Release.

Unsere Einschätzung

Barrierefreiheit ist das seltene Compliance-Thema, das das Produkt für alle besser macht: klarere Fokuszustände, bessere Formulare, robusteres Markup. Wenn der EAA Sie (oder Ihre Kunden) betrifft, zeigt ein fokussiertes Audit innerhalb weniger Tage, wo Sie stehen. Genau das leistet unser QA Health Check oder ein dediziertes Accessibility-Audit. Oder sprechen Sie mit uns über Ihren konkreten Fall.