WCAG 3.3.3: Fehlervorschlag

WCAG 3.3.3 verlangt, dass, wenn ein Eingabefehler automatisch erkannt wird, das System eine Textbeschreibung bereitstellen muss, die vorschlägt, wie der Benutzer den Fehler korrigieren kann – es sei denn, dies würde die Sicherheit oder den Zweck gefährden. Dieses Kriterium ist entscheidend für Nutzer mit kognitiven Beeinträchtigungen, Screenreader-Nutzer und alle, die Schwierigkeiten haben, vage oder fehlende Fehlermeldungen zu verstehen.

Was diese Regel bedeutet

WCAG 3.3.3 Error Suggestion ist ein Kriterium der Stufe AA unter dem Prinzip „Verständlich“. Es baut direkt auf 3.3.1 (Error Identification) auf, das verlangt, dass Fehler im Text identifiziert werden. Error Suggestion geht einen Schritt weiter: Wenn ein Eingabefehler automatisch erkannt wird, muss die Benutzeroberfläche außerdem vorschlagen, wie der Benutzer ihn korrigieren kann, sofern dieser Vorschlag nicht die Sicherheit oder den Zweck des Inhalts beeinträchtigt.

Der entscheidende Unterschied liegt hier zwischen Fehleridentifikation und Fehlervorschlag. Dem Benutzer zu sagen „Ihr Geburtsdatum ist ungültig“ ist Identifikation. Zu sagen „Ihr Geburtsdatum ist ungültig — bitte geben Sie ein Datum im Format TT/MM/JJJJ ein“ ist ein Vorschlag. Beide sind unter ihren jeweiligen Kriterien erforderlich, aber Error Suggestion verlangt, dass eine umsetzbare, korrigierende Anleitung die Fehlermeldung nach Möglichkeit begleitet.

Das Kriterium gilt immer dann, wenn ein Eingabefehler automatisch erkannt wird – das heißt, wenn clientseitige oder serverseitige Validierungslogik feststellt, dass ein übermittelter oder eingegebener Wert nicht den erwarteten Kriterien entspricht. Es gilt für alle Formularelemente: Texteingaben, Selects, Kontrollkästchen, Optionsfelder, Datumsauswahlfelder, Dateiupload-Felder und jede interaktive Komponente, die Benutzerdaten erfasst.

Was als bestanden gilt: Die Fehlermeldung wird im Text dargestellt (nicht nur durch Farbe oder Symbol), identifiziert das fehlerhafte Feld eindeutig und bietet konkrete Hinweise, wie es korrigiert werden kann. Zum Beispiel: „Das Passwort muss mindestens 8 Zeichen lang sein und einen Großbuchstaben enthalten“ statt nur „Ungültiges Passwort.“ Der Vorschlag muss in der Nähe des Feldes erscheinen, programmatisch mit ihm verknüpft sein (über aria-describedby oder Ähnliches) und für unterstützende Technologien wahrnehmbar sein.

Was als nicht bestanden gilt: Jede Fehlermeldung, die lediglich angibt, dass ein Fehler aufgetreten ist, ohne zu erklären, was falsch ist oder wie man es behebt. Allgemeine Meldungen wie „Fehler“, „Ungültige Eingabe“ oder „Pflichtfeld“ ohne weiteren Kontext verfehlen dieses Kriterium. Fehler, die nur durch einen roten Rahmen oder ein Warnsymbol ohne beschreibenden Text kommuniziert werden, fallen ebenfalls durch.

Definierte Ausnahmen: Das Kriterium enthält zwei ausdrückliche Ausnahmen, bei denen ein Vorschlag nicht erforderlich ist. Erstens, wenn die Bereitstellung des Vorschlags die Sicherheit gefährden würde – zum Beispiel bei einem Login-Formular, bei dem die genaue Erklärung, warum ein Passwort fehlgeschlagen ist (falsches Passwort vs. falscher Benutzername), Brute-Force-Angriffe erleichtern könnte. Zweitens, wenn die Bereitstellung des Vorschlags den Zweck des Inhalts gefährden würde – etwa bei einem Wissensquiz, bei dem die Offenlegung der richtigen Antwort das Bewertungsziel zunichtemacht. Diese Ausnahmen sind eng gefasst und sollten nicht genutzt werden, um die Anforderung in Standardformular-Kontexten zu umgehen.

Warum es wichtig ist

