Warum Formulare schwerer sind, als sie aussehen

Fast jede Website hat eins. Name, E-Mail, Nachricht, ein Knopf. Das sieht nach einer halben Stunde Arbeit aus.

Und für das, was man sieht, stimmt das auch. Nur ist ein Formular die einzige Stelle deiner Website, an der ein Besucher etwas tut statt liest. Alles andere kann er überfliegen. Hier muss er treffen, tippen, verstehen, warum eine Eingabe abgelehnt wird — und am Ende muss das, was er geschrieben hat, tatsächlich bei dir ankommen.

Das sind vier Stellen, an denen etwas schiefgehen kann, und keine davon sieht man dem fertigen Formular an.

Ein Formular ist nur HTML

Das klingt banal und ist der Ausgangspunkt.

Ein Formular hat genau eine feste Regel: Es steht in einem Formular-Element. Alles darin ist frei. Du kannst die Felder in Container packen oder in eine Liste. Am Bildschirm sieht beides identisch aus — die Wahl ändert nichts an der Darstellung.

Und genau deshalb sollte man die Wahl bewusst treffen. Wenn zwei Möglichkeiten gleich aussehen, aber eine von ihnen zusätzlich beschreibt, was die Teile miteinander zu tun haben, dann gibt es keinen Grund für die andere.

Das ist dasselbe Argument wie bei Aufzählungen und Tabellen: Die richtige Auszeichnung kostet nichts extra und trägt Bedeutung, die eine nachgebaute Variante nicht hat.

Die Beschriftung, die man nicht sieht

Jedes Feld braucht eine Beschriftung, die technisch mit dem Feld verbunden ist — nicht nur ein Stück Text daneben.

Der Unterschied ist unsichtbar. Ein Feld mit verbundener Beschriftung und eines mit losem Text daneben sehen exakt gleich aus. Es gibt aber einen Test, der zehn Sekunden dauert:

Klicke auf den Beschriftungstext, nicht auf das Feld.

Springt der Cursor ins Feld, ist die Verbindung da. Passiert nichts, ist sie es nicht.

Bei einem Ankreuzfeld ist der Unterschied noch deutlicher: Mit Verbindung kannst du auf das Wort klicken und das Kästchen setzt sich. Ohne Verbindung musst du das Kästchen selbst treffen — ein Ziel von wenigen Millimetern, am Handy, mit dem Daumen.

Und für jemanden, der die Seite vorgelesen bekommt, ist die Verbindung der einzige Weg, überhaupt zu erfahren, wofür ein Feld da ist. Ohne sie sagt die Vorlesesoftware „Eingabefeld" und sonst nichts.

Es gibt zwei Wege, die Verbindung herzustellen: Man verweist von der Beschriftung auf die Kennung des Feldes, oder man legt die Beschriftung um das Feld herum. Beides ist richtig.

Der graue Text im Feld ist keine Beschriftung

Der verbreitetste Fehler, und er entsteht aus einem gestalterischen Wunsch: Das Formular sieht aufgeräumter aus, wenn die Beschriftung im Feld steht statt darüber.

Das Problem ist einfach: Dieser Text verschwindet, sobald jemand anfängt zu tippen.

Wer beim dritten Feld kurz überlegt, was er gerade eintragen wollte, hat keine Möglichkeit mehr nachzusehen. Wer prüfen möchte, ob er in das richtige Feld geschrieben hat, auch nicht. Und wer das Formular abschickt und einen Fehler zurückbekommt, steht vor Feldern ohne jede Bezeichnung.

Die Barrierefreiheitsregeln sind an dieser Stelle eindeutig: Ein Platzhaltertext darf niemals die einzige Beschriftung sein. Er darf zusätzlich da sein, als Beispiel für das erwartete Format. Als Ersatz nicht.

Gruppen brauchen eine Überschrift

Am deutlichsten bei Auswahlmöglichkeiten, von denen nur eine zutrifft.

Wenn dort drei Optionen untereinander stehen, hat jede von ihnen ihre eigene Beschriftung. Was fehlt, ist die Frage, zu der sie gehören. Auf dem Bildschirm steht die Frage als Überschrift darüber, und das Auge stellt den Zusammenhang her.

Wer sich die Seite vorlesen lässt, hört nur die Antworten. Die Frage ist optisch vorhanden und technisch nicht verbunden.

Dafür gibt es ein Element, das eine Gruppe zusammenfasst, und ein zweites, das ihr eine Überschrift gibt. Zusammen sagen sie: Diese Felder gehören zusammen, und das hier ist die Frage.

Nebenbei macht das auch lange Formulare lesbarer — Kontaktdaten, Anliegen, Einwilligungen als drei sichtbare Blöcke statt als eine Kette von zwanzig Feldern.

Der richtige Feldtyp — und was er nicht leistet

Ein Eingabefeld kann verschiedene Typen haben: Text, E-Mail, Telefonnummer, Adresse, Zahl, Datum. Der Unterschied hat zwei sichtbare Wirkungen.

