Barrierefreie Formulare: Labels, Fehlermeldungen, Pflichtfelder

Formulare sind die Stelle, an der Barrierefreiheit aufhört, eine Stilfrage zu sein. Ein schlecht kontrastierter Fließtext ist ärgerlich — ein Bestellformular, das sich mit dem Screenreader nicht ausfüllen lässt, beendet den Kauf. Genau deshalb lohnt sich hier die meiste Sorgfalt: Es ist der kürzeste Weg von einer Barriere zu verlorenem Umsatz.

Ein barrierefreies Formular ist ein Formular, dessen Felder, Beschriftungen, Pflichtangaben und Fehlermeldungen sowohl visuell als auch programmatisch zugänglich sind — also auch dann vollständig nutzbar, wenn jemand es per Tastatur bedient, per Screenreader vorgelesen bekommt oder stark vergrößert darstellt. Entscheidend ist nicht, wie das Formular aussieht, sondern ob die Information über jedes Feld maschinenlesbar im Markup steht.

Was wir in echten Scans finden

Die folgenden Zahlen stammen aus unserer eigenen Scan-Datenbank: 867 geprüfte Seiten auf 109 Domains, Zeitraum 29. April bis 15. September 2026 (eigene Domains und Testseiten herausgerechnet). Gezählt wird pro Domain, damit große Websites das Bild nicht verzerren.

40,4 Prozent der geprüften Domains hatten mindestens einen Formular-Befund — 44 von 109. Aufgeschlüsselt nach Fehlertyp:

Zwei Dinge fallen daran auf.

Erstens ist das fehlende Label zwar der häufigste Befund, aber nicht der größte. Die 338 namenlosen ARIA-Bedienelemente auf 27 Domains sind die eigentliche Masse — das sind selbstgebaute Dropdowns, Custom-Checkboxen, Suchfelder und Datumswähler, die optisch wie ein Formularfeld aussehen, für assistive Technik aber ein anonymes div bleiben. Wer ein Design-System oder einen Page-Builder einsetzt, sammelt diesen Fehler dutzendfach ein, nicht einmal.

Zweitens ist die letzte Zeile aufschlussreich: Kein einziges autocomplete-Attribut in der gesamten Stichprobe war fehlerhaft. Das liegt nicht daran, dass alle es richtig machen — sondern daran, dass ein maschineller Test nur die Syntax vorhandener Attribute prüfen kann. Ein komplett fehlendes autocomplete sieht für den Scanner aus wie ein Formular ohne Anspruch darauf. Genau solche Lücken schließen nur manuelle Prüfschritte.

In sieben Schritten zum barrierefreien Formular

1. Jedes Feld mit einem sichtbaren Label verknüpfen

Jedes Eingabefeld braucht eine Beschriftung, die sichtbar ist und programmatisch mit dem Feld verbunden. Die Verbindung entsteht über das for-Attribut des label, das auf die id des Feldes zeigt:

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

Das ist die robusteste Variante — sie funktioniert in jedem Browser, mit jedem Screenreader, und sie vergrößert nebenbei die Klickfläche: Ein Klick auf das Label setzt den Fokus ins Feld. aria-label ist der Notnagel für Fälle, in denen wirklich keine sichtbare Beschriftung möglich ist; es erzeugt einen Namen, den sehende Nutzer nicht sehen, und ist damit die schlechtere Wahl. Maßgeblich sind WCAG 1.3.1 (Info und Beziehungen) und 4.1.2 (Name, Rolle, Wert), beide Stufe A.

2. Platzhalter nie als Beschriftung verwenden

Der Text im placeholder ist keine Beschriftung, sondern ein Beispiel. Er verschwindet, sobald jemand tippt — wer beim Ausfüllen unterbrochen wird, weiß danach nicht mehr, was in das Feld gehört. Hinzu kommt: Platzhaltertext wird von Browsern standardmäßig hellgrau dargestellt und reißt regelmäßig die Kontrastgrenze von 4,5:1. Wie man das nachmisst, steht im Farbkontrast-Artikel; einzelne Kombinationen prüfst du direkt im Kontrast-Checker.

Richtig ist: sichtbares Label über dem Feld, Platzhalter nur zusätzlich für ein Format-Beispiel — oder besser als dauerhaft sichtbarer Hinweis, der per aria-describedby mit dem Feld verknüpft ist.

3. Zusammengehörige Felder gruppieren

