1. Titelzeile
2. Inhaltsbereich
3. Fußzeile

1. Formulartitel
2. Button “Weitere Aktionen”
3. Badge

1. Sektion
2. Titel der Sektion
3. Auf-/Zuklappen Funktion
4. Badges (optional)
5. Inhaltsbereich

1. “Rückgängig machen”-Button
2. “Wiederholen”-Button
3. Trennlinie
4. “Schließen”-Button
5. “Speichern”-Button

1. Gruppentitel
2. 1-n Badges
3. Entfernen-Button
4. Inhaltsbereich

1. Titel
2. Badge (optional)
3. Bearbeiten-Funktion
4. Inhalte

Jedes Formular besteht aus einer Kopfzeile (Header), dem Inhalt und einer Fußzeile (Footer). Diese müssen als Regionen ausgezeichnet werden:

• Titelzeile: “Titelzeile-Formular”
• Inhalt: “Inhalt-Formular”
• Fußzeile: “Fußzeile-Formular”

Das Formular ist im Code als Region gekennzeichnet, deren Beschriftung sowohl den Formulartitel als auch den Badgetext beinhaltet im Format “[Formulartitel] – [Badgetext]”.

Innerhalb eines Formulars werden Elemente entsprechend der visuellen und inhaltlich logischen Reihenfolge mit der Tabulatortaste fokussiert. 

Optional können auf-/zuklappbare Zwischensektionen (Akkordeons) oder Formularfeldgruppen (siehe unten: Formularfeldgruppen) verwendet werden.

Formulare sind entweder direkt auf, der in der Regel, hellgrauen Hintergrundfläche positioniert, oder als Modal zentriert in der Fenstermitte. 

Bei Anzeige auf dem grauen Hintergrund besteht jeweils ein Abstand von 48 Pixeln nach oben und unten zum nächsten Element. In der Vertikalen fügen sie sich an das jeweilige Seitenlayout ein (siehe Raster und Breakpoints).

Bei Anzeige in der Modalansicht wird der Hintergrund mit einer halb transparenten Fläche abgedunkelt. Elemente im Hintergrund sind dann nicht mehr mit der Tastatur erreichbar und sind auch mit der Maus nicht mehr bedienbar.

Falls der Inhalt des Modals zu hoch ist, so dass Scrollen erforderlich ist, bleibt ein Abstand von 48 Pixeln zum oberen und unteren Fensterrand bestehen.

Das Modale Formular hat eine Maximalbreite von 800 Pixeln. Bei Bildschirmbreiten unter 800 Pixeln bleibt ein Abstand zum Fensterrand von 32 Pixeln nach rechts und links bestehen. 
Bei Bildschirmbreiten oder -höhen unter 560 Pixeln nimmt das Formular die komplette Bildschirmbreite und -höhe ohne Abstand zum Rand ein. 

Ab einer Formularhöhe unter 672 Pixeln ist der Header des Formulars nicht mehr sticky, d.h. er verschwindet beim Scrollen. Der Footer bleibt sticky. 

Unterhalb von 432 Pixeln Formularhöhe bleibt auch der Formularfooter nicht mehr sticky.

Im Formular gelten in der vertikalen folgende Abstandsregeln zwischen Elementen (gültig für alle Formularbreiten):

Header

• Header zu Formularinhalt: 48px
• Header zu Fehlerbanner: 0px
• Header zu Hinweisbanner: 0px
• Header zu Akkordeon: 0px
• Fehlerbanner zu Hinweisbanner: 0px
• Fehlerbanner zu Formularinhalt: 48px
• Hinweisbanner zu Formularinhalt: 48px

Akkordeons

• Akkordeon zu Akkordeoninhalt: 32px
• Akkordeon (geschlossen) zu nächstem Akkordeon: 0px
• Akkordeoninhalt zu nächstem Akkordeon: 48px
• Akkordeon zu Hinweisbanner (Hinweisbanner Typ 2): 0px
• Hinweisbanner zu Akkordeoninhalt: 32px

Eingabe-/Auswahlfelder

• Formularfeld zu Formularfeld: 24px (Gilt für alle Eingabe- und Auswahlfeldtypen inklusive Radio- und Checkboxgruppen)

Element-Gruppen

• Gruppe zu Gruppe: 32px
• Gruppe zu “Gruppe hinzufügen”-Button: 32px
• “Gruppe hinzufügen”-Button zu nächstem Eingabe-/Auswahlfeld oder Gruppe: 48px

Tabellen/Listen

• Tabelle/Liste zu Tabelle/Liste: 48px
• Tabelle/Liste zu nächstem Eingabe-/Auswahlfeld oder Gruppe: 48px
• Tabelle/Liste zu “Element hinzufügen”-Button: 32px

Zwischenüberschriften

• Eingabe-/Auswahlfeld zu Zwischenüberschrift: 48px
• Zwischenüberschrift zu folgendem Eingabe-/Auswahlfeld oder Tabelle/Liste: 24px
• Zwischenüberschrift zu folgendem Hinweistext (Hinweis Typ 3): 8px

Hinweistexte (Hinweise Typ 3)

• Hinweistext zu nächstem Element: 32px

Formularfeldunabhängige Validierungsfehler

• Vorheriges Element zu Validierungsfehler: 32px (falls nicht das erste in einem Inhaltsbereich; dann 0) 
• Validierungsfehler zu nächstem Element: 32px

Footer

• Hinweisbanner zu Footer: 0px
• Formularinhalt zu Footer: 80px

(immer wenn hier von “Eingabe-/Auswahlfeldern” gesprochen wird, werden hier alle Typen einzeilig/mehrzeilig/durchsuchbar/... gemeint einschließlich der Elemente Radiobutton, Checkboxen, Toggle-Elemente)

Stickieness

• Ab einer Formularhöhe unter 672 Pixeln ist der Header des Formulars nicht mehr sticky, d.h. er verschwindet beim Scrollen. Der Footer bleibt sticky. 
• Unterhalb von 432 Pixeln Formularhöhe bleibt auch der Formularfooter nicht mehr sticky.

Innerhalb des Formularbereichs wird ein vom Seitenlayout abweichendes Grid verwendet (siehe Raster & Breakpoints)

Das Formularraster besteht aus 12 Spalten mit einem fixen Spaltenabstand von jeweils 16 Pixeln. Der Abstand zum Formularrand beträgt bei allen Formularbreiten überhalb von 720 Pixeln 88 Pixel. Die Spaltenbreiten passen sich dementsprechend an (je nach Gesamtbreite des Formularbereichs).

Innerhalb einer Formulargruppe wird erneut ein 12-Spaltiges Raster angewendet, in dem Formularfelder platziert werden können. Spaltenabstände je 16px.

Durch die im folgenden definierten Maximal- und Minimalbreiten von Formularfeldern ist sichergestellt, dass mögliche Validierungsfehler noch unter dem Feld dargestellt werden können. Sie gelten für alle diese Formularelemente: 

• Alle Typen von Eingabefeldern
• Alle Typen von Auswahlfeldern

Folgende Elemente füllen unabhängig von der Formularbreite immer alle 12 Spalten des Formularrasters:

• Tabellen
• Listen
• Baumstrukturen
• Elementgruppe
• Elementliste mit löschbaren Einträgen
• Mehrzeilige Eingabefelder
• Mehrfachauswahlfelder
• Checkboxen und Checkbox-Gruppen
• Radio-Buttons und Radio-Button-Gruppen 
• Responsiver Umbruch von Check-Box- und Radio-Button-Gruppen (wie am Element definiert ist weiter erlaubt)

Somit können nie zwei Elemente dieser Typen nebeneinander angeordnet werden.

Einzelne Buttons (außer sie gehören zu einer Komponente, wie beispielsweise der Entfernen-Button von Formularfeldern oder Gruppen) werden immer in einer eigenen Zeile platziert.

Bei semantisch zusammenhängenden Feldern wie Beispielsweise Straße + Hausnummer oder Postleitzahl + Ort ist darauf zu achten, dass diese sich in mehrspaltigen Layouts (alle Formularbreiten über 480 Pixel) für alle Screengrößen nebeneinander befinden und nicht voneinander getrennt umbrechen.

TABLE

Die unterstützte Minimalbreite von Formularfeldern beträgt 320 Pixel.

Falls in einer Zeile mehrzeilige Labels, Hinweistexte am Feld oder Validierungsfehler vorkommen, so wird das Element entsprechend höher und die darauf folgende Zeile rutscht als ganzes nach unten.

Einzelne Buttons in Formularen rutschen immer in eine eigene neue Zeile und werden nicht neben anderen Eingabe/Auswahlelementen angezeigt. Eine Ausnahme bilden Buttons, die Teil einer Komponente sind (wie beispielsweise Entfernen-Buttons an Formularfeldern oder Formularfeldgruppen) – diese dürfen auch neben anderen Elementen platziert sein.

Durch die Auswahl eines Wertes in einem Auswahlfeld, können Folgefelder eingeblendet bzw. aktiviert werden. Wurden die Folgefelder befüllt und der Wert im ersten Auswahlfeld wird anschließend geändert, so wird der Inhalt der Folgefelder standardmäßig zurückgesetzt/geleert. Dies geschieht im Standardfall ohne, dass vor Zurücksetzen eine Sicherheitsabfrage erscheint.
Die Aktualisierung der Folgefelder findet erst dann statt, wenn ein Nutzer den entsprechenden Wert in der Auswahlliste ausgewählt hat. Die Aktualisierung erfolgt nicht beim Navigieren in der Auswahlliste.

Wird der Initialzustand durch Auswahl des Wertes “–” (wenn kein Pflichtfeld) oder mit der Rückgängig-Funktion wiederhergestellt, so werden die Folgefelder wieder geleert und deaktiviert bzw. ganz ausgeblendet.

Sonderfall, wenn es sich bei dem Feld mit Konsequenzen für Folgefelder um ein durchsuchbares Auswahlfeld handelt: Wurde bereits ein Wert ausgewählt und die Folgefelder befüllt und anschließend wird in dem durchsuchbaren Auswahlfeld ein ungültiger Wert eingegeben und das Feld wird verlassen, so wird der entsprechende Fehler am Feld angezeigt (siehe Element durchsuchbares Auswahlfeld). Die nachfolgenden Felder bleiben befüllt, werden jedoch als deaktiviert dargestellt. Wird anschließend im durchsuchbaren Auswahlfeld ein neuer gültiger Wert ausgewählt, so werden die Folgefelder zurückgesetzt. Wird der alte Wert wieder ausgewählt, so bleiben die vorherigen Werte bestehen und die Felder werden wieder aktiviert. 

Werden Felder zurückgesetzt/geleert, an denen vorher Validierungsfehlermeldungen bestanden, so werden auch die Fehlerzustände an den geleerten Feldern entfernt. Dies gilt auch für die Standardmeldung “Pflichtfeld nicht befüllt.” Wurden diese Fehler zu dem Zeitpunkt bereits im Fehlermeldungsbanner am Formularkopf angezeigt, so werden die entprechenden Einträge im Meldungsbanner deaktiviert.

Wichtig: Durch eine Wertänderung im Auswahlfeld dürfen immer nur nachfolgende Felder aktualisiert werden. Eine Wertänderung darf sich nie auf darüberliegende Elemente auswirken.

Falls Abhängigkeiten zwischen Feldern über mehrere Formularebenen hinweg bestehen, also zwischen Eltern- und Kindformularen, können Absprünge in Kindformulare temporär verhindert werden, wenn im Elternformular Eingaben entfernt oder Fehler generiert werden, welche mit dem Kindobjekt in Verbindung stehen.

Im Fall eines erzeugten Fehlers an einem solchen Formularelement im Elternformular wird standardmäßig zum Zeitpunkt der Wertübernahme der Akkordeoninhalt, in dem die Unterobjekte gelistet sind (als Tabelle oder als Karten) temporär durch einen Platzhalter ersetzt (Details zu Platzhalter siehe Akkordeons). Der Platzhalter weist darauf hin, dass die Inhalte des Akkordeons und damit die Absprünge in die Unterobjekte erst wieder nach Erfüllung einer Bedingung, z. B. der Befüllung eines Pflichtfeldes oder Behebung von Fehlern, sichtbar und bearbeitbar sind. Im Hinweistext ist so genau wie möglich zu beschreiben, welche Nutzeraktion zum Reaktivieren der Akkordeoninhalte erforderlich ist. Nach Ausführen der entsprechenden Nutzeraktion, bspw. dem Beheben der zuvor erzeugten Fehler im Hauptformular, verschwindet der Platzhalter und die Unterobjekte werden wieder sichtbar und bearbeitbar.

Wann das temporäre Erscheinen des Platzhalters vorkommt, welche Feldbearbeitung dieses auslösen kann und welche Bearbeitung den Platzhalter wieder entfernt, wird durch die Fachlichkeit definiert und ist daher in Userstories im Detail zu beschreiben.

Falls es fachlich gewünscht ist, so können Werte in den Folgefeldern bei einer Wertänderung auch übernommen werden. Falls dies der Fall sein soll, so ist dies in den Userstories zu beschreiben. Dies ist nur dann zu empfehlen, wenn die Folgefelder identisch sind (gleiche Bezeichnung).

Falls bei einer Wertänderung eine Sicherheitsabfrage erscheinen soll, so ist dies ebenfalls in den Userstories zu beschreiben. Dies ist zum Beispiel dann sinnvoll, wenn durch die Wertänderung sehr viele Daten zurückgesetzt werden, muss aber je nach fachlicher Relevanz im Einzelfall entschieden werden. Details zum Anzeigezeitpunkt, Fokussetzung und Verhalten (siehe Modialog: Sicherheitsabfrage) sowie bezüglich der Formulierung der Sicherheitsabfrage (siehe Meldungskonzept: Sicherheitsabfragen - Formulierungsregeln) sind in den entsprechenden Abschnitten zu finden.

Der Formular Header kann folgende Elemente beinhalten:

