Barrierefreiheit in 2 Stunden – mit AI statt tagelanger Handarbeit

Barrierefreiheit ist wichtig – aber niemand macht es gerne

Wer im Web arbeitet, kennt das Thema. Barrierefreiheit ist kein Nice-to-have, sondern Pflicht. Seit dem European Accessibility Act müssen digitale Produkte zugänglich sein. Die Theorie ist klar. Die Praxis sieht anders aus: ARIA-Labels auf jedes Element, semantisches HTML prüfen, Fokus-Management, Kontrastmodi, Screenreader-Kompatibilität. Das ist wichtig – aber es ist auch die Art von Arbeit, die sich endlos anfühlt.

Für grossbyte.io wollte ich es trotzdem richtig machen. Und ich wollte testen, wie viel AI mir dabei abnehmen kann.

Der Ausgangspunkt

Die Website war funktional, sah gut aus – aber in Sachen Barrierefreiheit war sie nicht auf dem Stand, der sie sein sollte. Kein Skip-to-Content-Link, keine ARIA-Labels auf interaktiven Elementen, keine Unterstützung für System-Präferenzen wie prefers-contrast oder prefers-reduced-motion. Kurz: Es fehlte fast alles.

Was in unter 2 Stunden entstanden ist

Mit Claude Code CLI habe ich die komplette Barrierefreiheit der Seite umgesetzt. Nicht oberflächlich – sondern auf einem Level, das WCAG 2.1 Level AA in den umgesetzten Bereichen übertrifft, mit Unterstützung für System-Präferenzen die über den Standard hinausgehen. Hier ein Überblick:

Semantisches HTML & ARIA

• Jedes interaktive Element hat ein sinnvolles aria-label
• Navigation mit aria-current="page", aria-expanded, aria-controls
• Formularfelder mit aria-required, aria-invalid, aria-describedby
• Fehlermeldungen mit role="alert" für Screenreader
• Dekorative Elemente konsequent mit aria-hidden="true" markiert

Fokus-Management

• Skip-to-Content-Link mit focus:not-sr-only
• Sichtbare Fokus-Styles auf allen interaktiven Elementen (focus-visible:outline-gb-green)
• Focus-Trap im mobilen Menü - Tab bleibt im Drawer, Escape schließt ihn
• Fokus wird nach dem Schließen auf den Hamburger-Button zurückgesetzt

System-Präferenzen

• prefers-contrast: more - Kontrastwerte automatisch erhöht
• prefers-contrast: less - Neon-Farben abgeschwächt, sanftere Töne
• prefers-reduced-motion - alle Animationen und Transitions deaktiviert
• prefers-reduced-transparency - dekorative Elemente mit Transparenz ausgeblendet
• forced-colors: active - Layout funktioniert im Windows High Contrast Mode

Manueller Accessibility-Modus

Zusätzlich zu den automatischen System-Präferenzen gibt es einen Toggle-Button im Header. Ein Klick aktiviert den .a11y-mode - höherer Kontrast, keine Animationen, keine dekorativen Transparenzen. Der Zustand wird im localStorage gespeichert und bleibt über Seitenaufrufe hinweg erhalten.

Kontaktformular

• Jedes Feld mit Label-Verknüpfung und Autocomplete
• Validierungsfehler werden per aria-describedby dem Feld zugeordnet
• Status-Meldungen über aria-live="polite" für Screenreader
• Honeypot-Feld mit aria-hidden="true" und tabindex="-1"
• Ladeindikator mit aria-busy auf dem Submit-Button

iOS-Zoom-Fix

Ein Klassiker, den viele vergessen: Inputs mit einer Schriftgröße unter 16px lösen auf iOS einen automatischen Zoom aus. Das ist kein Bug, aber nervig. Gelöst mit einem gezielten Media Query – WCAG 1.4.4-konform, ohne den Pinch-Zoom zu deaktivieren.

Was mich überrascht hat

Die Qualität. Ich hatte erwartet, dass ich vieles nacharbeiten muss. Stattdessen hat Claude Code die ARIA-Patterns korrekt umgesetzt – Disclosure-Widgets, Live-Regions, Focus-Traps. Das sind keine trivialen Patterns, und die Implementierung war sauber.

Was mich auch überrascht hat: Die System-Präferenzen. prefers-contrast: less und prefers-reduced-transparency sind CSS-Features, die ich vorher nie aktiv implementiert habe. Claude Code hat sie nicht nur eingebaut, sondern auch sinnvolle Farbwerte dafür gewählt – die neongrünen Akzente werden bei prefers-contrast: less auf ein angenehmeres Grün abgeschwächt.

Zeitaufwand: Perspektive

Hätte ich das manuell gemacht – jedes Element einzeln prüfen, ARIA-Labels formulieren, Focus-Traps schreiben, CSS für fünf verschiedene Kontrastmodi anlegen, das Kontaktformular zugänglich machen, alles in zwei Sprachen – dann wäre das ein Projekt von mehreren Tagen gewesen.

Mit Claude Code waren es unter 2 Stunden. Inklusive Review.

Das ist kein Zufall. Barrierefreiheit ist genau die Art von Aufgabe, bei der AI den größten Hebel hat: Die Regeln sind klar definiert (WCAG), die Patterns sind bekannt, und es betrifft viele Dateien gleichzeitig. Es ist repetitiv, fehleranfällig bei manueller Arbeit – und genau das, was AI gut kann.

Der ehrliche Take

AI ersetzt nicht das Verständnis für Barrierefreiheit. Man muss wissen, was aria-live tut, warum ein Focus-Trap nötig ist, und ob die Kontrastwerte Sinn ergeben. Aber die Implementierung – das Schreiben der Labels, das Anpassen der CSS-Variablen, das Hinzufügen von role-Attributen über dutzende Dateien – das ist Arbeit, die keinen Spaß macht und die AI in einem Bruchteil der Zeit erledigt.

Der echte Gewinn ist nicht nur Geschwindigkeit. Es ist die Tatsache, dass Barrierefreiheit aufhört, eine lästige Pflichtübung zu sein, die man vor sich herschiebt. Wenn die Umsetzung nur noch 2 Stunden dauert statt 2 Tage, macht man es einfach.

Barrierefreiheit sollte kein Feature sein, das man "irgendwann noch macht". Mit AI gibt es keine Ausrede mehr.