html-einfach.de

Barrierefreie Komponenten · Formulare

Validierung & Pflichtfelder barrierefrei

Von Zuletzt geändert am

Validierung soll helfen, nicht aussperren. Sie sagt jemandem, was noch fehlt oder nicht passt – und sollte das so tun, dass niemand am Formular scheitert, nur weil er einen Screenreader nutzt, langsamer tippt oder seine Telefonnummer mit Leerzeichen schreibt. Zwei Fragen stecken dahinter: Welche Felder sind Pflicht, und wie prüfe ich Eingaben fair?

Dieser Artikel kümmert sich um Kennzeichnung und Prüfung; wie die eigentlichen Fehlermeldungen formuliert und angekündigt werden, ist ein Thema für sich.

Pflichtfelder klar kennzeichnen

Eine Pflichtangabe muss vor dem Absenden erkennbar sein – sichtbar und programmatisch. Das native required-Attribut erledigt beides auf einmal: Es verhindert das Absenden und teilt den Zustand assistiven Technologien mit.

<label for="name">Name (Pflichtfeld)</label>
<input type="text" id="name" name="name" required />

Das Wort „Pflichtfeld“ im Label ist die eindeutigste Kennzeichnung. Sehr beliebt ist auch das Sternchen * – das ist in Ordnung, aber nur mit einer Erklärung an prominenter Stelle, denn von sich aus bedeutet ein * nichts:

<p>Mit <span aria-hidden="true">*</span> markierte Felder sind Pflichtfelder.</p>

<label for="email">E-Mail <span aria-hidden="true">*</span></label>
<input type="email" id="email" required aria-describedby="pflicht-hinweis" />

Das aria-hidden="true" am Stern verhindert, dass Screenreader ihn als „Stern“ vorlesen – die Pflicht ergibt sich ohnehin aus required. Reicht das native Attribut einmal nicht (etwa bei nachgebauten Bedienelementen), übernimmt aria-required="true" dieselbe Aussage.

Pflicht oder optional – was kennzeichnen?

Eine kleine Designfrage mit großer Wirkung: Markiert man die Pflicht- oder die optionalen Felder? Meine Regel ist pragmatisch – ich kennzeichne, was in der Minderheit ist. Sind die meisten Felder Pflicht, hebe ich die wenigen optionalen mit „(optional)“ hervor; ist es umgekehrt, markiere ich die Pflichtfelder. Das spart visuelles Rauschen und macht das Wichtige sichtbar. Felder ganz ohne jede Kennzeichnung sind dagegen immer ein Ratespiel.

Fair prüfen: Zeitpunkt und Toleranz

Wie und wann geprüft wird, entscheidet darüber, ob Validierung unterstützt oder gängelt.

  • Nicht bei jedem Tastendruck. Eine E-Mail als „ungültig“ zu melden, während man noch beim zweiten Buchstaben ist, frustriert nur. Ich prüfe beim Absenden – und danach gern erneut beim Verlassen eines Feldes (blur), das schon einmal beanstandet wurde.
  • Eingaben tolerant entgegennehmen. Telefonnummern mit Leerzeichen, IBANs in Vierergruppen, Namen mit Bindestrich: Was eindeutig gemeint ist, sollte akzeptiert und intern normalisiert werden, statt es zurückzuweisen.
  • Niemals das Einfügen blockieren. onpaste zu unterbinden – gern bei Passwort- oder E-Mail-Feldern gesehen – ist eine echte Barriere, gerade für Passwortmanager. Das mache ich grundsätzlich nicht.

Diese Toleranz ist kein Komfort-Extra. Wer Eingaben unnötig streng formatiert, sperrt reale Menschen aus – und das widerspricht dem Grundgedanken der vier Prinzipien der WCAG.

Native Validierung als Fundament

HTML bringt eine erstaunlich fähige Constraint-Validierung mit, die ich gern als Basis nehme und nur dort mit JavaScript ergänze, wo es nötig wird:

<label for="plz">Postleitzahl</label>
<input
  type="text"
  id="plz"
  inputmode="numeric"
  pattern="\d{5}"
  required
  autocomplete="postal-code"
  aria-describedby="plz-hilfe"
/>
<p id="plz-hilfe">Fünf Ziffern, z. B. 10115.</p>

Drei Dinge erledigt dieses Beispiel nebenbei: inputmode="numeric" blendet auf dem Smartphone die Zifferntastatur ein, pattern definiert das erlaubte Format, und autocomplete="postal-code" lässt den Browser bekannte Werte vorschlagen. Gerade autocomplete unterschätzen viele – es hilft allen, ist aber für Menschen mit kognitiven oder motorischen Einschränkungen ein echter Gewinn (und erfüllt WCAG 1.3.5).

Zusammenspiel mit Gruppen

Auch eine Gruppe kann Pflicht sein – etwa „mindestens eine Option wählen“. Die Kennzeichnung gehört dann in die <legend>, nicht an ein einzelnes Feld. Wie du solche Gruppen aufbaust, steht unter fieldset & legend.

Häufige Fehler

  • Pflichtfelder nur per Farbe markiert. Ohne Text oder required bleibt die Pflicht für viele unsichtbar.
  • Stern ohne Erklärung. Ein * allein sagt nichts – die Legende dazu fehlt oft.
  • Validierung bei jedem Tastendruck. Meldet Fehler, bevor die Eingabe fertig ist.
  • Zu strenge Formate. Leerzeichen oder Bindestriche werden abgelehnt, obwohl die Eingabe eindeutig ist.
  • Einfügen blockiert. Bricht Passwortmanager und Kopieren – eine vermeidbare Hürde.

Häufige Fragen

required oder aria-required?

Wo immer es geht required: Es kennzeichnet das Feld und erzwingt die Eingabe. aria-required="true" nutzt du nur, wenn das native Attribut nicht greift, etwa bei einem mit ARIA nachgebauten Bedienelement.

Soll ich das Absenden des Formulars deaktivieren, bis alles stimmt?

Davon rate ich ab. Ein dauerhaft ausgegrauter Absenden-Button verrät nicht, was fehlt, und ist für Tastatur- und Screenreader-Nutzung oft schwer zu deuten. Besser: absenden lassen, prüfen, klar zurückmelden.

Muss ich Eingaben trotzdem serverseitig prüfen?

Unbedingt. Clientseitige Validierung ist Komfort, keine Sicherheit – sie lässt sich umgehen. Die verbindliche Prüfung passiert immer auf dem Server.

Fazit

Barrierefreie Validierung heißt: Pflichtfelder sichtbar und programmatisch kennzeichnen (am besten mit required), zum richtigen Zeitpunkt prüfen und Eingaben tolerant entgegennehmen. Native HTML-Attribute liefern das Fundament, JavaScript ergänzt nur, wo nötig. Das Ziel bleibt immer dasselbe – Menschen durch das Formular helfen, nicht an ihm scheitern lassen.