Die erste ist das Handy. Ein Feld vom Typ E-Mail bringt eine Tastatur mit dem @-Zeichen mit. Ein Telefonfeld bringt den Ziffernblock. Ein Textfeld bringt die normale Tastatur, und der Besucher sucht das @ selbst. Das ist keine Kleinigkeit — es ist der Unterschied zwischen zwei und sechs Handgriffen, bei jedem Feld.

Die zweite ist eine erste Prüfung im Browser, noch bevor irgendetwas verschickt wird.

Und hier kommt der Teil, den man wissen muss: Diese Prüfung ist schwächer, als sie aussieht.

Ein E-Mail-Feld akzeptiert eine Adresse ohne Punkt hinter dem @, weil solche Adressen in Firmennetzen tatsächlich vorkommen. Ein Telefonfeld prüft die Eingabe gar nicht, weil Telefonnummern international zu unterschiedlich aufgebaut sind, als dass eine allgemeine Regel funktionieren könnte.

Der Feldtyp ist also ein Komfortmerkmal mit einem kleinen Prüfeffekt. Er ist keine Kontrolle.

Automatisches Ausfüllen

Browser können Namen, Adresse und Telefonnummer selbst einsetzen — aber nur, wenn im Feld steht, wofür es da ist. Ohne diese Angabe rät der Browser, und meistens rät er nicht.

Das ist eine der wenigen Maßnahmen, die niemandem schadet und mehreren Gruppen deutlich hilft: Wer sich Dinge schlecht merkt, muss sie nicht heraussuchen. Wer motorisch eingeschränkt ist, spart jeden einzelnen Anschlag. Und alle anderen sind schneller fertig.

Es steht als eigene Anforderung in den Barrierefreiheitsregeln, und es ist eine Zeile pro Feld.

Geprüft wird an zwei Stellen, aus zwei Gründen

Das ist der Punkt, an dem selbstgebaute Formulare am häufigsten unvollständig sind.

Im Browser wird für den Besucher geprüft. Er soll sofort sehen, dass eine Angabe fehlt, statt abzuschicken, zu warten und die Antwort zurückzubekommen. Das ist ein Komfortmerkmal.

Auf dem Server wird für dich geprüft. Und das ist kein Komfort, sondern die einzige Prüfung, die zählt. Es gibt dafür drei Gründe:

Erstens gibt es Prüfungen, die nur der Server machen kann. Ob ein Termin noch frei ist, ob eine Kundennummer existiert, ob eine Menge verfügbar ist — dafür braucht man die Daten, und die liegen nicht im Browser.

Zweitens läuft die Prüfung im Browser auf einem fremden Rechner. Sie wird zusammen mit der Seite ausgeliefert. Wer will, kann sie abschalten und trotzdem absenden. Eine Prüfung, die der Absender kontrolliert, ist keine.

Drittens macht man Fehler. Eine Prüfregel im Browser kann falsch geschrieben sein und deshalb alles durchlassen. Fällt das nicht auf, landen die falschen Daten trotzdem bei dir.

Wenn dein Formular aus einem Plugin kommt, macht das Plugin die Serverprüfung normalerweise mit. Wenn jemand ein Formular von Hand gebaut hat, weil es hübscher aussehen sollte, ist genau das die Stelle, an der man nachsehen muss.

Was ein Formular grundsätzlich nicht prüfen kann

Ob eine E-Mail-Adresse tatsächlich existiert.

Das lässt sich beim Ausfüllen nicht feststellen, mit keinem Verfahren. Der einzige Nachweis ist, eine Nachricht an diese Adresse zu schicken und darauf zu warten, dass jemand darin auf einen Link klickt. Genau deshalb funktionieren Anmeldungen überall auf der Welt nach diesem Muster.

Wer also aus einem Formular eine Liste aufbaut, sollte wissen: Die Adressen darin sind so lange unbestätigt, bis jemand geantwortet hat.

Und dann muss die Nachricht ankommen

Hier hört fast jede Anleitung auf, und hier fängt der Teil an, der in der Praxis am häufigsten schiefgeht.

Ein Formular ist nicht fertig, wenn es abgeschickt werden kann. Es ist fertig, wenn die Nachricht in deinem Postfach liegt.

Zwischen beidem liegt eine Kette: Deine Website übergibt die Nachricht an einen Versandweg. Der Versandweg übergibt sie an den Mailserver des Empfängers. Und dieser Server entscheidet, ob er sie annimmt, ablehnt oder in den Spam-Ordner legt — anhand von Einträgen, die nicht auf deiner Website stehen, sondern bei deiner Domain.

Das erklärt eine Beobachtung, die viele Betreiber machen und nicht einordnen können: Das Formular meldet „Nachricht gesendet", und es kommt trotzdem nichts an. Beides ist gleichzeitig wahr. Die Website hat abgegeben, und danach ist etwas passiert, wovon sie nichts mitbekommt.

Das ist ein eigenes Thema und hat einen eigenen Artikel. Für hier reicht die Konsequenz: Ein Formular gilt erst dann als geprüft, wenn du es einmal von außen ausgefüllt und die Mail erhalten hast. Nicht aus dem eingeloggten Zustand, nicht mit deiner eigenen Adresse als Absender, sondern so, wie ein Fremder es täte.

