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

Ein Link ist ein Link — oder doch eine Schaltfläche?

Der Einsatz von Links und Schaltflächen auf Webseiten ist in der Praxis oft nicht konsequent. Manche Webseiten weisen Navigationsleisten auf, die nur aus Schaltflächen bestehen, und auf anderen Webseiten werden Formulare mit Links abgeschickt.

Neue Seiten sollten mit Links aufgerufen werden

Der wesentliche Unterschied zwischen Links und Buttons ist, dass Buttons keine eigene Funktionalität mit sich bringen und Aktionen per JavaScript ausgelöst werden müssen. Auf einer funktionalen Ebene gibt es darüber hinaus kaum Gründe, sich für eine Schaltfläche oder einen Link zu entscheiden, denn beide Elementtypen bieten ähnliche Features:

• Sowohl Links als auch Buttons haben eine implizite Rolle (im Accessibility-Tree legen Browser Links mit der Rolle "link" und Schaltflächen mit der Rolle "button" ab).
• Sowohl Links (ein A-Element mit einem href-Attribut) als auch Schaltflächen (ein BUTTON-Element oder ein input-Element im Zustand "button", "submit", "reset" oder "image") werden standardmäßig von Browsern in die Fokus-Reihenfolge aufgenommen.
• Bei Links löst die Eingabetaste und bei Buttons die Leertaste oder Eingabetaste standardmäßig den Click-Event aus.

Es gibt aber auch kleine Unterschiede zwischen beiden Elementtypen:

• Buttons können mit dem disabled-Attribut deaktiviert werden während für deaktivierte Links das href-Attribut vom a-Element entfernt werden muss.
• Links können ohne JavaScript in einem neuen Fenster geöffnet werden oder mit dem Pseudoattribut :visited anders gestaltet werden.
• Browser bieten andere Features für die beiden Elemente im Kontextmenü.

Auch ein Blick in die HTML-Spezifikation liefert keine eindeutige Unterscheidung zwischen beiden interaktiven Elementen. Links stellen eine Verbindung zwischen zwei Ressourcen her während Buttons eine Aktion ausführen. Mit etwas gutem Willen können die Definitionen so verstanden werden, dass Links eine neue URI in der Adresszeile anzeigen während Buttons Aktionen im DOM ausführen; in der Praxis ist eine solche Trennung nicht immer begründbar.

Es gibt allerdings einen Grund, strikt zwischen Links und Buttons zu unterscheiden: Nutzer wissen, dass Links neue Inhalte aufrufen während Schaltflächen einen Befehlscharakter haben, d.h. mit Schaltflächen werden Inhalte bearbeitet, Bestätigungen eingefordert oder sonstige Anweisungen an eine Webanwendung vorgenommen.

"Links are for going and buttons are for doing"

Eine strikte Trennung für den Einsatz von Links oder Buttons ist leicht gefordert, aber eine eindeutige Antwort auf die Frage, wann Links und wann Schaltflächen eingesetzt werden müssen, gibt es leider nicht immer. Wie schwierig die Abgrenzung zwischen dem Einsatz von Links und von Schaltflächen sein kann, zeigt ein Beitrag von Jakob Nielsen aus dem Jahr 2007. Die Diskussionen dauern bis heute an.

Quelle: manufaktum.de

In einem E-Shop sollte eine Funktion "In den Warenkorb legen" eine Schaltfläche sein – vorausgesetzt, es wird keine neue Seite aufgerufen, und auf der Webseite sollte bei Aktivierung der Funktion eine entsprechende Statusmeldung erscheinen. Gleiches gilt für die Funktion "Auf den Wunschzettel". Hingegen führt "Zur Kasse" zu einer neuen Seite und sollte als Link umgesetzt werden. Im Übrigen wurden in der Seite im Screenshot die drei aktiven Elemente im HTML korrekt umgesetzt; nach den Usability-Diskussionen sollte der Link aber wie ein Link und nicht wie ein Button aussehen.

Die Argumentation der Usability-Experten zur Verwendung von Links und Schaltflächen hebt meist auf die Erwartungen ab. Sie sagen, ein Link führt zu einem anderen Inhalt beziehungsweise baut die Seite neu auf während eine Schaltfläche dazu dient, zum Beispiel den Status eines Inhalts zu verändern. Aus Sicht eines Entwicklers ist das Problem schnell gelöst: "Der Link soll ein Button sein? Kein Problem, das kriege ich mit CSS schnell hin."

Erwartungen der sehenden Nutzer können mit CSS erfüllt werden.

Den Nutzererwartungen wird am Bildschirm genüge getan, aber das gilt nicht für Screenreadernutzer. In Sprachausgaben und Braille-Zeilen ist die Funktion nachwievor ein Link. Statt nur in die CSS-Kiste zu greifen muss zuerst in die HTML-Kiste gegriffen werden und entweder ein BUTTON-Element oder ein role-Attribut mit der Rolle "button" vergeben werden.

Wann kommen Links in Frage?

Links sind in den folgenden Situationen Buttons vorzuziehen:

• Navigation (neue Webseite oder Ansicht)
• Download
• Webseite neu laden
• Sprunglinks innerhalb einer Webseite

Im Allgemeinen verändern Links den Kontext. Beispielsweise befindet sich der Tastaturfokus nicht mehr an der gleichen Stelle wie zuvor, wenn ein Link aufgerufen wird. Links haben außerdem die Eigenschaft, neue Ressourcen aufzurufen (außer bei Sprunglinks innerhalb einer Webseite).

