Formulare in HTML: Live-Beispiele zum Anfassen

Label und Input: Die Grundverbindung

Jedes Eingabefeld braucht ein zugehöriges <label>. Screenreader lesen das Label automatisch vor, sobald das Feld den Fokus bekommt. Außerdem wird das Eingabefeld fokussiert, wenn jemand auf das Label klickt – das hilft besonders bei kleinen Bedienelementen wie Checkboxen.

Es gibt zwei gleichwertige Varianten, Label und Input zu verbinden: explizit über for und id , oder implizit, indem das Input im Label verschachtelt wird. Die explizite Variante ist robuster und wird in der Praxis empfohlen.

Explizit verknüpft mit for und id

Implizit verschachtelt

Mehrzeilige Texteingabe

Für längere Eingaben gibt es <textarea> . Die Verknüpfung mit dem Label funktioniert genau wie bei <input> .

Wichtig: Nutze rows für die Anfangsgröße, aber lass die Höhe über CSS ( resize: vertical ) frei skalierbar – Nutzer:innen sollen die Größe an ihren Bedarf anpassen können.

Checkboxen mit Fieldset und Legend

Gruppen zusammengehöriger Eingaben werden mit <fieldset> eingerahmt, die Beschreibung der Gruppe steht im <legend> . Screenreader lesen die Legende vor, bevor sie die einzelnen Optionen ansagen – so wissen Nutzer:innen, was die Optionen bedeuten.

Radio-Buttons

Radio-Buttons funktionieren wie Checkboxen, aber es kann immer nur eine Option ausgewählt sein. Sie werden über das gleiche name -Attribut zu einer Gruppe verbunden.

Drop-down-Menü mit optionalen Gruppen

Das <select> -Element ist der Standard für Auswahl-Listen. Mit <optgroup> können verwandte Optionen logisch zusammengefasst werden – das macht lange Listen schneller verständlich.

Custom-Selects (z. B. aus React-Libraries) sind oft schöner gestylt, aber meist nicht so zugänglich wie das native Element. Wenn keine besonderen Anforderungen vorliegen: Native <select> bevorzugen.

Spezielle Input-Typen

HTML5 kennt eine Reihe von Input-Typen, die Browsern und Hilfstechnologien mehr Kontext geben – etwa welche Bildschirmtastatur auf Smartphones angezeigt werden soll oder welche Validierung der Browser ausführen darf.

E-Mail

Telefonnummer

Datum

Zahlen

Datei-Upload

Für Datei-Uploads gibt es <input type="file"> . Mit dem Attribut accept lässt sich einschränken, welche Dateitypen zugelassen sind; multiple erlaubt die Auswahl mehrerer Dateien gleichzeitig.

Wer das native Aussehen ändern möchte, sollte das Input visuell verstecken (nicht mit display: none , sondern mit der „visually-hidden"- Technik) und ein Label so stylen, dass es wie ein Button aussieht – damit bleibt die Tastaturbedienbarkeit erhalten.

Pflichtfelder kennzeichnen

Mit dem Attribut required wird ein Feld als Pflichtfeld markiert. Screenreader lesen das automatisch vor („Pflichtfeld" oder „erforderlich"), und der Browser verhindert das Abschicken eines Formulars mit leeren Pflichtfeldern.

Für sehende Nutzer:innen muss zusätzlich sichtbar gekennzeichnet sein, dass das Feld Pflicht ist – sonst sehen sie die Markierung erst beim Fehler. Üblich ist ein Sternchen direkt am Label.

Fehlermeldungen barrierefrei verknüpfen

Wenn ein Feld einen Fehler enthält, müssen drei Dinge zusammenspielen: eine visuelle Markierung, ein textlicher Hinweis und die maschinelle Verknüpfung von Feld und Hinweis. Dafür gibt es zwei wichtige Attribute: aria-invalid und aria-describedby .

aria-invalid="true" teilt Screenreadern mit, dass das Feld einen Fehler hat. aria-describedby verknüpft das Feld mit der ID des Fehlertexts – beim Fokussieren des Feldes liest der Screenreader Label, Wert und Fehlermeldung in dieser Reihenfolge vor.

Eine ausführliche Behandlung von Fehlermeldungen, Fehler-Zusammenfassungen am Formular-Anfang und Live-Regions findest du auf der Seite Barrierefreie Formulare.

Autocomplete: Hilfe für die Eingabe

Das autocomplete -Attribut sagt dem Browser, welche Art von Daten in ein Feld gehört. Browser können dann passende Werte aus dem Profil oder Adressbuch vorschlagen – das spart Tipparbeit und ist ein wichtiges WCAG-Kriterium (Erfolgskriterium 1.3.5: Identify Input Purpose).

Die häufigsten Autocomplete-Tokens für deutsche Formulare:

• name , given-name , family-name
• email , tel
• street-address , postal-code , address-level2 (Ort), country
• bday (Geburtsdatum), organization
• username , current-password , new-password (für Logins und Passwort-Manager)

Häufige Stolperfallen

Placeholder ersetzt kein Label

Ein häufiger Designtrend: Schmale Formulare ohne sichtbare Labels, dafür mit Placeholder-Text im Feld. Das ist gleich mehrfach problematisch:

• Sobald getippt wird, ist der Hinweis weg – Nutzer:innen können nicht mehr nachschauen, was im Feld gefordert war.
• Placeholder-Text hat oft schlechten Kontrast und ist für sehbehinderte Menschen schwer lesbar.
• Screenreader-Unterstützung für Placeholder ist inkonsistent.
• Beim erneuten Editieren eines vorausgefüllten Felds verschwindet der Kontext komplett.

Placeholder sind sinnvoll für Format-Beispiele(z. B. „DD.MM.JJJJ" in einem Datumsfeld), nicht als Ersatz für ein Label.

Custom-Selects und Custom-Checkboxen

Stylish gestaltete Custom-Komponenten aus JavaScript-Frameworks sind oft nicht so zugänglich wie native HTML-Elemente. Wenn das native Element reicht: Native verwenden. Wenn nicht, gibt es geprüfte Patterns vom W3C-WAI – siehe Verweise unten.

Layout statt Semantik

Ein häufiger Fehler: Eine Gruppe von Optionen wird mit <div> -Elementen und einer Überschrift „designt", statt mit <fieldset> und <legend> . Optisch sieht das gleich aus, semantisch fehlt der Gruppenkontext.

Submit-Button ohne sichtbares Label

Ein Button mit nur einem Icon (etwa nur „→") braucht einen Alternativtext – entweder als sichtbares Label oder über aria-label . Screenreader-Nutzer:innen wissen sonst nicht, welche Aktion der Button auslöst.

Fehlermeldungen nur in Rot

Ein roter Rand allein ist keine Fehlermeldung. Es braucht eine textliche Erklärung dessen, was falsch ist und wie es korrigiert werden kann. Farbe ist nur eine zusätzliche, optische Hilfe.