WCAG 3.3.1: Fehlererkennung

Was diese Regel bedeutet

WCAG 3.3.1 Fehlererkennung ist ein Erfolgskriterium der Stufe A unter dem Prinzip Verständlich. Es besagt: „Wenn ein Eingabefehler automatisch erkannt wird, wird das fehlerhafte Element identifiziert und der Fehler dem Benutzer in Textform beschrieben.“ Praktisch bedeutet das: Immer wenn Ihre Website oder Anwendung Benutzereingaben automatisch validiert – sei es beim Absenden des Formulars, beim Verlassen eines Feldes (Blur) oder in Echtzeit – müssen bei einem erkannten Fehler zwei Dinge passieren: Das konkrete Feld oder Steuerelement, das den Fehler enthält, muss eindeutig identifiziert werden, und die Art des Fehlers muss mit tatsächlichem Textinhalt kommuniziert werden (nicht ausschließlich über Farbe, Icon oder Ton).

Das Kriterium gilt für jede Situation, in der Eingaben von Nutzern erfasst und automatisch validiert werden. Dies umfasst HTML-Formularelemente wie <input>, <select>, <textarea> sowie benutzerdefinierte interaktive Widgets, die mit ARIA erstellt wurden. Es deckt clientseitige Validierung ab, die durch JavaScript ausgelöst wird, native Browser-Constraint-Validierung mit Attributen wie required, pattern, minlength und type sowie serverseitige Validierungsergebnisse, die nach einem Neuladen der Seite gerendert oder dynamisch in den DOM eingefügt werden.

Ein Bestehen erfordert, dass: (1) jedes fehlerhafte Feld programmatisch mit einer Fehlermeldung verknüpft ist – typischerweise über aria-describedby oder aria-errormessage –, damit unterstützende Technologien sie ausgeben können; (2) die Fehlermeldung als Klartext in der Benutzeroberfläche sichtbar ist (nicht vor sehenden Nutzern verborgen); und (3) der Text klar beschreibt, was schiefgelaufen ist, nicht nur, dass etwas schiefgelaufen ist. Zum Beispiel ist „E-Mail-Adresse ist erforderlich“ eine gültige Fehlerbeschreibung, während nur ein roter Rahmen oder ein Ausrufezeichen-Icon ohne Textalternative ein Nichtbestehen darstellt.

Ein Nichtbestehen tritt ein, wenn: Fehler ausschließlich durch Farbänderungen angezeigt werden (roter Rahmen ohne Text), Fehler nur über role="alert" angekündigt werden, ohne anzugeben, welches Feld betroffen ist, der Fehlermeldungstext leer oder generisch ist (z. B. „Ungültige Eingabe“), oder Fehlermeldungen zwar im DOM existieren, aber nicht programmatisch mit dem entsprechenden Feld verknüpft sind, sodass Screenreader sie nicht zuordnen können.

WCAG 3.3.1 gilt nicht, wenn keine automatische Erkennung stattfindet – wenn zum Beispiel ein Formular abgesendet wird und der Server die Seite einfach neu lädt, ohne irgendeinen Hinweis darauf zu geben, was schiefgelaufen ist. Das ist zwar ein separates Usability-Problem, fällt aber nicht in den engen Anwendungsbereich dieses Kriteriums. Wenn Ihr System jedoch eine automatische Erkennung durchführt (was praktisch auf alle modernen Formulare zutrifft), ist das Kriterium vollumfänglich relevant. Es gibt innerhalb des Kriteriums selbst keine Ausnahmen für bestimmte Eingabetypen oder Anwendungsfälle.

Warum es wichtig ist

