Formular-Labels

Ein Textfeld neben dem Wort „Email“ ist erst beschriftet, wenn das label-Element mit ihm verknüpft ist; bis dahin sagt ein Screenreader vielleicht nur „Eingabefeld“.

Jedes Feld braucht einen Namen

Landet der Fokus auf einem Formularfeld, sagt ein Screenreader sein Label, seinen Typ und seinen Zustand an: „E-Mail, Eingabefeld, erforderlich“. Das Label kommt von einem label-Element, das mit dem Feld verknüpft ist. Verknüpfen kann man auf zwei Arten. Gib dem input eine id und dem label ein passendes for, oder setz das input in das label hinein. So oder so verschiebt ein Klick auf den Label-Text auch den Fokus ins Feld, und kleine Checkboxen und Optionsfelder lassen sich viel leichter treffen.

<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">

<label>
  <input type="checkbox" name="news"> Send me the weekly menu
</label>

Das WCAG-2.2-Erfolgskriterium 3.3.2 Beschriftungen oder Anweisungen auf Stufe A verlangt Beschriftungen oder Anweisungen, wann immer Inhalte eine Eingabe brauchen, und 1.3.1 Info und Beziehungen verlangt, dass die Verbindung zwischen Label und Feld im Code besteht, nicht nur auf dem Bildschirm. Ein Absatz, der zufällig über einem input steht, ist nur optisch nah. Nichts sagt assistiven Technologien, dass die beiden zusammengehören.

Platzhalter sind keine Labels

Das Attribut placeholder zeigt grauen Hinweistext in einem leeren Feld. Es ist verlockend, ihn statt eines Labels zu verwenden, und viele Anmeldeformulare tun das. Das Problem: Er verschwindet, sobald man tippt, man kann also nicht mehr nachsehen, wofür das Feld war, und er ist meist so blass, dass er die Kontrastregeln der vorigen Einheit verfehlt. Nimm ein sichtbares Label und, wenn du magst, zusätzlich einen Platzhalter mit einem Beispielwert.

Gruppen, Zweck und Fehler

Optionsfelder und zusammengehörige Checkboxen brauchen auch ein Gruppenlabel. Pack sie in ein fieldset und setz die Frage in dessen legend, damit ein Screenreader „Größe, Gruppe“ sagt, bevor „Klein, Optionsfeld, 1 von 3“ kommt. Bei persönlichen Angaben sagt das Attribut autocomplete dem Browser, wofür ein Feld da ist, mit Namen aus dem HTML-Standard wie name, email, tel, new-password und one-time-code. Kriterium 1.3.5 Bestimmung des Eingabezwecks auf Stufe AA verlangt genau das, weil Browser so Felder ausfüllen und manche Werkzeuge vertraute Icons daneben zeigen können.

Wenn etwas schiefgeht, sag es in Worten. Kriterium 3.3.1 Fehlererkennung verlangt, dass ein Eingabefehler erkannt und der Person in Textform beschrieben wird, nicht nur durch einen rot gefärbten Rahmen. Die WCAG 2.2 haben außerdem 3.3.7 Redundante Eingabe ergänzt: Angaben, die jemand im selben Ablauf schon gemacht hat, sollen automatisch wieder eingetragen oder zur Auswahl angeboten werden, statt sie zweimal tippen zu müssen. Und 3.3.8 Barrierefreie Authentifizierung (Minimum) auf Stufe AA sagt, dass ein Anmeldeschritt nicht davon abhängen darf, sich etwas zu merken oder abzuschreiben, außer es gibt Hilfe. Dass Passwortmanager das Feld ausfüllen dürfen und Einfügen erlaubt ist, zählt beides als solche Hilfe.

Vorher sagen, was gebraucht wird

Anweisungen gehören vor die Felder, die sie beschreiben, nicht in eine Fehlermeldung, nachdem jemand gescheitert ist. Muss ein Passwort mindestens 15 Zeichen haben, schreib das neben das Label. Kennzeichne Pflichtfelder im Label-Text, zum Beispiel mit dem Wort „erforderlich“, und füg das Attribut required hinzu, damit der Browser es ebenfalls ansagt. Erscheint eine Fehlermeldung, lass sie bei ihrem Feld und verknüpf beide mit aria-describedby, das auf die id der Meldung zeigt; der Screenreader liest die Meldung dann vor, wenn das Feld den Fokus bekommt. Setz zum Schluss den Fokus auf das erste Feld mit einem Problem oder auf eine Fehlerübersicht oben, damit ein Tastaturnutzer nicht am Ende eines langen Formulars sitzt und sich fragt, was passiert ist.