Akkordeons und Tabs barrierefrei entwickeln: ARIA-Patterns

Akkordeons und Tabs gehören zu den am häufigsten falsch umgesetzten Komponenten auf deutschen Webseiten. Optisch wirken sie oft tadellos – erst mit Tastatur oder Screenreader zeigt sich, ob Nutzer die Inhalte tatsächlich erreichen können.

Die WAI-ARIA Authoring Practices beschreiben für beide Komponenten ein festes Muster aus Rollen, Zuständen und Tastaturinteraktionen. Wer sich daran hält, vermeidet die typischen Fehler bei FAQ-Bereichen, Produktbeschreibungen und mehrstufigen Formularen.

Warum Akkordeons und Tabs besondere Sorgfalt brauchen

Beide Komponenten blenden Inhalte optisch aus oder ein, ohne die Seite neu zu laden. Für sehende Mausnutzer ist das bequem, für Screenreader- und Tastaturnutzer entsteht dabei ein unsichtbarer Zustand: Ist ein Panel geöffnet oder geschlossen? Gehört ein Button zu einem Tab oder zu einem eigenständigen Inhalt? Ohne semantische Auszeichnung bleibt das reine Spekulation.

Genau deshalb legt die ARIA-Spezifikation für Akkordeons und Tabs feste Patterns fest. Sie definieren Rollen, Attribute und Tastenkombinationen verbindlich, damit Hilfstechnologie den Zustand korrekt vorliest und Nutzer die Bedienung nicht raten müssen.

Wer diese Patterns ignoriert, riskiert nicht nur Abstriche beim Barrierefreiheits-Scan, sondern verliert auch sehende Tastaturnutzer, die aus motorischen Gründen keine Maus verwenden.

Das Akkordeon-Pattern im Detail

Ein Akkordeon besteht aus mehreren Abschnitten, die jeweils aus einer Überschrift mit Button und einem zugehörigen Inhaltsbereich bestehen. In der Überschrift liegt ein <button>-Element, das die Rolle „button" von Haus aus mitbringt.

Der Button braucht aria-expanded="true" oder aria-expanded="false", je nach Zustand, sowie aria-controls mit der ID des zugehörigen Panels. Das Panel selbst bekommt eine eindeutige ID und wird bei geschlossenem Zustand mit hidden ausgeblendet oder vollständig aus dem DOM entfernt.

Wichtig: Der sichtbare Text der Überschrift muss weiterhin als echter Button fungieren, nicht als <div> mit Klick-Handler. Nur so bekommt die Komponente automatisch Tastaturfokus und die Enter-/Leertaste-Bedienung, ohne dass Entwickler das selbst nachbauen müssen.

Das Tabs-Pattern: tablist, tab und tabpanel

Tabs bestehen aus drei Rollen: Der äußere Container trägt role="tablist", jeder Reiter role="tab" und jeder zugehörige Inhalt role="tabpanel". Der aktive Tab erhält aria-selected="true", alle anderen aria-selected="false".

Jedes Tabpanel referenziert seinen Tab über aria-labelledby, jeder Tab referenziert sein Panel über aria-controls. Nur der aktive Tab liegt in der normalen Tab-Reihenfolge (tabindex="0"), die übrigen sind über tabindex="-1" aus der Reihenfolge genommen und werden per Pfeiltaste erreicht.

Diese Trennung zwischen „einmal mit Tab erreichbar" und „innerhalb der Gruppe mit Pfeiltasten navigierbar" ist der Kern des Patterns – und genau der Punkt, an dem die meisten Framework-Komponenten scheitern.

Tastaturbedienung: Welche Taste was auslösen muss

Bei Akkordeons genügen Tab zum Erreichen des Buttons sowie Enter oder Leertaste zum Öffnen und Schließen. Manche Nutzer erwarten zusätzlich, mit Pfeil-hoch/-runter zwischen mehreren Akkordeon-Headern springen zu können, was die Authoring Practices als optionale Erweiterung vorsehen.

Bei Tabs gilt: Pfeil-links/-rechts, bei vertikaler Anordnung Pfeil-hoch/-runter, wechselt zwischen den Reitern, Pos1 springt zum ersten, Ende zum letzten Tab. Bei automatischer Aktivierung ist Enter oder Leertaste gar nicht nötig – der Wechsel per Pfeiltaste aktiviert das Panel sofort.

Frameworks, die nur Mausklicks unterstützen oder Pfeiltasten komplett ignorieren, produzieren eine Komponente, die für Tastaturnutzer schlicht nicht bedienbar ist – unabhängig davon, wie korrekt die ARIA-Attribute im Markup stehen.

Typische Implementierungsfehler in JavaScript-Frameworks

