Barrierefreiheit mit KI sicherstellen: was heute schon geht (und was nicht)

Seit Juni 2025 ist das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft. Die meisten Teams wissen, dass sie etwas tun sollten, aber im Alltag geht das Thema meistens unter. Zu aufwendig, zu speziell, zu wenig Expertise im Team, außerdem gibt es ja Wichtigeres zu tun. Gleichzeitig explodiert das KI-Tooling. Die verlockende Frage liegt auf der Hand: Können wir uns mit Hilfe von KI den Aufwand sparen, Barrierefreiheit zu gewährleisten, oder sind wir weiterhin weit davon entfernt? Mit dieser Frage habe ich mich beschäftigt. Ich habe unterschiedliche KI-Tools und Vorgehensweisen ausprobiert, um zu schauen, wie weit man Stand Mai 2026 mit KI und Barrierefreiheit kommt. Meine Erkenntnisse möchte ich mit euch teilen.

KI und Barrierefreiheit: zwei Seiten

Allgemein kann uns KI von zwei unterschiedlichen Richtungen beim Thema Barrierefreiheit unterstützen: von der Nutzer*innensicht und von der Entwickler*innensicht.

Von der Nutzer*innenperspektive könnte KI beispielsweise helfen, indem sie visuelle Inhalte interpretiert und Nutzer*innen hilft, im Internet zu navigieren. Beispiele dafür sind Seeing AI, UserWay oder Be My AI, das verspricht:

„No more guessing. Whether it’s a menu, a document or a tricky interface, AI helps you navigate with confidence“.

Das bringt aber gewisse Risiken mit sich und hat auch seine Grenzen. Die Beschreibungen können ungenau oder gar fehlerhaft sein, und bei z.B. motorischen Einschränkungen hilft es gar nicht. Außerdem darf man nicht voraussetzen, dass Menschen mit Einschränkungen sich solche teuren Geräte oder Abonnements anschaffen. Daher bleibt die Verantwortung weiterhin bei uns Entwickler*innen, Barrierefreiheit zu gewährleisten.

Also: Wie kann uns KI auf der Entwickler*innenseite unterstützen? Das werden wir uns nun ansehen.

Wo stehen wir gerade

Bevor wir über Tools reden, ein kurzer Reality-Check. Automatisierte Accessibility-Testing-Engines wie axe-core erkennen je nach Studie zwischen 20 und 57% der WCAG-Violations. 

WCAG (Web Content Accessibility Guidelines) sind internationale Richtlinien zur barrierefreien Gestaltung von Websites und digitalen Inhalte.

Die oft zitierte 57% von Deque basiert aber auf einer geänderten Metrik, die Issues nach Häufigkeit statt nach WCAG-Kriterien zählt. Unabhängige Vergleichstests kommen auf deutlich niedrigere Werte. Die übrigen Violations lassen sich nicht automatisch erkennen und müssen manuell gesucht und bewertet werden.

Das liegt daran, dass sich verschiedene Aspekte der Barrierefreiheit unterschiedlich gut automatisieren lassen. Farbkontraste, fehlende Alternativtexte für Bilder oder fehlerhafte ARIA-Attribute (zusätzliche Informationen für Screenreader) kann ein Tool zuverlässig erkennen. Ob eine Überschriften-Hierarchie inhaltlich Sinn ergibt, wird schon schwieriger. Und ob ein Mensch mit Screenreader die Seite tatsächlich versteht und bedienen kann, müsste schon ein Mensch manuell prüfen. Oder geht's schon mit KI?

Das Experiment

Ich habe eine Anwendung genommen, die nicht ganz barrierefrei war, und versucht, sie nur mit KI-Tools zu verbessern. Ich habe auf explizite Accessibility-Checks bei E2E-Tests verzichtet und die Seite nicht manuell getestet. Stattdessen habe ich mich komplett auf KI-Tools verlassen. Die KI sollte anhand des Codes verstehen, was die Use Cases waren, und die Seite eigenständig testen. Im Idealfall sollten auch Komponenten mitgetestet werden, die nicht direkt sichtbar waren, z.B. Fehlermeldungen oder Toasts.

Dabei habe ich mehrere Ansätze ausprobiert: einen CI-Scanner, der automatisch Issues anlegt; Claude Code mit und ohne Tools; spezialisierte MCP-Server; und einen Zwei-Agenten-Workflow, der am Ende über zwanzig echte Probleme gefunden hat. Was dabei jeweils herauskam, möchte ich euch berichten.

