Figma

Form Inputs

Beschreibung

Ein Eingabefeld ermöglicht es den Nutzenden, Daten in das System einzugeben, sei es durch die Eingabe von Text, numerischen Werten oder anderen Formen von Informationen. Die Eingabe ist für die Interaktion zwischen dem Nutzenden und der Anwendung in verschiedenen Kontexten wie Formularen, Suchfeldern und Dateneingabeschnittstellen von entscheidender Bedeutung. Hier findest du allgemeine Informationen zu allen Typen von Eingabefeldern, Besonderheiten der einzelnen Ausprägungen findest du auf den Unterseiten:

• Input Checkboxes

  Dient der Auswahl einer oder mehrerer Optionen.

• Input Date

  Unterstützt Nutzende bei der Eingabe eines Datums.

• Input E-Mail

  Unterstützt Nutzende bei der Eingabe einer E-Mail-Adresse.

• Input File

  Ermöglicht das Hochladen einer oder mehrerer Dateien.

• Input Number

  Unterstützt Nutzende bei der Eingabe einer Zahl.

• Input Password

  Ermöglicht die Eingabe oder Erstellung eines Passworts.

• Input Radios

  Dienen der Auswahl nur einer Option aus sich gegenseitig ausschließenden Optionen.

• Input Select

  Bietet die Möglichkeit zur Auswahl einer Option aus einer ausklappbaren Liste von Optionen.

• Input Tel

  Unterstützt Nutzende bei der Eingabe einer Telefonnummer.

• Input Text

  Ermöglicht Nutzenden, Buchstaben, Zahlen und Sonderzeichen einzugeben.

• Input Textarea

  Ermöglicht eine Eingabe von langen Textinhalten durch Nutzende.

• Input URL

  Unterstützt Nutzende bei der Eingabe einer einer Internetadresse (URL).

States

Eingabefelder können verschiedene Zustände annehmen. Nicht alle Felder nutzen alle „states“. Bei den einzelnen Ausprägungen wird angegeben, welche „states“ sie verwenden.

State	Beschreibung und Verwendung
default	Wenn Nutzende Informationen eingeben können, wird das Input im Zustand „default“ angezeigt. Dies ist der Normalzustand in einem Formular.
hover	Wird verwendet, wenn der Mauszeiger der Nutzenden über dem Input schwebt.
focus	Sobald Nutzende das Input anklicken, antippen oder mit der Tabulatortaste ansteuern, wird es fokussiert. Dies zeigt an, dass das Feld aktiv und eingabebereit ist.
readonly	Inputs können im Zustand „readonly“ angezeigt werden, wenn zuvor Informationen gespeichert wurden, die an dieser Stelle nicht geändert werden können. In diesem Zustand sind die Inputs schreibgeschützt (inaktiv). Nutze diesen Zustand ausschließlich, wenn es Nutzenden einen Mehrwert bringt, die Information erneut einzusehen. Gegebenenfalls kann ein Link zu dem Ort hilfreich sein, an dem die angezeigten Informationen angepasst werden können.
disabled	Der Zustand „disabled“ zeigt an, dass Nutzende keine Inhalte eingeben können, beispielsweise bis eine andere Aktion abgeschlossen ist. Verwende diesen Zustand, wenn eine vorübergehende Deaktivierung des Inputs sinnvoll ist. Blende einen Input lieber aus, wenn es nicht benötigt wird.
error default	Beim Zustand „error“ wird das Input mit der entsprechenden Funktionsfarbe markiert und mit einer Fehlermeldung versehen. Dieser Zustand tritt auf, wenn beim Absenden des Formulars ein Fehler im entsprechenden Input festgestellt wurde – beispielsweise, wenn ein Pflichtfeld nicht ausgefüllt wurde. Die Meldung sollte knapp und verständlich erklären, was zu tun ist, um den Fehler zu beheben. Bei längeren Fehlermeldungen, achte darauf, dass sie das Layout nicht beeinträchtigen. Um Eingabefehler zu vermeiden, nutze Inputs zur Eingabe spezieller Formate. Sollen Nutzende zum Beispiel ein Datum eingeben, nutze Input Date.
error focus	Wenn beim Absenden eines Formulars ein Fehler festgestellt wurde, wird dieser am entsprechenden Eingabefeld angezeigt – wie im Zustand „error“ beschrieben. Sobald Nutzende das betroffene Input ansteuern, um den Fehler zu korrigieren, erhält es zusätzlich den Fokus (siehe State „focus“). Die visuelle Darstellung kann je nach Input-Typ variieren.
error hover	Wenn beim Absenden eines Formulars ein Fehler festgestellt wurde, wird dieser am entsprechenden Eingabefeld angezeigt – wie im Zustand „error“ beschrieben. Bewegt der Mauszeiger sich über das fehlerhafte Feld, wird dieser „error-hover“-Zustand visuell hervorgehoben. Die konkrete Darstellung kann je nach Input-Typ variieren.

