Macht deaktivierte Schaltflächen inklusiver

Lassen Sie uns über deaktivierte Schaltflächen sprechen. Insbesondere wollen wir uns damit befassen, warum wir sie verwenden und wie wir es besser machen können als das traditionelle `disabled`-Attribut in HTML (z. B. ``), um eine Schaltfläche als deaktiviert zu markieren.

Es gibt viele Anwendungsfälle, in denen eine deaktivierte Schaltfläche sehr sinnvoll ist, und auf diese Gründe werden wir gleich eingehen. Aber während dieses Artikels werden wir uns ein Formular ansehen, das es uns ermöglicht, eine Anzahl von Tickets in einen Warenkorb zu legen.

Dies ist ein gutes Basisbeispiel, da es eine klare Situation für die Deaktivierung der Schaltfläche "In den Warenkorb legen" gibt: wenn keine Tickets zum Warenkorb hinzugefügt werden können.

Aber zuerst: Warum deaktivierte Schaltflächen?

Menschen daran zu hindern, eine ungültige oder nicht verfügbare Aktion auszuführen, ist der häufigste Grund, warum wir uns vielleicht für eine deaktivierte Schaltfläche entscheiden. In der unten gezeigten Demo können wir nur dann Tickets hinzufügen, wenn die Anzahl der zum Warenkorb hinzugefügten Tickets größer als null ist. Probieren Sie es aus.

Gestatten Sie mir, die Codeerklärung in dieser Demo zu überspringen und unsere Aufmerksamkeit auf das zu lenken, was wichtig ist: die Schaltfläche "In den Warenkorb legen".

<button type="submit" disabled="disabled">
  Add to cart
</button>

Diese Schaltfläche wird durch das Attribut disabled deaktiviert. (Beachten Sie, dass dies ein boolesches Attribut ist, was bedeutet, dass es als disabled oder disabled="disabled" geschrieben werden kann.)

Alles scheint in Ordnung zu sein ... also, was ist daran falsch?

Nun, ehrlich gesagt, ich könnte den Artikel hier beenden und Sie bitten, keine deaktivierten Schaltflächen zu verwenden, weil sie Mist sind, und stattdessen bessere Muster zu verwenden. Aber seien wir realistisch: Manchmal ist das Deaktivieren einer Schaltfläche die Lösung, die am meisten Sinn ergibt.

Vor diesem Hintergrund tun wir für diese Demo so, als wäre das Deaktivieren der Schaltfläche "In den Warenkorb legen" die beste Lösung (Spoiler-Alarm: das ist sie nicht). Wir können sie immer noch verwenden, um zu lernen, wie sie funktioniert und ihre Benutzerfreundlichkeit im Laufe der Zeit zu verbessern.

Interaktionstypen

Ich möchte klären, was ich mit "benutzbaren deaktivierten Schaltflächen" meine. Sie denken vielleicht: "Wenn die Schaltfläche deaktiviert ist, sollte sie nicht benutzbar sein, also ... was ist der Haken?" Haben Sie etwas Geduld.

Im Web gibt es mehrere Möglichkeiten, mit einer Seite zu interagieren. Die Mausbedienung ist eine der häufigsten, aber es gibt auch andere, wie z. B. sehende Menschen, die die Tastatur zur Navigation verwenden, weil sie eine motorische Beeinträchtigung haben.

Versuchen Sie, die obige Demo nur mit der Tab-Taste zum Vorwärts- und Tab + Shift zum Rückwärtswechseln zu navigieren. Sie werden feststellen, wie die deaktivierte Schaltfläche übersprungen wird. Der Fokus springt direkt vom Ticket-Eingabefeld zum Link "Dummy-Bedingungen".

Lassen Sie uns kurz innehalten und die Gründe zusammenfassen, die uns dazu gebracht haben, die Schaltfläche überhaupt zu deaktivieren, im Vergleich zu dem, was wir tatsächlich erreicht haben.

Es ist üblich, "Interaktion" mit "Klicken" gleichzusetzen, aber dies sind zwei verschiedene Konzepte. Ja, *Klicken* ist eine Art der Interaktion, aber es ist nur eine unter anderen, wie Hover und Fokus.

Mit anderen Worten...

Alle Klicks sind Interaktionen, aber nicht alle Interaktionen sind Klicks.

