Welche Barrierefreiheitsanforderungen gelten für Fehlerhinweise in Formularen?

Barrierefreie Fehlerhinweise in Formularen müssen für alle Nutzerinnen und Nutzer wahrnehmbar, verständlich und bedienbar sein. Das bedeutet: Fehler dürfen nicht ausschließlich durch Farbe signalisiert werden, müssen im Text beschrieben werden und müssen technisch so ausgezeichnet sein, dass Screenreader sie zuverlässig vorlesen. Diese Anforderungen gelten für alle Websites, die unter das Barrierefreiheitsstärkungsgesetz (BFSG) fallen. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um barrierefreie Fehlerbehandlung in Formularen.

Welche WCAG-Kriterien betreffen Fehlerhinweise in Formularen?

Für Fehlerhinweise in Formularen sind vor allem vier WCAG-Erfolgskriterien relevant: 1.3.1 Info und Beziehungen, 3.3.1 Fehlererkennung, 3.3.2 Beschriftungen oder Anweisungen und 3.3.3 Fehlerkorrekturvorschlag. Diese Kriterien legen fest, wie Fehler erkannt, kommuniziert und korrigierbar gemacht werden müssen. Die Kriterien 3.3.1 und 3.3.3 gehören zum Konformitätslevel AA, das für die meisten rechtlichen Anforderungen nach BFSG und BITV maßgeblich ist.

Im Einzelnen regeln diese Kriterien Folgendes:

• WCAG 1.3.1 (Info und Beziehungen): Informationen, die durch visuelle Formatierung vermittelt werden, müssen auch programmatisch erkennbar sein. Ein rot umrandetes Eingabefeld allein genügt nicht.
• WCAG 3.3.1 (Fehlererkennung): Wenn ein Eingabefehler automatisch erkannt wird, muss das fehlerhafte Element identifiziert und der Fehler in Textform beschrieben werden.
• WCAG 3.3.2 (Beschriftungen oder Anweisungen): Eingabefelder müssen klare Beschriftungen und, wo nötig, Formathinweise erhalten, bevor Fehler überhaupt entstehen können.
• WCAG 3.3.3 (Fehlerkorrekturvorschlag): Wenn die Art des Fehlers bekannt ist und ein Korrekturvorschlag keine Sicherheitsrisiken verursacht, muss dieser Vorschlag angeboten werden.

Ergänzend spielt WCAG 4.1.3 (Statusmeldungen) eine wichtige Rolle: Statusmeldungen, die dynamisch in die Seite eingefügt werden, müssen so ausgezeichnet sein, dass Screenreader sie ankündigen, ohne dass der Fokus dorthin verschoben wird. Das betrifft beispielsweise Inline-Validierungsmeldungen, die nach dem Verlassen eines Feldes erscheinen.

Was muss ein barrierefreier Fehlerhinweis enthalten?

Ein barrierefreier Fehlerhinweis muss mindestens drei Elemente enthalten: eine klare Identifikation des betroffenen Feldes, eine Beschreibung des Fehlers in Textform und, wenn möglich, einen konkreten Korrekturvorschlag. Rein visuelle Signale wie rote Rahmen oder Ausrufezeichen-Icons sind nicht ausreichend und verstoßen gegen WCAG 3.3.1.

Ein guter Fehlerhinweis erfüllt folgende Anforderungen:

• Textbasiert: Der Fehler wird in lesbarem Text beschrieben, nicht nur durch Farbe oder Symbol signalisiert.
• Spezifisch: Statt „Ungültige Eingabe“ sollte der Hinweis lauten: „Bitte geben Sie eine gültige E-Mail-Adresse ein, zum Beispiel name@beispiel.de.“
• Zugeordnet: Der Fehlertext ist programmatisch mit dem Eingabefeld verknüpft, sodass Screenreader die Verbindung erkennen.
• Zeitlich sinnvoll: Der Hinweis erscheint zu einem Zeitpunkt, der die Nutzung nicht unterbricht, typischerweise nach dem Verlassen des Feldes oder beim Absenden des Formulars.
• Ohne Farbe als alleiniges Mittel: Farbe darf ergänzend eingesetzt werden, aber nie als einzige Methode zur Fehlerkommunikation (WCAG 1.4.1).

Für Nutzerinnen und Nutzer, die auf Screenreader angewiesen sind, ist die Verknüpfung zwischen Fehlermeldung und Eingabefeld besonders kritisch. Fehlt diese Verbindung, hören sie zwar eine Fehlermeldung, wissen aber nicht, welches Feld betroffen ist.

Wie müssen Fehlerhinweise technisch umgesetzt werden?

Technisch korrekte Fehlerhinweise erfordern den Einsatz geeigneter HTML-Attribute und ARIA-Rollen. Das Eingabefeld muss über aria-describedby mit dem Fehlertext verknüpft werden, und bei ungültigem Zustand sollte aria-invalid="true" gesetzt werden. Dynamisch eingefügte Fehlermeldungen müssen mit einer geeigneten Live-Region ausgezeichnet sein, damit Screenreader sie automatisch ankündigen.

