Eine barrierefreie Fehlermeldung entscheidet darüber, ob ein Mensch ein Formular abschicken kann – oder ratlos davorsitzt, weil es „einfach nicht funktioniert“. Denn für einen blinden Nutzer ist ein rot umrandetes Feld unsichtbar. Erscheint die Fehlermeldung nur optisch, drückt er auf „Senden“, nichts passiert, und er weiß nicht, warum. In diesem Ratgeber zeige ich Ihnen aus der Audit-Praxis, welche drei Aufgaben jede Fehlermeldung erfüllen muss, welche WCAG-Kriterien gelten, wie Sie Fehler technisch korrekt mit dem Feld verknüpfen und hörbar machen und wie Sie das Ganze in fünf Minuten selbst testen.
Was ist eine barrierefreie Fehlermeldung?
Eine barrierefreie Fehlermeldung teilt jedem Nutzer verständlich mit, was schiefgelaufen ist – unabhängig vom Hilfsmittel. Macht jemand einen Eingabefehler, etwa ein leeres Pflichtfeld oder ein falsches Format, muss das System dreierlei leisten. Es muss den Fehler benennen, erklären und an die assistive Technik melden.
Dahinter stehen mehrere WCAG-Kriterien. Das Erfolgskriterium 3.3.1 Fehlererkennung (Stufe A) verlangt, dass ein Fehler in Textform erkennbar ist. Das Kriterium 3.3.3 Fehlervorschlag (Stufe AA) fordert zusätzlich einen Hinweis, wie man ihn behebt.
Wichtig ist die Erkenntnis dahinter. Eine Fehlermeldung, die nur für sehende Mausnutzer funktioniert, ist keine vollständige Fehlermeldung. Denn gerade in Formularen entscheidet sich, ob ein Mensch eine Bestellung abschließen, einen Antrag stellen oder Kontakt aufnehmen kann. Deshalb ist die Fehlermeldung weit mehr als ein Detail – sie ist oft die letzte Hürde vor dem Ziel.
Das größte Problem: die stille Fehlermeldung
Die häufigste und folgenreichste Barriere ist die stille Fehlermeldung. Sie entsteht, wenn ein Fehler zwar sichtbar erscheint, aber nie an den Screenreader gemeldet wird. Ein blinder Mensch füllt das Formular aus, drückt auf „Senden“ – und hört nichts. Das Feld ist rot umrandet, vielleicht steht sogar Text daneben, doch davon erfährt er nichts. Für ihn bleibt schlicht im Dunkeln, dass überhaupt etwas schiefgegangen ist.
Die Folge ist Ratlosigkeit. Der Nutzer drückt erneut, prüft seine Eingaben, gibt irgendwann auf. Aus seiner Sicht ist das Formular schlicht kaputt. Dabei wäre die Lösung mit wenigen Zeilen Code möglich gewesen. Und genau das macht diese Barriere so ärgerlich: Sie ist leicht zu beheben und bleibt doch ständig unbemerkt.
Genau hier setzt unser Tiefen-Audit Access Ready an. Wir prüfen mit echten Nutzern assistiver Technik, ob eine Fehlermeldung tatsächlich ankommt – nicht nur, ob sie im Code vorhanden ist. Denn vorhanden und hörbar sind zwei verschiedene Dinge.
Wer auf gute Fehlermeldungen angewiesen ist
Von klaren Fehlermeldungen profitieren weit mehr Menschen als nur blinde Nutzer. Denn eine farbcodierte Meldung scheitert auch bei den rund neun Prozent der Männer mit einer Rot-Grün-Schwäche. Und eine vage Meldung überfordert Menschen mit kognitiven Einschränkungen ebenso wie Lernende mit anderer Muttersprache.
Auch die Bedienart spielt eine Rolle. Wer ein Formular nur per Tastatur ausfüllt, braucht den Fokus an der richtigen Stelle, um den Fehler überhaupt zu finden. Gute Fehlermeldungen helfen also einer ganzen Bandbreite von Menschen gleichzeitig. Was für blinde Nutzer unverzichtbar ist, erleichtert allen anderen die Bedienung.
Hinzu kommt ein handfester Geschäftsgrund. Jedes Formular, das im Fehlerfall blockiert, ist ein verlorener Kontakt, eine abgebrochene Bestellung, ein nicht gestellter Antrag. Bessere Fehlermeldungen senken damit direkt die Abbruchquote – und zwar für alle Nutzer, nicht nur für jene mit Behinderung.
Die drei Aufgaben jeder Fehlermeldung
Eine gute Fehlermeldung erfüllt immer dieselben drei Aufgaben. Sie sagt, welches Feld betroffen ist, was daran falsch ist und meldet das hörbar an die assistive Technik. Jede Aufgabe entspricht einem eigenen WCAG-Kriterium.
| Aufgabe | WCAG-Kriterium | Stufe |
|---|---|---|
| Fehler in Text benennen | 3.3.1 Fehlererkennung | A |
| Lösung vorschlagen | 3.3.3 Fehlervorschlag | AA |
| Fehler hörbar melden | 4.1.3 Statusmeldungen | AA |
Diese drei greifen ineinander. Fehlt eine davon, bleibt die Meldung für einen Teil der Nutzer wirkungslos. Die folgenden Abschnitte zeigen, was jede Aufgabe konkret bedeutet. Keine davon ist aufwendig – zusammen aber machen sie den Unterschied zwischen Frust und Erfolg.
Welches Feld? In Text, nicht nur in Farbe
Eine Fehlermeldung muss sagen, welches Feld betroffen ist – und zwar in Text. Denn ein rot umrandetes Feld allein hilft niemandem, der die Farbe nicht sieht. Davon betroffen sind blinde Menschen ebenso wie die rund neun Prozent der Männer mit einer Rot-Grün-Sehschwäche. Beide brauchen einen Hinweis, der unabhängig von der Farbe funktioniert.
Das zugehörige Kriterium ist eindeutig. Das Erfolgskriterium 1.4.1 Verwendung von Farbe (Stufe A) verbietet, Information allein über Farbe zu vermitteln. Eine rote Umrandung ist also nie genug.
Die Lösung ist einfach. Ergänzen Sie die Farbe immer um einen Text und idealerweise ein Symbol. So erkennt jeder Nutzer den Fehler – über die Farbe, das Symbol oder den Text. Mehr dazu zeige ich im Ratgeber zu Farben und Kontrasten. So bleibt der Hinweis auch dann erhalten, wenn jemand Farben gar nicht wahrnimmt.
Was ist falsch — und wie man es behebt
Eine Fehlermeldung soll nicht nur melden, dass etwas falsch ist, sondern auch was. Genau das verlangt das Erfolgskriterium 3.3.3 Fehlervorschlag (Stufe AA). Eine Meldung wie „Ungültige Eingabe“ oder schlicht „Fehler“ erfüllt das nicht, weil sie den Nutzer im Dunkeln lässt.
Hilfreiche Meldungen sind konkret. Statt „Ungültige Eingabe“ heißt es besser: „Die E-Mail-Adresse muss ein @ enthalten.“ Statt „Fehler im Feld Datum“ lieber: „Bitte ein Datum im Format TT.MM.JJJJ eingeben.“ So weiß der Nutzer sofort, was zu tun ist.
Der Unterschied ist enorm. Eine vage Meldung zwingt zum Raten, eine konkrete führt direkt zur Lösung. Formulieren Sie deshalb jede Fehlermeldung so, dass sie den nächsten Schritt klar benennt. Und formulieren Sie sie freundlich: Der Nutzer hat nichts falsch gemacht, er braucht nur einen Hinweis.
Die Fehlermeldung hörbar machen
Damit ein Screenreader eine Fehlermeldung vorliest, muss sie technisch korrekt verknüpft sein. Zwei ARIA-Attribute leisten das. Mit aria-invalid="true" markieren Sie das fehlerhafte Feld, und mit aria-describedby verbinden Sie die Fehlermeldung über ihre ID mit dem Eingabefeld.
Das Ergebnis ist hörbar. Springt der Nutzer auf das Feld, sagt der Screenreader die Beschriftung, den Hinweis „ungültig“ und den Fehlertext an. So entsteht aus drei Bausteinen eine vollständige, gesprochene Rückmeldung – zum Beispiel: <input aria-invalid="true" aria-describedby="mail-err"> mit einem zugehörigen <span id="mail-err">. Die Beschriftung des Feldes muss dafür ebenfalls korrekt verknüpft sein, sonst fehlt der Anfang der Ansage.
Bei dynamischen Fehlern braucht es mehr. Erscheint eine Meldung erst nach dem Absenden ohne Seitenneuladen, nutzen Sie role="alert" für sofortige, unterbrechende Meldungen oder einen Bereich mit aria-live="polite". Das neuere Attribut aria-errormessage wäre eleganter, wird aber noch nicht überall unterstützt – darum bleibt aria-describedby vorerst der sichere Weg. Mehr dazu im Ratgeber zu ARIA in Webanwendungen. Wichtig ist dabei nur, eine Variante konsequent und korrekt umzusetzen.
Beispiel: eine gute und eine schlechte Fehlermeldung
Der Unterschied zwischen einer schlechten und einer guten Fehlermeldung lässt sich an einem Beispiel zeigen. Beide reagieren auf dieselbe falsche E-Mail-Eingabe, doch nur eine davon ist barrierefrei. Im Code liegen dabei oft nur wenige Attribute zwischen den beiden Varianten.
Die schlechte Variante setzt allein auf Optik. Das Feld bekommt eine rote Umrandung, daneben steht „Fehler“. Für einen Screenreader ist beides ohne Bedeutung: keine Verknüpfung, kein konkreter Hinweis, kein hörbares Signal.
Die gute Variante verbindet alle Bausteine. Das Feld trägt aria-invalid="true", die Meldung ist per aria-describedby verknüpft und als role="alert" ausgezeichnet, und der Text sagt klar: „Die E-Mail-Adresse muss ein @ enthalten.“ Ein Symbol ergänzt die Farbe. So erfährt jeder Nutzer – sehend oder nicht – sofort, was zu tun ist.
Den Fokus an die richtige Stelle setzen
Nach dem Absenden mit Fehlern entscheidet der Fokus über alles Weitere. Bleibt er auf dem Senden-Knopf stehen, bemerkt ein Screenreader-Nutzer den Fehler oft gar nicht. Setzen Sie den Fokus deshalb gezielt auf das erste fehlerhafte Feld oder auf eine Fehlerübersicht.
Die bewährte Reihenfolge lautet: erst melden, dann fokussieren. Zuerst kündigt eine Statusmeldung an, dass Fehler vorliegen. Anschließend springt der Fokus an die Stelle, an der die Korrektur beginnt. So weiß der Nutzer sofort, dass und wo er etwas tun muss.
Dieser Schritt wird in der Praxis am häufigsten vergessen. Dabei ist er entscheidend für die Bedienbarkeit per Tastatur. Wie man den Fokus sauber steuert, vertiefe ich im Ratgeber zur Tastaturnavigation.
Die Fehlerübersicht für lange Formulare
Bei langen Formularen lohnt sich eine zusätzliche Fehlerübersicht. Sie steht ganz oben im Formular und listet alle Fehler auf einen Blick. Idealerweise ist jeder Eintrag ein Link, der direkt zum betroffenen Feld springt.
Der Ablauf ist klar geregelt. Nach dem Absenden wandert der Fokus in diese Übersicht, die als role="alert" ausgezeichnet ist und damit sofort vorgelesen wird. So erfasst der Nutzer den gesamten Umfang der Fehler, statt sich einzeln durchzutasten.
Am besten kombinieren Sie beides. Die Übersicht oben gibt den Gesamtüberblick, die einzelne Meldung am Feld den konkreten Hinweis vor Ort. Gerade bei mehrseitigen Anträgen erspart diese Doppelung den Nutzern viel Sucherei. Wichtig ist, dass die Anzahl der Fehler genannt wird, damit der Nutzer den Umfang sofort einschätzt.
Fehler vermeiden, bevor sie entstehen
Die beste Fehlermeldung ist die, die gar nicht nötig wird. Deshalb beginnt Barrierefreiheit hier bei der Vorbeugung. Sagen Sie schon vor der Eingabe, was erwartet wird – etwa „Passwort: mindestens 8 Zeichen mit einer Zahl“. Das verlangt auch das Erfolgskriterium 3.3.2 Beschriftungen oder Anweisungen (Stufe A). Nutzen Sie für diese Hinweise eine sichtbare Beschriftung, nicht nur einen Platzhalter, denn der verschwindet beim Tippen.
Ebenso wichtig ist der Umgang mit der Eingabe. Löschen Sie bei einem Fehler niemals die korrekt ausgefüllten Felder, sondern heben Sie nur die hervor, die einer Korrektur bedürfen. Nichts frustriert mehr, als ein halb ausgefülltes Formular von vorn beginnen zu müssen.
Auch der Zeitpunkt zählt. Prüfen Sie eine Eingabe sinnvollerweise beim Verlassen des Feldes oder beim Absenden, nicht schon bei jedem einzelnen Tastendruck. Bei rechtlich oder finanziell bedeutsamen Vorgängen verlangt 3.3.4 Fehlervermeidung zudem eine Möglichkeit zum Prüfen oder Korrigieren vor dem endgültigen Absenden.
Pflichtfelder klar kennzeichnen
Viele Fehler entstehen erst, weil unklar war, welche Felder ausgefüllt werden müssen. Deshalb gehört zu guten Formularen eine deutliche Kennzeichnung der Pflichtfelder. Genau das verlangt das Erfolgskriterium 3.3.2 Beschriftungen oder Anweisungen (Stufe A).
Ein häufiger Stolperstein ist das Sternchen. Ein einzelnes „*“ ist für Sehende eine vertraute Konvention, für einen Screenreader aber oft nur „Stern“ – ohne erklärten Sinn. Ergänzen Sie das Sternchen deshalb um das Wort „Pflichtfeld“ oder zeichnen Sie das Feld technisch mit aria-required="true" aus. So weiß auch ein Screenreader-Nutzer zuverlässig, welche Angaben verpflichtend sind.
Am verständlichsten ist die Kombination. Eine sichtbare Kennzeichnung im Text, eine erklärende Legende und die technische Auszeichnung greifen ineinander. So weiß jeder Nutzer von Anfang an, worauf es ankommt – und macht von vornherein seltener einen Fehler.
Auch der Erfolg will gemeldet werden
Nicht nur Fehler brauchen eine Rückmeldung, sondern auch der Erfolg. Denn nach dem Absenden fragt sich ein blinder Nutzer genauso: Hat es funktioniert? Eine Meldung wie „Ihr Formular wurde erfolgreich gesendet“ muss deshalb ebenfalls hörbar sein.
Technisch geschieht das ähnlich wie bei Fehlern. Ein Bereich mit role="status" oder aria-live="polite" sorgt dafür, dass die Erfolgsmeldung angesagt wird, ohne den Nutzer abrupt zu unterbrechen. Genau das verlangt das Erfolgskriterium 4.1.3 Statusmeldungen.
Eine stille Erfolgsmeldung verunsichert. Bleibt die Bestätigung unhörbar, weiß der Nutzer nicht, ob er erneut senden muss. Sorgen Sie deshalb dafür, dass jede wichtige Statusänderung – Erfolg wie Fehler – auch akustisch ankommt. Erst dann ist eine Interaktion für alle nachvollziehbar abgeschlossen.
Neu in WCAG 2.2: weniger Hürden in Formularen
Die Version 2.2 der WCAG hat zwei neue Kriterien gebracht, die Formulare spürbar erleichtern. Beide zielen darauf, unnötige Hürden zu vermeiden, bevor überhaupt ein Fehler entstehen kann. Damit rückt der Gedanke der Fehlervermeidung noch stärker in den Vordergrund.
Das erste betrifft Wiederholungen. Das Erfolgskriterium 3.3.7 Redundante Eingabe (Stufe A) verlangt, dass Nutzer Angaben innerhalb eines Vorgangs nicht erneut eingeben müssen. Eine bereits genannte Adresse sollte sich also übernehmen lassen, statt sie ein zweites Mal abzufragen.
Das zweite betrifft die Anmeldung. Das Erfolgskriterium 3.3.8 Barrierefreie Authentifizierung (Stufe AA) verbietet, die Anmeldung von einem reinen Gedächtnistest abhängig zu machen. Erlauben Sie deshalb das Einfügen aus der Zwischenablage und die Nutzung von Passwortmanagern. Mehr zu den Neuerungen zeige ich im Ratgeber zu WCAG 2.2.
Der Test mit geschlossenen Augen
Den wichtigsten Test können Sie sofort selbst machen. Er kostet nichts und deckt die stille Fehlermeldung zuverlässig auf.
Aus der Praxis – der Screenreader-Test: Schalten Sie Ihren Bildschirm aus oder schließen Sie die Augen und bedienen Sie Ihr Formular nur mit einem Screenreader wie NVDA oder VoiceOver. Schicken Sie es absichtlich fehlerhaft ab: Lassen Sie ein Pflichtfeld leer, geben Sie eine kaputte E-Mail-Adresse ein. Hören Sie nun genau hin. Erfahren Sie überhaupt, dass ein Fehler vorliegt? Hören Sie, welches Feld betroffen ist und was zu tun ist? Springen Sie auf das Feld – wird die Meldung dort vorgelesen? Und erscheint die Erfolgsmeldung hörbar, wenn Sie das Formular korrekt ausfüllen? Wenn Sie an irgendeiner Stelle im Stillen sitzen bleiben, haben Sie die häufigste Barriere gefunden. Genau so erlebt ein blinder Mensch Ihr Formular jeden Tag.
Häufige Fehler bei Fehlermeldungen
Über viele Audits hinweg wiederholen sich dieselben Muster. Diese acht sehe ich am häufigsten – und alle lassen sich beheben:
- Nur Farbe: ein rotes Feld ohne Text und ohne Symbol.
- Vage Meldung wie „Fehler“ oder „Ungültige Eingabe“.
- Stille Meldung, die für den Screenreader unhörbar bleibt.
- Keine Verknüpfung per
aria-describedbyundaria-invalid. - Fokus bleibt auf dem Senden-Knopf statt am Fehler.
- Eingaben gelöscht, sodass der Nutzer von vorn beginnt.
- Prüfung bei jedem Tastendruck, die ständig dazwischenredet.
- Platzhalter als einzige Beschriftung, die beim Tippen verschwindet.
Auffällig ist dabei eines. Fast kein Fehler entsteht aus bösem Willen. Vielmehr entsteht er, weil das Formular nur mit Maus und Augen getestet wurde – und beide diese Probleme nicht bemerken. Ein einziger Test mit dem Screenreader deckt die meisten davon auf.
Häufige Fragen zu barrierefreien Fehlermeldungen
Zum Abschluss die Fragen, die mir in der Praxis am häufigsten begegnen. Die Antworten fallen dabei kurz und konkret aus.
Reicht eine rote Umrandung als Fehlerkennzeichnung?
Nein. Eine Umrandung allein verstößt gegen 1.4.1 Verwendung von Farbe. Ergänzen Sie die Farbe immer um Text und idealerweise ein Symbol.
Wie erfährt ein Screenreader von einem Fehler?
Über die Auszeichnung im Code. Markieren Sie das Feld mit aria-invalid="true" und verbinden Sie die Meldung über aria-describedby. Dynamische Fehler kündigt role="alert" an.
Wohin soll der Fokus nach einem Fehler springen?
Auf das erste fehlerhafte Feld oder die Fehlerübersicht. Bleibt er auf dem Senden-Knopf, bemerkt ein Screenreader-Nutzer den Fehler häufig nicht. Bewährt hat sich daher die Reihenfolge „erst melden, dann fokussieren“.
So machen Sie Ihre Fehlermeldungen barrierefrei
Der Weg beginnt bei den messbaren Mängeln und endet bei der gehörten Realität. Einen schnellen Überblick liefert der kostenlose Access Score in Minuten. Er erkennt automatisch, was sich messen lässt: fehlende Beschriftungen, reine Farbkennzeichnung oder fehlende ARIA-Verknüpfungen.
Ob eine Meldung aber wirklich ankommt, zeigt sich erst im Gebrauch. Hört ein blinder Mensch, was schiefging? Findet er zum richtigen Feld? Versteht er, was zu tun ist? Das beurteilt kein Scanner allein. Mit Access Ready prüfen wir Ihre Formulare mit echten Nutzern assistiver Technik und stellen ein rechtssicheres Zertifikat aus.
| Ansatz | Prüft Code | Prüft Hörbarkeit | Nachweis |
|---|---|---|---|
| Kostenloser Scanner | messbare Mängel | nein | nein |
| Overlay-Widget | kaschiert, behebt nicht | nein | nein |
| Access Ready (IFDB) | Code und Erlebnis | ja | ja |
Der Unterschied liegt im Anspruch. Andere prüfen, ob eine Meldung im Code steht, und überlassen Ihnen den Rest. Wir prüfen, ob ein Mensch sie tatsächlich hört und versteht. So wird aus „der Fehler steht doch da“ ein belegtes „jeder erfährt, was zu tun ist“. Und aus einem Formular, an dem Menschen scheitern, wird eines, das alle bis zum Ende ausfüllen.
