Barrierefreie Formulare: So gestaltest du Formularelemente, die alle nutzen können

Warum Formulare darüber entscheiden, wer online teilhaben kann

Ein Produkt bestellen, einen Termin buchen, sich auf eine Stelle bewerben oder einen Antrag bei einer Behörde stellen: Fast jeder wichtige Schritt im Netz endet in einem Formular. Für viele Menschen ist das in einer Minute erledigt. Für andere ist genau hier Schluss.

Menschen, die assistive Technologien wie Screenreader, Braillezeilen oder Spracherkennungssoftware nutzen, stoßen oft auf Barrieren, die anderen gar nicht auffallen. Das gilt auch für Menschen mit Sehbehinderung, Farbsehschwäche oder kognitiven Beeinträchtigungen. Ebenso betroffen sind viele ältere Menschen und alle, die vorübergehend eingeschränkt sind.

Ein fehlendes Label, eine Fehlermeldung, die nur „Ungültige Eingabe“ sagt, oder ein CAPTCHA mit verschwommenen Bildern reicht aus, um sie auszuschließen.

Die gute Nachricht: Die meisten dieser Barrieren lassen sich leicht vermeiden, und davon profitiert das Nutzungserlebnis aller. Dieser Artikel zeigt zuerst die häufigsten Hürden und erklärt dann Element für Element, wie du Formulare baust, die alle selbstständig ausfüllen können.

Wenn Onlineformulare zur Hürde werden

Diese fünf Barrieren tauchen in Barrierefreiheitsprüfungen immer wieder auf. Weiter unten gehen wir auf jede genauer ein.

• Fehlende Struktur und Beschriftung: Screenreader-Nutzende und Menschen mit Sehbehinderung oder kognitiven Beeinträchtigungen erkennen nicht, welches Feld welche Eingabe erwartet. Sichtbare, verknüpfte Labels, eine logische Reihenfolge und gruppierte Abschnitte helfen.

• Bedienung nur mit der Maus: Menschen mit motorischen Einschränkungen und alle, die per Tastatur oder Sprache steuern, kommen nicht weiter. Vollständige Tastaturbedienbarkeit und zugängliche Namen, die dem sichtbaren Label entsprechen, helfen.

• Geringer Kontrast und kleine Schrift: Menschen mit Sehbehinderung, ältere Menschen und alle, die bei Sonnenlicht aufs Smartphone schauen, können das Formular kaum lesen. Ein Kontrast von mindestens 4,5:1 für Text und Layouts, die auch bei 200 % Textgröße funktionieren, helfen.

• Komplizierte CAPTCHAs und Zeitlimits: Menschen mit kognitiven Beeinträchtigungen oder Lernschwierigkeiten und blinde Menschen scheitern oft daran. Keine Rätsel, kein Zeitdruck und Alternativen wie Passkeys oder Login-Links per E-Mail helfen.

• Video oder Audio ohne Alternative: Gehörlosen, schwerhörigen und blinden Menschen fehlen wichtige Informationen. Untertitel, Transkripte und Anleitungen in Textform helfen.

Formularelemente und ihre Labels

Die meisten Formulare bestehen aus denselben HTML-Formularelementen: einzeiligen Eingabefeldern, mehrzeiligen Textfeldern, Auswahllisten, Radiobuttons, Checkboxen und Buttons zum Absenden oder Abbrechen.

Jedes dieser Formularfelder braucht einen zugänglichen Namen. Screenreader lesen ihn vor, sobald das Feld den Fokus erhält, damit Nutzende wissen, was sie eingeben sollen. Am zuverlässigsten gelingt das mit einem sichtbaren label-Element, das mit seinem Feld verknüpft ist: Das for-Attribut des Labels entspricht der id des Feldes. Erst diese programmatische Verknüpfung macht aus einer sichtbaren Beschriftung eine Information, die assistive Technologien nutzen können.

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

<input type="checkbox" id="newsletter" name="newsletter">
<label for="newsletter">Newsletter erhalten</label>

Bei Textfeldern und Auswahllisten steht das Label vor dem Feld, bei Checkboxen und Radiobuttons dahinter. Ein verknüpftes Label hat einen zweiten Vorteil: Ein Klick darauf aktiviert auch das Feld. Menschen mit motorischen Einschränkungen haben so eine größere Klickfläche.

