KI ist überall, und Testautomatisierung ist keine Ausnahme. Accessibility-Testing (A11y) ist Teil von diesem Wandel. Jahrelang haben wir uns auf regelbasierte Scanner verlassen, die wie starre Gatekeeper arbeiten: sie sind sehr gut darin zu prüfen, ob Markup und Attribute vorhanden sind, aber weiterhin schwach darin zu verstehen, wie eine Seite tatsächlich gerendert wird, wie Layout Bedeutung beeinflusst und ob Inhalte für echte Nutzer sinnvoll sind.
Wir bewegen uns endlich von „Info ist vorhanden“ zu „Info ist sinnvoll und korrekt“. Das ist ein großer Schritt. Statt isolierter Checks können wir semantische Struktur, visuelles Rendering und Sprachqualität in einem Durchlauf zusammenbringen und Feedback erhalten, das viel näher an dem liegt, was menschliche Reviewer finden würden. KI-Verbesserungen gehen aber über reines Scanning hinaus: Sie verbessern den gesamten Ablauf von Erkennung über Triage bis zu kontextbewussten Fixes.
Wo KI die Grenzen regelbasierter Prüfung durchbricht
Die Standardautomatisierung tut sich schwer mit WCAG-Erfolgskriterien, die menschenähnliches Urteilsvermögen erfordern. KI sollte jedoch nicht statische Regeln ersetzen – statische Regeln sind schnell und günstig, während KI im Vergleich deutlich resourcenaufwändiger ist. Der Punkt ist: KI sollte das übernehmen, was statische Regeln nicht können, und sie durch Kontextbewusstsein ergänzen.
Schauen wir zuerst auf das, was bereits funktioniert. SC 1.1.1 (Nicht-Text-Inhalte): KI-Experimente haben bereits gezeigt, dass wir validieren können, ob Alt-Text ein Bild tatsächlich korrekt beschreibt – nicht nur, ob Alt-Text vorhanden ist. Wie ich in einem früheren Beitrag über KI-erweiterte Scanner beschrieben habe, verschiebt sich der Fokus von der bloßen Existenz eines Alt-Textes hin zu dessen Sinnhaftigkeit. Während statische Regeln das Vorhandensein prüfen, übernimmt die KI den semantischen Abgleich.
Basierend auf meiner Erfahrung ist Folgendes eine erste Sammlung an „Easy Wins“, die ich mir gut vorstellen kann. Einige Fähigkeiten existieren bereits in benachbarten Workflows und müssen „nur“ in Accessibility-Scanner integriert werden, während andere eher persönliche Erwartungen sind, basierend auf KI-Stärken und Verbesserungspotenzial. Die Liste ist natürlich nicht vollständig, und ich bin sicher, es gibt weitere kreative Ideen, bei denen KI eine wertvolle Ergänzung sein kann.
SC 1.3.1 – Informationen und Beziehungen
Der erste Easy Win ist hier die Integrität von Hierarchien: Verläuft die Heading-Struktur logisch, und werden Ebenen übersprungen oder fehlen sie auf eine Weise, die die Dokumentstruktur bricht? Genau das können KI-Code-Reviewer heute bereits in HTML- und Markdown-Markup erkennen.
Auch hier geht es also weniger darum, eine völlig neue Fähigkeit zu erfinden, sondern eher darum, eine bestehende Fähigkeit in Accessibility-Scanner zu integrieren.
Eine natürliche Erweiterung wäre das Erkennen pseudo‑Überschriften – entweder über visuelle Merkmale oder über erfahrungsbasierte Hinweise wie heading‑ähnliche Klassennamen ohne echtes Heading‑Markup.
SC 3.1.5 – Leseniveau
Kognitive Barrierefreiheit ist wichtig, und auch hier kann KI-Code-Review heute bereits helfen. Sie kann Abkürzungen und Akronyme in HTML- oder Markdown-Inhalten erkennen und dann Vorschläge für einfache Sprache machen oder zumindest korrektes Markup empfehlen, das eine Abkürzung mit ihrer Definition verknüpft.
Wie beim vorherigen Beispiel wirkt auch das weniger wie ein Greenfield-Problem und mehr wie die Integration einer bereits nützlichen Fähigkeit in den größeren Accessibility-Testfluss.
SC 1.3.2 – Sinnvolle Reihenfolge
Moderne CSS-Layoutmöglichkeiten wie Flexbox, Grid und nun auch grid-lanes aka. Masonry geben uns enorme visuelle Flexibilität, bedeuten aber auch, dass Markup-Reihenfolge und visuelle Lesereihenfolge nicht mehr zwingend synchron sind. Ein Grid-Item, das im DOM zuletzt steht, kann visuell zuerst erscheinen, und keines der heute üblichen Tools wird das als Accessibility-Problem erkennen.
Genau diese Diskrepanz hat Browser-Ingenieurinnen Rachel Andrew dazu motiviert, auf eine saubere Lösung für Lesereihenfolge zu dringen, bevor Masonry-Layout ausgerollt wurde. Sie hat über das Problem und erste Lösungsansätze in Reading order and CSS layout geschrieben – lesenswert, falls du den Beitrag noch nicht kennst. Das Ergebnis ist die neue CSS-Eigenschaft reading-flow.
Ich glaube, KI könnte Abweichungen zwischen visueller Lesereihenfolge und DOM-Reihenfolge erkennen, besonders in diesen komplexen Layout-Szenarien. Historisch bedeutete ein Auseinanderlaufen von Layout und Markup-Reihenfolge oft, dass das Layout selbst umgebaut werden musste – ein Kompromiss, den Designer und Entwickler häufig nicht eingehen wollten. Dass KI das Problem markiert, machte die Lösung also nicht automatisch einfacher. Aber reading-flow ändert das: Es gibt Entwickler die Möglichkeit, die beabsichtigte Lesereihenfolge zu deklarieren, ohne das visuelle Layout anzufassen.
Dadurch wird KI-Erkennung dieser Abweichungen in der Praxis deutlich nützlicher. Statt einer reinen Warnung liefert das System nun den Impuls für eine gezielte Korrektur, ohne bestehende Strukturen zu beeinträchtigen.
Um es klar zu sagen: Es ist nicht die Aufgabe von KI, reading-flow anzuwenden. Die Rolle der KI ist hier Erkennung und Wahrnehmung; der Fix bleibt eine bewusste Entwicklerentscheidung.
SC 1.4.3 & 1.4.11 – Kontrast
Ich sehe Potenzial dafür, dass KI Kontrasttests verbessern kann, aber seien wir ehrlich: Das ist der fragilste Check in dieser Liste. Allerdings gilt das auch für manuelle Kontrasttests – in komplexen Rendering-Szenarien ist die Bewertung wirklich schwierig.
Aktuelle statische Tools haben bereits in bekannten Situationen Probleme: wenn der Hintergrund keine einheitliche Farbe ist oder wenn Inhalte und Hintergrundelemente nicht im selben Stacking Context liegen. Wie ich in einem früheren Beitrag über die Grenzen von Kontrasttools beschrieben habe, führen diese Edge Cases oft zu falschen Ergebnissen oder werden einfach übersprungen. KI könnte diese Lücken potenziell schließen, indem sie den tatsächlich gerenderten Output analysiert, statt sich nur auf berechnete CSS-Werte zu verlassen.
Die Herausforderung ist, dass diese Art pixelgenauer Analyse über Breakpoints und Layout-Zustände hinweg in frühen Versionen wahrscheinlich fragil wäre und sorgfältig kalibriert werden müsste, um nützlich statt noisy zu sein.
Ein Wort zu False Positives
Nach allem, was ich gesehen habe, verursachen KI-gestützte Scanner-Erweiterungen eher False Positives als regelbasierte Checks, besonders in frühen Versionen. Das Verhältnis von False Positives zu echten Findings könnte entscheidend für die Akzeptanz sein. Zu viele Fehlalarme erzeugen Alarmmüdigkeit und Ablehnung. Deshalb sollten KI-Erweiterungen immer auf statischen Regeln aufbauen und sie nicht ersetzen.
Von Findings zu Action: Triage und Fixes
Den Bug zu finden ist nur 20% der Aufgabe. Die eigentliche Entwicklungshürde entsteht beim Überführen einer Liste von Verstößen in einen klaren, umsetzbaren Plan. Das gilt unabhängig davon, ob Findings aus automatischen Scannern, manuellen Tests oder formalen Accessibility-Audits kommen. Genau hier hat KI genauso viel zu bieten wie beim Erkennen von Fehlern.
Gruppierung und Priorisierung
KI kann sogar vor der eigentlichen Triage helfen, indem sie Verstöße aus Audit-Reports und Dokumentation extrahiert und in priorisierbare Items im bestehenden Tracking-Workflow des Teams überführt. Findings an die richtige Stelle zu bringen, ist bereits die halbe Miete.
Aber Tickets zu haben ist nur der Anfang. In einem kürzlichen Projekt hatten wir drei getrennte Tickets: eines für den Fokusindikator eines Video-Players, eines für die Verbalität von Controls und eines für einen bestimmten Button. Das Problem war nicht die Anzahl der Tickets, sondern die fehlende Verbindung zwischen ihnen. Ohne diesen Zusammenhang arbeiten Entwickler möglicherweise jedes Thema isoliert ab, was zu doppelter Arbeit oder sogar widersprüchlichen Lösungen führen kann.
KI ist hervorragend in Mustererkennung. Sie kann diese drei Verstöße analysieren, erkennen, dass alle vom gleichen VideoPlayer-Component ausgehen, und sie zu einer einzelnen Refactoring-Aufgabe gruppieren. So wird aus einem unübersichtlichen Backlog eine klare, priorisierte Roadmap.
Kontextbewusste Fixes vs. Copy-Paste-Desaster
Wir kennen es alle: Ein Entwickler sieht einen A11y-Fehler, kopiert den „Suggested Fix“ aus einer statischen Doku-Seite und macht die Experience unbeabsichtigt schlechter, weil der Vorschlag den umgebenden Code nicht berücksichtigt.
KI liefert nicht nur einen Fix; sie liefert einen harmonischen Fix. Wenn man der KI den konkreten Code-Ausschnitt, den WCAG-Verstoß und eigene Anweisungen (z.B. allgemeine A11y-Best-Practices oder framework-spezifische Accessibility-Praktiken) gibt, kann sie eine Lösung erzeugen, die das bestehende Framework, State-Management und ARIA-Patterns respektiert. Das verschiebt uns von „möglichen Fixes“ zu „ready-to-merge Code“.
Die Lücke zwischen Audit und Code schließen
Audits sind oft die „Source of Truth“, bringen aber eine große Hürde mit: Tester sind selten Entwickler.
Tester können beschreiben, was sie erwarten – einen per Tastatur bedienbaren Media-Player, einen korrekt angekündigten Button, eine logische Fokusreihenfolge -, aber es ist nicht ihre Rolle zu spezifizieren, wie das umgesetzt wird. Das ist die Aufgabe von Entwicklern und Accessibility Experten, die technische Rahmenbedingungen, Framework-Konventionen und manchmal die Grenzen nativer Browser-Features abwägen müssen.
Ein Finding kann zu einem kleinen Fix, einem Component-Refactor oder sogar zu einer bewussten Abkehr von einem nativen Element hin zu einer Custom-Lösung führen. KI kann helfen, diese Lücke zu schließen, indem sie Audit-Findings mit der realen Codebase abgleicht und technisch belastbare Richtungen vorschlägt, statt Entwickler mit der reinen Testerbeschreibung allein zu lassen.
Die Gatekeeping-Herausforderung: Blick auf WCAG 3.0
Wie Karl Groves in seinem Artikel What I Like About WCAG 3.0 beschreibt, führt WCAG 3.0 Nuancen wie klare Sprache und algorithmische Fairness ein – Themen, die sich der traditionellen Automatisierung von Natur aus widersetzen.
Wenn wir unsere Tools nicht weiterentwickeln, riskieren wir, Gatekeeping ganz ans Ende des Entwicklungszyklus zu verschieben (in die Audit-Phase). Um Feedback-Loops kurz zu halten und echtes Shift-Left zu erreichen, müssen wir KI einsetzen, um das „Nicht-Automatisierbare“ zu automatisieren.
Auch wenn KI niemals die gelebte Erfahrung menschlicher Tester ersetzen wird, kann sie die schwere Arbeit über den gesamten Ablauf hinweg übernehmen: reichhaltigeres, kontextbewusstes Scanning, smartere Triage, technisch fundierte Fix-Vorschläge und eine engere Brücke zwischen Audit-Findings und Entwickler-Workflow. Menschen können sich dann auf das konzentrieren, was am wichtigsten ist: die komplexen, subjektiven Nuancen, die eine inklusive Experience wirklich ausmachen.
Was meinst du? Bist du bereit, KI-erweitertes Accessibility-Testing über den gesamten Workflow hinweg zu nutzen? Und vielleicht die provokativere Frage: Würdest du ein gewisses Maß an False Positives akzeptieren, wenn du dafür mehr Issues frühzeitig findest, oder bevorzugst du den strikten Zero-False-Positive-Ansatz, auf dem viele heutige Tools basieren? Lass uns darüber sprechen.
Original Post in Englisch: The Evolution of Accessibility Testing | Th3S4mur41
Michaël Vanderheyden ist Lead UX Engineer und arbeitet seit 2004 als Webentwickler mit einem starken Fokus auf Usability und Barrierefreiheit. Unter seinem Online-Handle Th3S4mur41 schreibt er auf seiner Webseite über moderne Webtechnologien und inklusive Entwicklung. Sein Ziel ist es, Benutzeroberflächen zu schaffen, die das Leben der Menschen spürbar verbessern.
Er hält einen Bachelor in Informatik von der Haute École de la Province de Liège in Belgien, lebt dort und pendelt als Grenzgänger nach Aachen. Dort arbeitet er für die cycos ag (ein Unternehmen der Atos-Gruppe). Michael ist von der IAAP als Certified Professional in Web Accessibility (CPWA) zertifiziert. Für ihn ist Barrierefreiheit kein nachträgliches Extra, sondern gehört von Anfang an fest in die Softwarearchitektur.
Sein Arbeitsstil ist stark von seiner Leidenschaft für den Kampfsport geprägt: Die Disziplin und der Respekt aus dem Training helfen ihm dabei, komplexe technische Herausforderungen mit Fokus und Beständigkeit zu lösen.