Unser Ziel ist es, den Klick zu verhindern, aber durch die Verwendung von disabled verhindern wir nicht nur den Klick, sondern auch den Fokus, was bedeutet, dass wir möglicherweise genauso viel Schaden wie Nutzen anrichten. Sicher, dieses Verhalten mag harmlos erscheinen, aber es führt zu Verwirrung. Menschen mit kognitiven Beeinträchtigungen können Schwierigkeiten haben zu verstehen, warum sie die Schaltfläche nicht fokussieren können.

In der folgenden Demo haben wir das Layout ein wenig angepasst. Wenn Sie eine Maus verwenden und über die Schaltfläche zum Absenden fahren, wird ein Tooltip angezeigt, der erklärt, warum die Schaltfläche deaktiviert ist. Das ist großartig!

Aber wenn Sie nur die Tastatur verwenden, gibt es keine Möglichkeit, diesen Tooltip zu sehen, da die Schaltfläche mit disabled nicht fokussierbar ist. Dasselbe passiert auch auf Touch-Geräten. *Autsch!*

Gestatten Sie mir, wieder die Codeerklärung zu überspringen. Ich empfehle dringend, "Inclusive Tooltips" von Haydon Pickering und "Tooltips in the time of WCAG 2.1" von Sarah Higley zu lesen, um das Tooltip-Muster vollständig zu verstehen.

ARIA zur Rettung

Das Attribut disabled in einem <button> tut mehr als nötig. Dies ist einer der wenigen Fälle, die ich kenne, in denen ein natives HTML-Attribut mehr schaden als nützen kann. Die Verwendung eines ARIA-Attributs kann bessere Ergebnisse erzielen und uns ermöglichen, Screenreadern mitzuteilen, wie sie die Schaltfläche interpretieren sollen, aber dies auf konsistente Weise tun, um eine inklusive Erfahrung für mehr Menschen und Anwendungsfälle zu schaffen.

Das Attribut disabled korreliert mit aria-disabled="true". Probieren Sie die folgende Demo aus, wieder nur mit der Tastatur. Beachten Sie, wie die Schaltfläche, obwohl als deaktiviert markiert, immer noch per Fokus erreichbar ist *und* den Tooltip auslöst!

Cool, oder? So eine kleine Änderung für eine große Verbesserung!

Aber wir sind noch nicht ganz fertig. Der Nachteil hierbei ist, dass wir den Klick immer noch programmatisch mit JavaScript verhindern müssen.

elForm.addEventListener('submit', function (event) {
  event.preventDefault(); /* prevent native form submit */

  const isDisabled = elButtonSubmit.getAttribute('aria-disabled') === 'true';

  if (isDisabled || isSubmitting) {
    // return early to prevent the ticket from being added
    return;
  }

  isSubmitting = true;
  // ... code to add to cart...
  isSubmitting = false;
})

Sie sind vielleicht mit diesem Muster vertraut, um doppelte Klicks zu verhindern, die ein Formular zweimal absenden. Wenn Sie das Attribut disabled aus diesem Grund verwendet haben, würde ich davon abraten, da dies zu einem vorübergehenden Verlust des Tastaturfokus führt, während das Formular gesendet wird.

Der Unterschied zwischen disabled und aria-disabled

Sie fragen sich vielleicht: Wenn aria-disabled den Klick standardmäßig nicht verhindert, was ist dann der Sinn der Verwendung? Um das zu beantworten, müssen wir den Unterschied zwischen beiden Attributen verstehen

Merkmal / Attribut	disabled	aria-disabled="true"
Klick verhindern	✅	❌
Hover verhindern	❌	❌
Fokus verhindern	✅	❌
Standard-CSS-Stile	✅	❌
Semantik	✅	✅

Die einzige Überschneidung zwischen beiden ist die **Semantik.** Beide Attribute kündigen an, dass die Schaltfläche tatsächlich deaktiviert ist, und das ist gut so.

Im Gegensatz zum disabled-Attribut geht es bei aria-disabled nur um Semantik. ARIA-Attribute ändern standardmäßig niemals das Verhalten oder die Stile einer Anwendung. Ihr einziger Zweck ist es, assistierenden Technologien (z. B. Screenreadern) zu helfen, den Seiteninhalt aussagekräftiger und robuster anzukündigen.

Bisher haben wir über zwei Arten von Menschen gesprochen, diejenigen, die klicken, und diejenigen, die Tab verwenden. Sprechen wir nun über eine weitere Art: Menschen mit Sehbehinderungen (z. B. Blindheit, eingeschränktes Sehvermögen), die Screenreader zur Navigation im Web verwenden.

