Die erste Regel von ARIA

Die erste Regel von ARIA sagt: Wenn ein natives HTML-Element die gewünschte Semantik und das gewünschte Verhalten bereits mitbringt, nimm dieses Element – statt ein anderes zweckzuentfremden und ihm per ARIA eine Rolle zu verpassen. Der Grund dahinter ist technisch und nicht stilistisch: ARIA verändert nur, was assistive Technik meldet, nicht, was das Element tut.

ARIA – Accessible Rich Internet Applications – ist ein Satz von Attributen, mit dem sich HTML um Bedeutung anreichern lässt: Rollen, Zustände, Eigenschaften. Das ist ein mächtiges Werkzeug, und genau darin liegt die Gefahr. Wer Meldung und Verhalten verwechselt, baut Barrieren ein, die vorher nicht da waren – deshalb der Merksatz, den ich für die wichtigste Faustregel der ganzen Barrierefreiheit halte: No ARIA is better than bad ARIA.

Das Wichtigste in Kürze

• ARIA liefert keine Funktionalität. Es ändert Name, Rolle und Zustand im Accessibility-Baum – Fokus, Tastatur und Verhalten musst du selbst bauen.
• Die Regel ist eine Reihenfolge, kein Verbot: erst natives HTML, dann so wenig ARIA wie nötig.
• Stand Februar 2026 belegt der WebAIM-Million-Report den Effekt: Startseiten mit ARIA hatten im Schnitt 59,1 erkannte Fehler, Seiten ohne ARIA 42,0 – bei einer ARIA-Verbreitung von 82,7 %.
• Eine Rolle ohne Verhalten ist schlechter als keine Rolle, weil sie eine Bedienbarkeit ankündigt, die es nicht gibt.
• Drei der fünf ARIA-Regeln drehen sich um Tastatur, Fokus und Namen – also genau um das, was ARIA nicht mitliefert.
• Es gibt echte ARIA-Fälle: Tabs, Live-Regionen, Comboboxen, Zustände wie aria-expanded und Namen per aria-label, wo kein sichtbares Label möglich ist.
• Eine bekannte Ausnahme bestätigt die Regel: Listen mit list-style: none verlieren in Safari ihre Semantik – hier ist das redundante role="list" nötig.

Die Regel im Wortlaut

Die W3C-Empfehlung Using ARIA formuliert sie so:

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 eine ARIA-Rolle, einen Zustand oder eine Eigenschaft hinzuzufügen, um es zugänglich zu machen.

Das Entscheidende steht in der Mitte: Semantik und Verhalten. Ein natives Element bringt beides, ARIA nur das Erste.

Was ARIA ändert – und was nicht

Der Screenreader liest vor, was im Accessibility-Baum steht. Er prüft nicht nach, ob das Element das Versprechen einlöst. Genau darum kann ARIA aktiv schaden: Es macht aus „gar nicht angekündigt“ ein „falsch angekündigt“, und das ist die unangenehmere Variante, weil sie Erwartungen weckt.

Der WebAIM-Million-Report vom Februar 2026 misst diesen Effekt seit Jahren: Startseiten mit ARIA-Attributen hatten im Schnitt 59,1 erkannte Fehler, Startseiten ohne ARIA 42,0. Das ist kein Beweis dafür, dass ARIA Fehler verursacht – komplexe Seiten nutzen mehr ARIA und haben mehr Fehler. Aber es widerlegt zuverlässig die Annahme, mehr ARIA bedeute mehr Barrierefreiheit.

Für alles außerhalb der assistiven Technik gilt das noch schärfer: Suchmaschinen-Crawler und Sprachmodelle werten ARIA praktisch nicht aus. Ein <div role="navigation"> ist für sie ein div; ein <nav> ist eine Navigation. Wer Struktur nativ auszeichnet, bedient beide Seiten mit derselben Zeile – der Zusammenhang steht unter Semantik & SEO.

div gegen button: die Rechnung

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. Was fehlt, zeigt der direkte Vergleich:

Um den <div> wirklich zu einem Button zu machen, bräuchte es tabindex="0", einen keydown-Handler für Enter und Leertaste, aria-disabled samt Klickblockade – und selbst dann sendet er kein Formular ab und fällt ohne JavaScript komplett aus. Für etwas, das ein <button> von Haus aus kann:

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

Diese Gegenüberstellung erklärt für mich die ganze Regel. Welches Element wann richtig ist, vertieft Buttons vs. Links.