Die Fehlererkennung wirkt sich in erheblichem Maße direkt auf mehrere Gruppen von Menschen mit Behinderungen aus. Für blinde und sehbehinderte Nutzer, die auf Screenreader wie NVDA, JAWS oder VoiceOver angewiesen sind, vermittelt ein roter Rahmen oder ein Warnsymbol keinerlei Information. Wenn eine Fehlermeldung nicht als tatsächlicher Text vorhanden und nicht programmatisch mit dem fehlerhaften Feld verknüpft ist, wird der Screenreader sie nicht ausgeben, und der Nutzer kann ein Formular wiederholt absenden, ohne zu verstehen, warum es fehlschlägt. Laut Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen eine Form von Sehbeeinträchtigung, und Millionen sind täglich auf unterstützende Technologien angewiesen, um mit Webinhalten zu interagieren.

Für Nutzer mit kognitiven Beeinträchtigungen – einschließlich Legasthenie, Aufmerksamkeitsdefizitstörung und Gedächtnisbeeinträchtigungen – stellen vage Fehlermeldungen wie „Etwas ist schiefgelaufen“ erhebliche Barrieren dar. Diese Nutzer profitieren enorm von präzisem, beschreibendem Fehlertest, der ihnen genau sagt, welches Feld korrigiert werden muss und welches Format oder welcher Wert korrekt ist. Anstatt „Ungültiges Datum“ ist zum Beispiel eine Meldung wie „Das Geburtsdatum muss im Format TT/MM/JJJJ eingegeben werden“ deutlich hilfreicher.

Nutzer mit motorischen Beeinträchtigungen, die mit Tastatur oder Schaltgeräten navigieren, müssen erheblichen Aufwand betreiben, um ein Formular zu durchlaufen. Wenn ein Fehler unklar oder nicht identifiziert ist, müssen sie das gesamte Formular erneut durchgehen, um das Problem zu finden, was die kognitive und körperliche Belastung bei der Formularbearbeitung stark erhöht. Eine klare Fehlererkennung ermöglicht es diesen Nutzern, direkt zum problematischen Feld zu springen.

Betrachten Sie folgendes Szenario aus der Praxis: Eine türkische Staatsbürgerin versucht, sich auf einem E-Government-Portal zu registrieren, um eine Leistung wegen einer Behinderung zu beantragen. Das Formular verlangt eine nationale Ausweisnummer in einem bestimmten Format. Die Nutzerin, die blind ist, gibt ihre Ausweisnummer ein. Beim Absenden wird das Formular neu geladen, Felder werden rot hervorgehoben, aber es gibt keinen zugehörigen Fehlertest. Der Screenreader liest nur die Feldbezeichnungen erneut vor – die Nutzerin hat keine Ahnung, was schiefgelaufen ist oder welches Feld das Problem darstellt. Sie bricht den Vorgang vollständig ab und verliert den Zugang zu einem wichtigen öffentlichen Service. Genau diese Situation soll WCAG 3.3.1 verhindern.

Über die Barrierefreiheit hinaus verbessert eine klare Fehlererkennung die Conversion Rates und Usability für alle Nutzer. Studien aus der UX-Forschung zeigen konsistent, dass beschreibende Inline-Fehlermeldungen die Abbruchrate bei Formularen reduzieren. Aus SEO-Perspektive wirken sich verbesserte Nutzersignale – einschließlich längerer Verweildauer und erfolgreicher Formularabschlüsse – langfristig positiv auf das Suchranking aus.

Verwandte Axe-core-Regeln

WCAG 3.3.1 erfordert für eine vollständige Überprüfung manuelle Tests. Der Grund: Automatisierte Tools können das Vorhandensein oder Fehlen struktureller Muster erkennen (wie aria-describedby oder aria-errormessage), aber sie können nicht beurteilen, ob der Textinhalt einer Fehlermeldung sinnvoll, korrekt oder ausreichend ist, um dem Nutzer beim Verstehen und Beheben des Fehlers zu helfen. Ein automatisiertes Tool erkennt, dass ein Element mit role="alert" existiert; es kann aber nicht bewerten, ob die Meldung „Fehler in Zeile 4“ eine Validierungsverletzung für einen Screenreader-Nutzer ausreichend beschreibt.

