Lovable macht aus einem Chatgespräch eine funktionierende Website oder App. Es schreibt soliden, modernen Code, baut aber, worum Sie bitten: Steht Barrierefreiheit nicht in der Anfrage, tauchen einige Probleme in Projekt um Projekt wieder auf. Diese Anleitung zeigt, was Lovable erzeugt, auf welche Probleme Sie achten sollten, wo Sie Anweisungen ablegen, damit Lovable sie bei jeder Änderung befolgt, und wie Sie das Ergebnis prüfen.
Was Lovable baut
Lovable schreibt React (eine weit verbreitete Technik zum Bauen von Webseiten) in TypeScript und gestaltet mit Tailwind CSS. Seit dem 13. Mai 2026 laufen neue Projekte auf TanStack Start, einem React-Framework, das Seiten auf dem Server vorbereitet, damit sie schneller laden und Suchmaschinen sie besser lesen. Ältere Projekte sind meist Single-Page-Apps, gebaut mit Vite. Für Daten, Logins und Dateien nutzt Lovable Supabase, direkt oder über Lovable Cloud.
Die meisten Oberflächenteile stammen aus shadcn/ui, einer Sammlung fertiger Komponenten auf Basis von Radix. Menüs, Dialoge, Tabs und Auswahllisten aus dieser Sammlung funktionieren mit der Tastatur und geben Screenreadern (Software, die den Bildschirminhalt vorliest) die richtigen Informationen. Ein guter Anfang, der aber nur hilft, wo Lovable diese Komponenten tatsächlich verwendet und ihr Verhalten unverändert lässt.
Häufige Probleme
Diese Muster tauchen in generierten Websites regelmäßig auf. Sie sind keine Fehler jedes Lovable-Projekts, und klare Anweisungen verhindern die meisten.
- Schaltflächen, die nur aus einem Symbol bestehen. Lovable nutzt die Symbolsammlung Lucide für Menüs, Schließen-Kreuze, Suche, soziale Netzwerke und „In den Warenkorb“. Ohne Namen im Code sagt ein Screenreader nur „Schaltfläche“.
- Fehlermeldungen nur als Toast. Ein Toast ist die kleine Meldung, die in einer Ecke erscheint und nach ein paar Sekunden wieder verschwindet. Steht ein Formularfehler nur dort, wird er leicht übersehen, und neben dem Feld steht nichts, was zu korrigieren ist.
- Gedämpfter Text mit zu wenig Kontrast. Das Standarddesign verwendet ein weiches Grau für Nebentext. Auf Weiß und vor allem auf hellgrauen Karten erreicht es oft den Mindestkontrast nicht.
- Fehlende oder falsche Seitensprache. Die Seitensprache sagt dem Screenreader, welche Aussprache er verwenden soll. Eine deutsche Website, die sich als „Englisch“ ausgibt, wird mit englischem Akzent vorgelesen.
- Klickbare Karten und Kästen. Eine Produktkarte oder ein Preisblock, der auf Mausklicks reagiert, aber kein echter Link und keine echte Schaltfläche ist, lässt sich mit der Tab-Taste nicht erreichen.
- Felder nur mit Platzhalter. Der graue Hinweistext im Feld verschwindet, sobald man zu tippen beginnt.
Wo dauerhafte Anweisungen hingehören
Lovable nennt seine dauerhaften Anweisungen Knowledge. Sie werden bei jeder Anfrage mitgeschickt, Sie schreiben Ihre Barrierefreiheitsregeln also nur einmal.
- Projekt-Knowledge gilt für ein Projekt. Öffnen Sie die Projekteinstellungen, indem Sie oben auf den Projektnamen klicken und Settings wählen, oder drücken Sie Strg+. (Cmd+. auf dem Mac), und gehen Sie zum Bereich Knowledge. Die Dokumentation von Lovable beschreibt diesen Weg.
- Workspace-Knowledge gilt für alle Projekte in Ihrem Workspace. Bauen Sie mehrere Websites, legen Sie die Barrierefreiheitsregeln dort ab und nutzen Sie Projekt-Knowledge für Markenfarben und Inhalte.
Halten Sie Knowledge kurz, mit Aufzählungspunkten. Menünamen ändern sich hin und wieder; suchen Sie nach „Knowledge“, falls der Weg oben nicht mehr stimmt.
Lovable bietet außerdem Skills, wiederverwendbare Abläufe, die Sie starten, indem Sie im Chat einen Schrägstrich tippen. Einer der eingebauten Skills ist /accessibility, der häufige Barrieren prüft und behebt. Nützlich für eine Prüfrunde, aber kein Ersatz für Knowledge: Ein Skill wirkt, wenn Sie ihn aufrufen, Knowledge gilt bei jeder Änderung.
Anweisungen für Lovable
Fügen Sie dies in Projekt- oder Workspace-Knowledge ein. Passen Sie die Sprache an, wenn Ihre Website nicht auf Deutsch ist.
Barrierefreiheitsregeln für jede Änderung (Ziel: WCAG 2.2 Stufe AA): - Verwende semantische Elemente: header, nav, main, footer, einen echten <button> für Aktionen und ein echtes <a> oder den Router-Link für Navigation. Setze nie onClick auf ein div, span oder eine Card. Ist eine ganze Karte klickbar, setze einen echten Link hinein. - Jeder Button, der nur aus einem Symbol (Lucide) besteht, bekommt ein aria-label in der Sprache der Website, zum Beispiel "Menü öffnen". Das Symbol selbst ist aria-hidden. - Jedes Input, Select und Textarea hat ein sichtbares, verknüpftes Label. Ein Platzhalter ist nie die einzige Beschriftung. - Formularfehler erscheinen als Text neben dem Feld und sind mit ihm verknüpft. Zeige einen Fehler nie nur in einem Toast. - Der Textkontrast beträgt mindestens 4,5:1, bei großem Text 3:1. Prüfe text-muted-foreground auf jedem Hintergrund, auch auf Karten und im Dunkelmodus, und dunkle ihn bei Bedarf ab. - Behalte den sichtbaren Fokusring auf allen interaktiven Elementen. Entferne ihn nie. - Setze lang="de" auf dem html-Element und gib jeder Seite einen eindeutigen Titel. - Ein h1 pro Seite, Überschriften in der richtigen Reihenfolge. Wähle Überschriftenebenen nie nach ihrer Größe. - Behalte das Tastaturverhalten der shadcn/ui- und Radix-Komponenten bei. Dialoge schließen mit Escape und geben den Fokus zurück. - Bedeutungstragende Bilder haben einen Alternativtext, der ihren Zweck beschreibt; dekorative Bilder bekommen alt="". - Beachte prefers-reduced-motion bei Animationen.
Folge-Prompts für häufige Probleme
Bitten Sie nach einer Prüfung um eine Korrektur nach der anderen. Ersetzen Sie die Teile in eckigen Klammern.
- Symbol-Schaltflächen: „Gib jeder Schaltfläche, die nur aus einem Symbol besteht, in [Kopfzeile und Fußzeile] einen klaren deutschen Namen, der sagt, was sie tut. Ändere nichts an ihrem Aussehen.“
- Fehler nur im Toast: „Zeige in [dem Kontaktformular] jeden Fehler als Text unter dem zugehörigen Feld an, mit dem Feld verknüpft. Behalte den Toast nur als Ergänzung.“
- Gedämpfter Text: „Der graue Nebentext hat auf [den Preiskarten] zu wenig Kontrast. Dunkle die gedämpfte Textfarbe ab, bis sie auf jedem Hintergrund, auf dem sie vorkommt, mindestens 4,5:1 erreicht, im hellen und im dunklen Modus.“
- Seitensprache: „Setze die Seitensprache auf jeder Seite auf Deutsch (de).“
- Klickbare Karten: „Ich erreiche [die Projektkarten] nicht mit der Tab-Taste. Ersetze die Klickfunktion auf der Karte durch einen echten Link um den Titel, damit die Karte mit der Tastatur funktioniert.“
Nach einer größeren Änderung können Sie auch /accessibility ausführen und die Seite danach erneut mit ibin prüfen.
Veröffentlichen und prüfen
ibin prüft Seiten im öffentlichen Web und braucht deshalb eine Adresse, die jeder öffnen kann.
- Veröffentlichen Sie. Klicken Sie oben rechts im Editor auf Publish. Lovable schlägt eine Adresse auf lovable.app vor, die Sie ändern können. Geteilte Vorschaulinks sind dafür gedacht, einer Person einen Zwischenstand zu zeigen, und laufen nach sieben Tagen ab; nutzen Sie zum Prüfen die veröffentlichte Adresse.
- Sorgen Sie dafür, dass die Website öffentlich ist. In manchen Tarifen können Sie den Zugang zur veröffentlichten Website auf Ihren Workspace beschränken. Ein Prüfwerkzeug kann sich nicht anmelden; wählen Sie also Public, solange Sie prüfen.
- Prüfen Sie die Seite mit ibin. Beginnen Sie mit der Startseite, dann mit Ihrem wichtigsten Formular.
- Fügen Sie die Lösung in Lovable ein. Bei jedem Problem im Bericht gibt es die Schaltfläche „Anleitung für ein KI-Tool kopieren“. Fügen Sie das Ergebnis in den Lovable-Chat ein. Es bittet um eine Korrektur in der Website selbst.
- Veröffentlichen Sie erneut und prüfen Sie erneut. Änderungen erscheinen erst nach dem Veröffentlichen unter der öffentlichen Adresse.
- Prüfen Sie weitere Seiten. Melden Sie sich an, um bis zu 200 Seiten derselben Website zu prüfen, und schalten Sie wöchentliche Prüfungen ein, um wiederkehrende Probleme zu erkennen.
Automatische Prüfungen finden etwa ein Drittel bis die Hälfte aller Probleme. Machen Sie deshalb auch den Tastaturtest in zehn Minuten.
Was Lovable nicht beurteilen kann
Manches hängt von Wissen ab, das nur Sie haben. Lovable beschreibt ein Foto vielleicht als „Team bei der Arbeit im Büro“, weiß aber nicht, dass es Ihre drei Gründer zeigt. Es kann nicht beurteilen, ob „Mehr erfahren“ verständlich ist, wenn ein Screenreader alle Links einer Seite auflistet, oder ob Ihr Text gut lesbar ist. Prüfen Sie Bildbeschreibungen und Linktexte selbst, jedes Mal wenn Sie Inhalte hinzufügen. Der optionale zweite Blick mit KI in ibin bewertet sie von 1 bis 5, damit Sie wissen, wo Sie anfangen, aber die Entscheidung trifft ein Mensch.
Den allgemeinen Ansatz, der in jedem Tool funktioniert, finden Sie in der Übersicht für KI-Baukästen. Die Reparaturanleitungen erklären jedes Problem verständlich, zum Beispiel Schaltflächen ohne Namen und Farbkontrast.
Prüfen Sie Ihre Lovable-Website
Veröffentlichen Sie Ihr Projekt und prüfen Sie eine Seite kostenlos mit ibin. Kopieren Sie die Anleitung zu jedem Problem in Lovable, veröffentlichen Sie erneut und prüfen Sie erneut, bis die dringenden Probleme verschwunden sind.
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.