Wie KI Barrierefreiheit unterstützen kann

Barrierefreiheitstests prüfen, ob Webanwendungen die Kriterien der WCAG erfüllen, einem internationalen Normkatalog mit über 80 Prüfpunkten. Rund 20 bis 25 davon lassen sich mit klassischen Werkzeugen automatisieren. KI-Sprachmodelle können zusätzlich sprachbezogene Kriterien übernehmen, etwa ob Überschriften zum Seiteninhalt passen. Clustering-Algorithmen helfen, aus einer großen Seitenmenge sinnvolle Prüfrepräsentanten auszuwählen.

Das Wichtigste in Kürze

• Barrierefreiheitstests laufen heute mit einem unproduktiven Werkzeugmix aus Word, Excel, Screenreader und Browser ab, der durch eine integrierte Testumgebung ohne Medienbrüche ersetzt werden sollte.
• Von über 80 WCAG-Kriterien lassen sich heute nur rund 20 bis 25 mit bestehenden Standardwerkzeugen automatisiert prüfen, der Rest erfordert weiterhin manuelle Arbeit.
• Sprachliche WCAG-Kriterien wie die Übereinstimmung von Überschrift und Textinhalt kann GPT-4 zuverlässig bewerten, visuelle Prüfungen wie das Erkennen von kaputten Layouts funktionieren mit aktuellen Modellen noch nicht ausreichend gut.
• Ein Crawler kombiniert mit Clustering-Algorithmen reduziert den manuellen Aufwand beim Barrierefreiheits-Audit, indem er Seiten nach relevanten Attributen wie eingebetteten PDFs oder Videos automatisch gruppiert und Repräsentanten vorschlägt.

Barrierefreiheitstests werden ab 2025 für viele Unternehmen zur Pflicht

Der European Accessibility Act zwingt ab Juni 2025 auch private Unternehmen, ihre digitalen Angebote barrierefrei zu gestalten. Im öffentlichen Bereich gilt diese Pflicht schon länger. Banken und Versicherungen bereiten sich seit Jahren darauf vor, weil Verstöße gegen die Regeln Konsequenzen haben.

Der Aufwand dahinter ist beträchtlich. Auf den Ausschreibungsportalen tauchen Testaufträge in Größenordnungen von vielen Personentagen auf. Wer eine größere Webanwendung prüfen muss, hat es nicht mit ein paar Stichproben zu tun, sondern mit einem strukturierten Prozess über viele Seiten hinweg.

Die fachliche Grundlage liefern die WCAG, ein international anerkannter Kriterienkatalog. Er beschreibt mit über 80 Kriterien, was erfüllt sein muss, damit eine Webseite als barrierefrei gilt. Daneben gibt es Länderverordnungen und EU-Recht, die diese Norm aufgreifen.

Welche Barrierefreiheitskriterien lassen sich automatisiert testen?

Von den über 80 WCAG-Kriterien gelten aktuell etwa 20 bis 25 als mit Standardwerkzeugen automatisierbar. Es existieren Open-Source-Tools, die diese Prüfungen abdecken und von vielen Teams bereits eingebunden werden.

Diese Werkzeuge arbeiten überwiegend mit Daten, die sich aus dem Rendering einer Seite extrahieren lassen. Kontrastwerte zwischen Text und Hintergrund sind ein typisches Beispiel: Sie ergeben sich direkt aus dem dargestellten Layout und sind objektiv prüfbar.

Der Rest bleibt manuelle Arbeit. Realistisch wird sich kein Verfahren absehbar alle 80 Kriterien automatisiert abprüfen lassen. Ein Teil davon braucht menschliches Urteil, etwa wenn es um Interpretation und Kontext geht.

Wie ein Barrierefreiheitsaudit abläuft

Ein Audit folgt einem definierten Vorgehensmodell, das als Ergänzung zur WCAG existiert und in groben Schritten beschreibt, wie man vorgeht. Der Ablauf ist nachvollziehbar und enthält nichts Magisches.

Die einzelnen Schritte:

1. Webseite erfassen. Verschaffe dir einen Überblick, wie die Anwendung aufgebaut ist.
2. Technologien identifizieren. Prüfe, welche Techniken auf der Seite eingesetzt werden.
3. Seitentypen bestimmen. Finde heraus, welche Arten von Seiten es gibt, etwa 20 unterschiedliche Typen statt 10.000 Einzelseiten.
4. Repräsentanten auswählen. Ziehe eine Stichprobe pro Seitentyp und dokumentiere jede Entscheidung, damit das Ergebnis später nachvollziehbar bleibt.
5. Kriterien prüfen. Gehe für jeden Repräsentanten den Kriterienkatalog durch.
6. Dokumentieren. Schreibe das Ergebnis auf.

Die Dokumentation zieht sich durch den gesamten Prozess. Welche Seitentypen ausgewählt wurden und warum, muss festgehalten werden, sonst ist das Audit nicht prüfbar.

Der größte Schmerz steckt im Werkzeug-Wust, nicht in der Prüfung selbst

Wer heute Barrierefreiheit testet, jongliert mit einer Vielzahl von Werkzeugen. Befunde landen in Word, Seitenlisten in Excel, für die Prüfung selbst braucht es einen Screenreader, ein Open-Source-Testwerkzeug und natürlich den Browser. Screenshots werden gemacht, eingefügt, kopiert.

Diese Medienbrüche kosten Zeit und Nerven. Gerade wenn viele Seiten zu prüfen sind, wird das Hin und Her zwischen den Anwendungen zum eigentlichen Hemmnis, nicht die fachliche Prüfung.

Ein Vergleich mit der Softwareentwicklung macht das Problem deutlich. Entwickler haben eine ähnliche Ausgangslage: Code, Compiler, Testframeworks, Ausführungsumgebung, Datenbank-Tools. Moderne Entwicklungsumgebungen bündeln all das über Plug-in-Architekturen in einer Oberfläche.

Genau dieses Prinzip fehlt beim Barrierefreiheitstesten. Eine integrierte Testumgebung, in der Tester ohne Medienbrüche arbeiten, Werkzeuge verlinken und neue Funktionen ergänzen können, ohne den Arbeitskontext zu verlassen, würde den größten Hebel bringen. Übrigens: ein Dark Mode gehört für die meisten Anwender selbstverständlich dazu.

KI hilft dort, wo Sprachverständnis gefragt ist

Künstliche Intelligenz spielt ihre Stärke bei Barrierefreiheitstests vor allem in sprachlichen Aufgaben aus. In der Domäne Sprache sind die aktuellen Sprachmodelle schon gut, und dort lohnt sich ihr Einsatz auch wirklich.

Ein konkretes Beispiel ist das Kriterium, dass eine Überschrift zum dazugehörigen Text passen muss. Diese Prüfung ist auch für Menschen nicht trivial und nicht eindeutig, es gibt Interpretationsspielraum.

Ein praktikabler Ansatz sieht so aus: Ein Werkzeug extrahiert für eine gegebene Seite die Überschriften samt zugehörigen Textbausteinen und schickt einen entsprechenden Prompt an ein Sprachmodell. Das Modell bewertet, wie gut Überschrift und Text zusammenpassen. Die Ergebnisse aus solchen Evaluationen sind durchweg gut genug, um sie produktiv durchzuwinken.

Bei aller Begeisterung lohnt sich Zurückhaltung. KI taugt nicht als Allzwecklösung für jedes Testproblem. Wer KI heute überall draufschreibt, macht sich eher verdächtig, weil das Thema mit zu hohen Erwartungen daherkommt. Die bessere Frage lautet: Welches Problem soll das Werkzeug an dieser Stelle konkret lösen?

Warum visuelle Fehlererkennung per KI noch nicht trägt

Ein KI-Modell zuverlässig erkennen zu lassen, ob eine Seite optisch kaputt ist, hat im ersten Anlauf nicht funktioniert. Die Idee war reizvoll: Ein Screenshot rein, und das Modell meldet ein gebrochenes Layout oder andere visuelle Defekte.

Solche Modelle muss man erst trainieren, und dafür braucht es gelabelte Daten. Künstlich kaputtgemachte Seiten wurden über mehrere Wochen Kunden in einer kleinen Web-Anwendung gezeigt, mit der Frage, ob die Seite kaputt aussieht oder nicht. Das Labeling lief als Wettbewerb mit Verlosung.

