Barrierefreie Formulare

Im Formular wird aus einem Besucher ein Kunde, eine Abonnentin oder ein Patient. Hier verlieren viele Websites aber auch unbemerkt Menschen. Ein Feld, das nur so lange sagt, was es erwartet, bis man zu tippen beginnt, ein Fehler, der nur als roter Rahmen erscheint, ein Rätsel, das man nicht lösen kann: Jedes davon kann dazu führen, dass jemand aufgibt. Dieser Artikel zeigt, was ein Formular für alle leicht macht, auch für Menschen mit Screenreader (einer Software, die den Bildschirm vorliest), für Menschen, die nur die Tastatur nutzen, und für Menschen, denen Lesen oder Merken schwerfällt. Sie erhalten kurze Codebeispiele vorher und nachher für Ihre Entwicklerin, Ihren Entwickler oder Ihren KI-Baukasten, dazu Checklisten für ein Kontaktformular, einen Bestellprozess und eine Registrierung.

Warum Formulare so oft scheitern

Formulare gehören zu den häufigsten Problemstellen im Web. Im WebAIM Million 2026, einer automatischen Prüfung von einer Million Startseiten, hatten 51 % der Seiten Formularfelder ohne Beschriftung. Und das ist nur, was eine Maschine auf einer Startseite findet. Bestell- und Registrierungsschritte, bei denen mehr auf dem Spiel steht, haben oft noch mehr Probleme.

Die meisten europäischen Barrierefreiheitsregeln, in Deutschland etwa das BFSG und die BITV 2.0, stützen sich direkt oder über die europäische Norm EN 301 549 auf die WCAG, die Web Content Accessibility Guidelines des W3C. Mehrere dieser Anforderungen betreffen Formulare: Felder brauchen Beschriftungen oder Anweisungen, Fehler müssen in Textform benannt werden, und es sollen Vorschläge zur Korrektur folgen. Das Formular-Tutorial des W3C geht ausführlich darauf ein. Hier die praktische Fassung.

Jedes Feld hat eine sichtbare Beschriftung

Eine Beschriftung (im Code „Label“) ist der Text, der sagt, wofür ein Feld da ist: „E-Mail-Adresse“, „Postleitzahl“, „Nachricht“. Sie sollte immer sichtbar sein, direkt beim Feld stehen und im Code mit ihm verbunden sein, damit ein Screenreader sie ansagt, sobald jemand ins Feld kommt. Eine verbundene Beschriftung hat einen Zusatznutzen: Ein Klick darauf setzt den Cursor ins Feld, wodurch kleine Kontrollkästchen viel leichter zu treffen sind.

Der häufigste Fehler ist, den Platzhalter (den grauen Hinweistext im Feld) als einzige Beschriftung zu verwenden. Er verschwindet, sobald man tippt, sodass man nicht mehr nachsehen kann, was gefragt war. Er ist oft zu blass zum Lesen, und manche Screenreader sagen ihn nicht an. Die Nielsen Norman Group fasst diese Probleme in ihrem Artikel über schädliche Platzhalter zusammen.

<!-- Vorher: Der Hinweis verschwindet beim Tippen, und nichts benennt das Feld -->
<input type="email" placeholder="E-Mail-Adresse" />

<!-- Nachher: eine sichtbare Beschriftung, über for und id mit dem Feld verbunden -->
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email" />

Wenn Sie ein Beispiel für das erwartete Format geben möchten, setzen Sie es in einen kurzen Hilfetext unter der Beschriftung („Zum Beispiel: 10115 Berlin“), nicht nur in den Platzhalter. Unsere Anleitung zu Beschriftungen zeigt die Lösung Schritt für Schritt.

Zusammengehörige Auswahlmöglichkeiten gruppieren

Optionsfelder (runde Knöpfe, mit denen man genau eine Option wählt) und Gruppen von Kontrollkästchen brauchen zwei Arten von Beschriftung: eine für jede Option und eine für die Frage insgesamt. Ohne die Frage hört jemand mit Screenreader vielleicht nur „Ja, Optionsfeld, 1 von 2“ und weiß nicht, wozu er Ja sagt.

Im Code ist die Gruppe ein fieldset und die Frage dessen legend:

<!-- Vorher: Die Frage ist einfacher Text, nicht mit den Optionen verbunden -->
<p>Wie dürfen wir Sie kontaktieren?</p>
<input type="radio" id="k-mail" name="kontakt" /> <label for="k-mail">E-Mail</label>
<input type="radio" id="k-tel" name="kontakt" /> <label for="k-tel">Telefon</label>

<!-- Nachher: Die Optionen sind gruppiert, und die Frage benennt die Gruppe -->
<fieldset>
  <legend>Wie dürfen wir Sie kontaktieren?</legend>
  <input type="radio" id="k-mail" name="kontakt" /> <label for="k-mail">E-Mail</label>
  <input type="radio" id="k-tel" name="kontakt" /> <label for="k-tel">Telefon</label>
</fieldset>

Dasselbe gilt für ein Datum in getrennten Feldern für Tag, Monat und Jahr oder für einen Block mit Adressfeldern.

Pflichtfelder und Anweisungen

Sagen Sie vorab, welche Felder ausgefüllt werden müssen. Zwei Wege funktionieren gut:

Schreiben Sie „(Pflichtfeld)“ in die Beschriftung jedes Pflichtfelds. Das ist am klarsten.
Oder verwenden Sie ein Sternchen (_) und erklären Sie es einmal oben im Formular: „Mit _ markierte Felder sind Pflichtfelder.“

Verlassen Sie sich nicht allein auf Farbe, etwa rote Beschriftungen für Pflichtfelder: Wer Farben schlecht unterscheidet, übersieht das. Ergänzen Sie im Code das Attribut required, damit auch Screenreader „erforderlich“ ansagen.

Halten Sie Anweisungen kurz und setzen Sie sie vor das Feld, um das es geht, nicht hinter die Absende-Schaltfläche. Eine Passwortregel wie „Mindestens 12 Zeichen“ gehört unter die Beschriftung des Passworts, wo man sie vor dem Tippen sieht.

Fragen Sie nur ab, was Sie wirklich brauchen. Jedes zusätzliche Feld ist eine weitere Gelegenheit zum Abbruch. Und lassen Sie Menschen innerhalb eines Vorgangs nicht zweimal dasselbe eingeben: Mit WCAG 2.2 kam die Anforderung Redundant Entry (redundante Eingabe) hinzu, nach der bereits gemachte Angaben automatisch ausgefüllt oder zur Auswahl angeboten werden sollen. Das Kästchen „Rechnungsadresse entspricht der Lieferadresse“ ist das klassische Beispiel.

Fehlermeldungen, die beim Korrigieren helfen

Alle machen Fehler beim Ausfüllen. Entscheidend ist, wie schnell man sie beheben kann. Eine gute Fehlermeldung:

Steht als Text da, nicht nur als roter Rahmen oder Symbol. Wer bestimmte Farben nicht unterscheiden kann, übersieht einen roten Rahmen leicht, und Screenreader sagen Farben überhaupt nicht an.
Steht neben dem Feld, um das es geht, damit man sie findet, und ist im Code mit ihm verbunden, damit sie vorgelesen wird, wenn man zum Feld zurückkehrt.
Sagt, wie man den Fehler behebt, nicht nur, dass es einen gibt. „Geben Sie eine E-Mail-Adresse im Format name@beispiel.de ein“ hilft; „Ungültige Eingabe“ nicht.
Behält, was schon eingegeben wurde. Ein komplett geleertes Formular nach einem einzigen Fehler ist ein Grund zu gehen.

Ergänzen Sie bei langen Formularen nach dem Absenden oben eine kurze Zusammenfassung, die jeden Fehler als Link zum jeweiligen Feld auflistet, und setzen Sie den Tastaturfokus (die Stelle, an der Eingaben landen) auf diese Zusammenfassung. Das GOV.UK Design System der britischen Regierung zeigt eine gut erprobte Fassung dieses Musters.

<!-- Vorher: nur ein roter Rahmen, nichts, was ein Screenreader ansagen kann -->
<input type="email" id="email" class="roter-rahmen" />

<!-- Nachher: eine Meldung als Text, mit dem Feld verbunden -->
<label for="email">E-Mail-Adresse</label>
<p id="email-fehler" class="fehler">Geben Sie eine E-Mail-Adresse im Format name@beispiel.de ein</p>
<input
  type="email"
  id="email"
  name="email"
  autocomplete="email"
  aria-invalid="true"
  aria-describedby="email-fehler"
