Was sind ARIA-Attribute? WAI-ARIA einfach erklärt

ARIA steht für Accessible Rich Internet Applications. Es ist ein Satz von HTML-Attributen, vom W3C als WAI-ARIA standardisiert (aktuelle Version 1.2, veröffentlicht im Juni 2023), der assistiven Technologien wie Screenreadern zusätzliche Informationen über Bedienelemente liefert. ARIA wird dort nötig, wo die Semantik von nativem HTML endet: bei einer Tab-Oberfläche, einem Akkordeon, einem selbstgebauten Dropdown oder einer Statusmeldung, die dynamisch erscheint. Das Vokabular besteht aus drei Bausteinen: Rollen beschreiben, was ein Element ist, Zustände beschreiben seine aktuelle Lage, und Eigenschaften beschreiben Merkmale und Beziehungen. ARIA ist mächtig und gefährlich zugleich. Richtig eingesetzt macht es komplexe Widgets für Screenreader-Nutzer bedienbar, falsch eingesetzt zerstört es Barrierefreiheit aktiv. Deshalb lautet die wichtigste Regel von ARIA, native HTML-Elemente immer dann vorzuziehen, wenn sie die Aufgabe erledigen können.

Wofür steht ARIA und warum gibt es das?

HTML bringt reichhaltige Semantik von Haus aus mit: Ein button wird als Schaltfläche angesagt, ein nav ist eine Navigation, eine angehakte Checkbox meldet ihren Zustand von selbst. Screenreader lesen all das aus dem Accessibility Tree, den der Browser aus Ihrem Markup aufbaut. Das Problem beginnt bei allem, wofür HTML kein Element hat. Es gibt kein natives Tab-Panel, kein Akkordeon, keine Toast-Benachrichtigung. Entwickler bauen das aus divs und spans, und für einen Screenreader-Nutzer ist ein div-basiertes Akkordeon einfach nur Stille: kein Name, keine Rolle, kein Zustand.

WAI-ARIA schließt genau diese Lücke. Damit teilen Sie assistiver Technik mit, was Ihr eigenes Widget ist und was es gerade tut, ohne dass sich für alle anderen am Aussehen oder Verhalten der Seite irgendetwas ändert.

Rollen, Zustände und Eigenschaften: die drei Bausteine von ARIA

• Rollen legen fest, was ein Element ist. role="dialog", role="tablist", role="alert". Eine Rolle ist ein Versprechen an den Nutzer: Dieses Ding wird sich wie ein Dialog verhalten.
• Zustände beschreiben die aktuelle, veränderliche Lage eines Elements. aria-expanded="true", aria-checked="false", aria-disabled="true". Zustände ändern sich während der Interaktion, und Ihr JavaScript muss sie synchron halten.
• Eigenschaften beschreiben Merkmale und Beziehungen, die sich selten ändern. aria-labelledby verweist auf das Element, das dieses hier benennt, aria-controls auf das Element, das dieses hier steuert, aria-required markiert ein Pflichtfeld.

Die Unterscheidung zwischen Zuständen und Eigenschaften ist im Alltag akademisch, beides sind schlicht Attribute. Das Denkmodell, auf das es ankommt: Die Rolle sagt, was es ist, alles andere sagt, wie es heißt, was es tut und wozu es gehört.

Die erste Regel von ARIA: Verwenden Sie kein ARIA

Das W3C-Dokument Using ARIA beginnt mit einer Regel, die wie ein Scherz klingt, aber vollkommen ernst gemeint ist: Wenn ein natives HTML-Element mit der Semantik und dem Verhalten, das Sie brauchen, bereits existiert, nehmen Sie dieses, statt ein anderes Element zweckzuentfremden und ARIA daraufzusetzen. Vergleichen Sie diese beiden Wege, einen Button zu bauen:

<!-- Sieht für sehende Nutzer wie ein Button aus, ist für alle anderen ein totes div -->
<div class="btn" onclick="save()">Speichern</div>

<!-- Alles inklusive: Rolle, Tastaturunterstützung, Fokus -->
<button type="button" onclick="save()">Speichern</button>