• aria-required-attr: Diese axe-core-Regel prüft, ob Elemente mit bestimmten ARIA-Rollen alle erforderlichen ARIA-Attribute besitzen. Sie ist zwar nicht ausschließlich eine Regel zur Fehlererkennung, aber relevant, weil ein Formularfeld im Fehlerzustand, das role="textbox" oder Ähnliches verwendet, ohne die erforderlichen Attribute möglicherweise keine Zustandsinformationen an unterstützende Technologien übermittelt und damit die Fehlerkommunikation untergräbt.
• aria-valid-attr-value: Diese Regel markiert Fälle, in denen ARIA-Attribute auf IDs verweisen, die im DOM nicht existieren. Wenn ein Feld zum Beispiel aria-describedby="email-error" verwendet, aber kein Element mit id="email-error" existiert, ist die Verknüpfung unterbrochen und die Fehlermeldung wird von Screenreadern nicht vorgelesen. Dies ist ein häufiges Muster des Nichtbestehens für 3.3.1.
• Erfordernis manueller Bewertung: Tester müssen Validierungsfehler manuell auslösen und dann einen Screenreader verwenden, um zu bestätigen, dass: das fehlerhafte Feld anhand seines Namens oder Labels identifiziert wird, die Fehlerbeschreibung ausgegeben wird, die Meldung sinnvoll und handlungsleitend ist und der Fehler nicht ausschließlich über nicht-textuelle Mittel kommuniziert wird. Automatisierte Scans können keine Benutzerinteraktionsabläufe simulieren oder die semantische Qualität von Meldungstexten bewerten, weshalb menschliches Urteil für dieses Kriterium unverzichtbar ist.

Wie man testet

1. Automatischer Scan mit axe DevTools oder Lighthouse: Führen Sie einen axe-DevTools-Scan auf der Seite mit dem Formular vor und nach dem Auslösen von Validierungsfehlern aus. Achten Sie speziell auf Verstöße im Zusammenhang mit fehlerhaften aria-describedby- oder aria-errormessage-Referenzen, fehlenden role="alert"- oder aria-live-Regionen für dynamische Fehlerausgabe und Formularfeldern ohne Labels (was ebenfalls eine korrekte Fehlerverknüpfung verhindert). Prüfen Sie in Lighthouse im Accessibility-Audit formularbezogene Verstöße. Beachten Sie, dass ein fehlerfreier automatischer Bericht die Konformität mit 3.3.1 nicht bestätigt – er schließt nur bestimmte strukturelle Fehler aus.
2. Manueller Tastaturnavigationstest: Versuchen Sie ausschließlich mit der Tastatur (Tab, Shift+Tab, Enter, Leertaste), das Formular mit absichtlich falschen oder fehlenden Werten abzusenden. Überprüfen Sie, ob: der Fokus zum ersten fehlerhaften Feld oder in dessen Nähe springt, jede Fehlermeldung im sichtbaren Bereich liegt und die Fehlermeldungen das konkrete Feld beim Namen nennen und das Problem in Klartext beschreiben.
3. Screenreader-Test mit NVDA + Firefox: Öffnen Sie das Formular in Firefox mit aktivem NVDA. Senden Sie das Formular mit Fehlern ab. Hören Sie genau hin: Gibt NVDA an, welches Feld einen Fehler hat? Wird die Fehlerbeschreibung vorgelesen? Tabben Sie in das fehlerhafte Feld – liest NVDA die zugehörige Fehlermeldung als Teil der zugänglichen Beschreibung des Feldes vor? Wenn aria-live-Regionen verwendet werden, prüfen Sie, ob die Ausgabe nicht verzögert oder unterdrückt wird.
4. Screenreader-Test mit VoiceOver + Safari (macOS/iOS): Wiederholen Sie denselben Prozess mit VoiceOver in Safari. Verwenden Sie VO+Rechtspfeil, um das Formular nach dem Absenden durchzugehen. Bestätigen Sie, dass jedes fehlerhafte Feld den Fehlertest in seinem zugänglichen Namen oder seiner Beschreibung enthält. Testen Sie auf iOS mit Touch-Navigation und Wischgesten.
5. Screenreader-Test mit JAWS + Chrome: Senden Sie mit laufendem JAWS in Chrome das Formular mit Fehlern ab. Verwenden Sie den virtuellen Cursor von JAWS, um zu jedem fehlerhaften Formularfeld zu navigieren. Bestätigen Sie, dass der Fehlermeldungstext in der Ausgabe von JAWS für das Feld enthalten ist. Prüfen Sie auch das Verhalten im JAWS-Formularmodus, da dieser einige Live-Region-Ausgaben unterdrücken kann.
6. Prüfung von Farb- und nicht-textuellen Hinweisen: Untersuchen Sie jeden Fehlerzustand visuell. Entfernen oder deaktivieren Sie CSS vorübergehend (mit den Entwicklertools des Browsers oder einem Bookmarklet) und stellen Sie sicher, dass die Fehlererkennung weiterhin als Text im DOM vorhanden ist. So wird überprüft, dass die Fehlerkommunikation nicht ausschließlich auf Farbe oder Ikonografie beruht.
7. Prüfung dynamischer Einfügungen: Verwenden Sie bei Single-Page-Anwendungen oder Formularen mit Echtzeitvalidierung die Entwicklertools des Browsers, um den DOM nach einem ausgelösten Fehler zu untersuchen. Bestätigen Sie, dass das Fehlermeldungselement im DOM existiert, nicht-leeren Text enthält und über aria-describedby oder aria-errormessage vom entsprechenden Eingabefeld referenziert wird.

