ARIA-Rolle Button: Vollständiger und praktischer Leitfaden

Die ARIA-Rolle button ist eine ARIA-Rolle, die bewirkt, dass assistive Technologien einen generischen Container als Schaltfläche ankündigen, aber sie bietet kein Verhalten: Man muss tabindex="0" hinzufügen, die Tasten Enter und Leertaste handhaben und den Zustand mit aria-pressed oder aria-disabled widerspiegeln. Die WAI-ARIA 1.2 Spezifikation definiert diese Rolle innerhalb der Kategorie Widget, und die erste Regel von ARIA empfiehlt, immer dann ein natives <button>-Element zu verwenden, wenn dies möglich ist.

Die ARIA-Rolle button gehört zur Rollentaxonomie von WAI-ARIA, dem W3C-Standard, der zugängliche Semantik für Webinterfaces beschreibt. Wenn ein Element role="button" erhält, hört der von Screenreadern (NVDA, JAWS, VoiceOver, Narrator) erstellte Accessibility-Tree auf, es als generisches div oder span darzustellen, und präsentiert es als bedienbares Steuerelement. Der Unterschied ist für jemanden, der mit einem Screenreader navigiert, enorm: Ohne die Rolle hört der Nutzer „Gruppe“ oder einfach nur Text; mit der Rolle hört er „Schaltfläche“ und weiß, dass er sie aktivieren kann.

Die übliche Verwechslung besteht in der Annahme, dass role="button" ein div in eine funktionale Schaltfläche verwandelt. Das tut sie nicht. Die Rolle ändert nur die angekündigte Semantik; das Verhalten – den Fokus zu erhalten, auf die Tastatur zu reagieren, die Aktion auszulösen – bleibt in der Verantwortung des Entwicklers. Diese Trennung zwischen Semantik und Verhalten ist die Wurzel der meisten Fehler, die bei dieser Rolle gemacht werden.

WAI-ARIA wurde als W3C-Empfehlung veröffentlicht, und die Version 1.2 ist die aktuelle Referenz für Rollen, Zustände und Eigenschaften. Die Rolle button ist eine der ältesten und stabilsten Widget-Rollen der Spezifikation und ist seit ARIA 1.0 vorhanden.

Wann man role=“button” verwenden sollte und wann nicht

Die erste Regel von ARIA, die in den WAI-ARIA Authoring Practices festgehalten ist, ist eindeutig: Wenn es ein natives HTML-Element mit der Semantik und dem Verhalten gibt, das Sie benötigen, verwenden Sie dieses. <button> bringt die implizite Rolle, den Tastaturfokus, die Aktivierung mit Enter und Leertaste sowie den deaktivierten Zustand bereits mit. All dies mit der ARIA-Rolle role="button" neu zu implementieren, bedeutet Mehraufwand und ist eine Quelle für Bugs.

Es gibt jedoch legitime Szenarien für die Rolle. Am häufigsten ist dies der Fall, wenn das Markup durch das Framework oder das CMS vorgegeben ist und Sie kein <button> einfügen können, ohne das Layout oder das bestehende JavaScript zu beschädigen. Ein weiterer Fall sind Komponenten, die sich wie eine Schaltfläche verhalten müssen, deren interne Struktur jedoch einen spezifischen Container erfordert, wie etwa bestimmte Widgets von Drittanbietern.

Verwandte: UserWay — Widget für den kostenlosen Zugang mit Plan, damit Sie noch heute dort arbeiten können.

Ein drittes, diskutableres Szenario sind Elemente, die bereits eine andere native Rolle haben und als Schaltfläche dargestellt werden müssen. Hier sollte man sich fragen, ob das Design nicht eine falsche Semantik erzwingt. Wenn etwas wie eine Schaltfläche aussieht, aber in Wirklichkeit zu einer anderen Seite navigiert, ist ein Link <a> korrekt, keine Schaltfläche.

