ARIA-Rollen und -Attribute: Beste Auswahl im Vergleich

Die ARIA-Rollen und -Attribute der W3C-Spezifikation WAI-ARIA 1.2 gehen in die Hunderte, obwohl eine Handvoll die meisten Barrierefreiheits-Probleme in XHTML- und CSS-Widgets löst. Eine Rolle definiert, was ein Element ist, und ein Attribut seinen Zustand oder seine Beziehungen, aber ARIA ändert nicht das Verhalten des Browsers: Jede hinzugefügte Rolle erfordert die Implementierung der Interaktion mit JavaScript.

Accessible Rich Internet Applications (ARIA) ist eine W3C-Spezifikation, die HTML-Elementen, die nativ keine Semantik besitzen, eine solche hinzufügt. Eine Rolle beschreibt, was ein Element ist (eine button, eine tab, ein dialog), während ein Attribut seinen Zustand oder seine Beziehungen beschreibt (aria-expanded, aria-controls, aria-labelledby). Die erste Regel von ARIA, die vom W3C in Using ARIA veröffentlicht wurde, ist deutlich: Wenn es ein natives HTML-Element gibt, das die Aufgabe bereits erledigt, verwenden Sie dieses und fügen Sie kein ARIA hinzu.

Der Grund dafür ist, dass ARIA das Browserverhalten nicht ändert. Ein <div role="button"> erhält keinen Fokus per Tab-Taste, reagiert nicht auf die Eingabetaste oder die Leertaste und wird nicht mit einem Formular abgesendet.

Es ändert nur, was die assistive Technologie ansagt. Die gesamte Interaktion muss mit JavaScript implementiert und sorgfältig verwaltet werden. In XHTML/CSS-Projekten, in denen das HTML statisch und das JS minimal ist, bedeutet dies, dass jede hinzugefügte ARIA-Rolle und jedes Attribut ein Versprechen ist, das Ihr Code einlösen muss.

Die zweite Regel von ARIA besagt, dass die native Semantik nicht geändert werden soll, es sei denn, es ist unumgänglich. Ein <h2 role="tab"> bricht die Struktur der Überschriften und verwirrt Screenreader, die nach Regionen navigieren.

Die dritte Regel erfordert, dass alle ARIA-Steuerelemente mit einer Tastatur bedienbar sind. Die vierte bittet darum, aria-hidden="true" nicht bei Elementen zu verwenden, die den Fokus erhalten. Die fünfte und am häufigsten vergessene Regel erinnert uns daran, dass jedes interaktive Element einen zugänglichen Namen benötigt: Eine Rolle ohne Beschriftung ist wie eine stumme Schaltfläche.

Verwandte: UserWay — Widget für den kostenlosen Zugang mit Plan, damit Sie noch heute dort arbeiten können.

Auswahl: Kriterien vor der Liste

Die Wahl einer Rolle oder eines Attributs ist keine Geschmackssache. Diese Kriterien, in dieser Reihenfolge angewendet, vermeiden die meisten Fehler bei ARIA-Rollen und -Attributen:

1. Gibt es ein natives HTML-Element? Wenn ja, verwenden Sie es. <button>, <details>, <dialog>, <input type="checkbox"> decken mehr Fälle ab, als man denkt.
2. Benötigt das Widget dynamische Zustände? Wenn es zwischen offen/geschlossen, ausgewählt/nicht ausgewählt oder erweitert/eingeklappt wechselt, benötigen Sie Zustandsattribute (aria-expanded, aria-selected, aria-pressed).
3. Werden Beziehungen zwischen Elementen benötigt? Beziehungsattribute (aria-controls, aria-labelledby, aria-describedby, aria-owns) verbinden Teile, die der Accessibility-Tree nicht aus dem DOM ableiten kann.
4. Sind Live-Ankündigungen erforderlich? Live-Regionen (aria-live, role="status", role="alert") lösen Aktualisierungen aus, ohne den Fokus zu verschieben.
5. Kann ich es warten? Ein komplexes ARIA-Muster ohne Tastatur- oder Screenreader-Tests ist schlimmer als gar nichts.

Die Wartungskosten sind das am meisten ignorierte Kriterium. Eine gut umgesetzte role="tablist" erfordert die Verwaltung der Pfeiltasten, einen rotierenden tabindex, die Synchronisation von aria-selected und aria-controls sowie das korrekte Ausblenden inaktiver Panels. Wenn das Team das nicht bewältigen kann, ist eine Reihe von Links mit Ankern zugänglicher und kostengünstiger.

Vergleich der nützlichsten ARIA-Rollen

