Barrierefreies Design System: Komponenten richtig

Es lohnt sich, die sechs Muster aus dem WebAIM Million Report konsequent als Bausteinfragen zu lesen. Sobald man sie den Komponenten zuordnet, wird aus einer langen Mängelliste eine kurze Aufgabenliste für das Design System. Fünf der sechs Muster verschwinden, sobald fünf Bausteine korrekt gebaut sind; das sechste ist eine einzelne Zeile im Grundgerüst.

Der Blick auf die Prozentzahlen macht die Hebelwirkung greifbar: Sind Bild, Formularfeld, Link, Button und das Farbsystem korrekt gebaut, verschwinden fünf der sechs Muster; das sechste, die Seitensprache, ist eine einzelne Deklaration im Grundgerüst. Damit ist der größte Teil der maschinell erkennbaren Barrieren keine Frage der Redaktion, sondern der Architektur. Die maschinelle Prüfung deckt allerdings nur einen Teil ab; Tastaturbedienung, Fokusreihenfolge und sinnvolle ARIA-Zustände zeigen sich erst im WCAG-Audit mit manueller Prüfung.

Alles, was mit der Maus geht, muss auch mit der Tastatur gehen - so fasst WCAG 2.1.1 die Anforderung zusammen. Bei einfachen Elementen wie nativen Links und Buttons ist das ohne Zusatzaufwand erfüllt, weil der Browser die Bedienung mitbringt. Kritisch wird es bei zusammengesetzten Komponenten: Menüs mit Unterebenen, Modale, Tabs, Akkordeons, Slider und eigene Auswahlfelder. Werden sie aus generischen div-Elementen ohne Tastaturlogik gebaut, sind sie mit der Maus bedienbar, mit der Tastatur aber tot. Und ein Modal, das den Fokus nicht einfängt und wieder freigibt, verstößt gegen WCAG 2.1.2 - der Nutzer bleibt gefangen.

Der entscheidende Punkt: Diese Bedienlogik gehört in die Komponente, nicht in jede einzelne Verwendung. Ein Modal-Baustein, der die Tab-Navigation einfängt, mit Escape schließt und den Fokus danach an den auslösenden Button zurückgibt, löst das Problem für jede Verwendung im ganzen Projekt. Wie sich der Fokus in dynamischen Oberflächen und Single-Page-Anwendungen sauber steuern lässt, vertieft der Beitrag zum Fokus-Management in Single-Page-Apps; die konkreten Muster für überlagernde Ebenen behandelt der Beitrag zu barrierefreien Modals und Overlays.

Diese Punkte sind keine Zutat, sondern Teil der Definition dessen, was eine fertige Komponente ausmacht. Eine tiefere Behandlung der Tastaturmuster - von der logischen Reihenfolge bis zu den erwarteten Tastenbelegungen - bietet der Beitrag zur Tastaturnavigation in der Webentwicklung.

Der wirtschaftliche Kern des Komponentenansatzes ist der Zeitpunkt. Barrierefreiheit, die in die Bausteine eingebaut ist, kostet erfahrungsgemäß einen Bruchteil dessen, was eine nachträgliche Reparatur über Hunderte Seiten verschlingt. Jede Komponente wird einmal durchdacht, geprüft und dokumentiert - danach entsteht Zugänglichkeit als Nebenprodukt der normalen Arbeit. Diese Verlagerung nach vorn, oft als Accessibility by Design beschrieben, verhindert, dass sich Mängel überhaupt erst ansammeln. Warum sich der frühe Einbau gegenüber dem späten Nachrüsten rechnet, vertieft der Beitrag zu Accessibility by Design.

Ein barrierefreies Design System besteht aber nicht nur aus Code. Zu jeder Komponente gehört eine kurze Dokumentation, die festhält, wie sie zu verwenden ist: welcher Alternativtext gebraucht wird, welche Überschriftenebene passt, wann eine Live-Region sinnvoll ist. So bleibt das Wissen erhalten, auch wenn Teams wechseln. Ergänzend sichern Grundlagen wie geprüfte Farbwerte und lesbare Typografie die visuelle Ebene ab - vertieft in den Beiträgen zu Farbkontrasten in der Barrierefreiheit und zu barrierefreier Typografie und Lesbarkeit. Und weil das beste System nur wirkt, wenn Redaktionen es richtig einsetzen, gehören Schulungen für Content-Teams fest dazu.

In der Praxis stehen Betriebe vor zwei Situationen. Entweder existiert bereits eine Komponentenbibliothek, dann geht es um ein gezieltes Audit: Welche Bausteine verstoßen gegen WCAG, und in welcher Reihenfolge lohnt sich die Reparatur? Die Priorität ergibt sich aus der Wiederverwendung - der Button und das Formularfeld, die auf jeder Seite stehen, werden vor dem Sonderfall geprüft, der nur an einer Stelle vorkommt. So entsteht der größte Effekt je investierter Stunde. Oder es gibt noch kein System, dann lohnt es sich, die zentralen Bausteine von Anfang an barrierefrei zu bauen, statt sie später mühsam nachzubessern.

Beide Wege führen über dieselbe Substanz: klar definierte Komponenten mit dokumentierter Zugänglichkeit, geprüft mit automatischen und manuellen Mitteln. Wir setzen in unseren Referenzprojekten genau hier an - erst die Bausteine, dann die Fläche. Welche Angebote unter das Barrierefreiheitsstärkungsgesetz fallen und welche Fristen gelten, ordnen die BFSG-Anforderungen ein. Auch verwandte Bausteine profitieren vom Systemgedanken: verständliche Inhalte, behandelt im Beitrag zu einfacher Sprache für verständliche Web-Texte, und bewegte Elemente wie im Beitrag zu barrierefreien Slidern und Karussells.

Der Weg über das Design System dreht die Logik der Barrierefreiheit um. Statt Fehler dort zu bekämpfen, wo sie sichtbar werden - auf der einzelnen Seite -, setzt er an der Quelle an, aus der sie stammen. Weil 96 Prozent (WebAIM Million, 2025) aller maschinell erkennbaren Fehler auf sechs Muster entfallen und jedes davon einer Komponente zuzuordnen ist, verwandelt eine einmal saubere Bibliothek den größten Teil der BFSG-Pflicht in eine Frage der Architektur. Das spart nicht nur Aufwand, es hält die erreichte Qualität auch stabil: Jede neue Seite, die aus geprüften Bausteinen entsteht, ist von der ersten Zeile an bedienbar - für Menschen mit Behinderung ebenso wie für alle anderen.