Barrierefreie Buttons brauchen oft ARIA
veröffentlicht in 2012zuletzt bearbeitet in
Überblendschaltflächen
Eine Überblendschaltfläche ist ein Steuerelement, das einen Inhalt als Overlay anzeigt. Eine Überblendschaltfläche darf nach Accessible Rich Internet Applications (ARIA) 1.2 nur solche Inhalte aufrufen, die einer der Rollen "menu", "listbox", "tree", "grid" oder "dialog" haben.
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 Assistenztechnologien 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".
Eine Überblendschaltfläche kann wie folgt aussehen:
<button aria-haspopup="true">
Beschriftung
</button>
Das Attribut informiert Nutzende von Screenreadern, dass die Aktivierung der Schaltfläche ein Overlay zur Seite hinzufügt und dass die aktuellen Inhalte im Hintergrund sein werden und vorübergehend nicht zugänglich sein werden. Bei den Overlays handelt es sich in der Regel um zusammengesetzte Widgets wie ein Menü oder um Dialogfenster, die im Prinzip alles enthalten können. Für zusammengesetzte Widgets wird ein Fokus-Management impliziert, denn zusammengesetzte 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".
Was aria-haspopup
eigentlich tut
Das aria-haspopup
-Attribut bewirkt, dass Screenreader ein Element mit zusätzlichem Text beschreiben. Statt das Element als "Schalter" wird das Element als "Schalter mit Popup" o.ä. identifiziert.
Wenn die Aktivierung einer Schaltfläche ein Dialogfenster öffnet, kann die folgende Schreibweise verwendet werden:
<button aria-haspopup="dialog">
Adressdaten eingeben
<span aria-hidden="true">↑</span>
</button>
<dialog id="foo"> ... </dialog>
Der Button wird beispielsweise mit dem Screenreader NVDA als "Adressdaten Schalter Dialogfeld öffnen" identifiziert. Im Screenreader JAWS wird die Überblendschaltfläche als "Adressdaten Schalter hat Popup Dialog" identifiziert.
In diesem Beispiel wird die Popup-Funktionalität mit einem "↑" gekennzeichnet, was in einem Screenreader mit "Pfeil nach oben" übersetzt werden könnte. Es gibt diverse Pfeile, die in Screenreadern alle individuell übersetzt werden. Um solche vielleicht uneindeutige 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 Überblendschaltfläche ist der sogenannte Hamburger Icon:
Bei einem solchen Button sollte der Wert "menu" oder "true" für das aria-haspopup
-Attribut vergeben werden:
<button aria-haspopup="menu">
<img src="hamburger-icon.svg" alt="Inhalte">
</button>
<div hidden role="menu" aria-modal="true"> ... </div>
Der vorstehende Code wird beispielsweise mit dem Screenreader JAWS als "Inhalte Menüschalter" identifiziert. Die folgende Tabelle zeigt, wie Screenreader Überblendschaltflächen abhängig vom Wert des aria-haspopup
-Attributs identifizieren.
Beispiel | JAWS/Chrome | NVDA/Firefox | VoiceOver/Safari |
---|---|---|---|
"Name des Elements" + "Menü Schalter" | "Name des Elements" + "Menü Schaltfläche Untermenü" | "Name des Elements" + "Einblendmenü" + "Taste" | |
"Name des Elements" + "Menü Schalter" | "Name des Elements" + "Schalter Untermenü" | "Name des Elements" + "Einblendmenü" + "Taste" | |
"Name des Elements" + "Schalter hat Popup Dialog" | "Name des Elements" + "Schalter Dialogfeld öffnen" | "Name des Elements" + "Einblendmenü" + "Dialog" + "Taste" | |
"Name des Elements" + "Schalter hat Popup Grid" | "Name des Elements" + "Schalter Gitter öffnen" | "Name des Elements" + "Einblendmenü" + "Raster" + "Taste" | |
"Name des Elements" + "Schalter hat Popup Listbox" | "Name des Elements" + "Schalter Liste öffnen" | "Name des Elements" + "Einblendmenü" + "Liste" + "Taste" |
Aufbau im HTML
Damit eine Überblendschaltfläche semantisch richtig aufbereitet wird, müssen folgende Punkte berücksichtigt werden:
- Die Überblendschaltfläche ist ein
button
-Element oder ein (vorzugsweise aktives) Element mit der Rolle "button". - Die Überblendschaltfläche benötigt ein
aria-haspopup
-Attribut mit einem Wert, der die Rolle des einzublendenden Widgets entspricht.
Hinweis: Dasaria-haspopup
-Attribut kann auf Elementemit verschiedenen Rollen angewandt werden.
- Der Name für die Überblendschaltfläche wird durch die Beschriftung des Elements mit der Rolle "button" bestimmt. Falls keine Beschriftung vorhanden ist, dann erhält das
button
-Element einaria-label
- oderaria-labelledby
-Attribut, z.B.:<button aria-haspopup="true" aria-label="Inhalte"></button>
- Sollte es eine Beschreibung zu der Funktion der Überblendschaltfläche geben, dann kann die Überblendschaltfläche ein
aria-describedby
-Attribut mit der ID des Elements mit der Beschreibung erhalten:<button aria-haspopup="menu" aria-label="Inhalte" 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 Überblendschaltflä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 Überblendschaltflächen beispielsweise mit einem aria-expanded
-Attribut ergänzt, was überflüssig ist. Ist das Overlay nicht sichtbar mag ein aria-expanded="false"
für die Überblendschaltfläche einleuchten, aber wenn das Overlay angezeigt wird, muss der Fokus in das Overlay gelegt werden. Wenn der Fokus aus dem Overlay entfernt wird, muss das Overlay ausgeblendet werden und die Überblendschaltfläche wäre (immer noch) mit aria-expanded="false"
gekennzeichnet.
Fokus-Management
In der Regel öffnen Überblendschaltflächen ein weiteres Widget. Mit einer Überblendschaltfläche wird ein Overlay mit der Rolle "menu", "listbox", "tree", "grid" oder "dialog" angekündigt und durch Aktivierung aufgerufen. Wenn ein Overlay geöffnet wird, müssen Autoren sicherstellen, dass der Fokus in das Overlay gesetzt wird. Bei dialog
-Elementen kümmert sich der Browser darum, wenn die showModal()
-Methode zusammen mit autofocus
eingesetzt wird. In anderen Fällen muss der Fokus (z.B. mit focus()
) in das Widget beziehungsweise Dialogfenster gesetzt werden.
Folgendes muss noch beachtet werden:
- Dialogfenster können alles mögliche enthalten – Texte, Formulare oder andere zusammengesetzte Widgets. Wenn es sich bei den Inhalten um Text oder Formularelemente handelt, muss kein besonderes Fokus-Management für das Dialogfenster berücksichtigt werden. Das Dialogfenster muss per Tastatur geschlossen werden können und bei Schließen des Dialogfensters sollte der Fokus dorthin zurückgebracht werden, wo er zuvor war, als das Dialogfenster aufgerufen wurde (falls möglich).
- Wird durch Aktivierung der Überblendschaltfläche ein Widget mit der Rolle "menu", "listbox", "tree" oder "grid" zur Webseite hinzugefügt, müssen Autoren das Fokus-Management für das Widget bereitstellen. Das Fokus-Management für die verschiedenen zusammengesetzten Widgets wird in den
ARIA Authoring Practices Guide beschrieben und mit Beispielen ergänzt. Insbesondere stehen Widgets immer genau einmal in der Fokus-Reihenfolge, d.h. bei Drücken von Tab oder Umschalt+Tab wird der Fokus zum vorherigen beziehungsweise zum nächsten aktiven Element der Seite gebracht und das Widget wird ausgeblendet. Das Fokus-Management umfasst dann insbesondere die Bedienung des Widgets mit Pfeiltasten.
Der Beitrag Barrierefreie Buttons brauchen oft ARIA besteht aus folgenden einzelnen Webseiten:
Umschaltflächen (Toggle-Buttons)
Wenn Buttons "gedrückt" oder "nicht gedrückt" aussehen, dann muss das
aria-pressed
-Attribut eingesetzt werden.Wechselschaltflächen (Switch-Buttons)
Wenn Buttons "aktiviert" oder "nicht aktiviert" aussehen, dann können Checkboxen oder Schaltflächen mit ARIA zu Wechselschaltflächen gemacht werden.
Einfache erweiternde bzw. reduzierende Schaltflächen (Disclosures)
Schaltflächen, die kürzere Inhalte ein- oder ausblenden, benötigen ein
aria-expanded
-Attribut.Akkordeons
Abschnittsüberschriften, die Inhalte ein- und ausblenden, benötigen ein
BUTTON
-Element mit einemaria-expanded
-Attribut.Überblendschaltflächen
(Aktuelle Seite)
Der folgende Begriff auf dieser Seite wird im Glossar definiert:Assistenztechnologien