Vibe Coding & Barrierefreiheit: Warum ein Satz im Prompt nicht reicht

Die neuesten KI-Modelle kennen die WCAG besser als die meisten Entwickler. Trotzdem besteht nur jede achte Oberfläche, die sie bauen, einen automatischen Barrierefreiheits-Test.

Das ist das Ergebnis eines Tests von Michael Fairchild, Accessibility-Programmmanager bei Microsoft, mit acht aktuellen Modellen, darunter GPT-5.5, Claude Opus 4.7 und Gemini 3.1 Pro. Ohne Hinweis zur Barrierefreiheit bestanden im Schnitt 12 % der generierten Oberflächen die Prüfung (Fairchild 2026). Das Wissen ist also da. Es wird nur nicht genutzt, solange niemand danach fragt.

Die Kurzfassung: Bei Vibe Coding ist Barrierefreiheit kein Selbstläufer. Im AIMAC-Benchmark bauen 68 von 70 KI-Modellen ohne Anleitung kritische oder schwere Barrieren ein (Stand Oktober 2026, aimac.ai). Ein Satz wie „Achte auf Barrierefreiheit“ im Prompt hilft bei aktuellen Modellen, reicht aber bei Weitem nicht. Was wirklich wirkt: konkrete Vorgaben pro Komponente, ein fester Prüf-Loop und ein Mensch, der am Ende draufschaut.

In diesem Artikel erfährst du, welche Barrieren KI-generierte Oberflächen am häufigsten haben, was der Prompt bringt und was nicht, und wie du einen Screen in 15 Minuten prüfst. Die Prüfschritte gibt es auch als Checkliste zum Herunterladen.

Was ist Vibe Coding?

Vibe Coding bedeutet: Du beschreibst in normaler Sprache, was du haben willst, die KI baut es, du probierst das Ergebnis aus und forderst Änderungen an. Den Code selbst liest du dabei kaum oder gar nicht. Den Begriff hat Andrej Karpathy im Februar 2025 geprägt. Sein Kern ist, dass man „vergisst, dass der Code überhaupt existiert“ (Martin Fowler: Vibe Coding).

Typische Werkzeuge sind Lovable, v0 und Bolt für ganze Oberflächen sowie Cursor und GitHub Copilot direkt im Editor. Gerade für Tech-Gründer ist das verlockend: In zwei Tagen steht ein MVP, das aussieht wie ein echtes Produkt.

84 % der Entwicklerinnen und Entwickler nutzen KI-Tools oder planen es (Stack Overflow Developer Survey 2025). Ob du komplett „vibest“ oder dir nur Komponenten generieren lässt: Die Barrieren sind dieselben. Hier geht es um KI beim Bauen deines Produkts. Wie KI im Produkt gut funktioniert, liest du im Artikel Invisible AI: Warum die beste KI in deinem SaaS unsichtbar bleibt.

Ist KI-generierter Code barrierefrei?

Nicht von allein. Und neuere Modelle lösen das Problem nicht automatisch.

Der AIMAC-Benchmark prüft laufend 70 aktuelle Modelle. Sie bauen Webseiten in 28 Kategorien, ohne Hinweis auf Barrierefreiheit, geprüft wird mit axe-core gegen WCAG 2.2 AA. Bei mehreren Anbietern schneidet die neuere Modellversion schlechter ab als die Vorgängerin. Bei anderen ist sie deutlich besser. Einen klaren Trend „neuer = barrierefreier“ gibt es nicht (aimac.ai).

Die wichtigsten aktuellen Messungen im Überblick:

Fairchild und WebAccessBench sind Veröffentlichungen einzelner Autoren ohne Peer Review. Die Ergebnisse zeigen aber alle in dieselbe Richtung.

Gleichzeitig hat das Web 2026 zum ersten Mal seit sechs Jahren wieder mehr Barrieren: 95,9 % der eine Million meistbesuchten Startseiten haben WCAG-Fehler (WebAIM Million 2026). WebAIM nennt KI-gestütztes Coding als möglichen Grund, gemessen wurde das nicht direkt. Dazu kommen zwei Effekte, die in keinem Benchmark stehen.

Menge
Baut ein Team heute ein Vielfaches der Screens von früher, multipliziert sich jeder Fehler.