Ergänzende Elemente und Eigenschaften

Label und Legende

Das Label oder die Legende eines Inputs sollte immer möglichst knapp und präzise beschreiben, welche Eingabe nötig ist.

Required-Auszeichnung

Formulare sollten idealerweise hauptsächlich aus Pflichtfeldern und nur wenigen optionalen Feldern bestehen. So bleibt das Formular übersichtlich und benutzerfreundlich – ganz im Sinne unserer KERN-Gestaltungsprinzipien.

Für die Kennzeichnung von Pflichtfeldern setzen wir bevorzugt auf aria-required="true", statt das native HTML-Attribut required zu verwenden. Der Grund: Das required-Attribut führt zu einer automatischen Browservalidierung, bei der Stil und Verhalten nicht konsistent steuerbar sind. Je nach Browser erscheint eine unterschiedlich gestaltete Fehlermeldung (z. B. Tooltip mit „Bitte füllen Sie dieses Feld aus“) und eine automatische Umrandung – was dem Anspruch an ein einheitliches, barrierefreies Fehlermuster widerspricht.

Mit aria-required="true" hingegen wird das Feld von assistiven Technologien korrekt als erforderlich erkannt, ohne dass der Browser automatisch eingreift. Das erlaubt uns, die Validierung vollständig per JavaScript und CSS zu steuern und somit ein einheitliches visuelles Feedback sowie zugängliche Fehlermeldungen umzusetzen – wie in den KERN-Richtlinien vorgesehen.

Alternativ kann auch der Ansatz des Bootstrap-Frameworks verfolgt werden: Hier wird das required-Attribut verwendet, die native Formularüberprüfung jedoch durch eigene Validierungsmechanismen ergänzt. Auch dies kann eine gangbare Lösung sein – sofern dabei sichergestellt wird, dass die Benutzerführung und das visuelle Feedback konsistent mit den KERN-Vorgaben umgesetzt werden.

infoEmpfehlung

Nutze bevorzugt aria-required="true" für die Markierung von Pflichtfeldern – für maximale Kontrolle über Darstellung und Barrierefreiheit.

Optional-Label

Kennzeichne optionale Inputs eindeutig. Überlege sorgfältig, ob die entsprechende Information wirklich benötigt wird, um das Formular nicht zu überladen. Idealerweise sollte das Formular hauptsächlich aus Pflichtfeldern und nur wenigen optionalen Feldern bestehen.

Hint

Der Hinweistext (hint) bietet unterstützende Informationen, die den Nutzenden zusätzlichen Kontext oder Hilfe geben. Er kann beispielsweise genutzt werden, um das erwartete Datenformat zu erklären. Der Hinweistext sollte nicht für lange Erklärungen mit Listen und Absätzen verwendet werden. Im Hinweistext sollten nur Informationen angezeigt werden, die für viele Nutzende in diesem Kontext hilfreich sind und die nicht mehrfach im Formular wiederholt werden. Beispiele: Geben Sie Ihre E-Mail im Format Beispiel@Anbieter.de ein. Das Ablaufdatum Ihrer Kreditkarte finden Sie auf der Rückseite Ihrer Karte.

Fehlermeldungen

Qualitativ hochwertige Fehlermeldungen sind in der Erstellung und Pflege zwar aufwändiger, dieser Aufwand zahlt sich jedoch durch eine verbesserte Nutzererfahrung und potenzielle Einsparungen im Support aus. Formuliere spezifische Fehlermeldungen für jeden erkennbaren Fehlerzustand. Eine Übersicht über die verschiedenen Zustände findest du in der States-Tabelle auf dieser Seite.

Achte beim Verfassen der Fehlermeldungen auf folgende Punkte:

• Konstruktiv: Fehlermeldungen sollten Nutzende anleiten, das Problem zu lösen – ohne tadelnden Ton. Sei transparent und gib alle hilfreichen Informationen weiter.
• Verständlich: Die Sprache muss klar und für die Zielgruppe nachvollziehbar sein. Vermeide Fachbegriffe, Fremdwörter oder mehrdeutige Formulierungen. Erkläre bei Bedarf durch kurze Beispiele.
• Prägnant: Formuliere knapp und beschränke dich auf eine einzige Fehlerursache. Nutze aktive Sprache und kurze, klare Sätze.
• Empathisch: Fehlermeldungen sollten freundlich, unterstützend und nicht abschreckend wirken.

Quelle: Leitfaden der German UPA (PDF)

Breite und Höhe der Eingabefelder