Error Suggestion existiert, weil das Ausfüllen von Formularen zu den kognitiv anspruchsvollsten Aktivitäten gehört, die Benutzer im Web ausführen, und zugleich zu den folgenreichsten – Fehler in Checkout-Formularen, Anträgen auf staatliche Leistungen, medizinischen Aufnahmeformularen oder Bankportalen können reale Konsequenzen für Benutzer haben, die nicht verstehen, was schiefgelaufen ist oder wie sie sich davon erholen können.

Kognitive Beeinträchtigungen: Benutzer mit Dyslexie, ADHS, Lernschwierigkeiten oder eingeschränkter Literalität können Schwierigkeiten haben, vage Fehlermeldungen zu entschlüsseln und sie mit dem konkreten Feld oder dem erforderlichen Format zu verknüpfen. Ohne einen klaren korrigierenden Vorschlag brechen sie das Formular möglicherweise ganz ab oder übermitteln falsche Informationen. Laut Weltgesundheitsorganisation lebt weltweit etwa 1 von 6 Menschen – über 1,3 Milliarden – mit irgendeiner Form von Behinderung, und kognitive Beeinträchtigungen gehören zu den häufigsten, aber am wenigsten berücksichtigten Kategorien.

Blinde und sehbehinderte Benutzer: Screenreader-Nutzer sind vollständig auf Textbeschreibungen angewiesen, um Validierungsfehler zu verstehen. Wenn eine Fehlermeldung nur „Ungültig“ sagt und keinen Vorschlag bietet, hat der Benutzer keinen Mechanismus, um zu bestimmen, was „ungültig“ für dieses Feld bedeutet. Er kann nicht auf benachbarte Beschriftungen, Platzhaltertext oder visuelle Formatierungshinweise schauen, um das erwartete Format zu erschließen. Ein klarer Vorschlag, der programmatisch über aria-describedby mit der Eingabe verknüpft ist, ist der einzige verlässliche Informationskanal.

Motorisch beeinträchtigte Benutzer: Benutzer, die auf Switch-Zugriff, Sprachsteuerung oder alternative Eingabegeräte angewiesen sind, haben einen erheblichen körperlichen Aufwand beim Ausfüllen von Formularen. Nach einer fehlgeschlagenen Übermittlung erneut zu einem Formular navigieren zu müssen – ohne zu verstehen, was geändert werden muss – verursacht eine unverhältnismäßige Belastung. Klare Vorschläge verringern den Aufwand für erneute Eingaben und die Anzahl fehlgeschlagener Übermittlungszyklen.

Nicht-muttersprachliche Benutzer und ältere Benutzer: Benutzer, die die Sprache des Formulars nicht fließend beherrschen oder weniger Erfahrung mit Webkonventionen haben, profitieren ebenfalls erheblich von expliziten korrigierenden Vorschlägen. Eine Meldung wie „Geben Sie Ihre Telefonnummer ohne Leerzeichen oder Bindestriche ein, z. B. 05321234567“ beseitigt Unklarheiten für Benutzer, die das Formular sonst möglicherweise nie erfolgreich abschließen würden.

Praxisbeispiel: Stellen Sie sich eine türkische Staatsbürgerin vor, die über ein E-Government-Portal eine Sozialleistung beantragt. Der Antrag erfordert eine TR Identity Number (TC Kimlik Numarası), ein spezifisches 11-stelliges Format. Wenn die Benutzerin 10 Ziffern eingibt und nur die Meldung „TC Kimlik Numarası hatalı“ (TC Identity Number ist falsch) erhält, weiß eine kognitiv beeinträchtigte Person, eine ältere Person oder ein Screenreader-Nutzer möglicherweise nicht, ob die Nummer zu kurz ist, ein ungültiges Zeichen enthält oder ein Formatproblem vorliegt. Das Hinzufügen von „TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901“ (TC Identity Number muss 11-stellig sein, z. B. 12345678901) beseitigt die Unklarheit sofort und ermöglicht der Benutzerin, den Fehler selbst zu korrigieren.

Vorteile für Usability und Conversion: Über die Barrierefreiheit hinaus ist der Abbruch von Formularen eine kritische Geschäftskennzahl. Untersuchungen zeigen immer wieder, dass unklare Fehlermeldungen zu den Hauptgründen gehören, warum Benutzer E-Commerce-Checkouts und Registrierungsabläufe abbrechen. Konkrete, umsetzbare Fehlervorschläge senken die Abbruchraten und verbessern die Abschlussquoten für alle Benutzer – dieses Kriterium ist daher sowohl ein starkes Geschäftsargument als auch eine Barrierefreiheitsanforderung.

