Kontakt

Aus dem Blog

Wie du deine KI-generierte Website barrierefrei und gut für SEO machst

Du lässt gerade eine neue Website von einer KI umsetzen – oder ein bestehendes Projekt mit KI-Unterstützung weiterentwickeln? Ohne ein paar Vorgaben wirst du dabei keine gute Website bekommen. Denn was die KI dir liefert, hängt davon ab, was sie vorher gelernt hat. Und ihr Lernmaterial ist das Web, so wie es heute ist – im Durchschnitt nicht barrierefrei.

Lesedauer: ca. 9 Minuten

Alle Artikel

Das Problem: Die KI kopiert den Durchschnitt

Ein Sprachmodell hat als Trainingsmaterial Millionen Websites gesehen – und daraus gelernt, was „normaler" Code ist. Das Problem: Normal ist nicht gleich gut. Die gute Nachricht: Das lässt sich mit ein paar Zeilen in deinem Projekt korrigieren, bevor die erste Zeile Code entsteht.

Für wen ist dieser Artikel?

Für alle, die mit KI-Unterstützung entwickeln – ob ganze Website oder einzelne Komponenten – und wollen, dass Barrierefreiheit und Auffindbarkeit von Anfang an stimmen, statt am Ende nachgebessert zu werden.

Wie gut ist der Durchschnitt?

Im Web überwiegen anklickbare div-Elemente statt echter Buttons, Formularfelder mit Platzhalter statt Beschriftung, und Fokusrahmen, die irgendwer aus Design-Gründen entfernt hat. Genau das reproduziert eine KI zuverlässig, wenn du ihr keine anderen Vorgaben machst.

Das ist kein Randproblem: Die WebAIM Million – eine jährliche Untersuchung der meistbesuchten Websites – findet Jahr für Jahr automatisch erkennbare Verstöße gegen die Barrierefreiheits-Richtlinien (WCAG).

über 90 %

der geprüften Startseiten haben erkennbare Verstöße – und das Jahr für Jahr aufs Neue.

+ 10 %

gegenüber 2025 – im Bericht 2026 steigen die Werte erstmals seit Jahren wieder, statt zu sinken.

WebAIM Million, Bericht 2026 (Externer Link, öffnet sich in einem neuen Fenster) (Englisch)

Wer eine KI ohne Vorgaben umsetzen lässt, bekommt mit hoher Wahrscheinlichkeit genau diesen Durchschnitt mitgeliefert – inklusive der Fehler.

Als einen möglichen Grund für den Anstieg nennt WebAIM selbst den wachsenden Einsatz automatisierter und KI-gestützter Programmierung. Ein Kreis, der sich schließt: Die KI lernt aus fehlerhaftem Code, produziert damit selbst wieder fehlerhaften Code – und der landet über kurz oder lang erneut als Trainingsmaterial im Netz.

Die Lösung: eine Regeldatei statt eines Prompts

Der naheliegende erste Gedanke ist, es im Chat zu sagen: „Bitte barrierefrei umsetzen." Das Problem: Diese Anweisung gilt nur für dieses eine Gespräch. Beim nächsten Chat, in einer neuen Sitzung, oder wenn ein Kollege dieselbe KI nutzt, fängst du wieder bei null an.

Eine Datei im Projektverzeichnis löst das. Sie wird automatisch bei jedem Gespräch, von jedem Werkzeug und jeder Person im Team gelesen – du musst sie kein zweites Mal erwähnen. Je nach KI-Werkzeug heißt sie:

  • CLAUDE.md (Claude Code)
  • AGENTS.md (verbreiteter Standard, u. a. Codex)
  • .github/copilot-instructions.md (GitHub Copilot)
  • oder eine Regeldatei direkt im Editor

Die Chancen stehen gut, dass du beim Entwickeln mit KI bereits so eine Datei im Projekt hast – viele Werkzeuge legen sie inzwischen automatisch an, sobald ein Projekt entsteht. Schon ein paar gezielte Ergänzungen wie im Beispiel weiter unten reichen aus, damit der generierte Code um ein Vielfaches besser wird.

Einmal geschrieben, gilt die Datei für das ganze Projekt – egal ob du damit eine Website komplett neu aufsetzt oder nur einzelne Komponenten optimierst.

Zwei Richtlinien, damit die Vorgaben auch wirken

1. Zahlen statt Adjektive. „Der Fokus soll gut sichtbar sein" ist keine Anforderung, sondern eine Hoffnung – die KI interpretiert „gut sichtbar" nach eigenem Ermessen. „Fokusrahmen 3 px, Abstand 2 px" ist dagegen eindeutig: prüfbar, wiederholbar, nicht verhandelbar. Dasselbe gilt für das Ziel insgesamt: nicht „barrierefrei", sondern konkret WCAG 2.2 Stufe AA.

