Barrierefreie Buttons brauchen oft ARIA veröffentlicht in 2012zuletzt bearbeitet in 2021

Menu-Buttons

Eine Menü-Schaltfläche (menu button) ist eine Komponente, die eine Funktion mit Popup-Charakter anzeigt. Eine Menü-Schaltfläche darf nach Accessible Rich Internet Applications (ARIA) 1.1 nur solche Inhalte aufrufen, die einer der Rollen "menu", "listbox", "tree", "grid" oder "dialog" haben.

Eine Menü-Schaltfläche ruft eine Auswahlliste auf

Das aria-haspopup-Attribut

Wenn ein Button visuell anzeigt, dass die Aktivierung des Buttons ein Widget zur Webseite hinzufügen wird und den Inhalt der Webseite überlagern wird, muss diese Information auch für Screenreader und andere Hilfsmittel zugänglich gemacht werden. Das erfolgt mit einem aria-haspopup-Attribut für ein Element mit der Rolle "button". Der Wert des Attributs soll der Rolle des zu öffnenden Widgets entsprechen, d.h. der Wert von aria-haspopup kann "menu", "listbox", "tree", "grid" oder "dialog" annehmen. Darüber hinaus ist der Wert "true" gleichbedeutend mit "menu"; standardmäßig hat das Attribut den Wert "false".

Ein Menu-Button kann wie folgt aussehen:

Die Popup-Funktionalität bedeutet, dass ein komplexes Widget auf der gleichen Seite geöffnet und andere Inhalte der Webseite überlagern wird. Außerdem wird ein Fokus-Management impliziert, denn komplexe Widgets dürfen nur einmal in der Fokus-Reihenfolge stehen und die Bedienung per Tastatur muss z.B. per Pfeiltasten autorenseitig sichergestellt werden.

Das aria-haspopup-Attribut ist nicht geeignet beispielsweise, um Tooltips oder Links, die in einem neuen Fenster oder Tab aufgehen, "anzukündigen". Das Attribut sagt aus, dass aus einer normalen Schaltfläche eine Menü-Schaltfläche wird. Der Nutzer (eines Screenreaders) wird somit informiert, dass mit der Aktivierung der Schaltfläche Inhalte durch neue Inhalte überlagert werden und dass die neuen Inhalte per Pfeiltasten bedient werden müssen.

Unterstützung von aria-haspopup

Nach aktuellem Stand (Januar 2021) unterscheiden weder JAWS noch NVDA (die zwei gängigsten Screenreader auf Windows-Systemen) zwischen den Werten für das aria-haspopup-Attribut. Außer bei dem Wert "false" identifiziert JAWS alle Menu-Buttons als "Menüschalter" und NVDA als "Menüschaltfläche".

Was noch nicht ist, kann ja noch werden. Wenn die Aktivierung einer Schaltfläche beispielsweise ein Dialogfenster öffnet, kann die folgende Schreibweise verwendet werden:

Der Button im vorstehenden Code wird beispielsweise mit dem Screenreader NVDA derzeit noch als "Adressdaten eingeben Menüschaltfläche" identifiziert.

In diesem Beispiel wird die Popup-Funktionalität mit einem "↑" gekennzeichnet, was in einem Screenreader mit "Pfeil nach oben" übersetzt wird – wenn überhaupt. Um solche vielleicht unklare Symbole für Screenreader zu unterdrücken, wird das umfassende Element mit aria-hidden="true" vor dem Accessibility-Tree verborgen. Das aria-haspopup-Attribut ist bei der Vielzahl an möglichen Symbolen die konsistentere Variante, um den Überlagerungseffekt und ein Fokus-Management anzukündigen.

Ein anderes typisches Beispiel für eine Menü-Schaltfläche ist der sogenannte Hamburger Icon:

Bei einem solchen Button sollte der Wert "menu" oder "true" für das aria-haspopup-Attribut vergeben werden:

Der vorstehende Code wird beispielsweise mit dem Screenreader JAWS als "Navigation Menüschalter" identifiziert.

Aufbau im HTML

Damit eine Menü-Schaltfläche semantisch richtig aufbereitet wird, müssen folgende Punkte berücksichtigt werden:

1. Die Menü-Schaltfläche ist ein BUTTON-Element oder ein (vorzugsweise aktives) Element mit der Rolle "button".
2. Die Menü-Schaltfläche benötigt ein aria-haspopup-Attribut mit einem Wert, der die Rolle des einzublendenden Widgets entspricht.
3. Der Name für die Menü-Schaltfläche errechnet sich aus dem Text innerhalb des Elements mit der Rolle "button". Falls keine Beschriftung vorhanden ist, dann erhält das BUTTON-Element ein aria-label- oder aria-labelledby-Attribut, damit der Name berechnet werden kann, z.B.:

   <button aria-haspopup="true" aria-label="Navigation"></button>

