Was gibt es Neues in WCAG 2.1: Label in Name

WCAG 2.1 Empfehlungen wurden 2018 veröffentlicht. Es ist nun einige Jahre her und es gibt einige neue Erfolgskriterien. In diesem Artikel werde ich Label in Name besprechen, also wie wir Komponenten visuell kennzeichnen. Wir werden uns ansehen, wie einige Fehlerzustände aussehen, wie man sie behebt und Beispiele, wie man sie richtig macht.

Du hast mich bei Success Criterion verloren...

Ein Erfolgskriterium ist eine testbare Aussage, die nicht technologie-spezifisch ist. Es ist die Basis, von der aus wir bestimmen, ob unsere Arbeit „zugänglich“ ist. In diesem Fall ist „Label in Name“ das zu bewertende Kriterium, das neben einer ganzen Reihe anderer Kriterien steht. WCAG 2.1 ist die aktuelle Version der Spezifikation und „Label in Name“ ist Punkt 2.5.3, was darauf hinweist, dass es in der zweiten Kategorie („Bedienbar“) der Kriterien, unter dem fünften Abschnitt („Eingabemodalitäten“) dieser Kategorie, als dritter Punkt in diesem Abschnitt aufgeführt ist.

WCAG 2.1 ist abwärtskompatibel mit WCAG 2.0, was bedeutet, dass es eine Erweiterung von WCAG 2.0 ist. Darüber hinaus sind die Veröffentlichungen von WCAG 2.1 und 2.2 im Verbund miteinander und sie funktionieren alle zusammen.

Label in Name

Um also auf die Dinge zurückzukommen, 2.5.3 Label in Name (Level A) ist neu und in den WCAG 2.1 Erfolgskriterien definiert. Hier ist, wie es beschrieben wird:

Bei Benutzeroberflächenkomponenten mit Bezeichnungen, die Text oder Bilder von Text enthalten, enthält der Name den Text, der visuell dargestellt wird.

Die Absicht dieses Erfolgskriteriums (SC) ist es sicherzustellen, dass die Wörter, die ein Label visuell auf der Komponente hat, auch in den Wörtern enthalten sind, die der Komponente programmatisch zugeordnet sind. Dies hilft sicherzustellen, dass jeder – sei es jemand, der Spracherkennungssoftware verwendet, oder jemand, der visuell sehend ist – sich auf Labels verlassen kann, um die Absicht einer Komponente zu beschreiben oder wie man damit interagiert. Das visuelle Textlabel und der programmatische Name müssen nicht exakt übereinstimmen, aber sie sollten ein gemeinsames Wort enthalten, das sie assoziiert (z. B. „Submit“ mit „Submit Now“).

Der Punkt ist, dass es keine Verwirrung gibt, aufgrund einer Diskrepanz zwischen dem, was gelesen und dem, was gesehen wird.

Assistive Technologie in Aktion

Nehmen wir das Beispiel eines HTML-Kontaktformulars. Ein Benutzer verwendet möglicherweise eine Spracherkennungssoftware, um ein Formular auszufüllen, und gelangt zum Ende, wo das Formular gesendet und abgeschickt wird.

Nehmen wir an, das Label des Buttons und der visuelle Text im Button sind inkonsistent

<form>
  <label>
    Message:
    <textarea name="message"></textarea>
  </label>

  <button aria-label="Submit">Send</button>
</form>

Im obigen Beispiel funktioniert der Button für assistive Technologie nicht richtig. Der Button enthält den Text „Send“, aber sein aria-label ist „Submit“. Hier liegt der Fehler. Das visuelle Label („Send“) stimmt nicht mit dem programmatischen Namen („Submit“) überein und stellt keine Verbindung zwischen beiden her.

Wenn diese übereinstimmen oder einen gemeinsamen Begriff haben, können Benutzer von Spracherkennungssoftware nach sichtbaren Textlabels von Komponenten wie Links, Buttons und Menüs navigieren. In diesem Fall könnten wir es beheben, indem wir das Label und den Text angleichen. Da der aria-label jedoch keinen Mehrwert bietet, ist das Entfernen eine bessere Lösung