Situation	Empfohlene Lösung	Grund
Aktion in Formular oder Interface	natives <button>	Rolle, Fokus und Tastatur enthalten
Navigation zu einer anderen URL	<a href>	Korrekte Link-Semantik
Nicht modifizierbarer Container	role="button" + Tastatur + Zustände	Einziger Fall, in dem die Rolle nützlich ist
Kippschalter (on/off)	<button aria-pressed>	Zustand nativ exponiert
Deaktivierte Schaltfläche	<button disabled>	Zustand und Fokus verwaltet

Wie man eine Schaltfläche mit role=“button” korrekt implementiert

Eine auf role="button" basierende Schaltfläche muss vier Bereiche abdecken: Fokus, Tastatur, Zustand und zugänglicher Name. Das Weglassen eines dieser Punkte führt zu einem Steuerelement, das zwar zugänglich „scheint“, aber in realen Tests versagt.

Der Fokus wird mit tabindex="0" aktiviert, wodurch das Element in die natürliche Tabulator-Reihenfolge eingefügt wird. Verwenden Sie niemals tabindex mit positiven Werten: Diese verändern die Tabulator-Reihenfolge der gesamten Seite und erzeugen unvorhersehbare Sprünge. Der Wert 0 ist korrekt für benutzerdefinierte interaktive Elemente.

Einen Blick wert: AudioEye — Zugriffsmöglichkeit: Kombinierte Automatisierung mit menschlicher Revision.

Die Tastatur erfordert die Handhabung von zwei Tasten: Enter und Leertaste. Ein natives <button> reagiert auf beide, aber ein div mit einer ARIA-Schaltflächenrolle tut dies nicht von selbst. Man muss auf keydown hören und die Aktion ausführen, wenn die Taste Enter oder Space ist, und dabei das Scrollen der Seite verhindern, das die Leertaste standardmäßig auslöst. Dieses Detail wird häufig übersehen und führt zu Schaltflächen, die nur mit der Maus funktionieren.

Der Zustand wird über ARIA-Attribute kommuniziert. Eine Kippschaltfläche verwendet aria-pressed="true" oder "false", um anzuzeigen, ob sie aktiv ist. Eine deaktivierte Schaltfläche verwendet aria-disabled="true", was den Zustand ankündigt, aber die Interaktion nicht von selbst verhindert: Die Aktion muss im Code blockiert werden.

Der Unterschied zwischen aria-disabled und dem nativen Attribut disabled ist wichtig, da ersteres das Element fokussierbar hält, während letzteres es aus der Tabulator-Reihenfolge entfernt.

Der zugängliche Name wird aus dem sichtbaren Text des Elements erstellt oder, falls kein Text vorhanden ist, mit aria-label oder aria-labelledby. Eine Schaltfläche ohne zugänglichen Namen ist eine Schaltfläche, die der Screenreader einfach nur als „Schaltfläche“ ankündigt, ohne Hinweis darauf, was sie tut.

<div
  role="button"
  tabindex="0"
  aria-pressed="false"
  id="btn-modo"
>
  Dark Mode
</div>

<script>
  const btn = document.getElementById('btn-modo');
  function toggle() {
    const activo = btn.getAttribute('aria-pressed') === 'true';
    btn.setAttribute('aria-pressed', String(!activo));
  }
  btn.addEventListener('click', toggle);
  btn.addEventListener('keydown', (e) => {
    if (e.key === 'Enter' || e.key === ' ') {
      e.preventDefault();
      toggle();
    }
  });
</script>

Das obige Beispiel deckt Fokus, Tastatur, Zustand und Name ab. Dies ist das Minimum, damit das Steuerelement mit Screenreader und Tastatur bedienbar ist.

Häufige Fehler und wie man sie erkennt

Der weiteste verbreitete Fehler ist die Anwendung von role="button" ohne tabindex, was zu einer per Tastatur nicht erreichbaren Schaltfläche führt. Automatische Tools erkennen dies als „Element mit interaktiver Rolle, das nicht fokussierbar ist“, eine der am häufigsten gemeldeten Verstöße in Accessibility-Audits.

Verwandte: IAAP CPACC / WAS Certification — Die professionelle Zertifizierung erfordert Erfahrung und Zugang.