Um die div-Variante zu reparieren, bräuchten Sie role="button", tabindex="0" und zusätzliches JavaScript für Enter und Leertaste. Das native Element erledigt all das kostenlos und wird es auch in Browsern tun, die Sie nie getestet haben. Dieselbe Logik gilt für Links, Checkboxen, Formularfelder und Überschriften.

Hinter dieser Regel steht eine ernüchternde Zahl. WebAIM analysiert jedes Jahr die Startseiten der eine Million meistbesuchten Websites, und die Berichte finden regelmäßig, dass Seiten mit ARIA im Schnitt mehr erkannte Barrierefreiheitsfehler haben als Seiten ohne. Das liegt nicht daran, dass ARIA schlecht wäre, sondern daran, wie häufig es falsch angewendet wird. Kein ARIA ist besser als kaputtes ARIA.

Die wichtigsten ARIA-Attribute erklärt

• aria-label: gibt einem Element direkt seinen barrierefreien Namen. Der klassische Anwendungsfall ist ein Button, der nur aus einem Symbol besteht: aria-label="Schließen" auf dem X eines Modals.
• aria-labelledby: verweist auf die ID eines anderen Elements, dessen sichtbarer Text zum Namen wird. Gegenüber aria-label vorzuziehen, wenn ein sichtbares Label existiert, weil beide dann nicht auseinanderlaufen können.
• aria-describedby: verweist auf zusätzlichen beschreibenden Text, typischerweise einen Hinweis oder eine Fehlermeldung unter einem Formularfeld.
• aria-hidden="true": entfernt ein Element samt seiner Kindelemente aus dem Accessibility Tree. Richtig bei dekorativen Symbolen, gefährlich bei allem, was fokussierbar ist.
• aria-expanded: signalisiert am auslösenden Element, ob der gesteuerte Bereich offen oder geschlossen ist. Das Rückgrat von Akkordeons, Dropdown-Menüs und mobiler Navigation.
• aria-controls: verbindet ein auslösendes Element mit dem Element, das es steuert.
• aria-live: macht ein Element zu einer Live-Region, deren Inhaltsänderungen automatisch angesagt werden. polite wartet auf eine Pause, assertive unterbricht sofort und sollte wirklich dringenden Meldungen vorbehalten bleiben.
• aria-current: markiert das aktuelle Element einer Menge, zum Beispiel aria-current="page" auf dem aktiven Navigationslink.
• aria-required und aria-invalid: kommunizieren Pflichtfelder und Validierungsfehler in Formularen. Bei nativer HTML-Validierung deckt required allein den ersten Teil bereits ab.

Was sind ARIA-Landmark-Rollen?

Landmarks teilen eine Seite in benannte Bereiche, zwischen denen Screenreader-Nutzer direkt springen können, so wie sehende Nutzer ein Layout visuell überfliegen. Die gute Nachricht: Moderne HTML-Elemente erzeugen die meisten Landmarks implizit, in einem gut strukturierten Dokument schreiben Sie diese Rollen also selten von Hand.

• header ergibt die Landmark banner
• nav ergibt navigation
• main ergibt main, und davon sollte es genau eine pro Seite geben
• aside ergibt complementary
• footer ergibt contentinfo
• form und section werden zu den Landmarks form und region, sobald sie einen barrierefreien Namen haben

Eine Gewohnheit, die sich lohnt: Hat eine Seite zwei Navigationen, unterscheiden Sie diese mit aria-label="Hauptmenü" und aria-label="Fußzeilenmenü". Zweimal Navigation ohne jeden Unterschied zu hören, hilft niemandem.

Praktische ARIA-Beispiele: Akkordeon und Live-Region

Ein minimaler barrierefreier Akkordeon-Kopf zeigt, wie die Teile zusammenspielen. Der Button trägt den Zustand, das Panel wird per ID referenziert, und JavaScript schaltet beim Klick beides um:

<h3>
  <button aria-expanded="false" aria-controls="panel-shipping">
    Versand und Rückgabe
  </button>
</h3>
<div id="panel-shipping" hidden>
  <p>Wir versenden innerhalb von 2 bis 4 Werktagen...</p>
