Betrachtung von WCAG 2.5.5 für bessere Ziel Größen

Haben Sie schon einmal die Frustration erlebt, wenn Sie auf einem Mobilgerät auf eine Schaltfläche tippen wollten, diese aber nichts bewirkte, weil die Zielgröße einfach nicht groß genug war und Ihr Tippen nicht erkannt wurde? Vielleicht haben Sie größere Finger, so wie ich, oder vielleicht liegt es an eingeschränkter Geschicklichkeit. Das liegt an der leider immer kleiner werdenden Zielfläche von Elementen, mit denen wir Benutzer interagieren müssen.

Sprechen wir über die Ziel-Größe und wie man sie groß genug macht, damit Benutzer mit einem Element leicht interagieren können. Das ist besonders wichtig, wenn ein Benutzer auf einem kleinen, tragbaren Touchscreen-Gerät auf Inhalte zugreift, wo der Platz viel knapper ist.

Erfolgsmerkmal überarbeitet

Ich habe das Erfolgsmerkmal „Label in Name“ (in einem früheren Artikel) zur WCAG 2.1 kurz angesprochen. Kurz gesagt, die WCAG-Kriterien sind die Grundlage, von der aus wir bestimmen, ob unsere Arbeit „zugänglich“ ist.

Wenn Sie sich fragen, ob es ein Kriterium für die Zielgröße gibt, lautet die Antwort ja. Es ist WCAG 2.5.5. Direkt aus den Richtlinien zitiert, erfordert das Bestehen von WCAG 2.5.5 mit einer AAA-Bewertung, dass „die Größe des Ziels für Zeigereingaben mindestens 44 mal 44 CSS-Pixel beträgt, außer wenn

• Äquivalent: Das Ziel ist über einen äquivalenten Link oder eine äquivalente Steuerung auf derselben Seite verfügbar, die mindestens 44×44 CSS-Pixel groß ist;
• Inline: Das Ziel befindet sich in einem Satz oder einem Textblock;
• Benutzeragentensteuerung: Die Größe des Ziels wird vom Benutzeragenten bestimmt und nicht vom Autor geändert;
• Wesentlich: Eine bestimmte Darstellung des Ziels ist für die vermittelten Informationen wesentlich.“

Was könnte schiefgehen?

Es ist nur eine Größe, richtig? Kinderleicht. Nichts kann schiefgehen.

Oder doch?

Kleine Zielgrößen können für viele Menschen Barrieren für die Zugänglichkeit darstellen. Sind Sie schon einmal in einem Fahrzeug auf einer holprigen Straße unterwegs gewesen und haben versucht, mit einer App auf Ihrem Handy zu interagieren, aber Sie konnten kein Element drücken? Das ist eine Barriere für die Zugänglichkeit. Menschen mit motorischen oder kognitiven Beeinträchtigungen werden es viel schwerer haben, da es für sie viel schwieriger ist, wenn die Zielgröße zu klein ist und die WCAG-Anforderungen nicht erfüllt.

Ich will Twitter hier nicht angreifen, aber es ist das erste nennenswerte Beispiel, das ich gefunden habe, als ich nach Beispielen für kleine Ziele gesucht habe.

Stellen Sie sich die Hindernisse vor, die jemand mit neuromuskulären Erkrankungen, wie Multipler Sklerose, Zerebralparese, Arthritis, Zittern oder Alzheimer, oder einer anderen motorischen Beeinträchtigung überwinden müsste, um ein Ziel in einem dieser Fälle zu aktivieren.

Ein weiteres beliebtes Beispiel, das ich oft sehe? Werbung. Haben Sie jemals Schwierigkeiten gehabt, auf das winzige "X"-Symbol zu klicken, um sie zu schließen?

Da ich persönlich keine motorischen oder kognitiven Behinderungen habe, fummle ich herum und brauche mehrere Versuche, um einige Zielbereiche zu treffen. Die Tatsache, dass jemand, der etwas wie einen Stift oder Stylus verwenden muss, auf eine Zielgröße, die nicht mindestens 44×44 Pixel beträgt, zugreift, kann eine schwierige Aufgabe sein. Diese Ziele sollten nicht mehrere Versuche zur Aktivierung benötigen, wenn die Zielgröße nicht den empfohlenen Richtlinien entspricht.

Überlegungen zur Zielgröße

WCAG 2.5.5 geht ins Detail, um uns bei diesen Dingen zu helfen, indem es die vier Arten von Steuerelementen definiert, die wir gerade gesehen haben: Äquivalent, Inline, Benutzeragent und Wesentlich.

