Tab-Komponente mit :checked-Hack vs. JS

Eine Tab-Komponente benötigt: eine visuelle Kennzeichnung des aktiven Tabs, ein zugehöriges Panel, das bei der Auswahl ein- oder ausgeblendet wird, Tastaturnavigation zwischen Tabs und barrierefreie ARIA-Attribute. Dies lässt sich mit reinem CSS über den :checked-Hack oder mit JavaScript für eine bessere Barrierefreiheit umsetzen.

Ausgeblendete Radio-Inputs dienen als Zustand: Jeder Tab ist ein mit einem Radio-Input verknüpftes <label>. Wenn ein Radio-Input ausgewählt ist, zeigen CSS-Geschwisterselektoren das entsprechende Panel an und gestalten das Label des aktiven Tabs. Dafür ist kein JavaScript erforderlich.

Platzieren Sie die Radio-Inputs, anschließend alle Labels (Tabs) und danach alle Panels im selben Container. Verwenden Sie den allgemeinen Geschwisterselektor (~), um ein ausgewähltes Radio mit seinem entsprechenden Panel zu verknüpfen. Panels haben standardmäßig display: none; das passende Panel erhält display: block.

Der :checked-Hack kann keine ARIA-Attribute aktualisieren (aria-selected, aria-controls), keine Navigation zwischen Tabs mit den Pfeiltasten ermöglichen, und die Einschränkung der DOM-Reihenfolge (Inputs vor Panels) kann mit den Anforderungen des visuellen Designs kollidieren. Diese Lücken schränken die tatsächliche Barrierefreiheit ein.

Eine JS-Tab-Komponente reagiert auf Klickereignisse der Tab-Schaltflächen, setzt aria-selected am aktiven Tab, aktualisiert aria-hidden an den Panels und verwaltet den Fokus. Dieser Ansatz ermöglicht vollständige ARIA-Konformität und Tastaturinteraktionsmuster gemäß den ARIA Authoring Practices.

Verwenden Sie role="tablist" am Container, role="tab" an jeder Tab-Schaltfläche mit aria-selected und aria-controls sowie role="tabpanel" an jedem Panel mit aria-labelledby. Screenreader geben die Anzahl, Position und den ausgewählten Zustand der Tabs aus.

Die ARIA Authoring Practices für Tabs sehen Folgendes vor: Mit der Tab-Taste gelangen Sie in die Tab-Liste und fokussieren den aktiven Tab. Mit Pfeil links/rechts wechseln Sie zwischen Tabs. Home/End springen zum ersten bzw. letzten Tab. Jede Bewegung mit einer Pfeiltaste aktiviert den fokussierten Tab (Muster mit automatischer Aktivierung).

Gestalten Sie den aktiven Tab mit einem unteren Rahmen oder einer Hintergrundänderung über den Selektor [aria-selected="true"] – dies funktioniert sowohl mit JS als auch mit dem :checked-Ansatz. So bleibt CSS mit dem ARIA-Zustandsattribut synchron, ohne dass zwei Zustände verwaltet werden müssen.

Ein animierter Tab-Indikator gleitet zwischen Tabs: Positionieren Sie ein absolut positioniertes Indikatorelement, verwenden Sie JavaScript, um seine linke Position und Breite an die Abmessungen des aktiven Tabs anzupassen, und animieren Sie es mit transition: left 200ms ease, width 200ms ease.

Wenn Tabs auf kleinen Bildschirmen aus ihrem Container herauslaufen, verwenden Sie horizontales Scrollen (overflow-x: auto; scrollbar-width: none) oder reduzieren Sie sie auf mobilen Geräten zu einem Select-Dropdown. Für den Select-Ansatz ist JS erforderlich, um das native Select mit der Sichtbarkeit des Tab-Panels zu synchronisieren.

Verwenden Sie den :checked-Hack für einfache, nicht kritische UI, bei der Barrierefreiheit keine vorrangige Anforderung ist. Verwenden Sie JavaScript-Tabs für jede Produktionsoberfläche, die Tastatur- oder Screenreader-Nutzende bedient oder in Audits bzw. aufgrund gesetzlicher Anforderungen ARIA-Konformität erfordert.

Was ist die wichtigste Einschränkung des CSS-:checked-Hacks für Tabs im Hinblick auf die Barrierefreiheit?

Der :checked-Hack ermöglicht das Umschalten von Tabs ausschließlich mit CSS, indem Radio-Inputs und Geschwisterkombinatoren verwendet werden, bietet jedoch keine ARIA- oder Tastaturzugänglichkeit. JavaScript-Tabs mit ARIA-Rollen (tablist, tab, tabpanel), der Verwaltung von aria-selected und der Behandlung der Pfeiltasten ermöglichen die vollständige, barrierefreie Benutzererfahrung, die für produktionsreife Komponenten erforderlich ist.