Typografie für Formulare und Eingabefelder

Es gibt einen Formular-Fehler, der so verbreitet ist, dass er zu einem eigenen Anti-Pattern geworden ist: das Formular mit Platzhalter-als-Label. Jedes Feld ist ein sauberer leerer Kasten mit blassgrauem Text darin — „E-Mail-Adresse”, „IBAN”, „USt-IdNr.” — und in dem Moment, in dem du klickst und tippst, verschwindet das Label. Füll sechs Felder aus, werde unterbrochen, komm zurück, und das Formular ist eine Wand aus anonymen Kästen: zu prüfen, was du getippt hast, gegen das, was gefragt wurde, ist unmöglich, ohne Felder zu leeren, um ihre Labels wieder zu sehen. Bei einer Kasse oder einer Banküberweisung ist das keine Reibung — das sind abgebrochene Warenkörbe und falsch überwiesenes Geld.

Formular-Typografie ist auf Scannen und Prüfen ausgelegt, nicht auf kontinuierliches Lesen: Eingabetext mit mindestens 16px, Labels über dem Feld in Fließtextgröße oder eine Stufe kleiner in mittlerer Schriftstärke, Hilfe- und Fehlertext klein, aber nicht unter etwa 13px, Fehler durch mehr als nur Farbe signalisiert und Monospace für alles, was Zeichen für Zeichen geprüft wird. Jede Regel auf dieser Liste existiert, weil Formularfehler — anders als Verleser in Fließtext — echtes Geld und echte Zeit kosten. Dieser Artikel ist Teil unseres Typografie-Leitfadens.

Warum brauchen Formulare eine andere Typografie als Fließtext?

Fließtext wird im Fluss gelesen — das Auge reitet auf dem Kontext und sagt kommende Wörter voraus. Formulare werden in einem völlig anderen Modus gelesen: zum nächsten Feld scannen, ein kurzes Label lesen, eigenen Text erzeugen, dann prüfen, was du erzeugt hast. Der Prüfschritt ist der ungewöhnliche. Die eigenen, frisch getippten Zeichen zu lesen ist schwerer, als gesetzten Fließtext zu lesen, weil es keinen Satzkontext gibt, aus dem man vorhersagen könnte — nichts an einer IBAN legt nahe, ob die nächste Ziffer eine 4 oder eine 9 sein sollte, also muss jedes Zeichen einzeln entschlüsselt werden — Arbeit an der Leserlichkeit statt an der Lesbarkeit.

Das macht Formulare zum Umfeld mit dem höchsten Einsatz für die Typografie. Ein leicht zu grauer Absatz kostet Komfort; eine falsch geprüfte Kontonummer kostet ein Support-Ticket, eine fehlgeschlagene Zahlung oder Schlimmeres. Die folgenden Regeln sind ganz gewöhnliche typografische Ideen, härter durchgezogen, weil der Preis des Scheiterns höher ist.

Welche Schriftgröße sollten Formular-Eingaben verwenden?

Sechzehn Pixel, mindestens, für den Text im Feld. Zwei Gründe — einer mechanisch, einer perzeptiv.

Der mechanische ist der iOS-Zoom-Fallstrick: Wenn die Schriftgröße eines fokussierten Eingabefelds unter 16px liegt, zoomt Safari auf dem iPhone die ganze Seite hinein, um das auszugleichen. Das Layout springt, das Feld rutscht aus der Mitte, und du musst nach jedem Feld wieder herauszoomen. Das ist seit Langem so, und Eingabetext auf 16px oder größer zu setzen ist die schlichte Lösung — der Browser erzwingt praktisch eine Untergrenze für Text, in den du tippen sollst.

Der perzeptive Grund ist das Prüf-Lesen. Fließtext überlebt 14px, weil der Kontext einen Teil der Arbeit übernimmt; deine selbst getippte IBAN bei 14px bekommt keine solche Hilfe, und die zeichenweise Prüfung braucht die zusätzliche Größe. Teams, die reine Desktop-Werkzeuge für den internen Gebrauch bauen, senken Eingaben manchmal auf 14px und kommen damit durch — aber überall, wo ein Smartphone die Seite erreichen kann, ist 16px die Untergrenze.

Wohin gehören Labels — über, neben oder in das Feld?

Über das Feld, linksbündig mit ihm. Usability-Empfehlungen, die darauf beruhen, wie die Augen durch Formulare wandern — wiedergegeben im Formular-Label-Tutorial des W3C — bevorzugen Labels oben: das Auge bewegt sich eine einzige Spalte hinunter, und jedes Label-Feld-Paar wird als eine Einheit erfasst. Labels neben dem Feld erzwingen einen Zickzack-Scan und einen unschönen, variablen Abstand zwischen Label und Kasten; außerdem brechen sie auf schmalen Bildschirmen zuerst um.

