KI-generierter Code: was Barrierefreiheitsprüfungen finden

Die Forschung zur Barrierefreiheit von KI-generiertem Code ist jung, und ihre Ergebnisse passen nicht zur einfachen Erzählung vom schlechten Maschinencode. Eine 2025 veröffentlichte Vergleichsstudie stellte Webcode von zwei Sprachmodellen dem Code menschlicher Entwickler gegenüber (Suh et al. 2025). Die Sprachmodelle lieferten oft zugänglicheren Code, vor allem bei Grundlagen wie Farbkontrast und Alternativtexten, taten sich aber mit komplexeren Punkten wie ARIA-Attributen schwer (Suh et al. 2025). Erweiterte Prompting-Strategien brachten laut der Studie einige Verbesserungen, die jedoch begrenzt blieben.

Eine zweite Arbeit setzt beim Menschen an, der das Werkzeug bedient. In einer Vorstudie mit 16 Entwicklerinnen und Entwicklern ohne Schulung in Barrierefreiheit beobachtete das Forschungsteam drei Kernprobleme beim KI-gestützten Programmieren (Mowar et al. 2025): Die Teilnehmenden forderten Barrierefreiheit im Prompt nicht an, sie ließen nötige Handarbeit aus, etwa das Ersetzen von Platzhalterattributen, und ihnen fehlte die Möglichkeit, die Konformität des Ergebnisses zu prüfen. Der zweite Punkt ist im Alltag tückisch. Ein generierter Vorschlag enthält etwa ein alt="Bild" oder ein aria-label="Button", das die Struktur erfüllt und den Inhalt offenlässt.

Die Werkzeuge selbst sind im Entwicklungsalltag angekommen. In der Stack Overflow Developer Survey 2025 gaben 84 Prozent der Befragten an, KI-Werkzeuge in der Entwicklung zu nutzen oder dies zu planen (Stack Overflow Developer Survey 2025). Zugleich misstrauen 46 Prozent der Genauigkeit der Ergebnisse, nur 33 Prozent vertrauen ihr (Stack Overflow Developer Survey 2025). Als größten einzelnen Ärgerpunkt nannten 66 Prozent Lösungen, die „fast richtig, aber eben nicht ganz“ sind (Stack Overflow Developer Survey 2025). Für die Barrierefreiheit beschreibt das die typische Lage: Das Ergebnis sieht richtig aus, aber die Bedienung ohne Maus und die Ausgabe für den Screenreader stimmen nicht.

Ein div mit onclick reagiert auf den Mausklick und sieht mit etwas CSS aus wie ein Knopf. Für einen Screenreader ist es aber ein Textcontainer ohne Rolle, und mit der Tabulatortaste ist es nicht erreichbar. Damit verfehlt es zwei Erfolgskriterien der Stufe A: SC 4.1.2 verlangt, dass Name und Rolle jedes Bedienelements programmatisch ermittelbar sind, und SC 2.1.1 verlangt, dass alle Funktionen über eine Tastaturschnittstelle bedienbar sind (W3C, WCAG 2.2). Ergänzt der Code ein role="button", ist nur die Hälfte erledigt. Der ARIA Authoring Practices Guide nennt eine Rolle ein Versprechen: Wer sie setzt, kündigt an, auch die erwartete Tastaturbedienung per JavaScript eingebaut zu haben, denn ARIA-Rollen bringen anders als HTML-Bedienelemente keine Tastaturbedienung mit (W3C, ARIA Authoring Practices Guide). Im Schnitt trugen Startseiten 2026 4,8 Attribute role="button", nach 3,6 im Jahr 2025 (WebAIM Million 2026).

Aufklappbare Details, Akkordeons und Menüs entstehen in generiertem Code gern mit ARIA-Attributen. Das sieht nach Sorgfalt aus: aria-expanded="false" steht im Markup, vielleicht auch aria-controls. Sitzt das Attribut aber an einem div ohne Fokus und ohne Reaktion auf Enter und Leertaste, lässt sich das Element nur mit der Maus öffnen. Vergisst das Skript zudem, den Zustand beim Öffnen umzuschalten, sagt der Screenreader weiterhin „zugeklappt“. Wie riskant ARIA ohne passende Bedienung ist, zeigt ein verwandtes Muster: 22 Prozent der ARIA-Menüs auf Startseiten verursachten Barrieren, weil nötiges Markup oder nötige Interaktionen fehlten (WebAIM Million 2026).

