Website mit KI gebaut?

Mit KI-Website-Baukästen wie Lovable, Bolt und v0 beschreiben Sie eine Website in einem Chatfenster und sehen sie wenige Minuten später vor sich. Sie tippen „eine Landingpage für mein Yogastudio mit Buchungsformular“, und das Tool schreibt den Code, meist in React (eine weit verbreitete Technik zum Bauen von Webseiten) mit Tailwind CSS für die Gestaltung. Der Baukasten tut aber vor allem das, worum Sie ihn bitten. Steht Barrierefreiheit nicht in Ihren Anweisungen, bleibt sie dem Zufall überlassen, und eine Website kann gepflegt aussehen und trotzdem schwer nutzbar sein für Menschen, die mit der Tastatur navigieren, einen Screenreader verwenden (Software, die den Bildschirminhalt vorliest) oder stärkeren Kontrast brauchen. Ein paar klare Anweisungen zu Beginn und eine einfache Prüfung danach verhindern die meisten häufigen Probleme. Dieser Artikel gibt Ihnen beides, fertig zum Kopieren.

Warum Barrierefreiheit bei KI-Websites untergeht

Eine Website durch Chatten mit einer KI zu bauen, wird oft „Vibe Coding“ genannt, ein Begriff, den Andrej Karpathy im Februar 2025 geprägt hat. Lovable, Bolt (bolt.new) und v0 von Vercel gehören zu den bekanntesten Tools dafür. Alle drei speichern auf Wunsch dauerhafte Anweisungen, die bei jeder Anfrage mitgelten: Lovable und Bolt nennen das „Knowledge“ und legen es in den Projekteinstellungen ab, in v0 speichern Sie Anweisungen (über die +-Schaltfläche im Eingabefeld), die für jeden Chat gelten, bis Sie sie abschalten. Manche Baukästen nutzen fertige Bausteine wie shadcn/ui, deren Menüs und Dialogfenster bereits mit der Tastatur funktionieren, und die Dokumentation von Lovable nennt Barrierefreiheitsprüfungen unter den eingebauten Skills. Das ist eine gute Grundlage, deckt aber nur ab, was die KI tatsächlich verwendet.

Der tiefere Grund: KI-Modelle lernen aus vorhandenem Webcode, und der größte Teil des Webs ist nicht barrierefrei. Laut der WebAIM-Analyse von 2026, die die eine Million meistbesuchten Startseiten untersucht hat, hatten 95,9 % Fehler, die automatische Tests erkennen können. Text mit zu wenig Kontrast fand sich auf 83,9 % der Seiten, Bilder ohne Alternativtext auf 53,1 % und Formularfelder ohne Beschriftung auf 51 %. Ein Tool, das von der durchschnittlichen Website lernt, übernimmt auch deren Gewohnheiten.

Muster, auf die Sie achten sollten

Diese Muster tauchen in generierten Websites häufig auf. Es sind keine Aussagen über ein bestimmtes Tool, und klare Anweisungen verhindern die meisten davon.

Klickbare Kästen, die keine echten Schaltflächen sind. Eine Karte oder ein einfacher Kasten (ein „div“ im Code) reagiert auf einen Mausklick, ist mit der Tabulatortaste aber nicht erreichbar, und ein Screenreader kündigt nicht an, dass man ihn betätigen kann.
Trendige Farben mit wenig Kontrast. Wünsche wie „minimalistisch“ oder „sanfte Pastelltöne“ führen oft zu hellgrauem Text auf Weiß, den viele Menschen schlecht lesen können.
Schaltflächen mit nur einem Symbol und ohne Namen. Ein Menüsymbol, ein Schließen-Kreuz oder ein Social-Media-Symbol, das ein Screenreader nur als „Schaltfläche“ vorliest. WebAIM fand leere Schaltflächen auf 30,6 % und leere Links auf 46,3 % der Startseiten.
Felder mit nur einem Platzhalter. Der graue Hinweistext im Feld verschwindet, sobald Sie tippen, und keine Beschriftung sagt, wofür das Feld gedacht ist.
Bilder ohne Alternativtext. Alternativtext ist eine kurze schriftliche Beschreibung eines Bildes, die Screenreader vorlesen. Generierte Websites lassen ihn oft weg oder schreiben „image“ oder einen Dateinamen hinein.
Animationen überall. Einblendeffekte, Parallax-Scrollen und Karussells, die von selbst laufen. Bewegung kann manchen Menschen Schwindel verursachen, deshalb bieten Geräte eine Einstellung, um Bewegung zu reduzieren.
Pop-ups, die die Tastatur verlieren. Ein Fenster öffnet sich, aber Tab springt dahinter, Escape bewirkt nichts, oder man kommt nicht mehr heraus.
Keine Seitensprache und durcheinandergeratene Überschriften. Ohne Sprachangabe liest ein Screenreader Ihren deutschen Text womöglich mit englischer Aussprache vor. Überschriften, die nach ihrer Größe gewählt wurden, zerstören die Gliederung der Seite.

Die Barrierefreiheits-Anweisungen zum Einfügen

