Input Field – Texteingabefelder im UI-Design

Ein Input Field (Eingabefeld) ist ein Formularelement, das Nutzern ermöglicht, freigeschriebenen Text, Zahlen oder strukturierte Daten in eine Anwendung einzugeben.

Rubrik: Mediendesign & Digitale Medien · Unterrubrik: UI-Komponenten · Niveau: Einsteiger Synonyme / Auch bekannt als: Texteingabefeld, Textfeld, Form Input, Text Input, Eingabemaske

Was ist ein Input Field?

Das Input Field ist das zentrale Element jedes Formulars in digitalen Interfaces. Es empfängt Nutzereingaben in freier Textform und übermittelt diese an Systeme – von der simplen Suchleiste bis zum mehrstufigen Checkout-Formular. Die korrekte Gestaltung von Eingabefeldern beeinflusst Conversion-Rates, Fehlerquoten und die Barrierefreiheit einer Anwendung maßgeblich.

Erklärung

Varianten nach Eingabetyp

Der HTML-type-Parameter bestimmt das Eingabeverhalten und die Tastatur auf Mobilgeräten:

• Text: Allgemeine Texteingabe (Name, Freitext)
• Email: Optimierte Tastatur mit @-Symbol, automatische Validierung
• Password: Eingabe wird maskiert (●●●●), Toggle für Sichtbarkeit empfehlenswert
• Number: Numerische Eingabe mit Stepper-Arrows
• Search: Semantisch für Suchfelder, oft mit Lupe-Icon und Clear-Button
• Tel: Zahlentastatur auf Mobilgeräten
• URL: Angepasste Tastatur mit .com-Kürzel
• Textarea: Mehrzeiliges Texteingabefeld für längere Eingaben

States (Zustände)

Anatomie

Ein vollständiges Input Field besteht aus: Label (oben, nicht als Placeholder-Ersatz!), Eingabecontainer (Border + Background), Placeholder-Text (Hinweistext, verschwindet bei Eingabe), Leading/Trailing Icon (optional: Suchsymbol, Passwort-Toggle), Helper Text (unterhalb, Zeichenanzahl oder Hinweis), Error Message (ersetzt Helper Text bei Fehler).

Accessibility (WCAG 2.1)

• Jedes Eingabefeld muss ein sichtbares <label> haben – Placeholder ist kein Ersatz für Labels (verschwindet bei Eingabe, schlechter Kontrast)
• for-Attribut im Label muss mit id des Inputs übereinstimmen
• aria-describedby verknüpft Fehlermeldungen und Hinweistexte
• aria-invalid="true" bei Validierungsfehlern
• Fokus-Indikator muss sichtbar bleiben (WCAG 2.4.7)
• Pflichtfelder: required HTML-Attribut + visueller Indikator (Asterisk * mit Erklärung)
• Fehlertext darf sich nicht nur auf Farbe stützen (WCAG 1.4.1 – Use of Color)

Beispiele

1. Google Search: Das prominenteste Input Field weltweit – floating Label-Design, integriertes Suchicon, Clear-Button bei Eingabe, Voice-Search-Icon rechts. Minimalismus als Designprinzip.
2. Stripe Checkout: Kreditkarteneingabe mit automatischer Kartentyp-Erkennung (Visa-/Mastercard-Logo erscheint bei Eingabe), inline Validierung, maskiertes Passwortfeld für CVV.
3. Mobile vs. Desktop: Mobile Eingabefelder sollten mindestens 44–48 px hoch sein. type="email" und type="tel" öffnen automatisch die passende Tastatur (mit @ bzw. Zahlenblock) – spart Nutzeraufwand.
4. Accessibility Best Practice: Das „Floating Label"-Pattern (Label schwebt über das Feld wenn gefüllt) ist barrierefrei, wenn es korrekt implementiert ist – Label muss jederzeit sichtbar bleiben, nicht nur als Placeholder.
5. Häufiger Fehler: Placeholder-Text als einziges Label verwenden. Beim Klick in das Feld verschwindet der Placeholder – Nutzer vergessen dann, was gefragt wurde. Besonders kritisch für Menschen mit kognitiven Einschränkungen.

In der Praxis

Figma: Input Fields als Komponenten mit Variants für alle States (Default, Focus, Error, Disabled) und Subkomponenten für Label, Helper Text und Icons. Auto Layout für responsive Breitenanpassung. Mit Component Properties lassen sich Label-Text, Placeholder und Error-Message direkt im Instance-Panel editieren.

HTML/CSS-Grundstruktur: ``html <div class="form-group"> <label for="email">E-Mail-Adresse *</label> <input type="email" id="email" name="email" placeholder="name@beispiel.de" required aria-describedby="email-hint email-error" /> <span id="email-hint" class="helper-text">Ihre Kontakt-E-Mail</span> <span id="email-error" class="error-text" role="alert" aria-live="polite"></span> </div> ``

Vergleich & Abgrenzung

Input Fields eignen sich für offene Eingaben; wenn die Optionen bekannt und begrenzt sind, ist ein Dropdown oder Radio Button die bessere Wahl.

Häufige Fragen (FAQ)

Wann soll ich Inline-Validierung einsetzen? Inline-Validierung (Feedback während der Eingabe) ist sinnvoll bei Passwortfeldern (Stärke-Anzeige) und Nutzernamen (Verfügbarkeit prüfen). Bei normalen Feldern wie E-Mail empfiehlt die NNG, erst nach dem Verlassen des Feldes (onBlur) zu validieren – Validierung während der Eingabe wirkt vorwurfsvoll und irritiert Nutzer.

Darf ich Labels durch Placeholders ersetzen? Nein. Placeholder-Text verschwindet bei Eingabe, hat oft zu geringen Kontrast (Standard-Grau erfüllt WCAG-Anforderungen meist nicht) und wird von Screenreadern unzuverlässig vorgelesen. Labels müssen immer sichtbar sein – auch wenn das Feld gefüllt ist.

Verwandte Einträge

• Dropdown & Select
• Date Picker
• Checkbox & Radio Button
• Formular-Design

Weiterführend

• Nielsen Norman Group – „Form Design": nngroup.com/articles/form-design
• Material Design 3 – Text Fields: m3.material.io/components/text-fields
• Apple Human Interface Guidelines – Text Fields: developer.apple.com/design/human-interface-guidelines/text-fields
• WebAIM – Accessible Forms: webaim.org/techniques/forms