Der ARIA Authoring Practices Guide beschreibt für jedes Muster, welche Tasten welche Wirkung haben, und stellt seiner Anleitung den Satz voran, dass kein ARIA besser ist als schlechtes ARIA (W3C, ARIA Authoring Practices Guide). Für aufklappbare Details genügt oft ein natives details-Element oder ein button, dessen aria-expanded das Skript beim Öffnen und Schließen pflegt. Mehr dazu im Beitrag zu ARIA-Rollen, Zuständen und Live-Regions und im Praxisteil zur Tastaturnavigation.

Automatische Prüfwerkzeuge gehören in jeden Ablauf mit generiertem Code, weil sie schnell und günstig sind und viele Seiten abdecken. Ihre Grenze benennen die Herausgeber der Richtlinien selbst: Werkzeuge können nicht alle Aspekte der Barrierefreiheit automatisch prüfen, es braucht menschliches Urteil, und sie können Barrierefreiheit nicht feststellen, sondern nur dabei helfen (W3C WAI). Auch WebAIM schreibt, dass das Fehlen erkannter Fehler nicht bedeutet, dass eine Seite barrierefrei oder konform ist (WebAIM Million 2026).

Wie groß die Lücke sein kann, hat der Government Digital Service der britischen Regierung gemessen. Das Team baute eine Testseite mit 143 Barrieren und ließ zehn verbreitete Prüfwerkzeuge darüber laufen. 42 der Barrieren fand keines der Werkzeuge, das sind 29 Prozent (GDS 2017). Zusammen fanden die Werkzeuge 71 Prozent, den Rest hätte nur eine manuelle Prüfung entdeckt (GDS 2017). Der Test ist eine Momentaufnahme aus dem Jahr 2017. An der Grundaussage ändert das wenig: Ob ein Name den Zweck trifft, ob die Fokusreihenfolge der Bedienlogik folgt und ob ein Menü per Tastatur vollständig bedienbar ist, beurteilt ein Mensch.

Welche Prüfmethoden es gibt und wie sie zusammenspielen, beschreibt unser Überblick zu Accessibility Testing. Dort steht auch, warum ein Score von 100 Punkten nur belegt, dass kein automatisch erkennbarer Fehler gefunden wurde. Ähnlich wie bei Overlays gilt: Eine Automatik, die Barrierefreiheit verspricht, ersetzt nicht die Prüfung des ausgelieferten Markups, wie der Beitrag zu Accessibility-Overlays ausführt.

Das Barrierefreiheitsstärkungsgesetz gilt für Dienstleistungen im elektronischen Geschäftsverkehr, die nach dem 28. Juni 2025 für Verbraucher erbracht werden (BFSG, § 1 Abs. 3). Es unterscheidet nicht nach dem Entstehungsweg des Codes. Wer einen Onlineshop im Anwendungsbereich des Gesetzes betreibt, verantwortet die Schaltfläche im Warenkorb unabhängig davon, ob ein Mensch oder ein Werkzeug sie geschrieben hat. Bietet ein Dienstleistungserbringer seine Dienstleistung entgegen § 14 Abs. 1 an, kann das als Ordnungswidrigkeit mit einer Geldbuße bis zu 100.000 Euro geahndet werden (BFSG, § 37).

Auch die Ausnahme für Inhalte Dritter hilft hier nicht weiter. Sie gilt nur für Inhalte, die der betreffende Wirtschaftsakteur weder finanziert noch entwickelt und die nicht seiner Kontrolle unterliegen (BFSG, § 1 Abs. 4 Nr. 4). Code, den ein Team mit einem Werkzeug erzeugt und in die eigene Seite übernimmt, ist in aller Regel eigener Code. Welche Anforderungen im Einzelnen gelten, fassen unsere BFSG-Anforderungen zusammen. Wer Komponenten von einer Agentur oder einem Dienstleister bezieht, sollte die Abnahmekriterien in den Vertrag schreiben; wie das geht, beschreibt der Beitrag zu Barrierefreiheit in Vertrag und Abnahme.

Hinter den Kriterien stehen Menschen, die auf Tastatur, Screenreader oder ausreichenden Kontrast angewiesen sind. Zum Jahresende 2025 lebten in Deutschland gut 7,8 Millionen Menschen mit schwerer Behinderung (Destatis). Nicht alle nutzen assistive Technik, und viele Barrieren aus den vier Mustern treffen auch Menschen ohne anerkannte Behinderung: wer die Maus wegen einer Sehnenscheidenentzündung meidet, wer im Sonnenlicht auf ein Display schaut oder wer mit der Tastatur schlicht schneller ist.