Stufe 1: Der CI-Scanner: Scan and Fix

Zuerst die idealistische Vorstellung: Ein Tool scannt die fertige Anwendung, findet Probleme und behebt sie am besten gleich selbst. Der GitHub AI-powered Accessibility Scanner sollte genau das machen. Man definiert URLs, der Scanner prüft sie, macht währenddessen Screenshots, legt für jedes Problem ein GitHub Issue an und beauftragt optional Copilot, einen Fix als Pull Request zu erstellen. Die Idee hat mich sofort angesprochen: Abgesehen von der CI-Pipeline-Konfiguration muss man den Code nicht selbst anfassen, alles Weitere läuft automatisch.

Disclaimer: Stand Mai 2026 befindet sich der Scanner noch in der Public Preview und wird aktiv weiterentwickelt; die beschriebenen Einschränkungen können sich ändern.

In der Praxis bin ich dann auf Probleme gestoßen. Der Scanner hat sich erstmal nicht anmelden können, weil er im Login-Formular nach fest codierten Labels sucht: username und password. Wenn die Labels anders heißen oder die App nicht auf Englisch ist, steigt er aus. Das ließ sich mit einem Workaround lösen: Ich habe die Authentifizierung per API-Call vorab erledigt und die Session-Cookies übergeben.

Zu den echten Ergebnissen bin ich allerdings auch damit nicht gekommen: Der Scanner führt den axe-Scan aus, bevor React die Seite fertig gerendert hat, und prüft daher ein leeres DOM. Er hat Fehler gemeldet, die gar nicht existieren, und hat direkt mehr als 15 wiederholende Issues angelegt, eines pro URL. Das Problem mit dem leeren DOM konnte ich nicht lösen. 

Und letztendlich: Im Hintergrund läuft nur ein axe-Scan, das ist nicht wirklich „KI“. Es wird nur die initial geladene Ansicht geprüft, keine Modals, keine Formulare, keine Tastaturnavigation, kein VoiceOver und vor allem keine Einschätzung „ist es gut bedienbar?“. Auch wenn das Client-Side Rendering Problem gelöst wäre, mir war es den Aufwand nicht wert: Da kann man schneller selber axe-core in die bestehenden E2E-Tests einbauen, als das ganze Setup durchzuspielen.

Stufe 2: Claude Code

Der nächste Ansatz war simpler: Ich habe Claude Code mit einem maximal einfachen und bewusst allgemein gehaltenen Prompt „Mach meine App barrierefrei" beauftragt. Ohne zusätzliche Tools schaut Claude sich den Quellcode an und fixt, was er dort sieht.

Ich hatte erwartet, dass Claude nur ein paar offensichtliche fehlende aria-label-Attribute findet, aber er hat deutlich mehr gefunden, z.B.: 

• fehlende Button-Semantik, 
• nicht-fokussierbare Elemente mit Click-Handlern, 
• Kontrast-Probleme, 
• fehlende ARIA-Zustände, 
• <div>-Elemente die als Buttons fungieren, 
• Probleme mit der Heading-Hierarchie. 

Mit Playwright MCP - einer Schnittstelle, über die KI-Assistenten externe Browser-Tools aufrufen können - lässt sich der Ansatz erweitern: Claude kann die laufende App öffnen, durch Seiten navigieren, Laufzeitprobleme finden und sie direkt fixen. Er hat dabei Dinge entdeckt, die der statische Code-Review nicht finden konnte: 

• die Seitentitel aktualisierten sich beim Routenwechsel nicht
• eine Combobox hatte aria-label="null" als String - ein Runtime-Bug, der im Code wie eine gültige Variable aussieht
• klickbare Tabellenzeilen für Tastatur-Nutzer*innen waren teilweise nicht erreichbar
• das Login-Formular nutzte nur Placeholder statt echte Labels - im Code schwer erkennbar, da eine externe Komponentenbibliothek verwendet wird.

Die Seite ist dadurch besser geworden, aber von vollständiger Barrierefreiheit noch weit entfernt.

