Barrierefreie Fehlerhinweise in Formularen m\u00fcssen f\u00fcr alle Nutzerinnen und Nutzer wahrnehmbar, verst\u00e4ndlich und bedienbar sein. Das bedeutet: Fehler d\u00fcrfen nicht ausschlie\u00dflich durch Farbe signalisiert werden, m\u00fcssen im Text beschrieben werden und m\u00fcssen technisch so ausgezeichnet sein, dass Screenreader sie zuverl\u00e4ssig vorlesen. Diese Anforderungen gelten f\u00fcr alle Websites, die unter das Barrierefreiheitsst\u00e4rkungsgesetz (BFSG) fallen. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um barrierefreie Fehlerbehandlung in Formularen.<\/p>\n
F\u00fcr Fehlerhinweise in Formularen sind vor allem vier WCAG-Erfolgskriterien relevant: 1.3.1 Info und Beziehungen<\/strong>, 3.3.1 Fehlererkennung<\/strong>, 3.3.2 Beschriftungen oder Anweisungen<\/strong> und 3.3.3 Fehlerkorrekturvorschlag<\/strong>. Diese Kriterien legen fest, wie Fehler erkannt, kommuniziert und korrigierbar gemacht werden m\u00fcssen. Die Kriterien 3.3.1 und 3.3.3 geh\u00f6ren zum Konformit\u00e4tslevel AA, das f\u00fcr die meisten rechtlichen Anforderungen nach BFSG und BITV ma\u00dfgeblich ist.<\/p>\n Im Einzelnen regeln diese Kriterien Folgendes:<\/p>\n Erg\u00e4nzend spielt WCAG 4.1.3 (Statusmeldungen)<\/strong> eine wichtige Rolle: Statusmeldungen, die dynamisch in die Seite eingef\u00fcgt werden, m\u00fcssen so ausgezeichnet sein, dass Screenreader sie ank\u00fcndigen, ohne dass der Fokus dorthin verschoben wird. Das betrifft beispielsweise Inline-Validierungsmeldungen, die nach dem Verlassen eines Feldes erscheinen.<\/p>\n Ein barrierefreier Fehlerhinweis muss mindestens drei Elemente enthalten: eine klare Identifikation des betroffenen Feldes<\/strong>, eine Beschreibung des Fehlers in Textform<\/strong> und, wenn m\u00f6glich, einen konkreten Korrekturvorschlag<\/strong>. Rein visuelle Signale wie rote Rahmen oder Ausrufezeichen-Icons sind nicht ausreichend und versto\u00dfen gegen WCAG 3.3.1.<\/p>\n Ein guter Fehlerhinweis erf\u00fcllt folgende Anforderungen:<\/p>\n F\u00fcr Nutzerinnen und Nutzer, die auf Screenreader angewiesen sind, ist die Verkn\u00fcpfung zwischen Fehlermeldung und Eingabefeld besonders kritisch. Fehlt diese Verbindung, h\u00f6ren sie zwar eine Fehlermeldung, wissen aber nicht, welches Feld betroffen ist.<\/p>\n Technisch korrekte Fehlerhinweise erfordern den Einsatz geeigneter HTML-Attribute und ARIA-Rollen. Das Eingabefeld muss \u00fcber Die wichtigsten technischen Anforderungen im \u00dcberblick:<\/p>\n Ein h\u00e4ufiger Fehler in der Praxis ist die Verwendung von Placeholder-Text als Ersatz f\u00fcr eine echte Feldbeschriftung. Platzhaltertexte verschwinden beim Eintippen und stehen dann als Fehlerkontext nicht mehr zur Verf\u00fcgung. Beschriftungen m\u00fcssen daher stets als sichtbares Ja, die Anforderungen an barrierefreie Fehlerhinweise gelten auch f\u00fcr Inline-Validierung, also Fehlermeldungen, die bereits w\u00e4hrend der Eingabe oder direkt nach dem Verlassen eines Feldes erscheinen. Entscheidend ist dabei der Zeitpunkt: Fehlermeldungen, die w\u00e4hrend des Tippens erscheinen, k\u00f6nnen Screenreader-Nutzerinnen und -nutzer unterbrechen und sollten daher erst nach dem Verlassen des Feldes ( F\u00fcr Inline-Validierung gelten dieselben technischen Anforderungen wie f\u00fcr Formularfehler beim Absenden. Zus\u00e4tzlich sind folgende Punkte zu beachten:<\/p>\n WCAG 4.1.3 (Statusmeldungen) ist hier besonders relevant: Jede Statusmeldung, die programmatisch in die Seite eingef\u00fcgt wird, muss so ausgezeichnet sein, dass assistive Technologien sie erkennen und ank\u00fcndigen, ohne dass der Fokus verschoben wird.<\/p>\n Zu den h\u00e4ufigsten Verst\u00f6\u00dfen gegen das Barrierefreiheitsst\u00e4rkungsgesetz im Bereich Formular-Feedback z\u00e4hlen: Fehlermeldungen, die ausschlie\u00dflich durch Farbe signalisiert werden, fehlende programmatische Verkn\u00fcpfung zwischen Fehlertext und Eingabefeld sowie Fehlermeldungen, die f\u00fcr Screenreader nicht wahrnehmbar sind. Diese M\u00e4ngel versto\u00dfen typischerweise gegen WCAG-Kriterien der Level A und AA, die das BFSG als Mindeststandard vorschreibt.<\/p>\n Die h\u00e4ufigsten Fehlerquellen in der Praxis sind:<\/p>\n Das BFSG gilt seit Juni 2025 f\u00fcr neue Produkte und Dienstleistungen im Bereich digitaler Angebote. Wer Formulare auf seiner Website betreibt, sollte diese Punkte systematisch auf Konformit\u00e4t pr\u00fcfen lassen. Automatisierte Tests k\u00f6nnen dabei helfen, viele dieser Fehler schnell zu identifizieren, ersetzen jedoch keine manuelle Pr\u00fcfung aller Aspekte.<\/p>\n Automatisierte Barrierefreiheitstests k\u00f6nnen einen erheblichen Teil der typischen Fehler bei Formular-Fehlerhinweisen erkennen, darunter fehlende Automatisierte Tests decken typischerweise folgende formularrelevante Probleme zuverl\u00e4ssig ab:<\/p>\n Nicht automatisiert pr\u00fcfbar sind hingegen Aspekte wie die inhaltliche Verst\u00e4ndlichkeit der Fehlermeldungen, das Nutzungserlebnis von Screenreader-Nutzerinnen und -nutzern im konkreten Interaktionsablauf oder die korrekte Reihenfolge von Fehlermeldungen bei komplexen Formularen. Sch\u00e4tzungen aus der Fachliteratur gehen davon aus, dass automatisierte Tests je nach Testwerkzeug und Seitentyp zwischen 30 % und 50 % aller Barrierefreiheitsprobleme erfassen. F\u00fcr eine vollst\u00e4ndige Konformit\u00e4tspr\u00fcfung ist daher eine erg\u00e4nzende manuelle Pr\u00fcfung notwendig.<\/p>\n\n
Was muss ein barrierefreier Fehlerhinweis enthalten?<\/h2>\n
\n
Wie m\u00fcssen Fehlerhinweise technisch umgesetzt werden?<\/h2>\n
aria-describedby<\/code><\/strong> mit dem Fehlertext verkn\u00fcpft werden, und bei ung\u00fcltigem Zustand sollte aria-invalid=\"true\"<\/code><\/strong> gesetzt werden. Dynamisch eingef\u00fcgte Fehlermeldungen m\u00fcssen mit einer geeigneten Live-Region ausgezeichnet sein, damit Screenreader sie automatisch ank\u00fcndigen.<\/p>\n\n
aria-invalid=\"true\"<\/code>:<\/strong> Dieses Attribut signalisiert Screenreadern, dass das Eingabefeld einen ung\u00fcltigen Wert enth\u00e4lt. Es sollte gesetzt werden, sobald ein Fehler erkannt wird.<\/li>\naria-describedby<\/code>:<\/strong> Verkn\u00fcpft das Eingabefeld mit dem Element, das den Fehlertext enth\u00e4lt. Screenreader lesen diesen Text automatisch vor, wenn das Feld fokussiert wird.<\/li>\naria-live=\"assertive\"<\/code> oder role=\"alert\"<\/code>:<\/strong> F\u00fcr dynamisch erscheinende Fehlermeldungen sorgen diese Attribute daf\u00fcr, dass der Screenreader die Meldung sofort ank\u00fcndigt, ohne dass der Fokus manuell verschoben werden muss.<\/li>\ndisplay:none<\/code> oder visibility:hidden<\/code> versteckt werden, solange sie aktiv sind, da Screenreader versteckte Inhalte nicht vorlesen.<\/li>\n<\/ul>\n<label><\/code>-Element oder als programmatisch zug\u00e4ngliche Alternative umgesetzt werden.<\/p>\nGilt die Pflicht zur barrierefreien Fehlerbehandlung auch f\u00fcr Inline-Validierung?<\/h2>\n
onblur<\/code>) ausgel\u00f6st werden.<\/p>\n\n
aria-live<\/code> oder role=\"alert\"<\/code>, damit sie ohne Fokuswechsel vorgelesen werden.<\/li>\nWelche Fehler bei Formular-Feedback f\u00fchren zu BFSG-Verst\u00f6\u00dfen?<\/h2>\n
\n
aria-invalid<\/code>-Auszeichnung:<\/strong> Ohne dieses Attribut erkennen Screenreader nicht, dass ein Feld einen Fehler enth\u00e4lt.<\/li>\naria-describedby<\/code> verkn\u00fcpft sind, werden von Screenreadern nicht mit dem Feld in Verbindung gebracht.<\/li>\naria-live<\/code>-Auszeichnung tragen, werden von Screenreadern schlicht ignoriert.<\/li>\nWie lassen sich Fehlerhinweise in Formularen automatisiert pr\u00fcfen?<\/h2>\n
aria-invalid<\/code>-Attribute, nicht verkn\u00fcpfte Fehlertexte und fehlende Label-Zuordnungen. Allerdings sind nicht alle Aspekte automatisiert pr\u00fcfbar: Die inhaltliche Qualit\u00e4t eines Fehlertexts oder das korrekte Timing von Inline-Validierung l\u00e4sst sich nur durch manuelle Tests beurteilen.<\/p>\n\n
<label><\/code>-Elemente<\/li>\naria-required<\/code>-Auszeichnung bei Pflichtfeldern<\/li>\nSo unterst\u00fctzt decareto bei der Pr\u00fcfung barrierefreier Formulare<\/h2>\n