Buttons, Buttons, Buttons  

Semantische Auszeichnung von Schaltflächen mit ARIA-Attributen

Ein Haufen Knöpfe in unterschiedlichen Farben und Größen

Buttons (oder: Schaltflächen) werden in Webanwendungen vielfältig eingesetzt. Es gibt verschiedene Arten von Buttons. Toggle- und Switch-Buttons stellen eine An/Aus-Funktionalität dar, es gibt Buttons zum erweitern von Inhalten und natürlich Buttons, die eine Popup-Funktionalität bewirken. Accessible Rich Internet Applications (ARIA) definiert verschiedene Attribute, um diese Unterschiede semantisch auszuzeichnen und in Screenreadern unterscheidbar zu machen.

Abgrenzung zwischen Buttons und Links

Zunächst müssen Buttons von Links abgegrenzt werden. Der entscheidende Unterschied zwischen einem Button und einem Link ist, dass Links generell eine neue Ressource aufrufen und Buttons eine Aktion auf der gleichen Seite ausführen – zumindest kann das als Erwartungshaltung der Nutzer angenommen werden. Darüber hinaus bieten Buttons (außerhalb von Formularen) keine eigene Funktionalität und müssen mit JavaScript ergänzt werden während Links JavaScript nicht voraussetzen. Zu dieser allgemeinen Abgrenzung gibt es zwei Ausnahmen:

  • Links können auch als Sprunglink innerhalb einer Webseite genutzt werden, d.h. sie rufen dann keine neue Ressource auf.
  • Buttons des Typs „submit“ innerhalb eines Formulars senden das Formular ab und können dann selbstverständlich eine neue Ressource aufrufen. Sowohl Buttons des Types „submit“ als auch des Typs „reset“ erfordern dabei kein JavaScript.

Im folgenden Beitrag geht es nicht um Buttons, die Formulare abschicken oder zurücksetzen, sondern um Widgets der Form
<button onclick="meinEventHandler();"> ... </button>.

Abgrenzung zwischen Buttons und Formularelementen

Oft werden Checkboxen, Radio-Buttons oder Select-Boxen als Widgets genutzt, d.h. während der Bearbeitung oder bei Aktivierung der Steuerelemente lösen Event-Handler JavaScript-Funktionen aus. Vor dem Hintergrund der Barrierefreiheit sollten aber Formularelemente stets statischer Natur sein. Formularelemente wie die zuvor genannten müssen bearbeitet und erst durch Drücken der Eingabe- oder Leertaste (und natürlich durch Mausklick) aktiviert werden. Wie problematisch die Dynamisierung von typischerweise statischen Steuerelementen sein kann, erläutert der Beitrag Lass‘ mich erst fertig machen.

Das heißt nicht, dass beispielsweise eine Checkbox keine dynamischen Aktionen auslösen darf. In diesem Fall benötigt die Checkbox lediglich die Rolle „switch“, um in einem Screenreader nicht mehr als Checkbox, sondern als Switch-Button identifiziert zu werden. Dass dabei der Widget-Charakter der Checkbox auch visualisiert werden sollte, steht außer Frage.

Typen von Buttons

