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.
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.
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.
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.
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.