</div>

Und eine Live-Region für Rückmeldungen, die ohne Seitenneuladen erscheinen, etwa nach dem Legen in den Warenkorb oder nach einer gefilterten Suche:

<div aria-live="polite" class="visually-hidden" id="status"></div>

<script>
  document.getElementById('status').textContent = '12 Produkte gefunden'
</script>

Ohne die Live-Region filtert ein Screenreader-Nutzer eine Produktliste und hört überhaupt nichts. Mit ihr wird die Trefferzahl in dem Moment angesagt, in dem sie sich ändert. Kleines Attribut, großer Unterschied.

Häufige ARIA-Fehler, die Sie vermeiden sollten

• aria-hidden="true" auf fokussierbaren Elementen: Das Element verschwindet aus dem Accessibility Tree, bleibt aber in der Tabulator-Reihenfolge. Tastaturnutzer landen auf einem Geist. Das ist einer der häufigsten ARIA-Fehler überhaupt.
• Überflüssige Rollen: role="button" auf einem button oder role="navigation" auf einem nav erzeugt nur Rauschen und zeigt, dass das Markup nicht verstanden wurde.
• Rollen ohne Verhalten: role="tab" verspricht Navigation mit den Pfeiltasten. Liefert Ihr JavaScript das nicht, macht die Rolle die Sache schlimmer als gar keine Rolle, weil sie Erwartungen weckt, die das Widget nicht erfüllt.
• Veraltete Zustände: ein aria-expanded, das für immer auf false steht, weil es niemand im Klick-Handler aktualisiert. Screenreader-Nutzer hören zugeklappt, während sie auf ein offenes Panel starren.
• aria-label auf reinen Textelementen: Auf einem div oder span ohne Rolle wird aria-label von den meisten assistiven Technologien ignoriert. Es ist kein Allzweck-Tooltip.
• Zu viele assertive Live-Regionen: Wenn jede Warenkorb-Aktualisierung, jeder Cookie-Hinweis und jede Newsletter-Box den Nutzer unterbricht, gehen die wirklich wichtigen Ansagen unter.

ARIA in WordPress-Themes und -Plugins

Der WordPress-Kern steht ordentlich da: Der Navigations-Block verwaltet aria-expanded an den Untermenü-Schaltern, die CSS-Klasse screen-reader-text für visuell ausgeblendete Labels ist eine seit Langem etablierte Konvention, und die Formularkomponenten des Kerns bringen sinnvolle Attribute mit. Ärger macht meist das, was obendrauf installiert wird. Page Builder, Slider-Plugins, Mega-Menüs und Popup-Tools sind die Stellen, an denen sich div-Suppe mit fehlendem oder kaputtem ARIA auftürmt. Wenn Sie ein Theme bewerten, ist der Tag accessibility-ready im WordPress-Theme-Verzeichnis ein echtes Signal, denn diese Themes durchlaufen eine Prüfung gegen definierte Kriterien. Für alles andere dokumentiert der ARIA Authoring Practices Guide erprobte Muster für nahezu jedes Widget, das Sie je bauen werden, funktionierendes Tastaturverhalten inklusive.

Wie prüft InspectWP den Einsatz von ARIA?

InspectWP untersucht Ihre gerenderten Seiten im Rahmen der Barrierefreiheitsanalyse und meldet ARIA-Probleme, die sich automatisiert zuverlässig erkennen lassen: ungültige Rollennamen, ARIA-Attribute, die auf dem Element, an dem sie stehen, nicht erlaubt sind, Verweise auf IDs, die es nicht gibt, fokussierbare Elemente, die mit aria-hidden ausgeblendet wurden, und interaktive Elemente ohne barrierefreien Namen. Die Befunde sind nach Schweregrad gruppiert, damit ein fehlender Name in Ihrer Hauptnavigation vor einer überflüssigen Rolle in der Fußzeile landet. Weil am Ende das Verhalten des Screenreaders entscheidet, was funktioniert, betrachten Sie den Bericht als schnellen, wiederholbaren ersten Durchgang und prüfen Sie die kritischen Abläufe danach mit einem echten Screenreader nach.