Formulare sind die Nadelöhre jeder Website. Durch sie läuft alles, was zählt: die Anmeldung, der Kauf, die Kontaktaufnahme, der Antrag. Und genau hier scheitert Barrierefreiheit am häufigsten – mit unmittelbaren Folgen, denn jeder Nutzer, der ein Formular nicht ausfüllen kann, ist nicht nur ausgeschlossen, sondern ein verlorener Kunde. Barrierefreie Formulare sind deshalb keine technische Kür, sondern eine der wirtschaftlich wichtigsten Stellen Ihrer gesamten digitalen Präsenz. In diesem Leitfaden gehe ich die Anatomie eines zugänglichen Formulars Schritt für Schritt durch – von Labels über Fehlermeldungen bis zu den kniffligen Fällen wie CAPTCHA und mehrstufigen Prozessen. Mit Code, mit Praxisbeispielen und mit der ehrlichen Einordnung, wo ein automatischer Test an seine Grenzen kommt.

Was macht ein Formular barrierefrei?

Ein Formular ist barrierefrei, wenn jeder Mensch es wahrnehmen, verstehen, ausfüllen und absenden kann – unabhängig davon, ob er sieht, eine Maus benutzt oder einen Screenreader einsetzt. Das klingt selbstverständlich, ist es aber selten. Ein blinder Nutzer muss per Screenreader hören, was in jedes Feld gehört. Ein Tastaturnutzer muss jedes Feld und jede Schaltfläche ohne Maus erreichen. Und ein Mensch mit kognitiven Einschränkungen muss klar erkennen, was verlangt wird und was bei einem Fehler zu tun ist. Hinzu kommt eine zeitliche Dimension: Wer auf eine Spracheingabe oder eine alternative Bedienung angewiesen ist, braucht oft länger – ein Formular, das nach kurzer Inaktivität die Sitzung verwirft und alle Eingaben löscht, schließt genau diese Menschen aus.

Die gute Nachricht: Barrierefreie Formulare beruhen größtenteils auf wenigen, gut etablierten Techniken, die kein Hexenwerk sind. Die schlechte Nachricht: Schon ein einziger Fehler – ein fehlendes Label, eine unverständliche Fehlermeldung – kann den gesamten Prozess für betroffene Nutzer blockieren. Bei Formularen gibt es kein „fast zugänglich“; entweder jemand kommt durch, oder er bricht ab. Gehen wir die entscheidenden Bausteine der Reihe nach durch.

Labels: das Fundament für barrierefreie Formulare

Das Label ist der wichtigste Baustein überhaupt. Es sagt dem Nutzer – und dem Screenreader –, was in ein Feld gehört. Entscheidend ist, dass das Label nicht nur sichtbar danebensteht, sondern programmatisch mit dem Feld verknüpft ist. Technisch geschieht das über das for-Attribut des Labels, das auf die id des Eingabefelds verweist:

<label for=“email“>E-Mail-Adresse</label>
<input id=“email“ type=“email“ name=“email“>

Mit dieser Verknüpfung liest der Screenreader beim Erreichen des Feldes automatisch „E-Mail-Adresse, Eingabefeld“ vor, und ein Klick auf das Label setzt den Fokus ins Feld – was nebenbei die Trefferfläche für alle vergrößert. Der häufigste Fehler ist, das sichtbare Label durch einen Platzhaltertext im Feld zu ersetzen. Platzhalter verschwinden, sobald man zu tippen beginnt, sind oft zu kontrastarm und werden von Screenreadern unzuverlässig behandelt. Sie sind ein netter Zusatz, niemals ein Ersatz fürs Label. Erst wenn ein sichtbares Label aus gestalterischen Gründen wirklich unmöglich ist, kommt aria-label als Notlösung in Betracht – aber das ist die Ausnahme, nicht die Regel. Die saubere Label-Verknüpfung erfüllt gleich mehrere Erfolgskriterien: 3.3.2 (Beschriftungen oder Anweisungen), 1.3.1 (die Verknüpfung von Feld und Beschriftung im Code) und 4.1.2 (Name, Rolle, Wert). Ein verwandter, oft übersehener Punkt ist 2.5.3 (Beschriftung im Namen): Wenn ein Button sichtbar „Absenden“ heißt, muss genau dieses Wort auch im barrierefreien Namen stecken – sonst läuft die Sprachsteuerung ins Leere, weil der gesprochene Befehl „Klicke Absenden“ nichts findet, falls per aria-label intern ein abweichender Text hinterlegt wurde.

