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 Einblenden 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 Toggle- und Switch-Buttons eingesetzt, die eine An/Aus-Situation darstellen. Generell gibt es drei Typen von Toggle-Buttons:
      1. Ein Toggle-Button 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“, wenn der Wert von aria-pressed „false“ lautet.
      2. Ein Switch-Button ist eine Spezialform des Toggle-Buttons, der meist der Funktionsweise von Checkboxen oder Radio-Buttons ähnelt:
        Filterfunktion bei einem Fernsehprogramm. 2 Schalter sind ausgewählt.
        Switch-Buttons 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 eines Toggle-Buttons 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 textlich 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 ein- und auszublenden:
      1. Einfache ausklappbare 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 größeren Abschnitten, d.h. Abschnitten mit einer vorangestellten Überschrift, die aus- und zugeklappt werden kann, ist das Design-Pattern eines Akkordeons zu bevorzugen:
        <h2><button aria-expanded="true" id="ref" onclick="meineFunktionen();">Überschrift </button></h2>

        <section aria-labelledby="ref"> … Einzublendender Inhalt … </section>

        Bei Akkordeons ist zu beachten, dass die einzublendende Seitenregion hier mit dem aria-labelledby-Attribut durch den Button-Text beschriftet wird.
    • Schließlich gibt es Menu-Buttons. Menu-Buttons fügen immer Inhalte zu einer Seite hinzu und überlagern in den meisten Fällen den zuvor sichtbaren Inhalt. Die neuen Inhalte können modal oder nicht-modal dargestellt werden. Eine Menü-Schaltfläche wird durch das aria-haspopup-Attribut gekennzeichnet:
      <button aria-haspopup="true" onclick="meineFunktionen();">Navigation</button>

      Ein solcher Button könnte in einem Screenreader als „Menüschalter Navigation“ identifiziert werden. Damit sollten Screenreadernutzer informiert werden, dass die Aktivierung des Buttons neuen Inhalt zur Webseite hinzufügt, der möglicherweise den ursprünglichen Inhalt überdeckt.
      Das aria-haspopup-Attribut darf verschiedene Werte haben. Der Wert „true“ ist identisch mit dem Wert „menu“, d.h. die vorstehende Schaltfläche deutet mit dem aria-haspopup-Attribut bereits an, dass die Aktivierung des Buttons ein Menü einblendet. Andere zulässige Werte sind „listbox“ (Auswahlliste), „dialog“ (Dialogfenster), „grid“ (Rastertabelle) und „tree“ (Baumstruktur). Wenn ein Menu-Button 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