Die fünf Regeln von ARIA

Die erste Regel ist die bekannteste, aber sie steht nicht allein. Die fünf Regeln der Web Accessibility Initiative sinngemäß, jeweils mit dem Fall, in dem sie gebrochen wird:

1. Natives HTML zuerst. Gebrochen bei <div role="button">, <span role="link">, <div role="heading" aria-level="2">.
2. Native Semantik nicht ohne Not überschreiben. Gebrochen bei <h2 role="tab"> oder einem <button role="heading"> – das Element verliert, was es vorher konnte.
3. Alle interaktiven ARIA-Bedienelemente müssen tastaturbedienbar sein. Gebrochen bei jedem Custom-Control, das nur auf click reagiert.
4. Keine fokussierbaren Elemente verstecken. Gebrochen bei aria-hidden="true" oder role="presentation" auf einem Link – der Fokus landet dann auf etwas, das der Screenreader nicht kennt, und es wird schlicht „leer“ angesagt.
5. Jedes interaktive Element braucht einen zugänglichen Namen. Gebrochen bei jedem Icon-Button ohne Beschriftung.

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

Wann ARIA nötig ist

ARIA abzulehnen wäre so falsch, wie es zu überdosieren. Ich würd die Regel deshalb nicht als Verbot lesen, sondern als Reihenfolge. Es gibt Muster, die HTML nativ nicht kennt:

• Tabs: Ein Tabs-Element gibt es nicht. Rollen, Zustände und die Pfeiltastensteuerung müssen von Hand kommen.
• Live-Regionen: Dynamische Änderungen anzukündigen, kann HTML allein nicht.
• Zustände wie aria-expanded an einem Aufklapp-Button – das native Element drückt den Zustand nicht aus.
• Namen per aria-label oder aria-labelledby, wo kein sichtbares Label möglich ist.
• Beziehungen per aria-describedby, etwa zwischen Feld und Fehlermeldung.

Zwei Dinge sind dabei wichtiger, als sie klingen. Erstens: aria-label wirkt nur auf Elementen, deren Rolle einen Namen zulässt. An einem <div> oder <span> ohne Rolle verpufft es folgenlos – ein Fehler, den kein Werkzeug meldet, weil syntaktisch nichts falsch ist. Zweitens: Ein vertipptes ARIA-Attribut (aria-labeledby mit einem l) scheitert stillschweigend. HTML meldet keinen Fehler, der Browser ignoriert es, und im Test fällt es nur auf, wenn jemand tatsächlich zuhört.

Die Ausnahme, die die Regel bestätigt

Es gibt einen Fall, in dem ein scheinbar redundantes role nötig ist. Safari entfernt die Listensemantik, sobald eine Liste per CSS mit list-style: none gestaltet wird – aus „Liste mit 6 Einträgen“ wird ein stummer Textblock. Betroffen ist damit fast jede Navigation und jede Kartenübersicht.

<!-- Listensemantik bleibt auch in Safari erhalten -->
<ul role="list" class="karten">
  <li>…</li>
</ul>

Das ist ARIA, das nichts Neues sagt – und trotzdem richtig, weil es eine Browser-Eigenheit ausgleicht. Solche Fälle sind selten, aber sie zeigen, worum es der Regel geht: nicht um ARIA-Vermeidung als Selbstzweck, sondern darum, dass am Ende stimmt, was ankommt. Mehr zu sauberen Listen steht bei Listen richtig nutzen.

Der teuerste Fehlgriff: die Menü-Rollen

Ein Muster begegnet mir in fast jedem Audit: die Hauptnavigation mit role="menubar" und role="menuitem". Der Gedanke ist naheliegend – es ist ja ein Menü. Nur meint ARIA damit etwas anderes: ein Anwendungsmenü wie in einem Desktop-Programm, mit Pfeiltastensteuerung, Escape zum Schließen und genau einem Tabstopp für die ganze Leiste.

<!-- Weckt Erwartungen, die die Navigation nicht erfüllt -->
<ul role="menubar">
  <li role="none"><a role="menuitem" href="/leistungen.html">Leistungen</a></li>
</ul>

Wer das ansagt, ohne die Tastatursteuerung nachzubauen, macht eine funktionierende Navigation kaputt: Der Screenreader kündigt ein Menü an, die Pfeiltasten tun nichts, und die Links sind plötzlich keine Links mehr. Eine Seitennavigation braucht diese Rollen nicht – ein <nav> mit einer Liste aus Links reicht vollkommen. Wie ein Aufklappmenü stattdessen aufgebaut wird, steht bei Menüs und Dropdowns.