Wir werden uns verschiedene Überlegungen zur Bestimmung von Zielgrößen ansehen und sie mit den WCAG-Richtlinien vergleichen, um uns bei guten, zugänglichen Designentscheidungen zu leiten.

Unterschied zwischen „Klick“ und „Tippen“ berücksichtigen

Dieses Erfolgskriterium stellt sicher, dass die Zielgrößen groß genug sind, damit Benutzer Ziele leicht aktivieren können, auch wenn der Benutzer auf Handheld-Geräten auf diese Ziele zugreift. Typischerweise assoziieren wir kleine Bildschirme mit „Tippen“ anstelle von „Klicken“ beim Aktivieren von Zielen. Und das ist etwas, das wir bei der Größenbestimmung unserer Ziele berücksichtigen müssen.

Mäuse und ähnliche Eingabegeräte verwenden einen Zeiger auf dem Bildschirm, der als „feine“ Präzision gilt, da er es dem Benutzer ermöglicht, ein Element auf dem Bildschirm mit exakter Präzision anzusteuern. Feine Präzision macht es theoretisch einfacher, kleinere Zielgrößen zu erreichen. Das Problem ist, dass diese Art von Eingabegerät für einige Benutzer schwierig sein kann, sei es beim Greifen des Geräts oder bei anderen kognitiven oder motorischen Fähigkeiten. Daher ist auch bei feiner Präzision ein klares Ziel immer noch von Vorteil.

Tippen hingegen kann problematisch sein, da es ein Eingabemechanismus mit sehr „grober“ Präzision ist. Benutzer können beim Verwenden einer Maus oder eines Stifts zum Beispiel ein gewisses Maß an feiner Kontrolle vermissen lassen. Ein Finger, der größer ist als ein Mauszeiger, verdeckt im Allgemeinen die genaue Stelle auf dem Bildschirm, die aktiviert oder berührt wird. Daher „grobe“ Präzision.

Dieses Problem wird im reaktionsfähigen Design noch verschärft, das für zahlreiche Arten von feinen und groben Eingaben geeignet sein muss. Beide Eingabetypen müssen für eine Website unterstützt werden, auf die sowohl über einen Desktop oder Laptop mit einer Maus als auch über ein Mobilgerät oder Tablet mit einem Touchscreen zugegriffen werden kann.

Das macht die tatsächliche Größe, die wir für ein Ziel verwenden, zu einem ziemlich wichtigen Detail. Je nachdem, wer eine Steuerung verwendet, was diese Steuerung tut, wie oft sie verwendet wird und wo sie sich befindet, sollten wir größere, klarere Ziele in Betracht ziehen, um unerwünschte Aktionen zu verhindern.

Aber bei all dem gesagt, haben wir tatsächlich eine CSS-Medienabfrage, die ein Zeigergerät erkennen kann, so dass wir bestimmte Stile für feine oder grobe Eingabeinteraktionen gezielt anwenden können, und sie wird gut unterstützt. Hier ist ein Beispiel direkt aus der Spezifikation

/* Make radio buttons and check boxes larger if we have an inaccurate primary pointing device */
@media (pointer: coarse) {
  input[type="checkbox"], input[type="radio"] {
    min-width: 30px;
    min-height: 40px;
    background: transparent;
  }
}

Aber warten Sie. Während das alles großartig ist, warnt Patrick H. Lauke vor dieser Interaktions-Medienabfrage und ihrem Potenzial für falsche Annahmen.

Unterschiedliche Plattformen haben unterschiedliche Anforderungen

Wenn WCAG genaue Werte angibt, lohnt es sich, darauf zu achten. Beachten Sie, dass uns empfohlen wird, Zielgrößen von mindestens 44×44 Pixeln zu verwenden, was im WCAG 2.5.5 Erläuterungsbericht nicht weniger als 18 Mal erwähnt wird.

Sie haben jedoch möglicherweise auch ähnliche Anforderungen mit unterschiedlichen Richtlinien von Apple's „Human Interface Guidelines“ für iOS und Google's „Material Design“ in deren plattformspezifischen Designanforderungen gesehen.

Berücksichtigung der „tappbaren Fläche“ eines Ziels

