KI kann Barrieren überbrücken - aber nicht Barrierefreiheit ersetzen

Am 28. Juni jährt sich das Barrierefreiheitsstärkungsgesetz (BFSG) erstmals. Seitdem gelten für viele private Anbieter verbindliche Anforderungen an barrierefreie digitale Produkte und Dienstleistungen; vom Webshop über Banking-Apps bis zu Angeboten im Personenverkehr.

Im öffentlichen Sektor ist digitale Barrierefreiheit bereits seit Jahren Pflicht: Öffentliche Stellen müssen Websites, Apps und Verwaltungsprozesse nach BITV 2.0 beziehungsweise den landesrechtlichen Regelungen barrierefrei gestalten. Mit der Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF) nimmt nun auch die Aufsicht über das BFSG Gestalt an.

Warum das mehr ist als ein Compliance-Thema, zeigt eine alltägliche Situation: Ein Nutzer mit eingeschränkter Feinmotorik, etwa infolge einer rheumatoiden Arthritis, möchte online einen Arzttermin buchen. Weil präzise Mausbewegungen schmerzhaft oder unsicher sind, nutzt er Tastatur oder Sprachsteuerung. Doch der Kalender funktioniert nur per Drag-and-drop, der Fokus springt unvorhersehbar über die Seite, ein Dialogfenster lässt sich nicht per Tastatur schließen. Was für andere ein ärgerlicher UX-Fehler ist, wird für ihn zur Barriere und verhindert die selbstständige Nutzung.

Hier kann KI als Assistenz für Menschen mit Behinderung einen Mehrwert schaffen: Sie kann Oberflächen erklären, Inhalte zusammenfassen, Sprache in Eingaben übersetzen, Bilder beschreiben oder alternative Bedienwege unterstützen. Für Menschen mit Behinderung kann das mehr Autonomie bedeuten. Aber KI überbrückt Barrieren nur. Sie ersetzt keine barrierefreie Anwendung. Wenn Bedienelemente falsch umgesetzt, Inhalte schlecht strukturiert oder Prozesse nicht per Tastatur nutzbar sind, bleibt die Verantwortung bei den Teams, die digitale Produkte entwickeln und testen.

Für IT-Teams ist digitale Barrierefreiheit keine nachgelagerte Spezialprüfung, sondern eine Engineering-Aufgabe. Die fachliche Grundlage bilden Standards wie die EN 301 549 und die Web Content Accessibility Guidelines (WCAG). In der Praxis geht es darum, digitale Angebote wahrnehmbar, bedienbar, verständlich und robust zu machen.

Das wird im Entwicklungsalltag konkret: Ist eine Funktion ohne Maus nutzbar? Sind Formulare verständlich beschriftet? Werden Informationen nicht nur über Farbe vermittelt? Funktionieren Inhalte auch mit Screenreader, Tastatur, Vergrößerung oder Sprachsteuerung?

KI-Copiloten können Entwicklungsteams unterstützen, etwa indem sie auf typische Lücken hinweisen, Testideen formulieren oder Anforderungen konsistenter umsetzen helfen. Der Nutzen entsteht aber nur mit klaren Qualitätsvorgaben. Ein Prompt wie „Mach die Anwendung barrierefrei“ reicht nicht aus. Dabei sieht der Code auf den ersten Blick funktionsfähig aus, enthält aber häufig typische Accessibility-Probleme. Dazu gehören klickbare Divs ohne Tastaturunterstützung, modale Dialoge ohne Fokusmanagement, Formulare ohne Labels oder ARIA-Attribute (Accessible Rich Internet Applications), die mehr Schaden als Nutzen erzeugen. Besser ist es, Anforderungen aus den verpflichtenden technischen Standards (EN 301 549 und WCAG) in User Stories, Akzeptanzkriterien und Tests zu übersetzen: Welche Bedienwege, Nutzergruppen und Kriterien müssen berücksichtigt werden?

KI beschleunigt also nicht automatisch Barrierefreiheit. Sie beschleunigt das, was ein Team fachlich gut steuert.

Wer Barrierefreiheit wirksam testen will, muss die Stärken und Grenzen der einzelnen Verfahren kennen. Klassische automatisierte Tests, KI-gestützte Prüfungen und manuelle Reviews leisten Unterschiedliches. Erst im Zusammenspiel entsteht ein belastbares Bild der tatsächlichen Zugänglichkeit.

Klassische automatisierte Tests arbeiten regelbasiert. Tools wie axe, Lighthouse, Pa11y oder WAVE prüfen HTML, CSS und den aktuellen DOM-Zustand (Document Object Model) auf bekannte Muster wie fehlende Formularlabels, zu geringe Kontraste oder leere Buttons. Ihr Vorteil ist Geschwindigkeit: Sie lassen sich in Pull Requests, CI/CD-Pipelines und Live-Monitoring einsetzen und machen technische Fehler früh sichtbar.

