Wenn eine Website Geld verdient, dann an ihren Formularen – im Checkout, im Kontaktformular, in der Anmeldung. Und genau dort scheitern in meinen Audits die meisten Nutzer mit assistiver Technologie. Barrierefreie Formulare sind deshalb nicht irgendein Detail, sondern der Punkt, an dem Barrierefreiheit und Conversion direkt aufeinandertreffen: Ein Formular, das ein Screenreader-Nutzer nicht ausfüllen kann, ist ein verlorener Kunde – und je nach Branche ein Compliance-Verstoß mit Bußgeldrisiko. In diesem Ratgeber zeige ich Ihnen die Anatomie eines wirklich bedienbaren Formulars, mit besonderem Augenmerk auf das, was am häufigsten falsch gemacht wird: die Fehlerausgabe für Screenreader.
Was ein Formular barrierefrei macht
Ein barrierefreies Formular lässt sich von jedem Nutzer vollständig ausfüllen und absenden – per Tastatur, mit Screenreader, mit Sprachsteuerung oder Maus. Das setzt voraus, dass jedes Feld eine eindeutig zugeordnete, sichtbare Beschriftung hat, dass Pflichtfelder klar erkennbar sind, dass Fehler nicht nur farblich, sondern auch textlich und für assistive Technologien wahrnehmbar gemeldet werden und dass die gesamte Bedienung ohne Maus funktioniert. Entscheidend ist, dass diese Informationen nicht nur sichtbar, sondern auch programmatisch verfügbar sind – also im Code so verankert, dass ein Screenreader sie vorlesen kann.
Die Anatomie eines bedienbaren Formulars
Gehen wir ein Formular von oben nach unten durch. Jeder dieser Bausteine entscheidet darüber, ob das Formular für alle funktioniert oder nur für Sehende mit Maus.
Labels: sichtbar und fest verknüpft
Jedes Eingabefeld braucht eine echte Beschriftung, die im Code mit dem Feld verknüpft ist – technisch über die Zuordnung von Label und Feld-ID. Nur so weiß ein Screenreader, dass „E-Mail-Adresse“ zu genau diesem Eingabefeld gehört. Der häufigste Fehler: das Label durch einen Platzhalter im Feld zu ersetzen. Platzhaltertext verschwindet, sobald jemand zu tippen beginnt, hat oft zu wenig Kontrast und wird von assistiven Technologien nicht zuverlässig als Beschriftung erkannt. Ein Platzhalter ist nie ein Ersatz für ein Label.
Zusammengehörige Felder gruppieren
Felder, die inhaltlich zusammengehören – eine Gruppe von Auswahloptionen, ein Adressblock, eine Ja-Nein-Entscheidung mit mehreren Optionen –, sollten als Gruppe ausgezeichnet und mit einer gemeinsamen Überschrift versehen sein. Für Screenreader-Nutzer ist das der Kontext, der einzelne Optionen erst verständlich macht. Ohne Gruppierung hören sie eine Reihe zusammenhangloser Auswahlmöglichkeiten.
Pflichtfelder eindeutig kennzeichnen
Pflichtfelder müssen auf mehr als nur einer Ebene erkennbar sein. Ein rotes Sternchen allein reicht nicht – die Information „Pflichtfeld“ muss auch im Code hinterlegt und damit für Screenreader hörbar sein. Am besten kombinieren Sie eine sichtbare Kennzeichnung im Label-Text mit der entsprechenden programmatischen Auszeichnung.
Eingabetypen und Autovervollständigung
Korrekte Feldtypen sorgen dafür, dass auf dem Smartphone die passende Tastatur erscheint – ein Ziffernblock für Telefonnummern, das At-Zeichen für E-Mail-Felder. Ergänzend hilft die Auszeichnung des Eingabezwecks, damit Browser und assistive Technologien Felder automatisch vorausfüllen können. Das reduziert den Aufwand für alle Nutzer und ist für Menschen mit motorischen oder kognitiven Einschränkungen eine echte Erleichterung. All das baut auf sauberem, semantischem Code auf, wie ich ihn in Semantisches HTML als Fundament der Barrierefreiheit beschreibe.
Fehlermeldungen, die auch ein Screenreader versteht
Hier liegt der kritischste und am häufigsten unterschätzte Teil. Ein Formular, das Fehler nur durch ein rot umrandetes Feld signalisiert, lässt blinde Nutzer im Dunkeln. Eine wirklich barrierefreie Fehlerbehandlung erfüllt vier Bedingungen.
Erstens, Fehler werden textlich beschrieben, nicht nur farblich. Statt nur das Feld rot zu färben, braucht es eine sichtbare Textmeldung, die konkret sagt, was falsch ist – und zwar spezifisch: „Bitte geben Sie eine gültige E-Mail-Adresse mit @ ein“ statt eines pauschalen „Fehler“.
Zweitens, die Fehlermeldung ist mit dem Feld verknüpft. Über die programmatische Zuordnung der Meldung zum Eingabefeld liest der Screenreader beim Fokussieren des Feldes direkt den zugehörigen Fehler mit vor. Das fehlerhafte Feld wird zusätzlich als ungültig markiert, sodass die assistive Technologie den Zustand kennt.
Drittens, der Fehler wird aktiv angekündigt. Wenn die Validierung anschlägt, muss die Meldung in einem Bereich erscheinen, den der Screenreader automatisch vorliest, ohne dass der Nutzer dorthin navigieren muss. Technisch geschieht das über eine Live-Region, die Änderungen sofort ansagt. Ohne diese Ankündigung bemerkt ein blinder Nutzer gar nicht, dass das Absenden fehlgeschlagen ist.
Viertens, es gibt eine Orientierungshilfe bei mehreren Fehlern. Bei längeren Formularen gehört an den Anfang eine Fehlerübersicht, die alle Probleme auflistet und idealerweise direkt zu den betroffenen Feldern verlinkt. Alternativ oder ergänzend sollte der Fokus nach dem Absenden auf das erste fehlerhafte Feld springen. So muss niemand das ganze Formular absuchen, um den Fehler zu finden.
Der richtige Zeitpunkt der Validierung
Auch das Wann der Fehlerprüfung will durchdacht sein. Eine Validierung, die schon beim ersten getippten Zeichen meckert, ist für alle nervig und für Screenreader-Nutzer durch die ständigen Ansagen regelrecht störend. Sinnvoller ist es, ein Feld zu prüfen, wenn der Nutzer es verlässt, und die vollständige Prüfung beim Absenden durchzuführen. Wichtig ist, dass auch positive Rückmeldungen – die erfolgreiche Absendung – angekündigt werden, damit niemand im Unklaren bleibt, ob das Formular durchging.
Die häufigsten Formular-Fehler aus der Praxis
In meinen Audits tauchen diese Mängel mit ermüdender Regelmäßigkeit auf: Platzhalter statt echter Labels, Pflichtfelder, die nur farblich markiert sind, Fehlermeldungen, die für Screenreader unsichtbar bleiben, weil sie nicht angekündigt werden, Captcha-Rätsel, die kognitiv eingeschränkte Nutzer aussperren, und Custom-Dropdowns oder Datepicker, die sich nicht mit der Tastatur bedienen lassen. Jeder einzelne dieser Fehler kann ein Formular für eine ganze Nutzergruppe unbenutzbar machen – und damit eine Conversion verhindern.
Warum Formulare besonders wartungsbedürftig sind
Hier kommt der Punkt, der barrierefreie Formulare von vielen anderen Accessibility-Themen unterscheidet: Formulare sind selten statisch. Sie werden per JavaScript validiert, durch A/B-Tests verändert, mit neuen Feldern erweitert, über Plugin-Updates angepasst. Ein Formular, das heute barrierefrei ist, kann nach dem nächsten Deployment kaputt sein – eine geänderte Validierungslogik, ein neues Feld ohne Label, eine überschriebene Fehlerausgabe. Das passiert oft unbemerkt, weil niemand nach jedem Release alle Formulare manuell mit dem Screenreader durchtestet.
Genau für dieses Problem gibt es unser Monitoring Access Guard. Es prüft Ihre Seiten automatisch nach jedem CMS-Update und jedem Code-Deployment, erkennt neu eingeführte Barrieren – etwa ein Formularfeld, dem plötzlich das Label fehlt – in Echtzeit und meldet sie direkt in Ihre bestehenden Werkzeuge wie Jira, Slack oder Teams. Dazu liefert es fertige Code-Hinweise zur Behebung, sodass Ihre Entwickler keine tiefen WCAG-Kenntnisse brauchen. So bleibt ein einmal barrierefrei gebautes Formular auch über Releases hinweg barrierefrei. Wie Sie speziell auf der WordPress-Plattform mit Formular-Plugins umgehen, lesen Sie in WordPress barrierefrei machen: Plugins, Themes und die echten Stolperfallen.
