HTML-Eingabefelder und Labels: Eine Liebes geschichte

Avatar of Amber Wilson
Amber Wilson am

DigitalOcean bietet Cloud-Produkte für jede Phase Ihrer Reise. Starten Sie mit 200 $ kostenlosem Guthaben!

Die meisten Eingabefelder haben etwas gemeinsam – sie sind am glücklichsten mit einem Begleitlabel! Und das Glück hört hier nicht auf. Formulare mit ordnungsgemäßen Eingabefeldern und Labels sind für Menschen viel einfacher zu bedienen, und das macht die Menschen auch glücklich.

Ein glückliches Label- und Eingabefeld-Paar

In diesem Beitrag möchte ich mich auf Situationen konzentrieren, in denen das Fehlen einer semantischen Kombination aus Label und Eingabefeld es für alle Arten von Menschen schwieriger macht, Formulare auszufüllen. Da Millionen von Menschen ihren Lebensunterhalt mit Formularen verdienen, lassen Sie uns in die besten Tipps eintauchen, die ich kenne, um eine erfüllende und harmonische Beziehung zwischen einem Eingabefeld und einem Label zu schaffen.

Inhaltswarnung: In diesem Beitrag werden Themen wie Liebe und Beziehungen behandelt.

Die Liebesgeschichte beginnt hier! Lassen Sie uns die Grundlagen für die Erstellung glücklicher Labels und Eingabefelder behandeln.

Wie man ein Label und ein Eingabefeld koppelt

Es gibt zwei Möglichkeiten, ein Label und ein Eingabefeld zu koppeln. Eine besteht darin, das Eingabefeld in ein Label zu wickeln (implizit), und die andere besteht darin, dem Label ein for-Attribut und dem Eingabefeld eine id hinzuzufügen (explizit).

Stellen Sie sich ein implizites Label als Umarmung eines Eingabefeldes vor und ein explizites Label als daneben stehend und seine Hand haltend.

<label> 
  Name:
  <input type="text" name="name" />
</label>

Der Wert des for-Attributs eines expliziten Labels muss mit dem Wert der id seines Eingabefeldes übereinstimmen. Wenn for beispielsweise den Wert name hat, sollte id ebenfalls den Wert name haben.

<label for="name">Name: </label>
<input type="text" id="name" name="name" />

Leider wird ein implizites Label nicht von allen assistiven Technologien korrekt behandelt, auch wenn for- und id-Attribute verwendet werden. Daher ist es immer am besten, ein explizites Label anstelle eines impliziten Labels zu verwenden.

<!-- IMPLICIT LABEL (not recommended for use) - the label wraps the input. -->
<label> 
  Name:
  <input type="text" name="name" />
</label>

<!-- EXPLICIT LABEL (recommended for use) - the label is connected to an input via "for" and "id" -->
<label for="explicit-label-name">Name: </label>
<input type="text" id="explicit-label-name" name="name" />

Jedes einzelne Eingabefeld sollte nur mit einem Label gekoppelt sein. Und ein Label sollte nur mit einem Eingabefeld gekoppelt sein. Ja, Eingabefelder und Labels sind monogam. ♥️

Hinweis: Es gibt eine Art Ausnahme von dieser Regel: wenn wir mit einer Gruppe von Eingabefeldern arbeiten, z. B. mehreren Radio-Buttons oder Checkboxen. In diesen Fällen wird ein <legend>-Element verwendet, um bestimmte Eingabefeld-Elemente, wie z. B. Radio-Buttons, zu gruppieren und als zugängliches Label für die gesamte Gruppe zu dienen.

Nicht alle Eingabefelder benötigen Labels

Ein Eingabefeld mit type="submit" oder type="button" benötigt kein Label – das value-Attribut fungiert stattdessen als zugänglicher Label-Text. Ein Eingabefeld mit type="hidden" ist ebenfalls ohne Label in Ordnung. Aber alle anderen Eingabefelder, einschließlich <textarea> und <select>-Elementen, sind am glücklichsten mit einem Label-Begleiter.