KI-gestützte Tests können visuelle Muster erkennen, potenzielle Barrieren hervorheben, Befunde gruppieren, Reports vorbereiten oder bei der Priorisierung unterstützen. Ihr Vorteil liegt in der Strukturierung großer Ergebnismengen. Gerade bei semantischen Fragen bleibt menschliche Bewertung entscheidend. Beispiel Alternativtext: KI kann beschreiben, was auf einem Bild sichtbar ist. Sie weiß aber nicht zuverlässig, ob ein Bild informativ, funktional, dekorativ oder nur stimmungsbildend eingesetzt wird und welcher Aspekt des Bildes hervorgehoben werden soll.

Manuelle Tests bleiben unverzichtbar. Ob eine Fokusreihenfolge sinnvoll ist oder eine Bildschirmlese-Software für blinde Menschen eine Oberfläche verständlich vermittelt, lässt sich nicht vollständig automatisieren.

Automatisierte Tests finden technische Regelverstöße. KI unterstützt bei Erkennung und Auswertung. Die Nutzungserfahrung muss weiterhin durch Expertinnen und Experten sowie idealerweise mit Nutzerinnen und Nutzern geprüft werden.

Mit KI-gestützter Entwicklung und Vibe Coding verschiebt sich Barrierefreiheit noch weiter nach vorn. Wenn Code, Komponenten oder Designentwürfe aus Prompts generiert werden, werden Anforderungen und Testfälle zur Steuerungsgrundlage. Was dort nicht beschrieben ist, wird häufig auch nicht zuverlässig umgesetzt.

Damit gewinnt ein testgetriebener Ansatz neue Bedeutung. Accessibility-Anforderungen müssen bereits in User Stories, Akzeptanzkriterien, Designvorgaben und Testfällen enthalten sein und nicht erst im nachgelagerten Audit. Requirements Engineers und Test Designer werden dadurch zu zentralen Rollen. Sie müssen wissen, welche Anforderungen aus Gesetzen und technischen Standards relevant sind und wie diese prüfbar formuliert werden.

Der Human-in-the-Loop-Ansatz wird an mehreren Stellen entscheidend: vor der Codegenerierung bei Anforderungen, Prompts und Testfällen; während der Umsetzung durch automatisierte Prüfungen in der Pipeline; nach der Generierung durch manuelle Reviews zu Semantik, Bedienlogik und Nutzungserfahrung. So wird Shift Left zur neuen Qualitätslogik: Barrierefreiheit wird als prüfbare Anforderung formuliert, durch Tests abgesichert, durch KI schneller umgesetzt und durch menschliche Expertise validiert.

1. Barrierefreiheit als Akzeptanzkriterium definieren.
2. Standards in Design-Systeme übersetzen, etwa in geprüfte Komponenten, Vorlagen und Checklisten.
3. Automatisierte Tests verbindlich in Pull Requests und Pipelines integrieren, aber nicht als alleinige Konformitätsnachweis verstehen.
4. Kritische Nutzerreisen wie Registrierung, Login, Suche, Bezahlung oder Self-Service regelmäßig mit Tastatur, Screenreader und weiteren assistiven Technologien prüfen.
5. KI gezielt einsetzen, aber Ergebnisse kontrollieren, beispielsweise bei Alternativtexten, einfacher Sprache, Testfällen oder Codevorschlägen.

Ein Jahr BFSG ist ein guter Zeitpunkt für eine ehrliche Zwischenbilanz. Viele digitale Angebote scheitern nicht an hochkomplexen Sonderfällen, sondern an Grundlagen: Kontrast, Struktur, Beschriftung, Tastaturbedienung, Fokusführung und verständliche Fehlermeldungen. Genau diese Grundlagen lassen sich mit klaren Standards, automatisierten Tests und KI-Unterstützung deutlich besser in den Entwicklungsalltag integrieren.

Der entscheidende Punkt ist jedoch: KI nimmt Unternehmen die Verantwortung nicht ab. Sie macht gute Prozesse schneller und schlechte Prozesse riskanter. Wer Barrierefreiheit erst am Ende eines Projekts prüft, wird auch mit KI vor allem schneller Fehler finden. Wer sie von Anfang an in Requirements, Design, Code und Test integriert, verbessert digitale Qualität für alle.

Digitale Barrierefreiheit gehört damit in dieselbe Kategorie wie Datenschutz, IT-Sicherheit und Performance: Sie ist kein Add-on, sondern ein Qualitätsmerkmal moderner Softwareentwicklung. Das BFSG macht diesen Anspruch verbindlich. KI kann helfen, ihn skalierbar umzusetzen. Erfüllen müssen ihn weiterhin Menschen, Teams und Organisationen.