Formulare

Barrierefreie Formulare und Fehlermeldungen

Begriffe vorab

• Label: die sichtbare Beschriftung eines Formularfelds.
• Fehlermeldung: Hinweis, was falsch ist und wie es behoben wird.
• Autovervollständigung: Vorschläge des Browsers anhand gespeicherter Daten.

Formulare sind eine der fehleranfälligsten Stellen für Barrierefreiheit, weil hier Eingabe, Beschriftung, Fehlerprüfung und Fokus zusammenspielen müssen.

Jedes Feld braucht ein echtes Label

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

Ein <label> mit passendem for/id-Paar verknüpft Beschriftung und Feld fest. Ein bloßer Platzhaltertext (placeholder) ist kein Ersatz: Er verschwindet bei der Eingabe, hat oft zu wenig Kontrast und wird von manchen Screenreadern nicht zuverlässig vorgelesen (WCAG 3.3.2, 1.3.1).

Fehler klar benennen

WCAG 3.3.1 verlangt, dass Fehler in Text identifiziert und beschrieben werden, nicht nur farblich markiert. Eine gute Fehlermeldung nennt das betroffene Feld und erklärt, was zu tun ist:

<p id="email-error" role="alert">E-Mail-Adresse: Bitte ein gültiges Format wie name@beispiel.de eingeben.</p>
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">

aria-describedby verknüpft die Fehlermeldung mit dem Feld, aria-invalid="true" signalisiert den fehlerhaften Zustand, und role="alert" (bzw. eine aria-live-Region) sorgt dafür, dass Screenreader die neue Meldung automatisch ansagen.

Gruppierung und Pflichtfelder

<fieldset> mit <legend> gruppiert zusammengehörige Felder, etwa eine Reihe von Radiobuttons, und gibt der Gruppe eine gemeinsame Beschriftung. Pflichtfelder sollten nicht nur farblich, sondern auch textlich oder mit einem Symbol plus Erläuterung gekennzeichnet sein (siehe Lektion zu Farben).

Ausfüllhilfen (WCAG 2.2, Kriterium 1.3.5 und 3.3.7/3.3.8)

WCAG empfiehlt, den Zweck von Eingabefeldern zusätzlich maschinenlesbar zu machen, etwa über autocomplete-Attribute (autocomplete="email", autocomplete="tel"), damit Browser und Hilfsmittel beim Ausfüllen unterstützen können. Neuere WCAG-2.2-Kriterien verlangen außerdem, dass bereits bekannte Informationen nicht erneut abgefragt werden müssen und dass Authentifizierung nicht allein auf einem Gedächtnis- oder Rechentest beruht, wenn es zugänglichere Alternativen gibt.

Praxistest: das komplette Formular nur mit der Tastatur ausfüllen und bewusst einen Fehler erzeugen (z. B. ungültige E-Mail). Wird die Fehlermeldung vom Screenreader angesagt, und ist danach klar, welches Feld korrigiert werden muss?

Ein Beispiel für eine gute Fehlerbehandlung

Nach dem Absenden erscheint oben eine Zusammenfassung: „2 Fehler: E-Mail-Adresse fehlt, Postleitzahl ungültig.“ Die Einträge sind Links zu den Feldern. Direkt am Feld steht eine verständliche Meldung („Bitte eine fünfstellige Postleitzahl eingeben“). Der Fokus springt zur Zusammenfassung, die Screenreader automatisch ansagen. So erfährt jede Person, was los ist und wo.

Verständlich statt technisch

Meldungen wie „Fehler 27“ oder „Ungültige Eingabe“ helfen nicht. Besser: sagen, was erwartet wird, möglichst mit Beispiel. Die Anweisung vor dem Feld zu nennen („Format: TT.MM.JJJJ“) ist hilfreicher, als erst danach zu beanstanden.

Weitere Stolpersteine

• Automatisches Weiterspringen zwischen Feldern.
• Zeitlimits ohne Verlängerungsmöglichkeit.
• CAPTCHAs ohne zugängliche Alternative.
• Pflichtangaben nur farblich gekennzeichnet.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.

Quellen

• WCAG 2.2 – Erfolgskriterien 1.3.1, 1.3.5, 3.3.1, 3.3.2, 3.3.7, 3.3.8
• W3C WAI-ARIA APG – Muster „Form“ und „Alert“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)
• WHATWG HTML Living Standard – Abschnitt zu autocomplete