Was ist ARIA (WAI-ARIA)?

Kurz gesagt

Ein Screenreader liest die Seite mit den Informationen, die der Browser liefert. Für jedes Element hört er einen Namen, eine Rolle und bei Bedarf einen Zustand, etwa „Suchen, Schalter“. Wo HTML diese Information nicht selbst liefern kann, kommt ARIA ins Spiel.

Laut W3C ergänzt WAI-ARIA die eigene Semantik von HTML und ersetzt sie nicht. Gutes ARIA heißt deshalb oft wenig ARIA.

Rollen, Zustände und Eigenschaften

Die Rolle sagt, welche Art Element es ist, und wird mit dem Attribut role vergeben. role="dialog" beschreibt zum Beispiel ein Fenster, role="alert" eine Warnung.

Ein Zustand ist eine Information, die sich durch Interaktion ändern kann. Ein gedrückter Umschalter trägt aria-pressed="true", beim erneuten Drücken wird es false. Ändert sich der Zustand, ändert sich die Art des Elements nicht.

Eine Eigenschaft ist eine Information, die zum Wesen des Elements gehört, oder ein Datenwert. aria-label und aria-labelledby sind Eigenschaften. Auch der Standard räumt ein, dass beide Begriffe nah beieinander liegen; beides sind Attribute mit dem Präfix aria-.

Die erste Regel von ARIA

Die erste Regel aus der Notiz „Using ARIA“ des W3C kann ich so wiedergeben: Gibt es ein HTML-Element oder -Attribut, das die benötigte Semantik und das Verhalten schon eingebaut hat, nutzen Sie es. Versuchen Sie nicht, ein anderes Element mit einer ARIA-Rolle, einem Zustand oder einer Eigenschaft barrierefrei zu machen.

Das Dokument wurde am 24. Februar 2026 als „Discontinued Draft“ markiert. Die vier Regeln stehen als historische Aufzeichnung auf der Seite, und das W3C verweist auf den ARIA Authoring Practices Guide (APG). Auch die dritte Regel ist wichtig: Jedes interaktive ARIA-Steuerelement muss mit der Tastatur bedienbar sein.

Der Grund steht im APG: ARIA-Rollen fügen dem Browser kein Tastaturverhalten und kein Styling hinzu. Bei einem div mit role="button" bauen Sie Fokus, Enter und Leertaste selbst ein. Die Überschrift im APG fasst das zusammen: „No ARIA is better than Bad ARIA“.

Was ist aria-label?

aria-label ist die Eigenschaft, die einem Element einen Namen als Text gibt. Sie ist für Elemente ohne sichtbaren Text gedacht, etwa einen Suchbutton, der nur eine Lupe zeigt.

Steht der Name schon auf dem Screen, empfiehlt WAI-ARIA 1.2 einen anderen Weg: aria-labelledby, das auf diesen Text verweist. Gibt es beides, nimmt der Browser aria-labelledby. aria-label wiederum geht dem Text im Button vor; es überschreibt also den sichtbaren Text.

In welcher Reihenfolge der Name berechnet wird, legt das Dokument Accessible Name and Description Computation des W3C fest. Die eigenen Regeln für Namen von Bildern stehen im Ratgeber zum Alternativtext.

Häufige Fehler

aria-label im Widerspruch zum sichtbaren Text. Auf dem Button steht „Weiter“, der Name lautet „Zum nächsten Schritt“. Wer den Computer per Sprache steuert, sagt das Wort, das er sieht, und der Befehl passt vielleicht nicht. Das Kriterium 2.5.3 Label in Name der WCAG 2.2, Stufe A, verlangt, dass der Name den sichtbaren Text enthält. Das W3C empfiehlt als gute Praxis, den sichtbaren Text an den Anfang des Namens zu setzen.

Button aus einem div. Sieht aus wie ein Button, hat aber keine Rolle und bekommt mit Tab keinen Fokus. Die Lösung ist nicht, role hinzuzufügen, sondern <button> zu nutzen.

Ein Name, der die Rolle wiederholt. Der Name „Speichern-Button“ wird zusammen mit der Rolle als „Speichern-Button, Schalter“ vorgelesen.

aria-hidden auf einem fokussierbaren Element. aria-hidden="true" auf ein Element zu setzen, das den Fokus bekommt, verstößt gegen die vierte Regel von Using ARIA.

Der Bericht WebAIM Million 2026 fand mit Daten vom Februar 2026 auf 82,7 % von einer Million Startseiten ARIA. Landmark-Rollen sind in diesem Anteil nicht enthalten. Insgesamt wurden im Schnitt mehr als 133 ARIA-Attribute pro Seite gezählt.

Auf Seiten mit ARIA wurden im Schnitt 59,1 Fehler gefunden, auf Seiten ohne 42. Der Bericht schreibt, dass das nicht heißen muss, dass ARIA diese Fehler verursacht hat. Seiten mit ARIA waren zugleich komplexer.

Live-Beispiel: Was hört der Screenreader?

Die vier Elemente unten sind ausgedacht. Jedes hat eine schlechte und eine korrigierte Fassung.

Was hört der Screenreader?

Bei jedem Element sehen Sie Code, Rolle, zugänglichen Namen und ungefähr, was der Screenreader sagt.

