Niemand sollte das Formular entschlüsseln müssen
Stellen wir uns eine Anfrage für ein Websiteprojekt vor. Jemand beschreibt die Aufgabe, hinterlässt einen Kontakt und klickt auf Senden. Danach erscheint nur ein roter Rahmen. Fehlt eine Nummer, ist die Verbindung unterbrochen oder wurde die Anfrage bereits versandt? Diese Unsicherheit ist ein Gestaltungsproblem. Ein hilfreicher Entwurf zeigt deshalb nicht nur ein vollständig ausgefülltes Formular, sondern auch unvollständige Angaben, mehrere Fehler, Wartezeiten und Erfolg. Diese kleinen Zustände machen den gesamten Ablauf verständlich.
Anforderungen vorher erklären
Jedes Feld braucht eine verständliche Beschriftung; WAI empfiehlt deren Zuordnung zum Eingabeelement. Ein Formatbeispiel ersetzt die Beschriftung nicht. In unserem fiktiven Briefing könnte die Telefonnummer freiwillig bleiben, wenn eine E-Mail-Adresse ausreicht. Eine vollständige Geschäftsanschrift sollte nicht allein aus Gewohnheit verlangt werden, wenn sie für das erste Gespräch unnötig ist. Listen Sie vor dem Gestalten alle Felder auf und begründen Sie ihren Zweck. Fehlt eine sinnvolle Begründung, sollte das Feld überdacht werden. W3C WAI: Labeling Controls
Das konkrete Problem benennen
Erkannte Fehler müssen als Text beschrieben und dem betroffenen Feld zugeordnet werden; Farbe allein reicht nicht. Statt einer allgemeinen Meldung über ungültige Daten kann bei einem fehlenden Kontakt stehen: „Bitte ergänzen Sie Ihre E-Mail-Adresse“. Für die Beispielanfrage sollten fehlender Kontakt, unvollständige Beschreibung und ein nicht erreichbarer Dienst unterschiedliche Meldungen bekommen. Ein einziger roter Hinweis verdeckt den Unterschied zwischen einem Eingabefehler und einem technischen Übermittlungsproblem. W3C: Error Identification
Eine Korrektur ermöglichen
Ist eine sichere Korrekturmöglichkeit bekannt, sollte sie erklärt werden. Bei einer konkreten Längenbegrenzung nennen Sie diese, statt lediglich einen erneuten Versuch zu verlangen. In längeren Formularen kann eine Fehlerübersicht mit Links zu den Feldern die Hinweise direkt an der Eingabe ergänzen. Meldungen sollten den eingegebenen Text nicht verdecken. Testen Sie den Weg mit der Tastatur: Das Problem finden, korrigieren und fortfahren, ohne das gesamte Briefing neu schreiben zu müssen. W3C: Error Suggestion
Validierung ist keine Zustellung
Prüfungen im Browser ersetzen keine serverseitige Validierung. Eine formal richtige Adresse beweist außerdem nicht, dass eine Nachricht zugestellt wurde. Die Rückmeldung muss zur tatsächlichen Antwort des Systems passen. Eine gespeicherte Anfrage und eine fehlgeschlagene Übermittlung sind unterschiedliche Zustände. Versprechen Sie keinen Rückruf in fünf Minuten, wenn es diesen Ablauf nicht gibt. Wiederholte Klicks, eine langsame Verbindung und ein erneuter Seitenaufruf verdienen eigene Überlegungen. MDN: Client-side form validation
Nicht nur den Erfolgsfall testen
WAI empfiehlt Rückmeldungen sowohl nach erfolgreichen als auch nach fehlgeschlagenen Übermittlungen. Prüfen Sie vor dem Start ein leeres Formular, einen falschen Kontakt, einen langen Text, die Korrektur, einen erfolgreichen Versuch und einen Dienstausfall. Testen Sie vergrößerten Text, Smartphone und Tastatur; zur Barrierefreiheit gehören auch Tests mit assistiven Technologien. Diese Liste ist keine Zertifizierung, sondern eine praktische Hilfe, um unnötige Hürden im Ablauf zu erkennen. W3C WAI: User Notifications