Die wichtigsten technischen Anforderungen im Überblick:

• aria-invalid="true": Dieses Attribut signalisiert Screenreadern, dass das Eingabefeld einen ungültigen Wert enthält. Es sollte gesetzt werden, sobald ein Fehler erkannt wird.
• aria-describedby: Verknüpft das Eingabefeld mit dem Element, das den Fehlertext enthält. Screenreader lesen diesen Text automatisch vor, wenn das Feld fokussiert wird.
• aria-live="assertive" oder role="alert": Für dynamisch erscheinende Fehlermeldungen sorgen diese Attribute dafür, dass der Screenreader die Meldung sofort ankündigt, ohne dass der Fokus manuell verschoben werden muss.
• Fokusmanagement: Beim Absenden eines Formulars mit Fehlern sollte der Fokus auf den ersten Fehler oder eine zusammenfassende Fehlerliste gesetzt werden, damit Tastaturnutzerinnen und -nutzer sofort an der richtigen Stelle landen.
• Sichtbarkeit im DOM: Fehlermeldungen dürfen nicht mit display:none oder visibility:hidden versteckt werden, solange sie aktiv sind, da Screenreader versteckte Inhalte nicht vorlesen.

Ein häufiger Fehler in der Praxis ist die Verwendung von Placeholder-Text als Ersatz für eine echte Feldbeschriftung. Platzhaltertexte verschwinden beim Eintippen und stehen dann als Fehlerkontext nicht mehr zur Verfügung. Beschriftungen müssen daher stets als sichtbares <label>-Element oder als programmatisch zugängliche Alternative umgesetzt werden.

Gilt die Pflicht zur barrierefreien Fehlerbehandlung auch für Inline-Validierung?

Ja, die Anforderungen an barrierefreie Fehlerhinweise gelten auch für Inline-Validierung, also Fehlermeldungen, die bereits während der Eingabe oder direkt nach dem Verlassen eines Feldes erscheinen. Entscheidend ist dabei der Zeitpunkt: Fehlermeldungen, die während des Tippens erscheinen, können Screenreader-Nutzerinnen und -nutzer unterbrechen und sollten daher erst nach dem Verlassen des Feldes (onblur) ausgelöst werden.

Für Inline-Validierung gelten dieselben technischen Anforderungen wie für Formularfehler beim Absenden. Zusätzlich sind folgende Punkte zu beachten:

• Kein zu frühes Auslösen: Fehler sollten nicht bereits beim ersten Zeichen angezeigt werden. Das frustriert Nutzerinnen und Nutzer und kann Screenreader-Nutzer unnötig ablenken.
• Live-Regions korrekt einsetzen: Dynamisch eingefügte Inline-Fehlermeldungen benötigen aria-live oder role="alert", damit sie ohne Fokuswechsel vorgelesen werden.
• Erfolgreiche Eingaben ebenfalls kommunizieren: Wenn ein Feld korrekt ausgefüllt wurde, kann eine positive Rückmeldung hilfreich sein. Auch diese muss barrierefrei kommuniziert werden, ohne aufdringlich zu sein.

WCAG 4.1.3 (Statusmeldungen) ist hier besonders relevant: Jede Statusmeldung, die programmatisch in die Seite eingefügt wird, muss so ausgezeichnet sein, dass assistive Technologien sie erkennen und ankündigen, ohne dass der Fokus verschoben wird.

Welche Fehler bei Formular-Feedback führen zu BFSG-Verstößen?

Zu den häufigsten Verstößen gegen das Barrierefreiheitsstärkungsgesetz im Bereich Formular-Feedback zählen: Fehlermeldungen, die ausschließlich durch Farbe signalisiert werden, fehlende programmatische Verknüpfung zwischen Fehlertext und Eingabefeld sowie Fehlermeldungen, die für Screenreader nicht wahrnehmbar sind. Diese Mängel verstoßen typischerweise gegen WCAG-Kriterien der Level A und AA, die das BFSG als Mindeststandard vorschreibt.

Die häufigsten Fehlerquellen in der Praxis sind:

• Farbe als alleiniges Signal: Ein rot umrandetes Feld ohne begleitenden Fehlertext verstößt gegen WCAG 1.4.1 und 3.3.1.
• Fehlende aria-invalid-Auszeichnung: Ohne dieses Attribut erkennen Screenreader nicht, dass ein Feld einen Fehler enthält.
• Nicht verknüpfte Fehlertexte: Fehlermeldungen, die räumlich neben einem Feld stehen, aber nicht per aria-describedby verknüpft sind, werden von Screenreadern nicht mit dem Feld in Verbindung gebracht.
• Dynamische Meldungen ohne Live-Region: Fehler, die nach dem Absenden eines Formulars dynamisch erscheinen, aber keine aria-live-Auszeichnung tragen, werden von Screenreadern schlicht ignoriert.
• Fehlende Fokussteuerung: Wenn nach dem Absenden eines fehlerhaften Formulars der Fokus nicht auf den Fehler gesetzt wird, müssen Tastaturnutzerinnen und -nutzer die gesamte Seite neu navigieren, um den Fehler zu finden.
• Unspezifische Fehlertexte: Generische Meldungen wie „Fehler“ oder „Pflichtfeld“ ohne weitere Erklärung verstoßen gegen WCAG 3.3.3, wenn eine spezifischere Beschreibung möglich wäre.