Beachten Sie, dass sich Apple's Plattformanforderungen auf eine „tappbare Fläche“ beziehen, wenn sie die ideale Zielgröße beschreiben. Das bedeutet, dass wir uns ebenso mit dem Raum befassen, wie mit dem Aussehen eines Ziels. Google's Material Design schlägt zum Beispiel eine Zielgröße von mindestens 48×48 dp (dichteunabhängige Pixel) für interaktive Elemente vor. Aber was, wenn Ihre Designanforderungen ein 24×24 dp Symbol erfordern? Es ist absolut legitim, Polsterung zu unseren Gunsten zu nutzen, um mehr interaktiven Raum um das Symbol herum zu schaffen, der die 48×48 dp Zielgröße ausmacht. Oder, wie es in Material Design dokumentiert ist.

Touch-Ziele sind die Teile des Bildschirms, die auf Benutzereingaben reagieren. Sie reichen über die visuellen Grenzen eines Elements hinaus. Zum Beispiel kann ein Symbol 24×24 dp groß erscheinen, aber die Polsterung darum herum macht das gesamte 48×48 dp Touch-Ziel aus.

Reaktionsfähiges Layout-Verhalten berücksichtigen

Genau, wir müssen berücksichtigen, wie sich Dinge in einem Design verschieben und bewegen, das für verschiedene Ansichtsgrößen ausgelegt ist. Ein Beispiel könnten Schaltflächen sein, die sich auf kleinen Bildschirmen stapeln, aber auf größeren Bildschirmen nebeneinander liegen. Wir wollen sicherstellen, dass dieser Übergang die Platzierung umliegender Elemente berücksichtigt, um überlappende Elemente oder Ziele zu verhindern.

Apropos Inline, es gibt einen besonderen Teil der WCAG-Ausnahme für Inline-Ziele, der hervorgehoben werden sollte.

Inline: Angezeigte Inhalte können oft basierend auf der verfügbaren Bildschirmbreite neu angeordnet werden (reaktionsfähiges Design). In neu angeordneten Inhalten können Ziele an beliebiger Stelle in einer Zeile erscheinen und ihre Position ändern, abhängig von der verfügbaren Bildschirmbreite. Da Ziele an beliebiger Stelle in der Zeile erscheinen können, darf die Größe nicht größer sein als der verfügbare Text und der Abstand zwischen den Sätzen oder Absätzen, da die Ziele sonst überlappen könnten. Aus diesem Grund sind Ziele, die in einem oder mehreren Sätzen enthalten sind, von den Anforderungen an die Zielgröße ausgenommen.

(Hervorhebung von mir)

Jetzt sprechen wir nicht unbedingt von nebeneinander liegenden Schaltflächen. Wir können Links innerhalb von Text haben und dieser Text kann die Platzierung des Ziels brechen, möglicherweise in zwei Zeilen.

Beziehung des Ziels zu seiner Umgebung berücksichtigen

Wir haben gerade gesehen, dass Inline-Links in einem Textblock von der 44×44-Regel ausgenommen sind. Es gibt ähnliche Ausnahmen, je nach Beziehung des Ziels zu den umgebenden Elementen.

Nehmen wir das Beispiel, das der WCAG-Erläuterungsbericht wieder in seiner Beschreibung von Inline-Zielausnahmen liefert.

Wenn das Ziel der gesamte Satz ist und der Satz nicht in einem Textblock steht, muss das Ziel mindestens 44 mal 44 CSS-Pixel groß sein.

Das ist ein guter Punkt. Wir sollten berücksichtigen, ob das Ziel ein eigener Block ist oder Teil eines größeren Textblocks. Wenn das Ziel ein eigener Block ist, muss es die Regeln befolgen, sei es eine Schaltfläche mit einer kurzen Beschriftung oder ein vollständiger Satz, der verlinkt ist. Auf der anderen Seite muss ein vollständiger Satz, der in einem anderen Textblock verlinkt ist, die Anforderungen an die Zielgröße nicht erfüllen.

Man könnte denken, dass ein verlinktes Symbol am Ende eines Satzes oder Absatzes den Regeln folgen müsste, aber die WCAG stellt klar, dass diese Ziele ausgenommen sind.

Eine Fußnote oder ein Symbol innerhalb oder am Ende eines Satzes gilt als Teil eines Satzes und ist daher von der Mindestzielgröße ausgenommen.

Und das ist sinnvoll. Stellen Sie sich Inhalte mit einer Zeilenhöhe von beispielsweise 32 Pixeln und einem Symbol am Ende vor, das bis zu 44×44 Pixel aufgepolstert ist, und wie einfach es wäre, das Symbol versehentlich zu aktivieren.

Berücksichtigung, ob das Ziel vom Benutzeragenten gestylt wird

