Sind KI-erstellte Websites barrierefrei? Ehrliche Antwort

Teilweise. Generierter Code bringt sauberes HTML mit, und damit einen echten Teil der Barrierefreiheit ohne Zutun: Überschriftenstruktur, native Formularfelder, bedienbare Schaltflächen. Was fast nie von allein stimmt, sind Kontrast, sichtbarer Tastaturfokus und Beschriftungen an selbst gebauten Bedienelementen. Eine generierte Seite ist ein guter Ausgangspunkt, aber keine geprüfte Seite.

Diese Antwort ist brauchbarer als ein Ja oder ein Nein, weil Barrierefreiheit kein Schalter ist. Sie ist eine Menge konkreter Eigenschaften, die eine Seite hat oder eben nicht hat, und generierter Code trifft davon einen Teil zuverlässig und verfehlt den Rest nach einem vorhersagbaren Muster. Dieser Text benennt das Muster und gibt Ihnen danach eine Prüfung, die Sie heute noch durchführen können.

Was heißt „barrierefrei“ hier konkret?

Barrierefrei heißt: Jemand kann Ihre Seite mit einem Screenreader benutzen, mit der Tastatur statt mit der Maus, bei 200 Prozent Zoom, mit eingeschränktem Sehvermögen oder mit einer motorischen Einschränkung, die genaues Klicken erschwert. Die Arbeitsgrundlage sind die WCAG, die Web Content Accessibility Guidelines des W3C, gegliedert in die Stufen A, AA und AAA.

Für die meisten Websites ist Stufe AA das praktische Ziel. Dort liegen die Anforderungen, die im Alltag tatsächlich auffallen: ausreichender Textkontrast, sichtbarer Fokus, eine Beschriftung an jedem Eingabefeld, Alternativtexte für inhaltstragende Bilder und eine Seite, die ohne Zeigegerät bedienbar bleibt.

Zwei Fragen geraten dabei regelmäßig in einen Topf und sollten getrennt bleiben. Die eine: Können Menschen mit Einschränkungen Ihre Seite benutzen? Das ist eine Produktfrage. Die andere: Unterliegen Sie einer rechtlichen Pflicht? In der EU gibt der European Accessibility Act den Rahmen vor, in Deutschland umgesetzt im Barrierefreiheitsstärkungsgesetz. Ob Ihr Angebot darunter fällt, hängt von Branche, Zielgruppe und Unternehmensgröße ab. Bei der ersten Frage hilft ein KI-Builder. Die zweite beantwortet er nicht, und niemand sollte behaupten, er täte es.

Was macht ein KI-Builder von sich aus richtig?

Mehr, als Skeptiker erwarten. Nicht aus Klugheit, sondern weil generierte Seiten aus Standardbausteinen entstehen, und Standard-HTML bringt Verhalten bereits mit.

• Dokumentstruktur. Überschriften sind meist korrekt verschachtelt, Abschnitte sind echte Abschnitte, und ein Screenreader kann daraus eine Gliederung aufbauen. Allein das macht eine Seite navigierbar, was ein Stapel gestylter div-Elemente nicht ist.
• Native Bedienelemente. Ein generiertes Formular benutzt in der Regel echte input-, button- und select-Elemente. Die sind mit der Tastatur bedienbar, fokussierbar und werden korrekt angesagt, ganz ohne Zusatzarbeit.
• Linktexte. Modelle schreiben eher „Preise ansehen“ als „hier klicken“, weil sie auf Text trainiert wurden, der sich gut liest. Für Screenreader-Nutzer, die sich eine Linkliste vorlesen lassen, ist das ein spürbarer Unterschied.
• Flexibles Layout. Ein Layout, das ein schmales Fenster übersteht, übersteht meist auch Browser-Zoom. Das ist eine echte Anforderung bei Sehbeeinträchtigung und nicht bloß ein Smartphone-Thema.

Garantiert ist nichts davon für einen einzelnen Build. Es ist die Grundquote: Diese Dinge kommen richtig heraus, weil das darunterliegende HTML schon richtig war.

Wo scheitern KI-erstellte Seiten regelmäßig?

Die Ausfälle sammeln sich an vier Stellen, und jede geht auf eine Gestaltungsentscheidung zurück, nicht auf schlampiges Markup.