Fügen Sie den folgenden Block in die dauerhaften Anweisungen Ihres Baukastens ein, bevor Sie die erste Version erzeugen lassen, oder an den Anfang Ihres ersten Prompts, wenn das Tool keine dauerhaften Anweisungen kennt. Er verweist auf die WCAG, die Richtlinien für barrierefreie Webinhalte des W3C, den internationalen Standard, auf dem die meisten Anforderungen an Barrierefreiheit aufbauen.

Wir geben die Anweisungen bewusst auf Englisch wieder. KI-Baukästen verstehen auch Deutsch, aber englische Anweisungen liefern in der Regel die verlässlichsten Ergebnisse, weil die Begriffe genau denen im Code entsprechen. Ihre Website bleibt trotzdem deutschsprachig: Punkt 6 und 8 bitten den Baukasten, Deutsch als Seitensprache festzulegen und Schaltflächen auf Deutsch zu benennen.

Accessibility requirements for this whole project. Aim for WCAG 2.2 level AA. Follow these rules in every change, and tell me when a request would conflict with them. All visible text on the site is in German.

1. Use real buttons for actions and real links for navigation. Never make a div, span or card clickable on its own. If a whole card should be clickable, put a real link inside it.
2. Every form field has a visible label that stays visible while typing. A placeholder is never the only label. Error messages appear in text next to the field and explain how to fix the problem.
3. Every meaningful image has alt text in German that describes what it shows or does. Decorative images get an empty alt (alt=""). Ask me when you cannot know what an image means.
4. Text has a contrast ratio of at least 4.5:1 against its background. Large text (24px, or about 19px bold) and icons, field borders and focus indicators need at least 3:1. This includes dark mode and text on images or gradients.
5. Every link, button and form field has a clearly visible keyboard focus style. Never remove the focus outline without a visible replacement.
6. Every icon-only button or link has a name in German that says what it does, such as "Menü öffnen" or "Dialog schließen".
7. Each page has one h1 that describes it, and headings follow in order (h2, then h3) without skipping levels. Never choose a heading level for its size.
8. Set the page language on the html element to German (lang="de") and give every page a unique, descriptive title.
9. Everything works with a keyboard alone. Tab moves in a logical order, Enter and Space activate buttons, menus open and close with the keyboard, and Escape closes dialogs and menus. When a dialog opens, move focus into it, keep it there until it closes, then return focus to the button that opened it.
10. Respect the prefers-reduced-motion setting by turning off parallax, auto-playing carousels and large movement when it is on. Nothing moves automatically for more than five seconds without a way to pause it.
11. Tap targets are at least 24 by 24 pixels, and main buttons and menu items at least 44 by 44 pixels on mobile, with space between them.
12. Use header, nav, main and footer, and add a "Zum Hauptinhalt springen" skip link as the first item on every page.
13. Never use colour alone to convey meaning, such as red for errors. Add text as well.
14. Keep the built-in keyboard and screen reader behaviour of the components you use.

Das Kontrastverhältnis vergleicht die Helligkeit von Text und Hintergrund, von 1:1 (kein Unterschied) bis 21:1 (Schwarz auf Weiß). Die Mindestgröße von 24 mal 24 Pixeln für Tippziele gehört zu den Anforderungen, die mit WCAG 2.2 hinzugekommen sind; 44 mal 44 ist strenger und für Finger angenehmer.

Folge-Prompts für bestimmte Probleme

Bitten Sie nach einer Prüfung jeweils um eine Korrektur: Kurze, gezielte Prompts liefern verlässlichere Ergebnisse als eine lange Liste. Auch diese Prompts sind auf Englisch. Ersetzen Sie die Teile in eckigen Klammern durch das, was in Ihrem Bericht steht.

Schaltflächen ohne Namen: „The report says buttons have no name. Give every icon-only button an accessible name in German that says what it does, such as 'Menü öffnen'. Do not change how they look.“
Zu wenig Kontrast: „The report says text in [the footer] has too little contrast. Adjust the colours until all text reaches at least 4.5:1, or 3:1 for large text. Stay close to the brand colours and tell me the new values.“
Fehlende Beschriftungen: „The report says form fields have no label. Add a visible label in German above every field in [the contact form], connected to its field.“
Fehlender Alternativtext: „The report says images have no alt text. List every image on this page and suggest alt text in German for each. Mark decorative images for an empty alt. Wait for my approval before applying.“
Tastaturzugang: „I cannot reach [the pricing cards] with the Tab key. Replace clickable divs with real buttons or links so everything works with the keyboard, in a logical order.“
Unsichtbarer Fokus: „When I press Tab, I cannot see where I am. Add a clear focus style to every link, button and field, with at least 3:1 contrast against the background.“
Pop-ups: „The [booking] pop-up does not work with the keyboard. Move focus into it when it opens, keep Tab inside, close it with Escape and return focus to the button that opened it.“
Sprache und Überschriften: „The report says the page language is missing and headings skip levels. Set the page language to German and fix the heading order without changing how the headings look.“

Eine Routine, die funktioniert: prompten, veröffentlichen, prüfen, wiederholen