Niemand schaut hin
Beim Vibe Coding wird der Code nicht gelesen. Und das Vertrauen ist hoch: In einer Umfrage des Prüftool-Anbieters Deque gaben 88 % der befragten Engineering-Verantwortlichen an, großes Vertrauen in die Barrierefreiheit von KI-Code zu haben (Deque 2026, Herstellerumfrage unter 200 US-Unternehmen).

Und noch etwas fällt auf, wenn man sich Produkte ansieht, die mit KI-Tools gebaut wurden. Sie sind oft stark überladen mit Features. Da kommen neben der eigentlichen Produktidee gern noch weitere Funktionen mit rein, weil sie die KI gerade mit vorgeschlagen hat. Das mag oft sinnvoll sein, aber jedes zusätzliche Element ist auch eine zusätzliche Stelle, an der ein Name, ein Kontrast oder ein Fokus fehlen kann.

Barrierefreiheit auf Zuruf: Was der Satz im Prompt bringt

Der naheliegende Gedanke: Dann schreibe ich halt „WCAG 2.2 AA“ in den Prompt. Ich nenne das Barrierefreiheit auf Zuruf: Man ruft der KI ein Ziel zu und hofft, dass sie weiß, was gemeint ist.

Die gute Nachricht: Bei aktuellen Modellen hilft der Zuruf. Im Test von Fairchild hat schon eine einzige Zeile Anweisung die Quote der bestandenen Oberflächen mehr als verdreifacht. Mit einer kurzen Basis-Anleitung lag sie bei 60 %. WebAccessBench kommt zu einem ähnlichen Bild: Mit einem kurzen Hinweis sinken die Fehler von 3,2 auf 2,0 pro Oberfläche, und 18 von 19 Modellen werden mit genauen Vorgaben besser.

Die schlechte Nachricht: Fehlerfrei sind auch mit Hinweis nur rund 11 % der Oberflächen. Der Zuruf macht es besser, aber nicht gut.

Vielleicht hast du gelesen, dass ein Barrierefreiheits-Hinweis den Code sogar schlechter macht. Das stimmt so nicht mehr. Diese Studien arbeiten mit älteren Modellen wie GPT-4o, die auf den Hinweis mit zusätzlichem ARIA und damit neuen Fehlern reagierten (Suh et al. 2025). Und selbst dort lohnt der zweite Blick: Im automatischen Test sah der Barrierefreiheits-Prompt leicht schlechter aus, Experten fanden in denselben Oberflächen aber 19 % statt 58 % Verstöße (Guriţă & Vatavu 2025).

Was wirklich den Unterschied macht, ist Genauigkeit. Fairchild hat den Modellen statt eines Satzes eine detaillierte Anleitung pro Komponente mitgegeben, also wie ein barrierefreier Dialog, ein Menü oder ein Formular aufgebaut sein muss. Damit bestanden 82 % die Checks. Mit einem zusätzlichen Schritt, in dem die KI ihr eigenes Ergebnis gegen eine Checkliste prüft, waren es 86 %. Der Preis: rund fünfmal so viele Tokens.

Auch konkretes Feedback wirkt. In einer Studie mit ChatGPT behob das Modell 70 % der Fehler, die man ihm aus dem Prüftool nannte, bei Kontrastfehlern allerdings nur 60 % (Aljedaani et al. 2024).

Der Unterschied in einem Satz:

„Mach es barrierefrei“ = ein Wunsch.
„Jeder Icon-Button braucht einen zugänglichen Namen, Dialoge halten den Fokus und schließen mit Escape“ = ein Auftrag.

Die 6 Barrieren, die KI-generierte UIs am häufigsten haben

Sechs Fehlertypen machen 96 % aller automatisch gefundenen Barrieren im Web aus (WebAIM Million 2026). Genau diese findest du auch in KI-generierten Oberflächen. Bei AIMAC betrifft zu geringer Kontrast 86,9 % der KI-Seiten, dahinter folgen leere Links, fehlende Formular-Labels und leere Buttons. Diese strukturellen Fehler sind seltener, aber schwerer: Sie sperren Menschen komplett aus. Jeden davon kannst du in unter einer Minute prüfen. Die Prozentwerte unten zeigen, wie verbreitet der Fehler im ganzen Web ist.

1. Zu geringer Kontrast

Text hebt sich nicht genug vom Hintergrund ab. Das betrifft 83,9 % aller Startseiten und ist damit der häufigste Fehler überhaupt. KI-Tools lieben hellgraue Hilfetexte, Platzhalter in blassem Grau und weiße Schrift auf Verläufen.

