Themenbereich · 37 Artikel
Barrierefreie Komponenten: Aufbau und Einstieg
Barrierefreie Komponenten sind Bedienelemente, deren Name und Rolle programmatisch ermittelbar sind, deren Zustände programmatisch gesetzt und gemeldet werden und die vollständig per Tastatur bedienbar sind. Name, Rolle und Zustand regelt WCAG 2.2, Erfolgskriterium 4.1.2 „Name, Rolle, Wert“ auf Stufe A, die vollständige Tastaturbedienbarkeit Erfolgskriterium 2.1.1 „Tastatur“, ebenfalls Stufe A. Standard-HTML-Steuerelemente erfüllen das bereits, wenn sie spezifikationsgemäß eingesetzt werden; aufwendig wird es erst bei selbstgebauten Widgets. Dieser Bereich sortiert die Bausteine nach Aufgabenfeldern statt nach Widget-Alphabet.
Das Wichtigste in Kürze
- Eine Komponente ist barrierefrei, wenn Name, Rolle und Zustand programmatisch ermittelbar sind (WCAG 2.2, 4.1.2, Stufe A) und sie vollständig per Tastatur bedienbar ist (2.1.1, ebenfalls Stufe A).
- Erste Regel von ARIA: Bringt ein natives HTML-Element die nötige Semantik und das nötige Verhalten mit, ist es zu verwenden – statt ein
divumzufunktionieren. - ARIA ändert weder Aussehen noch Verhalten, nur das, was der Accessibility-Tree meldet –
role="button"verpflichtet dich, Tastatur und Zustände selbst zu bauen. - Stand Juli 2026: Startseiten mit ARIA hatten laut WebAIM Million (Februar 2026) im Schnitt 59,1 Fehler, ohne ARIA 42 – ein Zusammenhang, keine belegte Ursache.
- Fang bei den Beschriftungen an: 51,0 % der Startseiten hatten fehlende Formular-Labels, 46,3 % leere Links, 30,6 % leere Buttons (WebAIM Million 2026).
- Dann die Tastatur: Von 65 deutschen Webshops waren nur 20 vollständig per Tastatur bedienbar (Aktion Mensch und Google, 3. Testbericht 2025).
Womit du anfängst
Mit dem Verzicht. Die erste Regel von ARIA lautet sinngemäß: Bringt ein natives HTML-Element die benötigte Semantik und das benötigte Verhalten schon mit, dann nimm es – statt ein Element umzufunktionieren und mit einer ARIA-Rolle nachzurüsten (W3C, Using ARIA). Stand Juli 2026 ist dieses Dokument ein „Discontinued Draft“ (24. Februar 2026); das W3C verweist auf den ARIA Authoring Practices Guide. Die Regel gilt weiter – anwenden lässt sie sich aber nur, wenn klar ist, was semantisches HTML ist.
Dass der Verzicht sich lohnt, legen die Zahlen nahe: Der WebAIM-Million-Report vom Februar 2026 zählte 133.589.803 ARIA-Attribute auf einer Million Startseiten (+27 % in einem Jahr) – bei gleichzeitig 56,1 Fehlern pro Seite (+10,1 %). Mehr ARIA geht mit mehr Barrieren einher – laut WebAIM nicht zwingend ursächlich, da ARIA-reiche Seiten auch komplexer sind. Daher der Merksatz des W3C: Kein ARIA ist besser als schlechtes ARIA.
Die Reihenfolge ergibt sich aus denselben Zahlen. Zuerst die Beschriftungen: Labels und Beschriftungen fehlten auf 51,0 % der Startseiten, und von 6,9 Eingabefeldern pro Seite waren 33,1 % nicht korrekt beschriftet. Dann die Tastatur – an Tastaturbedienung und Fokus scheiterten laut Aktion Mensch und Google 45 von 65 deutschen Webshops. Erst danach kommen die zusammengesetzten Widgets.
Was dabei schiefgeht, benennt der BITV-Test-Prüfschritt zu 4.1.2: Bedienelemente aus div oder span ohne ARIA-Ausgleich, Zustandswechsel nur per CSS statt über ARIA-Attribute, a-Elemente ohne href als Schaltflächen. Deshalb steht am Anfang die Frage Button oder Link?
Wie dieser Bereich aufgebaut ist
Formulare. Sichtbares Label, programmatisch verknüpft, dazu Fehlermeldungen mit aria-describedby und aria-invalid sowie eine faire Validierung und Pflichtfeldkennzeichnung. Das Fundament liefert die Formular-Semantik.
Navigation. Skip-Links, aussagekräftige Linktexte, aria-current für die aktive Seite und aria-expanded an Menüs und Dropdowns. Zur Gewichtung: 71,6 % der Screenreader-Nutzenden orientieren sich auf langen Seiten zuerst an Überschriften, nur 3,7 % an Landmarks; unabhängig davon geben 31,8 % an, Landmarks häufig zu nutzen (WebAIM Screen Reader User Survey #10, Erhebung Dezember 2023/Januar 2024, veröffentlicht Februar 2024). Landmarks und Outline sind nützlich, ersetzen aber keine saubere Überschriftenhierarchie.
Überlagerungen. Dialoge und Modals folgen einem Muster: Fokus hinein, Fokus dort halten, Esc schließt, Fokus zurück auf den auslösenden Button – genauso bei Tooltips und Popover und beim Cookie-Banner.
Tabellen und Daten. Echte Auszeichnung mit th, scope und caption – nachzulesen unter Tabellen semantisch aufbauen. Darauf setzen komplexe Datentabellen und sortierbare Tabellen mit aria-sort auf.
Medien. Alt-Texte, bedienbare Steuerelemente im Media-Player, keine Autoplay-Wiedergabe, Untertitel und Transkripte.
Zusammengesetzte Widgets. Hier wird ARIA unvermeidlich – bei Akkordeons (ohne JavaScript oft mit details und summary lösbar), Tabs, Comboboxen und bei Live-Regionen, die Statusmeldungen nach 4.1.3 transportieren.
Warum es diesen Bereich gibt
Die maßgebliche Muster-Sammlung ist der ARIA Authoring Practices Guide des W3C mit 30 Mustern von Accordion bis Window Splitter. Er ist informativ, nicht normativ, und sein „Read Me First“ warnt: Interoperabilität mit assistiver Technik muss vor dem Produktiveinsatz getestet werden, und die Beispiele enthalten bewusst keine Workarounds für Lücken in ARIA 1.2. „Code kopiert, fertig“ gilt also nicht. Und: Stand Juli 2026 existiert keine deutsche Übersetzung des APG. Diese Lücke fülle ich hier.
Komponenten-Bibliotheken sind eine legitime Abkürzung, aber keine Garantie. KoliBri vom ITZBund bringt über 40 barrierefreie Komponenten mit, der KERN-UX-Standard rund 40 – entwickelt entlang von BITV 2.0, EN 301 549 und WCAG – eine barrierefreie Bibliothek ergibt trotzdem keine barrierefreie Anwendung. Prüfe deshalb: Kommt Barrierefreiheit in der Doku vor? Sind Implementierungsdetails beschrieben? Und wie verhält sich das gerenderte Markup im Test mit NVDA? Einen kompakten Startpunkt bietet mein kostenloses E-Book.
Häufige Fragen
Brauche ich ARIA für barrierefreie Komponenten, oder reicht HTML?
Für den größten Teil einer Website reicht HTML. Buttons, Links, Formularfelder und Tabellen bringen Name, Rolle und Zustand von Haus aus mit und erfüllen 4.1.2 ohne Zutun. ARIA brauchst du erst, wo HTML kein passendes Element anbietet: Tabs, Comboboxen, Slider, Live-Regionen. Es ist eine Ergänzungstechnik, keine Ersatztechnik.
Gibt es den ARIA Authoring Practices Guide auf Deutsch?
Nein. Die Übersetzungsübersicht der W3C Web Accessibility Initiative führt Stand Juli 2026 auf Deutsch unter anderem den alt-Entscheidungsbaum, die Einführung in das barrierefreie Web samt Video-Einführung sowie WCAG 2.0 als autorisierte und WCAG 2.1 als inoffizielle Übersetzung – den APG jedoch nicht, er ist englischsprachig. Die Komponentenseiten hier machen seine Muster auf Deutsch und mit deutschem Prüfbezug verfügbar.
Reicht eine barrierefreie Komponenten-Bibliothek, um das BFSG zu erfüllen?
Nein. Eine Bibliothek liefert einzelne Bausteine, das Barrierefreiheitsstärkungsgesetz bewertet aber das fertige Produkt. Falsch eingesetzte Muster, fehlende Beschriftungen, unzureichende Kontraste und eigene Erweiterungen fallen auf dich zurück. Nutze Bibliotheken als Beschleuniger und prüfe das Ergebnis anschließend selbst – mit Tastatur, Accessibility-Tree und mindestens einem echten Screenreader.
Verwandte Themen
- Was ist semantisches HTML? – die Grundlage jeder Komponentenentscheidung.
- WCAG 4.1.2: Name, Rolle, Wert – das Kriterium, an dem eigene Bedienelemente scheitern.
- Rollen, States und Properties – die drei Bausteine von ARIA.
- Tastaturbedienung und Fokus – die Voraussetzung vor jedem Widget.
- BFSG einfach erklärt – wer seit dem 28. Juni 2025 in der Pflicht steht.
- Wie Screenreader-Nutzer surfen – warum Überschriften vor Landmarks kommen.