Wenn Ihre Fehlermeldungen Nutzer aussperren

Der Moment, in dem das Formular scheitert

Stellen Sie sich vor: Ein blinder Nutzer füllt ein Bestellformular aus, sendet es ab und hört von seinem Screenreader nichts Brauchbares. Keine Ansage. Keine Erklärung. Die Seite hat visuell fünf Validierungsfehler rot markiert, aber der Nutzer weiß nichts davon. Er klickt erneut auf Absenden. Und noch einmal. Irgendwann verlässt er die Seite.

Das ist kein Randszenario. Nicht barrierefreie Fehlerbehandlung gehört zu den häufigsten Barrieren, die wir in echten Audits finden — und zu denen, die Nutzer im denkbar ungünstigsten Moment frustrieren: wenn sie eine Transaktion abschließen oder etwas Wichtiges übermitteln wollen.

Die gute Nachricht: Das Problem zu beheben ist vor allem eine Frage des Wissens, wie “gut” aussieht. Die Fehler folgen fast immer denselben wenigen Mustern.

Warum Fehlermeldungen für Nutzer assistiver Technologien schwierig sind

Sehende Mausnutzer bemerken Validierungsfehler in der Regel sofort — der rote Rahmen, das Warnsymbol, der Text, der unter dem Feld erscheint. Aber Nutzer, die auf Screenreader, Tastaturnavigation oder Sprachsteuerung angewiesen sind, erleben etwas grundlegend anderes.

Wenn ein Formular abgesendet wird und Fehler erscheinen:

Screenreader-Nutzer hören möglicherweise gar nichts, es sei denn, der Fokus springt zum Fehler oder eine Live-Region kündigt ihn an
Tastaturnutzer müssen jede Fehlermeldung per Tastatur erreichen und verstehen können, zu welchem Feld sie gehört
Nutzer von Sprachsteuerung müssen Felder über eine sichtbare, korrekte Beschriftung ansprechen — ist die Beschriftung falsch oder fehlt sie, kommen sie nicht weiter

Nichts davon geschieht automatisch. Sie müssen es bauen.

Die anwendbaren WCAG-Kriterien

Vier Erfolgskriterien der WCAG 2.2 behandeln die Fehlerbehandlung direkt:

3.3.1 Fehlererkennung (Stufe A) — Wird ein Fehler automatisch erkannt, muss das fehlerhafte Element identifiziert und dem Nutzer in Textform beschrieben werden. Fehler dürfen nicht allein durch Farbe vermittelt werden.

3.3.2 Beschriftungen oder Anweisungen (Stufe A) — Eingaben, die ein bestimmtes Format erfordern, müssen diese Anforderung vor oder während der Eingabe deutlich machen, nicht erst nach einem gescheiterten Absenden.

3.3.3 Fehlerempfehlung (Stufe AA) — Wird ein Fehler erkannt und sind Korrekturvorschläge bekannt, müssen sie bereitgestellt werden. “Ungültiges Datum” reicht nicht. “Geben Sie das Datum im Format TT/MM/JJJJ ein” schon.

3.3.4 Fehlervermeidung (Stufe AA) — Bei folgenreichen Übermittlungen (Finanztransaktionen, rechtliche Vereinbarungen) müssen Nutzer die Möglichkeit haben, vor der endgültigen Aktion zu prüfen, zu korrigieren und zu bestätigen.

Hinzu kommt 4.1.3 Statusmeldungen (Stufe AA): Dynamisch eingefügte Meldungen, die keinen Fokus erhalten, müssen von assistiven Technologien über role="status" oder role="alert" angekündigt werden.

Was eine barrierefreie Fehlermeldung tatsächlich braucht

Fehlermeldungen richtig umzusetzen erfordert Aufmerksamkeit auf vier verschiedenen Ebenen:

1. Die programmatische Verknüpfung

Jede Fehlermeldung muss über aria-describedby mit ihrem Feld verknüpft sein. Das weist Screenreader an, den Fehlertext anzusagen, wenn das Feld den Fokus erhält.

<!-- Before: error text exists visually but is invisible to screen readers -->
<label for="email">Email</label>
<input type="email" id="email" class="error">
<p class="error-text">Enter a valid email address.</p>

<!-- After: programmatic association via aria-describedby -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-err"
  aria-invalid="true"
>
<p id="email-err" class="error-text">Enter a valid email address.</p>

Das Attribut aria-invalid="true" signalisiert, dass das Feld aktuell ungültig ist, was die meisten Screenreader ansagen, sobald der Fokus darauf landet.

2. Fokusmanagement nach dem Absenden

Wenn ein Formular abgesendet wird und Fehler vorliegen, muss der Fokus an eine sinnvolle Stelle springen. Die zwei häufigsten Muster:

Fokus auf eine Fehlerzusammenfassung am Formularanfang bewegen, die alle Fehler mit Links zu den betroffenen Feldern auflistet
Fokus auf das erste fehlerhafte Feld bewegen

Bleibt der Fokus auf der Absenden-Schaltfläche oder nirgendwo, müssen Screenreader-Nutzer die Fehler selbst entdecken, indem sie durch das Formular navigieren — sofern sie überhaupt wissen, dass Fehler existieren.

// After validation fails, move focus to the error summary
const summary = document.getElementById('error-summary');
summary.setAttribute('tabindex', '-1');
summary.focus();

