Barrierefreie Formulare: was jeder ausfüllen können muss

Ein Formular ist barrierefrei, wenn jeder es ohne Hilfe ausfüllen und absenden kann: mit Screenreader, nur mit der Tastatur, auf dem Handy oder mit einer Lernschwierigkeit. Dafür braucht es wenig. Jedes Feld hat eine sichtbare, technisch verknüpfte Beschriftung, Gruppen haben eine Überschrift, Fehler werden als Text beim Feld gemeldet und sagen, was zu tun ist. Dazu kommen der richtige Feldtyp und autocomplete, die das Tippen erleichtern oder ganz ersparen. Fast alles davon ist Standard-HTML und kostet bei einem Neubau so gut wie nichts.

Die Beschriftung: für und id

Ein Formular besteht aus dem <form>-Element, den Feldern, ihren Beschriftungen und dem Absende-Button. Der entscheidende Punkt ist die Verbindung zwischen Beschriftung und Feld. Das W3C-Tutorial zu Formularen sagt es knapp: Das for-Attribut des <label> muss exakt der id des Feldes entsprechen.

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

Erst diese Verknüpfung macht aus zwei nebeneinanderstehenden Elementen ein Paar, das auch ein Screenreader als zusammengehörig erkennt. Nebenbei wird die Beschriftung klickbar und vergrößert so die Fläche, mit der man das Feld trifft. Man sieht dem Formular den Unterschied nicht an: Ein Feld mit einem Text darüber sieht genauso aus wie ein Feld mit verknüpfter Beschriftung. Hörbar wird er erst mit dem Screenreader.

Die Verknüpfung fällt unter Kriterium 1.3.1 „Info und Beziehungen", Stufe A, das Vorhandensein einer Beschriftung unter 3.3.2 „Beschriftungen oder Anweisungen", ebenfalls Stufe A. Wer statt Standard-Feldern eigene Bedienelemente aus div und span baut, muss Name, Rolle und Zustand selbst liefern (4.1.2, Stufe A). Normale HTML-Felder erfüllen das von selbst, ein Grund mehr, bei ihnen zu bleiben.

Der Platzhalter ist keine Beschriftung

Der häufigste Fehler sieht am aufgeräumtesten aus: kein Label über dem Feld, stattdessen ein grauer Text im Feld selbst. Das W3C-Tutorial nennt drei Probleme:

• Er verschwindet, sobald jemand zu tippen beginnt. Wer nach einer Ablenkung zurückkommt, sieht ein halb ausgefülltes Feld ohne Hinweis, was hineingehörte.
• Er ist zu blass. Die Standarddarstellung der Browser erreicht den Mindestkontrast der WCAG nicht.
• Hilfsmittel behandeln ihn nicht als Beschriftung.

Platzhalter dürfen bleiben, als Beispiel für ein Format. Als Ersatz für die Beschriftung taugen sie nicht.

Der Feldtyp entscheidet über die Handy-Tastatur

Das ist der Punkt mit dem größten Alltagsnutzen und dem geringsten Aufwand. Das type-Attribut steuert, welche Bildschirmtastatur ein mobiler Browser einblendet, und die meisten Typen prüfen die Eingabe gleich mit:

Feld	type	Was der Nutzer bekommt
Telefonnummer	tel	Telefon-Tastenfeld mit Ziffern, Stern und Raute
E-Mail	email	Tastatur mit @, Prüfung des Formats
Website	url	Tastatur mit gut erreichbarem /, Prüfung des Formats
Suche	search	Eingabetaste oft als „Suchen" beschriftet
Menge	number	Zifferntastatur
Datum	date	Datumsauswahl, je nach Browser und System verschieden

Ein Telefonfeld mit type="text" heißt: Der Nutzer bekommt eine Buchstabentastatur, sucht die Umschalttaste für Ziffern und tippt weiter, bei jedem Formular. type="tel" prüft übrigens kein Format, weil Telefonnummern weltweit zu verschieden sind. Das ist richtig so.

Vorsicht bei number: MDN rät, es nur für echte Mengen zu verwenden. Postleitzahlen oder Kartennummern bestehen zwar aus Ziffern, sind aber keine Zahlen. Dafür nimmt man type="text" mit inputmode="numeric".

autocomplete erspart das Tippen ganz

Der Feldtyp sagt, welche Art von Daten erwartet wird. autocomplete sagt, wozu das Feld da ist: given-name für den Vornamen, family-name für den Nachnamen, email, tel, street-address, postal-code. new-password sagt dem Passwortmanager, dass hier ein neues Passwort entsteht, current-password, dass das gespeicherte eingesetzt werden soll.