Zusammengehörige Radiobuttons oder Checkboxen gehören in ein fieldset mit einer legend. Die Legende dient als sichtbare Beschriftung der ganzen Gruppe, und Screenreader lesen sie zusammen mit jeder Option vor.

<fieldset>
  <legend>Bevorzugter Kontaktweg</legend>
  <input type="radio" id="contact-email" name="contact" value="email">
  <label for="contact-email">E-Mail</label>
  <input type="radio" id="contact-phone" name="contact" value="phone">
  <label for="contact-phone">Telefon</label>
</fieldset>

Setze WAI-ARIA-Attribute nur ein, wo natives HTML nicht ausreicht. Das ARIA-Attribut aria-labelledby verweist auf vorhandenen sichtbaren Text, und aria-label gibt einem Element ohne sichtbaren Text einen Namen, zum Beispiel einem Icon-Button. Achte darauf, dass der zugängliche Name das sichtbare Label wörtlich enthält. Sonst erreichen Menschen, die per Sprache steuern und „Klick auf Senden“ sagen, den Button nicht.

Einzeilige und mehrzeilige Eingabefelder

Einzeilige Felder (input) eignen sich für kurze Angaben wie Name oder E-Mail-Adresse. Wähle den passenden type, zum Beispiel email oder tel. Auf Mobilgeräten öffnet sich dann die passende Tastatur. Mehrzeilige Felder (textarea) eignen sich für längere Nachrichten.

html

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

<label for="message">Deine Nachricht</label>
<textarea id="message" name="message" rows="5"></textarea>

Mit dem autocomplete-Attribut können Browser bekannte persönliche Daten automatisch ausfüllen. Das spart Tipparbeit und hilft Menschen mit motorischen Einschränkungen oder Gedächtnisproblemen (WCAG 1.3.5).

Placeholder ersetzen keine Labels

Ein Placeholder kann ein Beispiel für das erwartete Format zeigen, etwa „TT.MM.JJJJ“. Er darf aber nie die einzige Beschriftung sein. Der Placeholder-Text verschwindet, sobald jemand zu tippen beginnt, und damit die Information, um die Eingabe zu prüfen. Außerdem ist er meist hellgrau und erreicht den Mindestkontrast nicht. Formathinweise gehören deshalb ins Label oder in einen Hinweistext unter dem Feld, der mit aria-describedby verknüpft ist.

Pflichtfelder

Kennzeichne Pflichtfelder eindeutig und erkläre die Kennzeichnung am Anfang des Formulars, zum Beispiel: „Mit * markierte Felder sind Pflichtfelder“. Verlass dich nicht auf visuelle Hinweise wie Farbe allein, denn Menschen mit Farbsehschwäche übersehen sie. Ergänze das Attribut required oder bei eigenen Steuerelementen das Attribut aria-required, damit Screenreader das Feld als Pflichtfeld ansagen.

Tastatur, Maus und Sprache: Jede Eingabemethode muss funktionieren

Nicht alle nutzen eine Maus. Menschen mit motorischen Einschränkungen arbeiten oft mit der Tastatur, einem Schaltergerät oder Sprachsteuerung. Blinde Menschen navigieren mit Tastatur und Screenreader. Ein Formular muss deshalb die Tastaturnavigation unterstützen und vollständig ohne Maus bedienbar sein:

• Jedes Feld, jede Option und jeder Button ist mit der Tab-Taste erreichbar, in einer logischen Reihenfolge, die dem visuellen Aufbau folgt.

• Der Fokus ist immer deutlich sichtbar, zum Beispiel durch einen kräftigen Rahmen.

• Eigene Elemente wie gestaltete Dropdowns oder Datumsauswahlen funktionieren mit Pfeiltasten, Enter und Leertaste, genau wie native Elemente.

• Es gibt keine Tastaturfalle: Nutzende kommen aus jedem Feld wieder heraus.

• Klick- und Touch-Flächen sind groß genug, mindestens 24 × 24 Pixel (WCAG 2.5.8). Das ist wichtig für die Bedienung per Touch auf dem Smartphone und für Menschen mit Tremor.

