Barrierefreie Formulare: Struktur, Logik und die einzelnen Elemente

Ein Label ist die Beschriftung eines Eingabefelds. Es muss programmatisch mit dem Feld verbunden sein – nicht nur räumlich daneben. Diese Verknüpfung passiert über das for -Attribut am Label, das auf die id des Felds zeigt. Alternativ kannst du das Feld in das Label hineinstecken – auch das verknüpft beide.

Wer ein Feld per Screenreader erreicht, hört dann den Label-Text vorgelesen und weiß, was einzutragen ist. Wer das Label per Mausklick antippt, springt automatisch ins Feld – das vergrößert die Klickfläche und hilft besonders Menschen mit motorischen Einschränkungen.

HTML kennt eine ganze Reihe von Eingabe-Typen jenseits des reinen Text-Felds: email , tel , url , date , number . Diese Typen tun zwei Dinge gleichzeitig: Sie signalisieren dem Browser eine Validierung, und sie sorgen auf Smartphones für die passende Bildschirm-Tastatur (Zahlen, E-Mail-Layout, Datums-Picker).

Ergänzend hilft das autocomplete -Attribut. Es verrät dem Browser und assistiven Technologien, welche Bedeutung ein Feld hat – etwa given-name , family-name , postal-code oder tel . Das ist nicht nur Komfort, sondern ein WCAG-AA-Kriterium (1.3.5).

Welche Felder ausgefüllt werden müssen, muss sichtbar und für Screenreader hörbar sein. Im HTML setzt du dazu das required -Attribut – damit erfährt der Screenreader, dass das Feld Pflicht ist, und der Browser blockiert das Absenden bei leeren Pflichtfeldern.

Visuell wird Pflicht meist mit einem Sternchen markiert. Wichtig: Das Sternchen am Label sollte für Screenreader ausgeblendet sein ( aria-hidden="true" ), weil required die Information bereits transportiert – sonst hörst du an jedem Pflichtfeld doppelt „Stern erforderlich". Ergänzend sollte irgendwo am Anfang des Formulars stehen, was das Sternchen bedeutet.

Hinweise zu einem Feld – etwa „Bitte mit Vorwahl angeben", „Mindestens acht Zeichen" – müssen mit dem Feld verknüpft sein. Sonst hören Screenreader-Nutzer:innen den Hinweis nicht oder erst nach dem Feld, wenn es zu spät ist.

Das Standardwerkzeug dafür ist aria-describedby am Eingabefeld. Das Attribut bekommt die id des Hinweis-Elements als Wert. Beim Fokussieren des Felds liest der Screenreader Label und Hinweis nacheinander vor. Das funktioniert gleich gut für Hilfstexte und für Fehlermeldungen.

Wenn mehrere Felder logisch zusammengehören – etwa eine Adresse, eine Gruppe von Radio-Buttons, eine Reihe von Checkboxen – fasse sie mit <fieldset> zusammen und gib der Gruppe mit <legend> eine Überschrift.

Das ist besonders wichtig bei Radio-Buttons und Checkbox-Gruppen, weil einzelne Labels nicht reichen: Eine Radio-Frage wie „Versandart" muss sowohl mit den Optionen verbunden sein (Express, Standard, Abholung) als auch als Gesamtfrage erkennbar. Genau das leistet Legend in Verbindung mit dem umgebenden Fieldset.

Drei native Bausteine, drei klare Einsatzbereiche: Radio-Buttons für eine Auswahl aus mehreren sich ausschließenden Optionen. Checkboxen für unabhängige Ja/Nein-Entscheidungen oder Mehrfachauswahl. Select-Listen für längere Listen, in denen eine Option ausgewählt wird.

Die Faustregel: Bevorzuge native HTML-Elemente. Eigene Selects, die per JavaScript aus <div> -Konstruktionen nachgebaut werden, müssen sehr sorgfältig zugänglich gemacht werden – inklusive Tastatur-Navigation, ARIA-Rollen, Fokus-Management. Das gelingt selten gut. Die native Variante erfüllt diese Anforderungen ohne Zusatzaufwand.

Der Absende-Button braucht eine Beschriftung, die die Aktion beschreibt. „Absenden" geht, „Nachricht senden" ist besser, „Termin verbindlich buchen" ist am klarsten. Vermeide nichtssagende Beschriftungen wie „OK" oder „Weiter" – sie verraten der Person nicht, was passieren wird, und werden außerhalb des Kontexts unverständlich.

Technisch nutze ein echtes <button type="submit"> oder <input type="submit"> . Beide sind nativ tastaturbedienbar, werden von Screenreadern als Schaltflächen angekündigt und übernehmen das Absende-Verhalten automatisch. Ein gestyltes <div> mit Klick-Handler kann das alles nicht.

Wenn ein Feld nicht korrekt ausgefüllt ist, muss die Fehlermeldung drei Dinge leisten: Sie muss auffallen, sie muss verständlich erklären, was zu korrigieren ist, und sie muss mit dem Feld verknüpft sein, damit Screenreader-Nutzer:innen sie hören.

Die technische Verknüpfung läuft über zwei Attribute am Eingabefeld: aria-invalid="true" signalisiert „dieses Feld ist gerade fehlerhaft", und aria-describedby verweist auf die id des Fehlermeldungs-Elements. Sobald die Person das Feld fokussiert, liest der Screenreader Label und Fehlertext nacheinander vor. Wichtig: Setze aria-invalid erst nach der Validierung, nicht von Anfang an – sonst hörst du beim ersten Tab durch das leere Formular „ungültig, ungültig, ungültig".

Visuell sollte die Fehlermeldung nicht ausschließlich farblich markiert sein. Ein farbiger Rahmen am Feld in Kombination mit einem Icon und Klartext ist eine zuverlässige Lösung – sie funktioniert auch für Menschen mit Farbsehschwäche.