Faceless UI: Eine Open-Source Web Component für barrierefreie Karusselle

Wer das BFSG umsetzen will, steht schnell vor einer unerwarteten Aufgabe: Ein barrierefreies Karussell zu bauen ist deutlich aufwendiger als es aussieht. role="region", aria-roledescription, aria-live, inert, prefers-reduced-motion, Touch Targets, Swipe-Alternativen, dynamische Play/Pause-Labels, Fokus Management, das ist der Umfang dessen, was eine wirklich konforme Implementierung braucht. Diese Serie hat jede dieser Schichten aufgearbeitet.

Jetzt kommt die Frage, die am Ende jeder solchen Serie berechtigt ist: Muss das alles jedes Mal von Hand gebaut werden? Nicht unbedingt. faceless-carousel ist eine Open-Source Web Component, die genau diese Arbeit einmal erledigt, und sie dann in jedem Projekt wiederverwendbar macht, ohne dem Entwickler vorzuschreiben, wie das Karussell auszusehen hat.

Was eine Web Component ist — und warum das hier relevant ist

Eine Web Component ist eine nativ im Browser verankerte Komponente. Kein React, kein Vue, kein Angular, sie funktioniert in jedem Umfeld, weil sie Teil des Web-Standards selbst ist. Wer sie einbindet, importiert eine JavaScript-Datei und verwendet ein neues HTML-Element, als wäre es ein nativer Tag.

Was das für Accessibility bedeutet, ist nicht trivial. Web Components kapseln ihr inneres Verhalten im sogenannten Shadow DOM, einem abgeschlossenen DOM-Baum, der von außen nicht versehentlich überschrieben werden kann. ARIA-Attribute, Event Listener, Fokus-Management und Live Regions leben innerhalb dieser Kapselung, geschützt vor globalen CSS-Klassen, JavaScript-Konflikten oder Framework-Updates, die unerwartete Nebeneffekte haben. Wer Accessibility-Logik einmal sorgfältig in eine Web Component gegossen hat, kann sicher sein, dass sie sich bei jedem Einsatz gleich verhält, egal ob in einem Next.js-Projekt, einem statisch generierten Hugo-Blog oder einer klassischen HTML-Seite.

Das Faceless-UI-Prinzip

„Faceless" heißt: Die Komponente hat kein Gesicht. Sie bringt das komplette Accessibility-Fundament mit, ARIA-Struktur, Tastaturnavigation, Fokus Management, Live Regions, Autoplay-Kontrolle, Off-Screen-Behandlung, aber keinerlei Meinung dazu, wie das Karussell aussehen soll. Farben, Abstände, Animationen, Typografie: alles beim Entwickler.

Kein CSS, das überschrieben werden muss. Kein Design, das zum eigenen Designsystem passen muss oder eben nicht.

Der Gedanke dahinter: Accessibility-Logik ist Infrastruktur. Sie einmal sorgfältig zu bauen und dann überall einzusetzen ist effizienter als sie mit jeder neuen Komponente neu zu erfinden, und sicherer, weil sie nicht jedes Mal neu getestet werden muss.

Wie das in der Praxis aussieht

Nach fünf Teilen voller ARIA-Attribute und Edge Cases ist die Einbindung fast ernüchternd simpel. Man bindet das Script ein, schreibt <faceless-carousel> ins HTML, packt die eigenen Slides als direkte Kind-Elemente rein, und die Komponente übernimmt den Rest.

Jedes Kind wird automatisch als Slide erkannt, mit den richtigen ARIA-Rollen versehen und in die Navigation eingebunden. Kein Markup, das man von Hand pflegen muss. Kein JavaScript, das man schreiben muss.

Für das Styling gibt es keine Vorgaben. Die Komponente bringt kein CSS mit, das man überschreiben müsste. Wer Tailwind verwendet, schreibt Tailwind. Wer CSS Modules verwendet, schreibt CSS Modules. Punkte, Abstände, Animationen, Farben, alles über CSS Custom Properties steuerbar, so viel oder so wenig wie man braucht.

Die Steuerung des Karussells funktioniert auf zwei Wegen. Über HTML-Attribute direkt am Element: Loop, Autoplay, Anzahl sichtbarer Slides, Peek-Effekte, Mousewheel-Support, alles deklarativ, ohne eine Zeile JavaScript. Und über externe Buttons, die man irgendwo im DOM platzieren kann, etwa links und rechts neben dem Slider, und die man einfach mit einem Attribut mit dem Karussell verknüpft. Die Komponente verdrahtet sie beim Laden automatisch und räumt alles auf, wenn sie aus dem DOM entfernt wird. Wer mehr Kontrolle braucht, hat außerdem eine kleine JavaScript-API: next(), prev(), goTo(index), mehr braucht man meistens nicht.

Open Source

faceless-carousel ist open source, framework-agnostisch und ohne Abhängigkeiten. Wer Websites barrierefrei bauen will, ohne die ARIA-Schichten jedes Mal von Grund auf neu aufzubauen, findet hier eine produktionsreife Grundlage. Issues, Pull Requests und Feedback sind willkommen.

→ faceless-carousel auf GitHub

Was diese Serie gezeigt hat

Barrierefreiheit scheitert selten am Willen. Sie scheitert an der Komplexität, und daran, dass diese Komplexität unsichtbar ist. Kein Screenshot zeigt ein fehlendes aria-live. Kein visueller Test entdeckt eine zerstörte Tab-Reihenfolge. Kein Stakeholder-Review bemerkt, dass Off-Screen-Slides fokussierbar sind.

Was diese Serie gezeigt hat: Accessibility ist kein Feature, das man am Ende hinzufügt. Es ist eine Schicht, die von Anfang an mitgedacht werden muss, in der Semantik, in der Interaktion, in der Zustandskommunikation, in der physischen Eingabe. Wer das einmal verstanden hat, baut andere Komponenten. Bessere Komponenten. Komponenten, die für alle funktionieren.

Das Karussell war das Beispiel. Das Prinzip gilt für alles andere auch.

Zusammenfassung

Als Referenz für eigene Implementierungen und Audits, alle Punkte wurden in dieser Serie erklärt.

Checkliste Barrierefreies Karussell

• Karussell als Landmark navigierbar (role="region")
• aria-roledescription="carousel" auf dem Container gesetzt
• Aussagekräftiges aria-label auf dem Container, nicht „Karussell"
• Jede Slide einzeln identifiziert (role="group", aria-roledescription="slide")
• Positionsinformation verfügbar (aria-label="Slide N of M")
• Off-Screen-Slides im Accessibility Tree nicht vorhanden (inert oder aria-hidden)
• Slide-Wechsel bei manueller Navigation angekündigt (aria-live="polite")
• Slide-Wechsel bei Auto-Rotation nicht angekündigt (aria-live="off")
• Play/Pause-Button vorhanden und korrekt gelabelt
• Play/Pause-Button aktualisiert aria-label bei Zustandswechsel
• Rotation stoppt bei Tastatur-Fokus und Maus-Hover
• Fokus bleibt bei Navigation auf dem Kontrollelement
• Alle Kontrollelemente mit aussagekräftigen Labels
• Touch Targets mindestens 24×24 px (empfohlen: 44×44 px)
• Swipe-Gesten haben Button-Alternativen
• prefers-reduced-motion wird respektiert
• Getestet mit NVDA (Windows), VoiceOver (macOS/iOS), TalkBack (Android)

Quellen: W3C APG, Carousel Pattern · WCAG 2.2 · Chrome, Accessible Carousel · faceless-carousel Dokumentation