Technik

Barrierefreie Formulare: Labels, Fehlermeldungen und Pflichtfelder richtig umsetzen

Von Joshua Kantner · April 2026 · bf-check.de

Hinweis: Dieser Artikel dient der allgemeinen Orientierung und ersetzt keine rechtliche oder technische Fachberatung. Die genannten WCAG-Kriterien und BFSG-Bezüge geben den Stand April 2026 wieder. Für verbindliche Aussagen zu Ihrem konkreten Fall konsultieren Sie einen spezialisierten Berater.

Warum Formulare der häufigste Stolperstein sind

Formulare sind interaktive Elemente, die besonders hohe Barrierefreiheits-Anforderungen haben. Ein visuell beschriftetes Eingabefeld ist nicht automatisch für Screenreader zugänglich. Fehlermeldungen, die nur rot blinken, helfen niemandem, der Farben nicht sehen kann.

Und Pflichtfelder, die nur mit * markiert sind, werden von Screenreadern nicht als Pflicht erkannt.

Laut WCAG-Richtlinie 3.3 ("Input Assistance") müssen Formulare Nutzer dabei unterstützen, Fehler zu vermeiden und zu korrigieren. Das betrifft alle Eingabefelder -- von einfachen Kontaktformularen bis hin zu komplexen Checkout-Prozessen. Weitere Informationen finden Sie im Formular-Labels Glossar.

Das korrekte Einsetzen von ARIA-Attributen spielt dabei eine zentrale Rolle. Denn ohne programmatische Verknüpfung zwischen Label, Feld und Fehlermeldung bleibt ein Formular für assistive Technologien ein Rätsel.

Labels korrekt zuordnen: das for-Attribut

Jedes Eingabefeld braucht ein HTML-<label> mit for-Attribut, das auf die id des Feldes zeigt. Dieses Prinzip ist in WCAG SC 1.3.1 ("Info and Relationships") und SC 4.1.2 ("Name, Role, Value") verankert.

Platzhalter-Text (placeholder) ist KEIN Ersatz für ein Label -- er verschwindet beim Tippen und wird von manchen Screenreadern ignoriert.

Code-Beispiel: Vorher (falsch)

<!-- Falsch: Kein Label, nur Platzhalter -->
<input type="email" placeholder="E-Mail-Adresse">

<!-- Falsch: Label ohne for-Attribut -->
<label>Name</label>
<input type="text" id="name">

Code-Beispiel: Nachher (richtig)

<!-- Richtig: Label mit for zeigt auf id -->
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email"
       autocomplete="email"
       aria-required="true" required>

<!-- Richtig: Label korrekt verknüpft -->
<label for="name">Vollständiger Name</label>
<input type="text" id="name" name="name"
       autocomplete="name">

Wichtig: Das for-Attribut im Label muss exakt dem id-Wert des Eingabefeldes entsprechen. Groß-/Kleinschreibung zählt.

Formularfelder gruppieren mit fieldset und legend

Zusammengehörige Felder -- z.B. Adressdaten, Zahlungsmethoden oder Kontaktpräferenzen -- sollten mit <fieldset> und <legend> gruppiert werden. Screenreader lesen die legend vor jedem Feld der Gruppe vor, sodass der Kontext erhalten bleibt.

<fieldset>
  <legend>Rechnungsadresse</legend>
  <label for="strasse">Straße und Hausnummer</label>
  <input type="text" id="strasse" autocomplete="street-address">
  <label for="plz">Postleitzahl</label>
  <input type="text" id="plz" autocomplete="postal-code">
  <label for="ort">Ort</label>
  <input type="text" id="ort" autocomplete="address-level2">
</fieldset>

Ohne fieldset/legend hört ein Screenreader-Nutzer bei Radiobuttons nur "Ja" und "Nein" -- ohne zu wissen, worauf sich die Frage bezieht. Mit <legend>Newsletter abonnieren?</legend> wird der Kontext klar.

⚠️

Ist deine Webseite betroffen? Kostenloser BFSG-Schnellcheck – Ergebnis in 30 Sekunden.

Jetzt prüfen →