Radiobuttons und Checkbox-Gruppen brauchen eine Beschriftung für die Gruppe, nicht nur für die einzelne Option. Sonst hört ein Screenreader-Nutzer nur Ja und Nein, ohne die Frage zu kennen:

<fieldset>
  <legend>Möchten Sie unseren Newsletter erhalten?</legend>
  <input type="radio" id="nl-ja" name="newsletter" value="ja">
  <label for="nl-ja">Ja</label>
  <input type="radio" id="nl-nein" name="newsletter" value="nein">
  <label for="nl-nein">Nein</label>
</fieldset>

Dasselbe gilt für Adressblöcke, Zeiträume und alles, was inhaltlich eine Einheit bildet. Die Alternative über role="group" und aria-labelledby ist zulässig, aber aufwendiger — fieldset und legend sind der kürzere Weg zum gleichen Ergebnis.

4. Pflichtfelder doppelt kennzeichnen

Ein Sternchen allein reicht nicht: Es ist eine rein visuelle Konvention, die nicht jeder kennt und die nicht vorgelesen wird. Pflichtfelder brauchen beides — eine sichtbare Kennzeichnung mit erklärender Legende am Formularanfang und das Attribut required beziehungsweise aria-required="true", das die Pflicht an assistive Technik weitergibt.

Noch besser ist, die Frage umzudrehen: Kennzeichne stattdessen die optionalen Felder, wenn ohnehin fast alles Pflicht ist. Und streiche jedes Feld, das du nicht wirklich brauchst — das kürzeste Formular ist auch das barrierefreieste. WCAG 3.3.2 (Beschriftungen oder Anweisungen, Stufe A) verlangt genau diese Vorab-Information.

5. Den Eingabezweck maschinenlesbar machen

Felder, die persönliche Daten der ausfüllenden Person abfragen, brauchen ein passendes autocomplete-Attribut. Das ist kein Komfort-Feature, sondern seit WCAG 2.1 das Erfolgskriterium 1.3.5 (Eingabezweck bestimmen, Stufe AA):

<label for="vorname">Vorname</label>
<input type="text" id="vorname" name="vorname" autocomplete="given-name">

<label for="tel">Telefon</label>
<input type="tel" id="tel" name="tel" autocomplete="tel">

Der Nutzen ist doppelt: Browser füllen korrekt aus, und Werkzeuge für Menschen mit kognitiven Einschränkungen können Felder mit vertrauten Symbolen anreichern. Dazu passt der richtige type — type="email" oder type="tel" blendet auf dem Smartphone die passende Tastatur ein.

6. Fehler benennen, verorten und erklären

Die WCAG verlangen an dieser Stelle drei Dinge, die oft verwechselt werden:

• 3.3.1 Fehlererkennung (A): Der Fehler muss in Textform beschrieben werden. Ein roter Rahmen allein erfüllt das nicht — Farbe darf nie der einzige Träger einer Information sein.
• 3.3.3 Fehlerempfehlung (AA): Die Meldung muss sagen, wie es richtig geht. Ein pauschales Ungültige Eingabe ist zu wenig; ein Hinweis auf das erwartete Format erfüllt das Kriterium.
• 3.3.4 Fehlervermeidung (AA): Bei rechtlich bindenden, finanziellen oder datenverändernden Vorgängen sowie beim Einreichen von Testantworten muss die Eingabe prüfbar, korrigierbar oder widerrufbar sein — in der Praxis die Bestätigungsseite vor dem Absenden.

Technisch gehört die Meldung neben das betroffene Feld und per aria-describedby mit ihm verknüpft, das Feld selbst bekommt aria-invalid="true". Eine Sammelmeldung am Seitenanfang ist eine sinnvolle Ergänzung, ersetzt aber die Meldung am Feld nicht. Erscheint die Meldung dynamisch, gehört sie in einen Bereich mit role="alert", damit sie auch angesagt wird:

<label for="plz">Postleitzahl</label>
<input type="text" id="plz" name="plz" inputmode="numeric"
       aria-describedby="plz-fehler" aria-invalid="true">
<p id="plz-fehler" role="alert">
  Die Postleitzahl muss aus genau fünf Ziffern bestehen, zum Beispiel 34497.
</p>

7. Eigenen Bedienelementen einen Namen geben

