Formulare

Overview

Formulare stellen Gruppen von Eingabetypen dar, die es den Nutzern erlauben, Daten einzugeben oder Optionen zu konfigurieren. Formulare können sehr einfach, aber auch sehr komplex ausfallen. Daher können diese, je nach Situation und Anwendungsfall, unterschiedlich dargestellt werden, wie z.B. in Modal Dialogen, als Teil einer Seite oder in dedizierten Seiten (z.B. Formularseiten).

Formular Beispiel

Respektiere die Nutzer!

Formulare dienen dazu Informationen vom Nutzer abzufragen. Damit Nutzer Formulare effizient und vollständig ausfüllen, sollten wir diese folgenden Punkte berücksichtigen:

• Respektiere den Datenschutz und die DSGVO, frage nur nach den absolut notwendigen Informationen.
• Gruppiere zusammengehöre Informationen und verwende Zwischenüberschriften für Feldgruppen, um dem Nutzer mehr Kontext zu bieten, sowie das Erfassen der Benutzeroberfläche für den Nutzer zu erleichtern.
• Folge einer logischen, erwartungskonformen Reihenfolge, z.B. erst kommt der Vorname, dann der Nachname.
• Denke daran, dass Nutzer zusätzliche Hilfsmittel wie Passwort Manager oder andere browser-basierte Mechanismen zum automatischen Ausfüllen von Formularen nutzen.
• Sequenziere die Informationen und Aktionen über mehrere Schritte, bzw. Bildschirme, um die Komplexität zu reduzieren. Siehe dazu auch „Progressive Disclosure“ unter Verhalten.

Guidelines

Verwendung

Formulare sind äußerst weit verbreitet in der Gestaltung von Benutzeroberflächen. Ihr Design und die Verwendung entwickeln sich mit neuen und intelligenteren Eingabetypen, sowie durch die zunehmende Nutzung von Smartphones und Tablets, immer weiter.

Verwende folgende Richtlinien, um zu entscheiden welche Variante eines Formulars die richtige ist:

Varianten

Modaler Dialog

Formular im Modal Dialog (Schema)

👍 Do	👎 Don't
Verwenden, wenn - kritische Nutzereingaben getätigt werden, die jedoch selten erforderlich sind, wie z.B. das Anmelden im System oder das Bearbeiten einer Unteraufgabe im Rahmen einer übergeordneten Aufgabe.	Nicht verwenden, wenn - eine höhere Komplexität der abgefragten Daten vorliegt. Verwende dazu besser eine eigene Seite wie z.B. die Formularseite

Eigene Seite

Formular auf eigener Seite (Schema)

👍 Do	👎 Don't
Verwenden, wenn - Komplexere oder längere Formulare in Datengetriebenen Anwendungen verwaltet werden müssen. Verwende dazu z.B. eine Formularseite oder einen Wizard. - Objekte aus einer Tabelle angezeigt und manipuliert werden sollen.	Nicht verwenden, wenn - Daten wie z.B. Unterobjekte im Rahmen einer Übergeordneten Aufgabe erzeugt oder abgefragt werden müssen. Verwende dazu ein Formular in einem Modal Dialog.

Wofür verwende ich welchen Eingabetyp?

Alternativauswahl (Radio button)

Bei einer Liste mit 2-5 Optionen, von denen nur eine ausgewählt werden kann. Dafür wird die Auswahl deaktiviert, wenn eine andere Auswahl aus der selben Liste aktiviert wird. Siehe Alternativauswahl ( Radio Button ) für weitere Informationen.

Mehrfachauswahl (Check box)

Bei Listen, in denen keine, eine oder mehrere Optionen ausgewählt werden können. Siehe Mehrfachauswahl ( Check box ) für weitere Informationen.

Auswahllisten - Dropdown-Liste (Dropdown), Kombinationsfeld (Combo box) oder Lookups

Verwende Auswahllisten, wenn mehr als 5 Optionen gegeben sind, von denen nur eine ausgewählt werden kann. Kombinationsfelder ermöglichen das Eingrenzen von Optionen durch die Eingabe von Text. Siehe Dropdown-Liste ( Drop down , Kombinationsfeld ( Combo Box )) und Lookups für weitere Informationen.