Wenn das Ziel komplett ungestylt ist – also wenn Sie kein CSS hinzugefügt haben – und stattdessen die Standardstile des Browsers übernimmt, dann müssen Sie sich keine Sorgen um die 44×44-Regel machen. Das ist sinnvoll. Der Benutzeragent ist wie eine Benutzeroberfläche auf Systemebene, und ihn oberflächlich mit eigenen Stilen zu verändern, würde ein ganzes System überschreiben, was zu Inkonsistenzen in dieser Benutzeroberfläche führen könnte.

Also ja, wenn Sie eine Standard-<button> oder ähnliches verwenden und keine weiteren Stile oder Größen darauf angewendet werden, dann ist das in Ordnung. Aber viele von uns verwenden Resets, um UI-Elemente über Browser hinweg zu normalisieren. Achten Sie also in Ihrem Code auf solche Dinge, da dies die Benutzeragenten-Stile Ihres Ziels beeinflusst.

Gibt es andere Möglichkeiten, die Funktionalität zu aktivieren?

Wir alle haben Ankerlinks auf Seiten verwendet, richtig? CSS-Tricks hat oft ein Inhaltsverzeichnis am Anfang eines Artikels, das lediglich eine Liste von Ankerlinks ist.

WCAG verwendet Ankerlinks tatsächlich als Beispiel für etwas, das von den Anforderungen an die Zielgröße befreit ist. Warum? Weil es genauso möglich ist, manuell zu einer bestimmten Stelle auf einer Seite zu scrollen, wie auf einen Link zu klicken, um dorthin zu springen. Es gibt zwei Möglichkeiten, dasselbe zu erreichen, und eine davon ist direkt im Browser integriert.

Aber wir sollten trotzdem vorsichtig sein, wenn wir etwas wie ein Inhaltsverzeichnis verwenden. Ich bin mir hier nicht ganz sicher, aber da ein Inhaltsverzeichnis eine Liste von Links ist, kann jeder Link seinen eigenen Textblock darstellen, der nicht Teil eines größeren Textblocks wie eines Absatzes ist. In einem solchen Fall ist es vielleicht trotzdem eine gute Idee, etwas mehr Abstand zwischen den Listenelementen zu lassen. Es besteht weniger Gefahr, dass mehrere Ziele gleichzeitig versehentlich angeschnitten oder angetippt werden.

Zusammenfassung

Das WCAG 2.5.5 Kriterium bietet Anleitungen zur Anwendung von Zielgrößen, die klar, frei von Hindernissen und leicht zu aktivieren sind. Wie wir gesehen haben, gibt es viele Fälle, in denen die Größe eines Ziels den Unterschied ausmachen kann, wenn es darum geht, eine Aktion abzuschließen.

Das Interessante an den Richtlinien für Zielgrößen sind die Ausnahmen davon. Obwohl wir nicht jede spezifische Ausnahme einzeln behandelt haben, haben wir uns eine Reihe von Situationen angesehen, die eine sorgfältige Berücksichtigung der Zielgrößen erfordern, von der Art des verwendeten Eingabegeräts bis hin zur Beziehung des Ziels zu seinen umliegenden Elementen und vielem mehr dazwischen.

Der Schlüssel zu zugänglichen Zielgrößen liegt nicht unbedingt darin, weniger Styling auf ein Ziel anzuwenden (obwohl wir gesehen haben, dass Standard-Benutzeragenten-Stile ausgenommen sind), sondern vielmehr darin, den Kontext zu haben und entsprechend zu stylen. Wahrscheinlich gibt es Dutzende weiterer Situationen, die wir hier hätten behandeln und wie Stile eine Rolle spielen untersuchen können – also wenn Sie welche haben, teilen Sie sie mit!

Und was das Styling angeht, bieten CSS-Spezifikationen spezielle Funktionen, wie die Interaktions-Medienabfrage für pointer, um die Zielgrößen für Menschen noch besser zu machen. Gut eingesetzt, könnte dies eine großartige Möglichkeit sein, zu erkennen, ob ein Besucher ein feines oder grobes Eingabegerät verwendet. So können wir die Dinge anpassen, um ihre Erfahrung besser zu gestalten, als wenn wir diese Unterschiede gleich behandeln würden.

Also ja, Zielgrößen sind eine einfache Sache, die man abtun und ignorieren kann. Aber hoffentlich haben Sie jetzt wie ich eine echte Wertschätzung für richtig dimensionierte Ziele, da Sie nun die Informationen haben, um eigene richtig dimensionierte Ziele zu erstellen.