Buttons können vielfältig eingesetzt werden. Welche Buttons auf Webseiten eingesetzt und wie sie barrierefrei aufbereitet werden, kann wie folgt charakterisiert werden:

  1. In Formularen werden Submit-Buttons und Reset-Buttons eingesetzt. Die Aktivierung solcher Buttons schickt Formularangaben an ein Skript ab oder setzt das Formular auf seinen ursprünglichen Zustand zurück:
    <button>Speichern</button>
    oder
    <button type="submit">Speichern</button>
    sowie
    <button type="reset">Zurücksetzen</button>
  2. Innerhalb eines Formulars können weitere Buttons als Widgets eingesetzt werden, die weder das Abschicken noch das Zurücksetzen des Formulars bewirken. Damit sie nicht als Submit-Button behandelt werden, können sie wie folgt ausgezeichnet werden:
    <button type="button" onclick="meineFunktionen();">Name meiner Funktion</button>
    Das type="button" bewirkt, dass das Formular bei Aktivierung des Buttons nicht versehentlich abgeschickt wird.
  3. Außerhalb von Formularen ist das type-Attribut nicht mehr erforderlich. Buttons außerhalb von Formularen sehen zunächst wie folgt aus:
    <button onclick="meineFunktionen();">Beschriftung</button>
    Die Funktionalität wird per JavaScript bereit gestellt. Buttons können immer gleich aussehen, aber der Zustand eines Buttons wird oft durch Pfeile und andere Symbole visuell vermittelt. Je nach Aussehen und Funktionalität des Buttons kann es sich um folgende Widgets handeln:

    • Buttons werden oft als Umschaltflächen (Toggle-Buttons) oder Wechselschaltflächen (Switch-Buttons) eingesetzt, die eine An/Aus-Situation darstellen. Generell gibt es drei Typen solcher Buttons:
      1. Eine Umschaltfläche visualisiert einen gedrückten oder nicht gedrückten Zustand.
        Verschiedene Konfektionsgrößen Schalter 44 ist gedrückt
        Semantisch wird der Zustand mit dem aria-pressed-Attribut vermittelt:
        <button aria-pressed="true" onclick="meineFunktionen();">Option</button>

        Diese Auszeichnung mit aria-pressed bewirkt in einem Screenreader eine Identifizierung wie „Schalter Option gedrückt“ oder „Schalter Option nicht gedrückt“.
      2. Eine Wechselschaltfläche ist eine Spezialform der Umschaltfläche, die meist der Funktionsweise von Checkboxen ähnelt:
        Filterfunktion bei einem Fernsehprogramm. 2 Schalter sind ausgewählt.
        Wechselschaltflächen sind oft an Häkchen oder anderen Glyphen erkennbar. Statt „gedrückt“ oder „nicht gedrückt“ vermitteln sie eher die Zustände „aktiviert“ oder „nicht aktiviert“:
        <button role="switch" aria-checked="true" onclick="meineFunktionen();">Option</button>
        Ein Screenreader wird einen solchen Button z.B. mit „Umschalter Option an“ oder „Umschalter Option aus“ identifizieren.
      3. Die dritte Grundform einer Umschaltfläche wird mittels Text angezeigt und benötigt kein ARIA. Wenn beispielsweise in einem Multimedia-Player das Drücken des Play-Buttons bewirkt, dass anschließend ein Pause-Button anstelle des Play-Buttons angezeigt wird:
        Gegenüberstellung: Ein Play-Icon wird zum Pause-Icon
        Dann wird der Zustand des Buttons durch den Namen des Buttons vermittelt:
        <button onclick="meineFunktionen();"><img alt="Pause" src="pause.svg"></button> bzw.
        <button onclick="meineFunktionen();"><img alt="Abspielen" src="play.svg"></button>
        Nicht nur sollte aria-pressed in diesem dritten Fall nicht eingesetzt werden, sondern es gehört hier absolut nicht hin!
    • Buttons werden auch genutzt, um Inhalte zu erweitern oder zu reduzieren:
      1. Erweiternde bzw. reduzierende Schaltflächen sollten für kurze Texte genutzt werden. Der Code kann wie folgt aussehen:
        <button aria-expanded="false" onclick="meineFunktionen();">Thema</button>
        Das könnte in einem Screenreader wie „Schalter Thema reduziert“ bzw. „Schalter Thema erweitert“ identifiziert werden.
      2. Bei Abschnitten einer Webseite, die mit einer interaktiven Überschrift eingeleitet werden, die den Abschnitt erweitert oder reduziert, ist das Design-Pattern eines Akkordeons zu bevorzugen:
        <h2><button aria-expanded="true" id="ref" onclick="meineFunktionen();">Überschrift </button></h2>

        <section aria-labelledby="ref"> … Erweiterbarer bzw. reduzierbarer Inhalt … </section>

        Bei Akkordeons ist zu beachten, dass der erweiterbare Abschnitt hier mit dem aria-labelledby-Attribut durch die Beschriftung des Buttons bezeichnet wird.
    • Schließlich gibt es Überblendschaltflächen. Überblendschaltflächen fügen immer Inhalte zu einer Seite hinzu und überlagern den zuvor sichtbaren Inhalt. Überblendschaltflächen dürfen nur eingesetzt werden, wenn bestimmte Widgets wie ein Menü oder ein Dialogfenster zur Seite hinzugefügt werden. Die Widgets haben dabei immer ein Fokus-Management (Bedienung per Pfeiltasten) und wenn sie den Fokus verlieren, werden sie ausgeblendet. Eine Überblendschaltfläche wird durch das aria-haspopup-Attribut gekennzeichnet:
      <button aria-haspopup="menu" onclick="meineFunktionen();">Navigation</button>

      Ein solcher Button könnte in einem Screenreader als „Menüschalter Navigation“ identifiziert werden. Damit werden Screenreadernutzer informiert, dass die Aktivierung des Buttons ein neuer Inhalt die bisherigen Inhalte überblendet und dass die Bedienung per Tastatur auf die überlagernden Inhalte beschränkt sein wird.
      Das aria-haspopup-Attribut darf verschiedene Werte haben. Der Wert „true“ ist identisch mit dem Wert „menu“. Andere zulässige Werte sind „listbox“ (Listenfeld), „dialog“ (Dialogfenster), „grid“ (Rastertabelle) und „tree“ (Baumstruktur). Wenn eine Überblendschaltfläche also ein modales Dialogfenster öffnet, könnte der HTML-Code wie folgt aussehen:
      <button aria-haspopup="dialog" onclick="meineFunktionen();">Daten bearbeiten</button>
      <div hidden role="dialog" aria-modal="true">
      <h1>Daten bearbeiten</h1>

      </div>

ARIA-Attribute verändern nur die Semantik

Die Semantik im Code ist der erste Schritt bei der Gestaltung barrierefreier Komponenten. Natürlich fehlen in diesen Beispielen sowohl die Funktionalität und vor allem das Fokus-Management. Ausführliche Beiträge zu den einzelnen Buttons finden Sie drüben auf barrierefreies-webdesign.de:

2 Gedanken zu “Buttons, Buttons, Buttons – Semantische Auszeichnung von Schaltflächen mit ARIA-Attributen

  1. Ich habe oben auf meiner Webseite ein Hamburger-Menü-Symbol. Es ist ein Sprung-Link; bei Anklicken scrollt die Seite nach unten, wo sich das Menü befindet. Ich habe das Symbol wie üblich als button gekennzeichnet und für die Barrierefreiheit ein Aria-Label dazu gesetzt. Denn es sieht aus wie ein Button und führt wie bei üblichen Hamburger-Symbolen zum Menü. Nach Lesen dieses Artikels frage ich mich: Ist es sinnvoll, das Symbol als button zu kennzeichnen obwohl es ja eigentlich ein Sprung-Link ist?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert