Accessibility-Audit mit KI: Barrierefreiheit prüfen lassen

Ein Accessibility-Audit mit KI heißt: Ein Agent prüft deinen Code gegen WCAG 2.2 — fehlende Alt-Texte, schwache Kontraste, fehlende Formularlabels, kaputte Überschriftenhierarchie — und schlägt konkrete Korrekturen vor. Das deckt die maschinell prüfbaren Kriterien ab. Tastaturbedienung und Screenreader-Test bleiben Handarbeit.

Was prüft ein Accessibility-Audit eigentlich?

Barrierefreiheit klingt nach einem einzelnen Häkchen, ist aber eine ganze Kriterienliste. Der übliche Maßstab ist WCAG 2.2, die Web Content Accessibility Guidelines, gegliedert nach vier Prinzipien, die meist als POUR abgekürzt werden:

• Perceivable (wahrnehmbar): Inhalte müssen auch ohne Sehen oder Hören zugänglich sein: Alt-Texte für Bilder, Untertitel für Videos, ausreichender Farbkontrast.
• Operable (bedienbar): Alles muss ohne Maus funktionieren. Jede Schaltfläche per Tastatur erreichbar, der Fokus sichtbar, Klickziele groß genug.
• Understandable (verständlich): Vorhersehbares Verhalten, klare Formularfehler, verständliche Sprache.
• Robust: Sauberes, semantisches HTML, das Screenreader und Hilfstechnologien korrekt interpretieren.

Version 2.2 kam mit zusätzlichen Kriterien, unter anderem zu Zielgrößen, Fokus-Sichtbarkeit und barrierefreier Authentifizierung, also der Frage, ob man sich anmelden kann, ohne etwa ein Bilderrätsel lösen zu müssen.

Was kann ein KI-Agent davon übernehmen?

Der maschinell prüfbare Anteil ist größer, als viele denken. Alles ist er nicht.

Zuverlässig automatisierbar: Fehlende oder leere Alt-Attribute. Formularfelder ohne zugehöriges Label. Farbkontraste unter dem Schwellwert. Übersprungene Überschriftenebenen. Interaktive Elemente, die per Tastatur nicht erreichbar sind. Fehlende Sprachauszeichnung der Seite. Bedienelemente ohne zugänglichen Namen.

Nicht automatisierbar: Ob ein Alt-Text das Bild sinnvoll beschreibt. Ob die Reihenfolge beim Durchtabben logisch ist. Ob eine Fehlermeldung verständlich formuliert ist. Ob eine Animation jemanden mit Reizempfindlichkeit stört. Ob ein Screenreader die Seite tatsächlich brauchbar vorliest.

Der Unterschied ist wichtig, weil ein bestandener automatischer Test leicht als Freibrief missverstanden wird. Er heißt: keine offensichtlichen Fehler gefunden. Nicht: barrierefrei.

Wie richtest du das ein?

Der praktische Weg braucht zwei Bausteine: Fachwissen für den Agent und ein Messwerkzeug.

Das Fachwissen liefert ein Skill. Im Verzeichnis findest du dafür Accessibility Audit (WCAG 2.2): eine kompakte WCAG-Referenz nach den POUR-Prinzipien, mit konkreten HTML-, CSS- und JavaScript-Beispielen für typische Probleme — jeweils als Vorher-Nachher-Vergleich. Der Skill besteht ausschließlich aus Markdown, ohne ausführbaren Code und ohne Netzwerkzugriffe. Er bringt zusätzlich eine Testing-Checkliste mit Befehlen für Lighthouse und axe-core mit, den beiden verbreiteten Prüfwerkzeugen, sowie Hinweise für die manuelle Prüfung.

Das ist die sinnvolle Arbeitsteilung: Das Werkzeug misst, der Skill sagt dem Agent, was die Messwerte bedeuten und wie man sie behebt. Ein Agent ohne diese Referenz kennt WCAG nur ungefähr und produziert Korrekturen, die plausibel aussehen und den Kern verfehlen.

Wenn Skills für dich neu sind, führt Skills in Claude Code installieren durch die Einrichtung. Weitere Einträge aus dem Entwicklungsumfeld sammelt die Kategorie Entwicklung.

Wie läuft die Prüfung ab?

Ein Ablauf, der sich bewährt hat:

1. Automatisch messen. Lighthouse oder axe-core über die Seite laufen lassen. Das liefert die harten Verstöße in Minuten.
2. Befunde einordnen lassen. Der Agent nimmt die Ausgabe und übersetzt sie in konkrete Code-Änderungen an den betroffenen Stellen.
3. Fixes einzeln übernehmen. Besonders bei Alt-Texten: Der Agent kann Platzhalter erzeugen, die formal korrekt und inhaltlich nutzlos sind. „Bild" als Alt-Text erfüllt die Prüfung und hilft niemandem.
4. Selbst durchtabben. Leg die Maus weg und bedien die Seite nur mit Tabulator und Enter. Kommst du überall hin? Siehst du immer, wo du bist? Diese fünf Minuten finden Probleme, die kein Werkzeug meldet.
5. Mit einem Screenreader hören. Auf dem Mac ist VoiceOver eingebaut, unter Windows gibt es NVDA kostenlos. Auch nur die Startseite anzuhören verändert den Blick dauerhaft.

Die Schritte 4 und 5 werden am häufigsten übersprungen. Sie machen den Unterschied zwischen „besteht den Test" und „ist benutzbar".

Was hat das mit SEO zu tun?

Mehr, als es zunächst scheint, aber weniger, als manche versprechen.

Es gibt einen echten gemeinsamen Kern: Alt-Texte, eine saubere Überschriftenhierarchie, sprechende Linktexte statt „hier klicken", semantisches HTML. Diese Dinge helfen Screenreadern und Suchmaschinen aus demselben Grund — beide lesen Struktur, nicht Optik. Wer eines davon ordentlich macht, verbessert das andere mit.

Der Rest überschneidet sich nicht. Fokus-Sichtbarkeit, Zielgrößen oder Screenreader-Ansagen beeinflussen kein Ranking. Barrierefreiheit als SEO-Maßnahme zu verkaufen, führt deshalb in die Irre: Man macht dann die sichtbaren Punkte und lässt die eigentlichen liegen.

Wenn dein Ziel Suchsichtbarkeit ist, ist SEO-Audit mit KI der passendere Einstieg. Barrierefreiheit machst du, weil Menschen deine Seite sonst nicht bedienen können — der SEO-Effekt ist ein Nebenprodukt, kein Grund.

Wo fängst du an?

Bei der Tastatur. Öffne deine wichtigste Seite und versuch, sie ohne Maus vollständig zu bedienen: Navigation, Formular, Absenden.

Wenn das funktioniert, bist du weiter als die meisten. Wenn nicht, hast du deinen ersten Befund, und zwar einen echten. Danach lohnt der automatische Durchlauf mit dem Skill, um die Fehler zu finden, die man beim Draufschauen nicht sieht. Weitere Beispiele, was Skills in solchen wiederkehrenden Prüfaufgaben leisten, zeigt Claude Skills: Beispiele.