Sie müssen keinen Code lesen können, um Ihre Website in gutem Zustand zu halten. Sie brauchen eine Schleife, die Sie wiederholen, bis die wichtigen Probleme verschwunden sind.

Mit den Anweisungen prompten. Fügen Sie den Block ein, bevor etwas erzeugt wird, oder lassen Sie ein bestehendes Projekt damit abgleichen.
Eine Vorschau veröffentlichen. Stellen Sie die Website oder eine Vorschau unter einer öffentlichen Webadresse bereit. Eine Prüfung erreicht keine Seite, die nur im Baukasten oder hinter einer Anmeldung sichtbar ist.
Mit ibin prüfen. Der Bericht sagt, was nicht stimmt, wen es betrifft und wo es auf der Seite ist, mit Nahaufnahmen.
Die Probleme zurück in den Baukasten kopieren. Nutzen Sie die verständliche Beschreibung oder die Prompts oben. Auch die technischen Details unter „Code für Entwickler“ können Sie in den Baukasten einfügen.
Erneut prüfen, bis kein Problem mit der Einstufung „Kritisch“ mehr übrig ist, und dann den Rest abarbeiten. Melden Sie sich anschließend an und prüfen Sie bis zu 200 Seiten derselben Website, denn Baukästen wiederholen Kopfbereich, Fußbereich und Formulare auf jeder Seite.
Tastaturtest machen und eigene Inhalte prüfen, wie unten beschrieben.

Der Tastaturtest in zehn Minuten

Automatische Prüfungen finden viele häufige Probleme, grob ein Drittel bis die Hälfte aller Probleme, aber nicht alles. Legen Sie die Maus beiseite und testen Sie Ihre Startseite und Ihr wichtigstes Formular.

Drücken Sie oben auf der Seite Tab. Ist „Zum Hauptinhalt springen“ das Erste, was Sie erreichen, und sehen Sie immer, wo Sie gerade sind?
Drücken Sie weiter Tab. Erreichen Sie jeden Link, jede Schaltfläche und jedes Feld in einer Reihenfolge, die der Seite folgt?
Öffnen und schließen Sie das Menü mit Enter und Escape.
Füllen Sie das Formular nur mit der Tastatur aus und senden Sie es ab. Sind die Fehlermeldungen verständlich?
Öffnen Sie ein Pop-up. Können Sie es mit Escape schließen und dort weitermachen, wo Sie waren?
Schalten Sie in den Bedienungshilfen Ihres Geräts die Option zum Reduzieren von Bewegung ein und laden Sie die Seite neu. Hören die großen Animationen auf?
Zoomen Sie auf 200 %. Ist aller Text noch lesbar?

Was die KI nicht wissen kann

Manches kann weder ein Baukasten noch eine automatische Prüfung für Sie beurteilen, weil es von Ihrem Ziel und Ihrem Publikum abhängt.

Ob eine Bildbeschreibung passt. Die KI schreibt vielleicht „lächelnde Frau am Laptop“, weiß aber nicht, dass das Foto Ihre Gründerin zeigt oder dass eine Grafik zeigen soll, dass sich die Buchungen verdoppelt haben.
Ob Linktexte verständlich sind. Sechs Links mit „Mehr lesen“ verwirren jemanden, der sich eine Liste der Links vorlesen lässt. „Mehr über unsere Yogakurse“ funktioniert überall.
Ob Ihre Texte klar sind. Kurze Sätze und vertraute Wörter helfen allen, auch Menschen, die in einer Zweitsprache lesen.
Ob die Schritte logisch sind. Ein Buchungsablauf kann alle automatischen Tests bestehen und trotzdem verwirren.

Das gilt auch für alles, was Sie nach dem Start hinzufügen: Jedes neue Bild braucht Alternativtext, jeder neue Link einen Text, der sagt, wohin er führt. Der optionale zweite Blick der KI in ibin bewertet Bildbeschreibungen, Linktexte, Tastaturbedienung und verständliche Sprache auf einer Skala von 1 bis 5, damit Sie wissen, wo Sie zuerst hinschauen sollten. Die letzte Entscheidung trifft ein Mensch, und wenn möglich, bitten Sie jemanden, der täglich mit Tastatur oder Screenreader arbeitet, Ihre Website auszuprobieren.

Prüfen Sie Ihre KI-Website

Veröffentlichen Sie eine Vorschau und prüfen Sie eine Seite kostenlos mit ibin. Kopieren Sie die verständlich beschriebenen Probleme mit den Prompts oben in Ihren Baukasten, prüfen Sie erneut und nutzen Sie die Anleitungen zur Barrierefreiheit, wenn Sie eine Korrektur besser verstehen möchten. Ist Ihre Startseite in gutem Zustand, melden Sie sich an und prüfen Sie kostenlos bis zu 200 Seiten derselben Website.

Sehen Sie, wie Ihre Website abschneidet

Prüfen Sie kostenlos eine Seite, ohne Konto. Sie erhalten eine klare Liste, was zuerst zu beheben ist, mit Bildern, wo jedes Problem liegt.

Website mit KI gebaut? So wird sie ab dem ersten Prompt barrierefrei