Verzichte auf Tastenkürzel mit nur einer Taste und auf das accesskey-Attribut. Sie kollidieren oft mit Kürzeln von Screenreadern, Browsern und Sprachsteuerungen. Bietest du doch Kürzel an, müssen Nutzende sie abschalten oder ändern können (WCAG 2.1.4).

Kontrast und Schriftgröße

Text und Labels brauchen einen Kontrast von mindestens 4,5:1 zum Hintergrund. Feldrahmen, Fokusanzeigen und Icons, die zum Verständnis nötig sind, brauchen mindestens 3:1. Ein Kontrastprüfer zeigt schnell, ob deine Farben diese Werte erreichen. Wähle eine gut lesbare Schriftgröße und stelle sicher, dass das Formular auch bei 200 % Textgröße oder beim Zoomen funktioniert: Nichts überlappt, nichts wird abgeschnitten, und auf schmalen Bildschirmen ist kein horizontales Scrollen nötig.

Auch ein klares Formularlayout hilft. Gruppiere zusammengehörige Felder, trenne logische Abschnitte visuell und halte den Aufbau vorhersehbar. So können Menschen mit kognitiven Beeinträchtigungen dem Formular Schritt für Schritt folgen.

Hilfe- und Fehlermeldungen

Gute Formulare verhindern Fehler, bevor sie entstehen. Biete kurze Hilfetexte neben dem Feld, einen Tooltip oder einen Link zu einer Hilfeseite an, wenn die erwartete Eingabe nicht offensichtlich ist.

HTML5-Validierungsattribute wie required, type="email" oder pattern fangen viele Fehler automatisch ab. Die Standard-Fehlerhinweise der Browser sind aber nicht zuverlässig barrierefrei. Ergänze deshalb eigene Fehlermeldungen.

Tritt ein Fehler auf, muss die Meldung genau sagen, was falsch ist und wie es sich beheben lässt. Die WCAG nennen das Fehlererkennung und Korrekturvorschlag (WCAG 3.3.1 und 3.3.3). Zeige die Meldung als Text direkt am betroffenen Feld, nicht nur als roten Rahmen, und verknüpfe sie mit aria-describedby. Setze beim Absenden den Fokus auf das erste fehlerhafte Feld oder auf eine Fehlerübersicht oben im Formular.

Einige Beispiele für wenig hilfreiche und hilfreiche Meldungen:

• Formatfehler: Statt „Ungültige Eingabe“ besser „Datum im Format TT.MM.JJJJ eingeben, zum Beispiel 05.03.2026“.

• Wertfehler: Statt „Ungültiges Datum“ besser „Der März hat 31 Tage. Bitte Tag prüfen“.

• Fehlende Pflichtangabe: Statt „Fehler“ besser „E-Mail-Adresse ist erforderlich“.

• Fehlgeschlagener Login: Statt „Login fehlgeschlagen“ besser „E-Mail-Adresse oder Passwort ist falsch. Bitte beides prüfen oder Passwort zurücksetzen“.

Klare, einfache Sprache macht Fehlermeldungen und Hinweise für alle leichter verständlich.

Nur abfragen, was du wirklich brauchst

Jedes zusätzliche Feld ist eine weitere Fehlerquelle. Frag nur die Daten ab, die du wirklich brauchst, und keine Informationen, die dir schon vorliegen. Die WCAG 2.2 machen das ausdrücklich: Angaben, die Nutzende im selben Prozess bereits gemacht haben, müssen automatisch übernommen oder zur Auswahl angeboten werden (WCAG 3.3.7).

Zeige bedingte Felder nur, wenn sie relevant sind. Wählt jemand „keine Kinder“ aus, sollte das Feld für das Alter der Kinder gar nicht erst erscheinen.

Zwischenspeichern ermöglichen

Lange und mehrseitige Formulare wie Anträge oder Steuererklärungen brauchen Zeit. Zeige an, in welchem Schritt sich Nutzende befinden und wie viele Schritte noch folgen. Ermögliche es, Eingaben zu speichern und später weiterzumachen, und lösche nie bereits eingegebene Daten, wenn ein Fehler auftritt oder eine Sitzung endet. Bei Formularen mit rechtlichen oder finanziellen Folgen müssen Nutzende ihre Angaben vor dem endgültigen Absenden prüfen, korrigieren oder zurückziehen können (WCAG 3.3.4).

