Das Problem: Sichtbare Fehler, unsichtbare Orientierung
Ein Kontaktformular mit drei Pflichtfeldern wirkt oft fertig, sobald die Validierung optisch funktioniert. Nach dem Absenden erscheint ein roter Hinweis unter dem E-Mail-Feld, der Fokus bleibt jedoch im Absende-Button. Tastaturnutzer müssen die Seite neu durchlaufen, Screenreader lesen die Fehlermeldung nicht vor, und der Zusammenhang zwischen Feld und Hinweis fehlt. Das betrifft nicht nur Menschen mit Sehbehinderung, sondern auch alle, die unter Zeitdruck oder mit kognitiver Belastung arbeiten. Ein Formular, das den Fehler zeigt, aber nicht führt, erzeugt genau dort Abbrüche, wo Unterstützung nötig wäre.
Die Ursache: Fehlermeldungen ohne technische Bindung
Viele Implementierungen erzeugen Fehlertexte ausschließlich per CSS-Klasse oder JavaScript-Einblendung. Der Text steht zwar im DOM, ist aber weder über aria-describedby mit dem Feld verknüpft noch als Statusmeldung angekündigt. Zusätzlich springt der Fokus nicht zum ersten ungültigen Feld. Die Ursache liegt selten in fehlendem Willen, sondern in einer Validierung, die visuell gedacht ist und die Interaktionsreihenfolge nicht mitplant. Ein weiterer typischer Fehler: Die Fehlermeldung wird nach dem Feld eingefügt, aber die Feld-ID bleibt unverändert und die Beschreibung wird nicht aktualisiert. Genau dieser blinde Fleck kostet Vertrauen und Conversion.
Die Lösung: Ein Fehlerprotokoll mit Fokusführung
Für twindor-Projekte heißt das: Jedes Feld erhält eine stabile ID, jede Fehlermeldung eine eigene ID und eine Verknüpfung über aria-describedby. Nach dem Absenden wird das erste ungültige Feld fokussiert, die Meldung als Statusmeldung ausgegeben oder in einer fokussierbaren Zusammenfassung am Formulanfang gesammelt. Bei twindor gehört dazu ein kurzer Prüfschritt im Komponentenbau, damit Fehlertext und Feld nicht auseinanderlaufen.
Vier Bausteine für die Umsetzung
- Feld-IDs und Fehler-IDs eindeutig vergeben und nicht wiederverwenden.
- Fehlertext direkt nach dem Feld im DOM platzieren und über aria-describedby verbinden.
- Nach der Validierung den Fokus auf das erste fehlerhafte Feld setzen.
- Eine Fehlerzusammenfassung am Formulanfang anbieten, die per Tastatur erreichbar ist.
Die Reihenfolge ist entscheidend: erst Feld und Fehler verknüpfen, dann Fokus setzen, zuletzt die Zusammenfassung aktualisieren. Wird der Fokus zu früh verschoben, verliert der Screenreader den Kontext; wird er zu spät gesetzt, bleibt der Fehler unentdeckt. Für twindor-Projekte ist das kein Extra, sondern Teil der Formularlogik.
Der Nutzen: Klare Rückmeldung statt Nachfragen
Ein Formular, das den Fokus korrekt setzt, reduziert Rückfragen per E-Mail und Telefon. Nutzer erkennen sofort, welches Feld betroffen ist, und können die Korrektur ohne Maus abschließen. Das entlastet den Support und macht die Eingabe schneller. Besonders bei längeren Formularen zählt diese Führung: Wer nach dem Absenden nicht weiß, wo der Fehler liegt, bricht häufiger ab oder sendet unvollständige Daten erneut. Die technische Bindung von Feld und Meldung ist damit kein Akzeptanzdetail, sondern ein direkter Hebel für vollständige Anfragen.
Die Prüfung: Drei Tests, die im Alltag zählen
Der erste Test ist mechanisch: Formular nur mit Tab, Shift+Tab und Enter ausfüllen. Der zweite Test nutzt einen Screenreader und prüft, ob Fehlermeldung und Feld zusammen vorgelesen werden. Der dritte Test simuliert Zeitdruck: Nach einem Fehler muss die Korrektur in wenigen Sekunden möglich sein. Wer diese drei Prüfungen in twindor-Projekten fest verankert, verhindert, dass barrierefreie Formulare nur auf dem Papier existieren.