Was du in zehn Minuten selbst prüfst

Du brauchst dafür kein Werkzeug.

Klick auf die Beschriftungen. Nicht auf die Felder — auf den Text daneben. Springt der Cursor hinein?

Geh mit der Tabulatortaste durch. Erreichst du jedes Feld? Siehst du bei jedem Schritt, wo du gerade bist? Kommst du am Ende auf den Absendeknopf?

Öffne das Formular am Handy. Bekommst du beim E-Mail-Feld die Tastatur mit dem @? Beim Telefonfeld die Ziffern?

Schick es leer ab. Was passiert? Steht irgendwo, welches Feld fehlt — und steht es beim Feld oder nur oben als allgemeiner Hinweis?

Tipp etwas Falsches ein. Verstehst du die Fehlermeldung? Oder steht dort eine technische Formulierung, die niemand außerhalb der Entwicklung liest?

Und dann füll es einmal richtig aus, von außen, mit einer fremden Adresse. Kommt die Mail? Wie schnell? Und liegt sie im Posteingang oder im Spam?

Der unspektakuläre Kern

An einem Formular ist nichts schwierig. Jeder einzelne Punkt hier ist eine Zeile Auszeichnung oder eine Einstellung im Plugin.

Sie fallen trotzdem regelmäßig aus, weil ein Formular als fertig gilt, sobald es hübsch aussieht und sich absenden lässt. Das ist der Zustand, in dem die meisten Formulare stehen — und in dem sie für die Hälfte der Besucher mühsamer sind, als sie sein müssten.

Quellen

• Udemy, Web Forms — Build and Master HTML Web Forms, Abschnitt 4 — dass die Struktur eines Formulars frei ist und die Wahl zwischen Containern und Listen die Darstellung nicht verändert; dass eine Beschriftung optisch nichts bewirkt, wohl aber dazu führt, dass ein Klick auf ihren Text das zugehörige Bedienelement auswählt; dass es zwei Wege gibt, Beschriftung und Feld zu verbinden, nämlich über einen Verweis auf die Kennung oder durch Umschließen; dass ein Gruppierungselement zusammen mit einem Überschriftselement Felder gleichen Zwecks zusammenfasst und lange Formulare dadurch verständlicher werden.
• Udemy, Web Forms, Abschnitt 6 — dass ein Feld vom Typ E-Mail eine Adresse der Form Zeichen-at-Zeichen als gültig annimmt, weil Adressen aus Firmennetzen zulässig sind; dass von der Browserseite grundsätzlich nicht feststellbar ist, ob eine Adresse existiert, und der übliche Nachweis darin besteht, eine Nachricht mit einem Bestätigungslink zu senden; dass ein Feld vom Typ Telefonnummer keine Formatprüfung vornimmt, weil Telefonnummern international zu verschieden aufgebaut sind.
• Udemy, Web Forms, Abschnitt 10 — dass die Prüfung im Browser eine erste Kontrolle und ein Komfortmerkmal ist, weil der Besucher einen Fehler sofort statt nach einem Weg zum Server und zurück sieht; und die drei Gründe für die Prüfung auf dem Server: dass manche Prüfungen einen Datenbestand voraussetzen, über den nur der Server verfügt; dass die Prüfung im Browser mit der Seite ausgeliefert wird und deshalb umgangen werden kann; und dass eine fehlerhaft geschriebene Prüfregel unbemerkt alles durchlässt.
• Atlas, accessibility/criteria/3-3-2-labels-or-instructions.md — dass jedes Eingabefeld eine sichtbare Beschriftung braucht, dass Felder mit Formatvorgaben zusätzlich eine Angabe zum erwarteten Format erhalten, und dass ein Platzhaltertext niemals als alleinige Beschriftung dienen darf, weil er bei der Eingabe verschwindet. Die Anforderung ist eine der Grundstufe.
• Atlas, accessibility/criteria/1-3-5-identify-input-purpose.md — dass der Zweck eines Feldes, das persönliche Angaben erfasst, maschinenlesbar hinterlegt sein muss, damit das automatische Ausfüllen greift; dass Menschen mit kognitiven Einschränkungen davon profitieren und Menschen mit motorischen Einschränkungen erheblichen Aufwand sparen. Die Anforderung liegt auf der mittleren Stufe.
• Eigene Prüfpraxis — die Reihenfolge der Selbstprüfung, der Klicktest auf den Beschriftungstext, die Prüfung am Handy auf die richtige Tastatur, und die Regel, ein Formular erst dann als geprüft zu betrachten, wenn es von außen mit einer fremden Adresse ausgefüllt wurde und die Nachricht angekommen ist.
• Verweis statt Wiederholung — die Kette vom Absenden bis zum Posteingang wird hier nur benannt. Warum eine Nachricht unterwegs aussortiert wird und welche Einträge bei der Domain darüber entscheiden, steht im Artikel über Mails, die im Spam landen.