<form>
  <label>
    Message:
    <textarea name="message"></textarea>
  </label>

  <button>Send</button>
</form>

Sehende Benutzer, die Screenreader verwenden, werden ebenfalls eine bessere Erfahrung haben, wenn der gehörte Text mit dem auf dem Bildschirm sichtbaren Text übereinstimmt.

Wenn das Label und der visuelle Text nicht übereinstimmen, werden Benutzer von Spracherkennung, die versuchen, das sichtbare Textlabel als Navigationsmittel zu verwenden (z. B. „move to First Name“), oder zur Auswahl, stecken bleiben, da das vom Benutzer gesprochene sichtbare Label nicht mit dem zugänglichen Namen übereinstimmt oder nicht Teil davon ist, der als Teil des Sprachbefehls aktiviert ist.

Auch wenn der zugängliche Name vom sichtbaren Label abweicht, kann er als versteckter Befehl fungieren, der von Benutzern von Spracheingabe *versehentlich* aktiviert werden kann. SC gilt nicht, wenn für eine Komponente kein sichtbares Textlabel vorhanden ist.

Code in Aktion

Hier sind drei verschiedene Fehlerzustände.

• Ein problematisches <button>-Element, bei dem das gesprochene Label und das visuelle Label keine Verbindung haben.
• Ein Label-Mismatch, bei dem der gesprochene Text mehr Inhalt liest als das visuelle Label aufgrund eines „accessibly hidden“ Spans.
• Ein Input mit einem gesprochenen Label über aria-labelledby, der es versäumt, eine Korrelation zwischen dem gesprochenen und dem visuellen Label herzustellen.

Auch dies sind alles Beispiele für schlechte Praktiken gemäß dem SC 2.5.3 Label in Name.

Im Jahr 2020 evaluierte das WebAIM Million Projekt 4,2 Millionen Formulareingaben und stellte fest, dass 55 % falsch beschriftet waren, entweder über <label>, aria-label oder aria-labelledby.

Beim Arbeiten mit Formularen sind die meisten von uns ziemlich daran gewöhnt, ein <label> mit einem <input> oder einer anderen Formularsteuerung zu verknüpfen. Das ist großartig und eine gute Möglichkeit, anzugeben, was die Steuerung tut, aber es gibt auch den programmatischen Namen der Steuerung, der auch als „zugänglicher Name“ mit einem aria-label bekannt ist.

Wir erzielen eine bessere Benutzererfahrung, wenn der Name des <label> mit dem programmatischen (oder zugänglichen) Namen im aria-label verknüpft werden kann. Wenn wir beispielsweise „First Name“ für das <label> eines Inputs verwenden, dann möchten wir wahrscheinlich, dass unser aria-label ebenfalls „First Name“ oder etwas in dieser Richtung ist. Ein Versäumnis, eine Verbindung zwischen programmatischen Namen und sichtbaren Labels herzustellen, kann für Benutzer mit kognitiven Herausforderungen eine größere Herausforderung darstellen. Es erfordert zusätzliche kognitive Belastung für Benutzer von Spracheingaben, die sich daran erinnern müssen, einen Sprachbefehl zu sagen, der vom sichtbaren Label der Steuerung abweicht. Zusätzliche kognitive Belastung entsteht auch, wenn ein Text-to-Speech-Benutzer Sprachausgaben aufnehmen und verstehen muss, die nicht mit dem sichtbaren Label verbunden werden können. Diese Formulare werden gesendet, aber es geht auf Kosten der Zugänglichkeit und behinderter Benutzer.

Hier sind die drei oben genannten Beispiele, behoben!

Text im Label Details

Gemäß dem WCAG SC sollte Text nicht als sichtbares Label betrachtet werden, wenn er symbolisch verwendet wird, anstatt ihn direkt in menschlicher Sprache auszudrücken. Ein Rich-Text-Editor ist ein gutes Beispiel dafür, da ein Editor Bilder als Text verwenden könnte (was in 1.4.5 Bilder von Text enthalten ist).