Diese Informationen gelten für alle Eingabefelder, die eine Text- oder Zahleneingabe erlauben – nicht jedoch für andere Input-Typen wie Checkboxes oder Radios.
Ein Eingabefeld hat eine feste Höhe, die unabhängig von der Menge des eingegebenen Textes konstant bleibt. In der Breite sind Eingabefelder grundsätzlich flexibel. Achte jedoch darauf, Eingabefelder nicht zu breit anzulegen, da dies die Lesbarkeit und die Benutzerfreundlichkeit beeinträchtigen. Die Breite sollte idealerweise so gewählt werden, dass Nutzende bereits visuell abschätzen können, wie lang der erwartete Wert ungefähr ist. Ein zu kleines Feld kann den Nutzenden frustrieren, während ein zu großes Feld Platz verschwendet. Wähle eine konsistente Breite für Eingabefelder, die ähnliche Informationen erfassen. Teste zudem auf unterschiedlichen Bildschirmgrößen und Geräten, um ihre Benutzerfreundlichkeit sicherzustellen.

Eingabefelder außerhalb von Formularen

Diese Informationen gelten für alle Eingabefelder, die eine Text- oder Zahleneingabe erlauben – nicht jedoch für andere Input-Typen wie Checkboxes oder Radios. Ein Eingabefeld kann in Ausnahmefällen – außerhalb klassischer Formularstrecken – auf einem hellgrauen Hintergrund (layout/background/hued) platziert werden. Dies ist zum Beispiel dann sinnvoll, wenn es Teil einer kurzen Eingabemaske ist, die visuell vom übrigen Seiteninhalt abgegrenzt werden soll. Der Hintergrund des Feldes muss dann hell eingefärbt werden (layout/background-inverted).
Beispiel:

• Suchmaske auf einem Serviceportal

Dos und Don’ts

Label-Text sollte immer möglichst knapp und kurz formuliert sein und nicht mehrzeilig sein.

Nutze keinen Doppelpunkt am Ende eines Labels.

Ordne maximal zwei inhaltlich eng zusammengehörige Textfelder nebeneinander an. Bevorzuge zur besseren Erfassung die Anordung untereinander.

Schreibe Fehlermeldungen so prägnant wie möglich, gib immer Handlungsoptionen an. Tadele Nutzende nicht.

Nutze im Hinweistext (hint) keine Links. Diese werden von Screenreadern nicht als Links erkannt.

Schreibe Hinweistexte (hint) wenn möglich als ganzen Satz mit Punkt.

Kennzeichne lieber die wenigen optionalen Felder, als die Mehrzahl der Pflichtfelder.

Weitere Hinweise

• Erlaube das Kopieren und Einfügen von Inhalten sowie die Verwendung der „autocomplete“-Funktion in Eingabefeldern.
• Ein Leitfaden für gute Fehlermeldungen findet sich bei der German UPA.

Barrierefreiheit

Stelle sicher, dass Inputs für alle Nutzenden zugänglich sind, einschließlich Personen mit Beeinträchtigungen. Verwende geeignete ARIA-Labels und -Attribute und teste die Inputs mit Screenreadern. Sorge dafür, dass die Tab-Reihenfolge logisch und intuitiv ist, damit Nutzende problemlos durch die Inputs navigieren können.

disabled Attribut

Das Attribut disabled verhindert nicht nur die Interaktion mit einem Input, sondern macht es auch für Nutzende, die auf Tastaturnavigation angewiesen sind, unerreichbar. Elemente mit disabled können weder per Tabulatortaste fokussiert noch mit Screenreadern sinnvoll erfasst werden. Das bedeutet, dass Menschen, die eine Tastatur zur Navigation nutzen, das Input nicht erreichen oder ausfüllen können, selbst wenn sie die inhaltliche Information benötigen.
Ein häufiges Missverständnis ist, dass disabled eine gute Lösung sei, um bestimmte Inputs temporär zu deaktivieren. In Wirklichkeit führt dies jedoch dazu, dass betroffene Nutzende nicht einmal erfahren, dass dieses Input existiert oder warum es nicht verfügbar ist. Das kann besonders problematisch sein, wenn das Formular wichtige Abhängigkeiten zwischen Inputs hat und den Nutzenden keine alternative Möglichkeit gegeben wird, die Funktionalität zu verstehen oder zu nutzen.
Statt ein Input mit disabled zu versehen, ist es daher oft besser, es einfach vollständig auszublenden, wenn es nicht benötigt wird. Dadurch entsteht keine unnötige Verwirrung, und alle Nutzende haben die gleichen Möglichkeiten, mit der Oberfläche zu interagieren. Sollte das Input zu einem späteren Zeitpunkt wieder verfügbar sein, kann es dann dynamisch eingeblendet werden.
Falls eine Deaktivierung dennoch notwendig ist, sollte statt disabled besser aria-disabled="true" verwendet werden. Dies sorgt dafür, dass das Input zwar visuell als deaktiviert erscheint, aber weiterhin per Tabulator erreichbar und für Screenreader lesbar bleibt. Allerdings muss dann mit JavaScript sichergestellt werden, dass Funktionalitäten wie Events, Eingaben oder andere Interaktionen tatsächlich deaktiviert werden, um eine unbeabsichtigte Nutzung zu vermeiden.