3. Live-Region-Ansagen für dynamische Fehler

Für Fehler, die während der Eingabe erscheinen (Inline-Echtzeitvalidierung), verwenden Sie ARIA-Live-Regionen, damit die Meldung angesagt wird, ohne dass sich der Fokus bewegen muss.

<p role="alert" aria-live="assertive" id="password-err">
  Password must be at least 8 characters.
</p>

Verwenden Sie role="alert" / aria-live="assertive" für Fehler, die sofortige Aufmerksamkeit erfordern. Verwenden Sie role="status" / aria-live="polite" für weniger dringendes Feedback, das warten kann, bis der Nutzer pausiert.

4. Die Fehlermeldung selbst

Die Sprache zählt. Barrierefreie Fehlermeldungen sind:

Konkret: Sagen Sie, was falsch ist, nicht nur, dass etwas falsch ist
Handlungsleitend: Sagen Sie dem Nutzer genau, was er zur Korrektur tun soll
Höflich: Vermeiden Sie vorwurfsvolle Formulierungen wie “Sie haben einen ungültigen Wert eingegeben”

Nicht barrierefrei	Barrierefrei
”Ungültige Eingabe"	"Die E-Mail-Adresse muss ein @-Zeichen enthalten, z. B. name@example.com"
"Fehler"	"Das Datum muss im Format TT/MM/JJJJ angegeben werden"
"Pflichtfeld"	"Der vollständige Name ist erforderlich"
"Passwort ungültig"	"Das Passwort muss mindestens 8 Zeichen lang sein und eine Ziffer enthalten”

Muster für verschiedene Fehlerszenarien

Inline-Feldfehler

Das häufigste Muster. Eine Fehlermeldung erscheint direkt unter dem zugehörigen Feld. Funktioniert gut bei einfachen Formularen. Erfordert aria-describedby und aria-invalid, um korrekt angesagt zu werden.

Bei langen Formularen mit mehreren Fehlern platzieren Sie am Anfang eine Zusammenfassung, die alle Probleme als Links auflistet, die zum betroffenen Feld springen. Bewegen Sie den Fokus nach einem gescheiterten Absenden hierhin. Dieses Muster verwendet GOV.UK, und es wird für komplexe Formulare breit empfohlen.

Toast-Benachrichtigungen

Kurzlebige Meldungen, die am Bildschirmrand erscheinen, gehören zu den am wenigsten barrierefreien Mustern im verbreiteten Einsatz. Sie verschwinden, bevor Screenreader-Nutzer sie erreichen können, sie werden oft gar nicht angesagt, und sie bieten keinen Weg zur Korrektur. Vermeiden Sie Toasts für Fehler. Wenn Sie sie dennoch einsetzen, kombinieren Sie sie mit einem dauerhaften Fehlerzustand im Formular selbst.

Systemfehler

Wenn serverseitig etwas schiefgeht, sagen Sie dem Nutzer in klarer Sprache, was passiert ist und was er als Nächstes tun kann. “Etwas ist schiefgelaufen” ohne weitere Hilfestellung lässt Nutzer im Stich.

<div role="alert" aria-live="assertive">
  <p>We couldn't save your changes due to a network error.
  Please check your connection and try again.</p>
</div>

Die Test-Checkliste

Prüfen Sie nach der Umsetzung der Fehlerbehandlung diese Punkte manuell — automatisierte Tools erfassen die meisten davon nicht:

Das Absenden eines leeren Pflichtformulars bewegt den Fokus auf eine Fehlerzusammenfassung oder das erste fehlerhafte Feld
Jede Fehlermeldung ist über aria-describedby mit ihrem Feld verknüpft
Fehlerhafte Felder haben aria-invalid="true"
Fehlermeldungen werden angesagt, wenn der Fokus auf dem betroffenen Feld landet
Die Echtzeitvalidierung verwendet Live-Regionen
Fehlermeldungen verwenden konkrete, handlungsleitende Sprache — nicht nur “ungültig”
Farbe ist nicht das einzige Mittel zur Fehlerkennzeichnung (Symbol oder Textbeschriftung zusätzlich zum Rot)
Der Fehler ist per Tastatur mit Tab erreichbar
Die Fokusreihenfolge nach dem Absenden ist logisch und springt nicht unvorhersehbar
Toast-Meldungen sind mit einem dauerhaften Fehlerzustand kombiniert

Warum automatisierte Tools das meiste davon übersehen

Ein automatisierter Scanner kann prüfen, ob aria-describedby auf ein existierendes Element verweist und ob aria-invalid vorhanden ist. Er kann nicht prüfen, ob sich der Fokus nach dem Absenden korrekt bewegt, ob der Fehlertext zutreffend ist oder ob eine Toast-Benachrichtigung verschwindet, bevor sie gelesen werden kann. Unsere manuellen Barrierefreiheits-Audits umfassen formularspezifische Tests mit echten assistiven Technologien — der einzige verlässliche Weg zu verifizieren, dass die Fehlerbehandlung durchgängig funktioniert.

Wenn Sie unsicher sind, wo Ihre Formulare stehen, starten Sie einen kostenlosen Scan, um zunächst die automatisierbar auffindbaren Probleme sichtbar zu machen, und gehen Sie von dort aus weiter.