Ein bisschen über Buttons

1

Neulich veröffentlichten wir einen Artikel mit einem echten CSS-Trick, bei dem ein Element mit einer doppelten Umrandung wie ein Pausesymbol aussehen und sich schön in ein CSS-Dreieck verwandeln konnte, das wie ein Play-Symbol aussieht. Ursprünglich wurde es mit einem <div> als Demo-Element veröffentlicht, was ein totalerAccessibility-Fehler unsererseits war, da etwas, das so interagieren soll, eigentlich ein <button> sein sollte.

Es enthielt auch eine Demo mit dem Checkbox-Hack, um den Zustand des Buttons umzuschalten. Das ändert die Tastaturinteraktion von einem "Enter"-Klick zu einem "Leertaste"-Umschalten, aber wichtiger ist, dass es einen :focus-Zustand haben sollte, um anzuzeigen, dass der Button (eigentlich ein Label) überhaupt interaktiv war.

Beides wurde behoben.

2

Adam Silver hat einen interessanten Beitrag, bei dem der Titel die Problematik gut auf den Punkt bringt

Aber manchmal sehen Links aus wie Buttons (und Buttons sehen aus wie Links)

Buttons, die Buttons sind, sind nicht umstritten (z. B. ein Formular-Submit-Button). Links, die Links sind, sind nicht umstritten. Die Probleme entstehen, wenn wir die Welten vermischen.

Buttons (mit type=”button“) sind keine Submit-Buttons. Buttons werden verwendet, um Funktionen zu erstellen, die auf Javascript angewiesen sind. Verhaltensweisen wie das Einblenden eines Menüs oder das Anzeigen eines Datumsauswahlers.

Ein „Call-to-Action“-Button ist sein gutes Beispiel auf der anderen Seite. Es sind oft nur Links, die für mehr Hervorhebung wie ein Button gestylt sind. Dieser gesamte Abschnitt ist wichtig

In Resilient Web Design diskutiert Jeremy Keith die Idee der Materialechtheit. Er sagt, dass „ein Material nicht als Ersatz für ein anderes verwendet werden sollte, sonst ist das Endergebnis täuschend“.

Einen Link wie einen Button aussehen zu lassen, ist materiell unehrlich. Es sagt den Benutzern, dass Links und Buttons dasselbe sind, wenn sie es nicht sind.

In Buttons In Design Systems sagt Nathan Curtis, dass wir Links von Buttons unterscheiden sollten, da „Button-Verhalten eine ganze Reihe unterschiedlicher Überlegungen mit sich bringen als Ihr einfaches Anker-Tag“.

Zum Beispiel können wir einen Link in einem neuen Tab öffnen, die Adresse kopieren oder ihn für später als Lesezeichen speichern. All das können wir nicht mit Buttons.

Call-to-Action-Buttons – die wieder nur Links sind – sind täuschend. Benutzer sind ahnungslos, weil diese Formatierung ihre natürliche Affordanz entfernt und ihr Verhalten verschleiert.

Wir könnten Call-to-Action-Buttons wie normale Links aussehen lassen. Aber das macht sie optisch schwach, was ihre Hervorhebung zunichte macht. Daher das Problem.

Ich stelle fest, dass selbst innerhalb von <button>s Probleme auftreten können, da das, was diese Buttons tun, oft sehr unterschiedlich ist. Zum Beispiel bringt der Fork-Button auf CodePen Sie zu einer brandneuen Seite mit einer neuen Kopie eines Pens, was sich ein bisschen wie das Klicken eines Links anfühlt. Aber es ist *kein* Link, was bedeutet, dass er sich anders verhält und eine Erklärung erfordert.

3

Ich wiederhole Adam hier noch einmal

Buttons werden verwendet, um Funktionen zu erstellen, die auf Javascript angewiesen sind.

Buttons innerhalb eines <form> haben Funktionalität ohne JavaScript, aber das ist der einzige Ort.

Das bedeutet, ein <button> ist in HTML völlig nutzlos, es sei denn, JavaScript wird erfolgreich heruntergeladen und ausgeführt.

Wenn man es zu einer extremen logischen Schlussfolgerung bringt, sollte man niemals einen <button> (oder type="button") in HTML außerhalb eines Formulars verwenden. Da JavaScript erforderlich ist, damit der Button etwas tut, sollte man den Button mit JavaScript an Ort und Stelle einfügen, sobald seine Funktionalität bereit ist.

Oder wenn das nicht möglich ist…

<button disabled title="This button will become functional once JavaScript is downloaded and executed">
  Do Thing
</button>

Dann ändern Sie diese Attribute, sobald sie bereit sind.