Barrierefreiheit in React: Tastatur und Fokusfluss als Produktverhalten behandeln

Barrierefreiheit wird oft wie eine Checkliste behandelt, die erst am Ende der Entwicklung kommt: Kontrast anpassen, einige aria-label-Attribute ergänzen und eine Browser-Erweiterung starten. Kann eine Person aber ein Formular nicht mit der Tastatur abschließen, verliert in einem Dialog den Fokus oder nimmt eine Fehlermeldung nicht wahr, ist das Problem nicht ein fehlendes Label. Es ist ein Bruch im Produktverhalten.

In React-Oberflächen wechseln Zustände schnell: Ein Modal öffnet sich, eine Liste wird aktualisiert, ein Formularfehler erscheint, eine Route ändert sich oder ein Menü schließt. Nutzer mit Maus bemerken viele dieser Übergänge kaum. Für Personen mit Tastatur oder Screen Reader sind Fokus, Überschriften und Ansagen die Karte der Oberfläche. Barrierefreies Design hält diese Karte in jedem Zustand konsistent.

Zuerst eingebautes HTML-Verhalten verwenden

Der beste erste Schritt ist meist nicht eine eigene Komponente, sondern die Bedeutung von HTML zu erhalten. <button> für Aktionen, <a> für Navigation, <fieldset> und <legend> für zusammengehörige Felder sowie <table> für tabellarische Daten bringen Tastaturverhalten, Fokussierbarkeit und Screen-Reader-Information ohne Zusatzarbeit.

Einen klickbaren div oder span zu bauen, ist mit onClick nicht abgeschlossen. Enter- und Space-Taste, deaktivierter Zustand, Fokusindikator, Rolle und zugänglicher Name müssen neu umgesetzt werden. Einen echten Button zu verwenden, bedeutet weniger Code und weniger Fehler.

Die Überschriftenhierarchie sollte von visueller Größe getrennt sein. Wenn der Zweck einer Seite durch ein h1 und Unterabschnitte in logischer Reihenfolge mit Überschriften ausgedrückt werden, kann eine Person mit Screen Reader schnell durch die Seite navigieren. Nur für das Design gewählter fetter Text liefert diese Struktur nicht.

Tastaturfluss als Nutzerreise testen

Eine Seite nur mit Tab und Shift+Tab zu durchlaufen, deckt Barrierefehler schnell auf. Ist der Fokus sichtbar? Entspricht die Reihenfolge dem visuellen und funktionalen Ablauf? Bleibt Tastaturfokus an unsichtbaren, aber klickbaren Elementen hängen? Welche Tasten funktionieren, wenn ein Menü geöffnet wird? Diese Fragen zeigen, ob eine Komponente wirklich nutzbar ist.

Die Fokusreihenfolge folgt der DOM-Reihenfolge. Ein Element mit CSS auf dem Bildschirm zu verschieben und im DOM an anderer Stelle zu lassen, kann die Tastaturreise verwirrend machen. Bauen Sie eine sinnvolle DOM-Reihenfolge, statt sie mit positiven tabindex-Werten zu reparieren. Auch tabindex="0" sollte einem tatsächlich interaktiven Element vorbehalten bleiben, das nicht von Natur aus fokussierbar ist.

Entfernen Sie Fokusindikatoren nicht für das Design. Passt der Browserstandard nicht zur visuellen Sprache, entwerfen Sie eine deutlichere Alternative; erhalten Sie aber die Möglichkeit, das fokussierte Element klar zu sehen.

Fokus in Modals und Ebenen steuern

Wenn ein Modal geöffnet wird, sollte Fokus zu einem sinnvollen Element wechseln, das seinen Beginn vermittelt. Modal-Überschrift oder erste nutzbare Kontrolle sind meist passend. Solange es offen ist, darf Tab nicht zur Seite dahinter entkommen; beim Schließen sollte Fokus zum Auslöser zurückkehren.

Dieses Verhalten ist nicht unabhängig von React-State-Änderungen. Existiert der Auslöser beim Schließen noch? Ist er deaktiviert? Schließt die Person wegen eines Formularfehlers? Diese Details brauchen Design. Mit einer fertigen, auf Barrierefreiheit getesteten Dialogkomponente zu beginnen, ist meist sicherer als eine Fokusfalle selbst zu bauen.