Kriterium 1.3.5 „Eingabezweck bestimmen", Stufe AA, verlangt genau das für alle Felder, die Angaben über die Person erfassen. Das W3C nennt als Nutznießer Menschen mit Gedächtnis- und Sprachschwierigkeiten, denen der Browser die Angaben einträgt, und Menschen mit motorischen Einschränkungen, die weniger tippen müssen. Für alle anderen sind es gesparte Sekunden pro Feld. Wichtig: Nur die festgelegten Werte zählen. Ein erfundener Wert erfüllt das Kriterium nicht.

Pflichtfelder: required und ein Wort

Ob ein Feld Pflicht ist, ist eine geschäftliche Entscheidung: Braucht die Anfrage wirklich eine Telefonnummer, oder steht das Feld nur da, weil es schon immer da stand?

Ist die Entscheidung getroffen, gehört sie ins HTML. Das required-Attribut verhindert das Absenden, solange das Feld leer ist, und teilt Hilfsmitteln mit, dass es Pflicht ist. MDN empfiehlt es für alle normalen Felder. aria-required="true" meldet dieselbe Information nur an Hilfsmittel und prüft nichts. Es ist für selbstgebaute Bedienelemente gedacht, die keine HTML-Felder sind.

Ein rotes Sternchen oder eine rote Umrandung allein reicht nicht, denn Farbe trägt die Information nicht für jeden. MDN nennt Text oder ein Symbol als übliche Kennzeichnung, etwa „(Pflichtfeld)" in der Beschriftung, oder ein Sternchen mit einer Erklärung über dem Formular.

Gruppieren, was zusammengehört

Bei Radiobuttons ist eine Gruppenbeschriftung notwendig. Drei Optionen ohne übergeordnete Frage sind drei zusammenhanglose Wörter. Das W3C-Tutorial sagt: Radiobutton-Gruppen gehören immer in ein <fieldset>, Checkbox-Gruppen ebenso. <legend> gibt der Gruppe ihre Überschrift.

<fieldset>
  <legend>Wie sollen wir dich erreichen?</legend>
  <input type="radio" id="k-mail" name="kontakt" value="mail">
  <label for="k-mail">Per E-Mail</label>
  <input type="radio" id="k-tel" name="kontakt" value="tel">
  <label for="k-tel">Per Telefon</label>
</fieldset>

Screenreader gehen mit der Legende unterschiedlich um: Je nach Einstellung lesen sie sie bei jedem Feld, einmal oder selten gar nicht vor. Deshalb rät das W3C, die Legende kurz zu halten und die einzelnen Beschriftungen so zu formulieren, dass sie auch ohne Legende verständlich sind. Dasselbe Mittel ordnet lange Formulare: persönliche Angaben in einem Block, Kontaktdaten im nächsten.

Fehlermeldungen, die weiterhelfen

„Fehler" ist keine Meldung. Die Kriterien verlangen drei Dinge:

• Der Fehler steht als Text da (3.3.1, Stufe A). Eine rote Umrandung darf zusätzlich da sein, ersetzt den Text aber nicht.
• Die Meldung sagt, was zu tun ist, wenn eine Korrektur bekannt ist (3.3.3, Stufe AA). „Gib das Datum als TT.MM.JJJJ ein" statt „Ungültige Eingabe". Ist klar, was gemeint war, darf die Meldung es vorschlagen, im Stil von „Meintest du …?".
• Die Meldung ist mit dem Feld verknüpft. Die W3C-Technik ARIA21 setzt aria-invalid="true" auf das Feld und verbindet es über aria-describedby mit dem Meldungstext. Dann liest der Screenreader die Meldung vor, sobald das Feld den Fokus bekommt.

Das W3C-Tutorial empfiehlt außerdem, nach dem Absenden alle Fehler oben über dem Formular aufzulisten und den Fokus auf das erste fehlerhafte Feld zu setzen. Bei manchen Feldern ist es sinnvoll, schon beim Verlassen des Feldes zu prüfen statt erst beim Absenden. Die Erfolgsmeldung danach gehört in einen Bereich mit role="status", damit ein Screenreader sie ansagt, ohne dass der Fokus springen muss (4.1.3, Stufe AA).

Nachsichtig sein ist besser als gut melden. Das W3C rät, möglichst viele Schreibweisen anzunehmen: Telefonnummern mit Leerzeichen, Schrägstrich oder +49. Und es warnt vor reinen Zahlenfeldern für Postleitzahlen, weil sie in vielen Ländern Buchstaben enthalten. Ein Formular, das solche Eingaben annimmt und selbst aufräumt, erzeugt gar keinen Fehler. Die Prüfung im Browser ersetzt übrigens nicht die auf dem Server: Sie lässt sich umgehen.