Fehlermeldungen zugänglich machen (SC 3.3.1 und SC 3.3.3)

WCAG SC 3.3.1 ("Error Identification") verlangt: Wenn ein Fehler automatisch erkannt wird, muss das fehlerhafte Element identifiziert und der Fehler in Textform beschrieben werden.

WCAG SC 3.3.3 ("Error Suggestion") geht weiter: Wenn der Fehler erkannt wird und Korrekturvorschläge bekannt sind, müssen diese dem Nutzer bereitgestellt werden -- sofern das die Sicherheit nicht gefährdet.

Fehlermeldungen müssen konkret mehrere Anforderungen erfüllen:

Direkt beim fehlerhaften Feld stehen -- nicht nur oben auf der Seite
Per aria-describedby mit dem Feld verknüpft sein
Automatisch per aria-live="polite" oder role="alert" angesagt werden
Den Fehler in Text beschreiben -- nicht nur durch Farbe (SC 1.4.1)

Code-Beispiel: Fehlermeldung richtig umsetzen

<label for="email">E-Mail-Adresse *</label>
<input type="email" id="email"
       aria-required="true" required
       aria-describedby="email-error"
       aria-invalid="true">
<span id="email-error" role="alert"
      style="color:#dc2626">
  Bitte geben Sie eine gültige E-Mail-Adresse ein,
  z.B. name@beispiel.de
</span>

Beachte: aria-invalid="true" wird erst gesetzt, wenn die Validierung fehlgeschlagen ist -- nicht von Anfang an. Und die Fehlermeldung enthält einen konkreten Korrekturvorschlag (SC 3.3.3).

Pflichtfelder korrekt kennzeichnen (aria-required)

Pflichtfelder müssen sowohl visuell als auch programmatisch erkennbar sein. Ein Sternchen (*) allein reicht nicht -- Screenreader lesen es oft nicht vor oder ignorieren die Bedeutung.

Die richtige Kombination:

required -- für die native HTML-Validierung
aria-required="true" -- für maximale Screenreader-Kompatibilität
Sichtbarer Hinweis am Formularanfang: "Felder mit * sind Pflichtfelder"

Hilfetexte (z.B. "Mindestens 8 Zeichen") werden per aria-describedby mit dem Feld verknüpft. So hört ein Screenreader-Nutzer nach dem Label auch die Hilfe.

Autocomplete: Eingabezweck angeben (SC 1.3.5)

WCAG SC 1.3.5 ("Identify Input Purpose") verlangt, dass der Zweck von Eingabefeldern für persönliche Daten programmatisch bestimmbar ist. In der Praxis bedeutet das: autocomplete-Attribute setzen.

Das hilft nicht nur bei der Barrierefreiheit -- Nutzer mit motorischen Einschränkungen oder kognitiven Beeinträchtigungen profitieren, weil der Browser Felder automatisch befüllen kann. Auch personalisierte Icons (z.B. ein Telefonsymbol neben dem Telefonfeld) werden so ermöglicht.

Die wichtigsten Autocomplete-Werte:

autocomplete="name" -- Vollständiger Name
autocomplete="email" -- E-Mail-Adresse
autocomplete="tel" -- Telefonnummer
autocomplete="street-address" -- Straße
autocomplete="postal-code" -- Postleitzahl
autocomplete="cc-number" -- Kreditkartennummer
autocomplete="new-password" -- Neues Passwort

Die vollständige Liste der Werte findet sich in der WCAG-Dokumentation. Jedes Feld, das persönliche Daten abfragt, sollte einen passenden Autocomplete-Wert erhalten.

Formular-Validierung BFSG-konform

Clientseitige Validierung muss zugänglich sein. Das bedeutet konkret:

Fehlerhafte Felder nicht nur rot markieren, sondern auch per Text beschreiben
Den Fokus zum ersten fehlerhaften Feld setzen
Eine Zusammenfassung aller Fehler oben anzeigen -- mit Sprunglinks zu den betroffenen Feldern
Nach der Korrektur eine Erfolgsmeldung ausgeben ("Formular erfolgreich gesendet")