Die folgende Tabelle fasst die Rollen zusammen, die in realen Audits immer wieder vorkommen, zusammen mit ihrem nativen Äquivalent (falls vorhanden) und der häufigsten Falle.

Einen Blick wert: AudioEye — Zugriffsmöglichkeit: Kombinierte Automatisierung mit menschlicher Revision.

Rolle	Zweck	Native Alternative	Häufige Falle
button	Steuerelement, das eine Aktion ausführt	<button>	Fehlende Behandlung von Enter/Leertaste oder tabindex="0"
link	Navigation zu einer anderen URL	<a href>	Verwendung für Aktionen, die nicht navigieren
dialog	Modales oder nicht-modales Fenster	<dialog>	Fokus nicht einfangen oder beim Schließen nicht zurückgeben
tablist / tab / tabpanel	Tab-Interface	Keine direkte	aria-selected nicht mit dem sichtbaren Panel synchronisieren
menu / menuitem	Anwendungsmenü	<select> oder Linkliste	Verwendung für Web-Navigationsmenüs
alert	Dringende und sofortige Nachricht	role="status" für nicht dringendes	Übermäßiger Gebrauch, was den Screenreader überlastet
status	Informative Aktualisierung	<output>	Nicht vor der Aktualisierung in das DOM einfügen
progressbar	Fortschritt einer Aufgabe	<progress>	aria-valuenow nicht aktualisieren
tooltip	Aufpoppende Beschreibung	title (begrenzt)	Nicht mit aria-describedby verknüpfen
combobox	Feld mit Vorschlagsliste	<datalist> (begrenzt)	Anzahl der Ergebnisse nicht ansagen

Die Wahl zwischen role="alert" und role="status" ist ein gutes Beispiel für eine Entscheidung mit Nuancen bei ARIA-Rollen und -Attributen. alert unterbricht das aktuelle Lesen des Screenreaders; status wartet, bis der Benutzer fertig ist. Für einen Formularvalidierungsfehler ist alert angemessen. Für „3 Ergebnisse gefunden“, während der Benutzer schreibt, ist status korrekt, während alert aufdringlich wirkt.

Unverzichtbare ARIA-Attribute und ihre Kombination

Die Attribute lassen sich in vier Familien einteilen, von denen jede ein unterschiedliches Problem löst.

Beschriftung. aria-label gibt einen Namen an, wenn kein sichtbarer Text vorhanden ist. aria-labelledby referenziert die id eines anderen Elements und ist vorzuziehen, wenn der Text bereits auf dem Bildschirm existiert, da so eine einzige Quelle der Wahrheit („single source of truth“) erhalten bleibt. aria-describedby fügt eine längere Beschreibung hinzu, wie etwa den Hilfetext eines Feldes. Der Unterschied ist wichtig: Der Name ist das, was der Benutzer beim Fokussieren hört; die Beschreibung ist ein zusätzlicher Kontext, der unterbrochen werden kann.

Zustände. aria-expanded (true/false) für Akkordeons und Dropdown-Menüs. aria-selected für Tabs und Optionen. aria-checked für benutzerdefinierte Checkboxen, mit dem Wert mixed für Drei-Zustands-Werte. aria-pressed für Toggle-Buttons. aria-disabled, wenn das Element zwar fokussierbar, aber nicht bedienbar ist, im Gegensatz zum nativen Attribut disabled, das es aus der Tab-Reihenfolge entfernt.

Beziehungen. aria-controls gibt an, welches Element eine Schaltfläche steuert. aria-owns reorganisiert den Accessibility-Tree, wenn das DOM die visuelle Beziehung nicht widerspiegelt. aria-activedescendant ermöglicht es, den Fokus auf einem Container zu behalten, während das aktive Element angesagt wird – ein gängiges Muster bei Comboboxen.

Live-Regionen. aria-live="polite" oder "assertive" definieren die Dringlichkeit. aria-atomic="true" bewirkt, dass der gesamte Block angesagt wird, anstatt nur der geänderte Teil. aria-relevant filtert, welche Änderungen angesagt werden.

Verwandte: IAAP CPACC / WAS Certification — Die professionelle Zertifizierung erfordert Erfahrung und Zugang.

Ein Detail, das oft übersehen wird: ARIA-Attribute funktionieren nur bei Elementen mit einer gültigen Rolle. aria-expanded an einem <div> ohne Rolle wird nicht angesagt. Zudem sind ARIA-Boolesche Werte Textzeichenfolgen ("true", "false") und keine JavaScript-Booleschen Werte; das Schreiben von aria-expanded="false" als boolesche Eigenschaft führt zu inkonsistenten Ergebnissen.