4. Sollte es eine Beschreibung zu der Funktion der Menü-Schaltfläche geben, dann kann die Menü-Schaltfläche ein aria-describedby-Attribut mit der ID des Elements mit der Beschreibung erhalten:

   <button aria-haspopup="menu" aria-label="Navigation" aria-describedby="help"> </button>
<span id="help">
  Im Menü navigieren Sie mit Pfeiltasten, mit Enter wählen Sie aus, mit Esc brechen Sie ab und mit Tab übernehmen Sie die Auswahl ohne sie zu aktivieren.
</span>


   Diese Möglichkeit ist optional und nur dann sinnvoll, wenn eine Anweisung erforderlich ist.

ARIA bietet im Übrigen zahlreiche weitere Attribute, die in Einzelfällen auch für Menü-Schaltflächen genutzt werden können. Normalerweise sollten jedoch ARIA-Attribute nur dann eingesetzt werden, wenn es tatsächlich ein Problem gibt. Überflüssige ARIA-Attribute können die Barrierefreiheit einschränken oder ausschließen, wenn sie falsch eingesetzt werden.

Oft werden Menü-Schaltflächen beispielsweise mit einem aria-expanded-Attribut ergänzt, was überflüssig ist. Im nicht sichtbaren Zustand der einzublendenden Inhalte mag ein aria-expanded="false" für die Menü-Schaltfläche einleuchten, aber wenn der Inhalt eingeblendet wird, muss der Fokus in den eingeblendeten Inhalt gesetzt werden und in den meisten Fällen auch ein autorenseitiges Fokus-Management übernehmen. Wenn der Fokus wieder auf den Button steht, wird der eingeblendeter Inhalt wieder ausgeblendet und der Zustand der Menü-Schaltfläche ist wieder "nicht erweitert" – bei Fokus ist die Menü-Schaltfläche immer zugeklappt.

Fokus-Management

Menüs bestehen aus mindestens zwei seperaten Widgets:

1. Mit einem Menu-Button wird ein neues Layer mit der Rolle "menu" angekündigt und durch Aktivierung aufgerufen. Sofern ein BUTTON-Element verwendet wird, ist nur ein minimales autorenseitiges Fokus-Management für die Menü-Schaltfläche erforderlich.
2. Wird durch Aktivierung der Menü-Schaltfläche ein Widget mit der Rolle "menu", "listbox", "tree", "grid" oder "dialog" zur Webseite hinzugefügt, müssen Autoren das Fokus-Management für das Widget bereitstellen.

Im Folgenden steht die Menü-Schaltfläche im Fokus. Das Fokus-Management für die verschiedenen komplexen Widgets wird in den WAI-ARIA Authoring practices beschrieben und mit Beispielen ergänzt.

Sofern ein Button-Element für die Menü-Schaltfläche eingesetzt wird, ist kein besonderes Fokus-Management notwendig, denn alle Browser erlauben die Aktivierung eines BUTTON-Elements per Eingabe- und Leertaste. Die Aktivierung per Tastatur löst dabei den click-Event aus. Gleiches gilt für ein Link mit der Rolle "button":

Sollte die Rolle "button" für ein nicht aktives Element genutzt werden, dann müssen folgende Maßnahmen getroffen werden:

1. Das Element mit der Rolle "button" benötigt ein tabindex="0", damit es in der Fokus-Reihenfolge steht.

   <span role="button" tabindex="0" aria-haspopup="menu">
  Navigation
</span>

2. Es müssen Event-Handler (z.B. onkeypress oder onkeyup) für die Leertaste und die Eingabetaste berücksichtigt werden, um die damit verknüpfte Aktion auszulösen.

Für das Element mit der Rolle "button" müssen folgende Aktionen sowohl per Eingabe- als auch per Leertaste möglich sein, wenn der Fokus auf das Element steht:

1. Ist das Widget nicht sichtbar, dann wird es zur Webseite hinzugefügt.
2. Bei Menü-Schaltflächen muss der Fokus nach Aktivierung der Menü-Schaltfläche auf das erste oder ein als aktuelles Element markiertes Element des Widgets gesetzt werden.

Wenn das Widget zulässt, dass per Tab und Umschalt+Tab der Fokus auf aktive Elemente des verdeckten Inhalts gesetzt wird (was bis auf modale Dialogfenster der Normalfall ist), dann wird das Widget von der Webseite entfernt oder versteckt. Es ist daher wichtig, dass das Widget im HTML unmittelbar hinter der Menü-Schaltfläche steht: Mit Umschalt+Tab gelangt ein Nutzer direkt wieder zur Menü-Schaltfläche und das Widget wird geschlossen.