ARIA oder semantisches HTML.
Trägt semantisches HTML die Rolle eines Elements bereits, bringt zusätzliches ARIA keinen Gewinn; ARIA ist nur für das gedacht, was HTML nicht ausdrücken kann.
Die beiden Ansätze sind keine Konkurrenten, sondern eine Reihenfolge. Die erste Regel im W3C-Leitfaden zur ARIA-Nutzung lautet: Gibt es ein HTML-Element mit der passenden Bedeutung, verwenden Sie es und fügen Sie kein ARIA hinzu. ARIA ergänzt, es ersetzt nicht.
Warum ARIA kein Verhalten hinzufügt
Das ist der am häufigsten missverstandene Punkt. ARIA-Attribute schreiben nur Informationen in den Barrierefreiheitsbaum; den Browser veranlassen sie zu nichts. Einem div role="button" zu geben macht es nicht fokussierbar, lässt es nicht auf Enter reagieren und verhindert im deaktivierten Zustand keine Klicks. Alle drei müssen von Hand geschrieben werden — und alle drei werden häufig vergessen.
Ein echtes button-Element trägt dagegen all das von sich aus und verhält sich über Browserversionen hinweg gleich. Dieselbe Beziehung gilt für Listen, Überschriften, Navigation, Formularfelder und Tabellen. Was semantisches Markup ist steht getrennt geschrieben.
Wo ARIA wirklich nötig ist
Für manche Komponenten gibt es keine HTML-Entsprechung: Tab-Panel, Baumansicht, Kombinationsfeld, Schieberegler. Ohne ARIA lassen sie sich der Hilfstechnik nicht beschreiben, und die Autorenmuster des W3C wurden genau für diese Komponenten geschrieben.
Die zweite Gruppe sind Beziehungen. Zu welchem Feld ein Formularfehler gehört, der Name eines Bereichs, die Ansage von Inhalten, die sich ohne Seitenaufbau ändern — nichts davon hat eine HTML-Entsprechung. Auf dieser Website werden die Fehlermeldungen des Kontaktformulars als Live-Bereich angesagt, die Zuordnung zum Feld entsteht über aria-describedby. Das Formular als Ganzes ist getrennt beschrieben.
Der Maßstab: weder zu wenig noch zu viel
Die praktische Regel lautet: Wird das, was der Screenreader vorliest, ärmer, sobald man ein Attribut entfernt, dann ist es nötig; ändert sich nichts, ist es überflüssig und bringt nur Pflegeaufwand. Prüfwerkzeuge erkennen überschüssiges ARIA meist nicht — denn es ist technisch gültig, nur eben falsch. Die Grenzen automatischer Prüfung stehen getrennt geschrieben.
Kriterium
- Rolleninformation — Semantisches HTML: Kommt vom Element selbst — button, nav, main · ARIA: Wird von Hand per Attribut angegeben — role="button"
- Tastaturverhalten — Semantisches HTML: Liefert der Browser: Fokus, Enter, Leertaste · ARIA: Muss geschrieben werden — ARIA meldet nur, es fügt kein Verhalten hinzu
- Zustandsverwaltung — Semantisches HTML: Übernimmt der Browser (disabled, checked) · ARIA: Muss von Hand aktualisiert werden (aria-expanded, aria-checked)
- Fehlerrisiko — Semantisches HTML: Gering — das Verhalten ist eingebaut · ARIA: Hoch — eine falsche Rolle führt Hilfstechnik in die Irre
- Codeaufwand — Semantisches HTML: Nahezu null · ARIA: Eigener Aktualisierungscode für jeden Zustand
- Wann es nötig ist — Semantisches HTML: Überall dort, wo es eine Entsprechung gibt · ARIA: Bei Komponenten ohne HTML-Entsprechung — Tab-Panel, Baum, Kombinationsfeld
- Live-Aktualisierung — Semantisches HTML: Kein eigener Mechanismus · ARIA: Wird mit aria-live angesagt — in HTML nicht vorhanden
HÄUFIGE FRAGEN
Verbessert ARIA überall die Barrierefreiheit?
Nein, meistens verschlechtert es sie. Falsches oder überflüssiges ARIA sagt der Hilfstechnik, ein Element sei etwas anderes, als es tatsächlich ist; gar kein ARIA ist besser als das.
Wann wird ARIA gebraucht?
Wenn Sie eine Komponente bauen, für die HTML keine Entsprechung hat: Tab-Panel, Baumansicht, Kombinationsfeld, Live-Bereich. Und bei Beziehungen, die HTML nicht ausdrücken kann — etwa, zu welchem Feld ein Fehler gehört.
Ist role="button" dasselbe wie <button>?
Nein. role="button" meldet nur die Rolle; Fokussierbarkeit, die Reaktion auf Enter und Leertaste sowie der deaktivierte Zustand müssen von Hand geschrieben werden. <button> erhält all das vom Browser.