Kleinere Ebenen wie Menüs, Popover und Autocomplete tragen dieselbe Frage: Wie kommt Tastatureingabe nach dem Öffnen hinein, wie bewegt sie sich zwischen Optionen, was bewirkt Escape und wohin kehrt Fokus zurück? Nicht jede Ebene ist modal; Hintergrundinteraktion unnötig zu sperren, kann ebenfalls schaden.

Sinnvolle Zustandsänderungen ankündigen

Ein kleiner Toast am unteren Bildschirmrand nach dem Absenden eines Formulars kann für Screen-Reader-Nutzer unzureichendes Feedback sein. Erfolg, Fehler oder Ladeergebnis sollten über eine passende Live Region angekündigt werden, ohne einen dauernden Strom unnötiger Meldungen zu erzeugen.

Bei Formularvalidierung darf ein Fehler nicht nur ein roter Rand sein. Feldlabel, Fehlertext und Erklärung sollten programmatisch verbunden sein. Schlägt das Senden fehl, wandert Fokus zum ersten ungültigen Feld oder zu einer Fehlerzusammenfassung. Können Links darin zu ihren Feldern springen, wird Erholung in langen Formularen leichter.

Bleibt alter Inhalt während asynchronen Ladens sichtbar, unterbrechen Sie Personen nicht mit unnötigen Ansagen. Priorisieren Sie Zustände, die Inhalt wirklich ändern, Fehler erzeugen oder Abschluss melden. Statt nur „fehlgeschlagen“ zu sagen, sollte eine Ansage erklären, was fehlgeschlagen ist und was der nächste sichere Schritt ist.

Bei eigenen Controls ein Tastaturmodell umsetzen

Tabs, Comboboxes, Tree Views und Drag-and-Drop-Bereiche sind komplexer als Standard-HTML-Controls. Nur eine ARIA-Rolle hinzuzufügen, reicht nicht; die für diese Rolle erwartete Tastaturinteraktion muss umgesetzt werden. Pfeiltasten, Home/End, Enter, Space und Escape sollten für den Komponententyp konsistent funktionieren.

Ist die Komplexität nicht nötig, ist eine einfachere Komponente zugänglicher. Ein korrekt beschriftetes <select> kann für einen Filter statt einer vollständig eigenen Combobox genügen. Ist ein eigenes Control erforderlich, verringern eine zugängliche Komponentenbibliothek und gemeinsame Projektregeln wiederholte Fehler.

Kontext bei Route-Wechseln erhalten

In Single-Page-Anwendungen kann sichtbarer Inhalt wechseln, während Browserfokus an seiner alten Position bleibt. Fokus gezielt zur neuen Seitenüberschrift oder zum Hauptinhalt zu bewegen, zeigt der Person, dass Navigation abgeschlossen ist. Dies bei jeder kleinen Filteränderung zu tun, kann stören; die Beschränkung auf echte Übergänge auf Seitenebene ist ausgewogener.

Ein Skip-to-Content-Link gibt Tastaturnutzern außerdem einen schnellen Weg an wiederholter Navigation vorbei. Er sollte zu den ersten fokussierbaren Elementen gehören und klar zum Hauptinhalt führen.

Tests von Automation zu menschlichem Verhalten erweitern

Automatische Barrierefreiheitschecks finden viele Fehler früh, etwa fehlende zugängliche Namen oder ungültige ARIA-Nutzung. Sie beweisen aber allein nicht, dass Fokusreihenfolge sinnvoll, ein Modal nutzbar oder eine Fehlermeldung verständlich ist.

Erstellen Sie für jeden kritischen Ablauf ein kurzes manuelles Szenario: mit Tastatur anmelden, Filter ändern, ein Formular mit Fehlern absenden, Modal öffnen und schließen, Route wechseln. Diese Szenarien regelmäßig mit Screen Reader und verschiedenen Geräten zu probieren, macht Probleme zwischen Komponenten sichtbar. Tests sollten, wo möglich, echte Nutzeraktionen ausführen: klicken, tippen, Tab und Escape.

Barrierefreiheit ist keine Zusatzfunktion für eine getrennte Gruppe. Semantische Struktur, vorhersehbarer Fokus, klares Feedback und Tastaturunterstützung bedeuten für alle weniger Fehler, bessere Orientierung und eine robustere React-Oberfläche.