Wann sind Buttons zu bevorzugen?

Schaltflächen behalten im Gegensatz zu Links meist den Fokus, auch wenn die Inhalte der Seite geändert werden. Für die meisten Buttons ist außerdem JavaScript erforderlich.

Buttons werden zu unterschiedlichen Zwecken eingesetzt. Die Buttons können wie folgt kategorisiert werden:

• Abschicken (und Zurücksetzen) von Formularen - quasi die Ausnahme, denn meist wird dabei eine neue Webseite aufgerufen; außerdem ist JavaScript nicht erforderlich.
• Gewöhnliche Aktionsschaltflächen, d.h. nach Aktivierung einer Schaltfläche ändert sich der Zustand der Schaltfläche nicht. Das kann beispielsweise eine "Zwischenspeichern"-Schaltfläche in einer Webanwendung oder ein "Schließen"-Button für ein Dialogfenster sein.
• Toggle-Buttons (Umschaltflächen), die eine An/Aus-Funktion inne haben:

  <button aria-pressed="true|false">
  Beschriftung
  </button>

• Switch-Buttons (Knopfschalter), die eine Aktivierungs-Funktion inne haben:

  <button role="switch" aria-checked="true|false">
    Beschriftung
</button>

• Einblenden-Funktionalität:
  • Einfache ausklappbare Buttons, die kürzere Texte zur Webseite ein- und ausblenden:

    <button aria-expanded="true|false">
  Beschriftung
  </button>

  • Akkordeons, um Abschnitte einer Webseite ein- und auszublenden:

    <h2>
  <button aria-expanded="true|false">
    Abschnittsüberschrift
  </button>
</h2>

• Menü-Buttons, die eine Popup-Funktionalität anzeigen, z.B.:

  <button aria-haspopup="true">
  Beschriftung
</button>

Beim Einsatz von Buttons müssen folgende Punkte noch beachtet werden:

• Buttons bieten keine Funktionalität (außer innnerhalb von FORM-Elementen und wenn sie im Zustand "submit" oder "reset" sind). Die Funktionalität müssen Autoren mittels JavaScript bereitstellen. Sofern das BUTTON-Element genutzt wird, reicht dabei ein onclick-Event-Handler.
• Dient ein Button als Widget und befindet sich der Button innerhalb eines FORM-Elements, so wird nach dem HTML-Standard angenommen, dass es sich um ein Button des Typs "submit" handelt. Daher sollte in solchen Fällen der Typ "button" explizit angegeben werden:

  <form ...>
  <button type="button" onclick="meinEventHandler();">
    Beschriftung
  </button>
</form>

Bis auf die Schaltflächen zum Abschicken oder Zurücksetzen eines Formulars müssen im Übrigen Autoren dafür sorgen, dass der Fokus nicht verloren geht, wenn eine Schaltfläche aktiviert wird.

Es kommt auf die Rolle an

Jakob Nielsen versucht in seinem oben verlinkten Beitrag den Einsatz von Schaltflächen für Aktionen mit Befehlscharakter zu empfehlen. Die Begründung ist gut nachvollziehbar, aber in der Praxis kaum relevant, weil Links ohne weiteres wie Schaltflächen gestaltet werden können und umgekehrt.

Vor dem Hintergrund der Barrierefreiheit spielt die Verwendung von Schaltflächen und Links eine stärkere Rolle: die semantische Bedeutung einer Schaltfläche ist beispielsweise entscheidend für die Navigation innerhalb einer Webseite. In Screenreadern werden Schaltflächen mit anderen Befehlen aufgelistet oder angesteuert als Links; Buttons werden z.B. in den Screenreadern JAWS und NVDA mit der Taste B angesprungen. Außerdem dürfen Screenreadernutzer wie andere Nutzer bei der Aktivierung eines Buttons erwarten, dass der Kontext sich nicht ändert.

Wenn Schaltflächen gesucht werden, dann sollten Schaltflächen wie hier bei der Landtagslupe des WDR gefunden werden

In den Web Content Accessibility Guidelines (WCAG) 2.1 beziehungsweise der Barrierefreien Informationstechnik-Verordnung – BITV 2.0 wird der Einsatz von Schaltflächen versus Links nicht explizit behandelt, aber in den WCAG 2.1 wird an mehreren Stellen auf die Semantik im HTML eingegangen. Beispielsweise steht in der Best-Practice-Technik G115:

Using the appropriate semantic elements will make sure the structure is available to the user agent. This involves explicitly indicating the role that different units have in understanding the meaning of the content.

Konkret geht es um die Rolle eines Elements: Screenreader können zwischen Schaltflächen und Links unterscheiden und bieten alternative Steuerungsmöglichkeiten für unterschiedliche HTML-Elemente an. Wenn also etwas wie eine Schaltfläche gestaltet wird, dann sollte es auch im HTML eine Schaltfläche sein, und wenn ein Element wie ein Link aussieht, dann sollte im HTML auch ein Link stehen.

Wenn aktive Elemente wie Schaltflächen gestaltet werden und diese nicht als BUTTON ausgespielt werden können, dann sollte das HTML repariert werden und zumindest die Rolle "button" explizit vergeben werden:

Mit der expliziten Rolle "button" wird der Link im Accessibility-Tree als Button abgelegt und von einem Screenreader entsprechend als Schaltfläche identifiziert.