Bei Tastatur-Bedienbarkeit ist besonders wichtig: Der Tab-Fokus muss in logischer Reihenfolge durch das Formular führen. Nach dem Absenden mit Fehlern springt der Fokus zur Fehlerzusammenfassung oder zum ersten fehlerhaften Feld.

CAPTCHA-Alternativen: Sicherheit ohne Barriere

Klassische Bild-CAPTCHAs ("Klicke alle Ampeln an") sind für blinde und sehbehinderte Nutzer nicht lösbar. Auch für Menschen mit motorischen Einschränkungen sind sie problematisch.

Barrierefreie Alternativen:

Honeypot-Felder: Unsichtbare Felder, die nur Bots ausfüllen. Kein Aufwand für echte Nutzer.
Zeitbasierte Prüfung: Bots füllen Formulare in Millisekunden aus -- echte Nutzer brauchen länger.
reCAPTCHA v3: Arbeitet komplett im Hintergrund ohne Nutzerinteraktion.
hCaptcha Accessibility: Bietet einen barrierefreien Modus für Screenreader-Nutzer.
Logische Fragen: "Was ist 3 plus 4?" -- einfach für Menschen, schwerer für Bots. Aber Vorsicht: nicht für alle kognitiven Einschränkungen geeignet.

Am besten kombinierst du mehrere unsichtbare Methoden (Honeypot + Zeitprüfung). So bleibt dein Formular sicher, ohne eine einzige Barriere zu schaffen.

Mehrstufige Formulare und Wizards

Komplexe Formulare -- Checkout-Prozesse, Kontoeröffnungen, Bewerbungsformulare -- werden oft in mehrere Schritte aufgeteilt. Damit das barrierefrei funktioniert, sind mehrere Punkte zu beachten:

Fortschrittsanzeige: Zeige dem Nutzer, in welchem Schritt er sich befindet. Nutze aria-current="step" für den aktiven Schritt und informiere Screenreader über den Gesamtfortschritt (z.B. "Schritt 2 von 4").
Klare Überschriften: Jeder Schritt braucht eine eigene <h2> mit beschreibendem Titel ("Schritt 2: Lieferadresse").
Fokus-Management: Beim Schrittwechsel muss der Fokus auf die Überschrift oder das erste Eingabefeld des neuen Schritts gesetzt werden.
Zurück-Navigation: Nutzer müssen zu vorherigen Schritten zurückkehren können, ohne eingegebene Daten zu verlieren.
Zusammenfassung: Vor dem endgültigen Absenden eine Übersicht aller eingegebenen Daten zeigen -- mit Möglichkeit zur Korrektur (WCAG SC 3.3.4).

Datepicker und Datumsauswahl

Datepicker-Widgets sind notorisch schwer zugänglich zu machen. Viele JavaScript-Kalender-Widgets sind nicht per Tastatur bedienbar und für Screenreader unverständlich.

Empfohlene Strategien:

Textfeld mit Formathinweis: Ein einfaches <input type="text"> mit dem Hinweis "TT.MM.JJJJ" und aria-describedby ist die barrierefreiste Lösung.
Native HTML5: <input type="date"> ist in modernen Browsern akzeptabel, aber die Darstellung variiert.
ARIA-Datepicker: Wenn du einen Kalender-Dialog brauchst, orientiere dich am ARIA Authoring Practices Guide. Der Kalender muss per Pfeiltasten navigierbar sein, Enter wählt ein Datum, Escape schließt den Dialog.

Stelle immer sicher, dass das Datumsfeld auch ohne Maus bedienbar ist. Teste es mit der Tastatur-Bedienbarkeit: Kann ein Nutzer allein mit Tab, Pfeiltasten und Enter ein Datum auswählen?

Barrierefreie Tabellen in Formularen

Manche Formulare nutzen tabellarische Layouts -- z.B. Preisvergleiche mit Checkboxen oder Bestelllisten mit Mengenfeldern. Hier gilt: Die Tabelle muss semantisch korrekt sein (<th> für Spaltenüberschriften), und jedes Eingabefeld innerhalb der Tabelle braucht ein zugeordnetes Label.