Was gehört in ein Label

Der Inhalt, der in ein Label gehört, sollte

  • Sein Partner-Eingabefeld beschreiben. Ein Label möchte jedem zeigen, dass es zu seinem Eingabefeld-Partner gehört.
  • Sichtbar sein. Ein Label kann angeklickt oder angetippt werden, um sein Eingabefeld zu fokussieren. Der zusätzliche Platz, den es zur Interaktion mit dem Eingabefeld bietet, ist von Vorteil, da er die Tipp- oder Klickfläche vergrößert. Darauf werden wir gleich noch näher eingehen.
  • Nur einfachen Text enthalten. Fügen Sie keine Elemente wie Überschriften oder Links hinzu. Auch hier werden wir weiter unten auf das „Warum“ eingehen.

Eine nützliche Sache, die Sie mit dem Inhalt eines Labels tun können, ist das Hinzufügen von Formatierungshinweisen. Zum Beispiel wird das Label für <input type="date" id="date"> wie erwartet <label for="date"> sein. Aber dann können wir dem Benutzer einen Hinweis geben, dass das Datum in einem bestimmten Format eingegeben werden muss, z. B. TT-MM-JJJJ, in Form eines <span> zwischen dem Label und dem Eingabefeld, das diese Anforderung angibt. Der Hinweis gibt nicht nur das Datumsformat an, sondern hat auch einen id-Wert, der einem aria-describedby-Attribut am Eingabefeld entspricht.

<!-- Describes what the input is for - should be plain text only -->
<label for="date">Start date</label>
<!-- Describes additional information, usually about formatting -->
<span id="date-format">(DD-MM-YYYY):</span>
<input type="date" id="date" aria-describedby="date-format" min="2021-03-01" max="2031-01-01" />

Auf diese Weise erhalten wir den Vorteil eines klaren Labels, das beschreibt, wofür das Eingabefeld bestimmt ist, und einen zusätzlichen Hinweis für den Benutzer, dass das Eingabefeld in einem bestimmten Format eingegeben werden muss.

Bewährte Praktiken für eine gesunde Beziehung

Die folgenden Tipps gehen über die Grundlagen hinaus und erklären, wie sichergestellt werden kann, dass ein Label und ein Eingabefeld so glücklich wie möglich sind.

Tun Sie: Fügen Sie ein Label an der richtigen Stelle hinzu

Es gibt ein WCAG-Erfolgskriterium, das besagt die visuelle Reihenfolge einer Seite sollte der Reihenfolge entsprechen, in der Elemente im DOM erscheinen. Das liegt daran,

Ein Benutzer mit eingeschränktem Sehvermögen, der eine Bildschirmlupe in Kombination mit einem Screenreader verwendet, kann verwirrt sein, wenn die Lesereihenfolge auf dem Bildschirm zu springen scheint. Ein Tastaturnutzer kann Schwierigkeiten haben vorherzusagen, wohin der Fokus als nächstes springt, wenn die Quellreihenfolge nicht mit der visuellen Reihenfolge übereinstimmt.

Denken Sie darüber nach. Wenn wir Standard-HTML haben, bei dem das Label vor dem Eingabefeld steht

<label for="orange">Orange</label>
<input type="checkbox" id="orange" name="orange">

Das platziert das Label vor dem Eingabefeld im DOM. Aber nehmen wir jetzt an, unser Label und Formular sind in einem flexiblen Container und wir verwenden CSS order, um Dinge umzukehren, bei denen das Eingabefeld visuell vor dem Label steht

label { order: 2; }
input { order: 1; }

Ein Screenreader-Benutzer, der zwischen Elementen navigiert, könnte erwarten, dass das Eingabefeld vor dem Label den Fokus erhält, weil das Eingabefeld visuell zuerst kommt. Aber was wirklich passiert, ist, dass das Label stattdessen den Fokus erhält. Sehen Sie hier für den Unterschied zwischen der Navigation mit einem Screenreader und einer Tastatur.

