Die erste Regel von ARIA

ARIA – Accessible Rich Internet Applications – ist ein Satz von Attributen, mit dem sich HTML um Bedeutung anreichern lässt: Rollen, Zustände, Eigenschaften. Es ist ein mächtiges Werkzeug, und genau darin liegt die Gefahr. Denn ARIA verändert, wie eine Seite von assistiver Technik interpretiert wird – aber nicht, wie sie sich verhält. Wer das verwechselt, baut sich Barrieren ein, die vorher nicht da waren.

Deshalb steht über allem ein Grundsatz, den ich für die wichtigste Faustregel der ganzen Barrierefreiheit halte: No ARIA is better than bad ARIA. Kein ARIA ist besser als falsches ARIA. Und die offizielle erste Regel von ARIA bringt es auf den Punkt.

Die Regel im Wortlaut

Wenn du ein natives HTML-Element oder -Attribut verwenden kannst, das die benötigte Semantik und das benötigte Verhalten bereits mitbringt, dann nutze es – statt ein Element zweckzuentfremden und ihm per ARIA eine Rolle hinzuzufügen.

Das ist keine Stilfrage, sondern hat einen handfesten technischen Grund: ARIA liefert keine Funktionalität. Es ändert nur die Beschriftung im Accessibility-Baum.

Warum das so entscheidend ist

Nimm den Klassiker, einen als Button zweckentfremdeten <div>:

<!-- Sagt „Schaltfläche", ist aber keine -->
<div role="button">Absenden</div>

role="button" sorgt dafür, dass ein Screenreader „Schaltfläche“ ansagt. Das war’s. Der <div> ist weiterhin nicht fokussierbar, reagiert nicht auf Enter oder Leertaste und ist mit der Tastatur nicht bedienbar. ARIA hat ein Versprechen gegeben, das das Element nicht hält – und das ist schlechter als gar keine Rolle, weil Nutzende nun eine Bedienbarkeit erwarten, die fehlt.

Um den <div> wirklich zu einem Button zu machen, müsste man tabindex="0" ergänzen und Tastatur-Handler für Enter und Leertaste schreiben. Drei Zutaten plus Skript – für etwas, das ein echtes <button> von Haus aus kann:

<!-- Sagt „Schaltfläche" UND verhält sich so -->
<button type="button">Absenden</button>

Diese eine Gegenüberstellung erklärt für mich die ganze Regel. Mehr dazu auf der Seite Buttons vs. Links.

Die fünf Regeln im Überblick

Die erste Regel ist die bekannteste, aber sie steht nicht allein. Die fünf Regeln von ARIA der WAI lauten sinngemäß:

1. Nutze natives HTML, wann immer es Semantik und Verhalten schon mitbringt.
2. Verändere native Semantik nicht ohne Not (kein role="heading" auf einem <button>).
3. Alle interaktiven ARIA-Bedienelemente müssen tastaturbedienbar sein.
4. Verstecke fokussierbare Elemente nicht mit role="presentation" oder aria-hidden="true" – sonst entstehen Fokus-Stopps ins Leere.
5. Jedes interaktive Element braucht einen zugänglichen Namen.

Drei von fünf Regeln drehen sich also um Tastatur, Fokus und Namen – also genau um das Verhalten, das ARIA eben nicht liefert. Das ist kein Zufall.

Wann ARIA wirklich gebraucht wird

ARIA abzulehnen wäre genauso falsch wie es zu überdosieren. Es gibt Muster, die HTML schlicht nicht nativ kennt – und dort ist ARIA unverzichtbar:

• Tabs: Es gibt kein natives Tabs-Element. Rollen und Zustände müssen von ARIA kommen.
• Live-Regionen: Dynamische Änderungen anzukündigen, kann HTML allein nicht.
• Zustände wie aria-expanded an einem Disclosure-Button, die das native Element nicht ausdrückt.
• Namen per aria-label/aria-labelledby, wo kein sichtbares Label möglich ist.

Mein Vorgehen ist deshalb immer dasselbe: erst schauen, ob ein natives Element passt. Wenn ja, nehme ich es. Wenn nein, ergänze ich so wenig ARIA wie nötig – und sorge dafür, dass Verhalten und Tastaturbedienung das Versprechen der Rolle auch einlösen. Genau diese Haltung zieht sich durch den ganzen Bereich barrierefreie Komponenten.

Häufige Fehler

• Rolle ohne Verhalten. role="button", role="tab" & Co. ohne Fokus und Tastatur-Handler.
• ARIA, wo HTML genügt. role="navigation" an einem <nav> oder role="list" an einem <ul> ist überflüssig – das Element sagt es schon.
• aria-hidden auf fokussierbaren Elementen. Erzeugt Fokus-Stopps auf Unsichtbarem.
• Native Semantik überschrieben. Ein echtes Element zur falschen Rolle erklärt – fast immer ein Rückschritt.
• Falsche Annahme, mehr ARIA sei mehr Barrierefreiheit. Eher das Gegenteil.

Häufige Fragen

Heißt das, ich soll ARIA möglichst meiden?

Meiden nicht – aber bewusst und sparsam einsetzen. Die Reihenfolge zählt: natives HTML zuerst, ARIA nur dort, wo es keine native Entsprechung gibt. Dann ist ARIA ein Segen.

Schadet ein überflüssiges role wirklich?

Bestenfalls ist es wirkungslos, schlimmstenfalls überschreibt es korrekte native Semantik. Da es nie hilft und manchmal schadet, lasse ich Redundantes konsequent weg.

Wo kann ich das gefahrlos lernen?

Am besten an echten Mustern. Der ARIA Authoring Practices Guide zeigt für viele Komponenten das korrekte Zusammenspiel von Rollen, Zuständen und Verhalten – und genau diese Dreiheit ist der Kern.

Fazit

Die erste Regel von ARIA ist im Grunde eine Erinnerung daran, dass semantisches HTML der Ausgangspunkt ist und ARIA die Ergänzung. ARIA beschreibt, es verhält sich nicht – Fokus, Tastatur und Namen musst du selbst sicherstellen. Wer zuerst zum nativen Element greift und ARIA nur dort einsetzt, wo HTML an seine Grenzen kommt, baut robuste, zugängliche Oberflächen mit dem wenigsten Code. Kein ARIA ist besser als schlechtes ARIA.