Wie man testet

Automatisierter Scan als Basis: Führen Sie axe DevTools oder Lighthouse auf der Seite mit dem Formular aus. Notieren Sie alle vorhandenen Verstöße im Zusammenhang mit Formularlabels, ARIA-Rollen oder Fehleridentifikation (3.3.1). Diese müssen zuerst behoben werden, da sie Voraussetzungen für wirksame Fehlervorschläge sind. Automatisierte Scans markieren keine fehlenden Vorschläge – sie schaffen nur die strukturelle Basis.
Jede Validierungsbedingung auslösen: Lösen Sie für jedes Formularfeld bewusst jeden möglichen Fehlerzustand aus: Senden Sie ein leeres Pflichtfeld ab, geben Sie Daten in einem falschen Format ein (falsches Datumsformat, ungültige E-Mail, zu kurzes Passwort, nicht numerischer Wert in einem numerischen Feld) und überschreiten Sie etwaige Zeichenlimits. Dokumentieren Sie jede auftretende Fehlermeldung.
Qualität der Vorschläge bewerten: Fragen Sie bei jeder Fehlermeldung: (a) Identifiziert sie das konkrete Feld? (b) Erklärt sie, was falsch ist? (c) Bietet sie umsetzbare Hinweise, wie der Eintrag korrigiert werden kann? Eine Meldung, die alle drei Fragen beantwortet, besteht 3.3.3. Eine Meldung, die nur (a) beantwortet, besteht 3.3.1, fällt aber bei 3.3.3 durch.
Screenreader-Test mit NVDA + Firefox: Navigieren Sie mit Tab zum Formular. Geben Sie einen ungültigen Wert ein. Senden Sie ab oder verlassen Sie das Feld. Hören Sie, was NVDA ankündigt. Verifizieren Sie, dass der Fehlervorschlagstext automatisch vorgelesen wird (über eine aria-live-Region oder Fokusmanagement auf den Fehler), ohne dass der Benutzer ihn manuell suchen muss.
Screenreader-Test mit VoiceOver + Safari (macOS/iOS): Führen Sie die gleichen Schritte aus. Verwenden Sie VO+Rechtspfeil, um das Feld und seine zugehörige Beschreibung zu lesen. Bestätigen Sie, dass der Vorschlagstext als Teil der zugänglichen Beschreibung des Feldes angekündigt wird und nicht nur als benachbarter Text, der übersprungen werden könnte.
Screenreader-Test mit JAWS + Chrome: Nachdem Sie ein Formular mit Fehlern übermittelt haben, bestätigen Sie, dass JAWS den Fehlervorschlag entweder über Fokusmanagement (Fokus wird auf die Fehlerzusammenfassung verschoben) oder über Updates in einer aria-live-Region vorliest. Verwenden Sie den virtuellen Cursor von JAWS, um zum Feld zu navigieren, und bestätigen Sie, dass der Vorschlag Teil der Feldbeschreibung ist.
Nur-Tastatur-Navigation: Navigieren Sie ohne Screenreader mit Tab, Shift+Tab und Enter durch das Formular. Verifizieren Sie, dass Fehlervorschläge im sichtbaren Bereich erscheinen, nicht außerhalb des Bildschirms verborgen oder von anderen Elementen verdeckt sind, wenn das Feld nach einer fehlgeschlagenen Übermittlung den Fokus erhält.
Sicherheitsausnahmen überprüfen: Bestätigen Sie bei Login- und Authentifizierungsformularen, dass das Weglassen spezifischer Vorschläge beabsichtigt und dokumentiert ist und dass die Sicherheitsausnahme auf die minimal notwendigen Felder beschränkt ist.

Wie man es behebt

Generische Fehlermeldung – Falsch

<!-- Error message provides no suggestion on how to fix the problem -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

Generische Fehlermeldung – Richtig

<!-- aria-describedby links the suggestion text to the input;
     the suggestion explains exactly what format is expected -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

Passwortvalidierung ohne Formatangabe – Falsch

<!-- User is told the password is wrong but not why or how to fix it -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

Passwortvalidierung ohne Formatangabe – Richtig

<!-- The suggestion lists exactly what the password must contain,
     enabling the user to self-correct without guessing -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

Datumsfeld mit unklarem Formatfehler – Falsch

<!-- No indication of which date format is expected -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

Datumsfeld mit unklarem Formatfehler – Richtig