/>

aria-describedby verbindet die Meldung mit dem Feld, und aria-invalid teilt assistiven Technologien mit, dass das Feld Aufmerksamkeit braucht.

Lassen Sie den Browser Bekanntes ausfüllen

Browser und Passwortmanager können Name, Adresse, E-Mail und Telefonnummer automatisch ausfüllen, wenn das Formular angibt, was jedes Feld ist. Das spart allen Tipparbeit und macht einen großen Unterschied für Menschen mit motorischen Einschränkungen, Gedächtnisproblemen oder Legasthenie. Die WCAG nennen das Identify Input Purpose, also den Zweck der Eingabe erkennbar machen.

Das Attribut autocomplete erledigt das. Häufige Werte:

name, oder given-name und family-name für getrennte Felder für Vor- und Nachname
email und tel
street-address, postal-code, address-level2 (der Ort) und country-name
organization für einen Firmennamen
new-password bei der Registrierung und current-password bei der Anmeldung
one-time-code für einen Code per SMS

Nutzen Sie auch den passenden Feldtyp: type="email" und type="tel" zeigen auf dem Smartphone die richtige Tastatur.

Schaltflächen, Tastatur und Sicherheitsabfragen

Schaltflächen, die sagen, was sie tun

Die Absende-Schaltfläche sollte eine echte Schaltfläche mit klarem Text sein: „Nachricht senden“, „Zahlungspflichtig bestellen“, „Konto erstellen“. Nicht bloß „Absenden“ und nie ein Pfeilsymbol ohne Namen. Zeigt eine Schaltfläche nur ein Symbol, braucht sie einen unsichtbaren Namen, den ein Screenreader ansagen kann.

<!-- Vorher: eine anklickbare Fläche mit Symbol, ohne Namen und ohne Tastaturzugang -->
<div class="senden" onclick="senden()"><svg>...</svg></div>

<!-- Nachher: eine echte Schaltfläche mit Namen -->
<button type="submit">Nachricht senden</button>

Unsere Anleitung zu Namen von Schaltflächen behandelt auch Schaltflächen mit Symbolen.

Alles funktioniert mit der Tastatur

Wer nur die Tastatur nutzt, muss jedes Feld mit der Tabulatortaste erreichen, Optionen mit den Pfeiltasten oder der Leertaste wählen, eigene Auswahllisten öffnen und mit der Eingabetaste absenden können. Achten Sie auf Datumsauswahlen, selbstgebaute Auswahllisten und Flächen zum Hineinziehen von Dateien: Sie funktionieren oft nur mit der Maus. Unser 10-Minuten-Tastaturtest zeigt, wie Sie das selbst prüfen.

CAPTCHAs und Alternativen

Ein CAPTCHA ist ein Test, der beweisen soll, dass Sie kein Roboter sind: verzerrte Buchstaben abtippen oder Fotos anklicken. Für viele Menschen ist das eine Mauer. Das W3C beschreibt die Probleme in seiner Notiz zur Unzugänglichkeit von CAPTCHAs. Mit WCAG 2.2 kam außerdem Accessible Authentication (barrierefreie Authentifizierung) hinzu: Die Anmeldung darf nicht davon abhängen, sich etwas zu merken oder abzutippen, es sei denn, es gibt Hilfe, etwa indem Passwortmanager und Einfügen erlaubt sind.

Sanftere Wege gegen Spam sind unsichtbare Prüfungen im Hintergrund, ein verstecktes Feld, das nur Roboter ausfüllen, und eine Begrenzung, wie viele Nachrichten ein Besucher senden kann. Wenn ein sichtbarer Test unvermeidlich ist, bieten Sie mehr als eine Art an, etwa eine Audiofassung neben der visuellen. Und blockieren Sie nie das Einfügen in Passwort- oder Codefelder.

Zeitlimits

Läuft ein Formular ab, können Menschen, die langsam lesen oder tippen, ihre Eingaben verlieren. Die WCAG-Anforderung Timing Adjustable (Zeiteinteilung anpassbar) verlangt, dass man ein Zeitlimit abschalten oder verlängern kann. Üblich ist ein Hinweis vor Ablauf der Zeit, mit mindestens 20 Sekunden, um mit einer einfachen Handlung zu verlängern. Ticketverkäufe und Auktionen können Ausnahmen sein.