Aus der Praxis: Ein Newsletter-Formular bestand aus einem einzigen Feld mit dem Platzhalter „E-Mail-Adresse eingeben“ – ohne sichtbares Label. Sobald ein Nutzer zu tippen begann, verschwand der Hinweis; wer kurz abgelenkt war, wusste nicht mehr, worum es ging. Für den Screenreader war das Feld schlicht „Eingabefeld, leer“. Ein einziges <label> löste das Problem – und die Anmelderate stieg sogar, weil nun auch sehende Nutzer das Feld zuverlässig zuordnen konnten.

Pflichtfelder und Hilfetexte richtig kennzeichnen

Nutzer müssen vorab wissen, welche Felder Pflicht sind und welche Anforderungen gelten – nicht erst, nachdem sie auf „Absenden“ geklickt und einen Fehler kassiert haben. Pflichtfelder kennzeichnen Sie sowohl visuell als auch programmatisch. Das Attribut required teilt es assistiven Technologien mit; ein Sternchen oder das Wort „Pflichtfeld“ macht es sichtbar (Kriterium 3.3.2 verlangt genau diese vorab erkennbare Kennzeichnung). Wichtig: Erklären Sie die Bedeutung des Sternchens einmal am Formularanfang.

Hilfetexte und Format-Hinweise – etwa „Mindestens 8 Zeichen“ – sollten vor der Eingabe sichtbar sein und programmatisch mit dem Feld verknüpft werden, damit der Screenreader sie mit vorliest. Das leistet das Attribut aria-describedby, das auf die id des Hinweistexts zeigt:

<label for=“pw“>Passwort <span aria-hidden=“true“>*</span></label>
<input id=“pw“ type=“password“ required aria-describedby=“pw-hint“>
<p id=“pw-hint“>Mindestens 8 Zeichen, mindestens eine Ziffer.</p>

So hört ein blinder Nutzer beim Betreten des Feldes nicht nur „Passwort, Pflichtfeld“, sondern gleich auch die Anforderung. Das verhindert Fehler, bevor sie entstehen – die mit Abstand angenehmste Form der Fehlerbehandlung.

Fehlermeldungen: der häufigste Stolperstein

Wenn ich Formulare prüfe, ist die Fehlerbehandlung die Stelle, an der die meisten durchfallen. Eine zugängliche Fehlermeldung erfüllt drei Bedingungen: Sie steht in klarem Text, sie benennt das konkrete Feld und sagt, wie der Fehler zu beheben ist, und sie wird dem Screenreader aktiv angekündigt. Dahinter stehen zwei Erfolgskriterien: 3.3.1 verlangt, dass ein Fehler überhaupt in Textform benannt wird, 3.3.3, dass die Meldung einen konkreten Korrekturvorschlag macht. Ein rot umrandetes Feld ohne Text genügt keiner dieser Bedingungen – und verletzt zugleich 1.4.1, weil die Information allein über die Farbe transportiert wird. Für einen blinden Nutzer existiert der Fehler dann schlicht nicht.

Technisch verknüpfen Sie die Fehlermeldung wie einen Hilfetext über aria-describedby mit dem Feld und markieren das Feld mit aria-invalid. Damit der Screenreader die Meldung sofort vorliest, statt dass der Nutzer sie selbst suchen muss, hilft role=“alert“:

<input id=“email“ aria-invalid=“true“ aria-describedby=“email-err“>
<p id=“email-err“ role=“alert“>
  Bitte geben Sie eine gültige E-Mail-Adresse ein, z. B. name@firma.de.
</p>

Ebenso wichtig ist das Fokus-Management: Nach dem Absenden mit Fehlern sollte der Fokus zur ersten fehlerhaften Stelle springen oder zu einer Zusammenfassung am Formularanfang, die alle Fehler auflistet. Sonst landet ein Tastaturnutzer wieder ganz oben und muss raten, was schiefging. Und ein letzter Punkt aus leidvoller Audit-Erfahrung: Validieren Sie nicht bei jedem Tastenanschlag. Eine Fehlermeldung, die aufpoppt, während man die E-Mail noch tippt, verwirrt mehr, als sie hilft – prüfen Sie, wenn der Nutzer das Feld verlässt oder das Formular absendet. Bei längeren Formularen bewährt sich zusätzlich eine Fehlerübersicht am Seitenanfang, die alle Probleme bündelt und per Sprungmarke direkt zum jeweiligen Feld führt – so behält auch jemand den Überblick, der nicht das gesamte Formular auf einen Blick erfassen kann.