Fehler, die die Barrierefreiheit eines Widgets ruinieren

Der kostspieligste Fehler ist die Verwendung von ARIA, um ein schlecht strukturiertes HTML zu reparieren. Das Hinzufügen von role="navigation" zu einem <div>, wenn bereits ein <nav> verfügbar war, verdoppelt die Regionen und verwirrt die Navigation über Landmarks.

Der zweite Fehler betrifft den Fokus. Ein modales Widget, das den Fokus beim Öffnen nicht verschiebt, ihn während des Öffnens nicht einfängt und ihn beim Schließen nicht zum Auslöser zurückführt, lässt den Tastaturbenutzer durch unsichtbare Inhalte navigieren. Das native <dialog>-Element löst einen Teil davon, aber nicht alles: Die Rückgabe des Fokus liegt weiterhin in der Verantwortung des Entwicklers.

Wenn Sie einkaufen: accessiBe — Superposición de IA, das die WCAG seit 48 Stunden unterstützt.

Der dritte Fehler ist das Verstecken von Elementen mit aria-hidden, die weiterhin fokussierbar bleiben. Ein geschlossenes Menü mit aria-hidden="true", aber ohne display: none oder visibility: hidden, behält seine Links in der Tab-Reihenfolge, und der Benutzer fokussiert Elemente, die er nicht sehen kann. Die korrekte Kombination besteht darin, das Element gleichzeitig visuell und aus dem Accessibility-Tree zu entfernen.

Der vierte Fehler ist der fehlende zugängliche Name. Ein <button> mit nur einem SVG-Icon benötigt ein aria-label oder ein <span class="visually-hidden"> mit Text. Ein dekoratives SVG benötigt aria-hidden="true" und focusable="false", damit der Internet Explorer und einige ältere Browser es nicht in die Tab-Reihenfolge aufnehmen.

Tools zum Testen von ARIA-Rollen und -Attributen

Es gibt kein Tool, das das Testen mit einem echten Screenreader ersetzt, aber die Kombination verschiedener Tools erkennt die meisten Fehler bei ARIA-Rollen und -Attributen.

Statische Validierung. Der W3C ARIA-Validator (Teil des Nu HTML Checker) erkennt nicht existierende Rollen, falsch geschriebene Attribute und verbotene Kombinationen. axe DevTools und Lighthouse weisen auf Rollen ohne zugängliche Namen und fehlende obligatorische Attribute hin.

Inspektion des Accessibility-Trees. Die Chrome- und Firefox-DevTools ermöglichen es, den Accessibility-Tree genau so zu sehen, wie er von der assistiven Technologie empfangen wird. Dies ist der schnellste Weg, um zu prüfen, ob eine Rolle tatsächlich angewendet wurde und welchen zugänglichen Namen der Browser berechnet hat.

Manuelles Testen. Navigieren Sie das gesamte Widget nur mit der Tastatur (Tab, Shift+Tab, Pfeile, Enter, Leertaste, Escape) und anschließend mit NVDA unter Windows, JAWS (falls verfügbar) oder VoiceOver unter macOS und iOS. Die Kombination aus einem Desktop-Reader und einem mobilen Reader deckt die Mehrheit der realen Fälle ab.

Referenzdokumentation. Der ARIA Authoring Practices Guide (APG) des W3C enthält umfassende Muster mit Tastatur- und Codebeispielen. Dies ist die Quelle, die konsultiert werden sollte, bevor ein neues Muster erfunden wird.

Entscheidung in einem realen XHTML/CSS-Projekt

Auf XHTML-Seiten mit leichtem CSS und JavaScript ist die kosteneffizienteste Strategie, mit nativem HTML zu beginnen und ARIA nur dort hinzuzufügen, wo natives HTML nicht ausreicht. Ein Formular mit korrekten <label>, <fieldset> und <legend> benötigt sehr wenig ARIA. Eine Datentabelle mit <th scope> ebenfalls nicht. ARIA-Rollen kommen ins Spiel, wenn Muster auftreten, die HTML nicht abdeckt: Tabs, Akkordeons, Comboboxen mit Filterung, modale Dialoge und dynamische Benachrichtigungen.

Es ist ratsam, jede Verwendung von ARIA-Rollen und -Attributen im Code selbst mit einem Kommentar zu dokumentieren, der erklärt, warum sie dort ist. Wenn jemand die Komponente sechs Monate später refactored, weiß er, ob das aria-controls noch notwendig ist oder verwaist ist. Verwaiste ARIA-Attribute – die auf IDs verweisen, die nicht mehr existieren – sind eine stille Fehlerquelle, die kein Validator zuverlässig erkennt.