Schnelltest:
Im Browser per Rechtsklick „Untersuchen“ wählen und den Text anklicken. Chrome zeigt den Kontrastwert direkt an. Für normalen Text braucht es mindestens 4,5:1. Mehr dazu im Artikel zu barrierefreien Farben und Farbkontrasten.

2. Fehlende Formular-Labels

Ein Eingabefeld hat keine Beschriftung, die technisch mit ihm verknüpft ist. Oft steht nur ein Platzhalter im Feld, der beim Tippen verschwindet. Screenreader lesen dann nur „Eingabefeld“ vor. Das betrifft 51 % der Startseiten.

Schnelltest:
Auf die Beschriftung klicken. Springt der Cursor ins Feld? Dann ist sie verknüpft. Alles Weitere steht im Leitfaden zu barrierefreien Formularen.

3. Leere Buttons und Links

Ein Button oder Link hat keinen Namen, den ein Screenreader vorlesen kann. Der Klassiker in KI-generierten Oberflächen: Icon-Buttons mit Stift, Mülleimer oder drei Punkten. Sehende Nutzer verstehen sie. Ein Screenreader sagt nur „Schaltfläche“. Leere Links gibt es auf 46,3 % der Startseiten, leere Buttons auf 30,6 %.

Schnelltest:
Mit der Tab-Taste durch die Seite gehen und dabei den Screenreader laufen lassen (dazu weiter unten mehr). Jeder Button muss sagen, was er tut.

4. Fehlende Alternativtexte

Bilder ohne Beschreibung für Menschen, die sie nicht sehen. Hier ist KI vergleichsweise gut, trotzdem fehlen Alternativtexte noch auf 53,1 % der Startseiten. Häufiger als fehlende Texte sind bei KI-Code nichtssagende Texte wie „image“ oder „hero“.

Schnelltest:
Die Browser-Extension WAVE zeigt alle Bilder mit ihrem Alternativtext direkt auf der Seite an.

5. Keine echte Überschriften-Struktur

Statt einer klaren Hierarchie mit H1, H2 und H3 besteht die Seite aus Text-Blöcken, die nur optisch wie Überschriften aussehen. Deque zeigt ein typisches Beispiel aus generiertem React-Code: Der große Titel im Hero ist in mehrere span-Elemente zerlegt statt eine H1 zu sein (Deque: Vibe fixing).

Schnelltest:
Die Extension HeadingsMap oder der Bereich „Structure“ in WAVE zeigt die Überschriften als Gliederung. Ergibt sie für sich gelesen Sinn?

6. Falsches oder überflüssiges ARIA

Der Fehler, der am meisten Schaden anrichtet, weil er nach Barrierefreiheit aussieht. Er bekommt deshalb einen eigenen Abschnitt.

ARIA-Deko: Warum mehr ARIA mehr Barrieren bedeutet

ARIA ist eine Sammlung von HTML-Attributen, mit denen man Screenreadern zusätzliche Infos gibt. Zum Beispiel, dass ein Element ein Menü ist, ob es gerade geöffnet ist oder wie es heißt. Richtig eingesetzt ist ARIA sehr hilfreich. Falsch eingesetzt erzählt es dem Screenreader etwas, das nicht stimmt.

Das W3C, also die Organisation hinter den Web-Standards, formuliert es deutlich: „No ARIA is better than Bad ARIA“. Kein ARIA ist besser als schlechtes ARIA (W3C ARIA Authoring Practices).

Bei KI-Code sehe ich oft das, was ich ARIA-Deko nenne: Attribute, die nach Barrierefreiheit aussehen, aber keine bringen. Ein div bekommt role="button" und ein aria-label, ist aber per Tastatur nicht erreichbar. Ein Menü bekommt aria-expanded, das sich nie ändert. Für eine automatische Prüfung sieht das ordentlich aus. Für einen Menschen mit Screenreader ist es eine Falle.

Die Zahlen von WebAIM passen dazu. Eine Startseite enthält 2026 im Schnitt über 133 ARIA-Attribute, 27 % mehr als im Vorjahr. Seiten mit ARIA haben im Schnitt 59,1 Fehler, Seiten ohne 42. Ein Teil davon liegt an der höheren Komplexität, der Zusammenhang zeigt sich aber jedes Jahr (WebAIM Million 2026).