Labels im Feld — das Platzhalter-Muster vom Anfang — scheitern strukturell, nicht stilistisch: das Label wird durch das Ausfüllen selbst zerstört. Platzhalter haben durchaus eine legitime Aufgabe als ergänzende Format-Hinweise („[email protected]”) — nur eben nie als der einzige Name, den ein Feld hat.

Wie sollten Labels, Hilfetext und Fehler gestaltet werden?

• Labels: Fließtextgröße oder eine Stufe kleiner, mittlere Schriftstärke. Auf einer 16px-Skala heißt das 16px oder 14px bei Stärke 500 — präsent genug zum Scannen, ruhig genug, um nicht mit dem zu konkurrieren, was du tippst. Die Zugehörigkeit entsteht durch Abstände, nicht durch Styling: ein Label gehört sichtbar näher an sein eigenes Feld als an das Feld darüber (das Nähe-Prinzip aus der Wahrnehmung — Dinge, die einander näher sind, werden als zusammengehörig gelesen). Wenn Label-zu-Feld 8px beträgt, sollte Feld-zu-nächstem-Label 20px oder mehr sein.
• Hilfetext: klein, aber nicht unter ~13px. Eine Stufe unter dem Fließtext ist natürlich; unter etwa 13px wird der Text, der Formate und Sonderfälle erklärt, zu dem Text, den niemand lesen kann.
• Fehlertext: dieselbe Untergrenze, und nie allein über den Farbton. Roter Text plus ein Icon plus eine Meldung — farbenblinde Nutzer verlieren reine Farbton-Signale, also muss der Fehler auch über Form und Position auffindbar sein (nie allein über Farbe, im Formular-Gewand). Eine mittlere Schriftstärke hilft, dass er registriert wird.
• Der Eingabetext selbst: Tinte in vollem Kontrast. Erstaunlich viele ausgelieferte Formulare gestalten den getippten Text der Nutzer im selben blassen Grau wie die Platzhalter — die eigenen Worte lesen sich dann als Vorschlag statt als Antwort, und das Prüfen wird ohne Grund schwerer. Getippter Text ist Inhalt, kein Hinweis.

Wie sieht ein einzelnes Formularfeld auf einer 16px-Skala aus?

Aus einer 16px-Basisskala (Verhältnis 1,333, zwei Noten pro Intervall → 12, 14, 16, 18, 21…) ergibt sich eine vollständige Feld-Anatomie:

Die Abstände kommen aus demselben System: 8px vom Label zum Feld, 20–24px zwischen den Feldern, und jede Zeilenhöhe ein Vielfaches der 8px-Grundlinieneinheit — so stapelt sich ein langes Formular auf einen einzigen vertikalen Rhythmus, statt Feld für Feld Abweichung anzusammeln.

Du kannst diese Stufen als lebendige Schrift untersuchen: öffne die drei Textstufen des Formulars im Scale Composer — Label, Eingabe und Hilfetext aus einer einzigen 16px-Skala, jeweils mit eigener Schriftstärke und Laufweite — und tippe deine eigenen Labels in das Muster, um sie in realer Größe zu beurteilen.

Wann sollte ein Eingabefeld Monospace sein?

Immer dann, wenn der Lesemodus zeichenweise ist: Bestätigungscodes, IBANs, Lizenzschlüssel, API-Tokens, Kartennummern. Der Grund ist die feste Zeichenbreite — jedes Zeichen belegt dieselbe Breite, also sitzt das fünfte Zeichen in jeder Zeichenkette an derselben Stelle, Ziffern lassen sich Spalte für Spalte vergleichen, und ein fehlendes Zeichen verändert die Länge der Zeichenkette sichtbar. Proportionalschriften sind auf Wortformen optimiert; das Prüfen liest keine Wörter. Kombiniere die Monospace mit Gruppierung (SE35 5000 0000 …), und du hast dem Auge des Nutzers dieselbe Struktur gegeben, die der Validator der Bank verwendet.

Baue die dichte Variante

Back-Office-Formulare tauschen Luft gegen Zeilen auf dem Bildschirm, und die Verdichtung ist ein guter Test dafür, welche Regeln nachgeben: Labels können auf 12px in mittlerer Stärke mit leicht geöffneter Laufweite sinken, Zeilenhöhen ziehen sich um eine Grundlinienstufe zusammen, Feldabstände schrumpfen von 24px Richtung 16px — während der Hilfetext bei 14px bleibt (die nächste Stufe der Skala nach unten, 12px, unterschreitet die ~13px-Grenze) und der Eingabetext bei 16px bleibt, weil das Zoom-Verhalten und das Prüf-Lesen sich nicht darum scheren, wie dicht dein Dashboard ist. Um zu sehen, welche Regeln sich verdichten ließen und welche sich weigerten, lade die dichte Variante derselben Feld-Anatomie.