Tabs barrierefrei umsetzen

Tabs zeigen mehrere Inhaltsbereiche auf demselben Platz und lassen zwischen ihnen umschalten – einer ist sichtbar, die anderen warten im Hintergrund. Anders als die meisten Komponenten auf dieser Seite sind Tabs einer der wenigen Fälle, in denen ARIA wirklich nötig ist: HTML hat kein eingebautes Tabs-Element, also gibt es nichts Natives zu bevorzugen. Genau deshalb lohnt es sich, das Muster sauber nach dem ARIA Authoring Practices Guide umzusetzen.

Das Muster besteht aus drei Bausteinen mit eigenen Rollen: einer Tab-Liste, den einzelnen Tabs und den zugehörigen Tab-Panels.

Das Markup

<div class="tabs">
  <div role="tablist" aria-label="Kontoeinstellungen">
    <button role="tab" id="tab-profil" aria-selected="true" aria-controls="panel-profil">
      Profil
    </button>
    <button role="tab" id="tab-sicherheit" aria-selected="false" aria-controls="panel-sicherheit" tabindex="-1">
      Sicherheit
    </button>
  </div>

  <div role="tabpanel" id="panel-profil" aria-labelledby="tab-profil" tabindex="0">
    <h3>Profil</h3>
    …
  </div>
  <div role="tabpanel" id="panel-sicherheit" aria-labelledby="tab-sicherheit" tabindex="0" hidden>
    <h3>Sicherheit</h3>
    …
  </div>
</div>

Die Verknüpfungen sind das Herz des Musters: Jeder Tab zeigt per aria-controls auf sein Panel, jedes Panel per aria-labelledby zurück auf seinen Tab. Der aktive Tab trägt aria-selected="true", sein Panel ist sichtbar; die übrigen Panels sind hidden. Wie diese Rollen, Zustände und Eigenschaften generell zusammenspielen, vertieft Rollen, States & Properties.

Das Tastaturmodell – hier wird es speziell

Tabs verhalten sich bewusst anders als normale Buttons, und dieses Verhalten ist Teil des Musters. Der Schlüssel heißt Roving Tabindex: Nur der aktive Tab ist mit tabindex="0" in der Tab-Reihenfolge, alle anderen haben tabindex="-1". So springt die Tab-Taste nicht durch jeden einzelnen Tab, sondern aus der Tab-Liste heraus ins Panel.

• Pfeiltasten links/rechts wechseln zwischen den Tabs.
• Home / Ende springen zum ersten bzw. letzten Tab.
• Tab verlässt die Tab-Liste und führt zum Inhalt des aktiven Panels.

Beim Wechsel verschiebt das Skript also nicht nur aria-selected, sondern auch das tabindex und den Fokus. Dieses Umsetzen von Hand ist der eigentliche Aufwand bei Tabs – und der Grund, warum ich sie nur dort einsetze, wo das Muster wirklich passt.

Automatisch oder manuell aktivieren?

Es gibt zwei Varianten, wie ein Tab beim Tastaturwechsel aktiv wird:

• Automatisch: Schon das Anpfeilen zeigt sofort das zugehörige Panel. Gut, wenn die Panels leichtgewichtig sind.
• Manuell: Die Pfeiltasten bewegen nur den Fokus; erst Enter oder Leertaste schaltet das Panel um. Besser, wenn ein Panelwechsel teuer ist (Inhalte nachladen), weil sonst beim Durchblättern unnötig viel passiert.

Ich nehme im Zweifel die manuelle Variante – sie fühlt sich vorhersehbarer an und löst keine ungewollten Ladevorgänge aus.

Tabs sind nicht immer die Antwort

Tabs eignen sich für gleichrangige Inhalte, von denen man jeweils einen sehen will – Reiter im klassischen Sinn. Für ausklappbare Detailbereiche sind Akkordeons das einfachere, robustere Muster, ganz ohne Pfeiltasten-Mechanik. Auf schmalen Bildschirmen werden Tabs häufig sogar in Akkordeons umgewandelt. Bevor ich die ARIA-Maschinerie aufziehe, frage ich mich deshalb ehrlich, ob es nicht ein Akkordeon auch täte.

Häufige Fehler

• Kein Roving Tabindex. Wenn alle Tabs tabindex="0" haben, tabbt man durch jeden einzelnen, statt mit Pfeiltasten zu wechseln – das Muster ist dann kaputt.
• <div> als Tab. Die Tabs gehören auf <button>, sonst fehlen Fokus und Aktivierung.
• Fehlende aria-controls/aria-labelledby. Ohne die Verknüpfung ist der Zusammenhang von Tab und Panel für Screenreader nicht erkennbar.
• Inaktive Panels nicht hidden. Sie bleiben sonst im Lesefluss und per Tab erreichbar.
• role="tab" ohne das passende Tastaturmodell. Rollen ohne Verhalten versprechen etwas, das die Komponente nicht hält – das ist schlechter als gar kein ARIA.

Häufige Fragen

Warum ist hier ARIA nötig, sonst aber nicht?

Weil HTML kein Tabs-Element kennt. Es gibt nichts Natives, das die Rollen und das Tastaturverhalten mitbrächte – also muss ARIA sie liefern. Das ist genau der Ausnahmefall, den die erste Regel von ARIA meint.

Können die Pfeiltasten auch oben/unten sein?

Bei senkrecht angeordneten Tabs ja – dann nutzt man hoch/runter und ergänzt aria-orientation="vertical" an der Tab-Liste. Bei waagerechten Tabs sind es links/rechts.

Soll ich Tabs mit einer Fertig-Komponente bauen?

Wenn eine erprobte, barrierefreie Komponente verfügbar ist, spricht viel dafür – das Tastaturmodell korrekt selbst zu schreiben, ist fehleranfällig. Wichtig ist nur, dass die Komponente das hier beschriebene Verhalten tatsächlich umsetzt.

Fazit

Tabs sind das Muster, bei dem ARIA seine Berechtigung hat: role="tablist", role="tab" und role="tabpanel", verbunden über aria-controls und aria-labelledby, mit aria-selected für den aktiven Tab – und einem Roving Tabindex samt Pfeiltasten-Navigation. Das ist mehr Aufwand als bei den meisten Komponenten, deshalb die Gegenfrage zuerst: Tut es vielleicht ein Akkordeon?