Wir sollten uns dessen bewusst sein. Es ist üblich, das Label für Checkboxen und Radio-Buttons rechts neben dem Eingabefeld zu platzieren. Dies kann erreicht werden, indem das Label *nach* dem Eingabefeld im HTML platziert wird, um sicherzustellen, dass DOM- und visuelle Reihenfolge übereinstimmen.

<form>
  <!-- Checkbox with label on the right -->
  <span>
    <input type="checkbox" id="orange" name="orange">
    <label for="orange">Orange</label>
  </span>
  <!-- Radio button with label on the right -->
  <span>
    <input type="radio" id="banana" name="banana">
    <label for="banana">Banana</label>
  </span>
  <!-- Text input with label on the left -->
  <span>
    <label for="apple">How do you like them apples?</label>
    <input type="text" id="apple" name="apple">
  </span>
</form>

Tun Sie: Prüfen Sie Eingabefelder mit einem Screenreader

Ob ein Eingabefeld von Grund auf neu geschrieben oder mit einer Bibliothek erstellt wurde, es ist eine gute Idee, Ihre Arbeit mit einem Screenreader zu überprüfen. Dies dient dazu, sicherzustellen, dass

  • Alle relevanten Attribute vorhanden sind – insbesondere die übereinstimmenden Werte der for- und id-Attribute.
  • Der DOM entspricht der visuellen Reihenfolge.
  • Der Label-Text klingt klar. Zum Beispiel wird "tt-mm-jjjj" anders vorgelesen als seine Großbuchstaben-Entsprechung (TT-MM-JJJJ).
Screen reader reading out a lower case and upper case date input hint.
Nur weil die Buchstaben gleich sind, heißt das nicht, dass sie von einem Screenreader genauso vorgelesen werden.

In den letzten Jahren habe ich JavaScript-Bibliotheken wie downshift verwendet, um komplexe Formularelemente wie Autocomplete oder Comboboxen auf nativer HTML aufzubauen, wie Eingabefelder oder Selects. Die meisten Bibliotheken machen diese komplexen Elemente zugänglich, indem sie ARIA-Attribute mit JavaScript hinzufügen.

Die Vorteile nativer HTML-Elemente, die mit JavaScript erweitert wurden, gehen jedoch vollständig verloren, wenn JavaScript fehlerhaft ist oder deaktiviert ist, was sie unzugänglich macht. Prüfen Sie dies also und stellen Sie eine serverseitig gerenderte Alternative ohne JavaScript als sichere Fallback-Lösung bereit.

Sehen Sie sich diese grundlegenden Formular-Tests an, um festzustellen, wie ein Eingabefeld und sein Begleitlabel oder seine Legende geschrieben und von verschiedenen Screenreadern angekündigt werden sollten.

Tun Sie: Machen Sie das Label sichtbar

Die Verbindung eines Labels mit einem Eingabefeld ist wichtig, aber ebenso wichtig ist es, das Label sichtbar zu halten. Das Klicken oder Tippen auf ein sichtbares Label fokussiert sein Partner-Eingabefeld. Dies ist ein natives HTML-Verhalten, das einer riesigen Anzahl von Menschen zugute kommt.

Stellen Sie sich ein Label vor, das stolz seine Verbindung mit einem Eingabefeld zeigen möchte

A visible happy label proudly showing off its input partner.
Ein Label möchte wirklich seinen Armschmuck des Eingabefeldes zur Schau stellen. 💪🍬

Das heißt, es wird Zeiten geben, in denen ein Design ein verstecktes Label erfordert. Wenn ein Label versteckt werden muss, ist es daher entscheidend, dies auf zugängliche Weise zu tun. Ein häufiger Fehler ist die Verwendung von display: none oder visibility: hidden, um ein Label zu verstecken. Diese CSS-Display-Eigenschaften verstecken ein Element vollständig – nicht nur visuell, sondern auch für Screenreader.

Erwägen Sie die Verwendung des folgenden Codes, um Labels visuell zu verstecken