Login, CAPTCHAs und Zeitlimits

Ein Login sollte kein Gedächtnistest und kein Rätsel sein. Die WCAG 2.2 haben genau dafür ein Kriterium eingeführt: Nutzende dürfen sich zum Anmelden nichts merken, abschreiben oder ausrechnen müssen, es sei denn, es gibt eine Alternative (WCAG 3.3.8).

In der Praxis heißt das:

• Einfügen in Passwortfelder erlauben und Passwortmanager unterstützen. Die Zwischenablage nie blockieren.

• Alternativen zum Passwort anbieten, etwa Passkeys, Login-Links per E-Mail oder Zwei-Faktor-Authentifizierung per App.

• CAPTCHAs vermeiden, bei denen verzerrte Buchstaben entziffert oder Aufgaben gelöst werden müssen. Sie sind eine Barriere für Menschen mit Lernschwierigkeiten und kognitiven Beeinträchtigungen, und Bild-CAPTCHAs schließen blinde Menschen aus. Eine Audioversion allein löst das nicht, denn sie schließt taubblinde Menschen aus. Unsichtbarer, verhaltensbasierter Bot-Schutz oder ein Honeypot-Feld ist die bessere Wahl.

Zeitlimits setzen viele Menschen unter Druck, zum Beispiel Screenreader-Nutzende, Menschen mit motorischen Einschränkungen oder alle, die langsamer lesen. Login-Codes, die nach 30 oder 60 Sekunden ablaufen, sind ein typisches Beispiel. Lässt sich ein Zeitlimit nicht vermeiden, müssen Nutzende es abschalten, anpassen oder verlängern können, und sie müssen vor Ablauf gewarnt werden (WCAG 2.2.1).

Video und Audio in Formularen

Manche Formulare erklären Schritte in einem Video oder enthalten eine Audionachricht. Videos brauchen Untertitel, Audioinhalte ein Transkript (WCAG 1.2.1 und 1.2.2). Noch besser: Die wichtigsten Anweisungen zusätzlich als Text direkt ins Formular schreiben, damit niemand auf die Medien angewiesen ist.

Checkliste: Barrierefreie Formulare auf einen Blick

Die passenden WCAG-Erfolgskriterien (Version 2.2) stehen in Klammern.

• Jedes Feld hat ein sichtbares, verknüpftes Label (1.3.1, 2.4.6, 3.3.2)

• Zusammengehörige Optionen sind mit fieldset und legend gruppiert (1.3.1)

• Felder für persönliche Daten nutzen autocomplete (1.3.5)

• Textkontrast mindestens 4,5:1, Feldrahmen und Fokus mindestens 3:1 (1.4.3, 1.4.11)

• Das Formular funktioniert bei 200 % Textgröße und auf kleinen Bildschirmen (1.4.4, 1.4.10)

• Alles ist per Tastatur bedienbar, mit sichtbarem Fokus (2.1.1, 2.4.7)

• Keine Tastenkürzel mit nur einer Taste, oder sie lassen sich abschalten (2.1.4)

• Zeitlimits lassen sich abschalten, anpassen oder verlängern (2.2.1)

• Klickflächen sind mindestens 24 × 24 Pixel groß (2.5.8)

• Der zugängliche Name enthält das sichtbare Label (2.5.3)

• Pflichtfelder werden angesagt und nicht nur farblich markiert (1.4.1, 3.3.2)

• Fehlermeldungen sind konkret und schlagen eine Lösung vor (3.3.1, 3.3.3)

• Wichtige Angaben lassen sich vor dem Absenden prüfen und korrigieren (3.3.4)

• Bereits eingegebene Daten werden nicht erneut abgefragt (3.3.7)

• Der Login funktioniert ohne Gedächtnistest oder Rätsel (3.3.8)

• Videos haben Untertitel, Audio hat ein Transkript (1.2.1, 1.2.2)

Alle Kriterien findest du in den Web Content Accessibility Guidelines (WCAG) 2.2.

Fazit