Menschen, die Screenreader verwenden, bevorzugen oft die Navigation zu Formularfeldern über die Tab-Taste. Schauen Sie sich nun an, wie VoiceOver unter macOS die disabled-Schaltfläche vollständig überspringt.

Auch hier handelt es sich um ein sehr minimales Formular. In einem längeren Formular kann die Suche nach einer Schaltfläche zum Absenden, die nicht sofort sichtbar ist, störend sein. Stellen Sie sich ein Formular vor, bei dem die Schaltfläche zum Absenden versteckt ist und nur sichtbar wird, wenn Sie das Formular vollständig ausgefüllt haben. So fühlen sich manche Leute, wenn das Attribut disabled verwendet wird.

Glücklicherweise sind Schaltflächen mit disabled nicht für Screenreader völlig unerreichbar. Sie können immer noch jedes Element einzeln durchlaufen und schließlich die Schaltfläche finden.

Obwohl möglich, ist dies eine nervige Erfahrung. Andererseits wird mit aria-disabled der Screenreader die Schaltfläche normal fokussieren und ihren Status korrekt ankündigen. Beachten Sie, dass die Ankündigung zwischen verschiedenen Screenreadern leicht variiert. Zum Beispiel sagen NVDA und JWAS "Schaltfläche, nicht verfügbar", aber VoiceOver sagt "Schaltfläche, gedimmt".

Ich habe zusammengefasst, wie beide Attribute unterschiedliche Benutzererfahrungen schaffen, basierend auf den Tools, die wir gerade verwendet haben

Werkzeug / Attribut	disabled	aria-disabled="true"
Maus oder Tippen	Verhindert einen Klick auf die Schaltfläche.	Erfordert JS, um den Klick zu verhindern.
Tab	Kann die Schaltfläche nicht fokussieren.	Kann die Schaltfläche fokussieren.
Bildschirmlesegerät	Schaltfläche ist schwer zu lokalisieren.	Schaltfläche ist leicht zu lokalisieren.

Die Hauptunterschiede zwischen beiden Attributen sind also:

• disabled überspringt die Schaltfläche möglicherweise bei der Verwendung der Tab-Taste, was zu Verwirrung führt.
• aria-disabled fokussiert die Schaltfläche weiterhin und kündigt an, dass sie existiert, aber noch nicht aktiviert ist; genauso, wie Sie es visuell wahrnehmen würden.

Hier ist es wichtig, den subtilen Unterschied zwischen Barrierefreiheit und Benutzerfreundlichkeit anzuerkennen. Barrierefreiheit ist ein Maß dafür, ob jemand etwas nutzen kann. Benutzerfreundlichkeit ist ein Maß dafür, wie einfach etwas zu benutzen ist.

Ist disabled unter diesen Voraussetzungen barrierefrei? *Ja*. Hat es eine gute Benutzerfreundlichkeit? *Ich glaube nicht*.

Können wir es besser machen?

Ich würde mich nicht gut fühlen, wenn ich diesen Artikel nicht beenden würde, ohne Ihnen die wirklich inklusive Lösung für unser Ticketformularbeispiel zu zeigen. **Verwenden Sie deaktivierte Schaltflächen, wann immer möglich, nicht.** Lassen Sie die Leute jederzeit darauf klicken und zeigen Sie gegebenenfalls eine Fehlermeldung als Feedback an. Dieser Ansatz löst auch andere Probleme

• Weniger kognitive Reibung: Ermöglichen Sie den Leuten, das Formular jederzeit abzuschicken. Dies beseitigt die Unsicherheit, ob die Schaltfläche überhaupt deaktiviert ist.
• Farbkontrast: Obwohl eine deaktivierte Schaltfläche nicht die WCAG 1.4.3 Farbkontrast erfüllen muss, glaube ich, dass wir sicherstellen sollten, dass ein Element unabhängig von seinem Zustand immer richtig sichtbar ist. Aber das ist etwas, worüber wir uns jetzt keine Sorgen machen müssen, da die Schaltfläche nicht mehr deaktiviert ist.

Abschließende Gedanken

Das Attribut disabled in <button> ist ein besonderer Fall, bei dem es zwar in der Community sehr bekannt ist, aber möglicherweise nicht die beste Methode ist, um ein bestimmtes Problem zu lösen. Verstehen Sie mich nicht falsch, ich sage nicht, dass disabled *immer* schlecht ist. Es gibt immer noch einige Fälle, in denen es sinnvoll ist, es zu verwenden (z. B. Paginierung).