/* For non-natively-focusable elements. For natively focusable elements */
/* Use .visually-hidden:not(:focus):not(:active) */
.visually-hidden {
  border-width: 0 !important;
  clip: rect(1px, 1px, 1px, 1px) !important;
  height: 1px !important;
  overflow: hidden !important;
  padding: 0 !important;
  position: absolute !important;
  white-space: nowrap !important;
  width: 1px !important;
}

Kitty Giraudel erklärt ausführlich , wie man Inhalte verantwortungsbewusst versteckt.

Was zu vermeiden ist

Um eine gesunde Beziehung zwischen Eingabefeldern und Labels zu erhalten und aufrechtzuerhalten, gibt es einige Dinge, die Sie bei der Kopplung vermeiden sollten. Lassen Sie uns darauf eingehen, was diese sind und wie Sie sie verhindern können.

Nicht tun: Erwarten Sie, dass Ihr Eingabefeld in jedem Browser gleich ist

Es gibt bestimmte Arten von Eingabefeldern, die in einigen älteren Desktop-Browsern nicht unterstützt werden. Zum Beispiel wird ein Eingabefeld vom Typ type="date" in Internet Explorer (IE) 11 oder sogar in Safari 141 (veröffentlicht im September 2020) nicht unterstützt. Ein solches Eingabefeld fällt auf type="text" zurück. Wenn ein Datums-Eingabefeld kein klares Label hat und in älteren Browsern automatisch auf ein Text-Eingabefeld zurückfällt, können Benutzer verwirrt werden.

Nicht tun: Ein Label durch einen Platzhalter ersetzen

Hier ist, warum ein placeholder-Attribut bei einem Eingabefeld nicht anstelle eines Labels verwendet werden sollte

  • Nicht alle Screenreader kündigen Platzhalter an.
  • Der Wert eines placeholder ist in Gefahr, auf kleineren Geräten abgeschnitten zu werden oder wenn eine Seite im Browser übersetzt wird. Im Gegensatz dazu kann der Textinhalt eines Labels leicht in eine neue Zeile umgebrochen werden.
  • Nur weil ein Entwickler den hellgrauen placeholder-Text auf seinem großen Retina-Bildschirm, in einem gut beleuchteten Raum, in einer ablenkungsfreien Umgebung sehen kann, heißt das nicht, dass jeder andere das kann. Ein placeholder kann selbst Menschen mit guter Sehkraft dazu bringen, die Augen zusammenzukneifen und schließlich aufzugeben.
An input on a mobile device where the placeholder text is cut off.
Stellen Sie sicher, dass dies irgendwo ist, wo ich was sehen kann? Es ist schwer zu erkennen, wenn der Platzhalter so abgeschnitten wird.
An input where the translated placeholder is cut off.
Arbeiten Sie an einer mehrsprachigen Website? Ein übersetzter Platzhalter kann abgeschnitten werden, obwohl die englische Übersetzung einwandfrei ist. In diesem Fall sollte der übersetzte Platzhalter „Durchsuchen Sie die Dokumentation.“ lauten.

  • Sobald ein Zeichen in ein Eingabefeld eingegeben wurde, wird sein placeholder unsichtbar – sowohl visuell als auch für Screenreader. Wenn jemand zurückgehen muss, um Informationen zu überprüfen, die er in ein Formular eingegeben hat, muss er die eingegebenen Informationen löschen, nur um den Platzhalter wieder zu sehen.
  • Das placeholder-Attribut wird in IE 9 und darunter nicht unterstützt und verschwindet, wenn ein Eingabefeld in IE 11 fokussiert wird. Eine weitere Anmerkung: Die Platzhalterfarbe kann in IE 11 mit CSS nicht angepasst werden.

Platzhalter sind wie der Freund, der auftaucht, wenn alles perfekt ist, aber verschwindet, wenn man ihn am dringendsten braucht. Koppeln Sie ein Eingabefeld mit einem schönen, kontrastreichen Label. Labels sind nicht unzuverlässig und sind ihren Eingabefeldern 100 % der Zeit treu.

Die Nielsen Norman Group hat einen ausführlichen Artikel, der erklärt , warum Platzhalter in Formularfeldern schädlich sind.

