Wird geladen…
ARIA-Grundlagen: Wann und wie man es einsetzt
ARIA steht für Accessible Rich Internet Applications und ist eine Spezifikation des W3C, die HTML um semantische Informationen für Screenreader und andere assistive Technologien erweitert. Klingt technisch – und ist es auch. Aber die grundlegenden Konzepte sind schnell verstanden.
Das Wichtigste vorweg: ARIA ist kein Allheilmittel. Es verändert, was Screenreader ansagen – aber es verändert nicht das tatsächliche Verhalten eines Elements. Ein div mit role="button" wird für Screenreader zum Button, aber ohne JavaScript reagiert er weder auf Enter noch auf die Leertaste. Das macht falsch eingesetztes ARIA gefährlich.
Rollen, Eigenschaften und Zustände
ARIA besteht aus drei Kategorien:
Rollen (Roles): Beschreiben, was ein Element ist. Beispiele: role="button", role="dialog", role="navigation", role="alert". Rollen überschreiben die native HTML-Semantik.
Eigenschaften (Properties): Statische Zusatzinformationen über ein Element. Beispiele: aria-label="Suche" (gibt einem Element einen zugänglichen Namen), aria-describedby="hinweis-id" (verknüpft ein Element mit einer Beschreibung).
Zustände (States): Dynamische Informationen, die sich ändern können. Beispiele: aria-expanded="true" (ein Accordion ist geöffnet), aria-checked="false" (eine Checkbox ist nicht aktiviert), aria-disabled="true".
Landmark-Rollen
HTML – <header> / role="banner"
Kennzeichnet den Seitenkopf. Screenreader-Nutzende können direkt zu Landmarks springen – das spart viel Navigation.
HTML – <nav> / role="navigation"
Navigationsbereiche. Eine Seite kann mehrere haben – aria-label hilft, sie zu unterscheiden (z.B. "Hauptnavigation", "Breadcrumb").
HTML – <main> / role="main"
Der Hauptinhalt der Seite. Sollte nur einmal pro Seite vorkommen. Ermöglicht "Zum Hauptinhalt springen"-Links.
HTML – <footer> / role="contentinfo"
Informationen zur Seite: Impressum, Copyright, Kontakt. Ebenfalls ein Sprungziel für Screenreader-Nutzende.
Live-Regionen: dynamische Inhalte ankündigen
Wenn Inhalte sich ohne Seitenladung ändern – etwa Statusmeldungen, Fehlertexte oder Suchergebnisse – bemerken Screenreader das nicht automatisch. Live-Regionen lösen dieses Problem.
aria-live="polite": Die Änderung wird angesagt, sobald die Nutzerin aufgehört hat zu tippen oder zu navigieren. Geeignet für nicht-kritische Updates wie Suchergebnisse.
aria-live="assertive": Die Änderung wird sofort angesagt und unterbricht andere Ansagen. Nur für wirklich kritische Meldungen verwenden – etwa Fehler bei Überweisungen oder Sicherheitswarnungen.
role="alert": Kurzform für aria-live="assertive" aria-atomic="true". Geeignet für Fehlermeldungen und wichtige Systemstatusänderungen.
Häufige Fehler beim ARIA-Einsatz
! – ARIA-Rollen auf nativen Elementen
role="button" auf einem echten <button> ist redundant und kann zu Konflikten führen. Native Elemente nicht mit ARIA-Rollen überlagern.
! – aria-hidden auf fokussierbare Elemente
aria-hidden="true" entfernt ein Element aus dem Accessibility-Tree – aber nicht aus der Tab-Reihenfolge. Fokusfallen entstehen.
! – Zu viele aria-live-Regionen
Jede Änderung in einer Live-Region wird angesagt. Zu viele führen zu Informationsüberflutung. Sparsam einsetzen.
! – Veraltete ARIA-Muster
ARIA-Spezifikationen und Browser-Implementierungen ändern sich. Immer aktuelle Dokumentation und den ARIA APG als Referenz nutzen.
Weiterführende Ressourcen
W3C – ARIA Authoring Practices Guide
Offizielle Referenz für alle gängigen Widget-Muster mit Tastaturverhalten und ARIA-Implementierung.
ARIA Authoring Practices Guide besuchen (öffnet in neuem Tab)MDN – ARIA auf MDN Web Docs
Vollständige Referenz aller ARIA-Rollen, -Eigenschaften und -Zustände mit Browser-Kompatibilitätsinformationen.
ARIA auf MDN Web Docs besuchen (öffnet in neuem Tab)
Über die Autorin / den Autor