<!-- The suggestion states the required format and provides
     a concrete example, removing all ambiguity -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

Mehrfeld-Formular mit serverseitiger Fehlerzusammenfassung – Falsch

<!-- Error summary exists but links do not associate suggestions
     with individual fields, and messages are vague -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

Mehrfeld-Formular mit serverseitiger Fehlerzusammenfassung – Richtig

<!-- Error summary includes linked, specific suggestions;
     each list item links to the relevant field;
     inline errors also appear adjacent to each field -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

Häufige Fehler

Verwendung von placeholder als Ersatz für Fehlervorschläge: Platzhaltertext verschwindet, sobald der Benutzer mit der Eingabe beginnt, und wird von Screenreadern nicht zuverlässig als Fehler angekündigt. Verlassen Sie sich niemals ausschließlich auf Platzhaltertext, um nach einem Fehler mitzuteilen, welches Format erforderlich ist.
Fehlermeldungen nur in einer Toast-Benachrichtigung anzeigen, die nach einigen Sekunden verschwindet: Flüchtige Benachrichtigungen sind nicht für alle Benutzer wahrnehmbar – Screenreader-Nutzer können die Ankündigung verpassen, und die Meldung ist verschwunden, bevor ein langsamer Leser sie verarbeiten kann. Fehlervorschläge müssen bestehen bleiben, bis der Fehler behoben ist.
Verwendung von aria-invalid='true' ohne aria-describedby, das auf den Vorschlagstext zeigt: Das Setzen von aria-invalid signalisiert, dass ein Feld einen Fehler hat, aber ohne aria-describedby, das auf das Vorschlagselement verweist, lesen Screenreader den Vorschlagstext beim Fokussieren des Feldes nicht vor.
Bereitstellung des Vorschlags nur im visuellen Design (z. B. ein Tooltip beim Hover) und nicht im DOM: Nur-bei-Hover-Tooltips sind für Tastaturnutzer und Screenreader-Nutzer unzugänglich. Der Vorschlagstext muss im DOM vorhanden und programmatisch mit dem Feld verknüpft sein.
Verwendung ausschließlich von Farbe oder Symbolik, um anzuzeigen, welches Feld einen Fehler hat: Ein roter Rahmen oder ein Warnsymbol stellt keinen Fehlervorschlag dar. Der Vorschlag muss eine Textbeschreibung sein, die die korrigierende Aktion erklärt, nicht ein visueller Indikator.
Schreiben von Vorschlägen, die das Problem, aber nicht die Lösung benennen: „Ihr Passwort ist zu kurz“ identifiziert den Fehler, schlägt aber keine Lösung vor. „Ihr Passwort muss mindestens 8 Zeichen lang sein“ bietet die notwendige korrigierende Anleitung. Beide Teile sind für die Einhaltung von 3.3.3 erforderlich.
Zu breite Anwendung der Sicherheitsausnahme: Die Sicherheitsausnahme gilt eng für Situationen, in denen ein Vorschlag die Sicherheit tatsächlich gefährden würde – typischerweise auf Authentifizierungsfelder beschränkt. Sie gilt nicht für Standardformularfelder wie Namen, Adressen oder Telefonnummern, bei denen generische Fehler nicht gerechtfertigt sind.
Platzierung des Fehlervorschlags hinter der Senden-Schaltfläche oder weit entfernt vom Feld: Fehlervorschläge müssen visuell und programmatisch in der Nähe des Feldes liegen, das sie beschreiben. Alle Fehler am Ende eines langen Formulars zu platzieren, ohne zusätzlich Inline-Vorschläge an jedem Feld bereitzustellen, zwingt Benutzer zum Kontextwechsel und dazu, sich zu merken, welcher Vorschlag zu welchem Feld gehört.
Unterlassen, den Fokus nach einer fehlgeschlagenen serverseitigen Übermittlung auf die Fehlerzusammenfassung zu verschieben: Wenn eine Seite nach einer fehlgeschlagenen Übermittlung neu geladen wird, kehrt der Fokus typischerweise an den Seitenanfang zurück. Ohne programmatisches Fokusmanagement auf die Fehlerzusammenfassung oder das erste fehlerhafte Feld müssen Screenreader-Nutzer die gesamte Seite durchsuchen, um herauszufinden, was schiefgelaufen ist.
Verwendung vager Formulierungen wie „Bitte überprüfen Sie Ihre Eingabe“ oder „Etwas ist schiefgelaufen“: Diese Meldungen liefern keine Informationen darüber, was falsch ist oder wie man es behebt. Jeder Fehlervorschlag muss spezifisch für das Feld und die konkrete Validierungsregel sein, die verletzt wurde.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Barrierefreiheitslandschaft der Türkei hat sich mit dem Präsidialerlass 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, erheblich weiterentwickelt. Dieser Erlass legt verbindliche Anforderungen an die Barrierefreiheit von Web und mobilen Anwendungen fest, die sich an WCAG 2.2 orientieren, wobei Konformität auf Stufe AA für Einrichtungen erforderlich ist, die das vom Ministerium für Familie und Sozialdienste (Aile ve Sosyal Hizmetler Bakanlığı) vergebene Erişilebilirlik Logosu (Barrierefreiheitslogo) anstreben.