Kontrast. Sie bitten um eine „ruhige, gedämpfte Farbwelt“ und bekommen genau das: hellgrauer Fließtext auf Weiß. Auf Ihrem Monitor wirkt das edel, bei reduzierter Kontrastempfindlichkeit verschwindet es. Stufe AA verlangt für normal großen Text ein Kontrastverhältnis von mindestens 4,5:1. Nichts an einer Stimmungsbeschreibung sagt dem Modell, dass es diese Zahl prüfen soll.

Sichtbarer Fokus. Moderne Entwürfe entfernen gern den Fokusrahmen des Browsers, weil er die Optik stört. Kommt nichts an seine Stelle, sieht jemand, der mit der Tastatur arbeitet, nicht mehr, wo er sich befindet. Damit ist die Seite ohne Maus unbenutzbar, unabhängig davon, wie gut sie aussieht.

Selbst gebaute Bedienelemente. Akkordeons, Tabs, Dialoge und Karussells, die aus div-Elementen und Klick-Handlern zusammengesetzt sind, sehen korrekt aus und sagen nichts an. Hier braucht es ARIA-Rollen, Tastaturbedienung und Fokusverwaltung, und genau hier ist generierter Code am ehesten unvollständig.

Bilder und Icons. Dekorative Icons kommen oft ganz ohne alt-Attribut statt mit einem leeren, und inhaltstragende Bilder bekommen einen allgemeinen Alternativtext, weil das Modell nicht weiß, was später im Bild zu sehen sein wird. Der häufigste einzelne Mangel ist eine Schaltfläche, die nur aus einem Icon besteht und keinen zugänglichen Namen hat.

Wie formuliere ich Barrierefreiheit im Prompt?

Konkret. „Mach es barrierefrei“ ist zu abstrakt, um die Ausgabe stark zu verändern. Einzelne benannte Eigenschaften verändern sie deutlich, weil jede Formulierung auf eine Entscheidung trifft, die der Generator ohnehin fällen muss.

Erstelle eine Website für eine Physiotherapie-Praxis in Kassel.
Fließtext mit mindestens 4,5:1 Kontrast gegen den Hintergrund.
Sichtbarer Fokusrahmen auf jedem Element, das man anklicken kann.
Jedes Formularfeld mit echtem label, Platzhalter nur als Zusatz.
Jede Icon-Schaltfläche bekommt einen zugänglichen Namen.
Sprache: alle Texte auf Deutsch, Anrede „Sie“.

Das sind vier prüfbare Anforderungen statt einer Stimmung. Wenn Sie in Zugo bauen, funktionieren dieselben Sätze auch als Änderung an einem bestehenden Projekt, und diese Reihenfolge ist meist die günstigere: erst das Design holen, das Sie wollen, dann eine Änderung für den Barrierefreiheits-Durchgang ausgeben, statt beides gleichzeitig zu verhandeln.

Wie prüfe ich eine Seite in zehn Minuten?

Für die typischen Mängel brauchen Sie keine Fachkraft und kein gekauftes Werkzeug. Sechs Prüfungen decken den größten Teil dessen ab, was in der Praxis kaputt ist, und alle laufen in einem Browser, den Sie schon haben.

Zwei weitere Schritte lohnen sich, sobald die Grundlagen sitzen: einmal mit dem Screenreader Ihres Betriebssystems durch die Seite gehen und prüfen, ob ein geschlossener Dialog den Fokus an das Element zurückgibt, das ihn geöffnet hat. Die Seite Easy Checks des W3C ist der nächste Schritt, wenn Sie tiefer gehen wollen, ohne ein Werkzeug zu kaufen.

Was kostet die Nachbesserung?

Wenig, und das ist das eigentliche Argument, es überhaupt zu tun. Eine Änderung ist ein Satz, kein Ticket.

Die Tarife dazu: Free gibt Ihnen 5 Credits, Pro kostet 25 $ im Monat und enthält 200 Credits, Business kostet 99 $ im Monat und enthält 800. Zweihundert Credits sind, wenn Sie sie nur dafür ausgeben, 66 Änderungen oder 33 Builds oder rund 16 mehrseitige Plattformen. Ein Barrierefreiheits-Durchgang lässt sich meist in einer einzigen Nachricht zusammenfassen, weil die gefundenen Mängel gemeinsam beschrieben werden können.