Wie man es behebt

Szenario 1: Fehler nur durch Farbe angezeigt – Falsch

<!-- Fail: red border added via class, no error text associated -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' class='input-error'>
<!-- CSS sets border: 2px solid red on .input-error -->
<!-- No error message text is rendered in the DOM -->

Szenario 1: Fehler nur durch Farbe angezeigt – Richtig

<!-- Pass: error text is present, visible, and linked to the input -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-describedby='email-error'
  aria-invalid='true'
>
<!-- aria-invalid signals the error state to assistive technologies -->
<!-- aria-describedby links the input to its error message by ID -->
<p id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</p>

Szenario 2: Generische Fehlerzusammenfassung ohne Feldidentifikation – Falsch

<!-- Fail: a summary alert exists but does not identify which fields failed -->
<div role='alert'>
  <p>There are errors in the form. Please correct them and try again.</p>
</div>
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' name='phone' class='is-invalid'>
<!-- No per-field error message; user cannot determine which field failed -->

Szenario 2: Generische Fehlerzusammenfassung ohne Feldidentifikation – Richtig

<!-- Pass: summary lists specific fields in error, and each field has inline error text -->
<div role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>2 errors found. Please fix the following:</h2>
  <ul>
    <li><a href='#phone'>Phone Number: must contain only digits and be 10 characters long</a></li>
    <li><a href='#dob'>Date of Birth: required field — please enter your date of birth</a></li>
  </ul>
</div>
<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-error'
  aria-invalid='true'
>
<!-- Inline error linked via aria-describedby -->
<p id='phone-error'>Phone Number must contain only digits and be 10 characters long.</p>

Szenario 3: Defekte aria-describedby-Referenz – Falsch

<!-- Fail: aria-describedby references an ID that does not exist in the DOM -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- The element with id='username-msg' was never rendered or was removed -->
<!-- Screen readers find no target and announce nothing for the description -->

Szenario 3: Defekte aria-describedby-Referenz – Richtig

<!-- Pass: the referenced element exists in the DOM with matching ID -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- Element with matching id is present and contains descriptive text -->
<span id='username-msg'>
  Username must be between 4 and 20 characters and contain only letters and numbers.