Ein technisches Detail, das in der Praxis ständig schiefgeht: Ein Feld darf in aria-describedby mehrere IDs gleichzeitig referenzieren, durch Leerzeichen getrennt – etwa den Hilfetext und die Fehlermeldung: aria-describedby=“pw-hint pw-err“. Viele Entwickler ersetzen im Fehlerfall die Hinweis-ID durch die Fehler-ID und löschen damit den Hilfetext, statt ihn zu ergänzen. Der Screenreader liest dann zwar den Fehler vor, aber die ursprüngliche Format-Anforderung ist verschwunden. Stehen beide IDs nebeneinander, hört der Nutzer Anforderung und Korrektur in einem Durchgang – und weiß sofort, was zu tun ist.

Aus der Praxis: Ein Anmeldeformular markierte fehlerhafte Felder ausschließlich durch einen roten Rahmen – kein Text, keine Ansage. Ein blinder Tester füllte das Formular dreimal aus, drückte dreimal „Absenden“ und bekam dreimal dieselbe stumme Ablehnung, ohne je zu erfahren, dass sein Passwort eine Ziffer brauchte. Nachdem wir Textmeldungen mit role=“alert“ und Fokussteuerung ergänzt hatten, war das Formular beim ersten Versuch ausfüllbar. Eine einzige fehlende Meldung hatte den gesamten Zugang blockiert.

Zusammengehörige Felder sinnvoll gruppieren

Manche Felder gehören zusammen und ergeben einzeln keinen Sinn – eine Gruppe von Auswahlknöpfen für die Anrede etwa, oder die Felder eines Adressblocks. Für solche Gruppen gibt es fieldset und legend – das technische Mittel, mit dem Kriterium 1.3.1 die Zusammengehörigkeit auch im Code abbildet. Das fieldset klammert die zusammengehörigen Felder, die legend gibt der Gruppe eine gemeinsame Überschrift, die der Screenreader bei jedem Element der Gruppe mit vorliest:

<fieldset>
  <legend>Wie möchten Sie kontaktiert werden?</legend>
  <input type=“radio“ id=“mail“ name=“kontakt“> <label for=“mail“>E-Mail</label>
  <input type=“radio“ id=“tel“ name=“kontakt“> <label for=“tel“>Telefon</label>
</fieldset>

Ohne diese Gruppierung hört ein blinder Nutzer nur „E-Mail, Auswahlknopf“ und „Telefon, Auswahlknopf“, ohne zu wissen, worauf sich die Auswahl bezieht. Mit der legend wird daraus „Wie möchten Sie kontaktiert werden? E-Mail, Auswahlknopf“ – die Frage und die Antwort gehören wieder zusammen. Gerade bei Radio-Buttons und Checkbox-Gruppen ist das unverzichtbar – und es gehört zu den Punkten, die in der Hektik des Formularbaus am leichtesten untergehen.

Tastatur, Autovervollständigung und Eingabehilfen

Ein zugängliches Formular muss vollständig per Tastatur bedienbar sein (Kriterium 2.1.1): jedes Feld per Tab erreichbar, jede Auswahl mit den Pfeiltasten bedienbar, der Absenden-Button per Enter auslösbar. Achten Sie besonders auf selbstgebaute Auswahlfelder und Datumswähler – native HTML-Elemente bringen die Tastaturbedienung von Haus aus mit, nachgebaute Varianten oft nicht.