2. Verbote wirken stärker als Wünsche. Weil über 90 Prozent der Vorlagen im Trainingsmaterial fehlerhaft sind, reicht eine positive Bitte oft nicht aus, um dagegen anzukommen. „Bitte barrierefreie Formulare" lässt der KI viel Spielraum. „Kein Platzhalter als Beschriftung" schließt genau das eine Muster aus, das sonst zuverlässig auftauchen würde. Ein klares Verbot schlägt die Trainingsdaten – eine vage Bitte meistens nicht.

Eine Prüfstelle, die die KI selbst befragen kann

Für Details lohnt sich ein Blick auf die Website Specification (Externer Link, öffnet sich in einem neuen Fenster) – ein frei zugängliches Nachschlagewerk mit rund 170 Themen in zehn Kategorien: Grundlagen, SEO, Sicherheit, Barrierefreiheit, Performance, Datenschutz, Mehrsprachigkeit und mehr.

Über den MCP-Server mcp.specification.website kann dein KI-Assistent diese Prüfstelle direkt selbst abfragen, statt zu raten. Dafür reicht eine einzige Zeile in deiner Regeldatei – siehe Vorlage unten.

Die fertige Vorlage zum Kopieren

Lege den Inhalt als CLAUDE.md oder AGENTS.md in dein Projektverzeichnis, oder ergänze eine bestehende Datei. Nur den letzten Abschnitt musst du selbst füllen. Die Vorlage ist auf Englisch gehalten, wie auch der Code, auf den sie sich bezieht.

# Project rules

## Target level

WCAG 2.2 level AA.

## Markup

- Semantic HTML first. ARIA only where no element does the job.
- Focus ring 3px, offset 2px, on every operable element (2.4.11).
- Targets at least 24 × 24 px, aim for 44 × 44 px (2.5.8).
- Visible label with for/id, plus autocomplete. A placeholder is not a label (1.3.5).
- Validate on submit only. Error summary on top, links to the fields,
  aria-describedby (3.3.1).
- alt test: is information lost without the image? If not, alt="".
- Colour never carries information on its own (1.4.1). Contrast 4.5:1 / 3:1.
- Motion behind prefers-reduced-motion (2.3.3).
- No sideways scrolling at 320px, no loss of text at 200% zoom (1.4.10, 1.4.4).
- Headings form the outline. Never skip a level.

## SEO

- canonical points at the page itself, never at the main language version.
- hreflang reciprocal, including self and x-default.
- Own title and own description per page, following a fixed pattern.
- URLs are a promise. Move them only with a 301 — with and without .html.
- Indexing explicit: public pages indexable, previews noindex.
- JSON-LD only for facts that are visible on the page.

## Never

- <div onclick> where a <button> belongs
- outline: none without an equivalent replacement
- positive tabindex
- aria-label on an element that already has a visible name, or differing
  from it (2.5.3)
- "here" and "read more" as link text
- status, warning or severity by colour alone
- fonts from the Google CDN — self-host them (GDPR)
- CAPTCHA — honeypot plus a server-side filter
- extra libraries without asking

## Sources

- Normative: WCAG 2.2, w3.org/TR/WCAG22
- Implementation: Website Specification, via MCP at mcp.specification.website.
  Before every new page template: fetch the accessibility/required checklist.

## Project-specific

This is where everything goes that nobody can guess. For example:

- No hero images. Every page starts with text.
- Language and tone of voice, matching the lang attribute.
- Use elements which already exist.

Was die einzelnen Abschnitte bedeuten

Ein kurzer Durchgang durch die Vorlage, damit klar ist, was dahintersteckt.

Target level

Legt das gemeinsame Ziel fest, auf das sich alle folgenden Punkte beziehen. Stufe AA ist die, die sich für eine ganze Website realistisch erreichen lässt – die höchste Stufe AAA praktisch nie vollständig. Und die Fassung gehört ausdrücklich dazu: Ohne Versionsangabe orientiert sich eine KI an irgendeiner älteren, und die neuen Kriterien der Fassung 2.2 fallen stillschweigend unter den Tisch.

Markup