</span>

Szenario 4: In Echtzeit dynamisch eingefügter Validierungsfehler – Falsch

<!-- Fail: error injected into DOM but not associated with input; no live region -->
<label for='password'>Password</label>
<input type='password' id='password' name='password'>
<!-- After blur, JavaScript appends this element, but no aria-describedby on input -->
<div class='error-text'>Password is too short.</div>

Szenario 4: In Echtzeit dynamisch eingefügter Validierungsfehler – Richtig

<!-- Pass: error container pre-exists in DOM (empty), input references it; aria-live announces changes -->
<label for='password'>Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-describedby='password-error'
  aria-invalid='false'
>
<!-- Empty span present at page load; JavaScript populates text and sets aria-invalid='true' on error -->
<span id='password-error' aria-live='polite'></span>
<!-- JavaScript on blur: -->
<!-- document.getElementById('password-error').textContent = 'Password must be at least 8 characters.'; -->
<!-- document.getElementById('password').setAttribute('aria-invalid', 'true'); -->

Häufige Fehler

• Nur CSS-Klassenänderungen (z. B. Hinzufügen von border-color: red) zur Fehleranzeige zu verwenden, ohne entsprechenden Text im DOM. Farbe allein ist für blinde Nutzer oder Nutzer mit Farbfehlsichtigkeit nicht wahrnehmbar und verstößt sowohl gegen 3.3.1 als auch 1.4.1.
• aria-describedby auf das Eingabefeld zu schreiben, aber auf eine ID zu verweisen, die bei Zurücksetzen der Validierung bedingt gerendert oder aus dem DOM entfernt wird. Die defekte Referenz bedeutet, dass der Screenreader keinen zugehörigen Inhalt findet und der Fehler für Nutzer unterstützender Technologien faktisch unsichtbar ist.
• Platzhaltertext (placeholder) als einzige Fehlermeldung zu verwenden. Platzhaltertext verschwindet, sobald der Nutzer zu tippen beginnt, ist oft kontrastarm und wird von Screenreadern in Fehlerzuständen nicht zuverlässig als Teil der Feldbeschreibung ausgegeben.
• Fehlermeldungen dynamisch in den DOM einzufügen, ohne sicherzustellen, dass sie über aria-describedby mit ihrem übergeordneten Feld verknüpft sind. Eine visuell benachbarte Fehlermeldung ist nicht automatisch mit einer Eingabe verknüpft – die programmatische Verbindung muss explizit hergestellt werden.
• Eine seitenweite Fehlerzusammenfassung anzuzeigen, ohne jeden Eintrag mit dem konkreten fehlerhaften Feld zu verlinken. Screenreader- oder Tastaturnutzer müssen direkt von der Fehlerbeschreibung zu dem Feld springen können, das korrigiert werden muss.
• aria-invalid='true' auf ein Feld zu setzen, ohne einen Fehlermeldungstext bereitzustellen. Das Attribut aria-invalid signalisiert, dass sich ein Feld im Fehlerzustand befindet, beschreibt den Fehler aber nicht – es muss mit einer beschreibenden Meldung kombiniert werden.
• Fehlermeldungen zu generisch zu formulieren, etwa „Ungültige Eingabe“ oder „Fehler im Feld“. Diese Beschreibungen erklären nicht, was falsch ist oder wie es behoben werden kann, verfehlen die Anforderung an die Beschreibung in 3.3.1 und erschweren die Fehlerkorrektur unnötig für alle Nutzer.
• aria-live-Regionen oder role='alert' aus Fehlercontainern zu entfernen, wenn ein Formular zurückgesetzt wird, sodass die Container verschwinden, bevor Screenreader ihre Inhalte vollständig ausgegeben haben. Fehleransagen können abgeschnitten werden, sodass der Nutzer nichts vom Validierungsergebnis mitbekommt.
• Sich auf native Browser-Validierungsblasen (die standardmäßigen Tooltip-Popups des Browsers) ohne Anpassung zu verlassen. Native Browser-Validierungs-UIs sind über Browser- und Screenreader-Kombinationen hinweg inkonsistent und erfüllen in komplexen Formularszenarien häufig nicht die WCAG-Anforderungen an Identifikation und Beschreibung.
• Fehlermeldungen visuell weit von ihren zugehörigen Feldern zu platzieren – etwa nur in einer Hinweisbox im Kopfbereich – ohne zusätzlich Inline-Meldungen in Feldnähe bereitzustellen. Nutzer mit Sehbehinderung, die den Bildschirm vergrößern, sehen den Hinweis im Kopfbereich möglicherweise nicht, während sie sich auf den Eingabebereich konzentrieren, und Tastaturnutzer müssen eine große Strecke zurücklegen, um die Fehlermeldung zu lesen.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Web-Barrierefreiheit für eine breite Palette von in der Türkei tätigen Einrichtungen fest. Die Verfügung übernimmt WCAG 2.2 als technischen Standard und macht damit alle Erfolgskriterien der Stufe A – einschließlich WCAG 3.3.1 Fehlererkennung – für die betroffenen Organisationen rechtlich verbindlich.