Ein unterschätzter Helfer ist das autocomplete-Attribut (Kriterium 1.3.5). Es erlaubt Browsern und Passwortmanagern, Felder automatisch auszufüllen – eine enorme Erleichterung für Menschen mit motorischen oder kognitiven Einschränkungen, die nicht jedes Mal Name, Adresse und Telefonnummer neu eintippen wollen. Wichtig dabei: 1.3.5 verlangt den korrekten Token. Schreiben Sie also autocomplete=“email“, „given-name“ oder „postal-code“ statt eines bloßen autocomplete=“on“ – erst der spezifische Token sagt der assistiven Technologie, welche Art von Eingabe ein Feld erwartet. Setzen Sie außerdem die richtigen Eingabetypen: Ein type=“email“ oder type=“tel“ blendet auf dem Smartphone die passende Tastatur ein und reduziert Tippfehler. Mit WCAG 2.2 ist das Vermeiden redundanter Eingaben sogar ein eigenes Erfolgskriterium geworden (3.3.7) – bereits erfasste Daten sollen Sie nicht ein zweites Mal abfragen, etwa über eine Option „Rechnungsadresse entspricht Lieferadresse“. Achten Sie zusätzlich auf die Fokusreihenfolge: Der Tabulator sollte die Felder in der logischen, sichtbaren Reihenfolge durchlaufen. Spätestens wenn ein zweispaltiges Layout die Tab-Reihenfolge durcheinanderbringt und erst alle linken, dann alle rechten Felder ansteuert, wird das Ausfüllen für Tastaturnutzer zur Geduldsprobe. Die Reihenfolge im Code muss der Logik des Formulars folgen, nicht der optischen Anordnung im Raster.

Die schwierigen Fälle: CAPTCHA, mehrstufige Formulare und Datumseingaben

Drei Konstellationen bereiten in der Praxis besondere Mühe. Die erste ist das CAPTCHA. Klassische Bilderrätsel oder verzerrte Buchstaben sind für blinde Menschen oft unlösbar und verletzen seit WCAG 2.2 das Kriterium der zugänglichen Authentifizierung (3.3.8), wenn keine zugängliche Alternative existiert. Setzen Sie auf modernere Verfahren, die ohne kognitiven Funktionstest auskommen: ein unsichtbares Honeypot-Feld, das nur Bots ausfüllen, eine token-basierte Prüfung im Hintergrund oder eine Bestätigung per E-Mail-Link. Wenn Sie auf ein klassisches CAPTCHA nicht verzichten können, bieten Sie immer eine gleichwertige Alternative an – etwa eine Audio-Variante mit der Möglichkeit, sie neu abzuspielen.

Die zweite ist das mehrstufige Formular. Hier braucht der Nutzer Orientierung: Eine klare Fortschrittsanzeige muss vermitteln, in welchem Schritt er sich befindet und wie viele noch folgen, und sie muss auch für Screenreader verständlich sein. Die dritte sind Datums- und Formateingaben. Zwingen Sie Nutzer nicht in ein einziges starres Format, sondern akzeptieren Sie verschiedene Schreibweisen oder erklären Sie das erwartete Format klar vorab. Jede unnötige Formatregel ist eine zusätzliche Fehlerquelle. Bei Formularen mit rechtlichen oder finanziellen Folgen – Buchungen, Bestellungen, Vertragsabschlüsse – greift zudem Kriterium 3.3.4: Die Eingabe muss entweder umkehrbar, vor dem endgültigen Absenden überprüfbar oder durch einen bestätigenden Zwischenschritt abgesichert sein, damit ein versehentlicher Klick keinen folgenschweren Fehler auslöst.

Ein vierter Fall sind Felder, die je nach vorheriger Antwort ein- oder ausgeblendet werden. Solche dynamischen Änderungen müssen angekündigt werden, damit ein Screenreader-Nutzer überhaupt bemerkt, dass plötzlich ein neues Pflichtfeld erschienen ist – sonst sendet er ein vermeintlich vollständiges Formular ab und scheitert an etwas, das er nie wahrgenommen hat.

Aus der Praxis: Ein Buchungsformular verlangte das Reisedatum im Format TT.MM.JJJJ – ohne Hinweis, und jede Abweichung führte kommentarlos zur Ablehnung. Nutzer, die „3. Mai“ oder „03/05″ eingaben, scheiterten reihenweise, gerade ältere Kunden. Wir ergänzten einen sichtbaren Formathinweis und einen barrierefreien Datumswähler als Alternative. Die Abbruchquote an diesem Schritt halbierte sich nahezu. Barrierefreie Formulare zahlen sich hier unmittelbar in barer Münze aus.

Warum barrierefreie Formulare die Conversion steigern

