WAI-ARIA (Accessible Rich Internet Applications) ist eine technische Spezifikation des W3C, die HTML-Elementen durch Rollen, Zustände und Eigenschaften semantische Bedeutung verleiht, die nativer HTML-Code allein nicht ausdrücken kann – insbesondere für komplexe, dynamische UI-Komponenten.
Rubrik: Mediendesign & Digitale Medien · Unterrubrik: Accessibility · Niveau: Fortgeschritten
Was sind ARIA-Labels?
ARIA steht für Accessible Rich Internet Applications und ist eine Spezifikation der W3C Web Accessibility Initiative (WAI), die 2008 in der ersten Version veröffentlicht und zuletzt mit ARIA 1.2 (2023) aktualisiert wurde. ARIA ermöglicht es Entwicklerinnen und Entwicklern, HTML-Elementen drei Arten zusätzlicher Informationen beizufügen:
- Rollen (Roles): Was ist dieses Element? (z. B.
role="button",role="dialog",role="tablist") - Eigenschaften (Properties): Welche dauerhaften Merkmale hat es? (z. B.
aria-label="Suche",aria-required="true") - Zustände (States): Welchen aktuellen Zustand hat es? (z. B.
aria-expanded="true",aria-checked="false")
ARIA wird vom Browser über die Zugänglichkeits-API an Screen Reader – Barrierefreiheit für blinde und sehbehinderte Nutzer und andere assistive Technologien kommuniziert, ohne das visuelle Erscheinungsbild zu beeinflussen.
Erklärung
Die goldene Regel: Natives HTML geht vor
Die wichtigste ARIA-Regel lautet: Kein ARIA ist besser als schlechtes ARIA. Bevor ARIA eingesetzt wird, sollte immer geprüft werden, ob natives HTML dasselbe leisten kann:
<button>statt<div role="button"><nav>statt<div role="navigation"><input type="checkbox">statt<div role="checkbox">
Natives HTML hat ARIA-Rollen und -Zustände bereits eingebaut und wird von Browsern und Screen Reader – Barrierefreiheit für blinde und sehbehinderte Nutzer am zuverlässigsten interpretiert. ARIA ist korrekt für Fälle einzusetzen, in denen natives HTML nicht ausreicht: komplexe Widget-Muster (Tabs, Accordions, Comboboxes, Datepicker), dynamische Statusmeldungen, und Verknüpfungen zwischen Elementen.
Wichtige ARIA-Attribute im Detail
`aria-label`: Gibt einem Element einen zugänglichen Namen, der für Screen Reader – Barrierefreiheit für blinde und sehbehinderte Nutzer sichtbar ist, aber nicht visuell dargestellt wird. Wird verwendet, wenn kein sichtbarer Text vorhanden ist.
``html <button aria-label="Suche öffnen"> <svg><!-- Lupen-Icon --></svg> </button> ``
`aria-labelledby`: Verknüpft ein Element mit einer sichtbaren Text-ID als Name. Vorzuziehen gegenüber aria-label, wenn bereits ein sichtbarer Text existiert.
``html <h2 id="dialog-title">Einstellungen</h2> <div role="dialog" aria-labelledby="dialog-title">...</div> ``
`aria-describedby`: Verknüpft ein Element mit einem beschreibenden Text (ausführlicher als der Name). Häufig für Formularfeld-Hinweise.
``html <input type="password" aria-describedby="pw-hint"> <p id="pw-hint">Mindestens 8 Zeichen, inkl. einer Zahl.</p> ``
`aria-hidden="true"`: Versteckt ein Element vollständig vor assistiven Technologien. Nützlich für rein dekorative Elemente.
``html <span aria-hidden="true">★★★★☆</span> <span class="sr-only">4 von 5 Sternen</span> ``
`aria-expanded`: Zeigt an, ob ein Akkordeon, Dropdown oder Navigationsmenü ausoder eingeklappt ist.
``html <button aria-expanded="false" aria-controls="menu">Menü</button> <ul id="menu" hidden>...</ul> ``
`aria-live`: Definiert eine Live-Region, in der Änderungen automatisch von Screen Readern angekündigt werden – ohne Fokusverschiebung.
``html <div aria-live="polite" id="status-message"></div> ``
Werte: polite (wartet auf Pause im Sprachfluss), assertive (unterbricht sofort – nur für kritische Meldungen), off (keine Ankündigungen).
`aria-current`: Zeigt das aktuell aktive Element in einer Serie an (z. B. aktueller Schritt in einem Wizard, aktuelle Seite in einer Paginierung).
``html <a href="/schritt-2" aria-current="step">Schritt 2</a> ``
`role="region"` mit `aria-label`: Definiert bedeutungsvolle Seitenabschnitte, die in der Landmark-Navigation von Screen Readern erreichbar sind.
``html <section role="region" aria-label="Neueste Artikel">...</section> ``
ARIA-Rollen-Kategorien
ARIA 1.2 unterscheidet mehrere Rollen-Kategorien:
- Landmark-Rollen:
banner,main,navigation,search,complementary,contentinfo,region– entsprechen HTML5-Landmarks (<header>,<main>,<nav>, etc.) - Widget-Rollen:
button,checkbox,combobox,dialog,grid,listbox,menu,slider,tablist,tab,tabpanel,tooltip,tree - Dokument-Struktur-Rollen:
article,cell,definition,figure,heading,list,row,table - Live-Region-Rollen:
alert,log,marquee,status,timer
Häufige ARIA-Fehler
Doppelte Rollen: <button role="button"> ist redundant.
Falscher Name: <input aria-label="Name" placeholder="Name"> – hier ist aria-label redundant mit dem Placeholder, der aber kein Ersatz für ein echtes <label> ist (vgl. Barrierefreie Formulare – Labels, Fehler & Bestätigung).
Vergessene Zustandsaktualisierung: Ein Accordion mit aria-expanded="false" im HTML, das via JavaScript ausgeklappt wird, ohne den aria-expanded-Wert auf true zu aktualisieren.
`aria-hidden` auf fokussierbaren Elementen: <button aria-hidden="true"> – das Element ist für Screen Reader unsichtbar, aber per Tastatur erreichbar. Widersprüchlich und verwirrend.
Beispiele
Vollständiges Tab-Interface-Beispiel:
``html <div role="tablist" aria-label="Produktkategorien"> <button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1">Kameras</button> <button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2">Objektive</button> </div> <div role="tabpanel" id="panel-1" aria-labelledby="tab-1">...</div> <div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>...</div> ``
In der Praxis
ARIA-Implementierungen werden am besten anhand der WAI-ARIA Authoring Practices Guide (APG) des W3C umgesetzt, der für alle gängigen Widget-Muster vollständige Code-Beispiele mit Tastaturinteraktionen und ARIA-Attributen bereitstellt.
Im Design-Kontext: Jede benutzerdefinierte Komponente (Custom Dropdown, Modal, Accordion, Datepicker) sollte in der Spezifikation mit den notwendigen ARIA-Attributen dokumentiert werden, damit Entwicklerinnen und Entwickler wissen, welche semantischen Informationen die Komponente kommunizieren muss.
Vergleich & Abgrenzung
ARIA vs. natives HTML: Natives HTML ist immer vorzuziehen. ARIA ergänzt dort, wo HTML semantisch nicht ausreicht.
ARIA vs. CSS-visuelle Gestaltung: ARIA beeinflusst keine visuelle Darstellung. Visuelles Design und ARIA-Semantik sind unabhängig voneinander – beides muss korrekt sein.
Häufige Fragen (FAQ)
Muss ich ARIA auf jeder Website verwenden? Nicht zwingend. Semantisch korrektes HTML ohne zusätzliches ARIA kann bereits vollständig barrierefrei sein. ARIA ist für komplexe JavaScript-Widgets und dynamische Inhalte notwendig.
Was ist der Unterschied zwischen `aria-label` und `aria-labelledby`? aria-label enthält den Namenstring direkt; aria-labelledby verweist per ID auf ein anderes Element, dessen Textinhalt als Name dient. aria-labelledby ist vorzuziehen, wenn der Name sichtbarer Text ist.
Verwandte Einträge
- Accessibility – Grundlagen digitaler Barrierefreiheit
- WCAG – Web Content Accessibility Guidelines im Überblick
- Screen Reader – Barrierefreiheit für blinde und sehbehinderte Nutzer
- Tastaturnavigation & Fokus-Management
- Barrierefreie Formulare – Labels, Fehler & Bestätigung
- Accessibility Testing – Tools & Methoden (axe, WAVE, Lighthouse)
Weiterführend
- W3C: Accessible Rich Internet Applications (WAI-ARIA) 1.2. W3C Recommendation, 2023.
- W3C WAI: ARIA Authoring Practices Guide (APG). 2023.
- Faulkner, Steve: The Accessibility Tree: A Training Guide for Advanced Web Development. The Paciello Group, 2017.
- Pappas, Myk: Using ARIA. W3C Note. 2023.
- WebAIM: Accessible Rich Internet Applications (WAI-ARIA). 2023.