Das Problem ist die fehlende Systematik. Claude verweist zwar auf WCAG-Regeln, wenn er Probleme findet, aber er arbeitet keine Checkliste ab. Er läuft durch die App und fixt, was ihm auffällt. Playwright MCPs browser_snapshot hätte ihm den Accessibility-Tree zurückgeliefert, wurde aber gar nicht verwendet. Damit hätte er sehen können, welche Elemente für Screenreader keinen verständlichen Namen haben und welche Rollen fehlen oder falsch gesetzt sind. Auch die Landmark-Struktur aus Screenreader-Sicht wäre sichtbar gewesen. Stattdessen hat er sich auf das visuell Sichtbare verlassen. Am Ende war die App besser als vorher, ich hatte aber kein Vertrauen darin, was noch fehlte.

Stufe 3: MCP-Server für Accessibility 

Mit MCP können KI-Assistenten externe Tools aufrufen, die genau für die notwendige Aufgabe vordefiniert und entwickelt wurden. Von diesem Schritt habe ich mir erhofft, mit spezialisierten MCP-Servern für Accessibility einerseits mehr Systematik und Struktur zu gewinnen, und andererseits qualitativ bessere Ergebnisse zu erzielen.

Ich habe unterschiedliche Open-Source-MCP-Server ausprobiert. Leider hatten alle dasselbe Problem wie der GitHub Accessibility Scanner damit, sich anzumelden, wenn es um Live-Testing geht, aber bei einem Server konnte ich es mit einem Workaround lösen.

Der MCP-Server MCP Accessibility Scanner läuft als Docker-Container mit eigenem Playwright-Browser und bringt über 30 verschiedene Tools mit. Neben den üblichen Browser-Tools (navigate, click, type, screenshot) hat er dedizierte Accessibility-Tools:

Der Server konnte sich out of the box auch nicht einloggen, aber mit Hilfe von Claude und einem Workaround hat er das hingekriegt: Vite-Konfiguration angepasst, Login über native JavaScript-Setter statt über die eingebauten Tools. Das Ergebnis war qualitativ anders als bei den vorherigen Stufen: Ein systematischer Keyboard-Audit hat unsichtbare Focus-Stellen und Focus-Sprünge aufgedeckt. Außerdem fand er ein Touch-Target-Problem nach WCAG 2.2, was ein normaler axe-Scan gar nicht prüft. Alle Ergebnisse kamen als Reports mit konkreten WCAG-Referenzen zurück.

Der MCP-Server selbst findet Probleme und meldet sie, aber er versteht den Code nicht und schlägt keine Fixes vor. Außerdem testet er nur die angegebenen URLs im initialen Zustand, keine dynamischen Inhalte wie Dialoge oder Fehlermeldungen. Ein KI-Agent könnte die Findings zwar abarbeiten und Code ändern, aber ohne Fachwissen über Accessibility-Best-Practices wäre das Ergebnis nicht besser als in Stufe 2. Die nächste Frage war: Was passiert, wenn man spezialisierte Agenten einsetzt, die wissen, worauf sie achten müssen?

Stufe 4: Der Zwei-Agenten-Workflow

Ich möchte einen Schritt weiter gehen und auf Accessibility spezialisierte Agenten einsetzen. Bei Awesome GitHub Copilot findet man unterschiedliche Open-Source-Agenten. Ich habe einen Accessibility Expert und einen Accessibility Runtime Tester für das Projekt „angestellt“ und parallel laufen lassen. 

Der Accessibility Expert analysiert den Quellcode gegen WCAG 2.1/2.2: semantische Korrektheit, Keyboard- und Focus-Verhalten, ARIA-Rollen und -Zustände, Formular-Labeling, Focus-Management bei Modals, Live-Regions für dynamische Updates. Er folgt einem definierten Protokoll und prüft auch Komponenten, die gerade nicht auf dem Bildschirm sichtbar sind: der Unterschied zu Stufe 2.

Der Accessibility Runtime Tester navigiert per Tastatur durch die kritischen User-Flows, öffnet Dialoge und prüft Focus-Verhalten, injiziert axe-core mit WCAG-Filtern und nutzt `browser_snapshot`, um zu sehen welche Elemente für Screenreader keinen Namen haben. Die Leitfrage vom Tester ist: „Kann ein*e Keyboard-Nutzer*in diesen Flow von Anfang bis Ende abschließen?“.

Die beiden Agenten können ihre Findings verknüpfen, miteinander diskutieren und sich gegenseitig helfen. Der Accessibility Expert erkannte ein interaktives Element ohne Tastatur-Support im Code und der Runtime Tester bestätigte, dass es per Tastatur nicht erreichbar ist. Ein statischer Scan liefert nur eine der beiden Informationen.

