ARIA: Accessible Rich Internet Applications

Was ist ARIA?

ARIA (Accessible Rich Internet Applications, auch WAI-ARIA geschrieben) ist eine W3C-Spezifikation mit HTML-Attributen, die assistiven Technologien mitteilen, was ein Element ist, in welchem Zustand es sich befindet und wie es mit anderen Elementen zusammenhängt. Sie ist für eigene Widgets gedacht, die reines HTML nicht beschreiben kann, etwa Tabs, Comboboxen und sich live aktualisierende Bereiche.

ARIA ändert nur, was assistive Technik erfährt. Es fügt kein Verhalten hinzu: Ein Element wird dadurch weder fokussierbar noch klickbar noch per Tastatur bedienbar. Dafür braucht es weiterhin HTML und JavaScript.

Rollen, Zustände und Eigenschaften

WAI-ARIA 1.2, die aktuelle W3C-Empfehlung, kennt drei Arten von Attributen:

• Rolle (Role): der Hauptindikator dafür, was ein Element ist, zum Beispiel role="tablist" oder role="dialog".
• Eigenschaft (Property): ein Merkmal des Elements, das sich selten ändert, etwa aria-label oder aria-controls.
• Zustand (State): ein Merkmal, das sich durch Nutzeraktionen oder Skripte ändert, etwa aria-expanded oder aria-checked.

Die Regeln für den Einsatz von ARIA

Die W3C-Hinweise "Using ARIA" nennen vier Regeln. Die erste wird am häufigsten gebrochen:

1. Zuerst natives HTML verwenden. Wenn ein Element oder Attribut die benötigte Semantik und das Verhalten schon mitbringt, nutzen Sie es, statt ARIA an ein anderes Element zu hängen.
2. Native Semantik nicht verändern, außer es lässt sich nicht vermeiden.
3. Alle interaktiven ARIA-Steuerelemente müssen per Tastatur bedienbar sein.
4. role="presentation" oder aria-hidden="true" nie auf fokussierbare Elemente setzen, sonst landen Nutzer auf etwas, das scheinbar nichts ist.

<!-- Native: no ARIA needed -->
<button type="button">Save</button>

<!-- Avoid: a div pretending to be a button -->
<div role="button" tabindex="0">Save</div>

Der native Button ist fokussierbar, reagiert auf Enter und Leertaste und wird ohne weiteren Aufwand korrekt angesagt. Beim div muss all das von Hand nachgebaut werden. Ein Screenreader sagt nur an, was das Markup ihm mitteilt.

Beispiel: ein Aufklapp-Button

Ein Button, der ein Panel ein- und ausblendet, ist ein Fall, in dem ARIA echten Mehrwert bringt, weil HTML allein nicht sagen kann, ob das Panel offen ist:

<button type="button" aria-expanded="false" aria-controls="faq-1">
  Shipping details
</button>
<div id="faq-1" hidden>Orders ship within two days.</div>

Ihr Skript muss aria-expanded auf true setzen, wenn es hidden entfernt, und beim Schließen zurück. Bei Steuerelementen, die nur ein Icon zeigen, braucht es einen Namen über aria-label:

<!-- Icon-only button: no visible text, so it needs a name -->
<button type="button" aria-label="Close dialog"><svg aria-hidden="true">...</svg></button>

Häufige Rollen und Live-Regionen

• dialog für modale Dialoge, tablist, tab und tabpanel für Tabs, combobox für Autovervollständigung.
• Landmarks wie navigation und main, die das native <nav> und <main> bereits mitbringen.
• aria-labelledby und aria-describedby, um auf sichtbaren Text zu verweisen, der ein Element benennt oder erklärt.
• aria-current="page", um den aktuellen Link in einer Navigation zu markieren.

Live-Regionen melden Änderungen, die der Nutzer nicht durch Fokuswechsel ausgelöst hat. role="status" ist höflich und wartet, bis die aktuelle Ausgabe fertig ist; role="alert" unterbricht sofort und gehört deshalb nur zu Fehlern, die sofortige Aufmerksamkeit brauchen.

<div role="status">Draft saved</div>
<div role="alert">Connection lost</div>

Häufige Fehler

• ARIA statt des richtigen Elements. Der häufigste Fehler: ein div mit Rolle, wo ein Button, Link oder Select genügt.
• Rollen ohne Tastaturunterstützung. Ein role="tab" ohne Pfeiltasten-Steuerung wird als Tab angesagt und verhält sich wie nichts.
• Veraltete Zustände. Bleibt aria-expanded="false" stehen, obwohl das Menü offen ist, sagt es das Gegenteil dessen, was Nutzer sehen.
• Fokussierbare Inhalte verstecken. aria-hidden="true" an einem Button oder Link lässt ihn per Tastatur erreichbar, aber stumm.
• Beschriftungen, die dem sichtbaren Text widersprechen. Steht auf dem Button "Suchen", sein aria-label lautet aber "Los", können Nutzer der Sprachsteuerung nicht aussprechen, was sie sehen. Siehe auch barrierefreie Formulare.
• Nie mit assistiver Technik testen. Gültiges Markup garantiert keine sinnvolle Ansage.

ARIA und Barrierefreiheitstests

ARIA ist ein Baustein, um die WCAG zu erfüllen, denn mehrere Erfolgskriterien setzen voraus, dass Elemente Name, Rolle und Wert bereitstellen. Automatische Tools finden ARIA-Fehler, die sich allein am Markup erkennen lassen: ungültige Rollenwerte, an einer Rolle nicht erlaubte Attribute oder aria-hidden auf fokussierbaren Elementen sind Teil des Lighthouse-Accessibility-Scores. Ob ein Widget funktioniert, können sie nicht beurteilen. Ergänzen Sie sie daher um Tastaturtests, einen Durchgang mit dem Screenreader und automatisierte Barrierefreiheitstests in der CI. Unser Vergleich von Tools für Barrierefreiheitstests (auf Englisch) zeigt die Optionen. Das Page-Speed-Monitoring von LoadFocus erfasst bei jedem Audit die Lighthouse-Kategorie Accessibility, sodass Sie den Score über die Zeit verfolgen können.

Häufige Fragen: ARIA

Was ist die erste Regel von ARIA?

Verwenden Sie ein natives HTML-Element oder -Attribut, das Semantik und Verhalten schon liefert, statt ein anderes Element umzufunktionieren und ARIA hinzuzufügen. Native Elemente bringen Tastaturbedienung und korrekte Ansagen von Haus aus mit.

Macht ARIA ein Element per Tastatur bedienbar?

Nein. ARIA ändert nur, wie ein Element assistiver Technik beschrieben wird. Fokus, Tastenbehandlung und Verhalten müssen weiterhin mit HTML und JavaScript gebaut werden.

Ist kein ARIA besser als schlechtes ARIA?

Oft ja. Falsche Rollen und veraltete Zustände können Nutzer schlechter stellen als schlichtes, korrektes HTML. Setzen Sie ARIA ein, wenn natives HTML das Widget nicht ausdrücken kann, und testen Sie es.

Was ist der Unterschied zwischen aria-label und aria-labelledby?

aria-label liefert den zugänglichen Namen als Textzeichenkette. aria-labelledby verweist auf die ID eines anderen Elements, dessen sichtbarer Text zum Namen wird. Bevorzugen Sie sichtbaren Text, wo möglich.

Wo finde ich getestete ARIA-Muster?

Der W3C ARIA Authoring Practices Guide (APG) beschreibt Entwurfsmuster für gängige Widgets, jeweils mit funktionierenden Beispielen. Folgen Sie einem Muster, statt Tastaturverhalten selbst zu erfinden.