Um das Label-Text und den zugänglichen Namen übereinstimmend zu gestalten, ist es wichtig zu bestimmen, *welcher* Text für jede Komponente eines jeden Steuerelements als Label betrachtet werden sollte. Es gibt oft *mehrere* Textstrings in einer Benutzeroberfläche, die für eine Steuerung relevant sein können. Es gibt Gründe, warum das Label in unmittelbarer Nähe als Textlabel betrachtet werden sollte. Es geht darum, ein Muster der Vorhersehbarkeit für Benutzer zu schaffen, die mit einer Komponente interagieren. Diese Gründe legen nahe, dass sichtbare Labels positioniert sein sollten

• unmittelbar links von Texteingaben, Dropdown-Menüs und anderen Widgets oder Komponenten.
• unmittelbar rechts von Kontrollkästchen und Optionsfeldern.
• in Buttons oder Tabs oder unmittelbar unter Icons, die als Buttons dienen.

Satzzeichen und Groß-/Kleinschreibung können ebenfalls optional sein, wenn sie symbolisch verwendet werden. Zum Beispiel ist „First Name“ in Ordnung anstelle von „First Name:“ und „Next“ ist in Ordnung anstelle von „Next…“ und so weiter.

Eine weitere Überlegung: Komponenten ohne sichtbares Label werden vom WCAG SC nicht berücksichtigt.

Richtige Beschriftung hat seine Vorteile

Der Kernvorteil der Angleichung der Labels einer Komponente an ihren entsprechenden zugänglichen Namen ist, dass er Benutzern von Spracheingaben die Möglichkeit gibt, Steuerelemente auf einer Seite zu aktivieren, ohne den Fokus wechseln oder zwischen zwei verschiedenen Begriffen raten zu müssen.

Letztendlich sorgt die Verwendung klarer, konsistenter Terminologie zwischen dem Gesehenen und dem Gesprochenen für ein angenehmeres Benutzererlebnis – für alle –, da die von assistiven Technologien gelesenen Labels mit den sichtbaren Labels übereinstimmen, die ebenfalls gesehen und gelesen werden können. Das ist, was wir mit inklusivem Design meinen – jeder gewinnt und niemand wird ausgeschlossen.

Zusammenfassung

Wir haben gerade einige Feinheiten des WCAG 2.5.3 Erfolgskriteriums für Labels in Namen aufgeschlüsselt. Es klingt wie eine einfache Sache, der man folgen kann. Aber wie wir gesehen haben, gibt es Situationen, in denen es nicht so eindeutig ist.

Das Ziel der Einhaltung dieses Kriteriums ist natürlich, unsere Arbeit für alle Menschen zugänglich und inklusiv zu machen. Die WCAG hilft uns zu wissen, ob wir erfolgreich sind, nicht nur durch die Bereitstellung von Richtlinien, sondern auch durch die Festlegung von Konformitätsstufen (A, AA, AAA, wobei AAA die höchste ist). Text in Label fällt in die A-Kategorie, was ein Grundniveau der Konformität bedeutet. Um die Note zu erhalten, sucht die WCAG nach

[…] Benutzeroberflächenkomponenten mit Labels, die Text oder Bilder von Text enthalten, der Name enthält den Text, der visuell dargestellt wird.

Wir können testen und sicherstellen, dass unser Code vollständig und korrekt ist, indem wir uns den Quellcode der Website ansehen, die DevTools eines Browsers wie Chrome oder Firefox verwenden oder eine Zugänglichkeitsprüfung mit Tools wie der WAVE Browser Extension (Chrome und Firefox) und Axe von Deque Systems (Chrome) durchführen.

Kurz gesagt, hinter dem Glas sitzen echte Menschen, und es gibt Dinge, die wir in unserem Code und Design tun können, um ihnen die Interaktion mit den von uns erstellten Komponenten zu erleichtern. Text in Label ist nur eines von vielen Kriterien, die in den WCAG aufgeführt sind, und obwohl es wie ein kleines Detail erscheinen mag, kann die Einhaltung eine große Auswirkung auf unsere Benutzer haben.