Das inert-Attribut und Fokus Management in barrierefreien Karussellen

Wer Websites barrierefrei baut, denkt zuerst an Screenreader. Dabei ist die häufigste Accessibility-Anforderung eine deutlich nüchternere: vollständige Tastaturbedienbarkeit. WCAG 2.1.1, Level A, das bedeutet die grundlegendste Konformitätsstufe der Barrierefreiheit, fordert, dass jede Funktion einer Website ohne Maus erreichbar ist.

Beim Karussell scheitert das in der Praxis fast immer. Nicht weil es technisch schwierig wäre, sondern weil Fokus Management systematisch unterschätzt wird, und weil Off-Screen-Slides, wenn sie falsch behandelt werden, die Tab-Reihenfolge still und leise zerstören.

Den Fokus behalten

Die wichtigste Regel im Karussell-Fokus-Management lässt sich in einem Satz zusammenfassen: Der Fokus darf sich bei Navigation nicht verschieben.

Wenn eine Nutzerin den „Nächste Slide"-Button drückt, muss der Fokus auf genau diesem Button bleiben. Nicht auf der neuen Slide. Nicht auf dem ersten Link im neuen Inhalt. Auf dem Button. Denn nur so kann sie denselben Button erneut drücken, ohne erst wieder dorthin navigieren zu müssen.

Das klingt trivial. In realen Implementierungen passiert es trotzdem ständig, dass JavaScript nach einem Slide-Wechsel focus() auf ein Slide-Element setzt, aus gut gemeintem Reflex, den Nutzer „näher am Inhalt" zu platzieren. Das Ergebnis: Desorientierung, unterbrochene Tastaturnavigation, Frustration.

Die vollständige Tastatur-Map für ein Karussell sieht so aus:

ArrowLeft und ArrowRight wirken als Slide-Navigation nur, wenn das Karussell selbst oder ein Navigationselement den Fokus hält, nicht wenn der Fokus auf einem Link oder Button innerhalb einer Slide liegt. Das hat damit zu tun, dass die Arrow Navigation im Kontext eines Tab Patterns über den äußeren Container navigierbar ist. Das bedeutet im Umkehrschluss, dass diese Navigation nicht automatisch für das Region Pattern implementiert ist.

Den Fokus verlieren

Kommen wir zum zweithäufigsten Fehler, noch tückischer, weil er unsichtbar ist. Ein Karussell hat meistens mehr Slides, als gleichzeitig sichtbar sind. Die nicht sichtbaren Slides existieren weiterhin im DOM, der hierarchischen Baumstruktur, die alle HTML-Bausteine einer Seite auflistet. Und wenn ihre Inhalte, Links, Buttons, weiterhin in der Tab-Reihenfolge stecken, kann eine Tastatur-Nutzerin auf Elemente fokussieren, die sie gar nicht sehen kann.

Das W3C nennt drei Strategien, um das zu verhindern:

1. inert HTML-Attribut — die robusteste Lösung, mit Einschränkung beim Browser-Support. inert entfernt ein Element und seine Kinder vollständig aus dem Accessibility Tree und der Tab-Reihen

<!-- Off-Screen: aus dem Accessibility Tree entfernt -->
<div role="group" aria-roledescription="Slide" aria-label="2 von 5" inert>
  <a href="/produkt-2">Produkt 2</a> <!-- nicht fokussierbar -->
</div>

<!-- Aktive Slide: normal bedienbar -->
<div role="group" aria-roledescription="Slide" aria-label="3 von 5">
  <a href="/produkt-3">Produkt 3</a>
</div>

2. aria-hidden="true" + tabindex="-1" — der universelle Fallback. aria-hidden entfernt das Element aus dem Accessibility Tree, einer speziellen Screenreader-Darstellung des DOM. tabindex="-1" entfernt ein HTML-Element aus der Tab-Reihenfolge. Während aria-hidden auf die übergeordneten Slides gesetzt wird, muss tabindex auf alle interaktiven Kindelemente gesetzt werden, was bei komplexen Slide-Inhalten schnell aufwändig wird.

3. CSS interactivity: inert, definiert im CSS Overflow Module Level 5, repliziert die Funktionalität des klassischen HTML-Attributs inert. Da der aktuelle Browser-Support für die CSS-Variante unvollständig ist, gilt sie als experimentell. Für den produktiven Einsatz wird ein Fallback benötigt; inert in CSS sollte nicht als alleinige Lösung genutzt werden.

Achtung — display: none: Bei scroll-basierten Karussellen darf diese Eigenschaft nicht verwendet werden, um Slides auszublenden. Slides müssen im Layout vorhanden sein, damit CSS Scroll Snap und Scroll-Animationen funktionieren. inert ist hier die richtige Wahl, es versteckt den Inhalt semantisch, ohne ihn aus dem Layout zu entfernen.

Das Prinzip der Selbstbestimmung

Es gibt einen Grund, warum dieses Thema über technische Korrektheit hinausgeht. Fokus Management ist nicht nur eine WCAG-Anforderung, es ist die digitale Version eines grundlegenden Rechts: der Selbstbestimmung.

Ein Karussell, das den Fokus eigenständig verschiebt, trifft eine Entscheidung für die Nutzerin. Es sagt: Du sollst jetzt hier sein, nicht dort. Für eine Maus-Nutzerin ist das eine milde Unannehmlichkeit. Für eine Tastatur-Nutzerin bedeutet es, die Kontrolle über ihre eigene Navigation zu verlieren.

Genau nach demselben Prinzip entscheidet sich die Tab-Reihenfolge. Man stelle sich vor, eine Nutzerin gelangt nur nach Überspringen des Inhalts zur Navigation, oder zwischen den Navigationselementen ist ein großer Block an Texten und Steuerelementen. Das klingt für Mausnutzer:innen absurd, ist aber für Tastaturnutzer:innen der Alltag. Ein kleines Stück Kontrollverlust.

Barrierefreie Entwicklung bedeutet, diese Kontrolle konsequent in den Händen der Nutzenden zu lassen. Der Button löst eine Aktion aus. Wo der Fokus danach ist, entscheidet nicht das Karussell. Was das für die Implementierung bedeutet: JavaScript darf nach einem Slide-Wechsel niemals automatisch focus() aufrufen, es sei denn, der Nutzer hat explizit auf einen neuen Inhaltsbereich navigiert.

Was als Nächstes kommt

Semantik und Tastaturnavigation sind gelöst, aber ein Karussell kommuniziert noch nicht. Wenn sich der Inhalt ändert, muss ein Screenreader das erfahren. Wann, wie laut und in welcher Form das passiert, ist das Thema von Teil 4: aria-live, Autoplay und das Ankündigungsproblem.

➔ Wann ein Screenreader sprechen soll, und wann nicht

Quellen: W3C APG, Carousel Pattern · WCAG 2.1.1, Keyboard · Chrome, Accessible Carousel