Das BFSG gilt seit Juni 2025 für neue Produkte und Dienstleistungen im Bereich digitaler Angebote. Wer Formulare auf seiner Website betreibt, sollte diese Punkte systematisch auf Konformität prüfen lassen. Automatisierte Tests können dabei helfen, viele dieser Fehler schnell zu identifizieren, ersetzen jedoch keine manuelle Prüfung aller Aspekte.

Wie lassen sich Fehlerhinweise in Formularen automatisiert prüfen?

Automatisierte Barrierefreiheitstests können einen erheblichen Teil der typischen Fehler bei Formular-Fehlerhinweisen erkennen, darunter fehlende aria-invalid-Attribute, nicht verknüpfte Fehlertexte und fehlende Label-Zuordnungen. Allerdings sind nicht alle Aspekte automatisiert prüfbar: Die inhaltliche Qualität eines Fehlertexts oder das korrekte Timing von Inline-Validierung lässt sich nur durch manuelle Tests beurteilen.

Automatisierte Tests decken typischerweise folgende formularrelevante Probleme zuverlässig ab:

• Fehlende oder falsch verknüpfte <label>-Elemente
• Eingabefelder ohne zugänglichen Namen
• Fehlende aria-required-Auszeichnung bei Pflichtfeldern
• Verwendung von Placeholder-Text als einzige Beschriftung
• Fehlende Verknüpfung zwischen Fehlermeldung und Eingabefeld
• ARIA-Attribute mit ungültigen Werten

Nicht automatisiert prüfbar sind hingegen Aspekte wie die inhaltliche Verständlichkeit der Fehlermeldungen, das Nutzungserlebnis von Screenreader-Nutzerinnen und -nutzern im konkreten Interaktionsablauf oder die korrekte Reihenfolge von Fehlermeldungen bei komplexen Formularen. Schätzungen aus der Fachliteratur gehen davon aus, dass automatisierte Tests je nach Testwerkzeug und Seitentyp zwischen 30 % und 50 % aller Barrierefreiheitsprobleme erfassen. Für eine vollständige Konformitätsprüfung ist daher eine ergänzende manuelle Prüfung notwendig.

So unterstützt decareto bei der Prüfung barrierefreier Formulare

Wir bei decareto bieten eine automatisierte Barrierefreiheits-Software, die Websites systematisch auf Verstöße gegen WCAG, BITV und BFSG scannt, einschließlich typischer Fehler bei Formular-Fehlerhinweisen. Unser Tool hilft Ihnen dabei, Schwachstellen schnell zu identifizieren und priorisiert zu beheben.

Was decareto konkret für Sie leistet:

• Automatisierter Scan aller Unterseiten: Wir prüfen nicht nur die Startseite, sondern alle relevanten Unterseiten Ihrer Website, einschließlich Seiten mit Formularen.
• Erkennung formularspezifischer Probleme: Fehlende Label-Verknüpfungen, falsch eingesetzte ARIA-Attribute, unzureichende Fehlerkommunikation und weitere Schwachstellen werden automatisch erkannt und nach Schweregrad priorisiert.
• Konkrete Handlungsempfehlungen: Zu jedem gefundenen Problem liefern wir klare Hinweise, wie es behoben werden kann, formuliert für Entwicklerinnen und Entwickler sowie für Beraterinnen und Berater.
• Kontinuierliche Überwachung: Hunderte Websites lassen sich dauerhaft überwachen. Bei Änderungen, die neue Barrieren einführen, erhalten Sie automatische Benachrichtigungen.
• Teilbare Reports: Barrierefreiheits-Reports können direkt mit Kunden geteilt werden, auch ohne eigenen Zugang zur Plattform. Eine Whitelabel-Funktion ermöglicht es Agenturen, Reports unter eigenem Logo auszuliefern.

Bitte beachten Sie: Automatisierte Tests ersetzen keine vollständige manuelle Prüfung. Passing automated checks does not equal full legal conformity. decareto unterstützt Ihre Compliance-Arbeit, ersetzt jedoch nicht die Beurteilung durch qualifizierte Fachkräfte oder rechtliche Beratung.

Möchten Sie Ihre Website auf barrierefreie Fehlerhinweise und weitere Zugänglichkeitsprobleme prüfen? Jetzt kostenlos starten und einen ersten Scan durchführen.

Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.

Ähnliche Artikel

• Brauchen auch Freelancer und Solo-Selbstständige eine DSGVO-Website-Prüfung?
• Was bedeutet WCAG-Konformität für Agenturen und ihre Kunden?
• Wie erkennt man fehlende Sprachauszeichnung auf einer Website?
• Welchen Nutzen bietet Single Sign-On (SSO) für Compliance-Teams bei DSGVO-Prüfungen?
• Welche DSGVO-Anforderungen gelten für internationale Websites mit deutschsprachigem Publikum?