Barrierefreie Formulare sind keine Sonderfunktion. Sie sorgen dafür, dass ein Formular für alle funktioniert. Klare Labels, eine logische Struktur, vollständige Tastaturbedienbarkeit, hilfreiche Fehlermeldungen und faire Login-Verfahren ermöglichen es Menschen mit Behinderungen, älteren Menschen und Menschen mit vorübergehenden Einschränkungen, Formulare selbstständig auszufüllen. Gleichzeitig werden Formulare für alle anderen schneller und weniger fehleranfällig. Für Unternehmen bedeutet jedes abgebrochene Formular verlorene Conversions – ein versteckter Kostenfaktor einer nicht barrierefreien Website.

Wie barrierefrei sind die Formulare auf eurer Website? Starte einen kostenlosen Barrierefreiheitscheck mit Eye-Able und erhalte dein Ergebnis in weniger als 2 Minuten, oder sprich mit unseren Experten und Expertinnen für Barrierefreiheit.

FAQ: Barrierefreie Formulare

Was macht ein Onlineformular barrierefrei?

Ein barrierefreies Formular können alle ausfüllen, auch Menschen, die assistive Technologien nutzen, ältere Menschen und Menschen mit vorübergehenden Einschränkungen. Entscheidend sind sichtbare, verknüpfte Labels für jedes Feld, vollständige Tastaturbedienbarkeit, ausreichender Kontrast, klare Fehlermeldungen sowie kein Zeitdruck und keine Rätsel beim Login.

Welche WCAG-Kriterien gelten für Formulare?

Die wichtigsten sind 1.3.1 (Info und Beziehungen), 2.1.1 (Tastatur), 3.3.1 (Fehlererkennung), 3.3.2 (Beschriftungen oder Anweisungen) und 3.3.3 (Korrekturvorschlag). Mit WCAG 2.2 kamen 3.3.7 (Redundante Eingaben) und 3.3.8 (Barrierefreie Authentifizierung) hinzu, die ebenfalls direkt Formulare betreffen.

Reicht ein Placeholder als Beschriftung?

Nein. Der Placeholder-Text verschwindet, sobald jemand tippt, und hat meist zu wenig Kontrast. Nutze für jedes Feld ein sichtbares label-Element und den Placeholder höchstens als zusätzlichen Hinweis.

Brauche ich ARIA-Attribute für barrierefreie Formulare?

Meist nicht. Native HTML-Formularelemente mit verknüpftem label-Element sind bereits barrierefrei. ARIA-Attribute wie aria-describedby oder aria-required sind nützlich, um Hinweistexte und Fehlermeldungen zu verknüpfen, und für eigene Steuerelemente, die HTML nicht bietet.

Sind CAPTCHAs barrierefrei?

Die meisten nicht. Bild- und Texträtsel schließen blinde Menschen und Menschen mit kognitiven Beeinträchtigungen aus, Audio-CAPTCHAs schließen taubblinde Menschen aus. Unsichtbarer, verhaltensbasierter Bot-Schutz oder ein Honeypot-Feld schützt Formulare, ohne Nutzende zu testen.

Sind barrierefreie Formulare gesetzlich vorgeschrieben?

In vielen Fällen ja. In Deutschland setzt das Barrierefreiheitsstärkungsgesetz (BFSG) den European Accessibility Act um. Es gilt seit dem 28.06.2025 für viele digitale Produkte und Dienstleistungen, etwa Onlineshops und Bankdienstleistungen. Für öffentliche Stellen gilt die BITV 2.0. Technische Grundlage ist die europäische Norm EN 301 549, die auf die WCAG verweist. Außerhalb der EU gelten ähnliche Regeln, etwa der Equality Act 2010 im Vereinigten Königreich und der Americans with Disabilities Act in den USA.

Wie prüfe ich, ob meine Formulare barrierefrei sind?

Beginne mit drei schnellen Tests: Fülle das Formular nur mit der Tastatur aus, zoome die Seite auf 200 % und probiere das Formular mit einem kostenlosen Screenreader wie NVDA aus. Ein automatischer Barrierefreiheitscheck findet viele technische Probleme wie fehlende Labels oder zu geringen Kontrast. Ein manuelles Audit durch Fachleute für Barrierefreiheit deckt ab, was Tools nicht beurteilen können, zum Beispiel ob Fehlermeldungen wirklich hilfreich sind.