Die Faustregel ist einfach: Natives HTML-Element vor ARIA. Ein echter button kann alles, was ein nachgebauter Button mit ARIA können soll. Er ist per Tastatur erreichbar, reagiert auf Enter und Leertaste und hat eine Rolle, die jeder Screenreader kennt. Ohne ein einziges zusätzliches Attribut.

Die Fehler, die kein Tool findet

Selbst wenn alle automatischen Checks grün sind, ist eine Oberfläche nicht automatisch barrierefrei. Forschende des Politecnico di Torino nennen das die semantische Lücke: den Raum zwischen „besteht den automatischen Test“ und „vermittelt tatsächlich sinnvolle Information“ (Calò et al. 2026).

In 300 KI-generierten Oberflächen fanden sie 541 solcher Fehler, also rund zwei pro Oberfläche. Am häufigsten:

• Generische Buttons (27 %):
  Der Button hat einen Namen, aber einen nutzlosen. „Klick hier“, „Mehr“, „Button“.

• Vage Links (26 %):
  Fünfmal „Weiterlesen“ auf einer Seite. Wer mit Screenreader die Linkliste aufruft, weiß nicht, wohin welcher führt.

• Schlechte Alternativtexte (20 %):
  „Bild“, „Hero“, „Dashboard-Screenshot“. Vorhanden, aber ohne Inhalt.

• ARIA-Probleme (14 %) und generische Formular-Labels (12 %):
  „Eingabe 1“ statt „Rechnungsnummer“.

Für ein Prüftool ist all das korrekt. Für einen Menschen nicht. Genau deshalb gehört ein manueller Test in jeden Prüfablauf.

So prüfst du KI-generiertes UI auf Barrierefreiheit

So mache ich es selbst: Ich nutze KI für Prototypen. Die Qualitätssicherung danach läuft mit Browser-Extensions und von Hand. Beides gehört zusammen. Die Tools finden die Masse, der Handtest findet das, was wirklich nervt.

Für einen Screen brauchst du etwa 15 Minuten.

1. Automatisch prüfen (3 Minuten)
Lass eine Browser-Extension über die Seite laufen. Meine Empfehlungen:

• axe DevTools: gründlich, wenig Fehlalarme, die Basisversion ist kostenlos.

• WAVE: zeigt die Fehler direkt auf der Seite an, gut für Kontrast, Alternativtexte und Struktur.

• Lighthouse: ist in Chrome eingebaut und gibt einen schnellen Überblick. Für eine echte Prüfung reicht es allein nicht.

Wichtig: Automatische Tools finden nur einen Teil der Fehler. Deque kommt in einer Auswertung eigener Audits auf rund 57 % (Deque Coverage Report, Herstellerstudie), andere Schätzungen liegen deutlich niedriger.

2. Fehler zurück an die KI geben (2 Minuten)
Kopiere die gefundenen Fehler mit Element und Regel in den Prompt: „axe meldet: Der Button mit dem Stift-Icon in der Tabellenzeile hat keinen zugänglichen Namen. Behebe das mit einem echten button-Element und einem sichtbaren oder versteckten Text.“ Wer direkt im Editor arbeitet, kann Prüftools inzwischen auch dort anbinden, zum Beispiel über den axe MCP Server von Deque. Danach erneut prüfen.

3. Tastatur-Test (4 Minuten)
Maus weglegen. Mit Tab vorwärts, Shift+Tab zurück, Enter und Leertaste zum Auslösen, Escape zum Schließen. Achte auf drei Dinge: Siehst du immer, wo der Fokus gerade ist? Erreichst du jedes Bedienelement? Kommst du aus Dialogen und Menüs wieder heraus?

4. Screenreader-Kurztest (4 Minuten)
Auf dem Mac ist VoiceOver eingebaut (Cmd + F5), unter Windows ist NVDA kostenlos. Geh einmal durch den Screen. Hat jeder Button einen Namen? Werden Formularfelder mit ihrer Beschriftung vorgelesen? Stimmt die Reihenfolge?

5. Zoom und Farben (2 Minuten)
Zoome auf 200 %. Bricht das Layout, überlappen sich Texte? Dann in den Chrome DevTools unter „Rendering“ eine Farbsehschwäche simulieren (Chrome-Doku). Erkennst du Status und Fehler noch, wenn die Farbe wegfällt?

Für eine vollständige Prüfung aller Kriterien nimm die WCAG-Checkliste mit allen AA-Kriterien.

Leitplanken statt Nacharbeit: Design System als Vorgabe für die KI

