Barrierefreie Formulare: Labels und Validierung

Ein Formular vereint mehrere kritische Interaktionen auf engem Raum: Beschriftung, Eingabe, Validierung, Fehlerbehandlung und Absenden. Jeder dieser Schritte kann eine eigene Barriere erzeugen. Die häufigsten Probleme entstehen, weil visuelle Gestaltung und programmatische Struktur auseinanderlaufen. Ein Feld sieht beschriftet aus, weil daneben ein Text steht, aber dieser Text ist nicht als mit dem Feld verknüpft. Sehende Nutzer erkennen den Zusammenhang, ein Screenreader hingegen liest nur Eingabefeld vor.

Der WebAIM Million Report (2024) zeigt, dass 96,3% (WebAIM Million, 2024) aller untersuchten Startseiten mindestens einen automatisch erkennbaren WCAG-Verstoss aufweisen. Fehlende Formular-Labels stehen dabei seit Jahren konstant unter den Top-Fehlern. Hinzu kommt: Automatische Prüfwerkzeuge erkennen nur einen Teil aller Barrieren zuverlässig (W3C/WAI). Gerade bei Formularen sind manuelle Tests mit Tastatur und Screenreader unverzichtbar, weil die Bedienlogik und das Vorlese-Verhalten erst im realen Ablauf sichtbar werden.

Die Nielsen Norman Group (2023) beschreibt, dass unklare Fehlermeldungen und schlecht platzierte Hinweise zu den größten Frustfaktoren in Formularen gehören - für alle Nutzer, nicht nur für Menschen mit Behinderungen. Ein barrierefrei gebautes Formular ist deshalb fast immer auch ein nutzerfreundlicheres Formular mit niedrigeren Abbruchraten. Unsere Leistungen setzen genau an dieser Schnittstelle aus Barrierefreiheit und Conversion an. Besonders sichtbar wird das in den umfangreichen Bestell- und Adressformularen eines barrierefreien Shops.

Jedes Eingabefeld braucht eine programmatisch verknüpfte Beschriftung. Der einfachste und robusteste Weg ist das -Element mit einem for-Attribut, das auf die id des Feldes verweist. Screenreader lesen dann beim Fokussieren des Feldes automatisch die Beschriftung vor, und ein Klick auf das Label setzt den Fokus ins Feld - das vergrößert nebenbei das Klickziel und hilft Menschen mit motorischen Einschränkungen. Das WCAG-2.2-Kriterium 3.3.2 (Labels or Instructions) und 4.1.2 (Name, Role, Value) verlangen genau diese Verknüpfung (W3C, 2023).

Ein Platzhalter (placeholder) ist kein Ersatz für ein Label. Er verschwindet beim Tippen, wird von Screenreadern uneinheitlich behandelt und hat oft zu wenig Kontrast. Wenn aus Designgründen kein sichtbares Label möglich ist - etwa bei einem Suchfeld - kann aria-label oder aria-labelledby eingesetzt werden. Sichtbarer Text bleibt jedoch die beste Wahl, weil er allen Nutzern hilft, auch Menschen mit kognitiven Einschränkungen und Nutzern von Spracheingabe, die das sichtbare Label als Befehl ansprechen.

Pflichtfelder müssen sowohl visuell als auch programmatisch erkennbar sein. Ein roter Stern allein genügt nicht, da seine Bedeutung nicht erklärt ist und Screenreader ihn nicht zuverlässig vorlesen. Robust ist die Kombination aus dem nativen HTML-Attribut required (das zugleich die Browser-Validierung aktiviert) und einem sichtbaren Hinweis. Zusätzlich sollte am Formularanfang erklärt werden, was die Markierung bedeutet, etwa: Mit Stern markierte Felder sind Pflichtfelder.

Wer den Stern nutzt, sollte ihn für Screenreader entweder vorlesbar machen oder per aria-hidden ausblenden und stattdessen aria-required="true" setzen. Wichtig ist Konsistenz: Entweder werden alle Pflichtfelder markiert oder - bei Formularen, in denen fast alles Pflicht ist - nur die optionalen Felder als optional gekennzeichnet. Doppelte oder widersprüchliche Hinweise verwirren mehr, als sie helfen.

Die WCAG 2.2 widmen Fehlern gleich mehrere Kriterien: 3.3.1 (Error Identification) verlangt, dass ein Fehler erkannt und in Textform benannt wird. 3.3.3 (Error Suggestion) fordert, dass nach Möglichkeit ein konkreter Korrekturvorschlag gemacht wird (W3C, 2023). In der Praxis heisst das: Eine gute Fehlermeldung beschreibt nicht nur das Problem, sondern auch die Lösung. Statt Ungültige Eingabe besser: Bitte geben Sie eine E-Mail-Adresse mit at-Zeichen ein, zum Beispiel name@beispiel.de.

Jede Fehlermeldung gehört direkt an das betroffene Feld - nicht nur in eine Zusammenfassung am Seitenanfang. Programmatisch wird das Feld mit aria-invalid="true" markiert und die Meldung über aria-describedby mit dem Feld verbunden. Beim Fokussieren liest der Screenreader dann Label und Fehlermeldung gemeinsam vor. Damit eine neu eingeblendete Meldung sofort angekündigt wird, sollte der Meldungscontainer ein role="alert" (oder aria-live="assertive") tragen.