Abgerechnet wird in US-Dollar. Wer bei null anfängt, findet den Ablauf vom Prompt bis zur veröffentlichten Adresse in Website mit KI erstellen; für Projekte mit Konten und Datenbank steht dasselbe in App ohne Programmieren erstellen.

Was kann ein KI-Builder nicht für Sie erledigen?

Drei Dinge, und sie gehören klar benannt, weil zwischen „sieht sauber aus“ und „hat eine Prüfung bestanden“ der Abstand liegt, an dem man sich verbrennt.

Er kann die Absicht nicht beurteilen. Ob ein Bild dekorativ oder inhaltstragend ist, ist eine Frage an Ihren Inhalt, nicht an Ihr Markup. Ein Modell rät, Sie wissen es.

Er kann nicht mit echter assistiver Technik testen. Automatische Prüfungen finden fehlende Beschriftungen und zu geringen Kontrast. Sie finden keine Überschriftenstruktur, die formal gültig und inhaltlich Unsinn ist, und keinen Ablauf, der zwar bedienbar, aber zermürbend ist. Diese Lücke schließt ein Mensch, am besten einer, der täglich mit einem Screenreader arbeitet.

Er kann keine rechtliche Einschätzung abgeben. Pflichten hängen davon ab, wo Sie tätig sind und was für eine Organisation Sie sind. Fällt Ihr Angebot unter eine konkrete Vorgabe, behandeln Sie generierte Ausgabe als Entwurf, den eine Fachperson prüft, genauso wie Sie es mit generiertem Vertragstext täten.

Zu den Grenzen gehören auch unsere eigenen. Zugo startet jeden Build in einer Sandbox, bevor Sie ihn zu sehen bekommen: Ein Build, der nicht geladen hat, wird nicht ausgeliefert. Diese Prüfung beantwortet genau eine Frage, nämlich ob die Seite gerendert wurde. Sie ist keine Barrierefreiheitsprüfung und behauptet das auch nicht. Und bei einem komplexen Produkt ersetzt ein Builder kein Entwicklungsteam: Sehr spezifische Fachlogik entsteht über mehrere Änderungen, nicht über einen einzigen Prompt.

Wo hilft ein KI-Builder trotzdem?

Er nimmt der leeren Seite die Ausrede. Eine handgeschriebene Website von jemandem, der die WCAG nie gelesen hat, ist nicht barrierefreier als eine generierte. Meist ist sie es weniger, weil Menschen zu selbst gebauten Bedienelementen greifen, wo der Generator zu nativen greift.

Der realistische Ablauf ist bauen, prüfen, nachbessern. Eine einfache Seite steht in etwa einer Minute, eine mehrseitige Plattform in einigen Minuten, und danach ist jede Korrektur ein Satz im Chat. Zwei Durchgänge räumen die offensichtlichen Mängel in aller Regel ab. Was der Chat-Änderung ähnelt und wie sich das anfühlt, beschreibt der Text zu Vibe Coding.

Womit fange ich an?

Fangen Sie mit etwas an, das Sie bereits veröffentlicht haben. Gehen Sie mit Tab hindurch, prüfen Sie den Kontrast des Fließtexts und zählen Sie, wie viele der sechs Prüfungen die Seite besteht. Die meisten Seiten fallen bei zwei oder drei durch, egal ob ein Mensch oder ein Modell sie geschrieben hat.

Danach beheben Sie die Ausfälle dort, wo es am billigsten ist: in einem Builder, in dem eine Änderung ein Satz ist. Auf zugo.dev starten Sie mit 5 Credits; da ein frischer Build 6 kostet, reicht das Startguthaben für eine Änderung an einem bestehenden Projekt, nicht für einen kompletten Neubau. Veröffentlichen Sie das Ergebnis auf eine Adresse wie ihr-projekt.zugo.run und lassen Sie dieselben sechs Prüfungen noch einmal auf der Live-Seite laufen, bevor Sie eine eigene Domain darauf legen. Wie diese Umstellung abläuft, steht in KI-App-Builder mit eigener Domain.

So wird Barrierefreiheit kein Projekt. Sie wird ein Arbeitsschritt.