Trotz dieser Trainingsdaten reichte die Erkennungsgenauigkeit im ersten Schritt nicht aus. Das Ziel dahinter bleibt attraktiv: Ein Sensor, der bei jeder ohnehin laufenden Testausführung im Hintergrund mitläuft und bemerkt, dass eine getestete Anwendung optisch kaputt ist. Die meisten automatisierten Tests prüfen solche nicht-funktionalen Aspekte nicht großflächig ab.

Wie ein intelligenter Crawler die Seitenauswahl beschleunigt

Den Überblick über alle Seiten einer Anwendung zu gewinnen, ist einer der aufwendigsten Schritte im Audit, und genau hier hilft Automatisierung am direktesten. Manuell eine Landkarte aller Seiten zu erstellen, ist mühsam.

Ein Crawler, der ausgehend von einer oder mehreren Start-URLs die Anwendung durchläuft, übernimmt diese Kartierung. Crawler sind keine neue Erfindung, und auch die alten Probleme bleiben: Wann erkennst du, dass du wieder auf derselben Seite gelandet bist, obwohl sich nur ein Datum, eine Uhrzeit oder eine eingeblendete Werbung geändert hat? Diese Zustandsabstraktion ist die Kernschwierigkeit, dazu der Umgang mit Formularen und Formulardaten.

Statt den Crawler immer schlauer zu machen, hilft eine Kombination mit Clustering. Der Crawler läuft erst einmal los, danach gruppiert ein Clustering-Algorithmus die gefundenen Seiten anhand von Attributen, die aus Barrierefreiheitssicht relevant sind, etwa ob eine Seite ein PDF oder ein Video enthält.

So lassen sich sinnvolle Repräsentanten finden, ohne zehn ähnliche Seiten doppelt zu testen. Das spart Arbeit und liefert dem Tester aufbereitete Gruppen: hier alle Seiten mit PDFs, dort alle mit Video. Das Sammeln und Vorsortieren in dieser Phase nimmt dem Menschen viel ab, gerade weil die manuelle Prüfung danach ohnehin bleibt.

Lokale Sprachmodelle scheitern noch am Datenschutz-Anspruch

Für die sprachlichen Prüfungen ist OpenAI aktuell der Goldstandard, weil kein anderes Modell mit diesen Aufgaben so gut zurechtkommt. Das bringt zwei Probleme mit sich.

Erstens ist die API-Anbindung nicht stabil genug. Wenn die Status-Seite rot wird, schlägt das direkt in der eigenen Anwendung durch. Zweitens stellt sich beim Datenschutz schnell die Frage, wohin diese Daten eigentlich geschickt werden, gerade wenn Kunden auf den deutschen Datenraum beschränkt sind.

Deshalb ist lokales Modell ein wichtiges Thema für die Zukunft. Die Hoffnung liegt darauf, ein allgemein trainiertes Open-Source-Sprachmodell wie Llama auf den speziellen Use-Case nachzutrainieren. Im ersten Schritt hat das noch nicht gut funktioniert, hier ist OpenAI deutlich voraus.

Iterativ ausliefern und Anwender früh einbinden

Der sinnvollste Weg ist, einen ersten Satz funktionierender Werkzeuge auszuliefern und das Feedback der Anwender direkt einfließen zu lassen. Statt auf das große, fertige System zu warten, kommen vier oder fünf zusätzlich automatisierbare Kriterien zuerst in die Hand der Tester.

Die Botschaft an den Nutzer lautet: Hier ist ein Satz Werkzeuge, der funktioniert. Diese Kriterien lassen sich zusätzlich zum bisher Möglichen automatisiert prüfen, arbeite damit und sag uns, wie es sich anfühlt. Alles Weitere kommt Schritt für Schritt dazu.

Dieser Ansatz hält die Entwicklung nah an den echten Problemen der Anwender. Vor jeder KI-Funktion steht die Frage, was das Werkzeug konkret besser macht, nicht die Technologie als Selbstzweck. Eine offene Frage bleibt dabei, wie transparent man den KI-Einsatz machen sollte: Freut sich der Nutzer einfach über einen Button namens “Analyze”, oder will er wissen, was im Hintergrund passiert?