Bei serverseitiger Validierung, nach der die Seite neu geladen wird, sollte zusätzlich eine Fehlerzusammenfassung oberhalb des Formulars erscheinen. Diese listet alle Fehler als Links auf, die direkt zum jeweiligen Feld springen. Der Fokus wird nach dem Absenden programmatisch auf diese Zusammenfassung gesetzt, damit Screenreader- und Tastaturnutzer sofort erfahren, dass und wo etwas korrigiert werden muss. Das BITV-Prüfverfahren und die EN 301 549 bewerten genau diese Kombination aus Identifikation, Beschreibung und erreichbarer Korrektur (EN 301 549, 2021). Welche BFSG-Anforderungen im Detail gelten, hängt von der Art Ihres Angebots ab.

Inline-Validierung prüft Eingaben bereits während des Ausfuellens und gibt sofort Rückmeldung. Richtig umgesetzt reduziert das Fehler und Abbrüche; falsch umgesetzt erzeugt sie neue Barrieren. Der häufigste Fehler ist die Validierung bei jedem Tastendruck: Sie meldet einen Fehler, während der Nutzer noch tippt, und ein role="alert" würde dann ständig dazwischenfunken. Die Nielsen Norman Group (2022) empfiehlt, erst beim Verlassen des Feldes (blur) zu validieren und positive Rückmeldungen sparsam einzusetzen.

Für Live-Rückmeldungen eignet sich eine Region mit aria-live="polite", die Änderungen ankündigt, ohne den aktuellen Vorgang zu unterbrechen. assertive beziehungsweise role="alert" ist nur für dringende, blockierende Meldungen reserviert. Wichtig ist, dass eine Meldung, die wieder verschwindet (etwa weil der Fehler behoben wurde), den Fokus nicht stiehlt und der Nutzer den Korrekturpfad nachvollziehen kann. Ein Passwortfeld, das Anforderungen live abhakt, sollte diese als Liste mit klaren Zuständen führen statt nur per Farbe.

Fokus-Management entscheidet darüber, ob ein Formular per Tastatur und Screenreader nachvollziehbar bleibt. Grundregel: Die Tab-Reihenfolge folgt der visuellen Leserichtung, und jedes fokussierte Element hat einen deutlich sichtbaren Fokus-Indikator. Das mit WCAG 2.2 neu eingeführte Kriterium 2.4.11 (Focus Not Obscured) verlangt, dass das fokussierte Element nicht von Sticky-Headern, Cookie-Bannern oder Chat-Fenstern verdeckt wird (W3C, 2023).

Nach dem Absenden eines Formulars mit Fehlern wird der Fokus aktiv auf die Fehlerzusammenfassung oder das erste fehlerhafte Feld gesetzt. War das Absenden erfolgreich, sollte der Fokus auf die Erfolgsmeldung wandern, damit sie vorgelesen wird. Programmatisch gesetzter Fokus auf nicht-interaktive Elemente wie eine Überschrift erfordert ein tabindex="-1", damit das Element fokussierbar wird, ohne in die normale Tab-Reihenfolge zu rutschen. Sauberes Fokus-Management gehört für uns zur barrierefreien Webentwicklung dazu.

Das WCAG-Kriterium 1.3.5 (Identify Input Purpose) verlangt, dass der Zweck von Eingabefeldern, die persönliche Daten erfassen, programmatisch bestimmbar ist (W3C, 2023). Umgesetzt wird das über standardisierte autocomplete-Tokens wie given-name, family-name, email, tel, street-address, postal-code oder country-name. Browser und Hilfstechnologien können so gespeicherte Daten anbieten und Felder mit Symbolen anreichern - eine grosse Entlastung für Menschen mit motorischen oder kognitiven Einschränkungen.

Ergänzend steuert das inputmode-Attribut die Bildschirmtastatur auf mobilen Geräten: numeric für Postleitzahlen, email für E-Mail-Felder, tel für Telefonnummern. In Kombination mit dem korrekten type-Attribut entsteht eine Eingabe, die weniger Fehler produziert. Wer mehrere Formulare betreibt, profitiert hier doppelt, denn die gleichen Tokens lassen sich domainübergreifend wiederverwenden. Diese Details setzen wir in der barrierefreien Webentwicklung standardmäßig um.

Datumsfelder gehören zu den schwierigsten Formularelementen. Das native ist oft die beste Wahl, weil es Tastaturbedienung, Lokalisierung und Screenreader-Unterstützung mitbringt. Wo ein eigenes Datepicker-Widget nötig ist, muss es das vollständige Tastaturmuster abbilden: Navigation per Pfeiltasten, Auswahl per Enter, Schliessen per Escape und korrekte ARIA-Auszeichnung als Dialog oder Grid. Wichtig ist immer ein zusätzliches Texteingabefeld als Alternative, denn nicht jeder kann ein Kalender-Raster bedienen.

Das erwartete Datumsformat muss klar kommuniziert werden, etwa per Hilfetext TT.MM.JJJJ, der über aria-describedby mit dem Feld verbunden ist. Felder, die in Teilfelder zerlegt sind (Tag, Monat, Jahr), benötigen je ein eigenes Label und sollten in ein