Es lohnt sich, den wirtschaftlichen Kern noch einmal klar auszusprechen, denn er wird oft übersehen: Barrierefreie Formulare nützen nicht nur Menschen mit Behinderung – sie verbessern die Abschlussquote für alle. Jede einzelne Maßnahme, die ich beschrieben habe, hilft auch Nutzern ohne Einschränkung. Größere Trefferflächen und klickbare Labels erleichtern die Bedienung am Smartphone. Automatisches Ausfüllen spart jedem Zeit. Verständliche Fehlermeldungen, die sagen, was zu tun ist, verhindern Frust und Abbrüche quer durch alle Zielgruppen. Vorab sichtbare Format-Hinweise reduzieren Fehler, bevor sie entstehen.

Das ist die eigentliche Pointe: Ein zugängliches Formular ist fast immer auch ein besseres Formular. Was den blinden Nutzer durchkommen lässt, lässt auch den gestressten Kunden durchkommen, der auf dem Handy in der U-Bahn einen Kauf abschließen will. Wer barrierefreie Formulare baut, optimiert deshalb nicht für eine Minderheit, sondern für die Conversion insgesamt – die Zugänglichkeit ist gewissermaßen der willkommene Nebeneffekt einer durchdachten Nutzerführung.

Warum ein automatischer Test Formulare nur halb prüft

Ein automatischer Scanner kann viel über ein Formular sagen: ob ein Label existiert, ob ein Feld eine id hat, ob ein fieldset gesetzt ist. Was er nicht beurteilen kann, ist das Entscheidende: ob die Fehlermeldung verständlich formuliert ist, ob der Fokus nach einem Fehler sinnvoll springt, ob der Screenreader die Meldung im richtigen Moment ansagt, ob die Reihenfolge der Felder logisch ist. All das zeigt sich erst, wenn ein echter Mensch das Formular mit einem Screenreader tatsächlich ausfüllt.

Genau hier setzt unser Anker-Audit Access Ready an. Wir lassen barrierefreie Formulare nicht von einem Skript abhaken, sondern von echten Nutzern assistiver Technologien mit JAWS, NVDA und VoiceOver durchspielen – vom ersten Feld bis zum erfolgreichen Absenden, inklusive aller Fehlerpfade. So sehen Sie nicht, ob ein Label technisch vorhanden ist, sondern ob ein blinder Mensch Ihr Formular wirklich ausfüllen kann. Andere Prüfwege beschränken sich auf das, was eine Maschine sehen kann; Access Ready prüft das, worauf es ankommt – und führt Sie bis zum rechtlich belastbaren Zertifikat. Bei Formularen, wo jeder ausgeschlossene Nutzer direkt Umsatz kostet, ist dieser Unterschied bares Geld wert. Für Sie heißt das konkret: Sie erhalten keinen abstrakten Prüfbericht, sondern die belastbare Aussage, dass Ihre Anmeldung, Ihr Checkout und Ihr Kontaktformular für jeden funktionieren – und mit Access Ready das Zertifikat, das diese Aussage im Zweifel auch rechtlich trägt.

Vom zugänglichen Formular zum belastbaren Nachweis

Barrierefreie Formulare entscheiden über mehr als Compliance – sie entscheiden darüber, ob aus Besuchern Kunden werden. Die Bausteine kennen Sie nun: verknüpfte Labels, klar gekennzeichnete Pflichtfelder, verständliche und angekündigte Fehlermeldungen, sinnvolle Gruppierung, vollständige Tastaturbedienung. Damit haben Sie das Fundament. Was bleibt, ist der Nachweis, dass Ihre Formulare in der echten Nutzung auch wirklich tragen. Denn zwischen einem Formular, das im Code korrekt aussieht, und einem, das ein blinder Mensch in dreißig Sekunden ausfüllt, liegt oft genau die Differenz, die über den Abschluss entscheidet. Barrierefreie Formulare sind damit kein Nice-to-have, sondern eine Investition, die sich unmittelbar an Ihrer Conversion ablesen lässt.

Wenn Sie wissen wollen, wo Ihre Seite heute steht, ist ein kostenloser WCAG-Test Ihrer Website der schnelle Einstieg. Und wenn Sie den belastbaren Beleg brauchen, dass Ihre Formulare den Anforderungen nach BFSG standhalten, führt der Weg über ein zertifiziertes Tiefen-Audit mit echten Nutzern. Ich verspreche Ihnen keine perfekte Seite per Knopfdruck – aber die Gewissheit, dass jeder Mensch Ihre Formulare ausfüllen kann, und das Dokument, mit dem Sie Ihre Sorgfaltspflicht belegen.