WAI-ARIA
Was ist WAI-ARIA?
WAI-ARIA ist eine technische Spezifikation zur Verbesserung der Barrierefreiheit von Webinhalten und Webanwendungen. Sie ergänzt HTML um Rollen, Eigenschaften und Zustände, damit Screenreader und andere assistive Technologien interaktive Elemente, dynamische Inhalte und komplexe Bedienoberflächen korrekt erkennen und verständlich ausgeben können.
WAI-ARIA steht für Web Accessibility Initiative Accessible Rich Internet Applications. Die vom World Wide Web Consortium entwickelte Spezifikation beschreibt zusätzliche HTML-Attribute, mit denen Entwickler die Bedeutung und den aktuellen Zustand einer Benutzeroberfläche an assistive Technologien übermitteln.
WAI-ARIA wird vor allem für Komponenten benötigt, deren Funktion aus dem normalen HTML-Code nicht eindeutig hervorgeht. Dazu gehören aufklappbare Menüs, Tabs, Dialogfenster, Schieberegler, automatisch aktualisierte Statusmeldungen und individuell programmierte Steuerelemente.
So funktioniert WAI-ARIA
Browser übertragen den HTML-Code einer Seite in einen sogenannten Accessibility Tree. Screenreader greifen auf diese strukturierte Darstellung zu und lesen daraus ab, welche Elemente vorhanden sind, wie sie heißen und welchen Zustand sie besitzen. WAI-ARIA ergänzt diesen Baum um Informationen, die im nativen HTML fehlen.
ARIA-Attribute beeinflussen weder das Aussehen noch die eigentliche Funktion eines Elements. Ein <div role='button'> sieht dadurch nicht wie ein Button aus und reagiert auch nicht automatisch auf Tastatureingaben. Entwickler müssen Design, Fokusführung und Bedienlogik zusätzlich korrekt programmieren.
aria-expanded='false' als geschlossen und nach dem Öffnen über aria-expanded='true' als geöffnet gekennzeichnet werden. Ein Screenreader kann dem Nutzer dadurch den aktuellen Zustand mitteilen, obwohl sich der sichtbare Inhalt dynamisch verändert. Rollen, Eigenschaften und Zustände
WAI-ARIA besteht im Kern aus Rollen, Eigenschaften und Zuständen. Diese drei Kategorien beschreiben gegenüber assistiven Technologien, welche Aufgabe ein Element erfüllt, welche zusätzlichen Informationen dazugehören und wie sich sein aktueller Zustand verändert.
| Kategorie | Funktion | Beispiele |
|---|---|---|
| Rollen | Definieren die Bedeutung eines Elements | role='button', role='dialog', role='navigation' |
| Eigenschaften | Ergänzen dauerhaft relevante Informationen | aria-label, aria-labelledby, aria-describedby |
| Zustände | Beschreiben veränderliche Werte einer Komponente | aria-expanded, aria-selected, aria-checked |
ARIA-Rollen erklären die Funktion
Eine ARIA-Rolle teilt dem Screenreader mit, was ein Element darstellt. Mögliche Rollen sind beispielsweise Button, Dialog, Registerkarte oder Navigation. Viele native HTML-Elemente besitzen diese Bedeutung bereits automatisch. Ein echtes <button> benötigt deshalb normalerweise kein zusätzliches role='button'.
ARIA-Eigenschaften liefern Kontext
Eigenschaften wie aria-label oder aria-labelledby geben einem Bedienelement einen zugänglichen Namen. aria-describedby verknüpft es dagegen mit einer ergänzenden Beschreibung, etwa einem Hilfetext oder einem Hinweis zu einem Formularfeld.
ARIA-Zustände melden Veränderungen
Zustände informieren darüber, ob eine Komponente geöffnet, ausgewählt, aktiviert oder markiert ist. JavaScript muss den Attributwert bei einer Änderung aktualisieren. Bleibt beispielsweise aria-expanded='false' nach dem Öffnen eines Menüs unverändert, erhält der Screenreader eine falsche Information.
Semantisches HTML hat Vorrang
Die wichtigste Grundregel lautet: Verwende ein passendes natives HTML-Element, bevor du eine Funktion mit ARIA nachbildest. Semantische Elemente wie <button>, <nav>, <input> und <dialog> bringen bereits eine definierte Bedeutung und häufig eine funktionierende Tastaturunterstützung mit.
Der Unterschied zwischen semantischem HTML und WAI-ARIA liegt im Aufgabenbereich. HTML definiert Inhalt, Struktur und grundlegendes Verhalten. WAI-ARIA ergänzt fehlende Informationen für assistive Technologien, wenn native Elemente eine komplexe Komponente nicht ausreichend beschreiben.
Eine Checkliste für barrierefreie Websites hilft dabei, WAI-ARIA gemeinsam mit Kontrasten, Alternativtexten, Formularbeschriftungen und Tastaturbedienung zu prüfen. ARIA allein macht eine Website nicht barrierefrei.
WAI-ARIA in der Praxis 2026
Typische Anwendungsfälle sind Navigationen mit Untermenüs, Akkordeons, Autovervollständigungen, Warenkorbmeldungen und modale Dialoge. Bei einem Dialog kennzeichnet role='dialog' die Komponente, aria-labelledby verweist auf ihre Überschrift und eine kontrollierte Fokusführung hält die Tastaturbedienung innerhalb des geöffneten Fensters.
Dynamische Meldungen lassen sich über ARIA Live Regions ankündigen. Mit aria-live='polite' kann ein Screenreader beispielsweise eine aktualisierte Trefferzahl oder die Meldung über ein hinzugefügtes Produkt ausgeben, ohne die aktuelle Sprachausgabe abrupt zu unterbrechen. Solche Live Regions eignen sich auch für Warenkorbaktualisierungen und Statusmeldungen.
aria-hidden='true' auf fokussierbaren Elementen. Jede Implementierung sollte deshalb mit Tastatur und Screenreader geprüft werden. WAI-ARIA testen und prüfen
Automatisierte Prüfwerkzeuge erkennen fehlende Namen, unzulässige Rollen und bestimmte Attributkonflikte. Ein vollständiger Test benötigt zusätzlich eine manuelle Tastaturprüfung und mindestens einen Screenreader-Test, weil Tools weder verständliche Beschriftungen noch eine sinnvolle Bedienreihenfolge zuverlässig bewerten können.
Technische Prüfungen sollten WAI-ARIA zusammen mit Überschriften, Formularen, Alternativtexten und internen Links betrachten. Der Leitfaden zur laufenden Kontrolle technischer Website-Fehler zeigt, wie solche Prüfungen in einen wiederkehrenden Qualitätssicherungsprozess eingebunden werden können.
Relevanz für SEO, SEA und GEO
WAI-ARIA ist kein eigenständiger Google-Rankingfaktor. Korrekte Semantik und zugängliche Bedienoberflächen erleichtern jedoch die Nutzung einer Website und reduzieren Hindernisse in Navigation, Formularen und Checkout-Prozessen. ARIA sollte daher als Bestandteil technischer Qualität betrachtet werden, nicht als Maßnahme zur direkten Rankingsteigerung.
Im SEA betrifft WAI-ARIA vor allem die Qualität der Landingpage. Wenn Schaltflächen, Formulare oder Produktfilter mit Tastatur und Screenreader nutzbar sind, können mehr Besucher die gewünschte Aktion abschließen. Ein ARIA-Attribut allein verbessert jedoch weder Anzeigenrang noch Conversion Rate.
Für GEO, die Generative Engine Optimization, und maschinelles Parsing bleibt sauberes semantisches HTML die verlässlichere Grundlage. ARIA-Landmarken können Strukturen ergänzen, richten sich aber primär an Accessibility-Schnittstellen. Überschriften, verständliche Texte und echte HTML-Elemente bleiben für Suchmaschinen und KI-Systeme zentral.
Bei neuen Projekten sollte Barrierefreiheit bereits in Konzeption, Design und Entwicklung eingeplant werden. Eine Website-Entwicklung mit technischer SEO-Basis kann semantisches HTML, zugängliche Komponenten und messbare Qualitätskontrollen von Beginn an zusammenführen.
Wenn du bestehende Komponenten, Formulare oder Navigationsstrukturen fachlich prüfen lassen möchtest, bietet ein Potenzialcheck eine erste Einordnung.
Häufige Fragen zu WAI-ARIA
Ersetzt WAI-ARIA semantisches HTML?
Nein. Passende native HTML-Elemente haben Vorrang, weil sie Bedeutung und häufig auch Tastaturverhalten bereits mitbringen. ARIA ergänzt nur Informationen, die mit HTML allein nicht ausreichend abgebildet werden.
Wann sollte ich aria-label verwenden?
aria-label eignet sich, wenn ein interaktives Element keinen sichtbaren Text besitzt, etwa ein Icon-Button. Gibt es bereits eine sichtbare Beschriftung, ist aria-labelledby häufig die bessere Wahl, weil sichtbarer und zugänglicher Name dadurch übereinstimmen.
Was ist der Unterschied zwischen role und aria-label?
Das role-Attribut beschreibt die Funktion eines Elements, beispielsweise Button oder Dialog. aria-label gibt dem Element einen zugänglichen Namen, damit der Screenreader mitteilen kann, welche konkrete Aktion oder Information gemeint ist.
Wann braucht eine Website aria-live?
aria-live wird benötigt, wenn sich relevante Inhalte ohne Seitenwechsel verändern und diese Änderung für Screenreader-Nutzer hörbar sein soll. Beispiele sind Statusmeldungen, Suchergebnisse, Warenkorbaktualisierungen und Formularfehler.
Kann falsches ARIA die Barrierefreiheit verschlechtern?
Ja. Falsche Rollen, unpassende Namen oder nicht aktualisierte Zustände können assistiven Technologien irreführende Informationen liefern. Unnötiges ARIA sollte deshalb entfernt und jede verbleibende Auszeichnung getestet werden.
Ist WAI-ARIA gesetzlich vorgeschrieben?
Gesetze und Standards verlangen in der Regel ein barrierefrei nutzbares Ergebnis, nicht pauschal bestimmte ARIA-Attribute. WAI-ARIA kann zur Erfüllung technischer Anforderungen beitragen, ersetzt aber weder eine WCAG-Prüfung noch eine rechtliche Bewertung.
Wie kann ich WAI-ARIA mit einem Screenreader testen?
Öffne die Website mit einem Screenreader und bediene sie vollständig per Tastatur. Prüfe dabei, ob Rollen, Namen, Zustände, Fehlermeldungen und dynamische Änderungen verständlich angesagt werden und der Fokus einer logischen Reihenfolge folgt.
Sie haben noch Fragen?