• Titel des Formulars: Der Titel entspricht dem Schrifttyp H2. Je nach Seitenkontext ist der Formulartitel aber im Code als “H1” oder “H2” auszuzeichnen (siehe Definition der Seitentypen). Ist der Titel länger, wird er mehrzeilig dargestellt und der Formular Header wird entsprechend höher. Je nach dem, ob es sich beim Formular um ein Haupt-/Unter-/Nebenobjekt handelt und ob es eine Neuanlage oder Bearbeitung ist, gelten unterschiedliche Formulierungsregeln (Details siehe Navigationskonzept innerhalb GeFa: Übersicht der Objekttypen).
• (optional) Badge: Dieser dient zur Darstellung des Status, in dem sich das geöffnete Objekt befindet. 
• (optional) Menü-Button mit weiteren Aktionen (Icon mit drei Punkten). Der Alternativtext des Buttons lautet: “Weitere Aktionen”. Auch wenn nur eine einzige Aktion enthalten ist, ist diese über den 3-Punkte-Button mit Pop-Up-Menü aufrufbar.

Die Ausgabereihenfolge für den Screenreader ist: Zuerst Formulartitel, dann der Status-Badge, dann der “Weitere Aktionen”-Button.

Der Formular Header ist bis zu einer Formularhöhe von 672 Pixeln sticky. Bei kleineren Formularhöhen verschwindet er beim Scrollen.

Ein Sonderfall ist der Status “Auskunfssperre” bei einer Person. Da diese sehr wichtige Information von Nutzenden zuerst gelesen werden und sofort ins Auge stechen muss, ist dieses Badge über dem Formulartitel positioniert und der komplette Formular Header färbt sich außerdem gelb. Außerdem ertönt beim Öffnen eines Formulars ein akustischer Signalton vom Typ Hinweis/Warnung (siehe Akustische Signale). 

Damit die wichtige Information für Nutzer:innen sofort erkennen ist, wird das “Auskunftssperre-Badge” am Anfang des Formulartitels hinterlegt und gemeinsam ausgelesen. Die Hauptüberschrift des Formulars setzt sich also in diesem Fall aus Badge und Formulartitel zusammen. Die Ausgabereihenfolge für den Screenreader ist: Zuerst Status-Badge, dann Formulartitel, dann “Weitere Aktionen”-Button. 
Während der Formulartitel normalerweise bei unter 672 Pixeln nicht mehr sticky ist, bleibt das Label “Auskunftssperre” auch bei kleineren Screengrößen sticky und somit immer sichtbar.

Der Formular Header ist bis zu einer Formularhöhe von 672 Pixeln sticky. Bei kleineren Formularhöhen verschwindet er beim Scrollen.

Der Formular Footer enthält verschiedene Aktionsbuttons zum Bearbeiten oder Schließen des Formulars:

• Sekundärer Schließen-Button (immer vorhanden)
• Sekundäre Rückgängig- und Wiederholen-Buttons 
• Primärer Aktionsbutton: 
• • Bei Hauptobjekten: Anlegen/Speichern
  • Bei Unterobjekten: Hinzufügen/Übernehmen
  • Bei Nebenobjekten: Zuordnen/Speichern
  • Für spezielle Aktionen auch andere Buttonbenennungen möglich

Kann ein Formular nicht mehr durch eine Nutzeraktion bearbeitet werden (Beispiele: GVPs, welche sich bereits im Status “In Verwendung” befinden; Formulare in Verfahren, welche bereits den Status “Weggelegt” haben), so wird im Formular Footer nur noch der Schließen-Button angezeigt und alle Formularfelder werden im Read-only-Zustand angezeigt. 

Wenn ein Formular generell editierbar ist, nur der Nutzer keiner Bearbeitungsrechte dafür besitzt, werden Primär- sowie Rückgängig- und Wiederholen-Button dauerhaft deaktiviert angezeigt und alle Formularfelder werden ebenfalls im Read-only-Zustand angezeigt.

Sobald in einem Formular mindestens ein Zeichen hinzugefügt/entfernt oder geändert wurde, wird der primäre Aktionsbutton aktiv und klickbar. Gleichzeitig wird auch der Rückgängig-Button (Undo) im Footer des Formulars aktiv und klickbar – Im Fall von Änderungen in Eingabefeldern allerdings erst bei Verlassen des Feldes. Nachdem eine oder mehrere Eingabe/n rückgängig gemacht wurde, wird der “Wiederholen”-Button (Redo) aktiv.

Nachdem die Aktion “Schließen” ausgeführt wurde, wird das Formular geschlossen und Änderungen werden nicht gespeichert. Falls ungespeicherte Änderungen vorliegen und die Aktion “Schließen” ausgeführt wird, erscheint eine Meldung vom Typ Sicherheitsabfrage.

Wenn Änderungen durchgeführt wurden und die Primäraktion im Footer eines Haupt- oder Nebenformulars (Anlegen/Speichern/Zuordnen) ausgeführt wird, so läuft im Button eine Animation ab, welche den Fortschritt des Speichervorgangs anzeigt (siehe unten: Erfolgsindikatoren):

• Sobald Primärbutton geklickt wurde, wird ein rotierendes Ladesymbol (loading spinner) innerhalb des Buttons angezeigt. Der Alternativtext des Symbols lautet “Wird gespeichert”. Bei fokussiertem Button oder Mouse-Hover über den Button wird dieser ebenfalls als Tooltip angezeigt. Das Ladesymbol wird vom Screenreader automatisch ausgegeben, ohne dass der Systemfokus auf die Grafik gezogen wird. Allerdings wird der Text erst 2 Sekunden nach Ausführen der Aktion “Speichern” ausgegeben, um zu viel Audionoise zu vermeiden. Falls das Laden noch länger dauert, wird alle 10 Sekunden erneut der Alternativtext des Ladesymbols ausgelesen, unabhängig davon, wo sich der Fokus auf der Seite zu der Zeit befindet. Während sich der Button in diesem Ladezustand befindet, werden alle Maus- und Tastatureingaben innerhalb des Formulars ignoriert. Alle enthaltenen interaktiven Elemente werden für diese Zeit aus der Tabreihenfolge ausgenommen. Außerdem wird der Formularinhalt mit einer weißen Fläche von 50% Deckkraft überlagert. Der Undo-Button wird während des Speicherns deaktiviert. Sollte das Speichern (z. B. wegen Validierungsfehlern) nicht erfolgreich sein, so wechselt der Undo-Button in den aktiven Zustand zurück und der vorherige Undo-Stack bleibt erhalten.
• Falls Validierungsfehler im Formular festgestellt werden, wird das entsprechende Fahlerbanner angezeigt (siehe unten: Validierungsfehlern an Formularen). Der Speichern-Button springt wieder zurück zum Standard-Status (aktiv ohne Ladeanimation).
• Falls keine Validierungsfehler festgestellt werden und das Speichern erfolgreich durchgeführt wurde, so wird für eine Sekunde ein Häkchen-Symbol angezeigt. Dieses ist als Layoutgrafik deklariert. Gleichzeitig ertönt ein akustisches Signal: Erfolgsmeldung (siehe Akustische Signale). Danach wird der Button disabled und der Fokus wechselt auf den “Schließen”-Button.
• Falls Modaldialoge vom Typ (technische) Fehlermeldungen erscheinen, ist der Footer erst dann wieder bedienbar, wenn die Aktion im Dialog ausgeführt wurde. Im Fall, dass die Seite neu geladen wird und das Formular geöffnet bleibt, springt der Footer in den Status zurück, der keine ungespeicherten Eingaben enthält. Wird durch die Dialogaktion die Seite nicht neu geladen, so wird der Status beibehalten der vor dem Dialog aktiv war.

Wenn Änderungen durchgeführt wurden und die Primäraktion im Footer eines Unterformulars (Hinzufügen/Übernehmen) ausgeführt wird, so gibt es keine Animation im Button und keinen Bestätigungston. Falls Validierungsfehler im Unterformular festgestellt werden, wird das entsprechende Fehlerbanner angezeigt (Details siehe unten: Validierungsfehlern an Formularen).

Je nach dem, ob es sich beim Formular um ein Haupt-/Unter-/Nebenobjekt handelt und ob es eine Neuanlage oder Bearbeitung ist, ist der primäre Aktionsbutton im Formular verschieden benannt. (Details siehe Navigationskonzept innerhalb GeFa: Übersicht der Objekttypen). Die sekundäre Aktion lautet immer “Schließen”.

Wenn das Laden von Formularinhalten länger dauert, so wird anstelle des Formulars ein Platzhalter mit Ladesymbol angezeigt. 

Beispiel: Nutzende befinden sich im Splitview und haben das Formular von Person 1 geöffnet. Klicken Sie auf eine andere Person in der Personenliste, so wird das Ladesymbol anstelle des Formulars angezeigt, bis die Daten vollständig anzeigbar sind. 

Der Ladezustand des Formulars ist fokussierbar, damit Nutzende den Ladezustand wahrnehmen können, wenn sie mit Enter oder Tab-Taste von der Liste aus ins Formular navigieren (Tastaturbedienung der Liste siehe Liste: Tastaturbedienung). 

Sobald die Daten des Formulars vollständig geladen sind, verschwindet das Ladesymbol, alle Formularelemente werden angezeigt und der Tastaturfokus liegt auf dem ersten interaktiven Element im Formular.

Während Inhalte des Breadcrumbs noch nicht vollständig geladen sind, wird an Stelle des Pfades eine Ladeanimation angezeigt. (Details siehe Pfadnavigation: Ladezustand).

Durch Gruppen können innerhalb von Formularen Elemente gruppiert werden, bei denen ein inhaltlicher Zusammenhang besteht. 

Der Gruppen-Kopf besteht aus: 

• Gruppentitel
• (optional) 1-n Status-Badges. Diese zeigen den Status der Gruppe an. Beispiele: Aktiv, Deaktiviert. Sie sind als Liste umgesetzt. (siehe Badges)
• (optional) Tertiärer Entfernen-Button: Dieser hat bei genug Platz den Buttontext “Entfernen”. Die Beschriftung und damit der Tooltip des Buttons lautet jedoch “[Gruppentitel] entfernen” (Gruppentitel ohne Badge-Texte). Die programmatische Beschriftung bleibt immer “entfernen”. Das Wort “Entfernen” ist dabei in extra-bold gesetzt.

Deaktivierte Formulargruppen enthalten jeweils:

• Gruppentitel
• Badge mit Schriftzug “Deaktiviert”
• Tertiärer Button zum Auf-/Zuklappen: Dieser trägt je nach Zustand den Alternativtext “Inhalt einblenden” (wenn zugeklappt) bzw. “Inhalt ausblenden” (wenn aufgeklappt)

Teilweise ist es auch möglich, weitere Gruppen hinzuzufügen. In der Regel ist es möglich, Gruppen nach Erstellung wieder zu entfernen. Teilweise muss mindestens eine Gruppe bestehen bleiben (je nach fachlicher Anforderung). Der Entfernen-Button wird in diesen Fällen entfernt, wenn nur noch eine Gruppe vorhanden ist.

Für die Darstellungsreihenfolge von Gruppen gilt:

• Neu hinzugefügte Gruppen werden immer an letzter Stelle angezeigt.
• Nach Entfernen einer Gruppe rutschen die nachfolgenden Gruppen nach oben, die Reihenfolge der noch bestehenden bleibt jedoch unverändert.
• Wird im Formular die Aktion “Speichern” ausgeführt und das Formular bleibt geöffnet, so bleibt die Sortierung der Gruppen auch nach erfolgreichem Speichern unverändert.
• Nach Schließen und erneutem Öffnen eines Formulars (egal ob Haupt- oder Unterformular) ist es zulässig, dass Gruppe, sofern fachlich sinnvoll in eine andere Reihenfolge (z. B. Alphanumerisch nach Bezeichnung) umsortiert werden. Diese Umsortierung ist falls gewünscht in den Userstories zu beschreiben.

Wird ein Formular im Read-Only-Zustand geöffnet, weil Nutzende beispielsweise keine Bearbeitungsrechte für das Formular besitzen, so werden die Entfernen-Buttons an Gruppen sowie die Hinzufügen-Buttons, sofern vorhanden, als deaktiviert dargestellt.
(siehe auch globale Definition zur Darstellung nicht verfügbarer Funktionalitäten)

Es ist auch möglich eine Gruppe zu deaktivieren. Nachdem eine Gruppe deaktiviert wurde, wird der Badge “Deaktiviert” dem Gruppentitel hinzugefügt. In der Regel werden interaktive Elemente wie Eingabefelder durch deaktivieren der Gruppe zu Read-Only-Feldern (je nach fachlicher Anforderung). Interaktive Elemente wie Links bleiben weiterhin klickbar. Wird die Gruppe wieder aktiviert, so verschwindet der Badge "Deaktiviert" wieder und Eingabeelemente werden ggf. wieder interaktiv.

Deaktivierte Formulargruppen sind auf-/zuklappbar. Die Aktion kann durch das Klicken des Akkordeon-Pfeil-Button rechts neben dem Gruppentitel durchgeführt. 

Nachdem eine Formulargruppe deaktiviert wurde, bleibt sie aufgeklappt. Wenn Nutzende ein Formular öffnen, welches deaktivierte Gruppen enthält, werden sie standardmäßig zugeklappt dargestellt.

Bei Entfernen einer Gruppe erscheint in der Regel keine Sicherheitsabfrage, da die Aktion über den Formularfooter wieder rückgängig gemacht werden kann. Wenn durch Entfernen der Gruppe eine deaktivierte Gruppe wieder aktiviert wird, so erscheint beim Entfernen eine Meldung vom Typ Sicherheitsabfrage, in der auf die Konsequenzen des Entfernens (Reaktivierung der deaktivierten Gruppe) aufmerksam gemacht wird. Nur nach erneutem Bestätigen in der Meldung, verschwindet die Gruppe wieder und eingegebene Inhalte werden gelöscht. (Details zur Fokussetzung nach Entfernen einer Elementgruppe siehe Navigationskonzept innerhalb GeFa: Löschen und Entfernen)