Der in der Verfügung festgelegte Umsetzungszeitraum beträgt ein Jahr für öffentliche Institutionen und zwei Jahre für private Sektoren ab dem Veröffentlichungsdatum. Das bedeutet, dass öffentliche Institutionen bis Juni 2026 die Konformität mit WCAG 2.2 Stufe A erreichen müssen und betroffene private Unternehmen bis Juni 2027.

Die von der Verfügung erfassten Einrichtungen umfassen ein breites Spektrum türkischer digitaler Dienste. Öffentliche Institutionen – einschließlich aller zentralen Regierungsministerien, Kommunen, staatlichen Universitäten und öffentlichen Behörden – sind verpflichtet, die Barrierefreiheit ihrer digitalen Dienste sicherzustellen. Im privaten Sektor umfasst die Verfügung E-Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) zugelassen sind.

Für all diese Einrichtungen ist WCAG 3.3.1 überall dort direkt relevant, wo Online-Formulare verwendet werden – was in der Praxis nahezu jeden digitalen Kontaktpunkt betrifft. E-Commerce-Checkout-Formulare, Prozesse zur Kontoeröffnung bei Banken, Patientenregistrierungsportale von Krankenhäusern, Antragsformulare für staatliche Leistungen, Buchungssysteme von Flug- und Busunternehmen und Anmeldeseiten von Schulen sind alle auf Formularvalidierung angewiesen. Wenn eines dieser Systeme einen Eingabefehler automatisch erkennt, aber das Feld nicht identifiziert oder den Fehler nicht in Textform beschreibt, verstößt es direkt gegen die Anforderungen der Verfügung.

Nichtkonformität mit der Verfügung kann die betroffenen Einrichtungen regulatorischer Prüfung, Reputationsrisiken und potenziellen Sanktionen aussetzen, während sich der Rahmen für die Durchsetzung der digitalen Barrierefreiheit in der Türkei weiterentwickelt. Über die rechtliche Konformität hinaus zeigt die Einhaltung von 3.3.1 ein Bekenntnis zu inklusiver Leistungserbringung – sie stellt sicher, dass alle Bürger, einschließlich der etwa 8,5 Millionen Menschen mit Behinderungen in der Türkei (laut TÜİK-Daten), ohne Barrieren online auf essenzielle Dienste zugreifen können. Organisationen, die mit dem SDK-Framework von Accsible arbeiten, sollten sowohl automatisierte strukturelle Konformität als auch gründliche manuelle Tests priorisieren, um sicherzustellen, dass ihre Fehlerbehandlung dieses grundlegende Kriterium vollständig erfüllt.