Falls kein sichtbares Label möglich ist, verwende aria-label oder aria-labelledby, um die Zelle mit der Zeilen- und Spaltenüberschrift zu verknüpfen.

Checkliste: Barrierefreie Formulare

Nutze diese Checkliste, um dein Formular zu prüfen -- oder lass deinen gesamten Auftritt mit dem bf-check Scanner automatisch analysieren:

Jedes Feld hat ein <label> mit for-Attribut
Pflichtfelder: required + aria-required="true" + visueller Hinweis
Fehlermeldungen: aria-describedby + role="alert" + Textbeschreibung
Gruppen: fieldset + legend bei zusammengehörigen Feldern
Autocomplete-Attribute für persönliche Daten (SC 1.3.5)
Formular per Tastatur vollständig bedienbar
CAPTCHA hat barrierefreie Alternative
Mehrstufige Formulare: Fortschrittsanzeige + Fokus-Management
Datepicker per Tastatur und Screenreader nutzbar

Häufig gestellte Fragen

Sind Platzhalter als Labels okay?

Nein. Platzhalter verschwinden beim Tippen und werden von Screenreadern nicht zuverlässig als Label erkannt. Nutze immer ein sichtbares HTML-Label.

Muss ich aria-required UND required nutzen?

Am besten beides: required für HTML-Validierung, aria-required='true' für Screenreader-Kompatibilität.

Wie mache ich Fehlermeldungen für Screenreader zugänglich?

Verknüpfe Fehlermeldungen per aria-describedby mit dem jeweiligen Eingabefeld. Nutze aria-live='polite' oder role='alert', damit Screenreader die Meldung automatisch vorlesen. Die Fehlermeldung muss den Fehler in Textform beschreiben -- nicht nur durch Farbe (WCAG SC 3.3.1).

Was ist der Unterschied zwischen fieldset/legend und aria-labelledby?

fieldset/legend ist die native HTML-Methode um zusammengehörige Formularfelder zu gruppieren -- z.B. Adressfelder oder Zahlungsoptionen. aria-labelledby referenziert ein bestehendes Element als Beschriftung. Für Formular-Gruppen ist fieldset/legend die robustere Lösung, weil es von allen Screenreadern zuverlässig unterstützt wird.

Muss ich CAPTCHA barrierefrei machen?

Ja. Visuelle CAPTCHAs sind für blinde Nutzer unüberwindbar. Biete mindestens eine Alternative an: Audio-CAPTCHA, logische Fragen oder unsichtbare Lösungen wie Honeypot-Felder. Am besten: reCAPTCHA v3 oder hCaptcha Accessibility, die ohne Nutzerinteraktion arbeiten.

Wie kennzeichne ich Pflichtfelder korrekt?

Setze sowohl das HTML-Attribut required als auch aria-required='true'. Ergänze am Anfang des Formulars einen Hinweis wie 'Felder mit * sind Pflichtfelder'. Das Sternchen allein reicht nicht -- es muss erklärt und programmatisch erkennbar sein.

Welche Autocomplete-Werte muss ich setzen?

WCAG SC 1.3.5 verlangt autocomplete-Attribute für Felder mit persönlichen Daten. Typische Werte: autocomplete='name', 'email', 'tel', 'street-address', 'postal-code', 'cc-number'. Das hilft Nutzern mit motorischen Einschränkungen und Screenreader-Nutzern, Formulare schneller auszufüllen.

Wie gestalte ich mehrstufige Formulare barrierefrei?

Zeige eine Fortschrittsanzeige mit aria-current='step'. Jeder Schritt braucht eine klare Überschrift. Der Fokus muss beim Schrittwechsel auf die neue Überschrift oder das erste Feld gesetzt werden. Nutzer müssen zu vorherigen Schritten zurückkehren können, ohne Daten zu verlieren.

Weiterlesen

Technik
Newsletter barrierefrei Technik
Barrierefreie Navigation Leitfaden
BFSG 2025: Der komplette Leitfaden

Ist deine Webseite BFSG-konform?

Finde es in 30 Sekunden heraus – kostenloser Schnellcheck mit sofortigem Ergebnis.

Jetzt kostenlos prüfen →