ARIA.

ARIA ist eine Menge von Attributen, mit denen Rollen-, Zustands- und Eigenschaftsinformationen an Hilfstechnik gemeldet werden, wo HTML sie allein nicht ausdrücken kann.

ARIA ergänzt dort, wo semantisches HTML nicht ausreicht — es ersetzt es nicht. Diese Unterscheidung ist die wichtigste Regel zu ARIA, und wird sie missverstanden, ist das Ergebnis schlechter als gar kein ARIA.

Es meldet dreierlei. Die Rolle sagt, was ein Element ist — Tab, Dialog, Fortschrittsbalken. Der Zustand sagt, in welcher Lage es gerade ist — offen oder geschlossen, ausgewählt oder nicht, ungültig. Die Eigenschaft trägt unveränderliche Merkmale — welches Element es steuert, mit welchem Text es beschriftet ist.

Entscheidend ist: ARIA fügt kein Verhalten hinzu. Einem Element die Rolle „button“ zu geben macht es nicht tastaturbedienbar; es sagt dem Screenreader nur „das ist eine Schaltfläche“. Tastaturunterstützung, Fokussierbarkeit und Tastenverhalten müssen zusätzlich geschrieben werden. Deshalb ist ein echtes button-Element immer sicherer, als eine Schaltfläche mit ARIA nachzubilden.

Die erste Regel des WAI-ARIA-Leitfadens fasst das in einem Satz: Gibt es ein eingebautes HTML-Element, das die Aufgabe erfüllt, verwenden Sie es statt ARIA. Die zweite Regel weist in dieselbe Richtung — überschreiben Sie eingebaute Semantik nicht mit ARIA.

1. Eine falsche Rolle anzugeben ist schlechter, als keine anzugeben — dem Screenreader wurde eine Unwahrheit gesagt.
2. Ein visuell verborgenes Element nicht aus dem Barrierefreiheitsbaum zu nehmen lässt die Nutzerin durch unsichtbare Inhalte irren.
3. Ein Element zu verbergen und zugleich fokussierbar zu lassen erzeugt einen stummen Fokushalt.
4. Eine Beschriftung sowohl nativ als auch über ARIA zu vergeben erzeugt einen Konflikt; meist gewinnt ARIA, und die native Beschriftung verschwindet lautlos.

Der praktische Weg lautet: Wählen Sie zuerst das richtige HTML-Element, stellen Sie fest, dass das Verhalten vom Browser kostenlos mitkommt, und verwenden Sie ARIA nur für die verbleibende Lücke. Komponenten ohne HTML-Entsprechung — Tab-Gruppe, Akkordeon, eigenes Aufklappmenü — sind die Stellen, an denen ARIA wirklich nötig ist.

Häufig falsch eingesetzt wird ARIA beim Erzeugen des barrierefreien Namens. Erhält ein Element sowohl eine native als auch eine ARIA-Beschriftung, geraten beide in Konflikt, und meist gewinnt ARIA — die native Beschriftung verschwindet lautlos. Der sichtbare und der vorgelesene Text laufen auseinander, und wer Sprachsteuerung nutzt, kann das Element nicht auslösen, indem er die sichtbare Beschriftung ausspricht.

Als Regel gilt: Fragen Sie sich vor dem Hinzufügen von ARIA, ob sich diese Information nicht bereits aus dem HTML ableiten lässt. Lautet die Antwort ja, ist ARIA überflüssig — und es hinzuzufügen birgt ein Risiko.