1. 1 Button nur mit Icon

   Schlecht

   <button>
     <svg>…</svg>
   </button>

   Rolle

   Schalter

   Zugänglicher Name

   (leer)

   Fokus per Tastatur

   Ja, mit Tab

   Ungefähr zu hören

   „Schalter“

   Der Nutzer hört, dass es ein Schalter ist, erfährt aber nicht, was er tut.

   Korrigiert

   <button aria-label="Suchen">
     <svg aria-hidden="true">…</svg>
   </button>

   Rolle

   Schalter

   Zugänglicher Name

   Suchen

   Fokus per Tastatur

   Ja, mit Tab

   Ungefähr zu hören

   „Suchen, Schalter“

   Weil es keinen sichtbaren Text gibt, ist aria-label hier das richtige Werkzeug.

2. 2 Button aus einem div

   Schlecht

   In den Warenkorb

   <div class="button" onclick="add()">
     In den Warenkorb
   </div>

   Rolle

   keine (generisches Element)

   Zugänglicher Name

   (keiner)

   Fokus per Tastatur

   Nein

   Ungefähr zu hören

   „In den Warenkorb“ (wie einfacher Text)

   Der Fokus kommt mit Tab nicht hierher. Es funktioniert nicht mit der Tastatur, und der Screenreader stellt es nicht als Schalter vor.

   Korrigiert

   In den Warenkorb

   <button type="button" onclick="add()">
     In den Warenkorb
   </button>

   Rolle

   Schalter

   Zugänglicher Name

   In den Warenkorb

   Fokus per Tastatur

   Ja; funktioniert mit Enter und Leertaste

   Ungefähr zu hören

   „In den Warenkorb, Schalter“

   Rolle, Fokus und Tastaturverhalten liefert HTML selbst.

3. 3 Ein korrekter <button>

   Schlecht

   Speichern

   <button role="button"
     aria-label="Speichern-Button">Speichern</button>

   Rolle

   Schalter

   Zugänglicher Name

   Speichern-Button

   Fokus per Tastatur

   Ja, mit Tab

   Ungefähr zu hören

   „Speichern-Button, Schalter“

   Die Rolle war schon da. Das Wort „Button“ im Namen wird zusammen mit der Rolle doppelt vorgelesen.

   Korrigiert

   Speichern

   <button type="submit">Speichern</button>

   Rolle

   Schalter

   Zugänglicher Name

   Speichern

   Fokus per Tastatur

   Ja, mit Tab

   Ungefähr zu hören

   „Speichern, Schalter“

   Der Name kommt aus dem sichtbaren Text. ARIA braucht es gar nicht.

4. 4 aria-label im Widerspruch zum sichtbaren Text

   Schlecht

   Weiter

   <button aria-label="Zum nächsten Schritt">
     Weiter
   </button>

   Rolle

   Schalter

   Zugänglicher Name

   Zum nächsten Schritt

   Fokus per Tastatur

   Ja, mit Tab

   Ungefähr zu hören

   „Zum nächsten Schritt, Schalter“

   aria-label überschreibt den sichtbaren Text. Ein Sprachbefehl „Weiter“ passt vielleicht nicht.

   Korrigiert

   Weiter

   <button type="submit">Weiter</button>

   Rolle

   Schalter

   Zugänglicher Name

   Weiter

   Fokus per Tastatur

   Ja, mit Tab

   Ungefähr zu hören

   „Weiter, Schalter“

   Name und sichtbarer Text sind gleich. Auch der Sprachbefehl passt zu diesem Wort.

Vier ausgedachte Elemente. Rolle, Name und der gehörte Satz sind eine von Hand geschriebene Annäherung, nicht aus dem Browser gelesen. Die echte Ausgabe hängt von Screenreader, Browser und Sprache ab. Die Buttonbilder links sind nur Abbildungen, man kann sie nicht anklicken.

Um den echten Wert auf Ihrer eigenen Seite zu sehen, öffnen Sie in den Entwicklertools des Browsers das Panel zur Barrierefreiheit. Mögliche Tools finden Sie im Ratgeber zu Tools für Barrierefreiheitstests.

aria-live: Änderungen ankündigen

Ändert sich ein Teil der Seite, ohne dass sie neu lädt, bemerkt der Screenreader das vielleicht nicht von selbst. aria-live macht diesen Bereich zu einer Live-Region. Es gibt drei Werte:

• off: Standard. Ist der Fokus des Screenreaders nicht in diesem Bereich, wird die Änderung nicht vorgelesen.
• polite: Die Änderung wird bei der nächsten passenden Gelegenheit vorgelesen.
• assertive: Die Änderung wird sofort vorgelesen. Der Standard verlangt, das nicht zu nutzen, wenn die Unterbrechung nicht wirklich nötig ist.

Für eine Meldung wie „In den Warenkorb gelegt“ reicht polite. Auch die Statuszeile im Beispiel oben funktioniert so.

Meine Notiz

Wenn ich die Barrierefreiheit einer Oberfläche prüfe, fange ich beim HTML an. Ist das richtige Element gewählt, beschränkt sich der Bedarf an ARIA meist auf ein paar aria-label und eine Live-Region.

Jedem Button reflexhaft ein aria-label zu geben, halte ich für eine teure Gewohnheit. Der sichtbare Text ist schon der Name. Ein zweiter Name kann sich mit der Zeit von diesem Text entfernen. Alle Regeln finden Sie im WCAG-Ratgeber, die Prüfung Ihres eigenen Produkts auf der Seite zum UX Audit.