html-einfach.de

Barrierefreie Komponenten · Formulare

Fehlermeldungen barrierefrei gestalten

Von Zuletzt geändert am

Ein Formular abzuschicken und nur ein rotes Feld zurückzubekommen, ist frustrierend. Was war falsch? Ein Fehler hilft erst, wenn drei Dinge stimmen: Er ist wahrnehmbar, er ist dem Feld programmatisch zugeordnet, und er wird im richtigen Moment angekündigt. Klingt nach viel, ist aber mit nativem HTML und einer Handvoll ARIA-Attributen gut machbar.

Fehlermeldungen sind die Stelle, an der sich entscheidet, ob ein Formular bedienbar ist oder zur Sackgasse wird. Gerade hier sehe ich oft, dass alles auf Farbe und Optik gesetzt wird – und damit alle ausschließt, die diese Optik nicht wahrnehmen.

Drei Anforderungen an eine gute Fehlermeldung

Anforderung Heißt konkret
Wahrnehmbar Text, nicht nur Farbe; klar formuliert; ggf. mit Symbol
Zugeordnet per aria-describedby fest mit dem Feld verknüpft
Angekündigt beim Absenden hörbar – über Fokus oder eine Live-Region

Diese drei Punkte sind mein Prüfraster, wann immer ich Validierung umsetze. Gehen wir sie der Reihe nach durch.

Wahrnehmbar: niemals nur Farbe

Ein rot umrandetes Feld sagt jemandem mit Rot-Grün-Sehschwäche oder am Screenreader genau nichts. Die WCAG verlangen deshalb: Farbe darf nie der einzige Träger einer Information sein (1.4.1). Eine Fehlermeldung braucht also Text – und der sollte konkret sein:

  • Schlecht: „Ungültige Eingabe.“
  • Besser: „Bitte gib eine E-Mail-Adresse mit @ an, z. B. name@example.com.“

Die Farbe (rotes Rahmen, rotes Icon) darf den Fehler zusätzlich betonen – tragen muss ihn der Text. Dass der rote Ton auch genug Kontrast hat, ist dabei schnell übersehen; das Thema vertieft die Seite Farbkontraste richtig einstellen.

Zugeordnet: aria-describedby und aria-invalid

Damit ein Screenreader den Fehler beim Fokussieren des Feldes mitliest, muss er programmatisch verbunden sein. Das übernimmt aria-describedby (dasselbe Muster wie bei Hilfetexten und Labels). Zusätzlich markiert aria-invalid="true" das Feld als fehlerhaft:

<label for="email">E-Mail-Adresse</label>
<input
  type="email"
  id="email"
  name="email"
  aria-invalid="true"
  aria-describedby="email-fehler"
/>
<p id="email-fehler" class="feldfehler">
  Bitte gib eine gültige E-Mail-Adresse an, z. B. name@example.com.
</p>

Wird der Fehler behoben, entferne ich aria-invalid (oder setze es auf false) und löse die aria-describedby-Verbindung wieder. So bleibt der Zustand des Feldes immer ehrlich.

Angekündigt: Fokus oder Live-Region

Beim Absenden eines fehlerhaften Formulars muss klar werden, dass und wo etwas schiefging. Zwei bewährte Wege, die ich je nach Formular kombiniere:

1. Fokus auf eine Fehlerübersicht setzen. Bei längeren Formularen sammle ich alle Fehler oben in einer Box und springe per Skript mit dem Fokus dorthin. Jeder Eintrag verlinkt direkt zum betroffenen Feld:

<div class="fehleruebersicht" role="alert" tabindex="-1">
  <h2>Bitte korrigiere 2 Eingaben</h2>
  <ul>
    <li><a href="#email">E-Mail-Adresse fehlt</a></li>
    <li><a href="#plz">Postleitzahl muss 5 Ziffern haben</a></li>
  </ul>
</div>

Dieses Muster – Fehler bündeln, anspringen, verlinken – stammt aus den Design-Systemen der öffentlichen Hand (etwa GOV.UK) und hat sich für mich als das verlässlichste erwiesen.

2. Einzelne Fehler über eine Live-Region ankündigen. Bei einem kurzen Formular oder Inline-Prüfung genügt oft role="alert" direkt an der Meldung – der Text wird dann automatisch vorgelesen, sobald er erscheint. Wie das im Detail funktioniert, steht unter Live-Regionen (aria-live).

Der richtige Zeitpunkt

Wann geprüft wird, entscheidet maßgeblich über die Erfahrung. Aggressive Prüfung bei jedem Tastendruck – „E-Mail ungültig“, während man noch tippt – nervt und verwirrt. Ich validiere deshalb beim Absenden und korrigiere danach gern beim Verlassen des Feldes (blur), sobald es einmal als fehlerhaft markiert war. Mehr zu Timing und Pflichtfeldern steht unter Validierung & Pflichtfelder.

Häufige Fehler

  • Nur Farbe. Roter Rahmen ohne Textmeldung – der häufigste und folgenreichste Fehler.
  • Meldung nicht verknüpft. Der Hinweis steht sichtbar daneben, ist aber nicht über aria-describedby ans Feld gebunden – Screenreader finden ihn nicht.
  • Stumme Validierung. Beim Absenden passiert sichtbar etwas, akustisch aber nichts. Ohne Fokuswechsel oder Live-Region bleibt der Fehler verborgen.
  • Vage Texte. „Fehler“ oder „ungültig“ sagen nicht, was zu tun ist.
  • Fokus geht verloren. Nach dem Absenden landet der Fokus irgendwo – idealer ist die Fehlerübersicht oder das erste fehlerhafte Feld.

Häufige Fragen

role="alert" oder aria-live="assertive" – was denn nun?

role="alert" ist im Grunde die Kurzform: Es entspricht einer assertiven Live-Region und unterbricht die aktuelle Ausgabe. Für echte Fehler ist das angemessen. Die Feinheiten beider Varianten behandelt die Seite zu Live-Regionen.

Reicht die native Browser-Validierung nicht?

Die HTML-Constraint-Validierung (required, type="email" …) ist eine gute Grundlage, aber ihre Fehlerblasen sind kaum gestaltbar und in der Ausgabe uneinheitlich. Für verlässliche, einheitliche Meldungen baue ich sie meist mit eigenem Markup nach – auf Basis derselben Constraints.

Soll der Fehlertext über oder unter dem Feld stehen?

Das ist Geschmackssache, solange er per aria-describedby verbunden ist. Visuell finde ich direkt unter dem Feld am klarsten, weil Eingabe und Hinweis zusammen im Blick bleiben.

Fazit

Eine barrierefreie Fehlermeldung ist sichtbarer Text, fest mit dem Feld verknüpft (aria-describedby + aria-invalid) und beim Absenden hörbar – per Fokus auf eine Fehlerübersicht oder über eine Live-Region. Keine dieser Maßnahmen ist aufwendig, aber zusammen entscheiden sie darüber, ob ein Formular alle bis zum „Absenden“ bringt oder unterwegs abhängt.