1 von 4 erwachsenen Amerikanern lebt mit einer Form von Behinderung. Ist dein Formular nicht barrierefrei, schneidest du ein Viertel deiner möglichen Zielgruppe ab, bevor sie die Absende-Schaltfläche erreicht.
Ein barrierefreies Formular funktioniert für alle. Das gilt für Nutzer, die nur die Tastatur verwenden. Für Menschen, die per Screenreader zuhören. Für Nutzer mit eingeschränktem Sehvermögen. Für Menschen mit Tremor, die mehr Zeit zum Ausfüllen der Felder brauchen. Kein spezielles Design, keine zusätzliche Komplexität. Nur ein Formular, das so gebaut ist, dass all diese Menschen es wirklich nutzen können.
Klare Labels. Tastaturbedienung. Fehlermeldungen, die ein Screenreader vorlesen kann. Genug Kontrast, damit Nutzer mit eingeschränktem Sehvermögen den Text lesen können. Das sind keine Zusatzfunktionen. Es ist die Grundlage, die WCAG 2.1 AA und der Americans with Disabilities Act ab April 2026 verlangen.
Was barrierefreie Formulare anders macht
Nimm ein beliebiges Kontaktformular, und du findest dieselben Fehler. Ein Textfeld mit Platzhalter, aber ohne sichtbares Label. Ein Kontrollkästchen ohne Erklärung, was es bewirkt. Eine Fehlermeldung in rotem Text, die ein Screenreader nicht vorlesen kann.
Die meisten Formulare sind für Maus-Nutzer gebaut, und Barrierefreiheit wird später nachträglich drangeklebt. Ein barrierefreies Formular geht umgekehrt vor. Es geht von Anfang an davon aus, dass Menschen es auf verschiedene Arten nutzen. Manche mit der Maus, manche nur mit der Tastatur. Manche lesen es, manche hören es über einen Screenreader.
Das verändert, wie du das Formular baust. Platzhalter sind ohne Labels nutzlos. Rote Sternchen sind ohne Text nutzlos. Ein visuelles Layout, das für Maus-Nutzer funktioniert, kann Tastatur-Nutzer in eine Falle locken. Ein barrierefreies Formular ist nicht schwerer zu bauen. Du musst nur über Bedienmuster jenseits der Maus nachdenken.
Warum das wichtig ist
Gesetzliche Frist. Titel II des ADA verlangt WCAG 2.1 AA bis zum 24. April 2026. Nichteinhaltung ist kein Risiko mehr. Sie ist eine aktuelle Haftung.
Geschäftlicher Nutzen. Besucher mit Behinderungen geben echtes Geld aus. Ein barrierefreies Formular erhöht die Abschlussraten bei allen, weil klare Labels allen Nutzern helfen, nicht nur Menschen mit Behinderungen. Beschäftigten Nutzern, die um 6 Uhr morgens auf dem Handy überfliegen. Power-Usern, die per Tastatur navigieren. Allen.
SEO-Vorteil. Suchmaschinen bevorzugen Seiten, deren interaktive Elemente beschriftet und per Tastatur bedienbar sind. Barrierefreie Formulare ranken höher.
Was barrierefreie Formulare wirklich brauchen
Sichtbare Labels an jedem Feld
Jedes Eingabefeld braucht ein Label. Keinen Platzhalter, der verschwindet. Kein title-Attribut. Ein echtes Label, das direkt auf der Seite steht.
Ein Screenreader liest zuerst das Label vor und gibt dann den Feldtyp an. "Name, Texteingabe." Der Nutzer weiss, was zu tun ist. Ohne Label hörst du nur "Texteingabe" und sonst nichts. Der Nutzer hat keine Ahnung, was er eingeben soll.
Für sehende Nutzer funktionieren Labels wie auf Papier. Sie sagen dir, was in jede Lücke gehört. Sie vergrössern auch die klickbare Fläche. Verknüpfe das Label mit dem Eingabefeld über das Attribut for, und Nutzer können entweder auf das Label oder auf das Feld klicken, um es zu fokussieren. Auf dem Handy ist diese grössere Klickfläche wichtig.
Nur mit der Tastatur bedienbar
Viele Menschen fassen nie eine Maus an. Motorische Einschränkungen, eingeschränktes Sehvermögen, Screenreader. Diese Nutzer navigieren komplett mit der Tastatur. Braucht dein Formular eine Maus, ist es nicht barrierefrei.
Teste es. Zieh die Maus ab. Gehe nur mit der Tab-Taste, den Pfeiltasten und der Eingabetaste durch das Formular. Du solltest jedes Feld erreichen, jede Option wählen und auf Absenden drücken können, ohne die Hände zu bewegen.
Die Fokusmarkierung muss bei jedem Schritt sichtbar sein. Keine unsichtbaren Fokuszustände. Nutzer müssen wissen, wo sie im Formular sind. Auch die Tab-Reihenfolge ist wichtig. Felder sollten von links nach rechts und von oben nach unten laufen, so wie das Formular gelesen wird. Springt dein Layout herum oder versteckt Felder, bricht die Tab-Reihenfolge, und Tastatur-Nutzer stecken fest.
Fehlermeldungen, die sich wirklich bemerkbar machen
Roter Text am Anfang des Formulars bedeutet einem Screenreader-Nutzer nichts. Er schickt ab, hört Stille und versucht es erneut. Dann gibt er auf.
Verknüpfe den Fehler mit dem konkreten Feld, in dem er aufgetreten ist. Springt ein Screenreader-Nutzer per Tab in dieses Feld, wird der Fehler vorgelesen. Und formuliere die Fehlermeldung so, dass sie sagt, was zu beheben ist, nicht nur "Ungültig". Statt "Ungültige Eingabe" schreibe "Die E-Mail muss ein @-Zeichen enthalten."
Nutze ARIA-Attribute wie aria-describedby, um die Fehlermeldung mit dem Feld zu verbinden. Landet der Fokus auf dem Feld, liest der Screenreader den Fehler automatisch vor. Kein Raten.
Text für Nutzer mit eingeschränktem Sehvermögen lesbar machen
Hellgraue Labels auf weissem Hintergrund sind für jemanden mit eingeschränktem Sehvermögen unsichtbar. WCAG 2.1 AA verlangt für normalen Text ein Kontrastverhältnis von 4,5:1. Dunkler Text auf hellem Hintergrund oder heller Text auf dunklem Hintergrund. Der Kontrast muss deutlich sein.
Grösserer Text (ab 18 Punkt) darf einen Kontrast von 3:1 haben. Alles andere braucht 4,5:1. Ein Kontrastprüfer braucht 5 Sekunden. Prüfe jedes Label, jede Schaltfläche und jede Fehlermeldung vor dem Livegang damit.
Nutze Farbe nie allein, um Pflichtfelder zu kennzeichnen. Ein rotes Sternchen bedeutet einem farbenblinden Nutzer nichts. Setze das Wort "Pflichtfeld" neben das Feld. Screenreader lesen es vor. Sehende Nutzer sehen es. Text versteht jeder.
Hinweise für barrierefreie Formulare, Feld für Feld
Texteingaben und Textbereiche
Name, E-Mail, Telefon: alle brauchen ein Label direkt darüber oder daneben. Nutze das HTML-Element <label> mit einem Attribut for, das zur id des Eingabefelds passt.
Erwartet das Feld ein bestimmtes Format, sag es. "Format: 555-123-4567" hilft allen, besonders Menschen, die mit klaren Anweisungen besser zurechtkommen.
Textbereiche sollten so aussehen, als nähmen sie längere Antworten an. Ein einzeiliges Feld mit dem Label "Nachricht" wirkt wie eine kurze Antwort. Ein höheres Feld signalisiert "gib mir mehr". Die Grösse zählt.
Auswahllisten und Optionsfelder
Jede Auswahlliste braucht ein Label. "Wähle eine Option" und "Ja/Nein" ohne Kontext sind nutzlos. Ein Screenreader-Nutzer hat keine Ahnung, welche Frage du stellst. Mach im Label der Auswahlliste klar, um welche Wahl es geht.
Optionsfelder gehören in ein Fieldset mit einer Legende. Die Legende stellt die Frage. Die Optionen beantworten sie. "Was beschreibt deinen Anwendungsfall am besten?" mit Optionen wie "E-Commerce", "Medien", "SaaS". Ein Screenreader liest die Legende vor, dann jede Option. Der Nutzer versteht, dass er aus einer Gruppe wählt und wofür die Gruppe steht.
Kontrollkästchen
Das Label eines Kontrollkästchens sollte sich natürlich lesen. "Ich stimme den Nutzungsbedingungen zu" als Label, mit dem Kästchen daneben. Kein nacktes Kästchen ohne Text, bei dem Nutzer raten müssen, was es bewirkt.
Gibt es ergänzende Informationen, etwa einen Link zu den vollständigen Bedingungen, setze sie direkt neben das Kontrollkästchen. Verstecke sie nicht. Nutzer müssen wissen, wem sie zustimmen, bevor sie das Kästchen anhaken.
Gruppen von Kontrollkästchen funktionieren wie Gruppen von Optionsfeldern. Eine Legende benennt die Gruppe, und jede Option bekommt ihr eigenes Label.
Schaltflächen
Der Text einer Schaltfläche sollte sagen, was passiert. "Absenden." "Senden." "OK" passt für Bestätigungen. "Los" nicht. Keine allgemeinen Beschriftungen.
Hast du mehrere Schaltflächen, mach sie unterscheidbar. "Abbrechen" und "Absenden" sind klar. Zwei Schaltflächen, die beide "Weiter" heissen, sind es nicht: Ein Screenreader-Nutzer hört "Weiter-Schaltfläche, Weiter-Schaltfläche" und weiss nicht, welche welche ist.
Wo Formulare auf deiner Website stehen
Kontaktformulare in Pop-ups. Newsletter-Anmeldungen in Footern. Spendenformulare auf Seiten über deine Mission. Umfrageformulare im Checkout. Jedes Formular, überall, muss barrierefrei sein.
Pop-up-Formulare erzeugen eine Fokusfalle, wenn du sie nicht steuerst. Öffnet sich ein Modal, springt der Fokus hinein. Schliesst es sich, springt der Fokus zurück zur Schaltfläche, die es geöffnet hat. Ohne das bleiben Tastatur-Nutzer im Hintergrund der Seite hängen.
Füge bei langen Seiten mit Formularen weiter unten einen Sprunglink ein. Tastatur-Nutzer sollten nicht durch 50 Navigationspunkte tabben müssen, um dein Formular zu erreichen.
Häufige Fehler
Platzhaltertext statt Labels nutzen
Ein Platzhalter mit "Gib deine E-Mail ein" verschwindet, sobald jemand zu tippen beginnt. Jetzt hat der Nutzer keine Ahnung mehr, wofür das Feld war. Screenreader sehen ihn gar nicht.
Nutze ein echtes Label. Willst du einen Platzhalter für Formathinweise, ist das in Ordnung. Aber nutze ihn nie als Label selbst.
Farbe allein für Pflichtfelder nutzen
Ein rotes Sternchen ist für farbenblinde Nutzer unsichtbar. Ein Symbol ist für Screenreader unsichtbar. Nutze das Wort "Pflichtfeld" als Text. Text versteht jeder.
Manuelle Tests überspringen
Die richtige HTML-Struktur auf dem Papier heisst nicht, dass dein Formular in der Praxis funktioniert. Labels können zu weit von den Eingabefeldern entfernt sitzen. Fokusmarkierungen können unsichtbar sein. Fehlermeldungen werden vielleicht vorgelesen, bewegen den Fokus aber nicht zum Feld.
Teste mit der Tastatur. Teste mit einem Screenreader. Es gibt kostenlose Screenreader, die Standard-Software ist kostenpflichtig, und auf iOS ist einer eingebaut. Automatische Prüfer finden die offensichtlichen Probleme. Echte Tests finden den Rest.
Zeitlimits einbauen
Ein Nutzer mit Tremor tippt langsam. Ein Screenreader-Nutzer braucht Zeit, um alle Labels und Anweisungen anzuhören. Ein Limit von 5 Minuten sperrt Nutzer aus, die 10 brauchen.
Entferne Zeitlimits, wenn du kannst. Musst du sie haben, lass Nutzer die Zeit zweimal verlängern, bevor die Sitzung endet.
Wie WEMASY barrierefreie Formulare baut
WEMASY-Formulare sind von Anfang an barrierefrei gebaut, nicht erst nachträglich. Jede Vorlage enthält passende Labels. Der Fokus wird automatisch gesteuert. Fehler werden Screenreadern angesagt. Der Farbkontrast erfüllt standardmässig WCAG 2.1 AA.
Passe an, ohne die Barrierefreiheit zu zerstören. Füge Felder hinzu, ändere Labels, ordne das Layout um. Die zugrunde liegende Struktur bleibt barrierefrei. Die eingebaute Validierung sagt Fehler an Screenreader an.
Mehr dazu findest du in unserem vollständigen Leitfaden zu Formularen, oder sieh dir an, was in jedem WEMASY-Tarif enthalten ist.