Hilfe, bevor der Fehler passiert

Erwartet ein Feld ein bestimmtes Format, gehört das dazugeschrieben: als Text unter dem Feld, verknüpft über aria-describedby. So wird die Erklärung nach der Beschriftung vorgelesen und steht nicht nur da. Bei Datei-Uploads heißt das: erlaubte Formate und maximale Größe nennen, bevor jemand eine zu große Datei hochlädt.

Das W3C mahnt dabei zum Maß: Zu viel Anweisung schadet genauso wie zu wenig. Ein Hinweis pro Feld, wo er gebraucht wird, genügt.

Bei folgenreichen Formularen: prüfen lassen

Kriterium 3.3.4, Stufe AA, gilt für Formulare, die eine rechtliche Verpflichtung oder eine Zahlung auslösen, gespeicherte Nutzerdaten ändern oder löschen oder Prüfungsantworten abschicken. Mindestens eines muss dann gelten:

• Umkehrbar: Die Eingabe lässt sich zurücknehmen.
• Geprüft: Die Eingaben werden auf Fehler geprüft, und der Nutzer kann sie korrigieren.
• Bestätigt: Vor dem endgültigen Absenden gibt es eine Übersicht zum Prüfen und Korrigieren.

Für ein Kontaktformular ist das nicht gefordert. Für eine Bestellung, eine kostenpflichtige Buchung oder eine Kündigung schon.

Das CAPTCHA am Ende

Hier treffen sich zwei Themen an einer unangenehmen Stelle.

Barrierefreiheit: Das W3C hält in seiner Notiz zur Unzugänglichkeit von CAPTCHAs fest, dass verzerrte Schriftzeichen für blinde Menschen nicht lösbar sind, weil der Screenreader das Bild nicht lesen kann. Die Audio-Alternative ist ebenfalls verzerrt und von Störgeräuschen überlagert, und sie belastet alle Nutzer deutlich mehr als normale Sprache. Wer ein solches CAPTCHA vor sein Kontaktformular setzt, verliert Interessenten, ohne es zu merken.

Datenschutz: Das österreichische Bundesverwaltungsgericht hat am 13. September 2024 entschieden (W298 2274626-1/8E), dass Google reCAPTCHA für den Betrieb einer Website technisch nicht notwendig ist und deshalb eine Einwilligung braucht. Da die Entscheidung auf der europäischen Cookie-Richtlinie beruht, gilt sie auch für Deutschland als relevant. Praktisch ist das eine Zwickmühle: Wer reCAPTCHA erst nach Einwilligung lädt, hat bei allen, die das Cookie-Banner ablehnen, gar keinen Schutz.

Das W3C nennt als Alternative ohne Rätsel für den Nutzer unter anderem den Honeypot: ein unsichtbares Feld, das nur Bots ausfüllen. Er stört niemanden, und laut W3C funktioniert er gut genug, dass mehrere Content-Management-Systeme ihn anbieten. Ob ein anderer CAPTCHA-Dienst ohne Einwilligung eingesetzt werden darf, klärt eine Datenschutzberatung.

Wie du das selbst prüfst

Fünf Tests, keiner braucht ein Werkzeug:

1. Der Klick-Test. Klick auf den Beschriftungstext über einem Feld. Springt der Cursor ins Feld, ist die Verknüpfung da. Passiert nichts, fehlt sie. Das funktioniert bei jedem Formular, auch bei fremden.
2. Der Tastatur-Test. Leg die Maus weg. Tab dich durch das Formular, füll jedes Feld aus, sende ab. Kommst du überall hin? Siehst du bei jedem Schritt, wo du bist?
3. Der Fehler-Test. Sende das Formular absichtlich falsch ab: Pflichtfeld leer, E-Mail ohne @. Steht die Meldung als Text beim Feld? Sagt sie, was zu tun ist? Landet der Fokus beim Fehler?
4. Der Handy-Test. Tipp auf dem Telefon nacheinander in jedes Feld. Kommt beim Telefonfeld das Tastenfeld, beim E-Mail-Feld eine Tastatur mit @? Kommt überall dieselbe Buchstabentastatur, fehlen die Feldtypen.
5. Der Autofill-Test. Klick ins Namensfeld. Bietet der Browser einen Vorschlag an? Wenn nicht, fehlt vermutlich autocomplete.

Wer es genauer wissen will, nimmt einen Screenreader dazu. NVDA ist für Windows kostenlos.

Was zu tun ist

