Formulare, die jeder ausfüllen kann

Jedes Feld braucht eine sichtbare Beschriftung

Ein Platzhalter im Feld ist keine Beschriftung. Er verschwindet, sobald jemand tippt, hat oft zu wenig Kontrast und wird nicht von jedem Screenreader vorgelesen. Geben Sie jedem Feld ein sichtbares <label> und verknüpfen Sie es über for und id. Dann liest der Screenreader den Namen vor, und ein Klick auf die Beschriftung setzt den Fokus ins Feld, was auch Menschen mit zittriger Hand hilft.

Das betrifft 1.3.1 Info und Beziehungen, 3.3.2 Beschriftungen oder Anweisungen und 4.1.2 Name, Rolle, Wert. Steht im sichtbaren Text etwas anderes als im zugänglichen Namen, scheitern Menschen mit Sprachsteuerung (2.5.3 Beschriftung im Namen).

<input type="email" placeholder="E-Mail">

<label for="mail">E-Mail-Adresse</label>
<input id="mail" type="email" name="email"
  autocomplete="email">

Das Label bleibt sichtbar, ist mit dem Feld verknüpft und vergrößert die Klickfläche.

Gruppen, Pflichtfelder und Hinweise

Gehören Felder zusammen, etwa Radiobuttons zur Anrede oder die Teile einer Adresse, fassen Sie sie in ein <fieldset> mit <legend>. So hört man beim Wechsel in die Gruppe, worum es geht.

• Pflichtfelder kennzeichnen Sie im sichtbaren Text, zum Beispiel mit „(Pflichtfeld)“, und zusätzlich mit dem Attribut required. Ein rotes Sternchen allein reicht nicht, denn Farbe darf nicht die einzige Information sein (1.4.1 Benutzung von Farbe).
• Formatvorgaben wie „TT.MM.JJJJ“ gehören vor das Feld, nicht erst in die Fehlermeldung. Verknüpfen Sie den Hinweis über aria-describedby.
• Keine Zeitfallen: Läuft eine Sitzung ab, warnen Sie vorher und bieten Sie eine Verlängerung an (2.2.1 Zeitbegrenzung anpassbar).

<p>Zahlungsart *</p>
<input type="radio" name="pay" id="p1">
<label for="p1">Rechnung</label>

<fieldset>
  <legend>Zahlungsart (Pflichtfeld)</legend>
  <input type="radio" name="pay" id="p1" required>
  <label for="p1">Rechnung</label>
  <input type="radio" name="pay" id="p2">
  <label for="p2">Lastschrift</label>
</fieldset>

Autovervollständigung spart Tipparbeit

Mit dem Attribut autocomplete erkennt der Browser, welche Angabe gefragt ist, und kann sie aus gespeicherten Daten einsetzen. Für Felder, die Angaben zur Person abfragen, verlangt 1.3.5 Eingabezweck bestimmen genau das. Davon profitieren Menschen mit motorischen Einschränkungen, mit Lese- oder Gedächtnisschwierigkeiten und alle, die auf dem Smartphone bestellen.

Verwenden Sie die Werte aus der HTML-Spezifikation, etwa name, given-name, email, tel, street-address, postal-code oder bday. Eigene Fantasiewerte erkennt der Browser nicht.

Ebenso wichtig: Fragen Sie nichts doppelt ab. Hat jemand die Lieferadresse schon eingegeben, bieten Sie sie für die Rechnungsadresse an, statt sie erneut zu verlangen (3.3.7 Redundante Eingabe).

Fehlermeldungen, die weiterhelfen

Ein roter Rahmen um ein Feld sagt einem Screenreader nichts und vielen Menschen mit Farbsehschwäche auch nicht. Eine gute Fehlermeldung erfüllt drei Aufgaben:

1. Sie benennt das Feld und das Problem in Text (3.3.1 Fehlererkennung): „Bitte geben Sie Ihre Postleitzahl ein.“ statt „Ungültige Eingabe“.
2. Sie schlägt eine Lösung vor, wenn eine bekannt ist (3.3.3 Fehlerempfehlung): „Die Postleitzahl hat fünf Ziffern, zum Beispiel 10115.“
3. Sie ist am Feld technisch verknüpft: über aria-describedby, dazu aria-invalid mit dem Wert true am Feld.