Texteingabe

Verwende einzeilige oder mehrzeilige Eingabefelder für eine freie Texteingabe. Siehe Eingabefeld ( Text field ) für weitere Informationen.

Weitere Leitsätze

Verwende nach Möglichkeit Alternativauswahlen (Radio Buttons), anstatt Auswahllisten wie Dropdown-Listen (Dropdown) und Kombinationsfeld (ComboBox). Dieser Eingabetyp ist mental weniger anstrengenden für den Nutzer, weil alle Optionen permanent sichtbar sind und so besser verglichen werden können. Alternativauswahlen (Radio Buttons) sind darüber hinaus einfacher zu bedienen und erfordern keine präzise Mausbewegungen.

Aufbau

Übersicht

Formular Aufbau Beispiel Ausgefüllt Einspaltig mit Erläuterungen

1. Labels

Labels klären den Verwendungszweck vom jeweiligen Eingabetyp. Kurze und klare Labels unterstützen den Nutzer dabei, die richtigen Informationen einzugeben.

• Achte auf die Groß- und Kleinschreibung und fange immer mit einem Großbuchstaben an.
• Bei Labels von Pflichtfeldern steht ein * am Ende. Unter den Tasten wird das * aufgelöst.
• Verwende keinen Doppelpunkt (😃 nach den Labels
• Labels stellen keinen Hilfetexte dar, halte sie kurz und bündig. Verwende 1 bis 3 Wörter.

Oben ausgerichtete Labels

Oben ausgerichtete Labels (im Vergleich zu links ausgerichteten Labels) sind die einzige im SYNneo Design System angebotene Variante im Moment. Sie stehen links auf einer Linie mit dem dazugehörigen Eingabefeld und räumlich nahe Zusammen. Das erleichtert die Erfassung vom Formular durch den Nutzer.

Weitere Vorteile:

* Die Ausrichtung oben ermöglicht eine schnelleres ausfüllen von Formularen
* Es ist mehr Platz für die Benennung der Labels gegeben, was auch für weitere Sprachen relevant sein kann.

2. Eingabefelder

Informationen können auf unterschiedliche Art und Weise, wie z.B. durch Mehrfachauswahlen (Checkboxen), Alternativauswahlen (Radio Buttons) oder Dropdown-Listen eingegeben werden. Besuche die einzelnen Komponenten, um weitere Details über deren Funktionsweise zu erhalten.

INFO

Der Range Selector ist kein zulässiger Eingabetyp.

3. Hilfestellungen

Verwende im jeweiligen Kontext z.B. Platzhalter Texte oder Hilfe-Texte unterhalb der Eingabefelder, damit die Nutzer die richtigen Informationen eingeben. Zusätzlich stehen Mechanismen zur Validierung bereit, um die Eingaben der Nutzer zu überprüfen und Hilfestellung zu leisten. Für allgemeine Erläuterungen können außerdem Inline-Hilfetexte verwendet werden.

Hilfe-Texte

Hilfe-Texte sind unterhalb der Eingabefelder verortet. Sie sind immer sichtbar, auch wenn das Feld fokussiert ist. Daher sind sie die richtige Wahl für Informationen, die der Nutzer unbedingt wissen sollte. Für „nice-to-have“ Informationen, die mehr über den Kontext oder den Hintergrund kommunizieren, sollten Platzhalter-Text oder Tooltip verwendet werden.

Hilfe-Texte

👍 Do	👎 Don't
- Verwende Hilfe-Texte als Ergänzung zum Label. - Drück dich so kurz und präzise wie möglich aus. - Verwende Hilfe-Texte nur, wenn sie wirklich notwendig sind, damit der Nutzer nicht überfordert wird.	- Verwende Hilfe-Texte nicht anstelle von Labels. - Hilfe-Texte sollten möglichst nicht über die Länge vom Eingabefeld ragen und auf keinen Fall länger als zwei Zeilen werden.

Platzhalter-Texte

Platzhalter-Texte

Platzhalter-Texte geben dem Nutzer Tipps oder Beispiele für die Eingabe zum Beispiel "TT.MM.JJJJ". Sobald der Nutzer mit der Eingabe beginnt, werden Platzhalter-Texte ausgeblendet. Daher sollten sie keine dringend erforderlichen Hinweise enthalten.

👍 Do	👎 Don't
- Drück dich so kurz wie möglich aus und überschreite nicht die Breite vom Eingabefeld. - Anonymisiere die Beispiele anstatt echte Daten zu verwenden.	- Verwende Platzhalter-Texte nicht. um komplexe oder langwierige Anforderungen wie z.B. Passwort-Richtlinien zu kommunizieren. Nutzer dafür Hilfe-Texte. - Verwende Platzhalter-Texte nicht, wenn sie nicht notwendig sind. - Verwende Platzhalter-Texte niemals als Ersatz für Labels

Inline-Hilfetexte

Inline-Hilfetexte

Für allgemeine Erläuterungen und Hilfestellungen, können Inline-Hilfetexte verwendet werden. Ein Inline-Hilfetext ist ein Text-Paragraph, welcher im Formular eingefügt werden kann. Der Inline-Hilfetext wird unter der Formularüberschrift oder zu Beginn von Feldgruppen platziert. Die Hilfestellungen sollten immer an der passenden Stelle eingefügt werden. Ein Inline-Hilfetext, der sich auf eine Formulargruppe bezieht, wird unterhalb der zugehörigen Feldgruppenüberschrift platziert. Ein Beispiel ist im ersten Bild "Kontaktformular" oben rechts auf dieser Seite dargestellt.

Tooltip

Für „nice-to-have“ Informationen und Inhalte, die das dazugehörige User Interface Element beschreiben, kann ein Tooltip verwendet werden. Ein Tooltip wird eingesetzt, um dem Nutzer ergänzende Textinformationen zu einem bestimmten Element anzuzeigen. Da der Tooltip nicht initial sichtbar ist, sollte dieser nicht für wichtige oder kritische Informationen eingesetzt werden. Für Informationen, die der Nutzer unbedingt wissen sollte, eignen sich Hilfe-Texte.

INFO

Weitere Anwendungsbeispiele sind unter Formular Layout / Anwendungsbeispiele / Erweiterte Hilfestellungen und Kontextinformationen zu finden.

4. Tasten

Tasten ermöglichen dem Nutzer, die Informationen zu senden oder einen Prozess abzubrechen.

Verwende eine primäre Taste für die Hauptaktion, z.B. das Abschicken eines Formulars. Verwende sekundäre Tasten zum Abbrechen oder Verwerfen.

Layout

Formularüberschrift

Die Formularüberschrift beschreibt das Formular. Diese sollte die größte Typographie in Bezug auf das Formular sein. In der Regel kann man dazu heading-l verwenden. Sollte das Formular in einem Modal-Dialog oder als Formularseite angezeigt werden, dann kann die Titelleiste dafür verwendet werden.

Optional kann noch eine kurze Einführung oder Beschreibung folgen.

Feldgruppenüberschrift

Die Feldgruppenüberschrift beschreiben eine Gruppe von Eingabefeldern innerhalb eines Formulars.

INFO

Verwende die Typographie Klasse synneo-heading-xs zur Darstellung der Feldgruppenüberschrift.

Die Eingabefelder sollten inhaltlich logisch zusammen gruppiert werden. Versuche die Feldergrupppenüberschriften kurz und prägnant zu gestalten.

Optional kann eine kurze Beschreibung folgen.

Formularspalten

Grundsätzlich empfehlen wir die Nutzung von einspaltigen Formularen. Diese sind weniger anfällig für Fehlinterpretationen durch den Nutzer und insgesamt leichter zu erfassen.

Große Bildschirme mit hohen Auflösungen bieten natürlich viel Raum, daher sind auch mehrspaltige Formulare zulässig. In manchen Situationen stellen diese auch eine angemessene Lösung dar.

Feldgruppen mit Feldgruppenüberschriften lassen sich z.B. gut in zwei Spalten auf breiten Monitoren darstellen.

	Beispiel Einspaltig
	Beispiel Zweispaltig

Verwende deinen gesunden Menschenverstand, um Felder horizontal in einer Formularspalte zu gruppieren.

Eingabefeld, Dropdown-Liste oder Kombinationsfeld in einer Spalte stellen in der Regel kein Problem dar, wenn sie zusammengehörig sind. Gute Beispiele dafür sind folgende:

[Vorname] [Nachname]

[Kreditkarten Ablaufdatum] [Kreditkarten Sicherheitscode]

[Postleitzahl] [Ort]

Einzelne Felder der oben genannten Typen nehmen immer die gesamte Breite der Formularspalte ein.

Weitere Richtlinien und Empfehlungen

Weitere Richtlinien und Empfehlungen zur Gestaltung von Formularen stehen unter Formular-Layout zur Verfügung.

INFO

<strong>Dev</strong>

Verwende zum layouten am besten das SYNneo Block Layout (Normal).

Blocklayout

BlockLayout blockLayout = new BlockLayout

Deprecated ⚠️

Verwende zum Layouten der Formularspalten und um die Breite der Felder zu kontrollieren das Form Layout. Konfiguriere die responsive Steps mit den folgenden Design Tokens:

--synneo-size-breakpoint-s

--synneo-size-breakpoint-m

--synneo-size-breakpoint-l

Buttons im Formular

Im Formular können Tasten für Aktionen verwendet werden. Die Buttons werden immer linksbündig in der Formularspalte angeordnet. Folgendes Beispiel zeigt eine Taste im Formular, welche dem Nutzer die Option bietet, die Lieferadresse als Rechnungsadresse zu übernehmen.

Buttons für abschließende Funktionen

Die Buttons für abschließende Funktionen eines Formulars befinden sich entweder unter dem Formular linksbündig, wobei die primäre Aktion immer rechts angeordnet ist, oder in der Funktionsleiste, falls das Formular im Wizard, Modal Dialog oder auf einer Formularseite eingesetzt wird.

Ausblick

Designer verwenden oft Regeln um Informationen in Formularen zu gruppieren und zu gestalten. Das SYNneo Design System Team hat diese bisher noch nicht konsolidiert. Dies ist jedoch geplant um mehr Empfehlungen und Regeln zum gestalten von Formularen bereitzustellen.

Verhalten

Das Verhalten der unterschiedlichen Eingabetypen ist auf den jeweiligen Seiten beschrieben. Besuche diese Seiten für weitere Informationen.

Progressive Disclosure

Progressive Disclosure ist eine Design-Technik zur Sequenzierung von Informationen und Aktionen über mehrere Schritte bzw. Bildschirme, um Komplexität zu reduzieren. Durch die zunehmende Offenlegung von Informationen werden zunächst grundlegende und dann die weiterführenden Funktionen dargeboten. Die Reihenfolge der dargestellten Informationen erfolgt dabei vom „Abstrakten“ zum „Spezifischen“.

Das Prinzip lässt sich durch den Einsatz der Prozessnavigation und Bedienmuster Wizard auf weitere Bildschirme ausweiten.

👍 Do	👍 Do	👎 Don't	👎 Don't
Blende vertikal abhängige Felder in einer Formularspalte immer vollständig aus.	Horizontal abhängige Felder in einer Formularspalte sollten deaktiviert dargestellt werden, damit sich die Felder Größen zwischen beiden Zuständen nicht anpassen muss.	Schalte vertikal abhängige Felder nicht auf deaktiviert, um sie später zu aktivieren.	Horizontal abhängige Felder sollten nicht vollständig aus dem Layout entfernt werden, denn somit müssten sich die Größen der Felder zwischen den Zuständen ändern.

Defaultwerte

Defaultwerte sollten immer kritisch hinterfragt werden, da Nutzer dazu tendieren, sie nicht anzupassen. Wenn sie intelligent gewählt werden, können sie allerdings sehr sinnvoll sein (z.B. Land vorauswählen auf Grundlage der Geo-Location).

Validierung

Effektive und zeitnahe Fehlermeldungen können den Nutzern helfen das Problem zu verstehen und es zu lösen. Informiere zuerst die Nutzer darüber, was geschehen ist, und unterstütze sie dabei, die Probleme zu lösen. Beispiele für Standardfehlermeldungen sind unter dem Punkt Fehlermeldungen in den Foundations aufgeführt.

Generelle Richtlinien

Der Grund der Formular Validierung ist, Fehler in Formularfeldern nicht zustande kommen zu lassen. Die Validierung kann in verschiedenen Dimensionen stattfinden. Die einfachste Validierung prüft, ob der Inhalt eines Formularfeldes vorhanden oder nicht vorhanden ist oder ob der Inhalt dem richtigen Format entspricht.

Validierung bei "Eingabe"

Das gesamte Formular wird validiert.

Wenn es mehr als ein Formular auf der Seite gibt, werden nur die Eingabefelder in dem Formular validiert, das zuletzt im Fokus war. Dies kann auch abhängige Eingabefelder in anderen Abschnitten umfassen.

Wenn der Benutzer einen Wert durch Drücken der Eingabetaste auswählt, wird der Wert ausgewählt, ohne eine Validierung auszulösen (z. B. bei der Übernahme eines Vorschlags oder der Eingabe eines Werts in ein Kombinationsfeld). Der Benutzer muss dann ein zweites Mal die Eingabetaste drücken, um die vollständige Formularvalidierung auszulösen.

Etwaige Fehler oder Warnungen werden in einem Fehler Callout angezeigt.

Bei der Validierung der eingegebenen Daten wird eine Kombination der beiden folgenden Techniken verwendet:

Pre-Submit-Validierung

Wir empfehlen die Validierung einzelner Felder vor dem Abschicken des gesamten Formulars. Diese „Feldweise-Echtzeit-Validierung“ sollte stattfinden, sobald das Feld seinen Fokus verliert. Das hilft den Nutzern dabei, die Elemente zu identifizieren, die korrigiert werden müssen.

Die Fehleranzeige erfolgt in diesem Fall mittels Inline-Text Meldungen direkt unterhalb vom Feld. Die Meldung sollte so informativ wie möglich sein z.B. wenn ein Feld für Passwörter 16 Zeichen erwartet, der Nutzer jedoch nur 8 eingegeben hat, dann sollte der Text in etwa lauten: „Das Passwort muss mindestens 16 Zeichen lang sein.“

Übliche Fehler, die so entdeckt werden können sind z.B.:

• Falsch formatierte Eingaben

• Nicht ausgefüllte Pflichtfelder

• Unvollständig ausgefüllte Pflichtfelder

	Pre-Submit Validierung Beispielhafte Darstellung für ein nicht ausgefülltes Pflichtfeld, welches, nachdem es den Fokus verloren hat, eine Fehlermeldung anzeigt.
	Feldgruppenübergreifene Pre Submit Validierung Einfache Feldgruppen wie z.B. „Datum von - Datum bis“ können felderübergreifend auf diese Weise validiert werden, z.B. nachdem das letzte beteiligte Feld verlassen wird.
	Einfach Serverseitige Validierung Einfache serverseitige Validierungen können ebenfalls auf diese Weise durchgeführt werden.

Post-Submit-Validierung

Die Post-Submit Validierung findet statt, nachdem der Nutzer auf die Taste zum Abschicken vom Formular geklickt hat.

Im ersten Schritt sollten erneut alle einzelnen Felder validiert werden, damit z.B. sichergestellt ist das alle Pflichtfelder ausgefüllt sind.

Nach dem Klick auf die Taste zum Abschicken des Formulars, werden alle fehlerhaften Felder als solche markiert und der Fokus auf das erste fehlerhafte Feld gelegt.

Wenn es mehr als ein Formular auf der Seite gibt, werden nur die Eingabefelder in dem Formular validiert, das zuletzt im Fokus war. Dies kann auch abhängige Eingabefelder in anderen Abschnitten umfassen.

Wenn der Benutzer einen Wert durch Drücken der Eingabetaste auswählt, wird der Wert ausgewählt, ohne eine Validierung auszulösen (z. B. bei der Übernahme eines Vorschlags oder der Eingabe eines Werts in ein Kombinationsfeld). Der Benutzer muss dann ein zweites Mal die Eingabetaste drücken, um die vollständige Formularvalidierung auszulösen.

Formularübergreifende Validierung

Im nächsten Schritt können formularübergreifende Validierungen stattfinden, um komplexerer Businesslogik gerecht zu werden.

Übliche Fehler, die so entdeckt werden können:

• Fehler, die sich aus einer Kombination von mehreren Feldern ergeben bzw. durch die Manipulation von einem oder allen beteiligten Feldern korrigiert lassen.

• Fehler, die sich nicht im Kontext von dem aktuellen Formular lösen lassen, weil gewisse Vorbedingungen nicht gegeben sind oder die sich während der Bearbeitung geändert haben.

Nach dem Klick auf die Taste zum Abschicken vom Formular, werden alle identifizierten Fehler über dem Formular in der Callout Komponente - Variante Fehler aufgelistet, ggf. werden beteiligte Felder als fehlerhaft markiert und der Fokus wird auf die Überschrift der Fehlerliste gesetzt.

Für das Verhalten bzgl. der Validierung von Mehrseitigen Formularen siehe das Bedienmuster [Veraltet] Wizard.

Buttons

Submit-Taste zum Abschicken vom Formular

Jedes Formular verfügt über eine Submit-Taste mit der das Formular abgeschickt werden kann. Da dies die primäre Aktion in diesem Muster ist, wird dafür eine primäre Taste verwendet.

Je nach Kontext kann die Submit-Taste einen andere Titel haben wie z.B. „Speichern“ oder „Abschicken“.

In jedem Fall hat sie die Funktion das Formular als Ganzes abzuschicken und stößt die Post-Submit Validierungen an.

Sobald das Formular aufgerufen wird, steht die Submit-Taste aktiv zur Verfügung, unabhängig davon ob in den Feldern Daten enthalten sind oder diese geändert wurden.

Lediglich nach dem Klick auf die Taste wird diese für die Dauer der Übertragung und bis eine Rückmeldung erfolgt deaktiviert. Damit wird ein versehentliches, mehrfaches Abschicken eines Formulars vorgebeugt.

Ausblick

Weitere Mechanismen zur Rückmeldungen vom System Zustand wie z.B. um den Ladezustand zu visualisieren, sind in Planung.

Abbrechen

Die Bearbeitung eines Formulars lässt sich ggf. durch die "Zurück"-Taste im Browser oder ggf. über eine "Abbrechen"-Taste abbrechen, ohne dass die Änderungen gespeichert werden.

Um versehentlichen Datenverlust zu vermeiden, muss jeder Abbruch bestätigt werden (siehe Modaler Dialog – Gefahrenvariante).

Verwende im Modal Dialog z.B. folgenden Text:

Titel: "Eingaben verwerfen?"

Text: "Sind Sie sicher, dass alle bisherigen Eingaben verworfen werden sollen?"

Sekundäre Taste: "Weiter bearbeiten"

Gefahren Taste (rot): "Eingaben verwerfen"

Nach dem Abbrechen sollte der Kontext angezeigt werden, den der Benutzer vor dem Öffnen hatte.

Fehlermeldungen

Fehlermeldungen sollen ganze Sätze, sowie knapp und höflich formuliert sein. Zusatzworte wie "bitte” sollten vermieden werden. Die Sprache des Systems wird dadurch beiläufiger und alltäglicher. Je näher die Meldung an einem Textfeld steht umso knapper kann sie sein. Eine Meldung die über dem Formular steht soll Feldname oder Feldinhalt beinhalten, wenn dies zum Verständnis des Fehlers beiträgt. Die Fehlermeldung benennt immer das Problem. Optional bietet sie einen kurzen Text als Hilfestellung. Sie soll und kann eine fachliche Hilfe nicht ersetzen.

Best Practices

👎 Don't	👍 Do	👍 Do
Weist der Fehlertext auf ein komplexeres Problem hin, das nicht nur ein Feld betrifft, muss die exakte Problemstellung adressiert werden und alle involvierten Felder müssen als fehlerhaft dargestellt werden.	Hier wird genauer beschrieben und auch hervorgehoben, welche Felder-Überschneidung gemeint ist.	Ist der Fehler zu komplex ist oft ein Error Call-out passender, da er für die gesamte Seite gilt. Ein modaler Dialog reißt den User aus dem Kontext des Formulars und sollte deshalb immer vermieden werden.

👎 Don't

👍 Do

Unnötig komplexe Validierung auf beiden Feldern.

Das zweite Datumsfeld ist immer das letzte Feld, das von den Nutzern befüllt wird. Daraus ergibt sich der Fehlerzeitpunkt und der Auslöser. Das bedeutet, dass das zweite Feld den Fehler auslöst und diesen kommuniziert. Dem User ist es nun überlassen, das zweite oder erste Feld zu editieren, um den Fehler zu beseitigen. Im Fehler wird nur die Logik kommuniziert (Feld 1 < Feld 2). Dabei kann der User den Wert von Feld 1 reduzieren oder den von Feld 2 erhöhen.

👎 Don't	👍 Do	👍 Do
Das oben gezeigte Beispiel ist ein konzeptioneller Fehler. Für entweder/oder Entscheidungen zwischen Feldern gibt es die Radio-Auswahl.	Gibt es zwischen Feldern eine entweder/oder Verknüpfung sollte diese über die Radio-Buttons explizit gemacht werden. Erst in der Folge geht es um den Betrag. Das verringert die Fehlerhäufigkeit substanziell, da dem Nutzer die von ihm erwartete Entscheidung explizit dargestellt wird und nur diese eine Entscheidung verlangt wird. Durch Fokus setzt er den Radio-Button auf selektiert.	In diesem Fall wird also nur noch gewarnt, wenn der Nutzer die Betragsart Radio Gruppe übersieht. Dafür gibt es Standard-Fehlermeldungen, die der Nutzer bei Wiederholung besser lernt.

👎 Don't	👍 Do	👍 Do
Fehlerhinweise als Dialoge zeigen nicht auf den Ort der falschen Eingabe. Sie sind deshalb in Formularen meistens ungeeignet.	In Formularen sind Fehler Call-outs im Kopfbereich des Formulars dann passender, wenn das Formular nicht abgeschickt werden konnte.	In seltenen Fällen gibt es auch Dateneeingabe in Dialogen mit nur wenigen Feldern. Hier kann man den Hilfetext manchmal auslassen, da das Fehlen des Werts offensichtlich ist.

Barrierefreiheit

Beim Erstellen von Formularen sollten Sie die spezifischen Barrierefreiheitspunkte der Komponenten, die Sie verwenden möchten, kennen.

Die größte Herausforderung liegt darin die Tastaturbedienbarkeit zu gewährleisten, damit die Felder in der richtigen Reihenfolge fokussiert werden können und die Submit-Taste jederzeit erreicht und ausgelöst werden kann. Nach der Betätigung der Submit-Taste, muss im Fehlerfall entweder das erste fehlerhafte Feld oder die Überschrift der Fehlerliste programmatisch fokussiert werden.

Develop Vue

Die Implementierung der Webcomponenten in Vue.js kann in folgendem Showcase innerhalb des AKDB Netzwerks betrachtet werden: https://mate-ds-vue-components-showcase-25.core-platform.kubt.akdb.net/?path=/docs/pattern-form-layout--docs

Develop Flow

Der Showcase ist innerhalb des AKDB Netzwerks zu finden unter: https://mate-ds-flow-components-showcase-25.core-platform.kubt.akdb.net/?src=pattern%252Fform