Prüfen ist gut. Noch besser ist, wenn viele Fehler gar nicht erst entstehen. Der wirksamste Hebel dafür ist kein besserer Prompt, sondern weniger Freiheit für die KI.

Die Idee: Du definierst die wichtigsten Komponenten einmal sauber und barrierefrei. Button, Eingabefeld, Auswahl, Dialog, Menü, Tabelle. Die KI baut danach nur noch mit diesen Bausteinen und erfindet keinen eigenen Button mehr.

Konkret sieht das so aus:

• Komponenten im Repository:
  eine kleine Bibliothek, die du selbst geprüft hast. Viele Teams starten mit einer etablierten Bibliothek, deren Komponenten bereits auf Tastatur und Screenreader ausgelegt sind, und passen nur das Aussehen an.

• Regeln für die KI:
  In Cursor, Copilot und ähnlichen Tools kannst du eine Regel-Datei hinterlegen, die bei jedem Prompt mitgeschickt wird. Darin steht zum Beispiel: „Nutze ausschließlich Komponenten aus /components/ui. Verwende kein role-Attribut auf div- oder span-Elementen.“

• Farben als Tokens:
  Lege Text- und Hintergrundfarben fest, die den Kontrast bereits erfüllen. Dann kann die KI keinen hellgrauen Hilfetext mehr erfinden.

Nebenbei gibt ein eigenes Design System deinem Produkt ein eigenes Gesicht, statt des typischen KI-Looks, und der KI klare Grenzen.

Wirtschaftlich ist das der günstigere Weg. Jede Barriere, die nach dem Release gefunden wird, kostet einen Fix, einen Test und ein Deployment. In der Deque-Umfrage nannten 64 % der Befragten Barrierefreiheit als einen Hauptgrund für Nachbesserungen nach dem Release (Deque 2026, Herstellerumfrage). Barrieren, die sich so ansammeln, sind am Ende nichts anderes als Design Debt.

Wann lohnt sich ein Audit, und wann nicht?

Ehrlich gesagt: nicht immer.

Für einen Klick-Prototyp, mit dem du eine Idee bei fünf Testpersonen validierst, brauchst du kein Audit. Da reicht der 15-Minuten-Loop.

Anders sieht es aus, sobald echte Kunden mit dem Produkt arbeiten:

• Du verkaufst an Endverbraucher:
  Dann gilt in Deutschland seit Juni 2025 das Barrierefreiheitsstärkungsgesetz (BFSG). Reine B2B-Software fällt nach Auskunft der Bundesfachstelle Barrierefreiheit nicht darunter. Mehr dazu im Artikel Inklusive UX & Barrierefreiheit in SaaS.

• Du willst an öffentliche Auftraggeber verkaufen:
  Dort ist Barrierefreiheit oft Teil der Ausschreibung. Die europäische Norm EN 301 549 stellt gerade auf WCAG 2.2 um, die Aufnahme ins EU-Amtsblatt wird für Mitte Dezember 2026 erwartet (NDA Irland).

• Dein Produkt ist schnell gewachsen:
  Viele Screens, mehrere Leute und KI-Tools haben daran gebaut, aber niemand hat systematisch geprüft. Dann findet ein UX-Audit die Muster, die sich durch das ganze Produkt ziehen, und du behebst sie einmal an der Komponente statt hundertmal im Screen

Das hier ist keine Rechtsberatung. Ob und welche Vorgaben für dein Produkt gelten, klärst du am besten mit einer Fachanwältin oder der Bundesfachstelle Barrierefreiheit.

Fazit & nächste Schritte

Vibe Coding macht dich schnell. Barrierefrei macht es dein Produkt nicht von allein. Drei Dinge solltest du mitnehmen:

1. KI-Code ist nicht automatisch barrierefrei
   Auch die neuesten Modelle bauen ohne Anleitung fast immer Barrieren ein. Neuere Versionen sind nicht automatisch besser.

2. Barrierefreiheit auf Zuruf reicht nicht
   Ein Satz im Prompt hilft bei aktuellen Modellen etwas. Was wirklich wirkt, sind genaue Vorgaben pro Komponente, konkretes Feedback aus einer Prüfung und ein Mensch, der die Fehler sieht, die kein Tool findet.

3. Leitplanken schlagen Nacharbeit
   Barrierefreie Komponenten und klare Regeln für die KI verhindern Fehler, bevor sie entstehen.

Deine nächsten Schritte:

• Nimm dir heute einen Screen vor und geh den 15-Minuten-Loop durch. Die Checkliste dazu findest du unten in der Download-Box.

