ARIA-Labels verstehen: Accessibility für dynamische Inhalte
ARIA-Labels sind die zweite Sprache des Web: unsichtbar für sehende Nutzer, unverzichtbar für Screenreader. Sie kommen besonders dort ins Spiel, wo visuelle Metaphern (Icons, Farb-Zustände, Positionen) Information tragen, die ein Screenreader sonst nicht erfassen kann.
Die drei wichtigsten ARIA-Label-Attribute
aria-label: textlicher Kurzname direkt am Element. Beispiel: <button aria-label="Menü schließen">X</button>
aria-labelledby: verweist per ID auf ein anderes Element, das den Namen liefert. Gut für komplexe Dialoge.
aria-describedby: verweist auf ausführlichere Beschreibung (wird zusätzlich zum Label vorgelesen). Ideal für Hilfetexte bei Formularen.
Die goldene ARIA-Regel: Erst Semantik, dann ARIA
Die beste ARIA ist oft keine ARIA. Native HTML-Elemente (
Typische Einsatzgebiete
(1) Icon-only-Buttons (wie Schließen-X, Burger-Menü): aria-label liefert den Namen.
(2) Custom-Komponenten (Tabs, Accordions, Dialog-Boxes): role + aria-expanded/aria-selected.
(3) Formularfelder ohne sichtbares Label: aria-label als Notlösung (besser: echtes
Häufige ARIA-Fehler
Redundanz: <button aria-label="Senden">Senden</button> – Screenreader liest doppelt.
Widerspruch: <button aria-label="Menü öffnen">Menü schließen</button> – visueller und aria-Text differieren.
Überflüssig: <div role="button"> statt einfach <button> zu nutzen.
WCAG-Bezug
ARIA wird in WCAG 4.1.2 Name, Role, Value (Level A) gefordert, wenn native Semantik nicht ausreicht. WCAG 1.3.1 Info and Relationships (Level A) verlangt, dass semantische Beziehungen programmatisch erkennbar sind – ARIA liefert das für Custom-Komponenten.
Wie steht deine Webseite in diesem Punkt da?
Kostenloser Scan gegen 15 WCAG-2.1-AA-Kriterien – inkl. ARIA-Label-Check.
Jetzt Webseite prüfen →