Am Ende haben die Agenten viel mehr Probleme gefunden als Claude allein in der Stufe 2, mutmaßlich dank Best Practices und konkreten Auflistungen. Obwohl ich auch hier betonen musste, dass sie bitte ALLE Popups und Modals aufmachen sollen und sich ÜBERALL bitte durchklicken. 

Ein paar Fehler, die mit Tools des MCP-Servers in Stufe 3 gefunden wurden, haben die Agenten übersehen, dafür haben sie zusätzlich User-Flows geprüft. Was dabei neu dazukam:

• interaktive Elemente, die per Klick funktionieren, aber per Tastatur nicht erreichbar sind, weil role, tabIndex oder Keyboard-Handler fehlen
• Focus nach Schließen eines Dialogs: Focus springt zu <body> statt zurück zum auslösenden Element

Der Setup-Aufwand ist der geringste von allen getesteten Ansätzen: Zwei Markdown-Dateien ins Projekt legen, fertig. Kein npm install, kein Docker, keine CLI-Konfiguration. Das Ergebnis ist nicht deterministisch und eignet sich nicht als CI-Check, aber für eine einmalige strukturierte Prüfung, aus der man gezielte E2E-Tests ableiten kann, habe ich durchaus überzeugende Ergebnisse erzielen können.

Stufe 5: Agenten und MCP-Server kombinieren

Die logische Konsequenz aus allem: Die spezialisierten Agenten aus Stufe 4 zusammen mit dem MCP-Server aus Stufe 3 einsetzen. Wenn der Accessibility Runtime Tester Zugriff auf die Tools des MCP-Servers hat, kann er diese direkt in seinen Testing-Workflow einbauen, statt alles manuell zu navigieren.

Der MCP-Server liefert Messungen: Kontrast-Verhältnisse, Pixel-Größen, Tab-Reihenfolgen. Der Agent interpretiert sie, verknüpft sie mit dem Code und kann beurteilen, ob ein Problem eine*n Nutzer*in tatsächlich blockiert. Die Tools liefern mehr Kontext, wodurch wir hoffentlich präzisere Findings erwarten können.

Die Kombination aus spezialisierten Agenten und MCP-Servern liefert mehr als jeder Ansatz allein: deterministische Messwerte durch die MCP-Tools, kontextuelles Verständnis durch den Agenten, und User Flows, die ein reiner Scanner nie abdeckt.

Fazit

Kann man mit KI allein eine vollständig barrierefreie Anwendung bauen? Nach meinen Experimenten: noch nicht. Aber man kommt deutlich weiter, als ich erwartet hätte. 

Es erlaubt vor allem, schnell und ohne Fachwissen eine Menge offensichtlicher Probleme zu finden und zu beheben, und die Anwendungen barrierefreier als vorher zu machen, aber eben nicht zu 100%, auch wenn KI das behauptet. Denn: „Das Tool sagt, es ist okay" heißt nicht „Es ist okay".

Das zeigt uns nochmal das Beispiel der Accessibility-Overlays: Tools wie accessiBe haben versprochen, jede Website per KI-Widget barrierefrei zu machen. Die US-amerikanische FTC hat das Unternehmen Anfang 2025 wegen irreführender Claims zu einer Million Dollar Strafe verpflichtet. 

Die spezialisierten Agenten schaffen es teilweise, dynamische Elemente wie Toasts, Fehlermeldungen oder Dialoge zu triggern und zu prüfen, aber eben nicht alle. Mit dokumentierten User Stories als Input wäre das vermutlich zuverlässiger, vorausgesetzt, die Dokumentation existiert bereits. Und selbst dann: Ob VoiceOver einen Button im richtigen Moment ankündigt, hängt vom Kontext und von der Reihenfolge der Interaktionen ab. Nicht-technischen Anforderungen, die Kontextwissen erfordern, kann kein Tool bewerten: Ist die Seitenstruktur logisch? Sind Formularelemente sinnvoll beschriftet? Ist das Error-Handling verständlich?

Das Ökosystem entwickelt sich rasant. Was vor einem Jahr nicht existiert hat, ist heute als Open-Source-Projekt verfügbar und funktioniert: MCP als Standard, spezialisierte Accessibility-Agenten, axe-core direkt in der IDE. Die Tools sind noch jung, aber die Richtung stimmt. KI macht Accessibility-Audits heute schon deutlich effizienter, ersetzt aber weder das Verständnis dafür, was Barrierefreiheit wirklich bedeutet, noch die manuelle Validierung.