Das ist der Befund mit den meisten betroffenen Elementen — und der, der sich am schlechtesten von selbst erledigt. Sobald ein Dropdown, eine Checkbox oder ein Datumswähler nicht aus nativem HTML besteht, sondern aus div- und span-Elementen mit ARIA-Rollen, muss der Name von Hand gesetzt werden, üblicherweise über aria-labelledby (Verweis auf die sichtbare Beschriftung) oder aria-label.

Die bessere Entscheidung ist meistens, gar nicht erst nachzubauen: Ein natives select, input type="date" oder input type="checkbox" bringt Name, Rolle, Zustand und Tastaturbedienung bereits mit. Wer nachbaut, übernimmt die Verantwortung für alle vier — inklusive Fokusreihenfolge und Tastaturbedienung. Es gilt die Faustregel aus dem WCAG-Grundlagenartikel: Kein ARIA ist besser als schlechtes ARIA.

Welche WCAG-Kriterien für Formulare gelten

Formulare berühren mehr Erfolgskriterien als jedes andere Element einer Website. Diese Übersicht enthält die Kriterien, die praktisch bei jedem Formular greifen — mit ihrer Konformitätsstufe:

Mit der WCAG 2.2 sind drei Kriterien dazugekommen, die fast ausschließlich Formulare betreffen: 3.3.7 Redundante Eingabe (A — dieselbe Information nicht zweimal abfragen, etwa Liefer- und Rechnungsadresse), 3.3.8 Barrierefreie Authentifizierung (AA — ein kognitiver Test wie das Merken eines Passworts darf kein unumgängliches Hindernis sein: Es braucht eine Alternative oder eine Unterstützungsfunktion, etwa das erlaubte Einfügen aus dem Passwortmanager) und 2.5.8 Zielgröße (Minimum) (AA — Bedienelemente mindestens 24 × 24 CSS-Pixel). Für die rechtliche Orientierung in Deutschland ist derzeit noch WCAG 2.1 der Bezugspunkt, aber wer heute ein Formular neu baut, nimmt die drei sinnvollerweise gleich mit.

Was ein Scanner findet — und was nicht

Ein automatischer Test erkennt die strukturellen Formularfehler zuverlässig: fehlende Labels, namenlose Auswahllisten und Bedienelemente, konkurrierende Beschriftungen, unzureichende Kontraste. Das ist genau die Liste aus der Tabelle oben — und sie ist es wert, zuerst abgearbeitet zu werden, weil sie ohne Interpretationsspielraum auskommt.

Drei Dinge kann kein Scanner beurteilen, und sie entscheiden darüber, ob ein Formular in der Praxis funktioniert:

1. Ist das Label inhaltlich richtig? Ein Feld mit der Beschriftung Feld 3 ist technisch einwandfrei und trotzdem unbrauchbar.
2. Ist die Fehlermeldung hilfreich? Ob dort eine konkrete Formatangabe oder nur ein pauschaler Hinweis steht, erkennt nur ein Mensch.
3. Funktioniert der Ablauf von vorn bis hinten? Einmal mit der Tastatur durch das ganze Formular, einmal mit Screenreader, einmal bei 200 % Zoom — diese drei Durchläufe finden mehr als jedes Werkzeug.

Wie diese manuellen Prüfschritte konkret ablaufen, steht in unserem Leitfaden Website auf Barrierefreiheit testen.

Formulare und das BFSG

Für Unternehmen ist das Barrierefreiheitsstärkungsgesetz (BFSG) seit dem 28. Juni 2025 anwendbar. Es verlangt keine bestimmte WCAG-Stufe im Gesetzestext, sondern Barrierefreiheit nach dem Stand der Technik; als maßgebliche Orientierung gilt die europäische Norm EN 301 549, die für Webinhalte auf die WCAG-Kriterien der Stufen A und AA verweist. Alle in der Tabelle oben genannten Kriterien liegen in diesem Bereich.

Wichtig ist die Unterscheidung, um die es beim BFSG wirklich geht: Nicht jedes Formular auf jeder Website fällt darunter. Entscheidend ist, ob über die Website eine Dienstleistung für Verbraucher erbracht oder ein Verbrauchervertrag angebahnt wird — beim Checkout eines Online-Shops ist das eindeutig, bei einem reinen Informationsauftritt kommt es auf den Einzelfall an. Wer in der Pflicht ist und wo die Ausnahme für Kleinstunternehmen greift, klärt der Artikel BFSG: Wer ist betroffen?; für Shop-Betreiber gibt es die eigene Übersicht BFSG für Online-Shops, die auch die Zusatzanforderungen an Login, Sicherheit und Zahlung behandelt.