Bestätigung

Zeigen Sie nach dem Absenden eine klare Meldung auf dem Bildschirm, und sorgen Sie dafür, dass Screenreader sie ebenfalls ansagen, etwa indem der Fokus dorthin wandert. Bei Bestellungen, Buchungen und allem mit rechtlichen oder finanziellen Folgen sollten Menschen ihre Angaben vor dem letzten Schritt überprüfen können. Sagen Sie, was als Nächstes passiert: „Vielen Dank. Wir haben eine Bestätigung an name@beispiel.de geschickt.“

Checklisten für häufige Formulare

Kontaktformular

Jedes Feld hat eine sichtbare Beschriftung, die beim Tippen stehen bleibt.
Pflichtfelder sind im Text gekennzeichnet, nicht nur durch Farbe.
Felder für Name, E-Mail und Telefon haben den passenden autocomplete-Wert.
Fehler erscheinen als Text neben dem Feld und erklären die Lösung.
Auf der Schaltfläche steht „Nachricht senden“ oder etwas Ähnliches.
Ein eventueller Spamschutz kommt ohne visuelles Rätsel aus.
Nach dem Absenden erscheint eine Bestätigung, die auch angesagt wird.

Bestellprozess

Die Adressfelder nutzen autocomplete, und „Wie Lieferadresse“ erspart das erneute Tippen.
Liefer- und Zahlungsoptionen sind unter einer klaren Frage gruppiert.
Fehler in Karten- oder Adressfeldern werden in Worten erklärt.
Man kann die Bestellung vor dem Bezahlen überprüfen.
Auf der letzten Schaltfläche steht „Zahlungspflichtig bestellen“ oder „Jetzt kaufen“, nicht „Weiter“.
Ein eventuelles Zeitlimit lässt sich verlängern.
Die Bestätigungsseite sagt, was bestellt wurde und wie es weitergeht.

Registrierung und Anmeldung

Felder für E-Mail und Passwort haben sichtbare Beschriftungen und passende autocomplete-Werte.
Passwortregeln stehen vor dem Tippen da.
Einfügen und Passwortmanager funktionieren.
Codes per SMS oder E-Mail lassen sich einfügen.
Eine Schaltfläche zum Anzeigen des Passworts ist eine echte Schaltfläche mit Namen.
Fehlermeldungen sagen, was falsch ist, ohne zu verraten, welche Konten existieren.

Was ibin in Ihren Formularen prüfen kann und was nicht

Eine automatische Prüfung findet Felder ohne Beschriftung, Schaltflächen ohne Namen und Text mit zu wenig Kontrast. ibin zeigt jedes Problem mit einem vergrößerten Ausschnitt der Stelle und einer Anleitung, und die Schaltfläche „Anleitung für ein KI-Tool kopieren“ liefert Ihnen eine fertige Anweisung für Lovable, Bolt, v0 und ähnliche Werkzeuge. Automatische Prüfungen finden allerdings nur ungefähr ein Drittel bis die Hälfte aller Barrierefreiheitsprobleme. Ob eine Fehlermeldung hilft, ob die Schritte logisch sind oder ob ein CAPTCHA Menschen aussperrt, muss ein Mensch beurteilen. Füllen Sie Ihr eigenes Formular nur mit der Tastatur aus, machen Sie absichtlich einen Fehler und sehen Sie, was passiert.

Prüfen Sie Ihre Formulare

Prüfen Sie Ihre Kontakt- oder Bestellseite kostenlos mit ibin, um fehlende Beschriftungen und Schaltflächen ohne Namen zu finden. Gehen Sie danach die Checklisten oben und die Anleitungen durch. Wenn Sie sich anmelden, können Sie bis zu 200 Seiten derselben Website prüfen, und wöchentliche Prüfungen melden Ihnen, wenn eine Änderung an einem Formular etwas kaputt macht.

Sehen Sie, wie Ihre Website abschneidet

Prüfen Sie kostenlos eine Seite, ohne Konto. Sie erhalten eine klare Liste, was zuerst zu beheben ist, mit Bildern, wo jedes Problem liegt.

Barrierefreie Formulare: Beschriftungen, Fehlermeldungen und Schaltflächen, die für alle funktionieren