So prüfst du dein ARIA

1. Tab-Taste durch die Seite. Jedes Element, das eine interaktive Rolle ansagt, muss erreichbar sein – und jeder Fokus-Stopp muss etwas sein, das man bedienen kann.
2. Enter und Leertaste auf jedem Bedienelement. Was sich als Schaltfläche ausgibt, muss auf beide reagieren.
3. Accessibility-Baum ansehen. In den Chrome-Entwicklerwerkzeugen unter „Elements → Accessibility“ prüfen, ob Name, Rolle und Zustand dem entsprechen, was das Element wirklich tut.
4. Jedes role einzeln begründen. Wenn dir für ein Attribut kein Grund einfällt, ist es überflüssig – dann raus damit.
5. Mit dem Screenreader gegenhören. Der Abgleich zwischen Ansage und Verhalten passiert nur hier, siehe Mit NVDA testen.

Häufige Fehler

• Rolle ohne Verhalten. role="button", role="tab" und Co. ohne Fokus und Tastatursteuerung.
• ARIA, wo HTML genügt. role="navigation" an einem <nav> oder role="button" an einem <button> ist überflüssig.
• aria-hidden auf fokussierbaren Elementen. Erzeugt Fokus-Stopps auf etwas, das der Screenreader nicht kennt.
• Native Semantik überschrieben. Ein echtes Element zur falschen Rolle erklärt – fast immer ein Rückschritt.
• aria-label an Elementen ohne Rolle. Wirkungslos, aber im Code sichtbar – und damit ein falsches Sicherheitsgefühl.
• Vertippte Attribute. Werden stillschweigend ignoriert.
• aria-label überschreibt sichtbaren Text. Dann findet die Sprachsteuerung das Element nicht mehr, siehe 2.5.3 Beschriftung im Namen.

Häufige Fragen

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

Meiden nicht – bewusst einsetzen. Die Reihenfolge zählt: erst prüfen, ob ein natives Element passt, dann so wenig ARIA ergänzen wie nötig. Für Tabs, Comboboxen oder Live-Regionen führt kein Weg daran vorbei, und dort ist ARIA ein Segen.

Schadet ein überflüssiges role wirklich?

Bestenfalls ist es wirkungslos, schlimmstenfalls überschreibt es korrekte native Semantik. Da es fast nie hilft und manchmal schadet, lasse ich Redundantes konsequent weg – mit der Ausnahme von role="list" bei Listen ohne Aufzählungszeichen, die in Safari sonst ihre Semantik verlieren.

Warum ist ein div mit role="button" so verbreitet?

Weil es funktioniert, solange man mit der Maus testet. Der <div> sieht aus wie ein Button, reagiert auf Klicks und sagt sogar das Richtige an. Auffällig wird der Fehler erst mit der Tastatur oder dem Screenreader – und genau deshalb überlebt er so lange in Projekten.

Welche Rolle darf auf welches Element?

Das regelt die Spezifikation „ARIA in HTML“. Nicht jede Kombination ist erlaubt: Ein role auf einem <a> ohne href ist etwas anderes als auf einem Link mit Ziel, und manche Elemente erlauben gar keine Rollenänderung. Der HTML-Validator meldet unzulässige Kombinationen inzwischen mit, siehe HTML validieren.

Gilt die Regel auch für Landmarks?

Ja. <nav>, <main>, <header> und <footer> bringen ihre Landmark-Rolle selbst mit; ein zusätzliches role="navigation" ist reine Doppelung. Nur wo kein passendes Element existiert – etwa für role="search" in älteren Browsern – war ARIA nötig. Inzwischen gibt es dafür das Element <search>.

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.

Praktisch heißt das: zuerst zum nativen Element greifen, ARIA nur dort einsetzen, wo HTML an seine Grenzen kommt, und jedes Attribut begründen können. Wer so vorgeht, baut robuste Oberflächen mit dem wenigsten Code – und läuft nicht in die Falle, die der WebAIM-Report Jahr für Jahr misst. Kein ARIA ist besser als schlechtes ARIA.

Quellen

• Using ARIA (W3C – Wortlaut der fünf Regeln, darunter „First Rule of ARIA Use“)
• The WebAIM Million 2026 (WebAIM – 82,7 % ARIA-Verbreitung, 59,1 gegenüber 42,0 erkannten Fehlern)