Prüfen Sie erst beim Absenden oder beim Verlassen des Feldes, nicht bei jedem Tastendruck. Bei mehreren Fehlern hilft eine Zusammenfassung oben im Formular mit Links zu den Feldern; setzen Sie den Fokus auf diese Zusammenfassung. Eine lauffähige Vorlage finden Sie im Muster Formularfeld mit Fehlermeldung.

<input id="plz" class="error">
<span class="red">Fehler</span>

<label for="plz">Postleitzahl</label>
<input id="plz" name="plz" inputmode="numeric"
  autocomplete="postal-code"
  aria-invalid="true" aria-describedby="plz-err">
<p id="plz-err">Die Postleitzahl hat fünf
  Ziffern, zum Beispiel 10115.</p>

Der Fehlertext steht neben dem Feld, wird beim Fokus vorgelesen und nennt die Lösung.

Vor dem Absenden: prüfen, bestätigen, korrigieren

Bei Bestellungen, Verträgen, Zahlungen und Angaben mit rechtlichen Folgen verlangt 3.3.4 Fehlervermeidung (rechtlich, finanziell, Daten) mindestens eine dieser Möglichkeiten: Die Eingabe lässt sich rückgängig machen, sie wird auf Fehler geprüft und kann korrigiert werden, oder es gibt eine Übersicht zum Prüfen und Bestätigen vor dem endgültigen Absenden. Im Shop ist das die Bestellübersicht mit „Ändern“-Links zu jedem Schritt.

Anmeldung ohne Gedächtnistest

Neu in WCAG 2.2 ist 3.3.8 Barrierefreie Authentifizierung (Minimum): Für die Anmeldung darf niemand gezwungen werden, sich etwas zu merken, abzuschreiben oder ein Rätsel zu lösen, wenn es keine Alternative gibt. In der Praxis heißt das:

• Einfügen in Passwort- und Codefelder nicht blockieren, damit Passwortmanager funktionieren.
• autocomplete="username", "current-password" und "one-time-code" setzen.
• Einmalcodes nicht auf mehrere Einzelfelder verteilen, in die man Ziffer für Ziffer tippen muss, ohne einfügen zu können.
• Alternativen anbieten, etwa einen Anmeldelink per E-Mail oder Passkeys.

Wie Sie Spamschutz ohne Rätsel lösen, steht im Ratgeber CAPTCHAs und Alternativen.

<input type="password"
  onpaste="return false">

<label for="pw">Passwort</label>
<input id="pw" type="password"
  autocomplete="current-password">

Checkliste zum Abhaken

Passende WCAG-Kriterien

• 1.3.1 Info und Beziehungen
• 1.3.5 Eingabezweck bestimmen
• 3.3.1 Fehlererkennung
• 3.3.2 Beschriftungen oder Anweisungen
• 3.3.3 Fehlerempfehlung
• 3.3.4 Fehlervermeidung (rechtlich, finanziell, Daten)
• 3.3.7 Redundante Eingabe
• 3.3.8 Barrierefreie Authentifizierung (Minimum)

Werkzeuge und Muster dazu

• Fehlermeldungen, die helfen statt verwirrenFehler als Text, verknüpft, mit Lösung und Fehlerübersicht.
• ChecklistenFür Design, Entwicklung, Redaktion
• Spam abwehren, ohne Menschen auszusperrenEin CAPTCHA soll Bots aufhalten und hält oft Menschen auf: wer blind ist, schlecht sieht, schlecht hört oder Rätsel schwer lösen kann. Es gibt bessere Wege gegen Spam.
• Kostenlos prüfenIhre Startseite in zwei Minuten automatisch prüfen

Häufige Fragen

Quellen

• W3C WAI: Forms Tutorial
• W3C: Understanding 3.3.1 Error Identification
• W3C: Understanding 1.3.5 Identify Input Purpose
• W3C: Understanding 3.3.8 Accessible Authentication (Minimum)
• WHATWG HTML: Autofill
• W3C: WCAG 2.2