Behandeln Sie Barrierefreiheit schließlich als Teil der Definition von „Done“ der Komponente, nicht als nachträgliches Audit. Ein Widget mit ARIA-Rollen, das vom ersten Commit an mit Tastatur und Screenreader getestet wurde, kostet wesentlich weniger als eines, das nach dem Audit repariert werden muss.

Wichtige Erkenntnisse

• ARIA-Rollen und -Attribute fügen kein Verhalten hinzu: Eine Rolle ohne Tastatur- und Fokusmanagement ist schlimmer als gar nichts.
• Die erste Regel von ARIA ist, natives HTML zu verwenden, wann immer es existiert; <button>, <dialog> und <details> decken mehr Fälle ab, als man denkt.
• Attribute sind in Beschriftungen, Zustände, Beziehungen und Live-Regionen gruppiert; jede Familie löst ein anderes Problem.
• role="alert" unterbricht und role="status" wartet: Eine falsche Wahl überlastet den Screenreader-Benutzer.
• ARIA-Boolesche Werte sind Zeichenfolgen ("true"/"false"), und Attribute funktionieren nur bei Elementen mit einer gültigen Rolle.
• Das Testen mit einer Tastatur und einem echten Screenreader ist obligatorisch; Validatoren erkennen nur einen Teil der Fehler.

Quellen & Weiterführende Literatur

• WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) ist eine vom World Wide Web Consortium (W3C) veröffentlichte technische Spezifikation, die…

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer ARIA-Rolle und einem ARIA-Attribut?

Eine Rolle definiert für die assistive Technologie, was ein Element ist, z. B. role="tab" oder role="dialog". Ein Attribut beschreibt seinen Zustand oder seine Beziehungen, wie aria-expanded oder aria-labelledby. Rollen werden auf das Element angewendet, das die Komponente repräsentiert; Attribute werden normalerweise auf dasselbe Element oder auf damit verbundene Elemente angewendet.

Wann sollte ich ARIA anstelle von nativem HTML verwenden?

Nur wenn es kein HTML-Element gibt, das das Muster abdeckt. Die erste Regel von W3C ARIA ist explizit: Wenn es ein natives Element gibt, verwenden Sie es. ARIA-Rollen werden für Tabs, Akkordeons, Comboboxen mit Filterung und modale Dialoge sowie andere Muster benötigt, die HTML nicht allein implementieren kann.

Was bedeutet es, wenn ein Element einen zugänglichen Namen hat?

Ein zugänglicher Name ist der Text, den der Screenreader beim Fokussieren des Elements ansagt. Er wird aus dem Inhalt, aus aria-label, aus aria-labelledby oder aus einem zugehörigen <label> in einer durch die Spezifikation definierten Prioritätsreihenfolge berechnet. Eine interaktive Rolle ohne zugänglichen Namen ist ein Steuerelement, das der Benutzer nicht identifizieren kann.

Warum reagiert mein role="button" nicht auf die Tastatur?

Weil ARIA kein Verhalten hinzufügt. Ein <div role="button"> benötigt tabindex="0", um den Fokus zu erhalten, sowie keydown-Handler für Enter und Leertaste. Die einfachste und robusteste Lösung ist die Verwendung des nativen <button>-Elements, das bereits Fokus, Tastaturaktivierung und Formularübermittlung beinhaltet.

Ist die Verwendung von aria-hidden="true" schlecht?

Es ist richtig, dekorative oder doppelte Inhalte aus dem Accessibility-Tree auszublenden, aber dies sollte niemals auf Elemente angewendet werden, die den Fokus erhalten. Wenn ein fokussierbares Element mit aria-hidden="true" versehen bleibt, kann ein Tastaturbenutzer etwas fokussieren, das der Screenreader nicht ansagt. Kombinieren Sie dies immer mit einer tatsächlichen visuellen Ausblendung.

Welche Tools validieren ARIA-Rollen und -Attribute?

Der W3C Nu HTML Checker beinhaltet die Validierung von ARIA-Rollen und -Attributen und erkennt nicht existierende Rollen oder verbotene Kombinationen. axe DevTools und Lighthouse weisen auf Rollen ohne zugänglichen Namen und fehlende obligatorische Attribute hin. Um das Endergebnis zu überprüfen, zeigt der Accessibility-Tree-Inspektor in den Browser-DevTools genau an, was die assistiven Technologien erhalten.