1. Sichtbare Beschriftung an jedes Feld, verknüpft über for und id. Platzhalter nur als Formatbeispiel.
2. Feldtypen setzen: tel, email, url, date. number nur für echte Mengen.
3. autocomplete auf alle Felder mit persönlichen Angaben.
4. Pflichtfelder mit required und im Text kennzeichnen, nicht nur mit Farbe.
5. Radiobuttons und Checkbox-Gruppen in <fieldset> mit <legend>.
6. Fehlermeldungen als ganze Sätze beim Feld, mit aria-describedby und aria-invalid="true", und eine Erfolgsmeldung mit role="status".
7. Formathinweise dazuschreiben und ebenfalls verknüpfen.
8. Das grafische CAPTCHA ersetzen, im einfachsten Fall durch einen Honeypot.
9. Und der Punkt, der am meisten bringt: weniger Felder. Jedes Feld, das du streichst, musst du nicht beschriften, nicht prüfen, und niemand muss es ausfüllen.

Was das Gesetz verlangt

Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz für Dienstleistungen an Verbraucher, darunter den elektronischen Geschäftsverkehr. Bestell-, Buchungs- und Anmeldeformulare stehen damit im Mittelpunkt, weil dort der eigentliche Vorgang stattfindet. Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz oder Bilanzsumme sind teilweise ausgenommen. Maßstab ist die europäische Norm EN 301 549, die nach Angaben des Bundes die WCAG 2.1 in den Stufen A und AA verbindlich macht. Alle Kriterien in diesem Artikel gehören zu diesem Kern. Ob dein Betrieb betroffen ist, klärt eine Rechtsberatung, nicht eine technische Prüfung. Unabhängig davon gilt: Bei einem Neubau kosten diese Maßnahmen fast nichts, nachträglich deutlich mehr.

Quellen

• W3C WAI, Forms Tutorial: Labeling Controls — for und id, größere Klickfläche: w3.org
• W3C WAI, Forms Tutorial: Form Instructions — Platzhalter, aria-describedby für Hinweise: w3.org
• W3C WAI, Forms Tutorial: Grouping Controls — fieldset und legend, Verhalten der Screenreader: w3.org
• W3C WAI, Forms Tutorial: Validating Input — nachsichtige Prüfung, Postleitzahlen, Prüfung auf dem Server: w3.org
• W3C WAI, Forms Tutorial: User Notifications — Fehlerliste, Fokus auf das erste Fehlerfeld, Prüfung beim Verlassen: w3.org
• W3C, Understanding WCAG 2.2 — 1.3.1 Info und Beziehungen, Techniken H44 und H71: w3.org
• W3C, Understanding WCAG 2.2 — 1.3.5 Eingabezweck bestimmen: w3.org
• W3C, Understanding WCAG 2.2 — 3.3.1 Fehlererkennung: w3.org
• W3C, Understanding WCAG 2.2 — 3.3.2 Beschriftungen oder Anweisungen, zu viel Anweisung schadet: w3.org
• W3C, Understanding WCAG 2.2 — 3.3.3 Korrekturvorschläge: w3.org
• W3C, Understanding WCAG 2.2 — 3.3.4 Fehlervermeidung, drei Wege: w3.org
• W3C, Understanding WCAG 2.2 — 4.1.2 Name, Rolle, Wert: w3.org
• W3C, Understanding WCAG 2.2 — 4.1.3 Statusmeldungen, role="status": w3.org
• W3C, Technik ARIA21 — aria-invalid mit aria-describedby: w3.org
• W3C, Inaccessibility of CAPTCHA — grafische und Audio-CAPTCHAs, Honeypot: w3.org
• MDN, <input type="tel"> — Telefon-Tastenfeld, keine Formatprüfung: developer.mozilla.org
• MDN, <input type="number"> — nur für echte Mengen, nicht für Postleitzahlen: developer.mozilla.org
• MDN, <input type="date"> — Datumsauswahl je nach Browser: developer.mozilla.org
• MDN, inputmode — Bildschirmtastaturen für email, url, search: developer.mozilla.org
• MDN, autocomplete — Werte und Bezug zu 1.3.5: developer.mozilla.org
• MDN, aria-required — Vorrang von required, Kennzeichnung nicht nur über Farbe: developer.mozilla.org
• IT-Recht Kanzlei, BVwG Österreich zu Google reCAPTCHA — 13.09.2024, W298 2274626-1/8E, Einwilligung erforderlich: it-recht-kanzlei.de
• NV Access, About NVDA — kostenloser Screenreader für Windows: nvaccess.org
• Portal Barrierefreiheit des Bundes — Barrierefreiheitsstärkungsgesetz, Geltung ab 28.06.2025, Kleinstunternehmen: barrierefreiheit-dienstekonsolidierung.bund.de
• Portal Barrierefreiheit des Bundes — WCAG 2.1 und EN 301 549, Stufen A und AA: barrierefreiheit-dienstekonsolidierung.bund.de