Was sind ARIA-Attribute?
ARIA (Accessible Rich Internet Applications) ist eine Sammlung von HTML-Attributen die Screenreadern und anderen assistiven Technologien zusätzliche Informationen über interaktive Elemente und deren Zustände liefern. ARIA füllt Lücken wo semantisches HTML allein nicht ausreicht. Die wichtigste ARIA-Regel: Kein ARIA ist besser als schlechtes ARIA. Falsch eingesetztes ARIA verschlechtert die Barrierefreiheit aktiv. Zuerst semantisches HTML, dann ARIA wenn nötig.
Die fünf ARIA-Regeln
Regel 1 — Semantisches HTML bevorzugen
Wenn ein natives HTML-Element mit der gewünschten Semantik existiert, dieses verwenden statt ARIA. button statt div mit role='button', nav statt div mit role='navigation', h2 statt div mit role='heading'. Native Elemente haben eingebaute Keyboard-Unterstützung die ARIA nicht automatisch mitliefert.
Regel 2 — Semantik nicht ändern
Keine ARIA-Rollen auf Elemente setzen die eine andere native Semantik haben. role='button' auf einem a-Element ist verwirrend — ein Link navigiert, ein Button führt eine Aktion aus. Wenn Aktions-Semantik gewünscht ist: button verwenden.
Regel 3 — Interaktive ARIA-Elemente per Tastatur bedienbar
Wenn ein Element per ARIA interaktiv gemacht wird (role='button', role='tab'), muss es auch per Tastatur bedienbar sein — tabindex='0' für Fokussierbarkeit, Keyboard-Handler für Enter und Space. ARIA verändert nur die Semantik, nicht das Verhalten.
Regel 4 — Sichtbare Elemente nicht verstecken
aria-hidden='true' versteckt Elemente vor Screenreadern aber nicht visuell. Sichtbare und interaktive Elemente dürfen nicht aria-hidden sein — das macht sie für Tastaturnutzer fokussierbar aber für Screenreader unsichtbar.
Regel 5 — Interaktive Elemente brauchen zugänglichen Namen
Jedes interaktive Element muss einen Namen haben den Screenreader ansagen können. Buttons: sichtbarer Text oder aria-label. Icons ohne Text: aria-label. Formular-Inputs: label oder aria-label. Ohne Name kann der Nutzer nicht wissen was das Element tut.
Die wichtigsten ARIA-Attribute
aria-label — zugänglichen Namen definieren
Gibt einem Element einen Namen für Screenreader. Verwenden wenn: kein sichtbarer Text vorhanden (Icon-Button), der sichtbare Text nicht ausreichend beschreibend ist, oder mehrere gleichartige Elemente unterschieden werden müssen. Beispiel: button mit aria-label='Menue schliessen'.
aria-describedby — zusätzliche Beschreibung
Verknüpft ein Element mit einer beschreibenden Textstelle (via ID-Referenz). Für: Fehlerhinweise bei Formular-Inputs, Tooltips, ergänzende Informationen. Beispiel: input mit aria-describedby='email-error' und aria-invalid='true', gefolgt von p mit id='email-error'.
aria-expanded — Zustand von Akkordeons und Dropdowns
Zeigt an ob ein steuerbares Element (Akkordeon, Dropdown, Menü) geöffnet oder geschlossen ist. Auf dem Trigger-Element, nicht auf dem gesteuerten Inhalt. Muss per JavaScript aktualisiert werden wenn sich der Zustand ändert.
aria-hidden — von Screenreadern verstecken
Versteckt dekorative oder redundante Elemente vor Screenreadern. Für: dekorative Icons neben Text, redundante visuelle Inhalte, Slide-Inhalte die nicht aktiv sind. Nie auf Elemente setzen die fokussierbar sind oder Inhalt enthalten den der Nutzer braucht.
aria-live — dynamische Inhalte ankündigen
Informiert Screenreader über dynamische Inhaltsänderungen. aria-live='polite' (Ankündigung nach aktueller Aktion) für Updates, Suchergebnisse, Meldungen. aria-live='assertive' (sofortige Unterbrechung) nur für kritische Fehlermeldungen. role='alert' ist Shortcut für aria-live='assertive'.
aria-current — aktuelles Element markieren
Markiert das aktuelle Element in einer Navigation oder einem Prozess. aria-current='page' für aktuelle Seite in Navigation, aria-current='step' für aktiven Schritt in einem mehrstufigen Prozess. Besser als CSS-only Markierung da Screenreader es ansagen.
Landmark Roles
ARIA Landmark Roles strukturieren die Seite für Screenreader-Nutzer die per Tastenkürzel durch Landmarks navigieren. In modernem HTML gibt es native Elemente die automatisch Landmark-Semantik haben — ARIA-Rollen sind nur nötig wenn native Elemente nicht verwendet werden können.
role=‘banner’
HTML-Äquivalent: header — Seitenheader (top-level)
role=‘navigation’
HTML-Äquivalent: nav — Navigationsbereiche
role=‘main’
HTML-Äquivalent: main — Hauptinhalt
role=‘complementary’
HTML-Äquivalent: aside — Ergänzender Inhalt
role=‘contentinfo’
HTML-Äquivalent: footer — Seitenfooter (top-level)
role=‘search’
HTML-Äquivalent: search — Suchbereich
Häufig gestellte Fragen
Muss ich ARIA auf jeder Website einsetzen?
Nein — auf Websites die ausschließlich semantisches HTML mit nativen interaktiven Elementen (button, a, input) verwenden, ist ARIA oft gar nicht nötig. ARIA wird wichtig für: komplexe UI-Komponenten (Tabs, Akkordeons, Modals, Carousels), dynamisch aktualisierte Inhalte, und Custom-Components die keine HTML-Entsprechung haben.
Was ist der Unterschied zwischen aria-label und aria-labelledby?
aria-label enthält den Namen als direkten String-Wert im Attribut. aria-labelledby verweist per ID-Referenz auf ein sichtbares Element das den Namen enthält. aria-labelledby ist vorzuziehen wenn der Name bereits sichtbar auf der Seite steht — das vermeidet Redundanz und Inkonsistenz.
Wie teste ich ob ARIA korrekt implementiert ist?
Mit einem echten Screenreader: NVDA (Windows, kostenlos), JAWS (Windows, kostenpflichtig) oder VoiceOver (macOS/iOS, eingebaut). Alternativ: axe DevTools findet viele ARIA-Fehler automatisch. Browser Accessibility Inspector (Chrome/Firefox DevTools) zeigt den Accessibility Tree — die Darstellung die Screenreader sehen.
Kann ARIA Barrierefreiheit verschlechtern?
Ja — das ist der wichtigste ARIA-Warnhinweis. Falsche ARIA-Rollen, vergessene State-Updates (aria-expanded nicht aktualisiert), aria-hidden auf fokussierbaren Elementen, oder aria-label das den sichtbaren Text widerspricht: all das verwirrt Screenreader-Nutzer aktiv. Lieber kein ARIA als falsches ARIA.