Häufig gestellte Fragen (FAQ)

Was macht ein Formular barrierefrei?

Ein Formular ist barrierefrei, wenn jedes Feld eine sichtbare und programmatisch verknüpfte Beschriftung hat, Pflichtfelder und Formatvorgaben vor dem Ausfüllen erkennbar sind, das gesamte Formular per Tastatur bedienbar ist und Fehler in Textform benannt, dem Feld zugeordnet und mit einem Korrekturhinweis versehen werden. Technisch sind das vor allem die WCAG-Kriterien 1.3.1, 2.1.1, 3.3.1, 3.3.2, 3.3.3 und 4.1.2.

Reicht ein Placeholder als Beschriftung für ein Eingabefeld?

Nein. Der Platzhaltertext verschwindet, sobald jemand mit der Eingabe beginnt, wird von Screenreadern uneinheitlich behandelt und ist in der Standarddarstellung der Browser zu kontrastarm. Er darf ein sichtbares label ergänzen, aber nie ersetzen — sonst ist WCAG 3.3.2 nicht erfüllt und häufig zusätzlich 1.4.3.

Wie kennzeichne ich Pflichtfelder barrierefrei?

Doppelt: sichtbar und programmatisch. Sichtbar durch eine Markierung mit erklärender Legende am Formularanfang, programmatisch durch das Attribut required oder aria-required="true" am Feld. Ein Sternchen allein genügt nicht, weil es weder vorgelesen noch von allen Nutzern richtig gedeutet wird.

Wie müssen Fehlermeldungen in einem barrierefreien Formular aussehen?

Als Text, nicht nur als Farbe. Die Meldung muss beschreiben, welches Feld betroffen ist und wie die Eingabe richtig aussieht — also mit konkreter Formatangabe statt eines pauschalen Hinweises auf eine ungültige Eingabe. Sie steht direkt am Feld, ist per aria-describedby mit ihm verknüpft, das Feld trägt aria-invalid="true", und dynamisch eingeblendete Meldungen gehören in einen Bereich mit role="alert".

Muss mein Kontaktformular nach dem BFSG barrierefrei sein?

Das hängt davon ab, wozu die Website dient, nicht davon, dass ein Formular vorhanden ist. Das BFSG greift, wenn über die Website eine Dienstleistung für Verbraucher erbracht oder ein Verbrauchervertrag angebahnt wird. Ein Kontaktformular kann dafür ein Indiz sein, ist aber für sich genommen kein Auslöser — die Prüfung führt der Artikel BFSG: Wer ist betroffen? im Detail durch. Unabhängig von der Rechtslage gilt: Ein Formular, das sich nicht ausfüllen lässt, kostet Anfragen.

Welche WCAG-Kriterien gelten für Formulare?

Regelmäßig einschlägig sind 1.3.1 (Info und Beziehungen), 1.3.5 (Eingabezweck bestimmen), 1.4.3 und 1.4.11 (Kontraste), 2.1.1 (Tastatur), 2.4.7 (Fokus sichtbar), 2.5.3 (Beschriftung im Namen), 3.2.2 (Bei Eingabe), 3.3.1 bis 3.3.4 (Fehlerbehandlung und Anweisungen) sowie 4.1.2 (Name, Rolle, Wert). Mit WCAG 2.2 kommen 3.3.7 (Redundante Eingabe), 3.3.8 (Barrierefreie Authentifizierung) und 2.5.8 (Zielgröße) hinzu.

Sind Captchas barrierefrei?

Rein visuelle Captchas sind es nicht — sie sperren blinde Nutzer vollständig aus, und auch Audio-Alternativen scheitern häufig an Hintergrundgeräuschen oder fremder Sprache. WCAG 3.3.8 (Stufe AA, seit 2.2) verlangt, dass die Anmeldung keinen kognitiven Test voraussetzt — außer es gibt eine Alternative, eine Unterstützungsfunktion wie das Einfügen aus dem Passwortmanager, oder der Test beschränkt sich auf das Erkennen gängiger Objekte beziehungsweise selbst hochgeladener Inhalte. Praktikable Alternativen sind serverseitige Spam-Prüfungen, Honeypot-Felder oder zeitbasierte Heuristiken; sie sind für Nutzer unsichtbar und erzeugen keine Barriere.