Die technischen Grundregeln. Die Zahl in Klammern verweist jeweils auf das passende WCAG-2.2-Kriterium, falls du nachschlagen willst:

  • Semantisches HTML zuerst, ARIA nur wo nötig – echte Elemente wie <button> oder <nav> verwenden, statt alles mit <div> und ARIA-Attributen nachzubauen.
  • Fokusrahmen 3 px, Abstand 2 px (2.4.11) – ohne sichtbaren Fokus ist eine Seite mit der Tastatur kaum bedienbar.
  • Klickflächen mind. 24 × 24, besser 44 × 44 px (2.5.8) – wichtig für Touch-Bedienung und eingeschränkte Feinmotorik.
  • Sichtbare Beschriftung statt Platzhalter (1.3.5) – Platzhaltertext verschwindet beim Tippen und wird von Screenreadern oft ignoriert.
  • Validierung erst beim Absenden, Fehlerübersicht oben (3.3.1) – Live-Validierung während des Tippens unterbricht den Schreibfluss, vor allem mit Screenreader.
  • alt-Test – nur Bilder mit Informationsgehalt brauchen einen Alternativtext, rein dekorative bekommen alt="".
  • Farbe trägt nie allein die Information (1.4.1) – wichtig bei Farbfehlsichtigkeit, etwa bei Pflichtfeldern oder Statusanzeigen.
  • Bewegung hinter prefers-reduced-motion (2.3.3) – wer reduzierte Bewegung eingestellt hat, bekommt keine erzwungenen Animationen.
  • Kein seitliches Scrollen bei 320 px, kein Textverlust bei 200 % Zoom – die Seite muss auf kleinen Bildschirmen und bei starker Vergrößerung nutzbar bleiben.
  • Überschriften bilden die Gliederung – mit Screenreader springt man oft direkt von Überschrift zu Überschrift, eine übersprungene Ebene macht das unzuverlässig.

SEO

Hält die Punkte fest, die am häufigsten schiefgehen, wenn eine KI eine mehrsprachige oder mehrseitige Website umsetzt:

  • doppelte oder fehlende canonical- und hreflang-Angaben
  • kopierte Seitentitel
  • URLs, die ohne Weiterleitung verschoben werden
  • unklare Indexierung
  • strukturierte Daten (JSON-LD), die nicht zum sichtbaren Inhalt passen

Never

Die Liste der Muster, die am zuverlässigsten aus dem Trainingsmaterial auftauchen, wenn man sie nicht ausdrücklich verbietet – von der Klick-div statt Button über entfernte Fokusrahmen bis zur Google-Fonts-Einbindung, die als CDN-Aufruf eine DSGVO-Frage ist. Ein Verbot ist hier bewusst einfacher formuliert als eine Erklärung, warum – das würde die Datei nur aufblähen.

Sources

Sagt der KI, wo sie nachschlagen soll, statt zu raten: WCAG 2.2 als normativer Text, und die Website Specification über den MCP-Server für die konkrete Umsetzung – inklusive der Anweisung, vor jeder neuen Seitenvorlage die Barrierefreiheits-Checkliste abzurufen.

Was in den letzten Abschnitt gehört

Der Punkt Project-specific wirkt unscheinbar, hat aber großen Einfluss auf das Ergebnis. Hier landet alles, was ausschließlich für dein Projekt gilt und sich nicht erraten lässt.

Bei mir steht dort zum Beispiel „No hero images" – ohne diese Zeile schlägt praktisch jede KI zuverlässig ein bildschirmfüllendes Aufmacherbild vor, weil das seit Jahren gängige Praxis ist.

Kleine Ergänzungen in deinem MD-File, die sich lohnen

Aus meiner eigenen Erfahrung: Schon mit diesen paar Zeilen habe ich echt gute Ergebnisse erzielt. Die Kombination mit dem MCP-Server der Website Specification und den harten Regeln zusätzlich dazu lässt den Website-Durchschnitt hinter sich und macht daraus eine „bessere" Website.

Mittlerweile gibt es im Netz unzählige Accessibility-Skills und -Erweiterungen für KI-Werkzeuge – aber wer sich nicht hauptberuflich mit Barrierefreiheit beschäftigt, kann in diesem Dschungel unmöglich alle durchtesten.

Mein Tipp für alle, die sich von einer KI beim Umsetzen einer Website helfen lassen: Ergänze zumindest eine Regeldatei mit diesen paar Punkten – schon damit wird das Ergebnis um einiges besser.

Offen bleibt damit noch die Kontrolle: Was kann die KI an Barrierefreiheit und SEO selbst testen – und was bleibt Handarbeit? Dazu mehr im nächsten Artikel.

Quellen: W3C, Web Content Accessibility Guidelines 2.2 (Externer Link, öffnet sich in einem neuen Fenster) · The Website Specification (Externer Link, öffnet sich in einem neuen Fenster) · WebAIM Million (Externer Link, öffnet sich in einem neuen Fenster). Die verlinkten Quellen sind auf Englisch.