Der zweite Fehler ist die fehlende Tastatursteuerung. Ein div mit einer ARIA-Schaltflächenrolle und tabindex, aber ohne Tastatur-Handler, erhält zwar den Fokus, reagiert aber nicht auf Enter oder Leertaste. Der Tastaturnutzer bleibt stecken: Er kann die Schaltfläche fokussieren, aber nicht aktivieren.

Der dritte Fehler ist die Verwendung von role="button" auf einem Link. Dies bricht die Navigationssemantik und verwirrt Screenreader, die „Schaltfläche“ ankündigen, wenn der Benutzer einen Link erwartet. Wenn das Element navigiert, muss es ein Link sein.

Der vierte Fehler ist das Vergessen des Zustands bei Kippschaltflächen. Eine Schaltfläche, die zwischen zwei Modi wechselt, ohne aria-pressed, lässt den Benutzer im Unklaren darüber, in welchem Zustand sie sich befindet. Das Attribut ist der einzige Weg, diesen Zustand programmatisch zu kommunizieren.

Wenn Sie einkaufen: accessiBe — Superposición de IA, das die WCAG seit 48 Stunden unterstützt.

Um diese Probleme zu erkennen, weisen automatische Tools wie axe, Lighthouse oder WAVE auf Verstöße bei Rolle und Fokus hin, validieren aber nicht das Tastaturverhalten oder die Zustandslogik. Dieser Teil erfordert manuelle Tests: mit Tab navigieren, mit Enter und Leertaste aktivieren und die Ausgabe des Screenreaders anhören. Die Kombination aus automatischem Audit und manuellem Test ist der einzige zuverlässige Weg, eine benutzerdefinierte Schaltfläche zu validieren.

Wie man eine Schaltfläche mit role=“button” testet

Der Test beginnt mit der Tastatur. Navigieren Sie mit Tab durch die Seite und prüfen Sie, ob die Schaltfläche mit der ARIA-Rolle button einen sichtbaren Fokus erhält. Drücken Sie Enter und Leertaste separat: Beide müssen die Aktion auslösen. Wenn die Leertaste die Seite scrollt, anstatt die Schaltfläche zu aktivieren, fehlt das preventDefault.

Der zweite Test erfolgt mit einem Screenreader. NVDA unter Windows, VoiceOver unter macOS und Narrator unter Windows sind die am häufigsten verwendeten Referenzen. Beim Fokussieren der Schaltfläche muss der Reader die Rolle („Schaltfläche“), den zugänglichen Namen und den Zustand (falls vorhanden) ankündigen. Wenn er „Gruppe“ ankündigt oder den Zustand nicht erwähnt, stimmt etwas nicht.

Der dritte Test betrifft die Fokus-Reihenfolge. Die Schaltfläche muss in der logischen Tabulator-Reihenfolge erscheinen, weder vor noch nach der Stelle, an der sie visuell hingehört. Positive tabindex-Werte brechen diese Reihenfolge und sind ein klares Anzeichen für eine schlechte Implementierung.

Der vierte Test betrifft den Kontrast und den sichtbaren Fokus. Der Fokusindikator darf nicht mit outline: none entfernt werden, ohne ihn durch eine sichtbare Alternative zu ersetzen. Eine Schaltfläche, die den Fokus erhält, diesen aber nicht anzeigt, lässt den Tastaturnutzer ohne Referenz, wo er sich befindet.

Moderne Alternativen zur Rolle button

Das native <button>-Element ist auch 2024 und in jedem neuen Projekt die beste Option. Es bietet Rolle, Fokus, Tastatur und Zustände ohne zusätzlichen Code, und die Browser behandeln es konsistent.

Custom Elements oder Web Components bieten einen anderen Weg. Eine Komponente, die von HTMLElement erbt, kann das Schaltflächenverhalten kapseln und es mit der korrekten Semantik exponieren, obwohl sie den Fokus und die Tastatur genauso manuell verwalten muss wie bei role="button". Der Vorteil ist die Wiederverwendbarkeit; der Nachteil ist die gleiche Implementierungsverantwortung.