Nicht tun: Ein Label durch ein anderes Attribut oder Element ersetzen

Wenn kein Label vorhanden ist, suchen einige Screenreader nach angrenzendem Text und kündigen diesen stattdessen an. Dies ist ein Treffer-oder-Miss-Ansatz, da es möglich ist, dass ein Screenreader keinen Text zum Ankündigen findet.

Der folgende Code-Schnipsel stammt von einer echten Website. Das Label wurde durch ein <span>-Element ersetzt, das semantisch nicht mit dem Eingabefeld verbunden ist.

<div>
  <span>Card number</span>
  <div>
    <input type="text" value="" id="cardNumber" name="cardNumber" maxlength="40">
  </div>
</div>

Der obige Code sollte zur Gewährleistung der Barrierefreiheit neu geschrieben werden, indem der Span durch ein Label mit for="cardNumber" ersetzt wird. Dies ist bei weitem die einfachste und robusteste Lösung, die den meisten Menschen zugute kommt.

Obwohl ein Label durch einen Span mit einer id, deren Wert mit dem aria-labelledby-Attribut des Eingabefeldes übereinstimmt, ersetzt werden könnte, können die Leute den Span nicht anklicken, um das Eingabefeld zu fokussieren, wie es ein Label ermöglicht. Es ist immer am besten, die Kraft nativer HTML-Elemente zu nutzen, anstatt sie neu zu erfinden. Die Liebesgeschichte zwischen nativen Eingabe- und Label-Elementen muss nicht neu geschrieben werden! Sie ist so, wie sie ist, großartig.

Nicht tun: Interaktive Elemente in Labels platzieren

Nur einfacher Text sollte in einem Label enthalten sein. Vermeiden Sie die Einfügung von Dingen wie Überschriften oder interaktiven Elementen wie Links. Nicht alle Screenreader kündigen ein Label korrekt an, wenn es etwas anderes als einfachen Text enthält. Wenn jemand ein Eingabefeld anklicken möchte, um es zu fokussieren, aber dieses Label einen Link enthält, kann er versehentlich auf den Link klicken.

<form>
  <div>
    <!-- Don't do this -->
    <input type="checkbox" id="t-and-c" name="name" />
    <label for="t-and-c">I accept the <a href="https://link.com">terms and conditions</a></label>
  </div>
  <div>
    <!-- Try this -->
    <input type="checkbox" id="t-and-c2" name="name" />
    <label for="t-and-c2">I accept the terms and conditions.</label>
    <span>Read <a href="https://link.com">terms and conditions</a></span>
  </div>
</form>

Beispiele aus der Praxis

Ich finde immer, dass Beispiele aus der Praxis mir helfen, etwas richtig zu verstehen. Ich habe das Web durchsucht und Beispiele für Labels und Eingabefelder aus einer beliebten Komponentenbibliothek und Website gefunden. Unten erkläre ich, wo die Elemente Mängel aufweisen und wie sie verbessert werden können, um eine bessere Kopplung zu gewährleisten.

Komponentenbibliothek: Material

MaterialUI ist eine React-Komponentenbibliothek, die auf Googles Designsystem basiert. Sie beinhaltet eine Textfeldeingabekomponente mit einem schwebenden Label-Muster, das für viele Designer und Entwickler zu einem beliebten Standard geworden ist.

Das schwebende Label-Muster beginnt mit dem Label an der Platzhalter-Position, das das Label an seine richtige Stelle über dem Feld verschiebt. Die Idee ist, dass dies ein minimales Design erreicht und gleichzeitig das Problem verschwindender Platzhalter beim Tippen löst.

Das Klicken auf das Eingabefeld fühlt sich flüssig an und sieht gut aus. Aber das ist das Problem. Seine Qualitäten sind hauptsächlich oberflächlich.

