Tutorial
So machst du Fehlermeldungen im Formular barrierefrei
1 Min. Lesezeit
Kurz gesagt
Ein Formularfehler muss als Text benannt sein (3.3.1), programmatisch mit seinem Feld verbunden werden (aria-describedby plus aria-invalid) und sagen, wie es richtig geht (3.3.3). Erscheint er erst nach dem Absenden, muss er zusätzlich angesagt werden: role="alert" oder Fokus in eine Fehlerzusammenfassung (4.1.3).
In Kürze
Fehler als Text schreiben
Farbe und Rahmen reichen nicht. Der Fehler braucht einen Satz, der ihn benennt.
Mit dem Feld verbinden
Setze aria-describedby auf die id der Meldung und aria-invalid="true" auf das Feld.
Den Weg heraus nennen
Schreibe, was erwartet wird, mit Beispiel: „Beispiel: name@firma.de“.
Ansage sicherstellen
Bei nachträglich erscheinenden Fehlern role="alert" nutzen oder den Fokus in die Fehlerzusammenfassung setzen.
Formulare sind der Ort, an dem Barrierefreiheit über Umsatz entscheidet: Wer den Fehler nicht findet, bestellt nicht. Und genau hier scheitern die meisten Umsetzungen, weil die Fehlermeldung nur für Augen existiert.
Was hier schiefgeht
<form>
<label for="mail">E-Mail</label>
<input id="mail" name="mail" class="input-error">
<!-- Fehler nur farblich und optisch, nicht programmatisch:
- keine Verbindung zum Feld
- keine Rolle, also keine Ansage
- "ungueltig" sagt nicht, was erwartet wird -->
<span class="error-text">Ungueltig</span>
<button type="submit">Weiter</button>
</form>- Die Meldung ist nicht mit dem Feld verbunden: Wer per Tastatur ins Feld springt, hört nichts davon.
- „Ungültig“ sagt nicht, was erwartet wird (3.3.3 verlangt einen Hinweis, wenn er bekannt ist).
- Die Meldung erscheint stumm: ohne Live-Semantik oder Fokuswechsel bemerkt sie niemand, der nicht hinsieht (4.1.3).
Die Lösung am einzelnen Feld
<form novalidate>
<label for="mail">E-Mail</label>
<input
id="mail"
name="mail"
type="email"
autocomplete="email"
aria-invalid="true"
aria-describedby="mail-error"
>
<!-- Mit dem Feld verbunden (aria-describedby), als Text identifiziert
und mit einem konkreten Hinweis, wie es richtig geht -->
<p id="mail-error" class="error-text">
E-Mail-Adresse fehlt das @-Zeichen. Beispiel: name@firma.de
</p>
<button type="submit">Weiter</button>
</form>Mehrere Fehler auf einmal
<!-- Bei mehreren Fehlern: eine Zusammenfassung oben, fokussiert nach
dem Absenden. Jeder Eintrag springt zum betroffenen Feld. -->
<div role="alert" tabindex="-1" id="error-summary">
<h2>2 Angaben fehlen</h2>
<ul>
<li><a href="#mail">E-Mail-Adresse fehlt das @-Zeichen</a></li>
<li><a href="#plz">Postleitzahl braucht 5 Ziffern</a></li>
</ul>
</div>
<script>
// Nach dem Absenden: Fokus in die Zusammenfassung, damit die Ansage
// ankommt und die Tastatur direkt am Fehler steht.
document.getElementById("error-summary").focus();
</script>Nach dem Absenden eines langen Formulars ist die Zusammenfassung der verlässlichste Weg: Sie sagt die Zahl der Fehler, benennt jeden einzeln und bringt den Fokus mit einem Klick an die richtige Stelle. Das hilft nicht nur Screenreader-Nutzenden, sondern allen.
Häufige Zusatzfehler
- Placeholder als Beschriftung: verschwindet beim Tippen und ist kein Label (nutze ein echtes label-Element).
- Fehlerfarbe ohne zweites Merkmal: Rot allein verletzt 1.4.1 (Nutzung von Farbe).
- Meldungen, die beim Tippen sofort verschwinden und wiederkommen: Das erzeugt eine Ansage pro Tastendruck. Validiere beim Verlassen des Feldes oder beim Absenden.
- Ein aria-live-Container, der erst mit dem Text zusammen ins DOM kommt: Dann ist oft nichts zu hören. Der Container muss vorher da sein und nur gefüllt werden.
Testen
- Formular leer absenden und nur mit der Tastatur zum ersten Fehler navigieren.
- Mit einem Screenreader prüfen: Wird der Fehler angesagt? Wird er beim Fokussieren des Feldes wiederholt?
- Auf 200 Prozent zoomen: Bleibt die Meldung neben ihrem Feld sichtbar?
Zugehörige WCAG-Kriterien
Häufige Fragen
- Reicht die eingebaute HTML-Validierung des Browsers?
- Sie ist ein guter Ausgangspunkt, aber ihre Meldungen lassen sich kaum gestalten, sind je nach Browser unterschiedlich formuliert und verschwinden von selbst wieder. Für ein verlässliches Ergebnis validiere selbst und schreibe die Meldung ins Markup.
- Wann role="alert" und wann Fokuswechsel?
- role="alert" eignet sich für einzelne, kurze Meldungen, die sofort ankommen sollen. Bei mehreren Fehlern nach dem Absenden ist der Fokuswechsel in eine Zusammenfassung verlässlicher, weil er zusätzlich die Bedienposition mitnimmt.
- Muss jede Fehlermeldung einen Korrekturvorschlag enthalten?
- 3.3.3 verlangt ihn, wenn er bekannt ist und die Sicherheit nicht gefährdet. Bei einem Formatfehler ist er bekannt („Beispiel: name@firma.de“), beim Login-Passwort nicht, dort wäre er sogar schädlich.
Kostenlosen Scan anfragen
Sagen Sie uns Ihre Domain - wir führen einen kostenlosen Erst-Scan durch und zeigen Ihnen die wichtigsten Barrieren.