Wird geladen…
Barrierefreie Formulare: Labels, Fehler und Struktur
Formulare sind der Ort, an dem Barrierefreiheit am häufigsten scheitert. Fehlende Labels, unverständliche Fehlermeldungen, falsche Tastaturnavigation – das sind keine seltenen Ausnahmen, sondern die Regel. Gleichzeitig sind Formulare der Bereich, in dem WCAG am präzisesten formuliert ist. Wer die Anforderungen kennt, kann sie direkt umsetzen.
Dieser Artikel erklärt die wichtigsten Anforderungen – mit konkreten HTML-Beispielen und häufigen Fehlern aus der Praxis.
Labels: sichtbar, programmatisch verknüpft
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.
Pflichtfelder klar kennzeichnen
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.
Fehlermeldungen: verständlich und erreichbar
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.
Gruppen: fieldset und legend
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."
Autocomplete: Helfer für alle
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.
Über die Autorin / den Autor
