KI-Coding-Tools schreiben Code im Sekundentakt. Beim Thema Barrierefreiheit liefern die Werkzeuge ab Werk allerdings schwache Ergebnisse, wie ein Vortrag von der Microsoft Build 2026 mit harten Zahlen belegt. Für deutsche Betreiber trifft der Befund direkt auf die BFSG-Pflicht, und damit auf bares Bußgeldrisiko.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Barrierefreier Code aus dem KI-Assistenten besteht ab Werk nur 8 bis 25 Prozent der automatisierten Prüfungen. Diese Zahl nannte Accessibility-Experte Aaron Gustafson gemeinsam mit Jessie Lorenz und Carie Fisher auf der Microsoft Build 2026. Der Grund liegt in den Trainingsdaten: KI-Modelle haben von einem Web gelernt, das in weiten Teilen Barrieren enthält, und geben dieses Muster ungefiltert weiter.
Das Wichtigste in Kürze
- Coding-Agenten bestehen ohne Vorgaben nur 8 bis 25 Prozent der automatisiert prüfbaren Barrierefreiheits-Tests.
- Ein Instruction-File hebt die Quote auf 37 bis 60 Prozent, dedizierte Skills auf rund 86 Prozent.
- Erst eingebundene deterministische Tests bringen den Code durch alle maschinell prüfbaren Anforderungen.
- Automatisierte Tests decken nur etwa die Hälfte echter Barrierefreiheit ab, der Rest braucht manuelle Kontrolle.
Warum besteht KI-Code so selten den Barriere-Test?
Künstliche Intelligenz beschleunigt das Tempo der Entwicklung und zugleich die Produktion neuer Barrieren. Beide Effekte hängen an denselben Trainingsdaten. Modelle lernen aus einem Web, das in weiten Teilen nicht zugänglich gebaut wurde.
Gustafson zeigte einen Stufenverlauf vom Rohmodell zum geprüften Code. Ohne Anleitung passieren 8 bis 25 Prozent der automatisierten Checks. Ein Instruction-File mit klaren Vorgaben hebt die Quote auf 37 bis 60 Prozent. Mit dedizierten Skills erreicht der Agent rund 86 Prozent. Den Rest schaffen nur eingebundene, deterministische Tests, die den Agenten so lange zur Nachbesserung zwingen, bis der Code jede maschinell prüfbare Vorgabe erfüllt.
Auch der beste automatisierte Durchlauf hat eine Grenze. Maschinelle Tests decken nach Gustafsons Angabe nur rund die Hälfte dessen ab, was eine nutzbare Oberfläche ausmacht. Tastaturführung, Vorlesereihenfolge und Verständlichkeit lassen sich nur teilweise automatisch messen. Den Rest klärt eine manuelle Prüfung mit Betroffenen.
KI macht aus einem schlampigen Prozess einen schnellen schlampigen Prozess. Barrierefreiheit gehört deshalb in jeden Schritt der Entwicklung, nicht in die Schadensbegrenzung nach dem Launch.
— Michael Dobler, Herausgeber Dr. Web
Was bedeutet der Befund für das BFSG?
Seit dem 28. Juni 2025 verlangt das Barrierefreiheitsstärkungsgesetz von vielen Betreibern zugängliche Websites und Shops. Bei Verstößen drohen Bußgelder bis zu 100.000 Euro. Genau in diese Pflicht hinein liefern Coding-Agenten ihren schwächsten Output, sobald niemand die Vorgaben gesetzt hat.
Für den Mittelstand zählt deshalb die Reihenfolge. Erst die Anforderungen im Projekt verankern, etwa über ein Instruction-File, sauberes semantisches HTML und passende Skills, dann den Agenten schreiben lassen. Werkzeuge wie der quelloffene Accessibility Scanner von GitHub oder eine Prüf-Pipeline mit dem aXe-Regelsatz fangen die automatisierbaren Fehler früh ab. Die manuelle Kontrolle bleibt Pflicht, weil die Maschine nur die halbe Strecke prüft. Eine kompakte Übersicht aller Prüfpunkte vor dem Launch liefert unsere Website-Checkliste.
Mit KI-Tools im Build-Prozess gehört die Barrierefreiheit an den Anfang der Vorgaben, nicht ans Ende der Korrekturschleife. Die Kosten steigen mit jeder Stufe: im Planungsgespräch kostenlos, im fertigen Code das Hundertfache, nach dem Launch das Tausendfache. Eine klare Vorgabe zu Projektbeginn bleibt die günstigste Versicherung gegen teure Nacharbeit.
Mehr Newshunger?
