Screenreader und die erste Regel von ARIA

Die erste Regel von ARIA lautet, es zu vermeiden: Wenn ein natives HTML-Element wie button die Aufgabe schon erledigt, nimm dieses, statt einem div eine Rolle zu geben.

Womit ein Screenreader arbeitet

Ein Screenreader liest keine Pixel. Der Browser baut aus dem HTML einen Barrierefreiheitsbaum (Accessibility Tree), eine vereinfachte Kopie der Seite, in der jedes relevante Element eine Rolle hat (Button, Link, Überschrift, Checkbox), einen Namen (den Text, der es kennzeichnet) und manchmal einen Zustand (angehakt, ausgeklappt, deaktiviert). Der Screenreader liest diesen Baum vor oder schickt ihn an eine Braillezeile. Das WCAG-2.2-Erfolgskriterium 4.1.2 Name, Rolle, Wert auf Stufe A verlangt, dass jedes Bedienelement der Seite diese drei Dinge bereitstellt.

Kaum jemand hört eine Seite von oben bis unten an. Die in die großen Betriebssysteme eingebauten Screenreader und kostenlose zum Installieren lassen Nutzer eine Liste der Überschriften, Links oder Landmarks aufrufen, zum nächsten Formularfeld springen oder Zeile für Zeile lesen. Deshalb sind die früheren Einheiten so wichtig: Echte Überschriften, beschriftete Felder, Buttons, die wirklich Buttons sind, und Alternativtext fließen direkt in diesen Baum. Auch das Attribut lang am html-Element zählt. Kriterium 3.1.1 Sprache der Seite verlangt es, und Screenreader wählen damit die richtige Stimme und Aussprache.

Was ARIA hinzufügt

WAI-ARIA (Accessible Rich Internet Applications) ist eine Reihe von Attributen, die ändern, was in den Barrierefreiheitsbaum kommt: role setzt die Rolle, Attribute wie aria-label setzen den Namen, und solche wie aria-checked oder aria-expanded setzen den Zustand. ARIA ändert nur, was angesagt wird. Es macht ein Element nicht fokussierbar, fügt kein Tastaturverhalten hinzu und ändert nicht, wie es aussieht. Der W3C-Leitfaden ARIA Authoring Practices bringt es in einer Überschrift auf den Punkt: „No ARIA is better than bad ARIA“ (kein ARIA ist besser als schlechtes ARIA). Falsches ARIA erzählt Screenreader-Nutzern etwas Falsches über die Seite.

Die Regeln für den Einsatz von ARIA

Das W3C-Dokument Using ARIA legt kurze Regeln fest, die überall zitiert werden (es wurde im Februar 2026 als eingestellter Entwurf gekennzeichnet, aber die Regeln selbst haben sich nicht geändert). Regel 1: Wenn du ein natives HTML-Element oder -Attribut verwenden kannst, das Bedeutung und Verhalten schon eingebaut hat, tu das, statt ein anderes Element mit ARIA umzufunktionieren. Regel 2: Native Semantik nicht ändern, außer es muss wirklich sein. Regel 3: Jedes interaktive ARIA-Bedienelement muss per Tastatur bedienbar sein. Regel 4: Kein role="presentation" und kein aria-hidden="true" an ein Element, das den Fokus bekommen kann, sonst landen manche Nutzer auf „nichts“.

Wo ARIA wirklich hilft, ist beim Füllen von Lücken, die HTML nicht schließen kann. Ein Button, der nur ein Icon enthält, hat keinen Text und damit keinen Namen; aria-label="Close" gibt ihm einen. Ein SVG-Icon neben sichtbarem Text ist Dekoration, und aria-hidden="true" am svg hält es aus dem Baum heraus. Das sind die beiden Attribute, die die meisten Anfänger brauchen. Für ganze Widgets wie Tabs oder Menüs folge dem passenden Muster im Authoring Practices Guide, statt selbst eines zu erfinden.