Zum Zeitpunkt der Erstellung dieses Beitrags sind einige Probleme, die ich mit dieser Komponente festgestellt habe:

  • Es gibt keine Option, das Label außerhalb des Eingabefeldes zu haben, um eine größere Interaktionsfläche für das Fokussieren des Eingabefeldes zu bieten.
  • Es gibt eine Option, einen Hinweis hinzuzufügen, wie wir zuvor gesehen haben. Leider ist der Hinweis nur durch Nähe mit dem Eingabefeld verbunden und nicht durch eine übereinstimmende id und aria-describedby. Das bedeutet, dass nicht alle Screenreader die Hilfsnachricht mit dem Eingabefeld verknüpfen können.
  • Das Label befindet sich im DOM hinter dem Eingabefeld, wodurch die visuelle Reihenfolge falsch ist.
  • Das leere Eingabefeld sieht aus, als wäre es bereits ausgefüllt, zumindest solange es nicht aktiv ist.
  • Das Label gleitet nach oben, wenn auf das Eingabefeld geklickt wird, was es für diejenigen ungeeignet macht, die reduzierte Bewegungen bevorzugen.

Adam Silver erklärt auch , warum schwebende Labels problematisch sind und geht in eine detaillierte Kritik an Materials Text-Eingabefeld-Design.

Website: Huffpost

Die Huffpost-Website enthält Artikel mit einem Newsletter-Anmeldeformular.

Huffpost newsletter signup form
Dieses Formular sieht recht gut aus, könnte aber verbessert werden.

Zum Zeitpunkt der Erstellung dieses Blogbeitrags könnte das von Huffpost verwendete E-Mail-Eingabefeld von einer Reihe von Verbesserungen profitieren.

  • Das Fehlen eines Labels bedeutet eine kleinere Klick- oder Tippfläche. Anstelle eines Labels gibt es ein aria-label-Attribut am Eingabefeld.
  • Die Schriftgröße des placeholder und der Eingabefeldwerte beträgt winzige 11 Pixel, was schwer zu lesen sein kann.
  • Das gesamte Eingabefeld verschwindet ohne JavaScript, was bedeutet, dass die Leute keine Möglichkeit haben, sich für den Newsletter anzumelden, wenn JavaScript deaktiviert oder fehlerhaft ist.

Schlussbemerkungen

Eine überraschende Anzahl von Menschen hat Schwierigkeiten, Informationen in schlecht konstruierte Eingabefelder einzugeben. Zu dieser Liste gehören Menschen mit kognitiven, motorischen und körperlichen Behinderungen, Autismus-Spektrum-Störungen, Hirnverletzungen und Sehbehinderungen. Andere Menschen, die Schwierigkeiten haben, sind diejenigen, die es eilig haben, eine schlechte Verbindung haben, ein kleines Gerät benutzen, ein altes Gerät benutzen und mit digitalen Formularen nicht vertraut sind, unter vielen anderen.

Darüber hinaus gibt es zahlreiche Gründe, warum JavaScript fehlschlagen oder in einem Browser deaktiviert sein kann, was bedeutet, dass Eingabefelder funktionsunfähig oder völlig unzugänglich werden. Es gibt auch Menschen, die voll und ganz in der Lage sind, eine Webseite anzuzeigen, die aber möglicherweise eine Tastatur zusammen mit einem Screenreader verwenden.

Die Botschaft, die ich vermitteln möchte, ist, dass glückliche Label- und Eingabefeld-Paare entscheidend sind. Es spielt keine Rolle, ob Ihr Formular schön ist, wenn es unbrauchbar ist. Ich wette, fast jeder füllt lieber ein hässliches, aber einfach zu bedienendes Formular aus als ein hübsches, das Probleme verursacht.

Danksagung

Ich möchte den folgenden Personen herzlich für ihre Hilfe bei diesem Beitrag danken: Eric Eggert, Adam Silver, Dion Dajka und Kitty Giraudel. Ihr gebündeltes Wissen über Barrierefreiheit ist eine Macht, mit der man rechnen muss!

Fußnoten

  • 1 Der Datepicker ist in iOS 14 tatsächlich gut unterstützt und sehr gut. Man könnte sich vorstellen, dass eine macOS-Version am Horizont auftaucht.