Ein häufiger Fehler: role="tab" wird auf ein <div> statt auf einen Button gesetzt, ohne tabindex und Tastatur-Handler nachzurüsten. Die Komponente sieht für Screenreader korrekt aus, ist aber mit der Tastatur nicht erreichbar.

Ein zweiter Fehler betrifft aria-expanded: Viele Komponentenbibliotheken setzen das Attribut nur beim ersten Rendern, aktualisieren es aber nicht, wenn sich der Zustand durch Klick ändert – der Screenreader meldet dann dauerhaft „eingeklappt", selbst wenn der Inhalt sichtbar ist.

Drittens werden Panels häufig nur per CSS (display:none) versteckt, ohne hidden oder aria-hidden zu setzen. Manche Screenreader lesen den ausgeblendeten Text dann trotzdem vor, was zu verwirrenden Doppelinhalten führt.

Wo die Patterns im Alltag wirklich zählen

FAQ-Bereiche sind der klassische Einsatzort für Akkordeons – gerade weil sie oft die einzige Möglichkeit sind, häufige Kundenfragen kompakt darzustellen. Ein defektes Akkordeon-Pattern bedeutet hier: Screenreader-Nutzer finden Antworten nicht, die sichtbar direkt unter der Frage stehen.

Auf Produktseiten trennen Tabs häufig Beschreibung, technische Daten und Bewertungen. Sind diese Tabs nicht korrekt ausgezeichnet, bleiben ganze Produktinformationen für Hilfstechnologie unauffindbar, was sich direkt auf Kaufentscheidungen auswirken kann.

Auch mehrstufige Formulare mit Akkordeon-Abschnitten pro Kategorie sind verbreitet. Hier zählt zusätzlich, dass der Fokus nach dem Öffnen eines Panels nicht ungewollt springt und Nutzer den Überblick über bereits ausgefüllte Abschnitte behalten.

Responsive Verhalten: Wenn Tabs auf dem Smartphone zu Akkordeons werden

Viele responsive Layouts wandeln Tabs auf schmalen Bildschirmen in ein Akkordeon um, weil nebeneinanderliegende Reiter auf einem Smartphone kaum Platz finden. Diese Umwandlung darf nicht rein optisch erfolgen, denn die zugrunde liegenden ARIA-Rollen gehören ebenso zum Pattern wie das Layout selbst.

Bleiben role="tablist" und role="tab" bestehen, obwohl sich die Komponente auf dem Smartphone wie ein Akkordeon verhält, meldet der Screenreader weiterhin eine Tab-Gruppe mit Auswahlzustand, während Nutzer tatsächlich einzelne Panels auf- und zuklappen. Die Ansage passt dann nicht mehr zur tatsächlichen Bedienung, was gerade beim schnellen Wechsel zwischen Geräten für Verwirrung sorgt.

Sauberer ist es, die Rollen abhängig vom Breakpoint per JavaScript umzuschreiben: Oberhalb einer bestimmten Bildschirmbreite gilt das Tabs-Pattern mit tablist, tab und tabpanel, unterhalb wechselt die Komponente vollständig auf einzelne Buttons mit aria-expanded, inklusive angepasster Tastaturbedienung. Wird nur das CSS getauscht und das Markup bleibt gleich, stimmt zwar die Optik, die zugrunde liegende Semantik bleibt aber falsch.

In der Praxis lohnt sich ein einfacher Test: Verkleinere das Browserfenster testweise auf Smartphone-Breite und prüfe mit aktiviertem Screenreader, ob die Ansage weiterhin von „Tab" spricht oder korrekt auf „Schaltfläche, eingeklappt" wechselt. Bleibt die alte Ansage bestehen, ist die Umstellung auf das responsive Verhalten nur halb erledigt.

Screenreader-Test: So prüfst du beide Komponenten

Teste Akkordeons, indem du ausschließlich mit Tab und Enter navigierst: Der Fokus muss sichtbar auf dem Header-Button landen, und der Screenreader muss „eingeklappt" oder „ausgeklappt" ansagen, sobald sich der Zustand ändert.

Bei Tabs prüfst du mit Pfeil-links/-rechts, ob der Fokus tatsächlich zwischen den Reitern wandert und ob NVDA oder VoiceOver den aktiven Tab sowie dessen Position, etwa „Tab 2 von 4", ansagt.

Ergänzend hilft ein automatisierter Scan, um fehlende aria-controls-Referenzen oder doppelte IDs aufzudecken, die sich bei manueller Prüfung leicht übersehen lassen – ein kostenloser Scan zeigt solche Fehler direkt im Report.

Hinweis: Dieser Beitrag bietet allgemeine technische Orientierung und ersetzt keine individuelle Rechtsberatung zur Umsetzung des BFSG.

Häufig gestellte Fragen