WCAG 3.3.3 Error Suggestion fällt als Kriterium der Stufe AA in den Geltungsbereich dieser verbindlichen Anforderung. Jede erfasste Einrichtung, die Formulare betreibt – für Registrierung, Zahlung, Dienstleistungsanträge oder Kontoverwaltung – muss sicherstellen, dass ihre Fehlermeldungen nicht nur Fehler identifizieren, sondern umsetzbare korrigierende Vorschläge bieten, wie in diesem Kriterium beschrieben.

Die vom Präsidialerlass 2025/10 erfassten Einrichtungen umfassen ein breites Spektrum von Sektoren. Öffentliche Institutionen und Regierungsbehörden sind zur Einhaltung verpflichtet, was bedeutet, dass alle E-Government-Portale (z. B. e-Devlet-Dienste, kommunale Portale, Systeme für Leistungsanträge) konforme Implementierungen von Fehlervorschlägen bereitstellen müssen. Angesichts der Tatsache, dass viele staatliche Dienste von Bürgern die Übermittlung komplexer personenbezogener Daten verlangen – Identitätsnummern, Adresscodes, Steuernummern – sind klare Fehlervorschläge in diesem Kontext besonders kritisch.

Banken und Finanzinstitute sind erfasst, einschließlich Online-Banking-Plattformen, Registrierungsformulare für Anlagekonten und Portale für Kreditanträge. Diese Formulare erfassen routinemäßig sensible und präzise formatierte Daten, und das Fehlen korrigierender Vorschläge schafft reale Barrieren für behinderte Kunden und potenzielle rechtliche Risiken.

Krankenhäuser und Gesundheitsdienstleister müssen ebenfalls konform sein, einschließlich Patientenregistrierungssystemen, Terminbuchungsformularen und Portalen für Versicherungsansprüche. Medizinische Formulare beinhalten häufig komplexe Feldanforderungen (Diagnosecodes, Versicherungsnummern, genaue Datumsformate), sodass klare Fehlervorschläge insbesondere für ältere und kognitiv beeinträchtigte Patientinnen und Patienten wichtig sind.

Telekommunikationsunternehmen mit 200,000 oder mehr Abonnenten sind erfasst, einschließlich der Kundenportale großer Betreiber, SIM-Registrierungsformulare und Kontoverwaltungsoberflächen. E-Commerce-Plattformen – einschließlich Checkout-Abläufen und Konto-Registrierung – müssen konform sein, wodurch Error Suggestion direkt für Produkt- und Warenkorb-Formulare relevant ist, die im Zentrum ihrer Geschäftsabläufe stehen.

Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind, fallen ebenfalls in den Geltungsbereich. Buchungsformulare, Anmeldeanträge und Zahlungsoberflächen, die von diesen Einrichtungen betrieben werden, müssen die Standards der Stufe AA einschließlich 3.3.3 erfüllen.

Aus praktischer Compliance-Perspektive sollten Organisationen, die das Erişilebilirlik Logosu anstreben, WCAG 3.3.3 als zentralen Prüfpunkt bei jeder Barrierefreiheitsbewertung behandeln. Manuelle Tests aller Formularvalidierungsabläufe – einschließlich clientseitiger und serverseitiger Fehlerzustände – sind erforderlich, und die Dokumentation der Begründung für Sicherheitsausnahmen sollte für alle Felder geführt werden, bei denen korrigierende Vorschläge bewusst weggelassen werden. Die Nichterfüllung der Anforderungen der Stufe AA, einschließlich Error Suggestion, verhindert die Vergabe des Logos und kann erfasste Einrichtungen administrativen Konsequenzen gemäß dem Erlass aussetzen.