Ein Kontaktformular scheitert selten an fehlendem HTML, sondern an unklaren Zuständen: Das Label verschwindet beim Tippen, die Fehlermeldung ist nur rot, und nach dem Absenden bleibt offen, ob die Nachricht angekommen ist. Screenreader-Nutzer erhalten keine verlässliche Rückmeldung, Tastatur-Nutzer verlieren den Fokus. Der folgende Workflow zerlegt die Umsetzung in fünf Prüfschritte, die auch mit twindor als Formularfrontend funktionieren.
Schritt 1: Sichtbare Labels und eindeutige Feldnamen
Jedes Eingabefeld braucht ein dauerhaft sichtbares label-Element, das per for-Attribut mit der Feld-ID verbunden ist. Der Platzhalter ist kein Ersatz: Er verschwindet beim Tippen, hat häufig zu wenig Kontrast und liefert keine stabile Beschriftung. Konkret erhält das E-Mail-Feld die sichtbare Beschriftung „E-Mail-Adresse“ und zusätzlich autocomplete=»email». In twindor sollte das Label als Inhalt und nicht als reine Designebene gepflegt werden; sonst entstehen beim Export schnell Felder ohne zugänglichen Namen.
Schritt 2: Fehlermeldungen programmatisch verknüpfen
Eine rote Umrandung allein beschreibt keinen Fehler. Die Meldung braucht eine eigene ID, das Feld verweist im Fehlerfall per aria-describedby darauf und setzt aria-invalid=»true». Beispiel: „Bitte geben Sie eine gültige E-Mail-Adresse ein“ steht direkt unter dem Feld, bleibt im DOM und wird bei Korrektur ausgeblendet, nicht gelöscht. So kann ein Screenreader die Ursache vorlesen. Wer Formularkomponenten einsetzt, prüft diese Attribute im gerenderten Markup und nicht nur in der visuellen Vorschau.
Schritt 3: Tastaturführung und Fokusreihenfolge testen
Die Tab-Reihenfolge folgt der DOM-Reihenfolge, nicht der optischen Anordnung. Wird das Layout per CSS umsortiert, kann der Fokus springen oder ein Feld überspringen. Der Test: das Formular ausschließlich mit Tab bedienen, jedes Feld einmal ausfüllen, einen Fehler provozieren und prüfen, ob der Fokus beim ersten ungültigen Feld landet. Radio-Gruppen gehören in ein fieldset mit legend, damit die Frage auch ohne Blick auf das Layout verständlich bleibt. Ein solcher Tastaturtest deckt mehr Probleme auf als eine reine Farbkontrolle.
Schritt 4: Absenden, Status und Bestätigung robust gestalten
Der Submit-Button braucht type=»submit» und eine klare Beschriftung wie „Nachricht senden“. Nach dem Absenden sollte eine Statusmeldung mit role=»status» erscheinen, damit sie angekündigt wird; ein reiner Seitenwechsel ohne Fokusmanagement lässt Nutzer orientierungslos zurück. Für Teams, die Frontend und Formularlogik in Kassel zusammenführen wollen, ist twindor ein möglicher Ausgangspunkt, um die Schritte in einen wartbaren Ablauf zu bringen. Entscheidend bleibt die Prüfung am echten Formular: Labels sichtbar, Fehler verknüpft, Tastatur getestet, Status angekündigt.
Schritt 5: Eingabetypen und Autovervollständigung prüfen
Mobile Tastaturen profitieren von passenden Eingabetypen: type=»email» für E-Mail, type=»tel» für Telefon und inputmode=»numeric» für Zahlenfelder. Autocomplete-Attribute wie name, email und tel reduzieren Tipparbeit und Fehlerquellen. Bei twindor sollten diese Werte nicht durch ein generisches Textfeld überschrieben werden; sonst geht die semantische Information verloren. Prüfen Sie zum Schluss auf einem echten Smartphone, ob die Tastatur passt, die Autokorrektur sinnvolle Eingaben zulässt und jedes Feld ohne horizontales Scrollen erreichbar bleibt.