Um ehrlich zu sein, sehe ich das disabled-Attribut nicht unbedingt als ein Problem der Barrierefreiheit. Was mich beunruhigt, ist eher ein Problem der Benutzerfreundlichkeit. Durch den Austausch des disabled-Attributs durch aria-disabled können wir die Erfahrung von jemandem erheblich verbessern.

Dies ist ein weiterer Schritt auf meiner Reise zur Barrierefreiheit im Web. Im Laufe der Jahre habe ich entdeckt, dass Barrierefreiheit mehr ist als nur die Einhaltung von Webstandards. Der Umgang mit Benutzererlebnissen ist knifflig und die meisten Situationen erfordern Kompromisse und Abwägungen bei der Herangehensweise an eine Lösung. Es gibt keine einfache Lösung für perfekte Barrierefreiheit.

Unsere Pflicht als Webgestalter ist es, nach den verfügbaren verschiedenen Lösungen zu suchen und diese zu verstehen. Nur dann können wir die bestmögliche Wahl treffen. Es hat keinen Sinn, so zu tun, als ob die Probleme nicht existieren.

Denken Sie am Ende des Tages daran, dass nichts Sie davon abhält, das Web zu einem inklusiveren Ort zu machen.

Bonus

Immer noch da? Lassen Sie mich zwei letzte Dinge über diese Demo erwähnen, die meiner Meinung nach erwähnenswert sind

1. Live Regions kündigen dynamische Inhalte an

In der Demo änderten sich zwei Teile des Inhalts dynamisch: die Schaltfläche zum Absenden des Formulars und die Erfolgsbestätigung ("[X] Tickets hinzugefügt!").

Diese Änderungen werden visuell wahrgenommen, aber für Menschen mit Sehbehinderungen, die Screenreader verwenden, ist das einfach nicht die Realität. Um dies zu lösen, müssen wir diese Nachrichten in Live Regions umwandeln. Diese ermöglichen assistierenden Technologien, Änderungen zu verfolgen und die aktualisierten Nachrichten anzukündigen, wenn sie auftreten.

In der Demo gibt es eine .sr-only-Klasse, die ein <span> mit einer Lade-Nachricht ausblendet, aber ermöglicht, dass sie von Screenreadern angekündigt wird. In diesem Fall wird aria-live="assertive" auf das <span> angewendet und es enthält eine aussagekräftige Nachricht, nachdem das Formular gesendet wurde und sich im Ladevorgang befindet. Auf diese Weise können wir dem Benutzer mitteilen, dass das Formular funktioniert und Geduld haben soll, während es geladen wird. Darüber hinaus tun wir dasselbe für das Feedback-Element des Formulars.

<button type="submit" aria-disabled="true">
  Add to cart
  <span aria-live="assertive" class="sr-only js-loadingMsg">
     <!-- Use JavaScript to inject the the loading message -->
  </span>
</button>

<p aria-live="assertive" class="formStatus">
  <!-- Use JavaScript to inject the success message -->
</p>

Beachten Sie, dass das Attribut aria-live von Anfang an im DOM vorhanden sein muss, auch wenn das Element noch keine Nachricht enthält, da sonst assistierende Technologien möglicherweise nicht richtig funktionieren.

Es gibt noch viel mehr über dieses kleine aria-live-Attribut und die großen Dinge, die es tut, zu erzählen. Es gibt auch Fallstricke. Wenn das Attribut zum Beispiel falsch angewendet wird, kann es mehr schaden als nützen. Es lohnt sich, "Using aria-live" von Ire Aderinokun und Adrian Rosellis "Loading Skeletons" zu lesen, um besser zu verstehen, wie es funktioniert und wie man es verwendet.

2. Verwenden Sie nicht pointer-events, um den Klick zu verhindern

Dies ist eine alternative (und falsche) Implementierung, die ich im Web gesehen habe. Diese verwendet pointer-events: none; in CSS, um den Klick zu verhindern (ohne jegliches HTML-Attribut). Bitte tun Sie das nicht. Hier ist ein hässlicher Pen, der hoffentlich demonstriert, warum. **Ich wiederhole:** **_tun Sie das nicht_**. **tun Sie das nicht.**

Obwohl diese CSS-Regel tatsächlich einen Mausklick verhindert, denken Sie daran, dass sie den Fokus und die Tastaturnavigation nicht verhindert, was zu unerwarteten Ergebnissen oder, noch schlimmer, zu Fehlern führen kann.

Mit anderen Worten, die Verwendung dieser CSS-Regel als Strategie zur Verhinderung eines Klicks ist *sinnlos* (verstehen Sie?);)