ARIA in HTML (Regeln, die definieren, welche ARIA-Rollen auf jedem HTML-Element erlaubt sind) raten davon ab, native Rollen zu überschreiben. Die ARIA-Rolle role="button" auf ein <button>-Element anzuwenden, ist redundant; sie auf ein <a> mit href anzuwenden, ist kontraproduktiv. Die allgemeine Empfehlung lautet, die Rolle für Container ohne eigene Semantik zu reservieren.

Wichtige Erkenntnisse

• role="button" ändert nur die angekündigte Semantik; Fokus, Tastatur und Zustand müssen manuell implementiert werden.
• Die erste Regel von ARIA empfiehlt die Verwendung von nativem <button>, wann immer das Markup dies zulässt.
• Eine Schaltfläche mit ARIA-Rolle button benötigt tabindex="0", die Handhabung von Enter und Leertaste, einen zugänglichen Namen und einen Zustand via aria-pressed oder aria-disabled.
• Automatische Tools erkennen fehlenden Fokus, aber Tastaturverhalten und Zustand erfordern manuelle Tests mit einem Screenreader.
• Verwenden Sie niemals einen positiven tabindex und wenden Sie role="button" nicht auf navigierende Links an.

Häufig gestellte Fragen

Was ist der Unterschied zwischen role=“button” und dem button-Element?

Das native <button>-Element enthält die implizite Rolle, den Tastaturfokus, die Aktivierung mit Enter und Leertaste sowie den deaktivierten Zustand ohne zusätzlichen Code. Das Attribut role="button" liefert nur die angekündigte Semantik; das restliche Verhalten muss programmiert werden. Deshalb empfiehlt die erste Regel von ARIA immer das native Element, wenn möglich.

Benötige ich tabindex bei role=“button”?

Ja. Ein div oder span mit role="button" ist standardmäßig nicht fokussierbar, daher bleibt es ohne tabindex="0" außerhalb der Tabulator-Reihenfolge und ist per Tastatur nicht erreichbar. Der korrekte Wert ist 0; positive Werte verändern die Tabulator-Reihenfolge der gesamten Seite und sollten vermieden werden.

Wie sorge ich dafür, dass ein div mit role=“button” auf Enter und Leertaste reagiert?

Man muss auf das keydown-Event hören und die Aktion ausführen, wenn die Taste Enter oder Space ist. Im Falle der Leertaste sollte preventDefault aufgerufen werden, um das Scrollen der Seite zu verhindern. Ohne diese Handler erhält die Schaltfläche zwar den Fokus, wird aber nicht per Tastatur aktiviert.

Wie zeige ich an, dass eine Schaltfläche aktiv oder deaktiviert ist?

Für eine Kippschaltfläche verwenden Sie aria-pressed="true" oder "false" je nach Zustand. Für eine deaktivierte Schaltfläche verwenden Sie aria-disabled="true", was den Zustand ankündigt, aber die Interaktion nicht von selbst blockiert: Die Aktion muss im Code verhindert werden. Das native Attribut disabled ist vorzuziehen, wenn ein <button> verwendet wird.

Ist es schlechte Praxis, role=“button” in einem Link zu verwenden?

Ja, wenn der Link zu einer anderen URL navigiert. Die Rolle eines <a href> mit role="button" zu überschreiben, bricht die Navigationssemantik und verwirrt Screenreader, die „Schaltfläche“ ankündigen, wenn der Benutzer einen Link erwartet. Wenn das Element navigiert, muss es seine Link-Rolle behalten.

Welche Tools erkennen Fehler bei role=“button”?

Automatische Tools wie axe, Lighthouse oder WAVE weisen auf Verstöße wie fehlenden Fokus bei Elementen mit interaktiver Rolle hin. Sie validieren jedoch nicht das Tastaturverhalten oder die Zustandslogik, daher kombiniert eine zuverlässige Überprüfung automatische Audits mit manuellen Tests unter Verwendung von NVDA, VoiceOver oder Narrator.