ARIA-Rollen: warum ein natives HTML-Element einem div mit Rolle überlegen ist

Worum es geht

ARIA (Accessible Rich Internet Applications) ist eine Sammlung von Rollen, Zuständen und Eigenschaften, die assistiven Technologien mitteilen, was ein Element ist und in welchem Zustand es sich befindet. Es verändert nur den Accessibility Tree: Es macht ein Element nicht fokussierbar, fügt kein Tastaturverhalten hinzu, validiert keine Eingaben und ändert nicht die Darstellung. Das W3C-Dokument Using ARIA (seit Februar 2026 ein eingestellter Entwurf, wegen seiner vier Regeln aber weitergeführt; die aktuelle Anleitung findet sich im ARIA Authoring Practices Guide) beginnt mit diesen Regeln. Die erste: Existiert ein natives HTML-Element oder -Attribut mit der benötigten Semantik und dem benötigten Verhalten, ist dieses zu verwenden, statt ein anderes Element zweckzuentfremden und ARIA hinzuzufügen. Die zweite: native Semantik nur ändern, wenn es wirklich nötig ist (das Beispiel ist <h2 role="tab">, was die Überschrift zerstört; die Lösung ist <div role="tab"><h2>…</h2></div>). Die dritte: Jedes interaktive ARIA-Steuerelement muss mit der Tastatur bedienbar sein. Die vierte: role="presentation" oder aria-hidden="true" nie auf ein fokussierbares Element setzen, weil Benutzerinnen und Benutzer dann auf "nichts" fokussieren.

Warum es wichtig ist

Ein <button> ist fokussierbar, aktiviert sich bei Enter und Leertaste, meldet seinen deaktivierten Zustand, funktioniert in Formularen und wird als Button angesagt – alles ohne zusätzlichen Code. Ein <div role="button"> erhält nur die Ansage; alles Übrige muss nachgebaut und bei jedem Refactoring korrekt gehalten werden. Die "Read Me First"-Seite des APG sagt es unverblümt: kein ARIA ist besser als schlechtes ARIA, weil falsche Rollen und Zustände Benutzerinnen und Benutzer, die auf sie angewiesen sind, aktiv in die Irre führen, während die visuelle Oberfläche für alle anderen einwandfrei aussieht.

So wird es angewendet

• Zuerst zum nativen Element greifen: button, a href, input, select, details/summary, dialog, fieldset/legend, table. Es stylen, statt es wegen seines Standardaussehens zu ersetzen.
• ARIA einsetzen, um Lücken zu füllen, für die HTML kein Element hat (Tab-Panels, Baumansichten, Comboboxes, Live-Regionen), und dabei dem passenden APG-Muster samt Tastaturinteraktion folgen.
• Zustandseigenschaften (aria-expanded, aria-selected, aria-current, aria-invalid) nur dort hinzufügen, wo sie auch per Skript aktualisiert werden; ein veralteter Zustand ist schlimmer als gar keiner.
• Wo möglich mit sichtbarem Text beschriften; aria-label überschreibt sichtbaren Text für Screenreader-Nutzende, und Nutzende von Sprachsteuerung können unter Umständen nicht sagen, was sie sehen.
• Das Ergebnis im Accessibility Tree des Browsers prüfen, nicht nur im DOM.

Stolpersteine

Redundante Rollen (<button role="button">) sind harmlos; role="menu" auf einer Navigationsliste ist es nicht, weil das APG-Menu-Muster eine Pfeiltasten-Navigation verspricht, die eine schlichte Liste von Links nicht bietet. aria-hidden="true" auf einem Container blendet dessen fokussierbare Nachfahren aus dem Baum aus, behält sie aber in der Tab-Reihenfolge; Using ARIA warnt ausdrücklich davor, es auf einen Vorfahren eines sichtbaren interaktiven Elements anzuwenden. Zustände und Eigenschaften, die eine Rolle nicht unterstützt, sind ungültig und können ignoriert werden.