Die Gruppen sollten im Code als Formularfeldgruppe ausgezeichnet werden. In der Screenreaderausgabe muss zusätzlich zum Label des in der Gruppe enthalteten Eingabe-/Auswahlelementes jeweils der Gruppentitel mit vorgelesen werden (Ausgabe: “[Gruppentitel (ggf. inkl. Badges] [Label]”). Beispiel: 

Die Gruppe heißt “Kontoverbindung 1”. Darin enthalten sind die Formularfelder IBAN und BIC. Ausgelesen wird “Kontoverbindung 1 IBAN” und “Kontoverbindung 1 BIC”.

Innerhalb einer Elementgruppe wird erneut ein 12-Spaltiges Raster angewendet, in dem Formularfelder platziert werden können (Spaltenabstand je 16px).

Formulargruppen füllen immer die ganzen 12 Spalten im Formularlayout. Es dürfen keine 2 Formulargruppen nebeneinander platziert sein.

Eine Elementgruppe innerhalb einer Elementgruppe (Verschachtelung) ist nicht erlaubt.

Gruppen werden automatisch nummeriert. Der Gruppentitel besteht aus der Gruppenbezeichnung und der fortlaufenden Nummer. Die Nummer der Gruppe wird durch die Laufzeitkomponente bestimmt. 

Die älteste Gruppe wird zuerst angezeigt und hat die Nummer “1”. Alle Gruppen werden aufsteigend und ohne Lücken nummeriert. Wird eine Gruppe hinzugefügt oder entfernt, werden die Zähler aller nachfolgenden Gruppen sofort angepasst. 

Wenn in den Teilprojekten eine abweichende Logik 
benötigt wird, muss diese in den Stories beschrieben werden.

Mit diesem Element können zusätzliche Eingabe-/Auswahlfelder zu einem Formular hinzugefügt werden. Standardmäßig können die von Nutzenden manuell hinzugefügten Felder auch wieder entfernt werden, falls die Felder zu einem späteren Zeitpunkt nicht mehr benötigt werden oder falls sie fehlerhaft hinzugefügt wurden.

Die hinzugefügten Felder können sein: 

• Einzeiliges Eingabefeld
• Einzeiliges Eingabefeld mit Auto-Suggest
• Mehrzeiliges Eingabefeld
• Einfach-Auswahlfeld
• Mehrfach-Auswahlfeld
• Durchsuchbares Auswahlfeld
• Wertebereichs-Feld

• Der tertiäre Entfernen-Button ist immer vertikal zentriert zum Rahmen des hinzugefügten Elements platziert. Der Tooltip des Entfernen-Buttons lautet “[Bezeichnung des Eingabefeldes] entfernen”. Dies entspricht auch der Screenreaderausgabe. Bei Entfernen eines Feldes erscheint keine Sicherheitsabfrage.

Das entfernbare Element zusammen mit den Entfernen-Button nimmt immer genau eine Zeile ein. NICHT erlaubt ist:

• der Entfernen-Button bricht in eine neue Zeile um
• Es befindet sich ein weiteres Eingabe-/Auswahlfeld in der gleichen Zeile (Dann wäre nicht mehr klar, ob sich der Entfernen-Button auf ein oder mehrere Felder bezieht.)

Falls aus fachlichem Grund mindestens ein Feld in der Feldliste bestehen bleiben muss, so ist dies in Userstories zu erwähnen. In diesem Fall wird der Entfernen-Button disabled dargestellt, sobald nur noch ein Feld vorhanden ist. Wird dann wieder ein weiteres Feld hinzugefügt, so wird mit Erscheinen des neuen Feldes auch der Entfernen-Button an beiden Elementen wieder aktiviert.

Falls fachlich eine Mindestanzahl von Feldern bestehen bleiben muss, die größer als 1 ist, so ist dies Nutzern über einen Hinweistext (Typ je nach Anwendungsfall, siehe Hinweistexte in Formularen) über dem ersten Feld mitzuteilen, die Entfernen-Buttons werden aber nicht automatisch beim Erreichen dieser Mindestzahl deaktiviert (erst bei 1). Nach Ausführen der Primäraktion im Formularfooter erscheinen ggf. Validierungsfehlermeldungen, falls die Mindestanzahl an Feldern unterschritten wird (sind in Userstories zu beschreiben).  

Wenn die in den Listen enthaltenen Felder (beispielsweise durch die fehlenden Bearbeitungsrechte eines Nutzers nur Read-Only angezeigt werden, dann wird der Entfernen-Button neben dem Feld deaktiviert dargestellt. Gleiches gilt für den Hinzufügen-Button (falls vorhanden).
(siehe auch globale Definition zur Darstellung nicht verfügbarer Funktionalitäten)

Das Plus-Symbol im “[Eintrag] hinzufügen” Button ist als Layoutgrafik zu deklarieren.

Pro Maske dürfen innerhalb eines Inhaltsabschnitts nicht mehrere Felder mit identischer Bezeichnung vorkommen. Daher wird bei Feldern mit gleicher Bezeichnung im gleichen Inhaltsabschnitt standardmäßig entweder eine laufende Nummer an allen gleichnamigen Feldern angehängt oder es muss vom Nutzer eine Zusatzbezeichnung, welche die Felder unterscheidbar macht, definiert werden: 

• Die angehängte Nummer wird automatisch bei Hinzufügen des zweiten Feldes mit gleicher Bezeichung an alle gleich benannte Felder im entsprechenden Inhaltsabschnitt angehängt im Format “[Feldlabel] [Nummer]”. Sie wird überall aktualisiert, sobald Felder aus der Liste entfernt werden, so dass keine Lücken in der Nummerierung entstehen. Wird das vorletzte Feld mit gleicher Bezeichnung entfernt, so wird auch die Nummer am letzten/einzigen verbleibenden Feld wieder entfernt.
• Die zusätzliche Bezeichnung wird über ein Modal über ein Freitextfeld vergeben. Das Modal öffnet sich nach Klick auf den “[...] hinzufügen”-Button. Nach Vergabe der Zusatzbezeichnung wird diese im Format “[Feldlabel] – [Zusatzbezeichnung]” am Feld angezeigt.

Der Hinzufügen-Button bezeichnet genau einen zusätzlichen Eintrag. Der Buttontext lautet dann “[Label des Feldes] hinzufügen”. Nach Klicken des Buttons gibt es zwei Möglichkeiten:

• (a) Wenn noch kein Feld mit der gleichen Bezeichnung in diesem Inhaltsabschnitt vorhanden ist, so erscheint das neue Feld sofort in der Maske und ersetzt den Hinzufügen-Button. Das neue Feld hat genau die Bezeichnung, die im Button genannt wurde.
• (b) Falls es sich um ein Feld handelt, welches im gleichen Inhaltsabschnitt bereits vorkommt, so wird entweder eine “ 1” nach dem Label des bereits existierenden Felder und eine “ 2” an das Label des hinzugefügten Feldes angehängt oder es öffnet sich ein Modal, in dem Nutzende eine zusätzliche Beschriftung vergeben müssen.

Sobald das neue Feld entfernt wird, ist der Hinzufügen-Button wieder sichtbar.

Werden mehrere Felder mit gleicher Bezeichnung in einem Inhaltsabschnitt hinzugefügt, so wird nach Hinzufügen eines weiteren Feldes dem Feldlabel jedes mehrfach vorkommenden Feldes eine laufende Nummer, beginnend mit 1 angehängt. Wird ein Feld aus der Liste entfernt, so wird die Nummerierung aller folgenden Felder angepasst, sodass lückenlos nummeriert ist. Wird das vorletzte Feld entfernt, so wird auch die Nummer am ersten Feld entfernt, werden, da dann keine Felder mehr doppelt vorkommen.

Über den Hinzufügen-Button kann mehr als ein Eintrag hinzugefügt werden und Nutzende müssen zunächst eine Auswahl treffen. Der Button ist mit dem Text “[Eintragstyp] hinzufügen” bezeichnet. In diesem Fall öffnet sich nach Klicken des Buttons ein Modal, in dem Nutzende zusätzliche Eingaben machen müssen:

• Auswahlfeld, um welchen Eintragstyp es sich handelt (Pflichtfeld)
• Zusätzliche Bezeichnung (nur Pflichtfeld, falls es schon einen Eintrag mit dem gleichen Eintragstyp auf der vorherigen Maske gibt)
• Wert des Eintrags

Nach dem Schließen des Modals befindet sich der Fokus im neu hinzugefügten Feld. Außerdem wurden die Eingaben aus dem Modal folgendermaßen ins Feld übernommen:

• Das Label setzt sich wie folgt zusammen: “[Feldtyp Bezeichnung] – [Zusätzliche Bezeichnung]”. 
• Der Wert wird als Eingabe ins Eingabefeld übernommen und ist weiter editierbar.

Um die Bezeichnung oder den Feldtyp nach Schließen des Modales zu ändern, muss das Feld entfernt und neu hinzugefügt werden.

Wird ein Read-Only-Feld in einem Formular angezeigt, zum Beispiel weil es sich um einen automatisch generieren Wert handelt oder weil diese Information an anderer Stelle gesetzt wurde, so kann, je nach fachlicher Anforderung, die Möglichkeit bestehen, den Wert mit einem oder mehreren manuell eingegebenen Werten zu ersetzen. Dafür wird nach dem Read-Only-Feld ein tertiärer Button mit dem Label “[Label] bearbeiten” angezeigt.

Nachdem der Button “[Label] bearbeiten” geklickt wurde, erscheint darunter:

• Option 1: Ein neues, editierbares leeres Feld mit dem Titel „Neue/r/s/n [Label]” mit einem daneben liegenden Entfernen-Button. Der Entfernen-Button ist immer vertikal zum Rahmen des hinzugefügten Elements platziert. Der Tooltip des Löschenbuttons lautet „[Bezeichnung des Eingabefeldes] entfernen”. Dies entspricht auch der Screenreaderausgabe. Das entfernbare Element zusammen mit dem „Entfernen”-Button nimmt immer genau eine Zeile ein. Der „Entfernen”-Button darf nicht in eine neue Zeile umbrechen.
• Option 2: Eine neue, editierbare Gruppe mit dem Titel „Neue/r/s/n [Label]” mit einem „Entfernen”-Button (Beschreibung siehe oben: Verhalten von Elementgruppen).

Am ursprünglichen Feld wird der Text „(deaktiviert)” dem Feldlabel hinzugefügt und der enthaltene Wert wird durchgestrichen dargestellt. Wird der „Entfernen”-Button neben dem neu hinzugefügten Feld bzw. an der Gruppe geklickt, so wird der Ursprungswert wieder aktiviert, so verschwindet der Labelzusatz „(deaktiviert)" wieder und die Schrift wird nicht mehr durchgestrichen dargestellt.

Trennlinnien können in Formularen verwendet werden, um Inhaltsbereiche zu separieren. Sie können sowohl im Hauptinhaltsbereich von Formularen, als auch in Formulargruppen vorkommen.

Sie dienen in der Regel nur zur visuellen Darstellung, jedoch nicht zur semantischen Untergliederung des Formulars. 

Falls eine semantische Untergliederung erzielt werden soll, sind Zwischenüberschriften oder das Element “Formularfeldgruppe” einzusetzen.

In der Regel werden Trennlinien immer dann eingesetzt, wenn in einem Block von Eingabe- und Auswahlfeldern weitere Felder erst erscheinen, wenn eine bestimmte Auswahl getätigt wurde. Kann nur ein einziges Feld erscheinen, so muss keine Linie verwendet werden.

Die Linie befindet sich dann über den neu hinzugekommenen Feldern. Vor Erscheinen der zusätzlichen Felder wird noch keine Trennlinie angezeigt. 

Erscheint durch eine Auswahl ein neuer Abschnitt von Feldern mit einer darüberliegenden Zwischenüberschrift oder ein weiteres Akkordeon im Formular, so wird (auch nach Erscheinen dieser Abschnitte) keine Trennlinie angezeigt.

Um den Inhalt von Formularen semantisch zu untergliedern können Zwischenüberschriften verwendet werden. 

Die Überschriften sind so kurz und präzise wie möglich zu formulieren. Mehrzeiligkeit ist zu vermeiden. Bei sehr kleinen Screengrößen brechen sie jedoch wenn nötig um. Der Schrifttyp von Zwischenüberschriften ist “Subhead”. Die Überschriftenhierarchie im Code ist je nach 
Aufbau der entsprechenden Maske von Designer:innen festzulegen.

Wird eine Zwischenüberschrift eingesetzt, so wird ein Abstand von 48 Pixeln zum darüberliegenden Element gesetzt. 

Handelt es sich bei der Überschrift um das erste Element innerhalb des Formular- oder Akkordeoninhalts, wird kein zusätzlicher Abstand eingefügt. 

Nicht eingesetzt werden können Zwischenüberschriften innerhalb von Elementgruppen, da diese bei aktiven Screenreader die Gruppenüberschriften überschreiben (siehe oben: Verhalten von Elementgruppen).

In Ausnahmefällen kann eine Zwischenüberschrift fokussiert angezeigt werden. Anwendungsfall: Bei Rückkehr aus einem Neuanlage-Modal in ein Formular mit Tabelle und darüberliegender Zwischenüberschrift bzw. Tabellentitel muss das über der Tabelle liegende Element fokussiert sein, damit Nutzende den geänderten Tabelleninhalt wahrnehmen können. 
Die Überschrift ist in diesem Fall nur im Moment der Rückkehr fokussiert. Verschieben Nutzende den Fokus dann zu einem anderen Element, so kann der Fokus nicht wieder auf die Überschrift zurückgelegt werden (nur durch erneutes Öffnen des Neuanlage-Modals und anschließender Rückkehr).

Karten werden in Formularen eingesetzt, um Daten aus Unterformularen zusammenzufassen. Karten enthalten selbst keine bearbeitbaren Elemente (im Unterschied zur Komponente “Elementgruppe”).

Karten sollten nur eingesetzt werden, wenn für den Anwendungsfall weniger als 6 Objekte erwartet werden. Werden im Schnitt mehr als 6 Objekte angelegt, sollten diese z.B. in einer Tabelle aufgelistet werden.

Jede Karte besteht aus einem Kopf- und einem Inhaltsbereich: 

• Der Kopfbereich enthält den Titel, einen optionalen Status-Badge und einen Sekundärbutton zum Aufruf des Unterformulars. Dabei bilden Titel und Badge zusammen die Kartenüberschrift und werden vom Screenreader gemeinsam ausgelesen im Format “[Kartentitel] – [Badgebeschriftung]”
• Im Inhaltsbereich werden ausgewählte Daten des Unterformulars angezeigt. Die Daten sind innerhalb der Karte nicht bearbeitbar.

Das einzige interaktive Element im Kartenkopf ist ein Sekundärbutton mit Icon. Dieser öffnet das Unterformular des Objekts auf einer neuen Seite oder in einem modalen Dialog. Je nach dem, ob das Unterformular bearbeitbar ist, oder nur lesend geöffnet werden kann, enthält der Button ein Stift-Symbol (Alternativtext “[Titel der Karte] bearbeiten”) oder ein Auge-Symbol (Alternativtext “[Titel der Karte] anzeigen”).

Die Mindesthöhe des Kopfbereichs beträgt 88 Pixel. Der Wert ergibt sich aus der Höhe des Buttons (40 Pixel) und einem äußeren Abstand von 24 Pixel.

Bei einem mehrzeiligen Titel, wird der Kopfbereich entsprechend höher.

Der Inhaltsbereich der Karte kann bis zu vier Elemente im Status “Read-Only” aufnehmen, jedoch mindestens ein Element.

Pro Zeile kann ein Element platziert werden. Die Inhalte werden vom Screenreader zeilenweise von oben nach unten ausgegeben.

Die Höhe des Inhaltsbereichs ergibt sich aus den angezeigten Elementen.

In Formularen können verschiedene Arten von Hinweismeldungen vorkommen. Je nach fachlicher Anforderung und Wichtigkeit des Hinweises ist zu entscheiden, welcher Typ eingesetzt wird. Generell sollten Hinweise sparsam und nur für wichtige Informationen verwendet werden. 

Typ 1 Hinweise, die sich auf das gesamte Formular beziehen sind je nach fachlicher Anforderung entweder als graues Banner am Anfang des Formulars (unter dem Formularheader) oder am Formularende (über dem Formularfooter) positioniert. Es darf dabei nur eine der beiden Meldungen pro Formular vorkommen (oben oder unten).

Typ 2 Hinweise, die sich auf den gesamten Inhalt einer Akkordeon-Zwischensektion beziehen, sind als graues Banner unter dem Akkordeon-Header positioniert.

Typ 3 Hinweise, die sich nur auf Teilbereiche eines Formulars bzw. Teile eines Akkordeoninhalts beziehen, sind als grauer Text dargestellt. Sie befinden sich immer vor dem Element bzw. den Elementen, auf die sich der Hinweis bezieht. Bei Hinweisen zu einzelnen Formularelementen, wie z. B. Eingabe- oder Auswahlfeldern, die bereis einen programmatisch verknüpften Hinweisbereich enthalten, ist dieser zu nutzen.

Typ 1 und 2 werden jeweils als graues Banner dargestellt, welches die gesamte Formularbreite füllt. TYP 3 besteht aus reinem Text ohne Hintergrundfläche und fügt sich ins Formularraster ein (über alle 12 Spalten).

Hinweismeldungen bleiben beim Scrollen nicht sticky. 

Hinweismeldungen aller Typen sind, falls vorhanden, direkt beim Öffnen des Formulars sichtbar. 

Alle Hinweistypen sind folgendermaßen aufgebaut: “Hinweis: [Hinweistext]”

• Text “Hinweis:” Bei den Hinweistypen 1 und 2 ist dieser als Überschrift ausgezeichnet, auch wenn er visuell dem Schrifttyp “Body” entspricht. Die Überschriftebene ist abhängig vom jeweiligen Seiten-Layout: Sie sollte sich immer eine Überschriftebene unter dem jeweils darüberliegenden Formulartitel (Bei TYP 1) oder Akkordeontitel (bei TYP 2) befinden. Der Hinweistyp 3 wird nicht als Überschrift, sondern als Body-Text implementiert. 
• [Hinweistext] – Beschreibt so kurz und genau wie möglich den Hinweis. In der Regel sind ganze Sätze mit Punkt am Ende zu verwenden. Der Hinweistext kann auch Aufzählungen enthalten.

Optional kann darunter bei den Typen 1 und 2 eine Liste mit Links vorkommen.
Links (1-n): Es handelt sich um eine Liste. Jeder der Links springt zu einer neuen Seite.

Der Bereich der Hinweismeldungen 1 und 2 muss im Code als Region ausgezeichnet werden und die Beschriftung "Hinweis" erhalten. Typ 3 enthält keine Regionsauszeichnung.

Mehrere Hinweismeldungen im gleichen Bereich (form oben/unten) sollten nicht vorkommen. Es wäre aber theoretisch möglich, dass oben im Formular ein Hinweis angezeigt wird und unten ebenfalls.

Da in jedem Formular Validierungsfehler auftreten können (siehe unten: Validierungsfehlern an Formularfeldern), ist es auch möglich, dass ein Hinweis-Meldungsbanner und ein Fehlermeldungsbanner zur gleichen Zeit sichtbar sind. In diesem Fall sollte das Fehlerbanner über dem Hinweisbanner angeordnet sein.

Es wird unterschieden zwischen folgenden Arten der Validierung:

• Frontend-Validierungen an einzelnen Eingabe-/Auswahlelementen: Fehlermeldungen, die auf Frondend-Ebene geprüft werden können, werden Nutzenden in der Regel direkt bei der Wertübernahme einer Änderung angezeigt, spätestens jedoch bei Ausführen der Primäraktion im Formularfooter bzw. bei Wizardprozessen bei Vorwärtsnavigation über die Schrittübersicht (Details zum Validierungszeitpunkt pro Elementtyp siehe unten: Validierungsfehler an Formularfeldern).
• Frontend-Crossvalidierungen können durch den Abgleich der Eingaben an mehreren Elementen innerhalb eines Formulars bzw. einer Wizardseite geschehen. Sie können ab dem Moment geprüft werden, in dem das letzte zu vergleichende Feld auf der Seite befüllt wurde (unabhängig von der Befüllungsreihenfolge). Der spätest mögliche Zeitpunkt ist jedoch bei Ausführen der Primäraktion im Formularfooter bzw. bei Wizardprozessen bei Vorwärtsnavigation über die Schrittübersicht. Der genaue Zeitpunkt ist in Userstories zu definieren. Gefundene Crossvalidierungsfehler werden als formularfeldübergreifende Fehler dargestellt.
• Frontend-Crossvalidierungen, welche Elemente auf mehreren verschiedenen Formularen bzw. Wizardseiten betreffen (Beispiel “Die Eingaben im aktuellen Schritt 3 passen nicht zu den vorherigen Eingaben in Schritt 1.” oder “Die Eingabe im Kindformular passt nicht zur Eingabe im Elternformular) – Dieser Fall ist aktuell nicht zulässig (Technisch zwar möglich, aber aus Usability-Sicht nicht empfohlen. Erweiterung ist zu späterem Zeitpunkt denkbar, sofern fachlich benötigt).
• Backend-Validierungen werden in Formularen standardmäßig erst bei Ausführen der Primäraktion im Formularfooter des Hauptobjekts durchgeführt. In Wizards werden sie standardmäßig bei Ausführen der Primäraktion auf der Zusammenfassungsseite (bzw. falls es keine solche gibt bei Ausführen des Primärbuttons auf der dann letzten Wizardseite) durchgeführt. Es kann also vorkommen, dass erst kurz vor Abschluss einer Aktion wie der Anlage oder Bearbeitung eines Objekts noch Fehler in vorher geöffneten Unterformularen bzw. vorherigen Wizardschritten gefunden werden. Die Korrektur der Fehler kann nur durch Änderungen in den entsprechenden Haupt-/Unterformularen bzw. Wizardschritten erfolgen. In Ausnahmefällen können, falls fachlich sinnvoll, auch vorher bereits Backendvalidierungen durchgeführt werden. Der genaue Zeitpunkt (bei Verlassen eines Feldes / Ausführen einer Aktion / Weiter-Navigation) ist in Userstories zu definieren. In jedem Fall müssen diese Validierungen dann allerdings bei Speichern/Anlegen des Hauptojekts bzw. Abschluss des Wizards erneut geschehen.

Details zum Validierungsverhalten siehe:

• Meldungsbanner in Formularen & Ablauf Front-/Backend-Validierung
• Übergreifende Validierung zwischen Haupt- und Unterformularen
• Geführter Prozess für Neuanlage (Wizard): Ablauf von Validierungen in Wizardprozessen

Bei allen Einzelelementen wie Eingabe-, Auswahlfeldern, Radio Button- und Checkboxen-Gruppen können Validierungsfehler vorkommen.

Es handelt sich hier um Fehler, die sich auf exakt eines dieser Element beziehen und durch die Korrektur dieses Elements behoben werden können.

Beispiele: 

• Fehlerhafte Eingabe im Einzeiligen Eingabefeld
• Fehlende Eingabe im Auswahlfeld
• Fehlende Auswahl einer Checkbox
• Fehlende Auswahl in einer Radio-Button Gruppe

Nach Wertänderungen findet die tatsächliche Wertübernahme zu folgenden Zeitpunkten statt und in diesem Moment werden auch Frontendvalidierungen am Element durchgeführt:

• Bei Eingabefeldern (Einzeilig, Mehrzeilig, Datumseingabe, Uhrzeiteingabe) sowie dem durchsuchbaren Einfachauswahlfeld findet die Validierung nach Wertänderung und Verlassen des Feldes ODER nach Wertänderung und Klicken der Return-Taste statt.
• Bei Auswahlfeldern (Einfachauswahlfeld, Durchsuchbares Einfachauswahlfeld, Baumauswahlfeld, Radiobuttons, später auch nach Datumsauswahl via Datepicker) findet die Validierung direkt bei Auswahl eines neuen Wertes statt.
• Bei Mehrfachauswahlfeldern findet die Validierung bei Verlassen der Ausklappliste nach Wertänderung statt. 
• Bei einzelnen Checkboxen findet die Validierung bei Wertänderung statt. Bei Checkboxgruppen finden Validierungen erst bei Ausführen der Primäraktion im Formularfooter statt. – Besonderheit bei Checkboxgruppen: Eine Wertänderung innerhalb einer Gruppe führt immer zur Deaktivierung bereits vorhandene Validierungsfehlermeldungen der Gruppe (siehe Checkbox: Fehlerfälle / Validierung).

Pflichtfeldvalidierungen ohne Wertänderung werden immer erst nach Ausführen der Primäraktion im Formularfooter durchgeführt.

Backendvalidierungen werden im Regelfall erst nach Ausführen der Primäraktion im Hauptformular und vorheriger Frontendprüfung angezeigt (siehe auch bei "Ablauf Front-/Backendvalidierung" und "Übergreifende Validierung zwischen Haupt- und Unterformularen").

Das Ausrufezeichen-Symbol neben der Meldung ist immer als Layoutgrafik zu deklarieren.

Zusätzlich zu den Validierungs-Fehlermeldungen, die an Einzelelementen wie Eingabe-, Auswahlfeldern, Radio Button- und Checkboxen-Gruppen vorkommen können, können auch von diesen Elementen unabhängige Validierungsfehler in Formularen auftreten. 

Es handelt sich hier um Fehler, die nicht an exakt einem Element hängen, sondern aus einer Kombination aus getätigten oder fehlenden Eingaben entstehen. Sie können ab Befüllung des letzten zu vergleichenden Feldes, spätestens jedoch nach Ausführen der Primäraktion im Formularfooter erscheinen (Details zum Validierungszeitpunkt siehe oben bei "Fehler- und Erfolgsmeldungen in Formularen: Frontend-Cross-Validierungen"). Die Formularfeldunabhängigen Fehlermeldungen werden nach Ausführen der Primäraktion im Formularfooter auch im Fehlermeldungsbanner am Anfang des Formulars gelistet und können darüber direkt angesprungen werden.

Beispiele:

• Tabelle mit selektierbaren Zeilen (über Checkboxen): Es muss mindestens eine / höchstens 5 Checkboxen in der Tabelle selektiert sein.
• Verfahrenssperre: Es müssen mindestens zwei Personen hinzugefügt werden.
• Rollen einer verfahrensbeteiligten Person: Es müssen mindestens zwei Rollen angelegt sein. 
• Anlage eines Altverfahrens: Das Aktenzeichen, welches sich aus den Eingaben in mehreren Einzelfeldern zusammensetzt, existiert bereits.
• Tabelle mit fehlerhaften Unterobjekten, z. B. auf Grund von Überschneidenden Gültigkeitszeiträumen

Das Ausrufezeichen-Symbol neben der Meldung ist immer als Layoutgrafik zu deklarieren.

Validierungsmeldungen für eine Gruppe von Elementen sind immer oberhalb des ersten betroffenen Elements platziert. Es kann sich dabei um eine oder mehrere Meldungen handeln.

• Bei Elementgruppen: Immer über der ersten Gruppe positioniert (egal ob eine oder mehrere Fehlermeldungen)
• Bei Karten: Immer über der ersten Karte positioniert (egal ob eine oder mehrere Fehlermeldungen)
• Bei Tabellen: Über dem Tabellenheader; unter einer ggf. gesetzten Tabellenüberschrift
• Bei Listen über dem ersten Listenelement; unter einer möglichen Listenüberschrift.
• Bei mehreren logisch zusammengehörenden Formularfeldern mit Zwischenüberschrift, die in ihrer Kombination einen Fehler erzeugen (es kann also nicht genau ein Feld als Fehlerhaft benannt werden): Unter der darüberliegenden Zwischenüberschrift.

Um die Meldungen aus dem Meldungsbereich direkt mit der Tastatur ansteuern zu können, sind sie fokussierbar.

Wichtig ist eine eindeutige Formulierung der Fehlertexte, so dass möglichst genau daraus hervorgeht, an welchen Feldern bzw. Gruppen Änderungen vorgenommen werden müssen. Beispiele:

• Es müssen mindestens zwei Rollen angelegt sein. Aktuell ist eine Rolle vorhanden.
• Es muss mindestens ein Fachbereich ausgewählt sein. Aktuell ist keiner selektiert.
• Es dürfen höchstens vier Fachbereiche ausgewählt sein. Aktuell sind 7 selektiert.
• “Die Gültigkeitszeiträume von „[Titel Gruppe 1]” und „[Titel Gruppe 2]” überschneiden sich.”

Bei Tabellen mit fehlerhaften Unterobjekten ist in der formularfeldübergreifenden Fehlermeldung jeweils der Name des Unterobjekts (Text in Rowheader) zu nennen im Format “[Unterobjektname] – [Feldlabel]: [Fehlertext]” Beispiel: 

• Spruchgruppe A – Gültig: Von-Datum darf nicht vor dem Gültig-Ab-Datum des Entscheidungsorgans liegen

Bei Fehlermeldungen in Formularen müssen zwei Fälle unterschieden werden: 

1. Fehlermeldungen, die auf Frondend-Ebene geprüft werden können, werden Nutzenden direkt bei der Wertänderung bzw. beim Verlassen eines geänderten Feldes angezeigt (Details zum Validierungszeitpunkt pro Elementtyp siehe unten: Validierungsfehler an Formularfeldern)
2. Fehler, die erst auf Backend-Ebene geprüft werden können, werden den Nutzenden erst nach Klick auf den Speichern/Anlegen-Button angezeigt und alle im Frontend validierbaren Fehler müssen vorher bereits behoben sein.

Auf dieser Ebene kann beispielsweise geprüft werden: 

• wurde ein Pflichtfeld nicht befüllt
• ist das Eingabeformat korrekt (z. B. bei Datum)
• wurde die maximal zulässige Zeichenzahl erreicht
• wurden nicht erlaubte Zeichen eingegeben
• wurde ein Datum in der Zukunft eingegeben und dies ist fachlich nicht zugelassen (Bsp. Geburtstag)
• wurde ein Datum in der Vergangenheit eingegeben und dies ist fachlich nicht zugelassen (Bsp. Termin)
• liegt bei zwei Datumsfeldern (Von-Bis) das Beginndatum nach dem Enddatum (oder andersherum). Dieser Fall wird erst nach Verlassen des zweiten Datumsfeldes geprüft.
• .…

Auf fehlerhafte Eingabe werden Nutzende direkt bei der Wertänderung bzw. beim Verlassen eines geänderten Feldes angezeigt (Details zum Validierungszeitpunkt pro Elementtyp siehe unten: Validierungsfehler an Formularfeldern) – sowohl visuell als auch über ein akustisches Signal (siehe Spezifikationen zum jeweiligen Eingabe- und Auswahlfeldtyp).

Auf fehlende Eingaben (unbefüllte Pflichtfelder) werden Nutzende nicht direkt bei Verlassen eines Feldes hingewiesen, wenn keine Wertänderung stattgefunden hat, sondern erst nach Klick auf den Primärbutton im Formularfooter. Ausnahme: War ein Pflichtfeld bereits befüllt und Nutzende entfernen den Inhalt und verlassen dann das Feld, so wird die Pflichtfeldvalidierung direkt bei Verlassen angezeigt (da Wertänderung durchgeführt).

Nach Klick auf den Primärbutton “Speichern/Anlegen/Hinzufügen/Übernehmen” im Formular-Footer werden alle im Formular gefundenen, im Frondend validierbaren Fehler (fehlerhafte sowie fehlende Eingaben) in einem Banner unter dem Formularheader angezeigt und das Formular scrollt gleichzeitig ganz nach oben. Gleichzeitig ertönt ein akustisches Signal: Fehlermeldung (siehe Akustische Signale). Liegen die gefundenen Fehler innerhalb von zugeklappten Akkordeons in diesem Formular, so werden diese Akkordeons mit Erscheinen des Fehlermeldungsbanners ausgeklappt.

Der Fehlermeldungsbereich sollte als Region ausgezeichnet werden. Diese ist als “Fehlermeldung” beschriftet. Die Ausrufezeichen-Grafik ist als Layoutgrafik zu deklarieren.

Die Meldung beinhaltet eine detailierte Auflistung der einzelnen gefundenen Fehler (aus Front- und Backend-Validierung). Die Auflistung besteht aus tertiären Buttons (Detailbeschreibung zu dessen Status, siehe Button). Jeder einzelne der Buttons lässt bei Klick den Fokus zum entsprechenden Formularfeld springen bzw. zu der entsprechenden Fehlermeldung, wenn es sich um formuarlfeldunabhänige Fehler handelt. 
Die Reihenfolge der Fehlerauflistung orientiert sich an der Reihenfolge, in der die Eingabefelder im Formular vorkommen. 

Der entsprechende Button im Fehlerbanner wird deaktiviert, sobald eine Änderung am betroffenen Feld erfolgt ist und das entsprechende Feld verlassen bzw. das betroffene Feld gelöscht oder disabled wird. In Ausnahmefällen, falls durch eine andere im Formular ausgeführte Aktion ein Formularfeldfehler behoben wird, wird der entsprechende Eintrag im Fehlerbanner ebenfalls deaktiviert. Dies ist in den Userstories fachlich zu beschreiben. Entsteht durch die Eingabe ein neuer Frontend-Fehler, so wird dieser bei Verlassen des Feldes unter diesem angezeigt. Das Meldungsbanner wird nur durch den erneuten Klick auf “Speichern/Anlegen/...” aktualisiert, nicht während der Durchführung von Änderungen (bis auf die Deaktivierung der Einträg). Wird der letzte Eintrag im Fehlerbanner deaktiviert, so wird mit ihm auch die Überschrift “[Aktion] nicht möglich” als deaktiviert dargestellt (30% Opacity). Wird der Screeenreaderfokus auf diese deaktivierte Überschrift gesetzt, so wird dieser weiterhin ausgegeben mit dem Zusatz “Alle fehlerhaften Felder bearbeitet”.

Erst wenn alle im Frontend validierbaren Fehler behoben wurden und auf “Speichern/Anlegen” geklickt wird, werden die Daten zur Validierung an das Backend geschickt. Es wird dann noch zusätzlich geprüft, ob auf Datenbankebene Fehler entstehen. Beispiele:

• Objekt mit gleicher Bezeichnung existiert bereits
• …

Werden Fehler gefunden, so erscheint wieder ein Fehlermeldungsbanner mit dem exakt gleichen Verhalten (wie oben beschrieben). Zusätzlich tauchen an den betroffenen Feldern aussagekräftige Fehlermeldungen auf. Auch bei Backend-validierten Fehlern hier wird ein Eintrag im Fehlerbanner entfernt, sobald eine Änderung am betroffenen Feld erfolgt ist. Entsteht durch die geänderte Eingabe ein neuer Frontend-Fehler, so wird dieser bei Verlassen des Feldes am Feld und (falls nicht vorher korrigiert) nach erneutem Klick auf “Speichern” auch im Meldungsbanner angezeigt. Entsteht durch die Änderung ein gleicher/anderer Backend-Fehler, so wird dieser erst nach erneutem Klick auf Speichern wieder im Meldungsbanner sowie am betroffenen Feld angezeigt.

Der Speichern-Button ist auch im Fehlerfall immer aktivierbar.

• Nach Ausführen der Primäraktion in einem Haupt- oder Unterformular, wenn Fehler in diesem Formular gefunden werden: “[Aktionsbutton Bezeichnung] nicht möglich”
• Beispiele:
• • “Speichern nicht möglich”
  • “Hinzufügen nicht möglich”
  • “Anlegen nicht möglich”
  • “Übernehmen nicht möglich”
  • “Zuordnen nicht möglich”
• Bei Sprung zwischen Haupt- und Unterformularen kann der Fehlerbannertitel auch “Fehlerhafte Eingaben” lauten (Detailbeschreibung siehe unten: Übergreifende Validierungen zwischen Haupt- und Unterformularen)

• Text für Formularfeldfehler: “[Feldlabel]: [Validierungstext]”
• Text für Formularfeld-unabhängige Fehler: “[Validierungsfehlertext: Vorgaben siehe oben]”
• Text für Formularfeldfehler innerhalb von Formularfeldgruppen: “[Bezeichnung Formularfeldgruppe] – [Feldlabel]: [Validierungstext]”
• Text für Wertebereichsfelder: “[Label des Wertebereichsfeldes]: [Validierungstext, welcher immer auch das Label des Teilfeldes enthält, wenn der Fehler nur einen Feldteil betrifft]”
  Text für Wertebereichsfelder innerhalb von Formularfeldgruppen: “[Bezeichnung Formularfeldgruppe] – [Label des Wertebereichsfeldes]: [Validierungstext, welcher immer auch das Label des Teilfeldes enthält, wenn der Fehler nur einen Feldteil betrifft]”
• Text für Formuarfeldfehler in Unterformularen (siehe unten): “[Bezeichnung Unterobjekt] – [Feldlabel]: [Validierungstext]”
• Text für Formularfeldfehler auf anderen Seiten innerhalb eines Wizard-Neuanlageprozesses (siehe Wizard): “[Schrittnummer]. [Arbeitsschritt] – [Feldlabel]: [Validierungstext]”

• Max. 1-2 Sätze pro Element
• Erklärt, aus welchem Grund nicht gespeichert werden kann (Fehlerursache)
• Enthält Bezeichnung des Feldes

Beispiele:

• “IBAN: Pflichtfeld nicht befüllt”
• “Gültig: Bis-Datum darf nicht in der Vergangenheit liegen”
• “Bezeichnung: Bezeichnung am LG Musterstadt bereits vorhanden”

Bei Formularen mit Unterobjekten kann es vorkommen, dass auf dem Hauptformular Validierungen durchgeführt werden, bei denen Fehler in Unterobjekten gefunden werden. Dies kann durch Abhängigkeit zwischen den Haupt-/Unterobjekten entstehen oder dadurch, dass erst bei Ausführen der Aktion Speichern/Anlegen Backend-Validierungen durchgeführt werden. Die Korrektur der Fehler kann durch Änderugen im Haupt- oder Unterobjekt erfolgen. 

Beispiele:

• BEISPIEL 1 – Cross-Validierung von Gültigkeitszeiträumen im Modul Gerichtsverwaltung: Gültigkeitszeitraum des Unterobjekts “Entscheidungsorgan” passt nicht zum Gültigkeitszeitraum des Hauptformulars “Organisationseinheit”
• BEISPIEL 2 – Innerhalb einer GVP-Verteilung wurde bei mehreren Verteilungsregeln die gleiche Rangposition oder eine gleiche Zeichenkette/Datum/... (je nach Verteilart) definiert. 

1. Wird in einem Unterformular auf “Hinzufügen/Übernehmen” geklickt, dann werden bereits Frontend-Validierungen für das Unterformular durchgeführt. (Die Fehler können auch schon vorher, nach Verlassen eines fehlerhaft befüllten Feldes direkt am Feld angezeigt werden.) Werden Fehler gefunden, so erscheint im Unterformular das entsprechende Fehlerbanner, welches alle fehlerhaften Elemente in diesem Formular listet und Nutzer müssen die Fehler korrigieren, bevor das Objekt hinzugefügt bzw. Änderungen übernommen werden können.
2. Wird im Hauptformular auf “Speichern/Anlegen” geklickt, so werden sowohl die Inhalte des Hauptformulars, als auch die Inhalte aller Unterformulare und alle Abhängigkeiten untereinander validiert. Alle gefundenen Fehler werden im Fehlerbanner des Hauptformulars aufgeführt. Bei Cross-Validierungen (Wert im Hauptformular passt nicht zu Wert im Unterformular) wird davon ausgegangen, dass der Wert im Hauptformular richtig ist und nur die Eingabeelemente in Unterformularen werden als Fehler aufgeführt. Bei Fehlern in Unterobjekten wird die Objektbezeichnung dem Fehlertext im Banner vorangestellt (siehe unten Benennung). Zusätzlich zur Auflistung im Fehlerbanner wird ein Formularfeld-unabhängiger Validierungsfehlertext über der Stelle im Formular angezeigt, von der aus in das entsprechende Unterformular abgesprungen werden kann. Falls die fehlerhaften Unterobjekte im Hauptformular tabellarisch dargestellt sind, so werden diese im Rowheader zusätzlich mit einem Fehlerhaft-Symbol markiert. Um nun zur Behebung der Fehler in das Unterformular zu gelangen, gibt es zwei mögliche Navigationswege:
3. 1. Wird im Fehlermeldungsbanner des Hauptformulars auf einen Unterformular-Fehler geklickt, so öffnet sich dadurch das entsprechende Unterformular (im gleichen Browsertab). Der Tastaturfokus liegt dann auf dem fehlerhaften Element bzw. bei formularfeldunabhängigen Fehlern auf dem Fehlertext. 
   2. Es kann alternativ im Hauptformular zu der Stelle gescrollt werden, von der aus in das entsprechende Unterformular abgesprungen werden kann (oft Tabellen). Hier kann über Klick auf Bearbeiten in den Tabellenaktionen das Unterformular geöffnet werden. Der Tastaturfokus liegt dann auf dem ersten Element im Formularinhalt.
3. Im Unterformular ist erneut ein Fehlerbanner zu sehen, in welchem nur die Fehler aufgelistet sind, die dieses spezielle Unterformular betreffen. Sobald eine Änderung an einem betroffenen Feld erfolgt ist und dieses Feld verlassen wird, wird der entsprechende Eintrag im Fehlerbanner als deaktiviert dargestellt (auch wenn die erneute Backend-Überprüfung erst wieder im Hauptformular passiert). Entsteht durch eine Eingabe ein neuer Frontend-Fehler im Unterformular, so wird dieser bei Verlassen des Feldes am Element angezeigt. Im Meldungsbanner des Unterformulars wird der neu entstandene Frontend-Fehler (falls nicht in der Zwischenzeit behoben) erst nach Klick auf “Übernehmen/Hinzufügen” angezeigt. Dabei entspricht die Reihenfolge der gelisteten Fehler der Formularreihenfolge der betroffenen Felder (siehe oben: Ablauf Front-/Backend/Validierung). Betreffen ein Frond- und ein Backendfehler das gleiche Element, so wird der Backendfehler zuerst und der neu hinzugekommene Frontendfehler danach im Fehlerbanner gelistet. Wie in Schritt 1. gilt dann erneut, dass zuerst alle Frontend-Fehler im Formular behoben werden müssen, bevor das Formular verlassen werden kann (egal ob nach oben ins Eltern- oder nach unten in ein weiteres Kindformular). Noch offene Backend-Fehler verhindern nicht das Verlassen des Formulars.
4. Wurden alle Frontend-Fehler im Unterformular behoben und (optional) Backend-Fehler bearbeitet und Nutzende kehren mit Klick auf “Übernehmen/Hinzufügen” ins Hauptformular zurück, dann werden die Fehler-Einträge im Fehlerbanner des Hauptformulars, welche bereits im Unterobjekt bearbeitet wurden, als deaktiviert dargestellt. Alle noch unbearbeiteten Fehler sind weiterhin aktiv und klickbar. Die formularfeldüber-greifenden Fehlermeldungen der abgearbeiteten Fehler im Formularinhalt werden entfernt. Gleichzeitig wird die Fehlerhaft-Markierung im Rowheader der Unterobjekttabelle entfernt. Wären noch Backendfehler im Unterobjekt unbearbeitet, so bliebe die Fehlermeldung sowie die Markierung in der Tabelle noch erhalten.
5. Wird erneut die Abschlussaktion wie “Speichern” bzw. “Anlegen” im Hauptformular ausgeführt, dann findet erneut eine Validierung über das Haupt- sowie alle Unterformulare statt und das oben beschriebene Verhalten (ab Punkt 2) wiederholt sich gegebenenfalls. 

Hinweis: Cross-Validierungen zwischen Eltern- und Kindformular können, sofern fachlich sinnvoll, auch bereits auf Unterformularebene durchgeführt werden, statt erst bei Ausführen der Primäraktion im Hauptformular (Standardfall). Beispiel: Bei Ausführen der Primäraktion in einem Unterformular kann bereits validiert werden: “Die Eingaben in dessen Unterformular darunter passen nicht zu den Eingaben im aktuell geöffneten Unterformular”. Es gilt dann das gleiche Verhalten, wie oben zwischen Haupt- und Unterformular beschrieben: Im Fehlermeldungsbanner des Unterformulars, werden die Cross-Validierungsfehler der darunterliegenden  Unterformulare gelistet, die fehlerhaften Elemente können über das Banner angesprungen werden und werden nach Bearbeitung wieder als deaktiviert angezeigt.

Titel des Fehlerbanners:

“[Bezeichnung primärer Button] nicht möglich” wird verwendet, wenn…

• ...wenn in einem Hauptformular die Primäraktion ausgeführt wurde und Fehler in diesem oder Unterformularen neu gefunden wurden.
• ...wenn in einem Unterformular die Primäraktion ausgeführt wurde und Fehler in diesem Unterformular gefunden wurden.

“Fehlerhafte Eingaben” wird verwendet wenn…

• ...wenn ein fehlerhaftes Unterobjekt aufgrufen wird (z.B. über den Button “Bearbeiten” in einer Tabelle bzw. Karte im Elternformular oder über das Meldungsbanner des Hauptformulars).
• ...wenn über den Button “Schließen” im Formularfooter eines Unterobjekts zu einem fehlerhaften übergeordneten Objekt zurückgekehrt wird, welches nicht das Hauptobjekt ist.
• ...wenn eine Primäraktion in einem Unterformular ausgeführt wurde, durch diese keine neuen Fehler im aktuellen Formular gefunden wurden und dann in ein fehlerhaftes übergeordnetes Objekt zurückgekehrt wird, welches nicht das Hauptobjekt ist.

Buttontext in der Fehlerliste darunter setzt sich jeweils zusammen aus:

• “[Bezeichnung Unterobjekt] – ” (ggf. mehrmals, falls sich der Fehler in einem Unter-Unterobjekt befindet)
• Dem für das fehlerhafte Element definierten Zusatz (siehe unten: Fehlerbanner Schema Benennung)

Beispiel.

• “Spruchgruppe A – Gültig: Von-Datum darf nicht vor dem Ab-Datum des Entscheidungsorgans liegen”

Synchrone Erfolgsbenachrichtigungen (direktes Feedback auf eine Nutzeraktion) werden Nutzenden sofern möglich im Kontext des Elements mitgeteilt. 

• Das Detailformular eines bereits angelegten Objekts ist geöffnet und es wurden Änderungen durchgeführt. 
• Wenn auf “Speichern” im Formular-Footer geklickt wird, so läuft im Button eine Animation ab, welche das erfolgreiche Speichern anzeigt (siehe auch oben: Verhalten von Formular-Footer): 
• Sobald der Speichern-Button geklickt wurde, wird ein rotierendes Ladesymbol (loading spinner) innerhalb des Buttons angezeigt. Der Alternativtext des Symbols lautet “Wird gespeichert”. Bei fokussiertem Button oder Mouse-Hover über den Button wird dieser ebenfalls als Tooltip angezeigt. Das Ladesymbol wird vom Screenreader automatisch ausgegeben, ohne das der Systemfokus auf die Grafik gezogen wird. Allerdings wird der Text erst 2 Sekunden nach Ausführen der Aktion “Speichern” ausgegeben, um zu viel Audionoise zu vermeiden. Falls das Laden noch länger dauert, wird alle 10 Sekunden erneut der Alternativtext des Ladesymbols ausgelesen, unabhängig davon, wo sich der Fokus auf der Seite zu der Zeit befindet. Während sich der Button in diesem Ladezustand befindet, werden alle Maus- und Tastatureingaben innerhalb des Formulars ignoriert. Alle enthaltenen interaktiven Elemente werden für diese Zeit aus der Tabreihenfolge ausgenommen. Außerdem wird der Formularinhalt mit einer weißen Fläche von 50% Deckkraft überlagert. Der Undo-Button wird während des Speicherns deaktiviert. Sollte das Speichern (z. B. wegen Validierungsfehlern) nicht erfolgreich sein, so wechselt der Undo-Button in den aktiven Zustand zurück und der vorherige Undo-Stack bleibt erhalten.
• Falls Validierungsfehler im Formular festgestellt werden, wird das entsprechende Fehlerbanner angezeigt (siehe oben: Ablauf Front-/Backend/Validierun"). Der Speichern-Button springt wieder zurück zum Standard-Status (aktiv ohne Ladeanimation).
• Falls keine Validierungsfehler festgestellt werden und das Speichern erfolgreich durchgeführt wurde, so wird für eine Sekunde ein Häkchen-Symbol angezeigt. Dieses ist als Layoutgrafik deklariert. Gleichzeitig ertönt ein akustisches Signal: Erfolgsmeldung (siehe Akustische Signale). Danach wird der Button disabled. Fokussetzung siehe unten: "Tastaturbedienung".

• Nutzende klicken in Neuanlage-Formular bzw. Wizard auf den “Anlegen”-Button. 
• Im Button erscheint nach Klick eine Ladeanimation (wie in Beispiel 1). 
• Falls Validierungsfehler im Formular festgestellt werden, wird das entsprechende Fehlerbanner angezeigt (siehe oben: Ablauf Front-/Backend/Validierung). Der Speichern-Button springt wieder zurück zum Standard-Status (aktiv ohne Ladeanimation).
• Nach erfolgreichem Speichern schließt sich das Formular (ohne vorheriges Häkchen im Button, wie in Beispiel 1), Nutzende werden zur Datenübersicht zurückgeleitet und der neu angelegte Eintrag ist darin bereits enthalten. Unter Umständen ist dieser, falls es sich um eine paginierte Tabelle oder Liste handelt, nicht direkt sichtbar.
• Über der Datenübersicht (z. B. Tabelle/Liste/Baumstruktur/Kalender) erscheint ein Bestätigungsbanner. Fokussetzung siehe unten: Tastaturbedienung.

• Nutzende klicken im Neuanlage-Wizard auf den “Anlegen”-Button. Der Button zeigt das erfolgreiche Speichern mittels einer Lade- und Bestätigungs-Animation (wie in Beispiel 1) an. 
• Nach erfolgreichem Speichern öffnet sich das neu angelegte Verfahren im selben Browsertab (ohne vorheriges Häkchen im Button, wie in Beispiel 1). Fokussetzung siehe unten: Tastaturbedienung.

• Nutzende klicken im Unterobjekt auf “Hinzufügen/Übernehmen” und es gibt keine Animation im Button bzw. einen Bestätigungston.
• Falls Validierungsfehler im Formular festgestellt werden, wird das entsprechende Fahlerbanner angezeigt (siehe oben: Ablauf Front-/Backend/Validierung). 
• Solange keine Validierungsfehler vorliegen, wird das Formular des Unterobjekts ohne Buttonanimation oder Ton geschlossen. Fokussetzung siehe unten: Tastaturbedienung.

Header und Footer des Formulars sind bei ausreichend großem Bildschirm sticky und somit beim Scrollen durch das Formular immer sichtbar. 

Ab einer Formularhöhe unter 672 Pixeln ist der Header des Formulars nicht mehr sticky, d.h. er verschwindet beim Scrollen. Der Footer bleibt sticky. 

Unterhalb von 432 Pixeln Formularhöhe bleibt auch der Formularfooter nicht mehr sticky.

Sobald nicht das komplette Formular im sichtbaren Bereich liegt und Scrollen erforderlich ist, ist die Scrollbar permanent sichtbar.

Der Formularfooter ist bis bis zu einer Formularhöhe von 432 Pixeln sticky. Bei kleinerer Formularhöhe ist er nicht mehr permanent sichtbar.

Sobald der horizontale Platz nicht mehr ausreicht, um alle Buttons, mit je 16px Abstand zueinander, nebeneinander darzustellen, werden “Rückgängig-” und “Wiederholen-Button”, in einem “Weitere Aktionen”-Button zusammengefasst (siehe Pop-Up-Menü). Der Alternativtext des Buttons lautet: “Weitere Aktionen”. 

Der “Rückgängig-/Wiederholen-Button” im Pop-Up-Menü ist wie folgt bezeichnet: 

• Undo: Rückgängig machen der Eingabe von “[Eingabefeldtitel]" 
• Redo: Wiederherstellen der Eingabe von “[Eingabefeldtitel]"

Wenn der Weitere-Aktionen-, der Schließen- und der primäre Aktionsbutton (z. B. Speichern) nicht mehr nebeneinander Platz finden, wird der Schließen-Textbutton zu einem Button mit X-Symbol ohne Text. Der Alternativtext/Tooltip des Icon-Buttons lautet dann entsprechend “Schließen”.

Sollte der Buttontext des primären Buttons so lang sein, dass dieser mit dem verfügbaren Platz nicht mehr vollständig dargestellt werden kann, so wird der Button mehrzeilig und der Footer wird entsprechend höher.

Bei wenig Platz oder langen Gruppentiteln bzw. längeren/mehreren StatusBadges brechen Titel und Status-Badges um und werden mehrzeilig. Der Entfernen-Button richtet sich “bottom aligned” zum Titel aus.

Der Abstand zwischen der Gruppentitel-Textbox (inkl. Badges) und dem Entfernen-Button beträgt 16 Pixel. Sobald der Gruppentitel (inkl. Badges) in der Breite bei Skallieren des Fensters keine 200px Platz mehr erreichen kann, wird aus dem Entfernen-Button mit Icon und Text ein reiner Icon-Button (Entfernen-Symbol).

Abhängig von der Formularbreite können bis zu drei Karten nebeneinander angezeigt werden. Gibt es mehr Karten, als in einer Zeile Platz finden, wird eine weitere Zeile erzeugt, bis alle Karten verteilt wurden.

Karten werden am Formulargrid ausgerichtet. Für den Inhaltsbreich der Karte gibt es kein eigenes Umbruchverhalten.

Kartenbreite (in Bezug zur Formularbreite):

• Ab 1400 Pixel: 3 Karten pro Zeile (4 Spalten pro Karte)
• 1025 Pixel – 1399 Pixel: 2 Karten pro Zeile (6 Spalten pro Karte)
• Bis 1024 Pixel: 1 Karte pro Zeile (12 Spalten pro Karte) 

Sortierung:

• Nach Hinzufügen einer Karte und anschließender Rückkehr ins Elternformular ist die neue Karte an letzter Stelle platziert.
• Nach Bearbeiten einer Karte im Unterformular, Ausführen der Aktion “Übernehmen” und anschließender Rückkehr ins Elternformular ist die Karte weiterhin so platziert, wie vor Öffnen des Unterformulars, auch wenn sich deren Titel durch die Bearbeitung geändert haben sollte.
• Wird im Unterformular der Karte die Aktion “Schließen” ausgeführt, so ist die Kartensortierung nach Rückkehr ins Elternformular ebenfalls unverändert zum Zeitpunkt vor Öffnen des Unterformulars.
• Wird ein Karten-Unterobjekt aus dem Header des Unterformulars heraus entfernt, so kehren Nutzende in das Hauptformular zurück und die eben entfernte Karte wird nicht mehr angezeigt. Mögliche Folgekarten rutschen nach oben nach, die Sortierung bleibt jedoch unverändert zu der Kartenreihenfolge vor Öffnen des Unterformulars.
• Wird im Hauptformular die Aktion “Speichern” ausgeführt und das Formular bleibt geöffnet, so bleibt die Sortierung der Karten im Formularinhalt auch nach erfolgreichem Speichern unverändert.
• Wird ein Formular (egal ob Haupt- oder Unterformular) geschlossen und dann erneut geöffnet, so sind alle Karten anschließend standardmäßig alphanumerisch aufsteigend sortiert. Falls fachlich eine andere Sortierung gewünscht ist (z. B. chronologisch nach Anlage-/Bearbeitungzeitpunkt), so ist diese Sortierung in Userstories zu beschreiben.
  

Details zur Navigation und Fokussetzung siehe unten bei "Tastaturbedienung" und Navigationskonzept innerhalb GeFa: Unterobjekte entfernen).

Bei mehreren Karten pro Zeile:

• Alle Karten der selben Zeile haben die gleiche Höhe
• Die Karte mit dem größten Kopfbereich der Zeile bestimmt die Höhe der Kopfbereiche der anderen Karten der selben Zeile
• Die Karte mit dem größten Inhaltsbereich der Zeile bestimmt die Höhe der Inhaltsbereiche der anderen Karten der selben Zeile

Der Alternativtext des “Weitere Aktionen” Buttons lautet: “Weitere Aktionen”.

Bei Formularheadern ist die Ausgabereihenfolge für den Screenreader: Zuerst Formulartitel, dann der Status-Badge, dann der “Weitere Aktionen”-Button.

Der Alternativtext für die Buttons Undo & Redo lautet:

• Undo: Rückgängig machen der Eingabe von „[Eingabefeldtitel]" 
• Redo: Wiederherstellen der Eingabe von „[Eingabefeldtitel]"

Sonderfall: Bei Feldern innerhalb von Elementgruppen lautet der Alternativtext:

• Rückgängig machen der Eingabe von „[Name der Gruppe] – [Eingabefeldtitel]”
• Wiederherstellen der Eingabe von „[Name der Gruppe] – [Eingabefeldtitel]”

Bei Wertebereichsfeldern lautet der Alternativtext: 

• Rückgängig machen der Eingabe von „[Label des Wertebereichsfeldes] – [Label des Teilfeldes]”
• Wiederherstellen der Eingabe von „[Label des Wertebereichsfeldes] – [Label des Teilfeldes]”

Bei Wertebereichsfeldern innerhalb von Elementgruppen lautet der Alternativtext: 

• Rückgängig machen der Eingabe von „[Name der Gruppe] – [Label des Wertebereichsfeldes] – [Label des Teilfeldes]”
• Wiederherstellen der Eingabe von „[Name der Gruppe] – [Label des Wertebereichsfeldes] – [Label des Teilfeldes]”

Bei Hinzufügen einer Gruppe/eines weiteren Feldes:

• “Rückgängig machen der Aktion [Buttontext]”
• “Wiederherstellen der Aktion [Buttontext]”

Falls es sich bei der durchgeführten Aktion, nicht um ein Eingabe- oder Auswahlfeld gehandelt hat, wird statt dem Eingabefeldtitel verwendet: 

• Bei Radiobutton-/Checkbox-Gruppen: “Rückgängig machen/Wiederherstellen der Eingabe von [Gruppentitel]”
• Bei einzelner Checkbox ohne Titel: “Rückgängig machen/Wiederherstellen der Eingabe von [Checkbox-Text]”
• Bei Hinzufügen-Buttons der Buttontext bzw. bei Icon Buttons der Alternativtext: “Rückgängig machen/Wiederherstellen der Eingabe von [Button-Text]”

Bei durchgeführten Aktionen mit Kindobjekten:

• Rückgängig machen/Wiederherstellen des Hinzufügens von „[Kindobjektbezeichnung]”
• Rückgängig machen/Wiederherstellen der Bearbeitung von „[Kindobjektbezeichnung]”
• Rückgängig machen/Wiederherstellen des Entfernens von „[Kindobjektbezeichnung]”

Für Spezifizierungen zu den verschiedenen Button-Status siehe Button: Zustände. 
Für Details zum Undo-/Redo-Konzept siehe Navigationskonzept innerhalb GeFa: Undo & Redo.

Der Alternativtext des Ladesymbols lautet “Formularinhalte werden geladen”. Dieser wird auch als Tooltip angezeigt, wenn mit der Maus exakt über dem Lade-Icon gehovert wird. 
Der Ladezustand ist im Code als Überschrift der Hierarchiestufe gekennzeichnet, die der Formulartitel im jeweiligen Seitenlayout hätte, damit die Inhaltsstruktur der Seite auch beim Laden konsistent bleibt (in der Regel H2, siehe Seitenaufbau).
 

Der Alternativtext des Ladezustands wird automatisch vom Screenreader ausgegeben, auch wenn sich der Fokus nicht auf dem Icon befindet. Allerdings wird er, um Audionoise zu vermeiden, erst dann ausgegeben, wenn 2 Sekunden nach Öffnen der Seite die Formularinhalte noch nicht vollständig geladen sind. Falls das Laden noch länger dauert, wird alle 10 Sekunden erneut der Alternativtext des Ladesymbols “Formularinhalte werden geladen” ausgelesen, unabhängig davon, wo sich der Fokus auf der Seite zu der Zeit befindet.

Nach vollständigem Laden der Formularinhalte wird der Text “Formularinhalte geladen” vom Screenreader ausgegeben. Dies wird nur ausgegeben, wenn das Laden davor länger als 2 Sekunden gedauert hat und die Ergebnisse nicht vorher sichtbar wurden. Die Ausgabe erfolgt unabhängig davon, wo sich der Fokus auf der Seite zu der Zeit befindet.

Der Tooltip des Entfernen-Buttons lautet “[Bezeichnung des Eingabefeldes] entfernen”. Dies entspricht auch der Screenreaderausgabe.

Das Plus-Symbol im “[Eintrag] hinzufügen” Button ist als Layoutgrafik zu deklarieren.

Der Tooltip des Löschenbuttons lautet “[Bezeichnung des Eingabefeldes] entfernen”. Dies entspricht auch der Screenreaderausgabe.

Vom Screenreader werden Trennlinien nicht ausgegeben.

Die Zwischenüberschrift wird (anders als bei der Elementgruppe) nicht bei jedem untergeordneten Element vom Screenreader mit ausgelesen. Daher ist darauf zu achten, dass die Benennung der auf die Überschrift folgenden Elemente eindeutig bleibt. 

• Richtiges Beispiel: Überschrift “Gültigkeit”; enthaltene Datumseingabefelder “Gültig ab” und “Gültig bis”
• Falsches Beispiel: Überschrift “Gültigkeit”; enthaltene Datumseingabefelder “Ab” und “Bis”

Der Titel wird im Code als Überschrift ausgezeichnet Visuell wird der Schrifttyp H4 verwendet. 

Die Überschriftenebene in der Code-Auszeichnung ist abhängig vom jeweiligen Seitenlayout. Alle Karten des selben Formularabschnitts erhalten die gleiche Überschriftenebene: 

• Falls die Karten in einem Formular mit Zwischensektionen verwendet werden, ist die Hierarchieebene eine unterhalb der Überschriftenebene der Akkordeons. 
• Falls die Karten in einem Formular ohne Zwischensektionen verwendet werden, ist die Hierarchieebene eine unterhalb der Überschriftenebene des Formulars.

Die Ausgabereihenfolge für den Screenreader ist: Zuerst Kartentitel, dann der Status-Badge, dann der Button.

• Fokussetzung nach Öffnen eines Formulars siehe jeweiliger Seitentyp.
• Mit Tab Taste und Pfeiltasten kann entsprechend zu nächsten oder vorherigen Elementen gewechselt werden (z. B. Akkordeon oder Eingabefeld).
• Das Pop-up Menü verhält sich wie definiert.

• Mit der Tab Taste wird von von Button zu Button gewechselt (von links nach rechts: Undo, Redo, Abbrechen, Speichern) 
• Inaktive/Disabled Buttons werden dabei übersprungen und sind nicht fokussierbar.
• Klick auf Enter oder Leertaste führt die Aktion aus. Je nach dem, ob es sich bei dem Formular um ein Haupt- oder Unterformular, um eine Neuanlage oder Bearbeitung eines bereits existierenden Objekts handelt, unterscheidet sich die anschließende Fokussetzung (siehe auch Navigationskonzept innerhalb GeFa: Tiefennavigation in Inhaltsbereichen):

UNDO/REDO:

• • Nach Ausführen von “Undo” verbleibt der Fokus auf dem Button. Ist dieser nach Ausführen der Aktion deaktiviert, weil keine weiteren Aktionen rückgängig machbar sind, so wird der Fokus anschließend auf den “Redo”-Button gesetzt.
  • Nach Ausführen von “Redo” verbleibt der Fokus auf dem Button. Ist dieser nach Ausführen der Aktion deaktiviert, weil keine weiteren Aktionen wiederholt werden können, so wird der Fokus anschließend auf den “Undo”-Button gesetzt.

SEKUNDÄRAKTION

• • Nach Ausführen der Aktion “Schließen” in Haupt-/Nebenobjekt-Neuanlagen gilt die Standardfokussetzung des jeweiligen Seitentyps: In der Regel liegt der Fokus auf dem ersten interaktiven Element im Inhaltsbereich/Main (siehe Seitenaufbau).
  • Nach Ausführen der Aktion “Schließen” in Haupt-/Nebenobjekt-Bearbeitungsformularen gilt:
  • • Falls das Objekt ermittelbar ist (auf aktueller Seite der paginierten Tabelle), dann wird der Fokus auf die erste Zelle des gerade bearbeiteten Objekts gelegt (Bei Listen auf das bearbeitete Listenelement, bei Baumstrukturen auf das bearbeitete Baumelement).
    • Falls das Objekt nicht ermittelbar ist (z. B. weil es durch Bearbeitung der Objektbezeichnung auf eine andere Seite der paginierten Tabelle gerutscht ist), landet der Fokus auf dem Suchfeld über der Tabelle/Liste/Baumstruktur.
  • Nach Ausführen der Aktion “Schließen” in Unterobjekt-Neuanlagen liegt der Fokus auf dem “[Unterobjekt] hinzufügen” Button im Elternformular.
  • Nach Ausführen der Aktion “Schließen” in Bearbeitungsformularen von Unterobjekten liegt der Fokus wieder auf dem “Bearbeiten”-Button des Objekts, von dem aus das Unterformular geöffnet wurde (in der Regel in Aktionsspalte einer Tabelle oder Kopfbereich einer Karte).

PRIMÄRAKTION

• • Nach erfolgreichem Ausführen der Aktion “Speichern” in bereits angelegten Haupt-/Nebenobjekten bleibt das Formular geöffnet und der Fokus wechselt auf den “Schließen”-Button.
  • Nach erfolgreichem Ausführen der Aktion “Anlegen” bzw. “Zuordnen” in neuen Haupt-/Nebenobjekten und anschließender Rückkehr in die Datenübersicht liegt der Fokus auf dem Link im Bestägigungsbanner (siehe Erfolgsmeldungen). Falls nach Anlage nicht in eine Datenübersicht zurückgekehrt wird (bspw. nach Anlage eines Verfahrens), so gilt nach Öffnen der Seite die Standardfokussetzung des entsprechenden Seitentyps (siehe Seitenaufbau).
  • Nach erfolgreichem Ausführen der Aktion “Hinzufügen” in Unterobjekten liegt der Fokus nach Rückkehr ins Elternformular auf dem “[Unterobjekt] hinzufügen” Button. Falls dieser nicht mehr vorhanden oder deaktiviert ist, weil kein weiteres Objekt hinzugefügt werden kann, so wird der Fokus auf das nächste interaktiven Element oberhalb gelegt.
  • Nach erfolgreichem Ausführen der Aktion “Übernehmen” in Unterobjekten und Rückkehr ins Elternformular wird der Fokus auf den “Bearbeiten”-Button (in Tabelle oder Karte) des gerade geöffneten Unterobjekts gelegt. Falls das Objekt nicht mehr lokalisierbar ist (z. B., weil es durch die Bearbeitung der Objektbezeichnung auf eine andere Seite einer paginierten Tabelle gerutscht ist), dann wird der Fokus auf das über der Tabelle liegende Akkordeon gelegt. Falls kein Akkordeon vorhanden ist, dann wird der Fokus auf das erste fokussierbare Element in der Tabelle gelegt (bei sortierbaren Tabellen ist das die erste sortierbare Spalteüberschrift, sonst die erste Zelle des ersten Datensatzes im Tabelleninhalt).
  • Kann eine der Aktionen “Speichern/Anlegen/Zuordnen/Übernehmen/Hinzufügen” auf Grund von Validierungsfehlern nicht ausgeführt werden, so bleibt das Formular geöffnet, ein Fehlerbanner erscheint und der Tastaturfokus liegt auf der Überschrift dieses Banners (siehe auch oben bei "Fehlermeldungsbereich in Formularen”).
• Für Verhalten des “Mehr Aktionen” Buttons (bei kleinen Screenbreiten) siehe Pop-Up-Menü

• Der “Gruppe hinzufügen” Button kann mit der Tab-Taste fokussiert werden.
• Enter- oder Leertaste bei fokussiertem “Gruppe hinzufügen-Button” führt die Aktion aus und die neue Gruppe erscheint ODER ein Modalfenster öffnet sich. Der Tastaturfokus befindet sich anschließend im ersten Eingabefeld innerhalb der neu hinzugefügten Gruppe ODER im ersten Eingabefeld des geöffneten Modals.
• Durch Klicken der Tab-Taste kann der “Entfernen-Button” bzw. bei deaktivierten Gruppen der “Auf-/Zuklappen-Button” fokussiert werden.
• Durch Enter oder Leertaste bei fokussiertem “Entfernen-Button” (Details zur Fokussetzung nach Entfernen einer Elementgruppe siehe Navigationskonzept innerhalb GeFa: Löschen und Entfernen):
• 1. Falls durch entfernen der Gruppe keine deaktivierte Gruppe wieder aktiv wird: Die Aktion wird ausgeführt und die Gruppe verschwindet. Der Tastaturfokus befindet sich anschließend auf dem nächsten Element unterhalb des soeben entfernten Elements

  2. Falls durch entfernen der Gruppe eine deaktivierte Gruppe wieder aktiviert wird: Eine Meldung vom Typ Sicherheitsabfrage erscheint. Nach Bestätigen innerhalb der Sicherheitsabfrage verschwindet die ganze Gruppe und alle Inhalte werden gelöscht. Der Tastaturfokus liegt anschließend auf dem nächsten Element unterhalb des soeben entfernten Elements. Wird die Aktion in der Sicherheitsabfrage abgebrochen, bleibt die Gruppe unverändert bestehen und der Tastaturfokus liegt wieder auf dem “Entfernen” Button.
• Enter oder Leertaste bei fokussiertem “Auf-/Zuklappen-Button” öffnet die Sektion (falls geschlossen) oder schließt die Sektion (falls geöffnet). Der Tastaturfokus verbleibt auf dem Button.
• Klicken der Tab-Taste bei fokussiertem “Auf-/Zuklappen-Button” setzt den Fokus auf das erste interaktive Element im Inhaltsbereich der Gruppe (wenn geöffnet) bzw. auf das erste interaktive Element unterhalb der Gruppe (falls geschlossen).

• Mit Tab-Taste kann zum “Eintrag hinzufügen”-Button navigiert werden
• Enter- oder Leertaste führt die Aktion aus. Es gibt dann zwei mögliche Wege (basierend auf fachlicher Anforderung):
• • Wenn fachlich keine Zusatzbezeichnung erforderlich ist, erscheint das neue Feld sofort in der Maske. Der Fokus befindet sich dann im neu hinzugefügten Feld. 
  • Wenn fachlich zusätzliche Angaben zu Feldtyp oder Zusatzbezeichnung erforderlich ist, öffnet sich ein Modal. Der Fokus liegt auf dem ersten interaktiven Element im Inhaltsbereich des Modals. Nachdem im Modal die Aktion “Übernehmen” ausgeführt wurde, befindet sich der Fokus im neu hinzugefügten Feld. Wenn im Modal die Aktion “Schließen” ausgeführt wurde, befindet sich der Fokus auf dem “[Eintrag] hinzufügen”-Button.
• Mit der Tab-Taste kann vom hinzugefügten Feld zum Entfernen-Button gesprungen werden. 
• Enter- oder Leertaste führt das Entfernen aus. Details zur Fokussetzung nach Entfernen eines Elements siehe Navigationskonzept innerhalb GeFa: Löschen und Entfernen.

• Mit Tab-Taste kann zum “[Label] bearbeiten”-Button navigiert werden
• Enter- oder Leertaste führt die Aktion aus. Es erscheint sofort ein neues Feld bzw. eine neue Gruppe in der Maske. Der Fokus befindet sich im neu hinzugefügten Feld, bei Gruppen auf dem ersten Feld in der Gruppe.
• Mit der Tab-Taste wandert der Fokus zum nächsten interaktiven Element (Bei einem einzelnen hinzugefügten Feld zum Entfernen-Button, bei einer Gruppe zunächst zum nächsten Element im Gruppeninhalt).
• Der „Entfernen”-Button kann mit Enter- oder Leertaste ausgelöst werden. Das Feld bzw. die Gruppe verschwindet, der “[Label] bearbeiten”-Button erscheint wieder. Der Fokus befindet sich anschließend auf dem wieder reaktivierten Read-Only-Eingabefeld.

• Keine Interaktion möglich.

• Keine Interaktion möglich.
• Ist die Zwischenüberschrift fokussiert (im oben beschriebenen Ausnahmefall), so kann mit Tab, der Fokus zum nächsten Element geschoben werden.

• Tab fokussiert den Button im Kartenheader (sofern aktiv)
• erneuter Tab-Klick fokussiert das erste Read-Only Element im Inhaltsbereich der Karte
• Enter oder Leertaste bei fokussiertem Button im Kartenheader öffnet das Unterformular.
• Der erneute Klick auf die Tab-Taste fokussiert das nächste Steuerelement.
• Die Karten werden innerhalb einer Zeile von links nach rechts angesprungen. Ist das Ende einer Zeile erreicht, wird die erste Karte der nächsten Zeile angesprungen.

• Siehe Links.

• Keine Interaktion mit der Fehlermeldung selbst möglich.
• (Siehe entsprechende Eingabe- / Auswahlelemente)

• Mit Tab kann die Formularfeld-unabhängige Fehlermeldung fokussiert werden
• Durch erneutes Drücken der Tab-Taste wechselt der Fokus zum nächsten interaktiven Element.

• Mit Tab-Taste kann von Eingabefeld zu Eingabefeld gesprungen werden. Liegen Front-end Fehler bei einem gerade verlassenen Feld vor, so werden diese, sofern eine Wertänderung stattgefunden hat, bei Verlassen des Feldes angezeigt. Außerdem ertönt gleichzeitig ein akustisches Signal (siehe Akustische Signale).
• Liegen Front-end Fehler vor, werden diese, sofern eine Wertänderung stattgefunden hat, bei Verlassen des Feldes angezeigt. Außerdem ertönt gleichzeitig ein akustisches Signal (siehe Akustische Signale).
• Wird die Aktion “Speichern” im Formular Footer ausgeführt, findet anschließend die Backend-Validierung statt. 
• Falls keine Fehler gefunden werden: Speichern-Button zeigt erfolgreiches Speichern an (siehe oben bei Erfolgsindikatoren Formular-Footer).
• Falls Fehler gefunden wurden: Unter dem Formularheader erscheint ein Meldungsbereich, in dem alle gefundenen Fehler untereinander aufgelistet sind. Sie enthalten jeweils einen tertiären Button (springt zum jeweiligen Feld). 
• Sobald die Fehlermeldung oben erscheint, scrollt das Formular automatisch ganz nach oben und der Fokus wird auf die Überschrift der Meldung gesetzt.
• Mit Tab-Taste kann zum nächsten Button gesprungen werden.
• Klicken auf Enter oder Leertaste lässt den Fokus zum jeweiligen Feld springen. Das Formular scrollt an die entsprechende Stelle.
• (Zu prüfen: Ggf. Shortcut, um zur Fehlerübersicht zurück zu springen)

• Siehe oben: Meldungsbanner in Formularen
• Siehe oben: Validierungsfehler an Formularfeldern
• Siehe oben: Formularfeld-unabhängige Validierungefehler

• Siehe oben: Formular Footer. Enthält die detailierte Beschreibung der Fokussetzung nach Ausführen der Aktionsbuttons. Die Fokussetzung unterscheidet sich, je nach dem, ob es sich bei dem Formular um eine Neuanlage/Bearbeitung oder um ein Haupt- bzw. Unterformular handelt.
• Siehe Erfolgsmeldungen

• Durch Klick auf den Button rechts oben öffnet sich das Popup, in dem weiterführende Aktionsbuttons angezeigt sind. 
• Durch Klick mit linker Maustaste auf einen der Einträge wird die entsprechende Aktion ausgeführt.

• Klick mit linker Maustaste auf einen aktiven Button führt die Aktion aus. Für Fokussetzung nach Ausführen einer Aktion siehe oben Abschnitt “Tastaturbedienung”.
• Für Verhalten des “Mehr Aktionen” Buttons (bei kleinen Screenbreiten) siehe Beschreibung Pop-Up-Menü

• Klicken auf den “Gruppe hinzufügen” Button führt die Aktion aus und die neue Gruppe erscheint ODER ein Modalfenster öffnet sich. Der Tastaturfokus befindet sich anschließend im ersten Eingabefeld innerhalb der neu hinzugefügten Gruppe ODER im ersten Eingabefeld des geöffneten Modals.
• Nach Klicken auf den Entfernen-Button:

• 1. Falls durch entfernen der Gruppe keine deaktivierte Gruppe wieder aktiv wird: Die Aktion wird ausgeführt und die Gruppe verschwindet. Der Tastaturfokus befindet sich anschließend auf dem nächsten Element unterhalb des soeben entfernten Elements
  2. Falls durch entfernen der Gruppe eine deaktivierte Gruppe wieder aktiviert wird: Eine Meldung vom Typ Sicherheitsabfrage erscheint. Nach Bestätigen innerhalb der Sicherheitsabfrage verschwindet die ganze Gruppe und alle Inhalte werden gelöscht. Der Tastaturfokus liegt anschließend auf dem nächsten Element unterhalb des soeben entfernten Elements. Wird die Aktion in der Sicherheitsabfrage abgebrochen, bleibt die Gruppe unverändert bestehen und der Tastaturfokus liegt wieder auf dem “Entfernen” Button.
• Klick mit linker Maustaste auf den “Auf-/Zuklappen-Button” öffnet die Gruppe (falls geschlossen) oder schließt die Gruppe (falls geöffnet) und setzt den Tastaturfokus auf den Button.

• Klick mit linker Maustaste führt den “Eintrag hinzufügen”-Button aus. Es gibt dann zwei mögliche Wege (basierend auf fachlicher Anforderung):
• • Wenn fachlich keine Zusatzbezeichnung erforderlich ist, erscheint das neue Feld sofort in der Maske. Der Fokus befindet sich dann im neu hinzugefügten Feld. 
  • Wenn fachlich zusätzliche Angaben zu Feldtyp oder Zusatzbezeichnung erforderlich ist, öffnet sich ein Modal. Der Fokus liegt auf dem ersten interaktiven Element im Inhaltsbereich des Modals. Nachdem im Modal die Aktion “Übernehmen” ausgeführt wurde, befindet sich der Fokus im neu hinzugefügten Feld. Wenn im Modal die Aktion “Schließen” ausgeführt wurde, befindet sich der Fokus auf dem “[Eintrag] hinzufügen”-Button.
• Klick mit linker Maustaste auf den Entfernen-Button entfernt den Eintrag wieder. Details zur Fokussetzung nach Entfernen eines Elements siehe Navigationskonzept innerhalb GeFa: Löschen und Entfernen.

• Klick mit linker Maustaste führt den “[Label] bearbeiten”-Button aus. Es erscheint sofort ein neues Feld bzw. eine neue Gruppe in der Maske. Der Fokus befindet sich im neu hinzugefügten Feld, bei Gruppen auf dem ersten Feld in der Gruppe.
• Klick mit linker Maustaste auf den Entfernen-Button entfernt den Eintrag wieder, der “[Label] bearbeiten”-Button erscheint wieder. Der Fokus befindet sich anschließend auf dem wieder reaktivierten Read-Only-Eingabefeld.

• Keine Interaktion möglich.

• Keine Interaktion möglich.
• Ist die Zwischenüberschrift fokussiert (im oben beschriebenen Ausnahmefall), so kann durch Klick mit linker Maustaste auf ein anderes interaktives Element, dieses fokussiert werden.

• Klick mit der linken Maustaste auf den Button im Kartenheader (sofern aktiv) öffnet das Unterformular.

• Siehe Links.

• Keine Interaktion mit der Fehlermeldung selbst möglich.
• (Siehe entsprechende Eingabe-/Auswahlelemente)

• Klick mit linker Maustaste auf die Formularfeld-unabhängige Fehlermeldung fokussiert diese. 
• Klick auf ein anderes Interaktives Element auf der Seite wechselt den Fokus zu diesem.

• Durch Klick mit linker Maustaste auf ein Eingabe-/Auswahlfeld wird dieses fokussiert. Liegen Front-end Fehler bei einem gerade verlassenen Feld vor, so werden diese, sofern eine Wertänderung stattgefunden hat, bei Verlassen des Feldes angezeigt. Außerdem ertönt gleichzeitig ein akustisches Signal (siehe Spezifikationen zu Eingabe- und Auswahlfeldern).
• Klick mit linker Maustaste auf den Speichern-Button führt die Aktion aus (siehe auch oben: Formular Footer)
• Falls keine Fehler gefunden wurden: Speichern-Button zeigt erfolgreiches Speichern an (siehe oben: Erfolgsindikatoren Formular-Footer).
• Falls Fehler gefunden wurden: Unter dem Formularheader erscheint ein Meldungsbereich, in dem alle gefundenen Fehler (Front- und Backend) untereinander aufgelistet sind. Sie enthalten jeweils einen tertiären Button (springt zum jeweiligen Feld).
• Sobald die Fehlermeldung oben erscheint, scrollt das Formular automatisch ganz nach oben und der Fokus wird auf die Überschrift der Meldung gesetzt.
• Klick mit linker Maustaste auf einen der Buttons lässt den Fookus zum jeweiligen Element springen und das Formular an die entsprechendende Stelle scrollen.

• Siehe oben: Meldungsbanner in Formularen
• Siehe oben: Validierungsfehler an Formularfeldern
• Siehe oben: Formularfeld-unabhängige Validierungefehler

• Siehe oben: Formular Footer. Enthält die detailierte Beschreibung der Fokussetzung nach Ausführen der Aktionsbuttons. Die Fokussetzung unterscheidet sich, je nach dem, ob es sich bei dem Formular um eine Neuanlage/Bearbeitung oder um ein Haupt- bzw. Unterformular handelt.
• Siehe Erfolgsmeldungen

• Siehe oben: Standardverhalten bei Wertänderungen mit Konsequenzen für Folgefelder