Barrierefreiheit ist keine Zutat, die man am Ende darüberstreut. Sie entsteht aus der Struktur einer Komponente heraus. Wer semantisches HTML nutzt, Fokus sichtbar macht und die Tastatur ernst nimmt, baut Oberflächen, die für mehr Menschen funktionieren. Dieser Leitfaden zeigt die wichtigsten Bausteine mit React und Tailwind CSS.
- Barrierefreiheit fängt beim richtigen Element an. Ein button ist ein button, kein div mit onClick.
- Alles, was mit der Maus geht, muss mit der Tastatur gehen. Das ist der schnellste Test.
- Der Fokusring ist kein Schönheitsfehler. Wer ihn entfernt, nimmt Menschen die Orientierung.
- Kontrast ist messbar: 4,5 zu 1 für Fließtext, 3 zu 1 für große Schrift und Bedienelemente.
Mit semantischem HTML anfangen
Das richtige Element ist die halbe Miete. Ein button ist ein button, kein div mit onClick. Native Elemente bringen Fokusverhalten, Tastaturbedienung und die passende Rolle für Screenreader von sich aus mit. Das spart dir viel manuelle Nacharbeit.
Auch Struktur zählt. Überschriften in logischer Reihenfolge, nav für Navigation, main für den Hauptinhalt und Listen für Aufzählungen geben assistiven Technologien eine Landkarte deiner Seite. In React kostet das nichts extra, du wählst einfach das treffende Tag.
- Kein Fokus, die Tastatur kommt nicht hin.
- Enter und Leertaste tun nichts.
- Der Screenreader meldet: Gruppierung.
- Rolle, Zustand und Tastatur baust du von Hand nach.
- Fokus, Tab-Reihenfolge und Ring sind da.
- Enter und Leertaste lösen aus.
- Der Screenreader meldet: Schaltfläche.
- Du schreibst nur noch, was passieren soll.
Fokus sichtbar machen
Wer per Tastatur navigiert, muss sehen, wo er sich gerade befindet. Entferne den Fokusring deshalb niemals ersatzlos. In Tailwind steuerst du ihn gezielt über focus-visible, sodass er bei Tastaturnutzung erscheint, bei Mausklick aber nicht stört.
Eine Klasse wie focus-visible mit ring-2 und einer klaren Ringfarbe reicht oft schon. Achte auf genug Kontrast zum Hintergrund, damit der Zustand auch auf hellen Flächen deutlich bleibt. Ein gut sichtbarer Fokus ist ein Zeichen von Sorgfalt, kein Schönheitsfehler.
<button className="rounded-lg bg-neutral-900 px-5 py-3 text-white focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-neutral-900 focus-visible:ring-offset-2" Termin buchen</button>
ARIA nur gezielt einsetzen
ARIA-Attribute ergänzen Bedeutung, die sich aus dem HTML allein nicht ergibt. Die erste Regel lautet aber: kein ARIA ist besser als falsches ARIA. Wo ein natives Element ausreicht, brauchst du keine zusätzliche Rolle.
Sinnvoll wird ARIA bei eigenen Widgets. Ein Umschalter bekommt aria-pressed, ein aufklappbares Menü aria-expanded, ein rein dekoratives Icon aria-hidden. Für Buttons ohne sichtbaren Text sorgt aria-label für eine verständliche Beschriftung. Setze diese Attribute bewusst und halte sie mit dem tatsächlichen Zustand deiner Komponente synchron.
<button aria-pressed={aktiv} className={aktiv ? "bg-neutral-900 text-white" : "bg-neutral-100"} Wöchentlich</button>
Tastaturbedienung mitdenken
Alles, was mit der Maus geht, sollte auch mit der Tastatur gehen. Native Buttons und Links reagieren bereits auf Enter und Leertaste. Baust du interaktive Elemente selbst, musst du diese Tasten und eine sinnvolle Tab-Reihenfolge selbst herstellen.
Bei Overlays wie Dialogen kommt der Fokus dazu. Beim Öffnen wandert er in den Dialog, beim Schließen zurück zum auslösenden Element, und solange er offen ist, bleibt er im Dialog gefangen. Diese Fokusführung entscheidet darüber, ob eine Komponente wirklich bedienbar ist.
Kontrast und Farben prüfen
Text muss sich klar vom Hintergrund abheben. Als Richtwert gelten mindestens 4,5 zu 1 für normalen Text und 3 zu 1 für große Schrift. Sehr helle Grautöne auf Weiß sehen elegant aus, fallen bei diesem Test aber schnell durch.
Farbe darf außerdem nie die einzige Information sein. Ein Fehlerzustand braucht neben Rot auch ein Wort oder ein Icon, ein aktiver Link mehr als nur eine andere Farbe. So bleibt deine Oberfläche auch für Menschen mit eingeschränktem Farbsehen verständlich.
Bilder und Bewegung berücksichtigen
Jedes inhaltstragende Bild braucht eine kurze, treffende Alternative im alt-Attribut. Rein dekorative Bilder bekommen ein leeres alt, damit Screenreader sie überspringen und den Lesefluss nicht mit Deko unterbrechen.
Bewegung sollte sich abschalten lassen. Über prefers-reduced-motion und den Hook useReducedMotion bietest du eine ruhige Variante an. Zusammen mit gutem Kontrast und klarer Struktur wird deine Komponente so für deutlich mehr Menschen nutzbar.
Der Test in fünf Minuten
Du brauchst kein Prüfwerkzeug, um die groben Fehler zu finden. Diese vier Handgriffe decken die meisten davon auf.
- Maus weglegen. Mit Tab durch die Seite gehen. Kommst du überall hin, und siehst du immer, wo du bist?
- Auf 200 Prozent zoomen. Bricht das Layout, überlappt Text, verschwindet etwas? Zoom ist kein Sonderfall, viele Menschen surfen dauerhaft so.
- Farben prüfen. Graue Schrift auf hellem Grund ist der Klassiker. 4,5 zu 1 für Fließtext, 3 zu 1 für große Schrift.
- Bilder abschalten. Was bleibt, ist das, was ein Screenreader hört. Dekoration braucht ein leeres alt, Inhalt eine kurze Beschreibung.
Barrierefrei heißt nicht schmuckloser. Es heißt, dass die Gestaltung auch trägt, wenn jemand anders bedient.
Wo Tailwind hilft und wo nicht
Tailwind macht eine Seite nicht barrierefrei, aber es macht die richtigen Dinge bequem. focus-visible ist eine eigene Variante, sr-only steckt als Utility drin, und über Tokens hältst du Kontraste an einer Stelle.
Was Tailwind nicht abnimmt: das richtige Element wählen, Beschriftungen setzen, Zustände ankündigen. Ein div mit hover-Klasse sieht aus wie ein Button und ist trotzdem keiner.