• Installiere axe DevTools oder WAVE und lass sie über deine wichtigste Seite laufen.

• Lege eine Regel-Datei für dein KI-Tool an, die native HTML-Elemente und deine eigenen Komponenten vorschreibt.

Häufig gestellte Fragen zu Vibe Coding & Barrierefreiheit

Ist KI-generierter Code barrierefrei?

Nicht automatisch. Im AIMAC-Benchmark erzeugen 68 von 70 aktuellen KI-Modellen ohne Hinweis im Prompt kritische oder schwere Verstöße gegen WCAG 2.2 AA (Stand Oktober 2026). KI-generierter Code muss deshalb genauso geprüft werden wie jeder andere Code, automatisch und von Hand.

Sind neuere KI-Modelle besser bei Barrierefreiheit?

Nicht automatisch. Im AIMAC-Benchmark schneidet bei mehreren Anbietern die neuere Modellversion schlechter ab als die Vorgängerin. In einem Test mit acht aktuellen Modellen bestanden ohne Anleitung nur 12 % der Oberflächen die automatischen Checks. Entscheidend sind die Vorgaben und die Prüfung, nicht das Modell.

Reicht es, „barrierefrei“ oder „WCAG 2.2 AA“ in den Prompt zu schreiben?

Es hilft, reicht aber nicht. Bei aktuellen Modellen sinkt die Zahl der Fehler mit einem kurzen Hinweis deutlich, fehlerfrei sind laut WebAccessBench trotzdem nur rund 11 % der Oberflächen. Viel mehr bringen genaue Vorgaben pro Komponente und ein Prüfschritt: Damit bestanden in einem Test 86 % die automatischen Checks. Ältere Studien, nach denen der Hinweis schadet, beziehen sich auf Modelle wie GPT-3.5 und GPT-4o.

Warum macht zu viel ARIA eine Seite weniger barrierefrei?

ARIA-Attribute geben Screenreadern Informationen über ein Element. Sind sie falsch, erzählen sie etwas, das nicht stimmt, etwa dass ein Element ein Button ist, der sich nicht per Tastatur bedienen lässt. Seiten mit ARIA haben laut WebAIM im Schnitt 59,1 Fehler, Seiten ohne 42. Faustregel: natives HTML-Element vor ARIA.

Welche Barrierefreiheitsfehler macht KI-Code am häufigsten?

Zu geringer Kontrast ist mit Abstand der häufigste Fehler, er betrifft im AIMAC-Benchmark 86,9 % der KI-generierten Seiten. Dazu kommen fehlende Formular-Labels, Buttons und Links ohne Namen, fehlende Alternativtexte, keine echte Überschriften-Struktur und falsch eingesetztes ARIA. Typisch für KI-Oberflächen sind Icon-Buttons ohne Namen.

Wie prüfe ich KI-generiertes UI auf Barrierefreiheit?

In einem festen Ablauf: automatisch mit axe DevTools oder WAVE prüfen, die Fehler konkret an die KI zurückgeben, dann Tastatur-Test, kurzer Screenreader-Test mit VoiceOver oder NVDA und ein Blick auf Zoom und Farben. Für einen Screen reichen etwa 15 Minuten.

Welche Tools prüfen KI-Code automatisch auf WCAG-Fehler, und was finden sie nicht?

Bewährt sind axe DevTools, WAVE und Lighthouse im Browser, im Editor zum Beispiel der axe MCP Server. Automatische Tools finden aber nur einen Teil der Fehler, laut einer Herstellerauswertung von Deque rund 57 %. Eine Studie fand in KI-Oberflächen rund zwei Fehler pro Oberfläche, die jeden automatischen Test bestehen, etwa Buttons mit „Klick hier“. Ob Beschriftungen verständlich sind und ein Ablauf mit Screenreader funktioniert, muss ein Mensch prüfen.

Kann ich mit Lovable, v0 oder Cursor ein barrierefreies SaaS bauen?

Ja, aber nicht ohne eigenes Zutun. Die Tools liefern eine Oberfläche, die gut aussieht, aber selten vollständig barrierefrei ist. Mit barrierefreien Komponenten als Vorgabe, klaren Regeln für die KI und einem festen Prüf-Loop kommst du deutlich weiter. Spätestens wenn zahlende Kunden oder öffentliche Auftraggeber dazukommen, lohnt sich zusätzlich ein Audit.