Barrierefreie Formulare: Labels, Fehler und Struktur

Jedes Eingabefeld braucht ein Label. Das klingt selbstverständlich – ist es in der Praxis aber nicht. Die häufigsten Fehler:

Placeholder statt Label: Ein Placeholder verschwindet beim Tippen. Nutzende vergessen, was sie eingeben sollen. Nutzende mit kognitiven Einschränkungen haben keine Chance, das Feld nachträglich zuzuordnen. Und Screenreader kündigen Placeholder-Text manchmal gar nicht an. Labels ersetzen.

Visuelles Label, keine Verknüpfung: Ein Text über einem Feld, der optisch wie ein Label aussieht, aber nicht programmatisch verknüpft ist. Aus Screenreader-Sicht ist es nur Text. Lösung:

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

Oder alternativ das Input direkt in das Label einbetten. Beides ist valide.

Das Sternchen (*) ist eine Konvention, die viele kennen – aber nicht alle. Und das Sternchen selbst wird von Screenreadern oft als "Sternchen" vorgelesen, nicht als "Pflichtfeld".

Best Practice: Das Sternchen visuell anzeigen, aber zusätzlich aria-required="true" oder das native required-Attribut setzen. Und am Anfang des Formulars erklären, was das Sternchen bedeutet. Alternativ kann man auch alle optionalen Felder als "optional" kennzeichnen – das ist oft verständlicher als das Gegenteil.

Wenn ein Formular nicht valide abgesendet wird, muss die Fehlermeldung drei Kriterien erfüllen (WCAG 3.3.1):

1. Identifizieren: Welches Feld hat den Fehler? Nicht nur "Bitte prüfen Sie Ihre Eingaben" – sondern genau das Feld benennen.

2. Beschreiben: Was genau ist falsch? "Ungültige E-Mail-Adresse" ist besser als "Fehler". "Passwort muss mindestens 8 Zeichen haben" ist besser als "Passwort ungültig".

3. Erreichbar: Der Fokus muss nach dem Absenden auf die Fehlermeldung oder das erste fehlerhafte Feld wandern. Eine Fehlermeldung, die am Seitenanfang erscheint und den Fokus nicht erhält, ist für Tastatur- und Screenreader-Nutzende unsichtbar.

Zusammengehörige Felder – etwa Radiobuttons für eine Frage, eine Adressgruppe oder Checkboxen für eine Auswahl – gehören in ein <fieldset> mit einem <legend>. Screenreader lesen die Legende jedem Feld der Gruppe vor, bevor der Feldname kommt.

Schlechtes Beispiel: Drei Radiobuttons "Ja", "Nein", "Vielleicht" ohne fieldset. Screenreader sagt: "Ja, Radio-Button". Was ist die Frage? Unklar.

Gutes Beispiel: fieldset mit legend "Möchten Sie den Newsletter abonnieren?". Screenreader sagt: "Möchten Sie den Newsletter abonnieren? Ja, Radio-Button."

Das autocomplete-Attribut teilt dem Browser mit, welcher Typ von Information in einem Feld erwartet wird. Damit kann der Browser gespeicherte Daten anbieten – ein enormer Vorteil für Menschen mit motorischen Einschränkungen oder kognitiven Behinderungen, die sich Daten nicht merken können.

WCAG 1.3.5 (AA) verlangt autocomplete-Attribute für alle Felder, die persönliche Daten erfassen: Name, Adresse, E-Mail, Telefonnummer, Zahlungsinformationen. Die vollständige Liste der gültigen Werte findet sich in der WCAG-Dokumentation.

Beispiel: <input type="text" autocomplete="given-name"> für den Vornamen, autocomplete="email" für die E-Mail-Adresse.