Changelog

🚀 Inkrement 17

GD-431

• Spezifikation für Kalenderinhalte der Monatsansicht

🚀 Inkrement 17

GD-722

• Checkboxen innerhalb von Tabellen können im Disabled-Zustand vorkommen.

🚀 Inkrement 17

GD-359

Verhalten

• Die Beschriftung und Darstellung des Suchfeldes wurden präzisiert.
• Das Suchfeld erhält die programmatische Beschriftung sowie den visuellen Platzhaltertext „Suche nach [Bezeichnung]“.
• Bei Fokuserhalt wird die programmatische Beschriftung vom Screenreader ausgegeben. Der Platzhaltertext wird mit Beginn der Eingabe ausgeblendet.
• Nach dem Zurücksetzen des Suchfeldes wird der Platzhaltertext wieder angezeigt.

🚀 Inkrement 17

GD-406

Zellen mit mehreren Attributen

Lange Zelleninhalte

• Für Tabellenzellen mit mehreren Attributwerten wurden Darstellungsregeln definiert.
• Standardmäßig werden bis zu zwei Werte vollständig dargestellt. Ab drei Werten wird der erste Wert angezeigt und die Anzahl der weiteren Werte mit „und [Anzahl] weitere“ zusammengefasst.
• Alternativ können mehrere kurze Werte vollständig und durch Semikolon getrennt dargestellt werden.
• Die Reihenfolge der dargestellten Werte sowie deren Berücksichtigung bei der Spaltensortierung wurden definiert.
• Für lange, nicht vollständig darstellbare Zelleninhalte wurden Regeln zur Kürzung mit „...“ sowie zur vollständigen bzw. ergänzenden Ausgabe über Tooltip und Screenreader definiert.

🚀 Inkrement 17

GD-366

Verhalten

• Die programmatischen Beschriftungen für die Tabs im Ergebnisanzeigebereich der erweiterten Suche wurden definiert.
• Die Tabgruppe erhält die Beschriftung „Ergebnistyp“.
• Bei responsiver Darstellung als Einfachauswahlfeld lautet die Beschriftung „Auswahl Ergebnistyp“.

🚀 Inkrement 17

GD-326

Verhalten

• Die Darstellung der Detailbeschreibung in Modaldialogen wurde erweitert.
• Neben Fließtext können Detailbeschreibungen nun auch Aufzählungen bzw. eine Kombination aus Fließtext und Aufzählungen enthalten.

🚀 Inkrement 17

GD-289

Verhalten der Sortierfunktion

• Für Listen wurde eine Funktion zur Auswahl des Sortierkriteriums ergänzt.
• Das Sortierkriterium wird über ein reduziertes Einfachauswahlfeld ausgewählt und das aktuell verwendete Kriterium angezeigt.
• Standardmäßig werden Listen anhand ihrer primären Information alphabetisch aufsteigend sortiert. Weitere verfügbare Sortierkriterien werden fachlich definiert.
• Das aktuell verwendete Sortierkriterium muss als Information in den Listeneinträgen sichtbar sein. Bei einer Sortierung nach einem anderen Kriterium als der Primärinformation wird der entsprechende Wert als Sekundärinformation dargestellt.

🚀 Inkrement 17

GD-235

Verhalten bei Eingabe einer Telefonnummer

• Die Erfassung von Telefonnummern wurde präzisiert und zwischen Festnetz- und Mobilfunknummern unterschieden.
• Telefonnummern werden ohne automatische Umformatierung in einem einzeiligen Eingabefeld erfasst.
• Für Festnetz- und Mobilfunknummern wurden jeweils spezifische Hinweistexte mit Formatbeispielen für deutsche und internationale Telefonnummern definiert.

🚀 Inkrement 17

GD-490

Tiefennavigation innerhalb von Tabs & Verhalten bei Tabwechsel

• Das Verhalten für die Tiefennavigation innerhalb von Tabs und den Wechsel zwischen Tabs wurde definiert.
• Innerhalb eines Tabs ist eine Navigation in tiefere Ebenen möglich; die Pfadnavigation bildet dabei den jeweiligen Objektpfad ab.
• Bei einem Tabwechsel wird immer die Startseite des ausgewählten Tabs im Initialzustand geladen. Zuvor besuchte Navigationsebenen sowie Such-, Filter- und andere temporäre Zustände werden nicht beibehalten.
• Die Inhalte des ausgewählten Tabs werden bei jedem Tabwechsel neu geladen.
• Bei ungespeicherten Formulareingaben wird vor dem Tabwechsel eine Sicherheitsabfrage angezeigt. Wird der Tabwechsel bestätigt, werden die Änderungen verworfen; bei Abbruch bleiben der aktuelle Tab und die Eingaben erhalten.

🚀 Inkrement 16

GD-723

• Das Verhalten der Sammelauswahl über die Kopf-Checkbox wurde präzisiert:
• Es werden ausschließlich auswählbare (aktive) Zeilen selektiert.
• Deaktivierte Checkboxen werden von der Sammelauswahl nicht berücksichtigt.
• Sind alle Checkboxen auf der aktuellen Seite deaktiviert, wird die Kopf-Checkbox ebenfalls deaktiviert dargestellt.

🚀 Inkrement 16

GD-244

• Das Validierungsverhalten für manuelle Eingaben wurde ergänzt.
• Werte werden nur durch die aktive Auswahl eines Eintrags aus der Auswahlliste übernommen. Eine automatische Übernahme bei eindeutiger Übereinstimmung mit einem Listeneintrag erfolgt nicht.
• Wird das Feld mit einer Eingabe verlassen, ohne einen Eintrag aus der Auswahlliste auszuwählen, wird die Fehlermeldung „Wählen Sie einen Wert aus der Liste aus.“ angezeigt.

🚀 Inkrement 16

GD-224

• Die Verwendung von An-/Aus-Schaltern und Checkboxen wurde klar abgegrenzt. An-/Aus-Schalter lösen Funktionen unmittelbar aus, Checkboxen wirken erst nach dem Speichern oder Bestätigen der Formulareingaben.

🚀 Inkrement 15

GD-245

• Für Wertebereichsfelder mit einzeiligen Eingabefeldern wurde die Zeichenbegrenzung präzisiert:
• • Eine definierte maximale Zeichenzahl gilt immer für beide Feldteile gleichermaßen.
  • Das Zeichenlimit wird über den Hinweistext kommuniziert und nicht visuell im Feld angezeigt.
• Bei Erreichen der maximalen Zeichenzahl wird keine weitere Eingabe zugelassen.

🚀 Inkrement 15

GD-202

• Das Scrollverhalten wurde abhängig von der Fensterhöhe überarbeitet:
• • Bei größeren Fensterhöhen sind Listen- und Formularbereiche separat scrollbar.
  • Bei kleineren Fensterhöhen wird stattdessen die gesamte Seite scrollbar dargestellt.
• Das Sticky-Verhalten von Seitenelementen wurde angepasst:
• • Bei separaten Scrollbereichen bleiben zentrale Layout-Elemente fixiert.
  • Bei seitenweitem Scrollen bleibt nur die Headerleiste (bzw. Header + Pfadnavigation) fixiert.
• Abhängig von der Fensterhöhe wurden Layoutabstände im Headerbereich angepasst.

🚀 Inkrement 15

GD-8

• Die Sortierung der Trefferliste wurde angepasst:
• • Einträge, die mit der eingegebenen Zeichenfolge beginnen, werden priorisiert angezeigt.
  • Weitere passende Einträge folgen in alphanumerischer Reihenfolge.
  • Fachlich begründete Abweichungen von dieser Sortierung können in User Stories definiert werden.

🚀 Inkrement 15

GD-446

• Der Aufbau des Titels im Verfahrensheader wurde standardisiert.
• Der Titel besteht aus Aktenzeichen und Verfahrensbezeichnung im Format „[Aktenzeichen] – [Verfahrensbezeichnung]“.
• Die Anforderungen an die Verfahrensbezeichnung wurden präzisiert (z. B. Angaben zu Parteien und Streitgegenstand).

🚀 Inkrement 15

GD-453

• Tabellen können innerhalb von Formularen Pflichtangaben enthalten.
• Pflichtfelder in Tabellen werden über die Tabellenüberschrift gekennzeichnet:
• • Die Überschrift erhält ein Pflichtfeld-Sternchen (*).
  • Ein Hinweistext unterhalb der Überschrift beschreibt die erforderliche Eingabe.
• Pflichtangaben in Tabellen werden bei Ausführung der primären Formularaktion validiert.
• Bei fehlenden Eingaben wird ein Fehlerbanner sowie ein kontextbezogener Fehlerhinweis im Tabellenbereich angezeigt.
• Das Pflichtfeld-Sternchen in der Tabellenüberschrift wird von Screenreadern als „Eingabe erforderlich“ ausgegeben.

🚀 Inkrement 15

GD-156

• Wizards können nun auch für andere Aktionen als Neuanlagen verwendet werden.
• Titel- und Button-Benennung wurden flexibilisiert und vereinheitlicht.

🚀 Inkrement 15

GD-49

• Die Standardsortierung für alphanumerische Wertelisten wurde präzisiert.
• Einträge ohne Zeitangaben werden nun gemäß ISO 14651 (Unicode Collation Algorithm) case-insensitive aufsteigend sortiert.

🚀 Inkrement 15

GD-82

• Die Anzeigereihenfolge ausgewählter Werte wird nach dem Speichern und erneutem Öffnen standardmäßig alphanumerisch sortiert.
• Für ENUM-basierte Auswahllisten bleibt eine definierte Reihenfolge erhalten.
• Die Anzeige ausgewählter Werte im Feld wurde angepasst:
• • Bei mehreren oder zu langen Einträgen wird statt der vollständigen Auflistung der Text „[Anzahl] ausgewählt“ angezeigt.
  • Einzelne Einträge werden bei Überschreitung der maximalen Zeichenzahl gekürzt.
• Wenn alle Einträge ausgewählt sind, wird im Feld „Alle ([Anzahl])“ angezeigt.
• Für nicht bearbeitbare (read-only) Felder gilt:
• • Alle ausgewählten Werte werden ausgeschrieben dargestellt.
  • Grafische Elemente (z. B. Icons) werden nicht angezeigt.

🚀 Inkrement 15

GD-156

• Wizards können nun auch für andere Aktionen als Neuanlagen verwendet werden.
• Titel- und Button-Benennung wurden flexibilisiert und vereinheitlicht.

🚀 Inkrement 15

GD-156 & GD-162

• Wizards sind nicht mehr ausschließlich auf Neuanlagen beschränkt, sondern können auch für andere Aktionen verwendet werden.
• Die Anforderungen an die Benennung von Wizard-Titeln wurden flexibilisiert.
• Der Wizard-Titel muss nicht mehr zwingend das Wort „Neuanlage“ enthalten.
• Die Benennung von Aktionen im Wizard wurde vereinheitlicht:
• • Der Abbrechen-Button im Header heißt nun einheitlich „Schließen“.
  • Die Bezeichnung des primären Aktionsbuttons orientiert sich am Verb der im Titel beschriebenen Aktion und ist nicht mehr auf „Anlegen“ festgelegt.

GD-163

• Die Fokussetzung nach dem Wechsel in einen Wizard-Schritt entspricht der definierten Standardfokussetzung des Seitentyps.

🚀 Inkrement 15

GD-247

• Einträge können optional ein Icon in Kombination mit Text enthalten.
• Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgehen.
• Das Icon dient ausschließlich gestalterischen Zwecken und muss als Layoutgrafik deklariert sein.

GD-248

• Einträge können optional einen Avatar in Kombination mit Text enthalten.
• Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgehen.
• Die Grafik dient ausschließlich gestalterischen Zwecken und muss als Layoutgrafik deklariert sein.

🚀 Inkrement 15

GD-247

• Einträge können optional ein Icon in Kombination mit Text enthalten.
• Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgehen.
• Das Icon dient ausschließlich gestalterischen Zwecken und muss als Layoutgrafik deklariert sein.

GD-248

• Einträge können optional einen Avatar in Kombination mit Text enthalten.
• Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgehen.
• Die Grafik dient ausschließlich gestalterischen Zwecken und muss als Layoutgrafik deklariert sein.

🚀 Inkrement 15

GD-247

• Einträge können optional ein Icon in Kombination mit Text enthalten.
• Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgehen.
• Das Icon dient ausschließlich gestalterischen Zwecken und muss als Layoutgrafik deklariert sein.

GD-248

• Einträge können optional einen Avatar in Kombination mit Text enthalten.
• Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgehen.
• Die Grafik dient ausschließlich gestalterischen Zwecken und muss als Layoutgrafik deklariert sein.

🚀 Inkrement 15

GD-525

• Der Text „[Anzahl] Einträge“ muss in Tabellen verpflichtend angezeigt werden.
• Eine optionale Ausblendung ist nicht mehr zulässig.

🚀 Inkrement 15

GD-701

• Die Benennungslogik für modale Dialoge wurde geändert.
• Modale erhalten keine eigene Browsertabbenennung mehr.
• Der Browsertab zeigt weiterhin ausschließlich den Titel der aufrufenden Seite.

ℹ️ Änderung in Bold dargestellt

Infobox

[Der gesamte Inhalt dieser Seite wurde neu veröffentlicht.]

ℹ️ Änderung in Bold dargestellt

Benennung von Browsertabs

[Der gesamte Inhalt dieses Bereichs wurde neu spezifiziert.]

ℹ️ Änderung in Bold dargestellt

Seitenfüllende Fehlermeldungen

Definition Seitenfüllende Fehlermeldungen

Seitenfüllende Fehlermeldungen werden dann angezeigt, wenn die Inhalte einer ganzen Seite in GeFa aus einem der folgenden Gründe nicht angezeigt werden können:

• Fehlende Autorisierung: Anwendungsbeispiel: Nutzende haben einen GeFa-Direktlink im Browser aufgerufen und haben keine Berechtigung zum Aufruf dieser Seite. Dies gilt sowohl für fehlende Tätigkeitsberechtigungen im Backend oder Frontend (werden verwaltet in der BK Benutzerrechteverwaltung) als auch für fehlende Zugriffsberechtigungen (werden über die Zuordnung von Personen zu OE-Besetzungslisten in der GRVW gesetzt).
• Seite existiert nicht. Anwendungsbeispiel: Nutzende haben einen GeFa-Link eingegeben, der nicht bzw. nicht mehr existiert.
• Für den Fall, wenn Anwendende nicht eingeloggt sind, wird keine Seitenfüllende GeFa-Fehlermeldung angezeigt sondern sie werden direkt zur Login-Maske weitergeleitet.
Nach erfolgreichem Anmelden, werden Anwendende direkt auf die initial aufgerufene Seite zurückgeleitet.

Je nach Art des Fehlers können Handlungsanweisungen oder Aktionen angeboten werden (Beispielsweise “Zurück zur Startseite”, wenn Nutzende nicht authorisiert sind oder “Seite neu laden”, wenn ein Serverproblem vorliegt). Bei Meldungstexten sowie Handlungsanweisungen ist zu beachten

• Aus Sicht der Ergonomie & Barrierefreiheit sollte so genau wie möglich der Fehler beschrieben und konkrete Handlungsanweisung zu seiner Behebung gegeben werden.
• Aus Sicht der IT-Sicherheit, sollten keine sicherheitsrelevanten Informationen preisgegeben werden, bspw. keine Anleitung zur Umgehung von Authentifizierungen.

ℹ️ Änderung in Bold dargestellt

Darstellung nicht verfügbarer Funktionalitäten (Ausblenden vs. Disablen)

[Der gesamte Inhalt dieser Seite wurde neu veröffentlicht.]

ℹ️ Änderung in Bold dargestellt

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. 

[Grafik "Standardverhalten" wurde aktualisiert]

[Grafik "Nachträgliche Auswahl eines ungültigen Werts im durchsuchbaren Auswahlfeld" wurde hinzugefügt]

ℹ️ Änderung in Bold dargestellt

(...)

Wird ein Umsystem, bei dem es sich um eine Desktopanwendung handelt, aus GeFa heraus aufgerufen (z. B. über einen entsprechenden Button im GeFa Hauptmenü oder im Verfahrensheader), dann öffnet sich in einem neuen Browsertab eine seitenfüllende Meldung, welche den Nutzer darüber informiert, dass das entsprechende Umsystem gerade aufgerufen wird. Ein Hinweis informiert außerdem darüber, was Nutzer tun können, falls nichts passiert.

Ein Button ermöglicht den erneuten Aufruf des Umsystems. Nach Ausführen dieses Buttons öffnet sich erneut ein neuer Browsertab mit identischem Inhalt und gleichem Verhalten.

Nachdem sich die Desktopanwendung geöffnet hat, kann der Browsertab von Nutzenden manuell wieder geschlossen werden.

Falls es sich beim aufgerufenen Umsystem um eine Browserapplikation handelt, so erscheint diese Seite nicht und statt dessen wird direkt die URL des jeweiligen Systems aufgerufen.

Grundaufbau der Seite, Formulierungsregeln und Inhalte siehe oben bei Seitenfüllende Fehlermeldungen

[Grafik "Seitenfüllende Meldung bei Öffnen von Umsystemen" wurde hinzugefügt]

(...)

ℹ️ Änderung in Bold dargestellt

Verhalten von Formular-Footer (Fußzeile)

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. 

[Grafik „formular_footer_schliessen“]

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.

[Grafik „formular_footer_sicherheitsabfrage“]

ℹ️ Änderung in Bold dargestellt

Um den Schutz personenbezogener Daten zu gewährleisten, müssen Namen von Beteiligten im Browsertitel mit Initialen abgekürzt werden. Die Abkürzung setzt sich aus der abgekürzten Personenart und den Initialen des ersten Nach- und des ersten Vornamens zusammen. Titel, Namensvor- und Namenszusätze werden in der Abkürzung nicht berücksichtigt. Zwischen der abgekürzten Personenart und des Namens befindet sich ein Leerzeichen. 

Natürliche Person wird mit NP abgekürzt. 

Beispiele: 

• Yilmaz, Karim -> NP YM 
• Müller-Lüdenscheidt, Henrik Paul -> NP MH 
• Schmidt, Prof. Maria -> NP SM 
• Graf von Hinckelstein, Dr. Theo -> NP HT 

Namen von juristischen Personen werden ebenfalls im Browsertitel abgekürzt. Die Abkürzung setzt sich aus der abgekürzten Personenart und des ersten Buchstabens der Bezeichnung zusammen. Zwischen der abgekürzten Personenart und der Bezeichnung befindet sich ein Leerzeichen. 

Juristische Person wird mit JP abgekürzt.
Rechtsanwalt/Kanzlei wird mit RA/K abgekürzt. 

Beispiele: 

• Erdmann Betonstein GmbH -> JP E 
• Freshfields Bruckhaus Deringer Rechtsanwälte Steuerberater PartGmB -> RA/K F 
• Freie und Hansestadt Hamburg, vertreten durch die Behörde für.. -> JP F 
• HUK-Coburg Haftpflicht-Unterstützungs-Kasse... -> JP H 

Bei Personen mit dem Status Auskunftssperre, wird nur das Wort “Person” im Browsertitel verwendet.

------

Bei URLs werden keinerlei Umformatierungen vorgenommen. Zu nutzen ist ein normales einzeiliges Eingabefeld und es wird auch bei Verlassen des Feldes die von Nutzern eingegebene Formatierung beibehalten. 

Beispiele:
https://www.[...]
www.[...]

ℹ️ Änderung in Bold dargestellt

Dieser zeigt die eingestellten Parameter. Wenn der Filter neu hinzugefügt wurde und noch kein Parameter gesetzt ist, wird “–” angezeigt. Dies wird ebenfalls angezeigt, wenn der Filter als standardmäßig angezeigte Pille definiert wurde, aber standardmäßig ungefiltert ist.            
Abhängig von Filtertyp und Inhalt des Filter-Containers kann der Inhalt in der Pille in unterschiedlicher Art und Weise dargestellt sein:

Kein Wert

Einfachauswahl bzw. Freitexteingabe:

• Der ausgewählte/eingegebene Eintrag wird in der Filterpille angezeigt.
• Übersteigt die Länge des Eintrags 24 Zeichen, so werden alle Zeichen darüber hinaus mit “...” ersetzt.
• Sind bei Einträgen Kurzbezeichungen vorhanden, so können diese in der Filter-Pille angezeigt werden. Beispiel:
• • Justizbehördentyp: LG (statt “Landgericht”)
• Sind bei einem Eintrag Sub-Spezifikationen vorhanden, so werden diese in Klammern nach dem Haupt-Eintrag angezeigt. Liegen mehrere Sub-Spezifikationen vor, so sind diese mit Kommata voneinander getrennt. Gibt es bei den Sub-Spezifikationen nicht ausgewählte Checkboxen, so tauchen diese nicht in der Filterpille auf.

Unter 24 ZeichenÜber 24 Zeichen

Mehrfachauswahl- bzw. Eingabe:

• Die ausgewählten/eingegebenen Werte werden mit Semikolon voneinander getrennt angezeigt. Die Anzeige-Reihenfolge enspricht der Reihenfolge, in der die Werte in die im Filter-Container eingegebenen Felder eingegeben wurden.
• Bei insgesamt mehr als 24 Zeichen wird dann zusammengefasst in “[Anzahl] ausgewählt”
• Falls alle in dem Mehrfachauswahl-Filter zur Auswahl stehenden Werte gewählt wurden, wird in der Filterpille “Alle” angezeigt. Bei Justizbehörden-Filter ist auch “Alle in [Bundesland]” möglich.

Wertebereiche:

• Wertebereiche werden im Format “[Von] – [Bis]” dargestellt. Dabei wird, falls vorhanden die Einheit jeweils hinter Von und Bis dargestellt. Beispiele:
• • Geburtstag: 15.12.1978 – 01.08.2021
  • Geburtsjahr: 1970 – 1880
  • Stundensatz: 12,00 € – 18,00 €
  • Anzahl Beteiligte: 10 – 15
• Besonderheiten: Wird bei einem Datumsfilter das Tagesdatum ausgewählt, so wird dieses mit dem Wort “Heute” ersetzt. Dies kann auch bei der aktuellen Jahreszahl geschehen. Final ist dies vom jeweiligen Fachteam festzulegen. Beispiele:
• • Termindatum: 01.01.2022 – Heute
  • Jahr: 2015 – Heute
  • Wird entweder der “Von-” oder der “Bis-Wert” in einem Wertebereichts-Filter nicht definiert, so wird eine Suche nach “Größer als” bzw. “Kleiner als” ausführt. In der Filterpille wird dies angezeigt als “Ab [Von-Wert]” bzw. “Bis [Bis-Wert]”. Beispiele:
  • • Jahr: Ab 2015
    • Streitwert: Bis 15.000,00 €
    • Arbeitskraftanteile: Ab 50 %
    • Anzahl Beteiligte: Bis 25
• Nicht zugelassen sind Schreibweisen wie “Größer/kleiner”, “>/<”; “Größer als/Kleiner als“ oder “[Von] – Unbegrenzt”
  

---------------------

Wenn nicht genug Platz zur Verfügung steht, um alle Filter-Bedienelemente im vorgesehenen Rasterlayout darzustellen, werden diese inklusive des “Filter hinzufügen”-Buttons (falls vorhanden) durch ein einziges Bedienelement ersetzt. Dieses besteht aus einem Text, der anzeigt, wieviele Filter aktiv sind (“[X] aktive Filter”) und der gleichen Layoutgrafik wie beim normalen Filter-Bedienelement. Als aktive Filter werden diejenigen gezählt, bei denen ein oder mehrere Filterwerte gesetzt sind, also wo nicht “–” im Filterinhalt steht. 

Ist kein Filter aktiv, so steht nur “Filter” in der Filterpille (statt “[X] aktive Filter”). 
Die zusammengefasste Filterpille erhält den Tooltip “Alle Filter anzeigen”, welcher die Funktion beschreibt (nicht den programmatischen Namen abbildet).

[Grafik "Responsives Verhalten"]

Bei Aktivierung des Elements öffnet sich ein Pop-Up-Menü, welches alle Filter enthält: Sowohl aktive Filter, als auch inaktive Filter inklusive derjenigen, die sich in der nicht-responsiven Darstellung der Filterreihe hinter dem “Filter hinzufügen”-Button verstecken. Die Anzeigereihenfolge ist folgende: 

1. Aktive Filter (Filter bei denen ein oder mehrere Werte ausgewählt wurden); alphabetisch aufsteigend sortiert.
2. Inaktive Filter (Alle, die in der nicht-responsiven Version mit keinem Wert befüllt wurden, wo also “–” zu sehen war und zusätzlich all die, die über den Plus-Button hinzufügbar gewesen wären); alphabetisch aufsteigend sortiert.

Zwischen aktiven und inaktiven Filtern wird eine graue Trennlinie angezeigt und die Bereiche sind im Code als Gruppen mit den Überschriften “Aktive Filter” und “Weitere Filter” ausgezeichnet.

[Grafik "Aktive und Inaktive Filter"]

Jeder Pop-Up-Menü-Eintrag eines aktiven Filters besteht aus dem Filtertyp und dem eingestellten Parameter “[Filtertyp]:[Filterinhalt]” (Bspw: Justizbehörde: AG Freiburg). Bei inaktiven Filtern, wird “–” anstelle des Filterinhalts angezeigt. 
Jeder Eintrag (aktive und inaktive) öffnet den entsprechenden Filter und Nutzende können Einstellungen vornehmen (siehe Filter-Container).

Bei nicht ausreichendem Platz können die Einträge bis 42 Zeichen zweizeilig werden, danach werden die Parameter zusammengefasst zu “[X] Ausgewählt” (Bspw: “Nachname: 3 ausgewählt”).

ℹ️ Änderung in Bold dargestellt

Konzept für Rückgängig machen 

Undo/Redo kann sich auf alle Elemente beziehen, die sich in einem aktuell geöffneten Formular befinden. Rückgängig gemacht werden können dementsprechend: 

• Änderungen in Eingabe- oder Auswahlfeldern (egal ob einzeilig, mehrzeilig, Datumseingabe, Combobox, usw.)
• Änderungen einer Checkbox- oder Radio-Button-Auswahl
• Hinzufügen einer Elementgruppe oder eines weiteren Feldes im Formular
• Entfernen einer Elementgruppe oder eines Feldes im Formular
• Hinzufügen eines Unterobjekts: Dabei ist nur das Hinzufügen des Objekts als ganzes Rückgängig machbar, nicht die enthaltenen Einzelaktionen.
• Bearbeiten von Unterobjekten: Dabei ist nur die Bearbeitung des Objekts als ganzes Rückgängig machbar, nicht die enthaltenen Einzelaktionen.
• Entfernen von Unterobjekten (z. B. über die Tabellenaktionen einer Unterobjektübersicht im Elternformular oder über den Formularheader im Kindformular anschließende Rückkehr ins Elternformular)

Ablauf:

• Der Undo-Button im Formular-Footer wird erst aktiv, wenn eine Änderung im Formular durchgeführt wurde (mind. 1 Zeichen) – bei Eingabefeldern erst bei Verlassen des Feldes. Entsprechend wird bei Eingabefeldern auch nur die komplette Wertänderung im Stack gelistet, nicht jede einzelne Aktion (Zeichen hinzufügen/ändern/entfernen) innerhalb des Feldes.
• Der Redo-Button wird erst aktiv, sobald eine Aktion Rückgängig gemacht wurde.
• Die Anzahl an rückgängig-machbaren Aktionen ist nach oben nicht begrenzt. 
• Die Undo/Redo-Historie wird maximal bis zum Anlegen/Speichern/Schließen des Hauptformulars gespeichert.
• Bei Nutzeraktionen, welche Änderung an mehreren Feldern zur Folge haben, wird nur das auslösende Event als ein Eintrag im Undo- bzw. Redo-Stack gelistet (statt 1 Eintrag pro geändertem Feld und damit einzelner Rückgängigmachbarkeit). Beispiele: 
• • Änderung an Feld A führt zu Zurücksetzen oder Vorbefüllen der Felder B, C & D. Es wird nur die Änderung am Feld A im Undo- bzw. Redo-Stack gelistet.
  • Entfernen einer Gruppe führt zu entfernen aller enthaltener Felder. Es wird nur die Entfernen-Aktion im Undo- bzw. Redo-Stack gelistet.
• Bei Verlassen eines Elternformulars in ein Kindobjekt (egal ob Modales Formular oder Unterseite) wird die Undo/Redo-Historie des gerade verlassenen Elternobjekts gespeichert, ist allerdings erst nach Rückkehr in dieses Elternobjekt wieder abrufbar. 
• Jedes Öffnen eines Kindformulars startet in diesem mit einem leeren Stack und Undo+Redo-Button sind entsprechend deaktiviert, bis Änderungen durchgeführt werden.
• Wird ein Kindformular über  “Schließen”, “Hinzufügen” oder “Übernehmen” verlassen, so wird dessen Undo/Redo-Stack endgültig zurückgesetzt. Anschließend ist der vorherige Stand des Undo/Redo-Stacks im Elternformular wieder verfügbar.
• Wird das Hauptobjekt über “Speichern”, “Anlegen” oder “Schließen” verlassen, so wird dessen Undo/Redo-Stack endgültig zurückgesetzt.

Sonderfall Wizard:

Wird ein Wizardschritt verlassen, unabhängig ob über den Weiter-, Zurück-Button oder die Schrittnavigation, wird der Undo/Redo-Stack des verlassenen Schritts zurückgesetzt. 

Details zur Platzierung der Undo-Redo-Buttons und deren Alternativtexten siehe Formularelement › Footer.

[Grafik „navigation_ge_fa_navigation_detailformular” wurde aktualisiert]

Sicherheitsabfragen

• Wenn Gruppen/Unterobjekte innerhalb eines Formulares gelöscht werden, dann erscheint im Regelfall keine Sicherheitsabfrage, da die Aktion über den Formularfooter rückgängig gemacht werden kann. (Optional kann, wenn fachlich relevant aber eine Sicherheitsabfrage in Userstories definiert werden. In diesem Fall bleibt der Undo-Stack erhalten, egal welche der beiden Optionen gewählt wurde.)
• Wenn ein Kindformular über das Aktionsmenü in dessen Formularheader entfernt wird, dann erscheint keine Sicherheitsabfrage. Die Aktion zum Einen über Undo im Elternformular rückgängig gemacht werden und zum Anderen wird die Änderung erst durch Speichern/Anlegen des Hauptformulars final übernommen.
• Wird das Hinzufügen eines Kindformulars über den Undo-Button im Elternformular rückgängig gemacht, so erscheint im Regelfall keine Sicherheitsabfrage. Falls jedoch die dadurch entfernte Datenmenge sehr groß ist (riesige Kindformulare mit ggf. weiteren Unterformularen), so kann fachlich definiert werden, dass beim Klick auf Undo eine Sicherheitsabfrage erscheint. Beispiel: 
• • Hinzufügen von „[Kindobjekt]” rückgängig machen? – Durch diese Aktion gehen ggf. große Datenmengen verloren. Hinzufügen rückgängig machen?  – Aktionen: Abbrechen / Rückgängig machen
• Bei fachlichen Sicherheitsabfragen bei Feldänderungen (bspw. “Fachbereich ändern? Durch Änderung an diesem Feld werden ggf. bereits hinzugefügte Registerzeichenpräfixe und Entscheidungsorgane entfernt/fehlerhaft.” Aktionen: Abbrechen/Ändern”) bleibt der Undo-Stack des Formulars erhalten, egal welche der beiden Aktionen ausgeführt wird.

Sonderfall Filter & Suchzeile

Änderung von Filter-, Such oder Sortierparametern einer Tabelle/Liste im Formular sollten nicht rückgängig-machbar sein (da dies keine Daten sind, die gespeichert werden und da diese außerdem individuell zurückgesetzt werden können)

[Grafik „navigation_ge_fa_undo_redo_formular_unterobjekten” wurde aktualisiert]

Wechsel zwischen Tabs (Registerkarten)

• Beim Wechsel zwischen Registerkarten erscheint die entsprechende  Standardsicherheitsabfrage (siehe Meldungskonzept: Sicherheitsabfrage - Standard-Meldungen) wenn ungespeicherte Eingaben in einem geöffneten Formular vorliegen.

[Grafik „navigation_ge_fa_registerkarten” wurde aktualisiert]

ℹ️ Änderung in Bold dargestellt

Standardverhalten bei Wertänderungen mit Konsequenzen für Unterformulare

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.

[Grafik „formular_standardverhalten_unterformular” wurde aktualisiert]

ℹ️ Änderung in Bold dargestellt

Von Formularfeldern unabhängige Validierungsfehler

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.

Benennung der Meldungen

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

[Grafik „Unabhängige Validierungsfehler”]

[Grafik „Zusammengesetzte Eingabe existiert bereits”]

[Grafik „Beispiel für fehlerhafte Unterobjekte in einer Formulartabelle” wurde hinzugefügt]

[Grafik „Fehlermeldungsbereich in Formularen (Fehlerbanner)”]

[Grafik „Masse der Fehlermeldungen”]

ℹ️ Änderung in Bold dargestellt

Verhalten von Tabellenzeilen/-inhalten

Eine Tabellen-Zelle kann folgende Elemente enthalten: 

• Checkbox / Radio-Button (interaktiv): Details siehe unten im Abschnitt “Radio Button und Checkbox-Spalten”

[Grafik „Checkbox und Radiobutton”]

• Text

[Grafik „Text”]

• Link (interaktiv) Sonderfall: Inhalte mit fehlenden Zugriffsrechten werden als dunkel grauen Text und nicht als Link dargestellt und es wird zusätzlich ein Icon angehängt, welches auf die fehlenden Zugriffsrechte hinweist. Dieses trägt den Alternativtext “Keine Zugriffsrechte”. Wenn der Eintragstext länger ist, als in der Zelle darstellbar, so wird der Text am Ende mit “...” abgekürzt. Das Symbol führ fehlende Zugriffsrechte wird dabei weiterhin am Zellenende angezeigt, wird aber nicht im Tooltip angezeigt.

[Grafik „Link”]

[Grafik „Keine Rechte”]

• Bei Links die sich separat öffnen, also den aktuellen Browsertab nicht überschreiben, wird eine Pfeil-Grafik auf der rechten Seite des Links hinzugefügt. In diesem Fall trägt der Link die zusätzliche Beschreibung “Öffnet sich im neuen Tab oder Fenster” und die Pfeil-Grafik muss als Layoutgrafik deklariert werden.

[Grafik „Link der sich im neuen Tab öffnet”]

[Grafik „Link der sich im neuen Tab öffnet (mehrzeilig)”]

• Bildmarke/Icon + Text/Link: Kommt eine Grafik gemeinsam mit Text in einer Zelle vor, so ist diese als Layoutgrafik zu deklarieren und die Information muss über den Eintragstext wahrnehmbar sein.

[Grafik „Beispiel Icon mit Link”]

• Grafik: Wird eine Grafik allein in einer Zelle angezeigt, so muss ein Alternativtext hinterlegt werden. Dieser wird bei fokussieren der Zelle bzw. Mouse-Hover auch als Tooltip angezeigt.

[Grafik „Grafik”]

• Numerische Inhalte: Numerische Werte, mit denen statistische und arithmetische Berechnungen möglich sind, werden rechtsbündig und an Kommastellen ausgerichtet. Alle anderen, aus Ziffern bestehenden Werte, wie z.B. Zeitstempel (bestehend aus Datum und Uhrzeit), Raumnummern, durch Semikolon getrennnte Werte o.ä., sind linksbündig ausgerichtet. Siehe Schriften: Textausrichtung.

[Grafik „Numerische Inhalte”]

• Zeitstempel, bestehend aus Datum + Uhrzeit als absolute oder relative Angabe (Detaildefinitionen siehe Schriften: Zeit): Diese werden linksbündig ausgerichtet. Die Spalte für Zeitstempel ist immer fix 200px breit, so dass hier keine Umbrüche entstehen.
• Datum und Uhrzeit-Zeitraum: In Tabellen wo ein Datum und ein Uhrzeit-Zeitraum in einer Zelle dargestellt werden, kommt nach dem Datum immer ein Umbruch. Der Zelleninhalt kann auch als Link dargestellt werden. Format: “[Wochentag in Kurzform], [Datum], [Umbruch] [Zeitraum]”. Beispiel:

[Grafik „Zeitstempel”]

• Badge: Zellen mit Badges kommen meist zur Darstellung von Statusinformationen zum Einsatz - im Regelfall in einer eigenen Tabellenspalte. Falls auf Grund fachlicher Besonderheiten mehr Aufmerksamkeit auf bestimmte einzelne Werte oder Attribute in der Tabelle gezogen werden soll, so können zu diesem Zweck auch in Spalten mit Text, Link oder numerischem Inhalt zusätzliche Badges in den Zellen ergänzt werden (nicht zulässig sind Zusatzbadges in Spalten, wo mehrere mit Semikolon voneinander getrennte Attribute pro Zelle angezeigt werden könnten). Zusatzbadges werden in Zellen immer unter dem eigentlichen Zelleninhalt in einer eigenen Zeile platziert (Ausnahme: Bei Auskunfts- und Verfahrenssperre oberhalb, siehe Tabellenzeilen-Hervorhebung). Der Haupt-Zelleninhalt kann dann nur noch einzeilig dargestellt werden. Die Ausrichtung von Zelleninhalt und Badge richtet sich nach dem Eintragstyp (z. B. Rechtsbündig bei numerischen Inhalten, siehe auch Textausrichtung). Bei Fokuserhalt einer solchen Zelle wird der Badge-Text oder Alternativtext nach dem Eintragstext vorgelesen (Ausnahme: Verfahrens- oder Auskunftssperre). Ist der Text in der Inhaltszeile länger als im verfügbaren Platz darstellbar, so wird er am Ende der Zeile mit “...” abgekürzt - der Badge in der Zeile darunter (bzw. in oben beschriebenen Ausnahmefällen darüber) bleibt weiterhin sichtbar. Details siehe unten “Verhalten bei langem Zellen-Inhalt.”

[Grafik „Badge”]

[Grafik „Badge Auskunftssperre”]

[Grafik „Badge + Attribut”]

• Markierung für fehlerhafte Einträge: Diese kann in normalen Textzellen oder Textzellen mit vorangestelltem Icon/Personensymbol an den Text angehängt werden (nicht bei Links). Die Markierung dient dazu, in Formulartabellen fehlerhafte Unterobjekte grafisch hervorzuheben. Dabei wird das Icon immer nur am Rowheader ergänzt – es kann also nicht mehrmals pro Zeile vorkommen. Der Alternativtext des Symbols, welcher bei Fokuserhalt der Zelle vom Screenreader nach dem Eintragstext ausgelesen wird lautet “– Fehlerhaft”.

[Grafik „Markierung für fehlerhafte Einträge” wurde hinzugefügt]

• Aktionsbuttons (interaktiv): Diese befinden sich in der Regel in der letzten Tabellenspalte. Es können bis zu 2 Buttons nebeneinander dargestellt werden. Sind mehr als zwei Aktionen zu einer Zeile verfügbar, so werden diese zu einem “Weitere Aktionen”-Button zusammengefasst. Der Button öffnet ein Pop-Up-Menü, von dem aus die Einzelaktionen aufrufbar sind. Die programmatische Beschriftung des Buttons lautet “Weitere Aktionen zu [Inhalt Spate 1]”. Der Tooltip des Buttons lautet nur “Weitere Aktionen”. Wenn eine Tabellenzeile über einen Aktionen-Button gelöscht wird, dann liegt der Tastaturfokus anschließend auf der ersten Zelle der nächsten Zeile. Falls es sich bei der gelöschten Zeile um die letzte gehandelt hat, dann liegt der Fokus auf der ersten Zelle der vorherigen Zeile.

[Grafik „Eine Aktion”]

[Grafik „Zwei Aktionen”]

[Grafik „Weitere Aktionen”]

• Info-Button in Spalte “Details”: Dieser Button kann in einer Tabellenspalte verwendet werden, um zusätzliche Informationen in einem Info-Modal anzeigen zu lassen. Die programmatische Beschriftung des Buttons lautet “Weitere Informationen”. Der Tooltip des Buttons lautet nur “Weitere Informationen”. (Detailbeschreibung siehe Infobox).

[Grafik „Info-Button in spalte Details” wurde hinzugefügt]

[Grafik „Beispiele Tabelleninhalt”]

[Grafik „Darstellung von Zeilen mit Datum + Uhrzeit-Zeitreaum”]

Es ist darauf zu achten, dass die Gesamtzahl an interaktiven Elementen innerhalb einer Zeile nicht zu hoch wird (im Idealfall maximal 3). Die interaktiven Elemente verhalten sich entsprechend ihrer Standarddefinition. 

Die Zellengröße ist abhängig vom dargestellten Inhalt. Bspw. gibt es Inhalt, der mit einer festen Breite definiert ist (Aktionen, Datum, etc...) und Inhalt, der sich prozentual an die Tabellenbreite anpasst (Namen, Textinhalte, etc...). Wie genau sich eine Zelle verhält muss fachlich definiert werden.

Verhalten bei Tabellen mit fehlerhaften Unterelementen

Bei Tabellen in Formularen können Tabelleneinträge als fehlerhaft markiert sein. 
Die Markierung taucht auf, sobald bei Validierungen im Hauptformular Fehler in Unterobjekten festgestellt werden. Dabei wird das Icon immer nur am Rowheader ergänzt – es kann also nicht mehrmals pro Zeile vorkommen. (Details zur Markierung siehe oben Verhalten von Tabellenzeilen/-inhalten)

Zusätzlich wird über der Tabelle eine formularfeldunabhängige Validierungsfehlermeldung pro in der Tabelle enthaltenem fehlerhaftem Objekt angezeigt. 
(siehe Globale Meldungsregeln: Formular-Validierungsfehler)

[Grafik „Tabelle vor Validierung Keine fehlerhaften Unterobjekte” wurde Hinnzugefügt]

[Grafik „Tabelle nach Validierung mit fehlerhaften Unterobjekten” wurde Hinnzugefügt]

ℹ️ Änderung in Bold dargestellt

Dropdowns

Jeder Eintrag der Ausklappiste kann bestehen aus: 

• Text: Einzelwert bzw. Einzelbegriff (Beispiel Sprachauswahl: Deutsch/Englisch...)
• Icon mit Text: Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.
• Avatar mit Text: Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.
• Primär- und Sekundärtext (Beispiel Raumauswahl: Angezeigt wird die Bezeichnung des Raumes in Zeile 1; Die Gebäudeart und Straße in Zeile 2 – ”Raum 2.01; Hauptgebäude, Berliner Straße 4a”)
• Primär- und Sekundärtext mit zusätzlicher Bildmarke (Beispiel: Personenauswahl: Avatar bzw. Foto einer Person, daneben Nachname und Vorname in erster Zeile, Amts-/Dienstbezeichnung in zweiter Zeile). Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.

[Grafik „Typen von Einträgen”]

Es können auch deaktivierte (disabled) Elemente im Dropdown angezeigt werden. Diese können auch fokussiert werden. Vom Screenreader werden sie als deaktivierte Elemente ausgegeben.

Wichtig ist: Es muss für die Nutzenden fachlich einen Mehrwert bieten, dass die Einträge noch in deaktivierter Form als Teil der Ausklappliste angezeigt werden und es muss aus dem Maskenkontext klar hervorgehen, warum die Einträge deaktiviert sind. Kann dies nicht garantiert werden, so sollten die entsprechenden Werte in der Ausklappliste ganz ausgeblendet statt nur deaktiviert werden. 

Dropdowns öffnen sich immer nach unten. Die Höhe des sich öffnenden Dropdown-Elements orientiert sich an der Menge der Einträge innerhalb und am verfügbaren Platz auf der Seite. Bei wenig Einträgen ist auch das Dropdown-Element weniger hoch. Falls mehr Einträge vorhanden sind, als sie in der verfügbaren Fensterhöhe darstellbar sind, wird der Inhalt scrollbar. Es bleibt ein Padding von mindestens 16 px zum unteren Fensterrand bestehen.

[Grafik „Wenig Einträge”]

[Grafik „Mit Scroll”]

Öffnen Nutzende ein durchsuchbares Einfachauswahlfeld und fangen an, Text einzugeben, so werden Suchergebnisse angezeigt. Der Systemfokus liegt auch bei geöffneter Ausklappliste im Eingabefeld. Der blinkende Cursor wird angezeigt (falls bereits eine Auswahl vorhanden war, befindet er sich hinter dem letzten Zeichen).

• Ist in der Liste bereits ein Wert ausgewählt (nicht leer oder default), dann wird nach Öffnen der Liste nur dieser gewählte Eintrag in der Ausklappliste angezeigt und ist visuell als ausgewählt angezeigt. Er wird außerdem vom Screenreader ausgegeben.
• Ist in dem Element kein Eintrag bzw. der Default-Eintrag ausgewählt, dann werden beim Öffnen der Liste alle Einträge angezeigt und der Default-Eintrag “–“ wird visuell als ausgewählt angezeigt.

[Grafik „Ausgewählter Eintrag”]

[Grafik „Kein Eintrag”]

Fangen Nutzende, bei geöffneter Ausklappliste, an zu tippen, so wird der Inhalt des Auswahlfeldes auf diesen Wert hin gefiltert. Auswahlwerte, die den eingegebenen Wert nicht enthalten, werden ausgeblendet und die Liste wird bei wachsender Zeichenzahl entsprechend kürzer. Der gefundene Suchbegriff wird in der Ergebnisliste mit blauer Hinterlegung markiert (bei selektierten Einträgen invertiert). Zwischen jeder Wertänderungen und der entsprechenden Aktualisierung der Trefferliste besteht eine Verzögerung von 400ms. So haben Nutzende die Möglichkeit, Ihre Eingabe zunächst zu beenden (statt Ausführen der Aktion bei jedem Tastendruck). Dabei werden nur die als Listeneinträge hinterlegten Texte als gültige Werte akzeptiert.

Wird kein Ergebnis gefunden, so wird den Nutzenden der Text “Kein Treffer für [Suchbegriff] gefunden” angezeigt.

Falls die Serverabfrage für die Suche länger dauert (über 200ms), wird ein Ladezustand (loading spinner) im Dropdown angezeigt, bis Suchergebnisse vorhanden sind. Dieser ist nicht fokussierbar. Der Alternativtext des Symbols, der vom Screenreader automatisch ausgegeben wird, sobald er erscheint lautet “Einträge werden geladen”. Dieser wird auch als Tooltip angezeigt, wenn mit der Maus exakt über dem Lade-Icon gehovert wird. Falls das Laden länger dauert und das Auswahlfeld weiterhin fokussiert ist, wird alle 10 Sekunden erneut der Alternativtext des Ladesymbols “Ergebnisse werden geladen” ausgelesen.

Noch offen: Verhalten bei ausbleibender Server-Antwort (Hier ist vorher die technische Umsetzung zu klären)

Sobald Ergebnisse gefunden oder aktualisiert wurden, wird vom Screenreader die Anzahl der gefundenen Einträge automatisch ausgeben. Text: “[Anzahl] Treffer gefunden”.

Verhalten der Ausklappliste bei über 100 gefundenen Treffern (siehe Eingabe und Auswahlfelder).

[Grafik „Ergebnisse Laden”]

[Grafik „Keine Ergebnisse”]

[Grafik „Über 100 Treffer”]

Durchsucht werden kann bei Dropdownseinträgen mit Primär- und Sekundärtext immer nur der Primärtext (In den Beispielen: “Raum 2.04” und “Nachname, Vorname”). Basierend auf fachlicher Anforderung sollte definiert werden, ob eine der folgenden Suchverhalten gilt:

• “Beinhaltet [...]” – Sucht nach Zeichenabfolgen, die irgendwo innerhalb der Bezeichnung vorkommen.
• “Startet mit [...]” – Sucht nur nach Zeichenabfolgen die am Anfang der Bezeichnung stehen. 

Falls nicht definiert gilt die Regel “Beinhaltet [Suchbegriff]”. 

Alle für Suchfelder in GeFa definierten Wildcards können auch in Comboboxen genutzt werden (siehe Suchfeld: Wildcards).

Besteht der Inhalt eines Dropdown-Eintrags aus langem Text, so bricht dieser um, sobald er nicht mehr in einer Zeile darstellbar ist. Eine Abkürzung von Inhalten (z. B. mit “...”) darf nicht stattfinden, damit kein Inhalt versteckt wird.

Nach Auswahl eines Eintrags, wird bei Einträgen mit Primär- und Sekundärtext standardmäßig nur der Primärtext im Feld dargestellt.

ℹ️ Änderung in Bold dargestellt

Detailablauf im Wizard

1. Wird in einem Arbeitsschritt auf “Weiter” geklickt oder wird der Arbeitsschritt durch Auswahl eines aktiven (da vorher bereits besuchten) Folgeschritts über die Schrittübersicht verlassen, so werden Frontend- und ggf. Cross-Validierungen für diesen Wizardschritt durchgeführt. Die Fehler können auch schon vorher direkt am fehlerhaft befüllten Feld erscheinen (siehe Formular: Validierungsfehlern an Formularfeldern). Liegen Frontend-/Cross-Validierungsfehler in dem Schritt, der gerade verlassen werden soll, vor, so erscheint bei Klick auf “Weiter” bzw. einen aktiven Folgeschritt in der Schrittnavigation ein Fehlerbanner, welches alle Fehler im aktiven Schritt listet. Nutzende müssen diese zunächst beheben, bevor zum nächsten Arbeitsschritt gewechselt werden kann. Möglicherweise aktive Folgeseiten in der Schrittübersicht werden deaktiviert (im Moment, wenn auf “Weiter” oder einen Folgeschritt in der Schrittübersicht geklickt wird) und sind erst wieder aufrufbar, wenn alle Frontend-/Crossvalidierungsfehler auf der Seite behoben wurden. Die in Folgeschritten ggf. bereits eingegebenen Daten werden allerdings auch bei deaktivieren der Schritte weiterhin vorgehalten. Gleichzeitig mit Erscheinen des Fehlerbanners wird der aktive Schritt in der Schrittübersicht als fehlerhaft markiert (siehe oben Verhalten Wizard Schrittübersicht). Wird erneut auf “Weiter” bzw. den aktiven Folgeschritt in der Schrittnavigation geklickt und es wurden vorher alle Fehler auf der Seite behoben, so verschwindet die Markierung als fehlerhaft wieder aus der Schrittübersicht und möglicherweise vorher bereits aktiv gewesene Folgeschritte werden wieder klickbar und enthalten dann wieder die vorher bereits befüllten Eingaben.
2. Ein Formular mit Frontend-/Crossvalidierungsfehlern kann über Zurück bzw. Klick auf einen vorherigen Schritt in der Schrittübersicht verlassen werden. Falls zu diesem Zeitpunkt bereits Folgeschritte besucht wurden und aktiv sind, so erscheint bei Verlassen die entsprechende Standardsicherheitsabfrage (siehe Meldungskonzept: Sicherheitsabfrage - Standard-Meldungen). Nach Bestätigen der Sicherheitsabfrage wird der Schritt verlassen und die bereits aktiv gewesenen Folgeschritte des verlassenen Schritts in der Schrittnavigation werden deaktiviert. Die darin bereits eingegebenen Daten werden allerdings weiterhin vorgehalten. Erst nach Verlassen des fehlerhaften Schritts vorwärts (über “Weiter”) und wenn die Frontend-/Crossvalidierungsfehler behoben wurden, können Folgeschritte wieder aktiv werden und enthalten dann wieder die vorher bereits befüllten Eingaben. Wurde die fehlerhafte Seite rückwärts (zu vorherigem Schritt) verlassen und Nutzer kehren anschließend wieder auf die Seite zurück, so sind die fehlerhaften Eingaben, die vor oder bei Verlassen der Seite bereits validiert wurden, sichtbar (Fehlermarkierungen an Formularelementen und ggf. zusätzlich das Meldungsbanner, falls bereits vorher versucht wurde, den Schritt in Vorwärts-Richtung zu verlassen). Erst nach Beheben aller Frontend-/Crossvalidierungsfehler in diesem Schritt, kann wieder vorwärts navigiert werden (über Weiter oder Schrittübersicht). Wird ein Formular ohne Frontend-/Crossvalidierungsfehlerrückwärts über “Zurück” oder die Schrittübersicht verlassen, so führt dies nicht zu einem deaktivieren der ggf. bereits aktiven Folgeschritte in der Schrittnavigation.
3. Wird am Ende auf der Zusammenfassungs- bzw. letzten Wizardseite die Primäraktion im Footer (bspw. “Anlegen”) ausgeführt, so werden nun Backend-Validierungen für die in allen Schritten des Wizards getätigten Eingaben durchgeführt. Alle gefundenen Fehler werden in einem Fehlerbanner auf der Zusammenfassungs- bzw. letzten Wizardseite aufgelistet. Gleichzeitig mit Erscheinen des Banners werden die Schritte, in denen die fehlerhaften Eingaben identifiziert wurden, in der Schrittübersicht mit dem Fehlersymbol markiert (Markierung siehe oben Verhalten Wizard Schrittübersicht). Die Zusammenfassungsseite des Wizards, welche ausschließlich nicht bearbeitbare Anzeigefelder enthalten kann, wird dabei nie als fehlerhaft markiert, sondern nur Seiten, auf denen die Fehler auch behoben werden können. Falls es sich um einen Wizard ohne Zusammenfassungsseite handelt, und die letzte Seite editierbare Felder enthält, so kann es hier auch zu einer Fehlermarkierung in der Schrittübersicht kommen. Dem Fehlertext im Banner der Zusammenfassungs- bzw. letzten Wizardseite wird immer die Schrittnummer und -bezeichnung, in dem sich das fehlerhafte Element befindet, vorangestellt. Es gibt nun drei Möglichkeiten, wie für die Fehlerbehebung zu den fehlerhaften Feldern zu navigiert werden kann:
4. 1. Jeder einzelne Fehler im Banner ist klickbar. Es öffnet sich dadurch der entsprechende Prozessschritt (im gleichen Browsertab) und der Tastaturfokus wird auf das fehlerhafte Element bzw. bei Formularfeldunabhängigen Fehlern auf dem Fehlertext gelegt.
   2. Über die Schrittübersicht kann ebenfalls manuell zu der entsprechenden Stelle navigiert werden (Details siehe oben Verhalten Wizard Schrittübersicht)
   3. Auch die manuelle Rücknavigation Schritt für Schritt über den “Zurück”-Button im Footer ist möglich.
4. Im angesprungenen Schritt sind erneut die Backend-Fehler im Fehlerbanner aufgelistet, welche diesen einen Prozessschritt betreffen. Sobald eine Änderung an einem betroffenen Feld erfolgt ist und die Wertübernahme stattgefunden hat (Zeitpunkt Wertübernahme pro Feldtyp siehe Formular: Validierungsfehlern an Formularfeldern) wird der entsprechende Eintrag im Fehlerbanner des Schritts als deaktiviert dargestellt (auch wenn die erneute Backendprüfung erst wieder auf der Zusammenfassungs- bzw. letzten Wizardseite geschieht). Entsteht durch die Korrektur ein neuer Frontendfehler, so wird dieser zum Zeitpunkt der Wertübernahme am Element angezeigt. Im Meldungsbanner werden die neu hinzugekommenen Frontend-/Crossvalidierungsfehler erst nach erneutem Klick auf “Weiter” bzw. Klick auf einen Folgeschritt in der Schrittübersicht mit gelistet. Neu hinzugekommene Frontend-/Crossvalidierungsfehler werden dann zusätzlich zu den ggf. bereits deaktivierten Backendfehlern des Schritts im Banner angezeigt. Dabei entspricht die Reihenfolge der gelisteten Fehler der Formularreihenfolge der betroffenen Felder (siehe Formular: 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-/Crossvalidierungsfehler auf der Wizardseite behoben werden müssen, bevor zur nächsten Seite gewechselt werden kann. Auch die Folgeseiten in der Schrittübersicht werden in dieser Zeit deaktiviert und sind erst wieder aufrufbar, wenn alle Frontend-/Crossvalidierungsfehler behoben wurden. Noch offene Backend-Fehler führen nicht zu einer temporären Sperrung der Weiter-Navigation bzw. zu Deaktivierung nächster Schritte in der Schrittübersicht, verhindern also nicht, dass ein Schritt verlassen werden kann.
5. Wurden alle Frontend-/Crossvalidierungsfehler in einem Wizardschritt behoben und alle Elemente mit Backend-Fehlern bearbeitet und Nutzende verlassen den Schritt mit Klick auf “Weiter” oder durch Klick auf einen der wieder aktivierten Folgeschritte in der Schrittnavigation, so wird die Fehlermarkierung des verlassenen Schritts in der Schrittnavigation entfernt. Wären noch Backendfehler unbearbeitet, so bliebe die Markierung nach Verlassen des Schritts erhalten. Wird ein Schritt, in dem alle Fehler behoben und entsprechende Einträge im Fehlerbanner deaktiviert wurden, rückwärts über die Schrittübersicht verlassen und bei Verlassen werden keine neuen Fehler festgestellt, so wird bei Verlassen auch die Fehlerhaft-Markierung in der Schrittübersicht entfernt.
6. Kehren Nutzer mit Klick auf “Weiter” oder über die Schrittnavigation auf die Zusammenfassungs- bzw. letzte Wizardseite zurück, dann werden dort alle bereits bearbeiteten Backend-Fehlereinträge im Banner deaktiviert dargestellt. Noch unbearbeitete Fehlereinträge sind im Fehlerbanner weiterhin aktiv und klickbar.
7. Wird erneut die Abschlussaktion (z. B. “Anlegen”) auf der Zusammenfassungs- bzw. letzten Wizardseite ausgeführt, so findet erneut eine Validierung über alle Prozessschritte statt und das oben beschriebene Verhalten (ab Punkt 2) wiederholt sich gegebenenfalls.

Benennung der Meldungen

Der Titel des Fehlerbanners lautet:

• Auf der Zusammenfassungs- bzw. letzten Wizardseite: “[Bezeichnung primärer Button] nicht möglich”
• Auf alleren vorherigen Schritten des des Wizards “Fehlerhafte Eingaben”

Der Buttontext in der Fehlerliste darunter auf der Zusammenfassungs- bzw. letzten Wizardseite setzt sich zusammen aus:

• “[Schrittnummer]. [Arbeitsschritt] –”
• Dem für das fehlerhafte Element definierten Zusatz (siehe Formular: Fehlerbanner Schema Benennung)

Beispiel: Ein fehlerhaftes einzeiliges Eingabefeld “Bezeichnung” im ersten Wizard-Schritt wird folgendermaßen beschrieben:
“1. Grunddaten – Bezeichnung: Objekt mit gleicher Bezeichnung im gleichen Gültigkeitszeitraum existiert bereits”

[Grafik „Backend-Validierungen”]

ℹ️ Änderung in Bold dargestellt

Verhalten

Modaldialoge stellen sicher, dass die gewünschte Aktion an erster Stelle von Nutzenden bearbeitet wird. Ein gleichzeitiges Ausführen anderer Aktionen ist nicht möglich. Der Hinweis erscheint zentriert in der Fenstermitte. Der Hintergrund wird durch eine halbtransparente Fläche abgedunkelt. Elemente im Hintergrund sind dann nicht mehr mit der Tastatur erreichbar und sind auch mit der Maus nicht mehr bedienbar.

Gleichzeitig mit Erscheinen der Meldungen ertönt je nach Meldungstyp ein akustisches Signal (siehe Akustische Signale). 

Modaldialoge enthalten jeweils: 

• Meldungstext 1: Eine Überschrift mit Kurzbeschreibung der Meldung (visuell H3; im Code als H2 gekennzeichnet)
• Meldunstext 2: Eine bei Bedarf mehrzeilige Detailbeschreibung, die Nutzende über den Grund des Modals und mögliche Konsequenzen (bei Sicherheitsabfragen) bzw. Schritte zur Behebung des Fehlers (bei Fehlermeldungen) informiert. Diese Detailbeschreibung kann Fließtext oder eine Mischung aus Fließtext und Aufzählungen enthalten. Optional können zum Beschreibungstext weiterführende Links ergänzt werden. Abweichend zum Standardverhalten von Links (Öffnen im gleichen Browsertab), müssen sich Links aus Meldungstexten immer in einem separaten Browsertab öffnen, damit der Kontext der Meldung bestehen bleibt und ggf. noch weitere Links im Inhalt der Meldung geöffnet werden können.
• Einen Dialog-Footer (Fußzeile). Dieser enthält mindestens einen primären Aktionsbutton. Bei Bedarf können zusätzliche sekundäre oder tertiäre Buttons erscheinen.

Details zur Formulierung der Meldungstexte für Sicherheitsabfragen und Fehlermeldungen (Modaldialog) siehe Meldungskonzept.

Modaldialoge sind technisch als solche ausgezeichnet. Sie enthalten keine zusätzlichen Regionsauszeichnungen für Header, Footer & Inhaltsbereich.

Abhängig von der Kategorie des Fehlers ist die Hintergrundfarbe des Modals und die Hintergrundabdunklung unterschiedlich gefärbt:

• Sicherheitsabfragen und andere Hinweise = Nachtblau
• Fehler und kritische Systemnachrichten = Rot

Bei “Roten Meldungen” wird zusätzlich ein Ausrufezeichen-Icon in der rechten oberen Ecke angezeigt, um auf die Wichtigkeit hinzuweisen. Die Grafik ist als Layoutgrafik zu deklarieren.

Details zur Formulierung der Meldungstexte für Sicherheitsabfragen und Fehlermeldungen sind im Meldungskonzept zu finden.

[Grafik „Modaldialoge” wurde aktualisiert]

Modaldialog Fehlermeldung

Fehlermeldungen könenn aus unterschiedlichen Gründen ausgelöst werden, die entweder mit den Anwendern oder dem System zusammenhängen.

Für die folgenden Fälle sind die Meldungsinhalte (siehe Meldungskonzept: Fehlermeldungen (Modaldialog) - Standard-Fehlermeldungen) definiert:

• Optimistic Locking: Bearbeiten zwei Personen dasselbe Formular, so werden die Änderungen der Person übernommen, die zuerst speichert.
• Ein Objekt wird von einem anderen Anwender, oder demselben Anwender in einem neuen Tab gelöscht, bevor Änderungen übernommen wurden.
• Versuch des Öffnens eines bereits gelöschten Datensatzes.
• Der Server reagiert nicht.
• Das Umsystem ist nicht erreichbar.

Nutzende müssen das Modal schließen (in der Regel über den primären Button), um fortfahren zu können. In Ausnahmefällen können auch bei diesem Fehlertyp mehrere Aktionen (primär/sekundär) zur Auswahl stehen. Eine gleichzeitige Bearbeitung der im Hintergrund liegenden Seite ist nicht möglich.

[Grafik „Technische Fehlermeldung” wurde aktualisiert]

[Grafik „Fehlermeldung bei optimistic Locking” wurde aktualisiert]

[Grafik „Fehlermeldung bei bereits gelöschtem Objekt” wurde aktualisiert]

[Grafik „Fehlermeldung bei bereits gelöschter Person” wurde aktualisiert]

[Grafik „Fehlermeldung bei Serverfehler” wurde aktualisiert]

[Grafik „Fehlermeldung bei nicht Erreichung des Umsystems” wurde aktualisiert]

ℹ️ Änderung in Bold dargestellt

Übergreifende Validierungen zwischen Haupt- und Unterformularen

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. 

Ablauf

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.

Benennung der Meldungen

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”

[Grafik „Cross-Validierung von Gültigkeitszeiträumen” wurde aktualisiert]

ℹ️ Änderung in Bold dargestellt

Fehlerbanner Schema Benennung

Titel Fehlerbanner

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)

1x Tertiärer Button Pro Fehlerhaftem Feld

• 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]”

Validierungsfehler-Text:

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”

[Grafik „Validierungsfehler bei Formularfeldgruppen”]

ℹ️ Änderung in Bold dargestellt

Meldungstext 2 Seitenfüllende Fehlermeldungen

• Eine mehrzeilige Detailbeschreibung des Fehlers. Diese beschreibt in Fließtext den festgestellten Fehler (Ursache) und was der Nutzer tun kann, um den Fehler zu beheben (soweit mit Datenschutzvorgaben vereinbar)
• Eine Request ID. Diese wird in folgendem Format an den Fehlertext angehängt:„[Detailbeschreibung Fehler] [Umbruch] (Request ID: [ID])“

Primäre Aktion (Optional) Seitenfüllende Fehlermeldungen

• Aktionsbutton: Beschreibt in max. 2-3 Wörtern die Aktion, die bevorzugt von Nutzenden auszuführen ist. Auf seitenfüllenden Fehlermeldungen wird maximal nur ein Aktionsbutton angezeigt.
  
  Details zu Verhalten und Bedienung, siehe Komponente seitenfüllende Fehlermeldung.

[Grafik „Beispiel für eine seitenfüllende Fehlermeldung” wurde aktualisiert]

Definition Fehlermeldungen (Modaldialog)

Dialoge vom Typ Fehler erscheinen entweder direkt anschließend auf eine Nutzeraktion, die z. B. auf Grund eines Fehlers nicht ordnungsgemäß ausgeführt werden kann oder auch unabhängig von einer Nutzeraktion, wenn es wichtig ist, dass der Nutzer die Meldung sofort wahrnimmt.

Dabei kann es sich um technische Fehler (z. B. Server nicht erreichbar) oder fachliche Fehler (z. B. Weglegen eines Verfahrens aufgrund noch nicht erledigter Unterobjekte nicht möglich) handeln.

Falls technisch möglich, muss der Meldungstext bei technischen Fehlern eine Request ID (muss nicht von Fachteams definiert werden) enthalten (Ausnahme kann z. B. reine Frontend-Kommunikation zwischen GeFa und Umsystem in der Rahmenanwendung und Kontexthandler sein), um eine eindeutige Identifizierung des Fehlers zu gewährleisten.

Fehlermeldungen könenn aus unterschiedlichen Gründen ausgelöst werden, die entweder mit den Anwendern oder dem System zusammenhängen. Für die folgenden Fälle sind die Meldungsinhalte (s. Standard-Fehlermeldungen unten) definiert:

• Optimistic Locking: Bearbeiten zwei Personen dasselbe Formular, so werden die Änderungen der Person übernommen, die zuerst speichert.
• Ein Objekt wird von einem anderen Anwender, oder demselben Anwender in einem neuen Tab gelöscht, bevor Änderungen übernommen wurden.
• Versuch des Öffnens eines bereits gelöschten Datensatzes.
• Der Server reagiert nicht.
• Das Umsystem ist nicht erreichbar.

Weitere Fälle können fachlich definiert werden. Für diese anderen Fälle gelten die unten genannten Formulierungsregeln.

[Grafik „Beispiel Fehlermeldung” wurde aktualisiert]

Meldungstext 2 Fehlermeldungen (Modaldialog)

• Erklärt den Grund des Modals und mögliche Schritte zur Behebung des Fehlers.
• Im Idealfall max. 1-2 Sätze, falls nötig auch Aufzählung möglich.
• Aufzählungen muss ein einleitender Text vorangestellt werden, der den Grund des Modals erläutert.
• Weiterführende Links können optional ergänzt werden, wenn beispielsweise zum Beheben des Fehlers das Bearbeiten anderer Objekte (z. B. Verfahren) in GeFa erforderlich ist. Der Link sollte immer nach dem dazugehörigen Beschreibungstext platziert sein. Wenn eine Meldung also zwei Links enthält, sollte das Muster “Text 1, Link 1, Text 2, Link 2” gelten. Links ohne Beschreibungstext sind nicht zulässig.
• Bei technischen Fehlern, wenn möglich, eine Request ID im Format: „[Detailbeschreibung Fehler] [Umbruch] (Request ID: [ID]“) angehängt.

Standard-Fehlermeldungen

ℹ️ Änderung in Bold dargestellt

Verhalten Such- und Filterergebnisanzeige bei Baumstrukturen

Über Suche (siehe Suchfeld) und Filter (siehe Filter) können die Inhalte von Baumstrukturen reduziert werden, so dass Nutzende schnell den gewünschten Eintrag finden (siehe auch allgemeine Definitionen zu Such- & Filterlogik)

Die Summe aller gesetzten Filter und Suchbegriffe definiert die Ergebnismenge in der Baumstruktur und der Text “[Anzahl] Einträge” wird nach jeder Änderung entsprechend aktualisiert.

Vom jeweiligen Modul ist zu definieren, welche Attribute durchsucht werden können (siehe Suchen & Filtern).  Im Modul Beteiligtenverwaltung wird in der Regel nur die primäre Information (Name) durchsucht. Im Modul Gerichtsverwaltung können primäre- und sekundäre Information (Stellenbezeichnung, Ebenenbezeichnung, Stellen-Nr.) durchsucht werden.

[Grafik „Suche und Filter im Listenbaum” wurde hinzugefügt]

Fangen Nutzende bei fokussiertem Suchfeld an, zu tippen so wird der Inhalt der Baumstruktur auf den Wert hin gefiltert. Baumelemente die den eingegebenen Wert nicht enthalten, werden ausgeblendet und die Liste wird bei wachsender Zeichenzahl entsprechend kürzer. 
Objektbeziehungen zwischen den noch übrig gebliebenen Elementen werden, falls vorhanden, weiterhin dargestellt. Alle Einträge werden als aufgeklappt dargestellt. Der Auf-/Zuklappen-Button von Elternobjekten wird ausgeblendet, wenn keines der Kindelemente mit dem Suchbegriff übereinstimmen. Entsprechend wird der Zustand “Aufgeklappt/Zuklappt” nicht von Screenreadern ausgegeben. 

Der gefundene Suchbegriff wird in der Ergebnisliste mit blauer Hinterlegung markiert (bei selektierten Einträgen invertiert). Zwischen jeder Wertänderungen und der entsprechenden Aktualisierung der Trefferliste besteht eine Verzögerung 400ms. So haben Nutzende die Möglichkeit, Ihre Eingabe zunächst zu beenden (statt Ausführen der Aktion bei jedem Tastendruck). Details zur Suchlogik und Markierungen in der Baumstruktur, siehe Komponent “Suchfeld”.

[Grafik „Gefundener Suchbegriff” wurde hinzugefügt]

Enthält eine Baumstruktur Unterkategorie-Trennblöcke, so bleiben diese immer stehen, auch wenn keine enthaltenen Einträge den Suchbegriff beinhalten. Es wird dann im Trennblock der Leerzustand mit dem Text “Kein Treffer für diese Such- und Filterkriterien gefunden.” angezeigt und im Trennblock-Titel wird “0 Einträge” angezeigt. Dieser ist fokussierbar (Zustände und Tastaturbedienung siehe unten Verhalten Leerzustand). Vom Screenreader wird das Leer-Element als deaktiviertes Baumelement ausgegeben.

Das identische Verhalten gilt, wenn die Inhalte eines Filtercontainers geändert werden und die Aktion “Anwenden” ausgeführt wird.

[Grafik „Mit Unterkategorie-Trennblöcken” wurde hinzugefügt]

[Grafik „Nach der Suche” wurde hinzugefügt]

Falls die Serverabfrage für die Aktualisierung der Trefferliste nach Eingabe eines Suchbegriffes oder Ändern/Löschen/Hinzufügen eines Filters länger dauert (über 2 Sekunden), wird ein Ladezustand (loading spinner) an Stelle der Baumstruktur angezeigt, bis Suchergebnisse vorhanden sind. Der Alternativtext des Symbols, der vom Screenreader ausgegeben wird lautet “Ergebnisse werden geladen”. Das Ladesymbol wird vom Screenreader automatisch ausgegeben, ohne dass der Systemfokus auf die Grafik gezogen wird.

Sobald Ergebnisse gefunden oder aktualisiert wurden, wird vom Screenreader die Anzahl der gefundenen Einträge automatisch ausgeben. Text: “[Anzahl] Einträge”. Außerdem wird der darunterliegende Text “[Anzahl] Einträge” entsprechend aktualisiert.

Werden keine Treffer gefunden, so wird die komplette Baumstruktur inklusive des “Alle auf-/zuklappen”-Buttons ausgeblendet und stattdessen wird der Text “Kein Treffer für diese Such- und Filterkriterien gefunden” angezeigt.

[Grafik „Ladezustand ohne Treffer” wurde hinzugefügt]

[Grafik „Responsives Verhalten des Elements Keine Treffer Gefunden” wurde hinzugefügt]

ℹ️ Änderung in Bold dargestellt

Folgender Satz wurde entfernt: Bei Hover mit der Maus erscheint ein Tooltip, welcher den vollständigen Text anzeigt.

[Grafik "Tooltip" wurde entfernt]

ℹ️ Änderung in Bold dargestellt

https://1.1.designsystem.gefa-justiz.de/komponenten/checkbox?tab=spezifikation

[Grafik Read-Only Gruppe wurde entfernt]

Einzelne Checkboxen werden im Read-Only-Zustand als ein Read-Only Eingabefeld dargestellt (Aufbau siehe Eingabefeld). Die Feldbezeichnung des Eingabefelds entspricht dem Textlabel der Checkbox. Im Read-Only Eingabefeld wird bei aktivierter Checkbox der Wert als “Ja” ausgeben, bei nicht aktiver Checkbox wird der Wert als “Nein” ausgegeben.

Checkboxgruppen werden im Read-Only-Zustand auch als ein einzelnes Read-Only Eingabefeld dargestellt. In diesem Fall entspricht die Feldbezeichnung dem Checkboxgruppentitel und es werden alle aktiven Einträge der Gruppe in einem Eingabefeld aufgelistet. Diese werden mit ";" getrennt. Inaktive Checkboxen werden im Read-Only-Zustand ausgeblendet und nicht im Eingabefeld angezeigt.

ℹ️ Änderung in Bold dargestellt

https://1.1.designsystem.gefa-justiz.de/komponenten/radiobutton?tab=spezifikation#verhalten

[Grafik Read-Only Gruppe wurde entfernt]

Radio-Button-Gruppen werden im Read-Only-Zustand als ein Read-Only Eingabefeld dargestellt (Aufbau siehe Eingabefeld). Die Feldbezeichnung des Eingabefelds entspricht dem Radio-Button-Gruppen-Titel. Das Textlabel des aktiven Eintrags der Gruppe wird im Read-Only Eingabefeld ausgegeben. Inaktive Einträge werden im Read-Only-Zustand ausgeblendet und nicht im Eingabefeld angezeigt.

Bugfix

Stand Vorher:

Weiter navigieren:
Wird der Arbeitsschritt vorwärts zu einem folgenden Arbeitsschritt verlassen, wird das Formular validiert und der nächste Schritt wird geöffnet, wenn es keine Validierungsfehler gibt.

Fehlerverhalten siehe Bereich “Meldungsbanner in Formularen”. Der Titel der Fehlermeldung ist “Fehlerhafte Eingaben”.

Zurück navigieren:
Vorherige Schritte können jederzeit angesprungen werden und das Formular wird dafür nicht validiert. Eingaben bleiben erhalten. Der verlassene Arbeitsschritt wird als besucht angezeigt.

Verlassen eines vorher besuchten (Bereits Validierten) Arbeitsschritts

Wird eine besuchter und validierter Arbeitsschritt erneut geöffnet, wird das Formular beim Verlassen des geänderten Feldes bzw. Arbeitsschrittes wieder validiert (unabhängig von der Navigationsrichtung).

Wurde geändert zu:

Je nach dem, in welche Richtung navigiert wird, gilt:

• Weiter navigieren: Wird der Arbeitsschritt vorwärts zu einem folgenden Arbeitsschritt verlassen, wird das Formular validiert und der nächste Schritt wird geöffnet, sofern es keine Validierungsfehler gibt. Im Fehlerfall erscheint ein “Meldungsbanner” mit dem Titel “Fehlerhafte Eingaben”.
• Zurück navigieren: Vorherige Schritte können jederzeit angesprungen werden und dadurch wird keine Validierung ausgelöst. Eingaben bleiben erhalten. Der verlassene Arbeitsschritt wird als besucht angezeigt.

Für die vollständige und detailierte Beschreibung des Validierungsverhaltes im Wizard siehe “Ablauf von Validierungen in Wizardprozessen”.

ℹ️ Änderung in Bold dargestellt

Konzept für Rückgängig machen

Undo/Redo bezieht sich nur auf die Elemente, die sich in einem aktuell geöffneten Formular befinden. Rückgängig gemacht werden können dementsprechend: 

• Änderungen in Eingabe- oder Auswahlfeldern (egal ob einzeilig, mehrzeilig, Datumseingabe, Combobox, usw.)
• Änderungen einer Checkbox- oder Radio-Button-Auswahl
• Hinzufügen einer Elementgruppe oder eines weiteren Feldes im Formular
• Entfernen einer Elementgruppe oder eines Feldes im Formular
• Hinzufügen eines Unterobjekts: Dabei ist nur das Hinzufügen des Objekts als ganzes Rückgängig machbar, nicht die enthaltenen Einzelaktionen.
• Bearbeiten von Unterobjekten: Dabei ist nur die Bearbeitung des Objekts als ganzes Rückgängig machbar, nicht die enthaltenen Einzelaktionen.
• Entfernen von Unterobjekten (z. B. über die Tabellenaktionen einer Unterobjektübersicht im Elternformular oder über den Formularheader im Kindformular anschließende Rückkehr ins Elternformular)

Ablauf:

• Der Undo-Button im Formular-Footer wird erst aktiv, wenn eine Änderung im Formular durchgeführt wurde (mind. 1 Zeichen) – bei Eingabefeldern erst bei Verlassen des Feldes. Entsprechend wird bei Eingabefeldern auch nur die komplette Wertänderung im Stack gelistet, nicht jede einzelne Aktion (Zeichen hinzufügen/ändern/entfernen) innerhalb des Feldes.
• Der Redo-Button wird erst aktiv, sobald eine Aktion Rückgängig gemacht wurde.
• Bei Verlassen des Formulars (beispielsweise durch Öffnen eines Modals/Unterformulars oder der nächsten Seite eines Wizards) wird die Undo/Redo-Historie des gerade verlassenen Formulars nicht weiter gespeichert.
• Die Anzahl an rückgängig-machbaren Aktionen ist nach oben nicht begrenzt.
• Maximal bis zum Anlegen/Speichern/Schließen des Formulars
• Die Undo/Redo-Historie wird maximal bis zum Anlegen/Speichern/Schließen des Hauptformulars gespeichert.
• Das Hinzufügen/Bearbeiten eines Kind-Formulars kann nicht über das Undo der Elternmaske rückgängig gemacht werden.
• Das Entfernen eines Kind-Formulars kann nur Rückgängig gemacht werden, wenn es aus dem Elternformular heraus ausgeführt wurde (aus Tabelle oder Liste).
• Hinzufügen von Objekten (wie Gruppen oder weiterer Felder) innerhalb des Formulars können rückgängig gemacht werden.
• Bei Nutzeraktionen, welche Änderung an mehreren Feldern zur Folge haben, wird nur das auslösende Event als ein Eintrag im Undo- bzw. Redo-Stack gelistet (statt 1 Eintrag pro geändertem Feld und damit einzelner Rückgängigmachbarkeit). Beispiele: 
• • Änderung an Feld A führt zu Zurücksetzen oder Vorbefüllen der Felder B, C & D. Es wird nur die Änderung am Feld A im Undo- bzw. Redo-Stack gelistet.
  • Entfernen einer Gruppe führt zu entfernen aller enthaltener Felder. Es wird nur die Entfernen-Aktion im Undo- bzw. Redo-Stack gelistet.
• Bei Verlassen eines Elternformulars in ein Kindobjekt (egal ob Modales Formular oder Unterseite) wird die Undo/Redo-Historie des gerade verlassenen Elternobjekts gespeichert, ist allerdings erst nach Rückkehr in dieses Elternobjekt wieder abrufbar. 
• Jedes Öffnen eines Kindformulars startet in diesem mit einem leeren Stack und Undo+Redo-Button sind entsprechend deaktiviert, bis Änderungen durchgeführt werden.
• Wird ein Kindformular über “Schließen”, “Hinzufügen” oder “Übernehmen” verlassen, so wird dessen Undo/Redo-Stack endgültig zurückgesetzt. Anschließend ist der vorherige Stand des Undo/Redo-Stackis im Elternformular wieder verfügbar.
• Wird das Hauptobjekt über “Speichern”, “Anlegen” oder “Schließen” verlassen, so wird dessen Undo/Redo-Stack endgültig zurückgesetzt.

ℹ️ Änderung in Bold dargestellt

Begrenzung von Trefferzahlen bei Tabellen & Listen (nicht bei Baumstrukturen)

Bei kleinen Datenmengen: Vollständige Anzeige aller Objekte im Frontend

Im Idealfall sollten Datenübersichten (Tabellen/Listen/Baumstrukturen/Kalenderansichten) immer die Gesamtmenge der vorhandenen Objekte eines Typs beinhalten, ggf. auf mehrere Seiten verteilt bei paginierten Tabellen oder Listen.

[Grafik " Idealfall ohne Begrenzung bei niedriger Gesamtzahl an Objekten " wurde hinzugefügt"]

Bei sehr hohen Objektzahlen kann die Darstellung der gesamten Ergebnismenge im Frontend jedoch zu erheblichen Performance-Problemen führen. Dies ist vor allem dann zu erwarten, wenn komplexe Such- und Filteranfragen gestellt werden.

Beispiele für Datenübersichten in GeFa mit erwartungsgemäß sehr hohen Trefferzahlen:

• Justizbedienstete (beinhaltet die Justizbediensteten aller Behörden eines ganzen Bundeslandes)
• Poolpersonen (ebenfalls bundeslandübergreifender Katalog häufig an Verfahren beteiligter Personen)
• Termine (je nach dem, wie lange in die Vergangenheit oder in die Zukunft Termine vorgehalten werden, hohe Anzahl möglich)

Limitierung bei der Trefferanzeige

Um die Systemperformance zu optimieren bzw. Überlastungen im Vorhinein vorzubeugen, wurde ein Limit von 200 Einträgen festgelegt, welche maximal im Frontend von Tabellen und Listen angezeigt werden.

Die Begrenzung hat zur Folge:

• Bei einem Limit von 200 Einträgen werden in paginierten Tabellen und Listen maximal 20 Seiten mit Einträgen angezeigt, die der Nutzer manuell durchblättern kann. (Falls die Anzahl von Einträgen pro Seite, aktuell 10, irgendwann in den Nutzereinstellungen erhöht werden kann, so verringert sich die Seitenzahl entsprechend).
• Welche Einträge auf den ersten 20 Seiten angezeigt werden, wird durch die Sortierung bestimmt (entweder die fachlich vorgegebene Initialsortierung oder eine vom Nutzer geänderte Sortierung). Bei alphabetischer Sortierung könnte es also sein, dass in einer Tabelle nur Personen mit Nachnamen, die mit A und B starten, angezeigt werden.
• Um weitere Einträge sehen zu können, müssen Nutzer durch Suchen oder Filtern die Ergebnismenge einschränken. Ebenfalls möglich ist die Änderung der Sortierung - im vorherigen Beispiel der alphabetisch sortierten Personen wären dann bei umgekehrter Sortierung nur noch die Namen sichtbar, die mit den letzten Buchstaben des Alphabets beginnen.

Damit Nutzenden bewusst ist, dass sie nur einen Auszug aus der Gesamtliste aller Objekte sehen können und niemand fälschlicherweise davon ausgeht, dass es sich um alle Einträge handelt, wird im Fall der Limitierung folgendes an der Tabellen- und Listendarstellung geändert:

• Es erscheint ein zusätzlicher Hinweistext Typ 3 über der Tabelle oder Liste mit folgendem Inhalt: “Hinweis: Es gibt sehr viele Treffer. Hier werden nur die ersten [Anzahl] Einträge dargestellt. Schränken Sie bei Bedarf Ihre Such- und Filterparameter weiter ein.”
• In der Überschrift “[Anzahl]+ Einträge” wird die Anzahl von Tabelleneinträgen über alle Seiten der Paginierung hinweg genannt. Diese kann hier maximal 200 betragen (auch wenn im Backend mehr Einträge existieren). An die Anzahl ist außerdem ein Plus-Zeichen angefügt. Beispiel “200+ Einträge”. Die Überschrift wird Screenreadernutzenden inklusive des Plus-Zeichens bei jeder Trefferaktualisierung ausgegeben, z. B. nach Änderung der Such- oder Filterparameter (Details siehe Ergebnisanzeige bzw. -ausgabe bei Tabellen und Listen).
• Falls die Tabelle oder Liste sich innerhalb eines Tabs befindet, in welchem die Gesamtzahl der enthaltenen Objekte genannt wird (bspw. Verfahrenstab “Beteiligte”), so wird im Tab weiterhin die tatsächliche Gesamtzahl angezeigt und ist diese ist nicht auf 200 begrenzt. Die Zahl im Tab kann also vom Text “[Anzahl] Einträge” über der Tabelle oder Liste abweichen.
• Die Paginierung ist auf maximal 20 Seiten begrenzt. (bzw. weniger, falls irgendwann mehr als 10 Einträge pro Seite angezeigt werden können).
• Auf der letzten Tabellen- bzw. Listenseite wird im Inhaltsbereich unter dem letzten Eintrag eine Hinweiszeile angezeigt, welche erneut erinnert, dass es eigentlich noch mehr Einträge gibt, welche aber an dieser Stelle abgeschnitten sind.

Obwohl 200 als Maximalzahl definiert ist, kann es auch zu geringeren Objektzahlen in Tabellen oder Listen kommen, auch wenn eigentlich noch mehr Einträge existieren. Dies kann vorkommen, wenn nach Absenden einer Such- und Filteranfrage mehrere Tabellen auf der Datenbank zuerst zusammengefügt werde, dann eine Anzahl von 400 Einträgen der zusammengefügten Tabelle abgeschöpft wird und anschließend in der neuen Tabelle erst Duplikate identifiziert und entfernt werden. Gab es viele Duplikate so kann die anschließend ans Frontend übergebene Ergebnistabelle theoretisch auch weniger als 200 Einträge enthalten. Dies ist technisch schwer vorherzusehen bzw. zu verhindern. Jedoch kann mit einem genügend großen Gap zwischen der Menge, die im Backend pro Tabelle abgeschöpft wird und den letztendlich im Frontend angezeigten Einträgen, erreicht werden, dass es möglichst selten zu einer Unterschreitung der 200 Einträge im Frontend kommt. (Falls der Fall noch zu oft vorkommt, so kann die Zahl “400” später noch angehoben werden)

[Grafik "Die Anzahl der Objekte überschreitet das Anzeigelimit in Tabellen." wurde hinzugefügt]

[Grafik "Die Anzahl der Objekte überschreitet das Anzeigelimit in Listen." wurde hinzugefügt]

Wichtig: Die Begrenzung der maximalen Trefferzahl gilt nur für Tabellen und Listen. Bei Baumstrukturen müssen – da hier nicht paginiert wird – immer alle Treffer im Frontend angezeigt werden. Bei der Konzeption wurde entsprechend darauf geachtet, dass Datenübersichten mit enorm hohen zu erwartenden Eintragszahlen nicht als Baumstruktur, sondern tabellarisch im Frontend abgebildet werden.
Bei Kalenderansichten wird ebenfalls keine Begrenzung der Treffer auf einer Ansicht (Tages-, Wochen- oder Monatsansicht) vorgenommen.

ℹ️ Änderung in Bold dargestellt

Verhalten Einzeiliges Eingabefeld

Im einzeiligen Eingabefeld können Informationen eingegeben werden.

Je nach Einsatz kann das Feld mit Hinweistext und/oder einer maximalen Zeichenanzahl versehen sein. Pflichtfelder sind mit “*” (Sternchen”) nach dem Label markiert. Bei Read-Only-Feldern gibt es keine visuelle Pflichtfeldauszeichnung, auch wenn diese im Backend ggf. als Pflichtfelder geprüft werden.

[Grafik Eingabefeld mit Pflichtfeldauszeichnung]

Die Eingabefeldbezeichnung sollte so kurz und präzise wie möglich formuliert sein. Sollte ein Label dennoch länger sein müssen, so bricht es um und wird mehrzeilig.

[Grafik Mehrzeiliges Label]

Wenn eine maximale Zeichenzahl definiert wird:

Bei Erreichen der maximal erlaubten Zeichenzahl wird keine weitere Eingabe zugelassen. Bei jedem weiteren Tastenanschlag (keydown) ertönt ein akustisches Signal: Fehlermeldung (siehe akustische Signale).

Wenn keine maximale Zeichenzahl definiert wird: 
Die Standardanzahl erlaubter Zeichen beträgt 255. Da dies abhängig von der technischen Umgebung ist, kann die Anzahl aber auch variieren. Falls die eingegebene Zeichenanzahl das Zeichenlimit überschreitet, wird bei Verlassen des Feldes ein Validierungsfehler an Formularfeldern ausgelöst (siehe Formular: Validierungsfehlern an Formularfeldern). Die Fehlermeldung lautet „Maximale Zeichenanzahl überschritten: [Eingegebene Zeichen im Feld]/[technisch maximal mögliche Zeichen]”.
Das Standardverhalten für Fehlermeldungen findet Anwendung (siehe Formular: Ablauf Front-/Backend-Validierung).

Fehlerfälle / Validierung mehrzeiliger Eingabefelder

Bei fehlerhaften oder fehlenden Eingaben (Ablauf siehe Formulare: Ablauf Front-/Backend-Validierung) erscheint ein Ausrufezeichen-Icon mit erklärendem Text, dieses muss als Layoutgrafik deklariert werden. Gleichzeitig ertönt ein akustisches Signal: Fehlermeldung (siehe akustische Signale).

(Standard-)Fehlermeldungen, Formulierungsregeln für Fehlermeldungen und das Verhalten bei Erreichen einer definierten maximalen Zeichenanzahl des Feldes sind identisch mit dem einzeiligen Eingabefeld. (siehe oben Fehlerfälle / Validierung Einzeiliges Eingabefeld).

Wenn keine maximale Zeichenzahl definiert wird: 
Die Standardanzahl erlaubter Zeichen beträgt in der Regel 4000. Da dies abhängig von der technischen Umgebung ist, kann die Anzahl aber auch variieren. Falls die eingegebene Zeichenanzahl das Zeichenlimit überschreitet, wird bei Verlassen des Feldes ein Validierungsfehler an Formularfeldern ausgelöst (siehe Formular: Validierungsfehlern an Formularfeldern). Die Fehlermeldung lautet „Maximale Zeichenanzahl überschritten: [Eingegebene Zeichen im Feld]/[technisch maximal mögliche Zeichen]”.
Das Standardverhalten für Fehlermeldungen findet Anwendung (siehe Formular: Ablauf Front-/Backend-Validierung).

Im Read-Only-Zustand passt sich die Feldhöhe dem eingegebenen Inhalt an, so dass zum einen der komplette Text lesbar ist, zum anderen keine optischen Lücken in Formularen entstehen, wenn wenig Text eingegeben wurde.

[Grafik Positives Beispiel für mehrzeilige Eingabefelder]

[Grafik negatives Beispiel für mehrzeilige Eingabefelder]

ℹ️ Änderung in Bold dargestellt

In Mehrfachauswahlfeldern wird vor dem ersten Eintrag immer die Alle-Auswählen-Option angeboten. Dafür trägt die erste Checkbox die Bezeichnung “Alle Einträge auswählen” und darunter wird eine graue Linie angezeigt. Diese dient nur zur visuellen Darstellung.

Wird die Checkbox im Alle-auswählen-Eintrag aktiviert, so werden alle im Dropdown enthaltenen anderen Einträge automatisch auf “Ausgewählt” gesetzt. Wird die Checkbox wieder deaktiviert, so werden alle im Dropdown enthaltenen Elemente auf “Nicht ausgewählt” gesetzt. Wurden alle Werte selektiert, so wird im Auswahlfeld (egal ob Ausklappliste geöffnet oder geschlossen) das Wort “Alle” angezeigt, anstatt jeden Einzelwert zu listen. Dies gilt jedoch nur für bearbeitbare Felder.

Falls Nutzende händisch alle im Dropdown enthaltenen Checkboxen selektieren, so wird die Checkbox “Alle Einträge auswählen” automatisch aktiviert. Falls die Checkbox bei “Alle Einträge auswählen” aktiviert ist und händisch eine Checkbox in einem darunterliegenden Eintrag entfernt wird, so wird die Checkbox bei “Alle Einträge auswählen” wieder deaktiviert.

Besonderheit zur Wertanzeige im Feld (nur bei bearbeitbaren Feldern): Wurden alle Werte selektiert, so wird im Auswahlfeld “Alle ([Anzahl ausgewählter Einträge])” angezeigt (egal ob die Ausklappliste geöffnet oder geschlossen ist). Ausnahme: Enthält die Auswahlliste nur einen Wert (zusätzlich zur “Alle-auswählen-Option”) und dieser ist ausgewählt, so wird der Wert im Feld immer direkt genannt an Stelle der Formulierung “Alle (1)”.

Ist ein Mehrfachauswahlfeld nicht bearbeitbar (read-only), so werden immer alle ausgewählten Werte im Feld ausgeschrieben, so dass Nutzende die Auswahl wahrnehmen können. Auch, wenn alle verfügbaren Einträge gewählt sind, werden im Feld die Einzelwerte angezeigt statt “Alle ([Anzahl ausgewählter Einträge])”. Werden die ausgewählten Inhalte zu lang, um in einer Zeile dargestellt zu werden, so werden sie abgekürzt (siehe Eingabefeld: Verhalten). In der Read-Only-Ansicht werden keine Grafiken (z. B. Personen-Icons) mit angezeigt, sondern nur reiner Text.

[Grafik "Alle Auswählen Funktion" wurde aktualisiert]

ℹ️ Änderung in Bold dargestellt

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”).

[Grafik "Karte die nur lesend geöffnet werden kann" wurde hinzugefügt]

------------

Tastaturbedienung

• 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.

-------------

Mausbedienung

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

ℹ️ Änderung in Bold dargestellt

Definition Seitenfüllende Fehlermeldung

Seitenfüllende Fehlermeldungen werden dann angezeigt, wenn die Inhalte einer ganzen Seite in GeFa aus einem der folgenden Gründe nicht angezeigt werden können:

• Fehlende Authorisierung: Anwendungsbeispiel: Nutzende haben einen GeFa-Direktlink im Browser aufgerufen und haben keine Berechtigung zum Aufruf dieser Seite. Dies gilt sowohl für fehlende Tätigkeitsberechtigungen im Backend oder Frontend (werden verwaltet in der BKKB) als auch für fehlende Zugriffsberechtigungen (werden über die Zuordnung von Personen zu OE-Besetzungslisten in der GRVW gesetzt).
• Seite existiert nicht. Anwendungsbeispiel: Nutzende haben einen GeFa-Link eingegeben, der nicht bzw. nicht mehr existiert.
• Für den Fall, wenn Anwendende nicht eingeloggt sind, wird keine Seitenfüllende GeFa-Fehlermeldung angezeigt sondern sie werden direkt zur Login-Maske weitergeleitet.
Nach erfolgreichem Anmelden, werden Anwendende direkt auf die initial aufgerufene Seite zurückgeleitet.

----------------

Seitenfüllende Fehlermeldung bei Öffnen von Umsystemen

Wird ein Umsystem, bei dem es sich um eine Desktopanwendung handelt, aus GeFa heraus aufgerufen (z. B. über einen entsprechenden Button im GeFa Hauptmenü oder im Verfahrensheader), dann öffnet sich in einem neuen Browsertab eine seitenfüllende Meldung, welche den Nutzer darüber informiert, dass das entsprechende Umsystem gerade aufgerufen wird. Ein Hinweis informiert außerdem darüber, was Nutzer tun können, falls nichts passiert.

Ein Button ermöglicht den erneuten Aufruf des Umsystems. Nach Ausführen dieses Buttons öffnet sich erneut ein neuer Browsertab mit identischem Inhalt und gleichem Verhalten.

Nachdem sich die Desktopanwendung geöffnet hat, kann der Browsertab von Nutzenden manuell wieder geschlossen werden.

Falls es sich beim aufgerufenen Umsystem um eine Browserapplikation handelt, so erscheint diese Seite nicht und statt dessen wird direkt die URL des jeweiligen Systems aufgerufen.

[Grafik "Seitenfüllende Fehlermeldung bei Öffnen von Umsystemen" wurde hinzugefügt]

ℹ️ Änderung in Bold dargestellt

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.

[Grafik Eingabe]

[Grafik Auswahl]

[Grafik Checkbox-Gruppe]

[Grafik Radiobutton-Gruppe]

ℹ️ Änderung in Bold dargestellt

Fehlerfälle/Validierung

Bei fehlerhaften oder fehlenden Eingaben (Ablauf siehe Formular: Ablauf Front-/Backend-Validierung) erscheint ein Ausrufezeichen-Icon mit erklärendem Text, dieses muss als Layoutgrafik deklariert werden. Gleichzeitig ertönt ein akustisches Signal: Fehlermeldung (siehe Akustische Signale)

Auf fehlerhafte Eingabe werden Nutzende direkt nach Verlassen des Feldes hingewiesen, es erscheint ein Ausrufezeichen-Icon mit erklärendem Text, dieses muss als Layoutgrafik deklariert werden. Gleichzeitig ertönt ein akustisches Signal: Fehlermeldung (siehe Akustische Signale). Beispiele für Fehler hier: 

• Nicht befülltes Pflichtfeld
• Wert ins Feld geschrieben aber kein Wert aus der Liste aktiv ausgewählt

Es findet nie eine automatische Wertübernahme ohne Auswahl aus der Liste (via Mausklick oder Enter) statt, auch dann nicht, wenn Nutzende die primäre Information eines Eintrags manuell komplett ins Feld eingeben, dann das Feld verlassen und der Wert mit genau einem Eintrag aus der Trefferliste übereinstimmt. Falls das Feld verlassen wird, bereits etwas ins Feld geschrieben wurde aber kein Wert aus der Liste aktiv ausgewählt wurde, dann wird bei Verlassen die Fehlermeldung “Wählen Sie einen Wert aus der Liste aus” angezeigt (siehe Meldungskonzept: Standard-Meldungen für Formular-Validierungsfehler).

Bei anderen Fehlermeldungen sind die Formulierungsregeln für Meldungen zu beachten (siehe Meldungskonzept: Formulierungsregeln für Formular-Valididierungsfehler).

[Grafik Element "Kein Suchbegriff gefunden"]

[Grafik Verhalten bei keinem vorher gewählten Eintrag]

[Grafik Verhalten bei bereits gewähltem Eintrag]

[Grafik Verhalten bei unvollständiger Eingabe]

ℹ️ Änderung in Bold dargestellt

Tastaturbedienung

• Mit der Tab-Taste wird das Multiselect-Element fokussiert. 
• Leertaste, ALT+Pfeil unten und Pfeil unten öffnen das Dropdown mit den Auswahloptionen.
• Falls vorher kein Eintrag ausgewählt war, ist beim Öffnen der erste Eintrag im Dropdown fokussiert. 
• Falls vorher bereits einer oder mehrere Einträge gewählt waren, ist der Erste davon beim Öffnen des Dropdowns fokussiert.
• Sollte der selektierte Eintrag eingeklappt sein, wird der erste Eintrag fokussiert.
• Pfeiltasten nach unten/oben wechseln zur nächsten/vorherigen Auswahloption.
• Bei Drücken eines oder mehrerer Buchstaben, wird der nächste Eintrag fokussiert, dessen Primärtext mit der entsprechenden Zeichenkette beginnt (ausgehend vom aktuell fokussierten Eintrag). Nach 1 Sekunde wird die Zeichenkette zurück gesetzt.
• Enter oder Leertaste wählt den fokussierten Eintrag aus und der Fokus bleibt auf dem Eintrag. Erneutes Drücken der Enter oder Leertaste wählt den Eintrag wieder ab (default state).
• Drücken der Home-Taste bei geöffneter Ausklappliste verschiebt die visuelle Hervorhebung auf das erste Element in der Liste.
  Drücken der End-Taste bei geöffneter Ausklappliste verschiebt die visuelle Hervorhebung auf das letzte Element der Liste.
• Mit der Esc-Taste kann das Dropwdown geschlossen werden und die ausgewählten Werte werden übernommen. Das Select-Element ist wieder fokussiert.
• Mit Tab-Taste kann das Dropdown-Element ebenfalls geschlossen werden, die ausgewählten Werte werden übernommen und das nächste interaktive Element ist fokussiert.

ℹ️ Änderung in Bold dargestellt

Tastaturbedienung

• Mit der Tab-Taste wird das Select-Element fokussiert. 
• Leertaste, ALT+Pfeil unten und Pfeil unten öffnen das Dropdown mit den Auswahloptionen. 
• Falls vorher kein Eintrag ausgewählt war, ist beim Öffnen der erste Eintrag im Dropdown fokussiert. 
• Falls vorher bereits ein Eintrag gewählt war, ist dieser beim Öffnen des Dropdowns fokussiert.
• Pfeiltasten nach unten/oben wechseln zur nächsten/vorherigen Auswahloption unabhängig davon, ob diese aktiv oder deaktiviert dargestellt ist.
• Bei Drücken eines oder mehrerer Buchstaben, wird der nächste Eintrag fokussiert, dessen Primärtext mit der entsprechenden Zeichenkette beginnt (ausgehend vom aktuell fokussierten Eintrag). Nach 1 Sekunde wird die Zeichenkette zurück gesetzt.
• Enter oder Leertaste wählt den fokussierten Eintrag aus und schließt das Dropdown. Das Select-Element ist wieder fokussiert. Ausnahme: Ist ein deaktiviertes Elemente visuell hervorgehoben, so hat die Entertaste keine Auswirkung (Ausklappliste bleibt geöffnet und Hervorhebung bleibt unverändert).
• Deaktivierte (disabled) Elemente können nicht mit Enter oder Leertaste ausgewählt werden.
• Drücken der Home-Taste bei geöffneter Ausklappliste verschiebt die visuelle Hervorhebung auf das erste Element in der Liste.
• Drücken der End-Taste bei geöffneter Ausklappliste verschiebt die visuelle Hervorhebung auf das letzte Element der Liste.
  Mit der Esc-Taste kann das Dropwdown geschlossen werden, ohne das eine Auswahl getätigt wird. Das Select-Element ist wieder fokussiert.
• Die Tab-Taste wechselt zum nächsten interaktiven Element.

Tastaturbedienung der minimierten Version gleich wie die, der Standard Variante.

Tastaturbedienung Einfachauswahlfeld mit Baumstruktur und selektierbaren Knotenpunkten

• Mit der Tab-Taste wird das zuletzt fokussierte Element fokussiert. 
• Leertaste, ALT+Pfeil unten und Pfeil unten öffnen das Dropdown mit den Auswahloptionen.
• Falls vorher kein Eintrag fokussiert war, wird beim Öffnen der erste Eintrag im Dropdown fokussiert. 
• Falls vorher bereits ein Eintrag fokussiert war, ist dieser beim Öffnen des Dropdowns fokussiert.
• Pfeiltasten nach unten/oben wechseln zur nächsten/vorherigen Auswahloption.
• Pfeiltaste nach rechts öffnet den Baum-Zweig unabhängig davon, ob diese aktiv oder deaktiviert dargestellt ist.
• Falls der Baum-Zweig schon geöffnet ist und erneut die Pfeiltaste nach rechts gedrückt wird, springt der Fokus zum nächsten Kindelement.
• Pfeiltaste nach links schließt den Baum-Zweig.
• Falls der Baum-Zweig schon geschlossen ist und erneut die Pfeiltaste nach links gedrückt wird, springt der Fokus zum Elternelement.
• Bei Drücken eines oder mehrerer Buchstaben, wird der nächste Eintrag fokussiert, dessen Text mit der entsprechenden Zeichenkette beginnt. Dabei wird die Baumstruktur wie eine flache Liste behandelt. Kindelemente von zugeklappten Baumelementen werden nicht durchsucht. Falls kein darunterliegendes Baumelement mit der Zeichenkette übereinstimmt, startet die Suche erneut beim ersten Listenelement. Die Fokussetzung wird nach einer Verzögerung von einer Sekunde ausgeführt und damit wird die Zeichenkette wieder zurückgesetzt.
• Beim Drücken der Sternchen/Asterisk-Taste (*) werden alle Geschwisterelemente des aktuell fokussierten Baumelements aufgeklappt (Elemente, welche sich auf der gleichen Ebene wie das aktuell fokussierte Baumelement befinden). Der Fokus ändert sich dabei nicht.
• Drücken der Home-Taste bei geöffneter Ausklappliste verschiebt den Fokus auf das erste fokussierbare Element der Liste
• Drücken der End-Taste bei geöffneter Ausklappliste verschiebt den Fokus auf die letzte Element der Liste (ohne, dass eine Kategorie geöffnet/geschlossen wird).
• Enter oder Leertaste wählt den fokussierten Eintrag aus und schließt das Dropdown. Das Select-Element ist wieder fokussiert.
• Deaktivierte (disabled) Elemente können nicht mit Enter oder Leertaste ausgewählt werden.
• Mit der Esc-Taste kann das Dropwdown geschlossen werden, ohne das eine Auswahl getätigt wird. Das Select-Element ist wieder fokussiert.
• Die Tab-Taste wechselt zum nächsten interaktiven Element.

ℹ️ Änderung in Bold dargestellt

Fehlerfälle / Validierung

Bei fehlerhaften (zum Beispiel “51:30” oder “11111”) oder fehlenden Eingaben (Ablauf siehe Formulare: Ablauf Front-/Backend-Validierung) erscheint ein Ausrufezeichen-Icon mit erklärendem Text, dieses muss als Layoutgrafik deklariert werden. Gleichzeitig ertönt ein akustisches Signal: Fehlermeldung (siehe akustische Signale).

[Grafik Falsches Eingabeformat]

Die Standardfehlermeldung für falsch eingegebene Uhrzeiten lautet entweder “Falsches Eingabeformat” oder, bei einer Uhrzeit, die die Formatvorgaben erfüllt, jedoch nicht existiert (Beispiel “26:15”) “Keine gültige Uhrzeit” (siehe Meldungskonzept: Standard-Meldungen für Formular-Validierungsfehler).

Details zur Anwendung der Standardfehlermeldungen sind im Meldungskonzept beschrieben. Bei anderen Fehlermeldungen sind die Formulierungsregeln für Meldungen zu beachten (siehe Meldungskonzept: Formulierungsregeln für Formular-Valididierungsfehler).

ℹ️ Änderung in Bold dargestellt

Fehlerfälle / Validierung

Bei Erreichen der maximal erlaubten Zeichenzahl wird keine weitere Eingabe zugelassen. Bei jedem weiteren Tastenanschlag (keydown) ertönt ein akustisches Signal: Fehlermeldung (siehe Akustische Signale).

Bei fehlerhaften oder fehlenden Eingaben (siehe Formular: Ablauf Front-/Backend-Validierung) erscheint ein Ausrufezeichen-Icon mit erklärendem Text, dieses muss als Layoutgrafik deklariert werden. Gleichzeitig ertönt ein akustisches Signal: Fehlermeldung (siehe Akustische Signale)

Die Teilfelder müssen in Fehlermeldungen immer genannt und als “Von-Wert” und “Bis-Wert” referenziert werden. Handelt es sich bei dem Wertebereichsfeld jedoch um ein Datumsbereich, so werden die Felder “Von-Datum” und “Bis-Datum” genannt. (Siehe Formular: Fehlerbanner Schema Benennung)

Validierungsfehler sind wie folgt zu kennzeichnen:

• Wenn nur eines der Teilfelder fehlerhaft ist, ist dieser im Fehlertext zu benennen. Bsp. “Von-Wert: Nur positive Ganzzahlen zulässig im Format 1.234”. In diesem Fall wird nur das linke Feldteil optisch als fehlerhaft dargestellt.
• Wenn beide Teilfelder fehlerhaft sind, dann erscheinen zwei Fehlermeldungen unter dem Wertebereich-Feld, in denen jeweils die Beschriftungen des zum Fehler gehörenden Teilfeldes genannt werden muss. Bsp: “Von-Wert: Nur Ganzzahlen zulässig im Format 1.234” und “Bis-Wert: Nur Ganzzahlen zulässig im Format 1.234” Beide Feldteile werden optisch als fehlerhaft angezeigt.
• Ist die Kombination aus beiden Eingaben nicht schlüssig (Cross-Validierung), so wird ein gemeinsamer Fehler angezeigt. Bsp: “Bis-Wert darf nicht vor Von-Wert liegen”. Alle editierbaren Feldteile werden optisch als fehlerhaft angezeigt.

[Grafik Fehler in einem Feld + Focus]

[Grafik Fehler und Validierungen]

Für Standardvalidierungsmeldungen für die beinhalteten Teilfelder siehe jeweiliges Eingabe- oder Auswahlelement.

Standardvalidierungsmeldungen für Cross-Validierung zwischen den zwei Feldern (wird erst geprüft, sobald die Einzelfelder fehlerfrei sind):

• Wenn die Reihenfolge der Werte logisch nicht schlüssig ist (Beispiel: Von-Wert “6”, Bis-Wert “2”): “Bis-Wert darf nicht vor Von-Wert liegen”
• Ausnahme: Wenn der Bis-Wert sich im Read-Only-Zustand befindet: “Von-Wert darf nicht nach Bis-Wert liegen”

Standardmeldungen bei Cross-Validierung bei Datums-Wertebereichsfeldern:

• Wenn die Reihenfolge der Daten nicht chronologisch ist: “Enddatum darf nicht vor Beginndatum liegen”
• Ausnahme: Wenn der Bis-Wert sich im Read-Only-Zustand befindet: “Beginndatum darf nicht nach Enddatum liegen”

Details zur Anwendung der Standardfehlermeldungen sind im Meldungskonzept beschrieben (siehe Meldungskonzept: Standard-Meldungen für Formular-Validierungsfehler). Bei anderen Fehlermeldungen sind die Formulierungsregeln für Meldungen zu beachten (siehe Meldungskonzept: Formulierungsregeln für Formular-Valididierungsfehler).chten (siehe Meldungskonzept: Formular-Validierungsfehler).

ℹ️ Änderung in Bold dargestellt

Fehlerfälle / Validierung

Bei fehlerhaften oder fehlenden Eingaben (Ablauf siehe Formulare: Ablauf Front-/Backend-Validierung) erscheint ein Ausrufezeichen-Icon mit erklärendem Text, dieses muss als Layoutgrafik deklariert werden. Gleichzeitig ertönt ein akustisches Signal: Fehlermeldung (siehe akustische Signale).

[Grafik Datumsfeld mit fachlichem Hinweistext]

Standardfehlermeldungen lauten:

• Bei ungültigem Datumsformat: “Falsches Eingabeformat”
• “Datum darf nicht in der Zukunft liegen”
• “Datum darf nicht in der Vergangenheit liegen”
• “Kein gültiges Datum” (Beispiel: “65.50.2012”)

Details zur Anwendung der Standardfehlermeldungen sind im Meldungskonzept beschrieben (siehe Meldungskonzept: Standard-Meldungen für Formular-Validierungsfehler). Bei anderen Fehlermeldungen sind die Formulierungsregeln für Formular-Valididierungsfehler zu beachten (siehe Meldungskonzept: Formulierungsregeln für Formular-Validierungsfehler).

[Grafik Falsches Eingabeformat]

ℹ️ Änderung in Bold dargestellt

Der gesamte Inhalt der Seite wurde neu veröffentlicht.

ℹ️ Änderung in Bold dargestellt

Der gesamte Inhalt der Seite wurde neu veröffentlicht. Die Formulierungsregeln sind im Meldungskonzept zu finden.

ℹ️ Änderung in Bold dargestellt

Der gesamte Inhalt der Seite wurde neu veröffentlicht.

ℹ️ Änderung in Bold dargestellt

Der gesamte Inhalt der Seite wurde neu veröffentlicht.

ℹ️ Änderung in Bold dargestellt

Aufbau Radiobutton mit Grafik

Bei Radion Buttons mit Grafik, ist die Grafik linksbündig unter dem Textlabel zu platzieren.

[Grafik Aufbau Radiobutton mit Grafik wurde hinzugefügt]

1. Radiobutton
2. Text Label
3. Gruppentitel
4. Grafik

Verhalten

Radio Buttons ermöglichen immer nur die Auswahl eines Elements einer Gruppe gleichzeitig. Wird eine andere Option ausgewählt, so wird die vorherige wieder inaktiv.

Standardmäßig sind Radio-Button-Gruppen initial mit einem vom Teilprojekt zu definierenden Wert vorbefüllt (in der Regel ist dies der erste Wert in der Gruppe). Falls keine Vorbefüllung vorhanden sein soll, ist dies in den Userstories zu definieren.
Nach dem ersten Aktivieren einer der Einträge kann nur über den Undo-Button zum Zustand “alle unbefüllt” zurückgekehrt werden.

Radiobuttons können neben dem Textlabel auch zusätzlich eine Grafik enthalten. Diese muss als Layoutgrafik definiert werden. Der Inhalt der Grafik muss aus dem Textlabel hervorgehen. (Aufbau und Verhalten siehe Radio Button Grafik)

Ein Radio-Button kann durch Klicken auf das Icon, das Label und, falls vorhanden, der Grafik aktiviert werden.

Ein Radio-Button kann nicht ohne sichtbares Textlabel verwendet werden. Die Klickfläche hat eine minimal Seitenlänge von 40px.

Mehrere Radio-Buttons werden zu einer Gruppe kombiniert, die mit einem sichtbaren Label definiert sein muss. Es handelt sich visuell um eine Überschrift des Typs “Label” in der Farbe Schwarz. Der Abstand zu anderen Elementen neben der Gruppe muss ausreichend sein, dass die Gruppe klar als solche zu erkennen ist (mind 24px).

Lange Gruppen können auch zweispaltig dargestellt werden.

[Grafik Gruppierung]

[Grafik Zweispaltige Gruppe]

Pflicht-Radiobutton-Gruppen sind mit “*” (Sternchen”) nach dem TextLabel (Gruppenlabel) markiert.

[Grafik Radiobutton-gruppen mit Pflichtfeldkennzeichnung]

Bei Read-Only-Feldern gibt es keine visuelle Pflichtfeldauszeichnung, auch wenn diese im Backend ggf. als Pflichtfelder geprüft werden.

[Grafik Read-Only Gruppe]

Responsives Verhalten Radiobutton mit Grafik

Die Darstellungsart und Umbruchpunkte der Radiobuttongruppen mit Grafik gleicht die der normalen Radiobuttongruppen (siehe oben Responsives Verhalten Radiobutton).

Das Seitenverhältnis der Grafik wird immer beibehalten und ist 5:3

[Grafik Radiobutton-Gruppe mit Grafik ab einer Inhaltsbreite von 1424 und höher wurde hinzugefügt]

Bei einer Inhaltsbreite unter 1424 Pixeln gilt:

• Breite der Grafik beträgt 4 Spalten. Es können also bis zu 3 Felder nebeneinander platziert werden.

[Grafik Radiobutton-Gruppe mit Grafik ab einer Inhaltsbreite unter 1424 Pixeln wurde hinzugefügt]

Ab einer Inhaltsbreite unterhalb 761 Pixeln gilt:

• Breite der Grafik beträgt 6 Spalten. Es können also bis zu 2 Felder nebeneinander platziert werden.

[Grafik Radiobutton-Gruppe mit Grafik ab einer Inhaltsbreite unter 761 Pixeln wurde hinzugefügt]

Ab einer Inhaltsbreite unter 440 Pixeln gilt:

• Breite der Grafik beträgt 1 Spalten. Es können also keine Felder nebeneinander platziert werden.

[Grafik Radiobutton-Gruppe mit Grafik ab einer Inhaltsbreite unter 440 Pixeln wurde hinzugefügt]

Zustände

[Grafik Radiobuttons einzeilig und zweizeilig]

[Grafik Radiobutton mit Fehler]

[Grafik Zustände Radiobuttons mit Grafik wurde hinzugefügt]

[Grafik Zustände Radiobuttons mit Grafik und fehlerhaftem Eintrag wurde hinzugefügt]

ℹ️ Änderung in Bold dargestellt

Überschrift-Ebenen

H1: Titel des Wizards
H3: Sidebar-Überschrift
H2: Formulartitel

ℹ️ Änderung in Bold dargestellt

Überschrift-Ebenen innerhalb eines Verfahrens

H1: Titel des Verfahrens; visuell H3
H3: Sidebar-Überschrift
H4: Anzahl Einträge in der Sidebar; visuell Schrifttyp “Subhead”
H2: Formulartitel
H3: Zwischensektionen im Formular (Accordions)

ℹ️ Änderung in Bold dargestellt

Sortierung

Für sortierte Wertelisten wie bspw. die Inhalte von Tabellen, Listen oder Baumstrukturen oder die Inhalte von Ausklapplisten an Auswahlfeldern gelten folgende Standardsortierregeln (abweichendes Verhalten muss in User Stories definiert werden):

• Einträge ohne Zeitangaben werden alphanumerisch aufsteigend nach ISO 14651 /UCA case-insensitive sortiert. (mehr Informationen siehe Wikipedia Artikel: Unicode Collation Algorithm)
• Einträge mit Zeitangaben werden chronologisch absteigend sortiert (neue Einträge zuerst).
• Als sekundäres Sortierkriterium wird standardmäßig die verknüpfte Datenbank-ID in absteigender Sortierung verwendet, welche immer eindeutig ist (damit ist sekundär in der Regel nach dem Anlagezeitpunkt des Objekts sortiert: neuestes zuerst). Dieses sekundäre Sortierkriterium kommt nur dann zum Tragen, wenn zwei Objekte, für das Attribut nach dem sortiert wird, den gleichen Wert besitzen. In User Stories kann auch ein anderes zweites oder drittes Sortierkriterium definiert werden, die Datenbank-ID wird dann als letztes Sortierkriterium verwendet.

Bei Elementen mit Primär- und Sekundärinformation (z. B. in Ausklapplisten von Auswahlfeldern oder bei Listen bzw. Baumstrukturen) wird standardmäßig nach der primären Information sortiert.

[Grafik Sortierung]

ℹ️ Änderung in Bold dargestellt

Einleitung

Eine Infobox wird zusammen mit einem Info-Button oder einem Kalendereintrag eingesetzt. Der Info-Button / Kalendereintrag öffnet die Infobox und die Infobox legt sich dann über den bisherigen Bildschirminhalt.

[Grafik Infobox]

Positionierung (Fensterbreite mindestens 448px)

Die Infobox öffnet sich immer im sichtbaren Bereich des Fensters und soll mit einer Ecke den Info-Button / Kalendereintrag berühren (horizontal und vertikal jeweils 8px vom Rand des Buttons/Kalendereintrags versetzt).

[Grafik Positionierung der Infoboxen wurde hinzugefügt]

Wenn horizontal zu beiden Seiten des Info-Buttons genug Platz für die Infobox vorhanden ist, soll sich die Infobox zur rechten Seite öffnen. Wenn vertikal in beide Richtungen ausreichend Platz vorhanden ist, soll sich die Infobox nach unten hin öffnen.

Wenn der Abstand vom Info-Button zum Fensterrand in der Vertikalen oder Horizontalen nicht ausreicht, die Fenster-Breite aber mindestens 448px beträgt, darf die Infobox den Info-Button partiell oder vollständig überlagern.

ℹ️ Änderung in Bold dargestellt

Auswirkungen der Fensterhöhe und Scrollverhalten

Wird bei Fensterhöhen über 720px gescrollt, so ist die Seite nicht als ganzes scrollbar, sondern nur der Inhaltsbereich des Formulars. Im unwahrscheinlichen Fall einer sehr langen Schrittnavigation, wäre auch diese hier separat scrollbar. Beide Elemente (Schrittnavigation und Formular) haben dann je eine einzelne Scrollbar innerhalb. Alle Elemente auf der Seite bleiben ansonsten beim Scrollen fix stehen.

[Grafik Fensterhöhe über 720 Pixel wurde hinzugefügt]

Wird bei Fensterhöhen unter 720px gescrollt, so hat nur noch die komplette Seite eine Scrollbar und dafür sind die Inhaltsbereiche von Formular und Schrittnavigation nicht mehr einzeln scrollbar. Entsprechend wird nur noch eine Seitenscrollbar statt der beiden Scrollbars bei Schrittnavigation und Formular angezeigt. Nur die Headerleiste bleibt dann beim Scrollen fix stehen.

[Grafik Fensterhöhe unter 720 Pixel wurde hinzugefügt]

Für die Definition des Scrollverhaltens innerhalb des Formularbereichs (Stickyness von Formular-Header und -Footer), siehe Wizard: Verhalten.

ℹ️ Änderung in Bold dargestellt

Auswirkungen der Fensterbreite innerhalb eines Verfahrens

Es gelten gleiche Elementbreiten wie außerhalb eines Verfahrens mit der Ergänzung: 

• VERFAHRENSHEADER: Breite entspricht bei allen Fenstergrößen immer der kompletten Fensterbreite

Auswirkungen der Fensterhöhe und Scrollverhalten

Auswirkungen der Fensterhöhe und Scrollverhalten außerhalb eines Verfahrens

Ab einer Fensterhöhe unter 800px verringert sich der vertikale Abstand von Headerleiste zu Pfadnavigation von 16px auf 0px. 

[Grafik Unter 800 Pixeln]

Wird bei Fensterhöhen über 720px gescrollt, so ist der Inhaltsbereich der Liste und der Inhaltsbereich des Formulars separat voneinander scrollbar. Es wird daher keine Seitenscrollbar, sondern je eine Elementscrollbar am Rand des Listen- sowie Formularinhalts angezeigt. Alle anderen Elemente auf der Seite bleiben beim Scrollen fix stehen. 

[Grafik Über 720 Pixeln]

Wird bei Fensterhöhen unter 720px gescrollt, so ist nur noch die Komplettseite scrollbar. Die einzelnen Scrollbars bei Formular und Liste werden ausgeblendet und stattdessen die Seitenscrollbar angezeigt. Nur die Headerleiste bleibt dann beim scrollen fix stehen.

[Grafik Unter 720 Pixeln]

Für die Definition des Scrollverhaltens innerhalb des Formularbereichs sowie von Listen (Stickyness von Formular-Header und -Footer und Listenpaginierung), siehe Formular und Liste.

Auswirkungen der Fensterhöhe und Scrollverhalten innerhalb eines Verfahrens

Ab einer Fensterhöhe unter 960px verringert sich der vertikale Abstand von Headerleiste zu Pfadnavigation von 16px auf 0px. 

Ist der Hauptinhaltsbereich unterhalb des Verfahrensheaders ([Fensterhöhe] minus [Höhe Headerleiste] minus [Höhe Verfahrensheader]) größer als 680px hoch und es wird gescrollt, so ist der Inhaltsbereich der Liste und der Inhaltsbereich des Formulars separat voneinander scrollbar. Es wird je eine Einzelscrollbar am Rand des Formularinhalts sowie der Liste angezeigt. Alle anderen Elemente auf der Seite bleiben beim Scrollen fix stehen.

[Grafik Über 680 Pixeln]

[Grafik Unter 680 Pixeln]

Ist der Hauptinhaltsbereich unterhalb des Verfahrensheaders ([Fensterhöhe] minus [Höhe Headerleiste] minus [Höhe Verfahrensheader]) unter 680px hoch und es wird gescrollt, so ist nur noch die komplette Seite als ganzes scrollbar und eine entsprechende Scrollbar am Seitenrand wird angezeigt. Dafür werden keine Einzelscrollbars mehr am Inhaltsbereich von Formular und Liste angezeigt. Nur die Headerleiste und die Pfadnavigation bleibt dann beim scrollen fix stehen.

Die Pfadnavigation liegt zunächst auf hellem Grund. Sobald jedoch gescrollt wird und der Verfahrensheader den sichtbaren Bereich verlässt, wird die Pfadnavigation invertiert (siehe Pfadnavigation: Verhalten) und bleibt am oberen Rand sticky. Auch wenn sich der Pfadnavigation-Inhalt nur über die 12 Seitenlayoutspalten erstreckt, wird das Fenster dann auf Höhe der Pfadnavigation auf kompletter Breite blau eingefärbt.

[Grafik Dunkle Pfadnavigation]

Für Verhalten des Verfahrensheaders abhängig von der Fensterhöhe siehe Verfahrensheader.

Für die Definition des Scrollverhaltens innerhalb des Formularbereichs sowie von Listen (Stickyness von Formular-Header und -Footer und Listenpaginierung), siehe Formular und Liste.

ℹ️ Änderung in Bold dargestellt

Aufbau Wizard Inhaltsbereich (Formular)

Header und Footer des Wizard-Formulars werden bei ausreichender Fensterhöhe sticky dargestellt. Es gelten hier die gleichen Definitionen, wie bei Standardformularen (siehe Formular).

ℹ️ Änderung in Bold dargestellt

Höhe der Tabelle/Liste und Scrollbarkeit

Bei nicht-paginierten Tabellen/Listen (bis 10 Einträge) entspricht deren Höhe immer der summierten Eintragshöhe.

Bei paginierten Tabellen/Listen (ab 11 Einträge) muss sichergestellt werden, dass sich er Paginations-Footer immer an der gleichen Stelle befindet und beim Wechseln zwischen Seiten nicht in der Y-Position springt. Daher haben paginierte Tabellen-/Listen immer eine fixe Höhe. Es wird dabei unterschieden zwischen Tabellen/Listen außerhalb von Formularen und Tabellen innerhalb von Formularen. Listen kommen innerhalb von Formularen nicht vor. Der Paginations-Footer ist in der Regel sticky, bis eine gewisse Tabellen-/Listenhöhe unterschritten wird (siehe Tabelle: Verhalten Tabellen-Footer (Fußzeile) mit Paginierung und Liste: Verhalten des Listen-Footers (Fußzeile) mit Paginierung).

[Grafik Scrollverhalten und Paginierung einer Tabelle]

[Grafik Scrollverhalten und Paginierung einer Tabelle auf kleinem Bildschirm]

Außerhalb von Formularen gilt:

• Tabellen/Listen mit bis zu 10 Einträgen sind nicht paginiert. Ihre Höhe entspricht der Summe Eintragshöhe. Ist im Seitenlayout zu wenig Platz in der Horizontalen zur Darstellung aller Einträge verfügbar, so wird die Liste scrollbar.
• Tabellen/Listen mit über 10 Einträgen werden paginiert. Die Tabellen-/Listenhöhe passt sich dann immer dem maximal auf der Seite verfügbaren Platz an. Bei großen Fensterhöhen kann so ein nicht fokussierbarer Weißraum zwischen dem letzten Eintrag auf einer Seite und dem Paginationsfooter am unteren Seitenrand entstehen. Reicht die Tabellen-/Listenhöhe nicht aus, um alle Einträge auf einer Seite darzustellen, so wird die Tabelle/Liste bzw. die Seite scrollbar (für Details zum Scrollverhalten siehe auch Seitentypen Formular mit Schnellnavigations-Sidebar oder Tabelle/Liste/Baum/Kalender: Verhalten beim Scrollen der Seite).

Innerhalb von Formularen gilt:

• Bei bis zu 10 Einträgen werden Tabellen nicht paginiert. Die Tabellen-/Listenhöhe entspricht der summierten Höhe aller Einträge. 
• Ab 11 Einträgen werden Tabellen paginiert. Die Tabellenhöhe ist fix und entspricht dem 5,5 fachen der Eintragshöhe.

Tastaturbedienung

• Tab fokussiert das erste interaktive Element der Paginierung.
• Nächster Tab springt zum nächsten interaktiven Element der Paginierung.
• Enter löst die fokussierte Aktion aus.
• Der Fokus bleibt nach Seitenwechsel auf dem ausgelösten Element, es ist jedoch nicht mehr interaktiv. Wenn der Listen/Tabellenfooter sticky ist (bei ausreichender Höhe), dann wird durch einem Seitenwechsel über den Paginierungsfooter die Scrollposition im Listen/Tabellen-Inhaltsbereich der neu geöffneten Seite zurückgesetzt, d. h. der oberste Listen- bzw. Tabelleneintrag auf der neu geöffneten Seite ist anschließend sichtbar. Falls der Listen/Tabellenfooter (auf Grund geringer Listen/Tabellenhöhe unter 400px) nicht mehr sticky ist, dann wird die Scrollposition beibehalten, damit der Tastaturfokus, welcher im Footer verbleibt, nicht aus dem sichtbaren Bereich verschwindet.
• Drücken der Home-Taste setzt den Tastaturfokus auf die ersten Seite.
• Mit End-Taste wird der Tastaturfokus auf die letzte Seite gesetzt.
• Für Tastaturbedienung und Fokussetzung innerhalb des “Ausgeblendete Seiten anzeigen”-Menüs siehe Pop-Up Menü: Tastaturbedienung.
• Mit Tab-Taste kann der Ladezustand im Inhaltsbereich der Tabelle/Liste fokussiert werden.

Mausbedienung

• Klick mit linker Maustaste löst die Aktion aus.
• Der Fokus bleibt nach Seitenwechsel auf dem ausgelösten Element, es ist jedoch anschließend nicht mehr klickbar. Wenn der Listen/Tabellenfooter sticky ist (bei ausreichender Höhe), dann wird durch einem Seitenwechsel über den Paginierungsfooter die Scrollposition im Listen/Tabellen-Inhaltsbereich der neu geöffneten Seite zurückgesetzt, d. h. der oberste Listen- bzw. Tabelleneintrag auf der neu geöffneten Seite ist anschließend sichtbar. Falls der Listen/Tabellenfooter (auf Grund geringer Listen/Tabellenhöhe unter 400px) nicht mehr sticky ist, dann wird die Scrollposition beibehalten, damit der Tastaturfokus, welcher im Footer verbleibt, nicht aus dem sichtbaren Bereich verschwindet.
• Für Tastaturbedienung und Fokussetzung innerhalb des “Ausgeblendete Seiten anzeigen”-Menüs siehe Pop-Up Menü: Mausbedienung.
• Klick mit linker Maustaste auf den Ladezustand einer Tabellen-/Listenseite fokussiert diesen.

ℹ️ Änderung in Bold dargestellt

Verhalten Tabellen-Footer (Fußzeile) mit Paginierung

Der Tabellenfooter erscheint, wenn eine Paginierung benötigt wird, weil die Tabelle zu viele Zeilen beinhaltet.

Der Tabellenfooter ist im Regelfall sticky und somit (sofern vorhanden) immer am Ende des Tabellenbereichs sichtbar. Ab einer Tabellenhöhe unter 400px ist die Paginierungsfußzeile nicht mehr sticky, scrollt mit der Gesamttabelle mit und ist unter dem jeweils letzten Tabelleneintrag positioniert.

Details siehe Paginierung.

[Grafik Tabelle mit Footer]

[Grafik Responsive Version]

ℹ️ Änderung in Bold dargestellt

Aufbau

[Grafik Liste mit Suche, Filter, Neuanlage und Paginierung wurde aktualisiert]

1. Neuanlage-Button (optional)
2. Suche (optional)
3. Filter (optional)
4. Text “[Anzahl] Einträge” (nicht fokussierbar)
5. Sortierparameter
6. Sortierrichtung
7. Erster Listeneintrag
8. Geöffneter Eintrag
9. Fußzeile mit Paginierung (optional, je nach Menge der Listeneinträge)

Verhalten

Listen bestehen immer aus einem Inhaltsbereich und der darüberliegenden Sortierfunktion. Wie auch bei Tabellen, können sich oberhalb von Listen außerdem Such- und Filtermöglichkeiten befinden, mit denen die Anzahl der angezeigten Inhalte reduziert werden kann (siehe Suchfeld und Filter).

Die Tabreihenfolge ist:

1. Neuanlage-Button (optional)
2. Suche (optional)
3. Filter (optional)
4. Text “[Anzahl] Einträge” (nicht fokussierbar)
5. Sortierparameter
6. Sortierrichtung
7. Erster Listeneintrag
8. Fußzeile mit Paginierung (optional, je nach Menge der Listeneinträge)

Jede Liste trägt eine visuell nicht sichtbare programmatische Beschriftung. Diese sollte identisch sein mit der visuell sichtbaren Beschriftung, welche die Liste inhaltlich beschreibt. Die sichtbare Beschriftung kann sein:

• Seitentitel (bei Listen auf Modul-Startseiten bzw. Modul-Unterseiten, wenn unter dem Seitentitel keine Tabs vorkommen)
• Beschriftung des aktiven Tabs (bei Listen auf Modul-Startseiten bzw. Modul-Unterseiten mit Tabs unter dem Seitentitel)
• Schnellnavigations-Titel (bei Listen in der Schnellnavigations-Sidebar)
• Akkordeontitel (bei Listen in Formularen, die sich direkt einem Akkordeon unterordnen)

Der Text “[Anzahl] Einträge” oberhalb der Liste ist nur verpflichtend zu verwenden, wenn sich Such- oder Filtermöglichkeiten über der Liste befinden. Falls die Anzahl 0 oder eine beliebige Zahl über 1 ist, wird das Wort “Einträge” verwendet. Falls die Anzahl genau 1 ist, wird statt “Einträge” das Wort “Eintrag” verwendet. Die [Anzahl] der Einträge ist als H3 zu kennzeichnen (visuell und semantisch).

Listen dürfen nur außerhalb von Formularen verwendet werden und dienen beispielsweise dem Wechsel zwischen Objektdetailformularen im Seitentyp “Unterseite eines Moduls: Formular mit Schnellnavigationssidebar”.
Soll innerhalb von Formularen eine Auflistung von Unterobjekten angezeigt werden, so sind dafür Tabellen oder ggf. Karten zu verwenden.

[Grafik Liste auf grauem Hintergrung]

[Grafik Liste auf weißem Hintergrund]

Verhalten des Listen-Footers (Fußzeile) mit Paginierung

Der Listenfooter mit Paginierung erscheint, sobald in einer Liste eine bestimme Eintragsanzahl überschritten wird.

Der Listenfooter ist im Regelfall sticky und somit (sofern vorhanden) immer am Ende des Listenbereichs sichtbar. Ab einer Listenhöhe unter 400px ist die Paginierungsfußzeile nicht mehr sticky, scrollt mit der Gesamtliste mit und ist unter dem jeweils letzten Listeneintrag positioniert.

Details siehe Paginierung.

ℹ️ Änderung in Bold dargestellt

Tabs (M) - nicht ausreichender Platz

Sollte es nicht genug Platz für alle Reiter geben wird die Tableiste angeschnitten und es erscheinen links und rechts Pfeile zur Navigation.

Ist der erste/letzte Reiter vollständig sichtbar wird der entsprechende Pfeil inaktiv.

Bei Mouse-Hover auf den Pfeilen wird im Tooltip folgendes angezeigt:

• links: "Nach links scrollen"
• rechts: "Nach rechts scrollen"

Wird der Pfeil links oder rechts ausgelöst scrolled die Tab-bar so, dass der nächste Reiter vollständig zu sehen ist. 
Gleiches gilt, wenn ein Reiter fokussiert/geklickt wird, der nicht komplett zu sehen ist.

[Grafik Pfeilnavigation]

[Grafik Pfeilnavigation mit Tooltip wurde hinzugefügt]

ℹ️ Änderung in Bold dargestellt

Menü-Buttons

Die interaktiven Icon-Elemente ermöglichen es, weitere Unterbereiche der Applikation einzublenden. Alle diese Unterbereiche (siehe Overlaymenü) werden nach Erscheinen an der Unterkante der Headerleiste angezeigt. Die Icon-Buttons müssen aussagekräftige Titel haben:

1. “Hauptmenü”
2. “Suche”
3. “Kalender”
4. “Meldungen”
5. “[Name eingeloggte Person]”
6. “Profil”
7. “Hilfe”

Die Menüelemente werden als tertiäre Icon-Buttons umgesetzt, geöffnete Menü-Elemente müssen dabei mit einem Status gekennzeichnet sein, der es bei Screenreaderausgabe ermöglicht, diese als geöffnet wahrzunehmen.

ℹ️ Änderung in Bold dargestellt

Verhalten

Das Wertebereichs-Feld ist stets in zwei Unterelemente geteilt: Eines, das den Von- bzw. Startwert angibt und ein zweites was den Bis- bzw. Endwert angibt.

Es können folgenden Eingabe-/Auswahlfeldtypen vorkommen. Dabei müssen von- und bis-Feld jeweils dem gleichen Typen entsprechen:

• Datumsfeld
• Uhrzeitsfeld
• Einzeiliges Eingabefeld mit numerischem Inhalt (mit oder ohne Einheit)
• Einzeiliges Eingabefeld
• Einfach-Auswahlfeld

Beispiele: 

• Zeitraum von 01.01.2022 bis 31.12.2022
• Streitwert in € von 2.000,00 bis 6.000,00
• AKA in % von 75 bis 100
• Uhrzeit von 09:00 bis 16:00
• Buchstaben von A bis F

[Grafik Basis-Elemente]

[Grafik Wertebereichsfeld mit Ausklappliste]

[Grafik Wertebereichsfeld responsive Darstellung]

Zeichenbegrenzung

Bei Wertebereichsfeldern des Inhaltstyps “Einzeiliges Eingabefeld” (sowohl für numerischem als auch für textuellen Inhalt) darf eine maximal erlaubte Zeichenzahl definiert sein - allerdings muss diese immer für beide Feldteile gleich sein. Ein Zeichenzähler wird bei Wertebereichsfeldern visuell nicht am Feld angezeigt – die begrenzte Zeichenzahl muss allerdings aus dem Hinweistext des Feldes hervorgehen. Falls an dem Wertebereichsfeld sowohl ein fachlicher Hinweis als auch einer zu Eingabeformat bzw. Zeichenlimit benötigt wird, so wird die Zeichenlimitierung mit einem Gedankenstrich getrennt dem fachlichen Hinweis nachgestellt. Explizite Formatbeispiele wie beispielsweise “TT.MM.JJJJ” oder “Wert zwischen 1 und 100 ohne Nachkommastellen” machen eine zusätzliche Nennung des Zeichenlimits obsolet.
Bei Erreichen der maximal erlaubten Zeichenzahl wird keine weitere Eingabe zugelassen. Bei jedem weiteren Tastenanschlag (keydown) ertönt ein akustisches Signal: Fehlerton (siehe akustische Signale).

Wenn keine maximale Zeichenzahl definiert ist und die eingegebene Zeichenanzahl das technisch definierte Zeichenlimit überschreitet, gilt das beim Einzeiligen Eingabefeld definierte Standardverhalten.

[Grafik Wertebereichsfeld mit Zeichenbegrenzung wurde hinzugefügt]

ℹ️ Änderung in Bold dargestellt

Platzhalter im Akkordeon

Wenn ein Akkordeonabschnitt aus fachlichen Gründen noch nicht bearbeitbar ist, wird statt dem eigentlichen Akkordeoninhalt nur ein Platzhaltertext (ohne weitere Inhalte) angezeigt. Sobald der Abschnitt bearbeitbar wird, wird der Platzhaltertext durch den entsprechenden Inhalt ersetzt.
Formulierungsregel: „Hinweis: [Begründung, warum der Abschnitt nicht bearbeitet werden kann]”
Beispiel: „Hinweis: Terminsbesetzung kann erst bearbeitet werden, wenn ein Aktenzeichen ausgewählt wurde.”
Der Platzhaltertext ist fokussierbar. Der Screenreader gibt bei Fokuserhalt den Platzhaltertext aus.

[Grafik "Akkordeon mit Platzhalter" wurde hinzugefügt]

[Grafik "Beispiel Platzhaltertext" wurde hinzugefügt]

-------

• Pfeiltasten nach oben/unten wechseln zum nächsten Akkordeon-Eintrag.
• Tabulatortaste wechselt zum ersten Inhalt des göffneten Akkordeon-Eintrag, (bei geschlossenem Akkordeon-Eintrag zum nächsten Akkordeon-Eintrag)
• Bei geöffnetem Akkordeon kann mit Tab-Taste der Platzhalter (wenn vorhanden) fokussiert werden. Erneutes Drücken der Tab-Taste bewegt den Fokus zum nächsten interaktiven Element.
• Enter oder Leertaste öffnet die Sektion (falls geschlossen) oder schließt die Sektion (falls geöffnet).
• Der Fokus verbleibt auf der aktivierten Sektion.

• Klick mit linker Maustaste auf einen Akkordeonneintrag öffnet diesen (falls er geschlossen ist) oder schließt diesen (falls er geöffnet ist).
• Klick mit linker Maustaste auf den Platzhalter fokussiert diesen.

ℹ️ Änderung in Bold dargestellt

Verhalten

Jede Tabelle besitzt einen Kopfbereich (Details siehe Tabellenheader), wo zu jeder Spalte eine kurze sowie aussagekräftig Spaltenüberschrift enthalten ist und einen Inhaltsbereich (Details siehe Tabelleninhalt). Bei langen Tabellen kommt noch eine Fußzeile dazu, welche die Navigation der Paginierung enthält (Details siehe Tabellenfooter mit Paginierung).

Jede Tabelle trägt eine visuell nicht sichtbare programmatische Beschriftung. Diese sollte identisch sein mit der visuell sichtbaren Beschriftung, welche die Tabelle inhaltlich entweder direkt (z. B. Tabellenüberschrift) oder im Kontext (z. B. Seitentitel) beschreibt. Die sichtbare Beschriftung kann sein:

• Seitentitel (bei Tabellen auf Modul-Startseiten bzw. Modul-Unterseiten, wenn unter dem Seitentitel keine Tabs vorkommen)
• Beschriftung des aktiven Tabs (bei Tabellen auf Modul-Startseiten bzw. Modul-Unterseiten mit Tabs unter dem Seitentitel)
• Akkordeontitel (bei Tabellen in Formularen, die sich direkt einem Akkordeon unterordnen)
• Tabellenüberschrift (in Formularen bei Tabellen, die sich nicht direkt unter einem Akkordeon befinden)

Oberhalb von Tabellen können sich außerdem Such- und Filtermöglichkeiten befinden, mit denen die Anzahl der angezeigten Inhalte reduziert werden kann. 
(siehe Suchfeld und Filter) 
(“Such- und Filterergebnisanzeige” in der Tabelle siehe unten Verhalten bei Durchsuchen und Filtern von Tabelleninhalten)

Die Elementreihenfolge ist wie folgt (definiert die Vorlesereihenfolge für Screenreader und Tab-Reihenfolge, falls fokussierbare Elemente enthalten sind):

1. Ansichtswechsel-Schalter (optional)
2. Neuanlage-Button (optional)
3. Suche (optional)
4. Filter (optional)
5. Text “[Anzahl] Einträge” (nicht fokussierbar)
6. Funktionsbutton (optional - aktuell nur im Modul KTR zur Terminsfindung über Tabellen zulässig)
7. Menu-Button “Tabellen-Einstellungen”
8. Tabellen-Header
9. Tabelleninhalt
10. Tabellen-Footer (optional, je nach Eintragszahl)
11. Mehrfachauswahl-Fußzeile (optional)
12. Hinzufügen-Button (optional)

Der Text “[Anzahl] Einträge” oberhalb der Tabelle ist immer verpflichtend anzuzeigen (in Formularen oder Hauptseiten, mit oder ohne Such- und Filtermöglichkeiten).
Falls genau ein Eintrag vorhanden ist, wird das Wort “Eintrag” statt “Einträge verwendet.
Der Text “[Anzahl] Einträge” entspricht visuell dem Schrifttyp “Subhead”. Die semantische Überschriftenauszeichnung variiert je nach Seitentyp (siehe entsprechender Seitenaufbau).

Wird eine Tabelle innerhalb eines Formulars angezeigt, so ist der Hinzufügen-Button immer direkt unterhalb der Tabelle positioniert.
Die Mehrfachselektions-Fußzeile (falls vorhanden) befindet sich bei Tabellen in Formularen immer unterhalb der Tabellenfußzeile oder, falls keine Paginierung vorhanden, unter dem letzten Tabelleneintrag. Details siehe Mehrfachauswahl-Footer.

ℹ️ Änderung in Bold dargestellt

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.

[Grafik Standardverhalten für Unterformulare wurde hinzugefügt]

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.

(...)

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)

[Grafik "Entfernen-Button im Read-Only State" wurde hinzugefügt]

ℹ️ Änderung in Bold dargestellt

Sortierung von Gruppen

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)

[Grafik "Elementgruppe im Read-Only Zustand" wurde hinzugefügt]

ℹ️ Änderung in Bold dargestellt

Verhalten

Pflichtfelder sind mit “*” (Sternchen”) nach dem Label markiert. Bei Read-Only-Feldern gibt es keine visuelle Pflichtfeldauszeichnung, auch wenn diese im Backend ggf. als Pflichtfelder geprüft werden.

Die Auswahlfeldbezeichnung sollte so kurz und präzise wie möglich formuliert sein. Sollte ein Label dennoch länger sein müssen, so bricht es um und wird mehrzeilig.

[Grafik Einzeiliges Label]

[Grafik Mehrzeiliges Label]

Neben einer Checkbox zur Auswahl eines Eintrags kann jeder Eintrag einer Auswahlliste bestehen aus: 

• Text: Einzelwert bzw. Einzelbegriff.
• Icon mit Text: Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.
• Avatar mit Text: Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.
• Primär- und Sekundärtext (Beispiel Raumauswahl: Angezeigt wird die Bezeichnung des Raumes in Zeile 1; Die Gebäudeart und Straße in Zeile 2).
• Primär- und ggf. Sekundärtext mit zusätzlicher Bildmarke (Beispiel: Icon oder Personen mit Avatar oder Foto; daneben Nachname und Vorname in erster Zeile, Amts-/Dienstbezeichnung in zweiter Zeile). Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.

[Grafil Typen von Einträgen wurde hinzugefügt]

Nach getätigter Auswahl von mehreren Werten werden diese mit Semikolon voneinander getrennt im Auswahlfeld dargestellt (siehe Schriften: Trennzeichen bei Listung mehrerer Werte) Beispiele:

• Registerzeichen: O; T; AR
• Justizpersonen: Witt, Emma; Singer, Fritz

Dabei wird bei Dropdowninhalten mit primärer und sekundärer Information immer nur die Primärinformation beachtet.

[Grafik Beispiel für Trennung durch Semikolon]

[Grafik Beispiel für den Gebrauch des Kommas in einem Attribut]

Zustände

[Grafik Mehrfachauswahlfeld]

[Greafik Geöffnete Ausklapplisten]

[Grafik Zustände der Einträge wurde aktualisiert]

ℹ️ Änderung in Bold dargestellt

Verhalten von Tabellenzeilen/-inhalten

Eine Tabellen-Zelle kann folgende Elemente enthalten: 

• Checkbox / Radio-Button (interaktiv): Details siehe unten im Abschnitt “Radio Button und Checkbox-Spalten”

----------

Checkbox-/Radio-Button-Spalten

Checkbox- oder Radiobutton-Spalten werden immer am Zeilenbeginn platziert. Dabei bleibt jedoch die darauf folgende Spalte der Rowheader.
Die Beschriftung sowie der Tooltip von Radio-Buttons oder Checkboxen in Tabellen lautet jeweils “[Objektbezeichnung]” und die Objektbezeichnung wird dabei jeweils mit dem Inhalt des Row-Headers (zweite Spalte) der entsprechenden Zeile befüllt (z. B. mit dem Name bei einer Tabelle mit Personen).
Einen Sonderfall bildet die "Alle auswählen"-Checkbox im Spaltenheader: Details zu deren Beschriftung siehe Tabellenheader.
Bei Radiobutton-Spalten erhält jeder Radiobutton mit Tab den Fokus (nicht nur der ausgewählte). Bei Fokuserhalt einer Checkbox- bzw. eines Radiobuttons wird jeweils der Spaltentitel “Auswahl” mit ausgegeben.
Details zur Spaltentitel von Checkbox-/Radiobutton-Spalten siehe Tabellenheader.

----------

Verhalten Tabellen-Header

Spalten mit Checkboxen oder Radiobuttons zur Selektion ganzer Tabellenzeilen werden immer als eigene Spalte dargestellt und ganz links platziert.
Spalten mit Radiobuttons tragen den Spaltentitel “Auswahl”.
Der Spaltentitel einer Checkbox-Spalten enthält an Stelle einer textuellen Beschriftung immer eine Checkbox, um alle enthaltenen Einträge aus- bzw. abzuwählen. Diese Checkbox trägt die Beschriftung sowie den Tooltip "Alle Einträge" bzw. "Alle Einträge auf aktueller Seite" (bei paginierter Tabelle).
Bei Navigation in der darunterliegenden Tabelle und Fokuserhalt eines Radiobuttons bzw. einer Checkbox zur Auswahl eines einzelnen Tabelleneintrags wird die Spaltenbeschriftung “Auswahl” jeweils mit ausgegeben. Details zu deren Verhalten und Beschriftung siehe Tabelleninhalt.

ℹ️ Änderung in Bold dargestellt

Verhalten von Tabellenzeilen/-inhalten

• Badge: Zellen mit Badges kommen meist zur Darstellung von Statusinformationen zum Einsatz - im Regelfall in einer eigenen Tabellenspalte. Falls auf Grund fachlicher Besonderheiten mehr Aufmerksamkeit auf bestimmte einzelne Werte oder Attribute in der Tabelle gezogen werden soll, so können zu diesem Zweck auch in Spalten mit Text, Link oder numerischem Inhalt zusätzliche Badges in den Zellen ergänzt werden (nicht zulässig sind Zusatzbadges in Spalten, wo mehrere mit Semikolon voneinander getrennte Attribute pro Zelle angezeigt werden könnten). Zusatzbadges werden in Zellen immer unter dem eigentlichen Zelleninhalt in einer eigenen Zeile platziert (Ausnahme: Bei Auskunfts- und Verfahrenssperre oberhalb, siehe Tabellenzeilen-Hervorhebung). Der Haupt-Zelleninhalt kann dann nur noch einzeilig dargestellt werden. Die Ausrichtung von Zelleninhalt und Badge richtet sich nach dem Eintragstyp (z. B. Rechtsbündig bei numerischen Inhalten, siehe auch Textausrichtung). Bei Fokuserhalt einer solchen Zelle wird der Badge-Text oder Alternativtext nach dem Eintragstext vorgelesen (Ausnahme: Verfahrens- oder Auskunftssperre). Ist der Text in der Inhaltszeile länger als im verfügbaren Platz darstellbar, so wird er am Ende der Zeile mit “...” abgekürzt - der Badge in der Zeile darunter (bzw. in oben beschriebenen Ausnahmefällen darüber) bleibt weiterhin sichtbar. Details siehe unten “Verhalten bei langem Zellen-Inhalt.”

------------

Zellen mit mehreren Attributen

Wenn Tabellenzellen Attribute enthalten, die mehr als einen Wert haben können, dann sind folgende zwei Darstellungen möglich:

• Der erste Wert wird in der ersten Zeile ausgeschrieben und darunter wird die Anzahl der noch folgenden Einträge im Format “und [Anzahl] weitere” genannt (Beispiel: “AG Lüneburg und 3 weitere”). Falls in Userstories nicht abweichend definiert, wird diese Darstellungsform als Standard verwendet.
• Werte hintereinander geschrieben und mit Semikolon voneinander getrennt (Beispiel: “2; 3; 6; 12” oder “Montag; Mittwoch; Freitag”). Diese Darstellungsform wird nur empfohlen, wenn jeder Einzelwert aus nicht mehr als 20 Zeichen besteht und wenn die erwartete Gesamtzahl an Attributen 12 Stück nicht übersteigt.

In beiden Fällen muss fachlich festgelegt werden, in welcher Reihenfolge die Werte in der Tabellenzelle angezeigt werden sollen bzw. welcher Eintrag der erste und damit ausgeschriebene ist. Falls nicht abweichend definiert, werden die Werte in der Reihenfolge angezeigt, in der sie auch im Detailformular gelistet sind. Der erstgenannte Wert der Zelle bestimmt bei der Sortierung der zugehörigen Tabellenspalte die Position, an der das Objekt in der Tabelle angezeigt wird. Die Verwendung von Zusatzbadges (Details siehe oben bei “Zellentyp Badge”) ist in Zellen mehren möglichen Attributen nicht zulässig.

------------

Tabellenzeilen / Inhalt

Der Screenreader gibt bei Navigation durch die Zellen nur den jeweiligen Spaltentitel aus, ohne das Attribut der Sortierung.

Ist der Text einer Zelle nicht vollständig darstellbar, so wird dieser am Ende mit “...” abgekürzt. Vom Screenreader wird dennoch bei Fokuserhalt einer Zelle der gesamte Text vorgelesen. Zusätzlich wird bei Maus-Hover oder bei Fokuserhalt der Zelle mit der Tastatur im Tooltip der komplette Eintragstext dargestellt. 

Im Fall, dass in einer Zelle mehrere Attribute enthalten sind und diese mit “...” abgekürzt sind, so wird nur der Teil im Tooltip vollständig dargestellt, der vor dem “und [Anzahl] weitere” befindet. Es werden nicht alle Attribute im Tooltip gelistet. Vom Screenreader wird dann ebenfalls nur ausgegeben “[Vollständiges erstes Attribut] und [Anzahl] weitere”.

Im Fall, dass eine Zelle Text/Zahl in einer Zeile und einen Badge in einer zweiten enthält, so enthält der Tooltip “[Vollständiger Text/Zahl] [Badgetext]”. Dieser wird auch vom Screenreader vorgelesen.

-----------

Leere Zellen

Ist bei einer Zelle kein Inhalt vorhanden (z.B. weil Attribut kein Pflichtattribut und im Objektformular kein Wert eingetragen wurde), so wird visuell ein Gedankenstrich “–” in Textform in der Zelle angezeigt. Das gilt für Spalten aller Inhaltstypen (Text, Badge, Zahl, Datum usw.). Vom Screenreader wird statt des Gedankenstrichs das Wort “leer” bei Fokuserhalt dieser Zelle ausgegeben.

In Sonderfällen können, wenn fachlich sinnvoll Zellen, welche den Wert “–” enthalten grau hinterlegt sein.

[Grafik Beispiel für Graue Hinterlegung bei Leeren Zellen wurde hinzugefügt]

ℹ️ Änderung in Bold dargestellt

Dropdowns

Jeder Eintrag der Ausklappiste kann bestehen aus: 

• Text: Einzelwert bzw. Einzelbegriff (Beispiel Sprachauswahl: Deutsch/Englisch...)
• Icon mit Text: Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.
• Avatar mit Text: Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.
• Primär- und Sekundärtext (Beispiel Raumauswahl: Angezeigt wird die Bezeichnung des Raumes in Zeile 1; Die Gebäudeart und Straße in Zeile 2 – ”Raum 2.01; Hauptgebäude, Berliner Straße 4a”)
• Primär- und Sekundärtext mit zusätzlicher Bildmarke (Beispiel: Personenauswahl: Avatar bzw. Foto einer Person, daneben Nachname und Vorname in erster Zeile, Amts-/Dienstbezeichnung in zweiter Zeile). Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.

Es können auch deaktivierte (disabled) Elemente im Dropdown angezeigt werden. Diese können auch fokussiert werden. Vom Screenreader werden sie als deaktivierte Elemente ausgegeben. 

Wichtig ist: Es muss für die Nutzenden fachlich einen Mehrwert bieten, dass die Einträge noch in deaktivierter Form als Teil der Ausklappliste angezeigt werden und es muss aus dem Maskenkontext klar hervorgehen, warum die Einträge deaktiviert sind. Kann dies nicht garantiert werden, so sollten die entsprechenden Werte in der Ausklappliste ganz ausgeblendet statt nur deaktiviert werden. 

[Grafik Wenig Einträge]

[Grafik Mit Scroll]

Öffnen Nutzende ein durchsuchbares Einfachauswahlfeld und fangen an, Text einzugeben, so werden Suchergebnisse angezeigt. Der Systemfokus liegt auch bei geöffneter Ausklappliste im Eingabefeld. Der blinkende Cursor wird angezeigt (falls bereits eine Auswahl vorhanden war, befindet er sich hinter dem letzten Zeichen).

• Ist in der Liste bereits ein Wert ausgewählt (nicht leer oder default), dann wird nach Öffnen der Liste nur dieser gewählte Eintrag in der Ausklappliste angezeigt und ist visuell als ausgewählt angezeigt. Er wird außerdem vom Screenreader ausgegeben.
• Ist in dem Element kein Eintrag bzw. der Default-Eintrag ausgewählt, dann werden beim Öffnen der Liste alle Einträge angezeigt und der Default-Eintrag “–“ wird visuell als ausgewählt angezeigt.

[Grafik Ausgewählter Eintrag]

[Grafik Kein Eintrag]

Fangen Nutzende, bei geöffneter Ausklappliste, an zu tippen, so wird der Inhalt des Auswahlfeldes auf diesen Wert hin gefiltert. Auswahlwerte, die den eingegebenen Wert nicht enthalten, werden ausgeblendet und die Liste wird bei wachsender Zeichenzahl entsprechend kürzer. Der gefundene Suchbegriff wird in der Ergebnisliste mit blauer Hinterlegung markiert (bei selektierten Einträgen invertiert). Zwischen jeder Wertänderungen und der entsprechenden Aktualisierung der Trefferliste besteht eine Verzögerung von 400ms. So haben Nutzende die Möglichkeit, Ihre Eingabe zunächst zu beenden (statt Ausführen der Aktion bei jedem Tastendruck). Dabei werden nur die als Listeneinträge hinterlegten Texte als gültige Werte akzeptiert.

Wird kein Ergebnis gefunden, so wird den Nutzenden der Text “Kein Treffer für [Suchbegriff] gefunden” angezeigt.

Falls die Serverabfrage für die Suche länger dauert (über 200ms), wird ein Ladezustand (loading spinner) im Dropdown angezeigt, bis Suchergebnisse vorhanden sind. Dieser ist nicht fokussierbar. Der Alternativtext des Symbols, der vom Screenreader automatisch ausgegeben wird, sobald er erscheint lautet “Einträge werden geladen”. Dieser wird auch als Tooltip angezeigt, wenn mit der Maus exakt über dem Lade-Icon gehovert wird. Falls das Laden länger dauert und das Auswahlfeld weiterhin fokussiert ist, wird alle 10 Sekunden erneut der Alternativtext des Ladesymbols “Ergebnisse werden geladen” ausgelesen.

Noch offen: Verhalten bei ausbleibender Server-Antwort (Hier ist vorher die technische Umsetzung zu klären)

Sobald Ergebnisse gefunden oder aktualisiert wurden, wird vom Screenreader die Anzahl der gefundenen Einträge automatisch ausgeben. Text: “[Anzahl] Treffer gefunden”.

Verhalten der Ausklappliste bei über 100 gefundenen Treffern (siehe Eingabe und Auswahlfelder).

[Grafik Ergebnisse Laden]

[Grafik Keine Ergebnisse]

[Grafik Über 100 Treffer]

Durchsucht werden kann bei Dropdownseinträgen mit Primär- und Sekundärtext immer nur der Primärtext (In den Beispielen: “Raum 2.04” und “Nachname, Vorname”). Basierend auf fachlicher Anforderung sollte definiert werden, ob eine der folgenden Suchverhalten gilt:

• “Beinhaltet [...]” – Sucht nach Zeichenabfolgen, die irgendwo innerhalb der Bezeichnung vorkommen.
• “Startet mit [...]” – Sucht nur nach Zeichenabfolgen die am Anfang der Bezeichnung stehen. 

Falls nicht definiert gilt die Regel “Beinhaltet [Suchbegriff]”. 

Alle für Suchfelder in GeFa definierten Wildcards können auch in Comboboxen genutzt werden (siehe Suchfeld: Wildcards).

Besteht der Inhalt eines Dropdown-Eintrags aus langem Text, so bricht dieser um, sobald er nicht mehr in einer Zeile darstellbar ist. Eine Abkürzung von Inhalten (z. B. mit “...”) darf nicht stattfinden, damit kein Inhalt versteckt wird.

Nach Auswahl eines Eintrags, wird bei Einträgen mit Primär- und Sekundärtext standardmäßig nur der Primärtext im Feld dargestellt.

Zustände

Bei einer Trefferzahl über 100, erscheint ein weiteres Feld, welches nur fokussiert werden kann.

[Grafik Durchsuchbare Einfachauswahlfelder]

[Grafil Zustände Geöffneter Felder]

[Grafik Dropdown Einträge wurde aktualisiert]

[Grafik Über 100 Treffer - Deafult]

[Grafik Über 100 Treffer - Fokus]

ℹ️ Änderung in Bold dargestellt

Verhalten

Pflichtfelder sind mit “*” (Sternchen”) nach dem Label markiert. Bei Read-Only-Feldern gibt es keine visuelle Pflichtfeldauszeichnung, auch wenn diese im Backend ggf. als Pflichtfelder geprüft werden.

Wenn Nutzende das Feld auch leer lassen können müssen, so muss der Eintrag ”–” zur Auswahl stehen (je fachliche Entscheidung im Einzelfall). 

Die Auswahlfeldbezeichnung sollte so kurz und präzise wie möglich formuliert sein. Sollte ein Label dennoch länger sein müssen, so bricht es um und wird mehrzeilig.

[Grafik Auswahlfeld mit mehrzeiligem Label]

Jeder Eintrag der Ausklappliste kann bestehen aus: 

• Text: Einzelwert bzw. Einzelbegriff
• Icon mit Text: Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.
• Avatar mit Text: Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.
• Primär- und Sekundärtext (Beispiel Raumauswahl: Angezeigt wird die Bezeichnung des Raumes in Zeile 1; Die Gebäudeart und Straße in Zeile 2)
• Primär- und ggf. Sekundärtext mit zusätzlicher Bildmarke (Beispiel: Personen mit Avatar oder Foto; daneben Nachname und Vorname in erster Zeile, Amts-/Dienstbezeichnung in zweiter Zeile). Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.

[Grafik Typen von Einträgen wurde hinzugefügt]

Es können auch deaktivierte (disabled) Elemente im Dropdown angezeigt werden. Diese können auch mit fokussiert werden. Vom Screenreader werden sie als deaktivierte Elemente ausgegeben.

Zustände

[Grafik Einfachauswahlfelder]

[Grafik Geöffnete Auswahlfelder]

[Grafik Zustände von Einträgen in Auswahlfeldern wurde aktualisiert]

[Grafik Minimalisierte Einfachauswahlfelder]

[Grafik Einfachauswahlfelder mit Baumstruktur]

[Grafik Einfachauswahl Baum geöffnet]

[Grafik Ausklapplisten Elemente]

ℹ️ Änderung in Bold dargestellt

Trennzeichen bei Listung mehrerer Werte

Werden mehrere Einzelwerte z. B. in einem Auswahlfeld oder einer Tabellenzeile gelistet, so sind die Einzelwerte mit Semikolon voneinander zu trennen.
(Details siehe auch “Mehrzeiliges Eingabefeld” oder Tabelle: Zellen mit mehreren Attributen)

ℹ️ Änderung in Bold dargestellt

Verhalten eines einzeiligen Eingabefelds bei numerischen Eingaben (mit oder ohne Einheit)

Wie im normalen einzeiligen Eingabefeld, kann hier ein beliebiger Zahlenwert eingegeben werden. Dabei wird die Einheit des einzugegenen Wertes stets als Teil des Feldlabels angegeben:
"[Feldtitel] in [Einheit]"

Pflichtfelder sind mit “*” (Sternchen) nach dem Label markiert.

Numerische Werte werden im deutschen Format eingegeben. Dabei wird "Punkt" für 1000-Trennzeichen und "Komma" für die Unterteilung in Nachkommastellen verwendet.

Falls es eine fachliche Anforderung gibt, dass Werte in eine einheitliche Form gebracht werden sollen (Beispiel: Geldbeträge immer mit zwei Nachkommastellen), dann geschieht die Umformatierung erst bei Verlassen des Feldes (siehe Eingabefeld: Verhalten bei Eingabe einer IBAN).

[Grafik Beispiel: Stundensatz in Euro]

[Grafik Beispiel: Arbeitskraftanteile in Prozent]

Standardfehlermeldung für Zahlenfelder lauten:

• “Nur Zahlen zulässig im Format 1.234,56”
• Wenn nur positive Zahlen zugelassen: “Nur positive Zahlen zulässig im Format 1.234,56” 
• Wenn nur negative Zahlen zugelassen: “Nur negative Zahlen zulässig im Format -1.234,56”
• Wenn nur Ganzzahlen erlaubt sind: “Nur Ganzzahlen zulässig im Format 1.234”
• Wenn nur positive Ganzzahlen erlaubt sind: “Nur positive Ganzzahlen zulässig im Format 1.234”
• Wenn nur negative Ganzzahlen erlaubt sind: “Nur negative Ganzzahlen zulässig im Format -1.234”

(siehe Meldungsliste aller Eingabe-/Auswahlelemente).

Ist das zulässige Format des Eingabefeldes nicht mit den oben beschriebenen Standardmeldungen abgedeckt, z. B. nur eine Nachkommastelle zulässig oder führende Nullen erforderlich, ist dies fachlich zu beschreiben. Die Fehlermeldung setzt sich aus den oben genannten Varianten (Zahlen allgemein; nur positive Zahlen etc.) und einem aussagekräftigen Beispiel zusammen. Das Beispiel des definierten Formats ist so zu wählen, dass es zum fachlichen Kontext passt und einfach verständlich ist.:

• “Nur [Zahlenformat] zulässig im Format [Beispiel definiertes Format]” (Beispiele: Positive Ganzzahlen mit führenden Nullen: “Nur positive Ganzzahlen zulässig im Format 001” | Zahlen mit einer Nachkommastelle: “Nur Zahlen zulässig im Format 1.234,5”)

Bei fachlichen Fehlermeldungen sind die globalen Formulierungsregeln für Meldungen zu beachten (siehe Globale Meldungsregeln: Modaldialog vom Typ Fehlermeldung).

ℹ️ Änderung in Bold dargestellt

Verhalten Einzeiliges Eingabefeld

Im einzeiligen Eingabefeld können Informationen eingegeben werden.

Je nach Einsatz kann das Feld mit Hinweistext und/oder einer maximalen Zeichenanzahl versehen sein. Pflichtfelder sind mit “*” (Sternchen”) nach dem Label markiert. Bei Read-Only-Feldern gibt es keine visuelle Pflichtfeldauszeichnung, auch wenn diese im Backend ggf. als Pflichtfelder geprüft werden.

[Grafik Eingabefeld mit Pflichtfeldauszeichnung]

Die Eingabefeldbezeichnung sollte so kurz und präzise wie möglich formuliert sein. Sollte ein Label dennoch länger sein müssen, so bricht es um und wird mehrzeilig.

[Grafik Mehrzeiliges Label]

Wenn eine maximale Zeichenzahl definiert wird:

Bei Erreichen der maximal erlaubten Zeichenzahl wird keine weitere Eingabe zugelassen. Bei jedem weiteren Tastenanschlag (keydown) ertönt ein akustisches Signal: Fehlermeldung (siehe akustische Signale).

Wenn keine maximale Zeichenzahl definiert wird: 
Falls die eingegebene Zeichenanzahl das technisch definierte Zeichenlimit überschreitet, wird bei Durchführen der Primäraktion des Formulars ein Validierungsfehler an Formularfeldern ausgelöst (siehe Formular: Validierungsfehlern an Formularfeldern). Die Fehlermeldung lautet „Maximale Zeichenanzahl überschritten: [Eingegebene Zeichen im Feld]/[Anzahl max. Zeichen]”. Das Standardverhalten für Fehlermeldungen findet Anwendung (siehe Formular: Ablauf Front-/Backend-Validierung).

Fehlerfälle / Validierung mehrzeiliger Eingabefelder

Bei fehlerhaften oder fehlenden Eingaben (Ablauf siehe Formulare: Ablauf Front-/Backend-Validierung) erscheint ein Ausrufezeichen-Icon mit erklärendem Text, dieses muss als Layoutgrafik deklariert werden. Gleichzeitig ertönt ein akustisches Signal: Fehlermeldung (siehe akustische Signale).

(Standard-)Fehlermeldungen, Formulierungsregeln für Fehlermeldungen und das Verhalten bei Erreichen der maximalen Zeichenanzahl sind identisch mit dem einzeiligen Eingabefeld (siehe oben Fehlerfälle / Validierung Einzeiliges Eingabefeld).

Im Read-Only-Zustand passt sich die Feldhöhe dem eingegebenen Inhalt an, so dass zum einen der komplette Text lesbar ist, zum anderen keine optischen Lücken in Formularen entstehen, wenn wenig Text eingegeben wurde.

[Grafik Nicht editierbare mehrzeilige Felder]

ℹ️ Änderung in Bold dargestellt

Verhalten bei Eingabe einer E-Mail

Das E-Mail-Eingabefeld ist ein Sonderfall des einzeiligen Eingabefeldes. Es unterscheidet sich in folgendem:

Erlaubt ist die Eingabe von Buchstaben, Zahlen, Punkte, Bindestriche, Unterstriche und dem Sonderzeichen “@”. Die Eingabe von anderen Sonderzeichen, Leerzeichen, Akzentbuchstaben oder Buchstaben außerhalb des lateinischen Alphabets ist nicht erlaubt. Das Sonderzeichen “@” muss in der Eingabe verwendet werden, darf aber nur ein mal vorkommen. Zudem muss die E-Mail mit einer gültigen Top-Level-Domain (z.B “.de”,”.com”, “.net”) enden.

Beispiel:

• beispiel@behoerde.de

[Grafik Eingabefeld E-Mail wurde hinzugefügt]

Fehlerfälle / Validierung eines E-Mail-Eingabefeldes

Siehe [Einzeiliges Eingabefeld]

Die Standardfehlermeldung bei fehlerhafter E-Mail (z.B. durch falsche Top-Level-Domain) lautet:

• “Keine gültige E-Mail”

ℹ️ Änderung in Bold dargestellt

Wertebereiche

Wertbereiche in Texten oder Labeln werden in folgendem Format dargestellt:

“[Von-Wert] – [Bis-Wert]”.

Falls die Werte zusätzlich eine Einheit besitzen, wird diese im Regelfall sowohl an den Von- als auch den Bis-Wert angehängt.

Beispiel:

• 15:00 Uhr – 15:30 Uhr
• 01.01.2024 – 31.12.2024
• 15 % – 50 %
• 1,00 – 5,00

Bei sehr langer Einheit (ab 4 Zeichen) ist es auch zulässig, die Einheit nur beim zweiten Wert zu nennen.

Beispiel:

• Kinder 7 – 16 Jahre

Die Erfassung von Von-Bis-Werten findet via Wertebereichsfelder statt.

URLs

Bei URLs werden keinerlei Umformatierungen vorgenommen. Zu nutzen ist ein normales einzeiliges Eingabefeld und es wird auch bei Verlassen des Feldes die von Nutzern eingegebene Formatierung beibehalten. 

Beispiele:

• https://www.[...]
• www.[...]

ℹ️ Änderung in Bold dargestellt

Favicon im Browsertab

Im jedem GeFa Browsertab, egal ob im separaten Browser oder im Browser innerhalb einer Rahmenanwendung geöffnet, wird immer eine Minimalversion des GeFa-Logos als Favicon im Tab angezeigt.

Siehe GeFa-Logo und dessen Darstellung in verschiedenen Größen.

[Grafik Favicons im Browser wurde aktualisiert]

ℹ️ Änderung in Bold dargestellt

Regeln für Formularfeldbreiten (gültig für alle Typen von Eingabe- und Auswahlfeldern)

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.

Platzierung Einzelner Buttons

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.

[Grafik Formular mit 1828 Pixeln Breite]

TABLE

[Grafik 720 Pixel]

[Grafik 620 Pixel]

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

[Grafik Formularbreite 460 Pixel]

[Grafik Minimale Formularbreite]

[Grafik Formular mit 320 Pixeln Höhe]

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.

[Grafik Positives Beispiel Responsive Buttons wurde eingefügt]

[Grafik negatives Beispiel Responsive Buttons wurde hinzugefügt]

Von Formularfeldern unabhängige Validierungsfehler

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 “Validierungstypen: 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.

ℹ️ Änderung in Bold dargestellt

Mit einem konsequenten Typografie-Konzept und klaren visuellen Hierarchien wird sichergestellt, dass die Elemente der Benutzeroberfläche klar und deutlich erkennbar sind und Nutzende sich gut zurechtfinden. Dafür sollten immer die definierten Textstile genutzt werden, die Größe, Schnitt und Abstände festlegen.

In der gesamten GeFa-Applikation wird die lizenzfreie Schrift Roboto in den Schriftschnitten Regular, Medium und Bold verwendet.

Nutzende haben die Möglichkeit in den Benutzerbezogenen Einstellungen von den GeFa-Standarddefinitionen für Zeilen-, Zeichen-, Wort- und Absatzabstand abzuweichen. Mit den nachfolgenden Auswahlmöglichkeiten können die Abstände so eingestellt werden, dass die WCAG-Mindestanforderungen (siehe https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html) erfüllt werden:

Zeilenabstand

• Standard
• Vergrößert (mind. 1,5-fache Schriftgröße) [exakte Zeilenabstände pro Schrittyp siehe Tabelle rechts]

Zeichenabstand

• Standard
• Leicht vergrößert (0,025-fache Schriftgröße)
• Vergrößert (0,05-fache Schriftgröße)
• Stark vergrößert (0,08-fache Schriftgröße)
• Extra stark vergrößert (0,12-fache Schriftgröße)

Wortabstand

• Standard
• Leicht vergrößert (0,03-fache Schriftgröße)
• Vergrößert (0,06-fache Schriftgröße)
• Stark vergrößert (0,09-fache Schriftgröße)
• Extra stark vergrößert (0,16-fache Schriftgröße)

Absatzabstand (Abstand zwischen Textabsätzen)

• Standard
• Vergrößert (2-fache Schriftgröße)

[Grafik Übersicht der Schrifttypen wurde aktualisiert]

[Grafik Zeichenabstand wurde hinzugefügt]

[Grafik Wortabstand wurde hinzugefügt]

[Grafik Zeilenabstand wurde hinzugefügt]

[Grafik Absatzabstand wurde hinzugefügt]

ℹ️ Änderung in Bold dargestellt

Aufbau Wizard Zusammenfassungsseite und Sektionsüberschriften

Die Sektionsüberschrift zeigt den Titel des Arbeitsschritts aus der Schrittnavigation. Die Arbeitsschritte werden wie in der Schrittübersicht durchnummeriert:  
“[Schrittnummer]. [Titel des Arbeitsschritts]”

Um Fehler bearbeiten zu können, enthält jeder Abschnitt einen sekundären Button mit Stift-Symbol, der den zugehörigen Arbeitsschritt aufruft.
Die Fokussetzung nach Sprung in den entsprechenden Schritt entspricht der Standardfokussetzung des Seitentyps Wizard).

[Grafik Sektionsüberschrift]

ℹ️ Änderung in Bold dargestellt

Sortierung

Für Komponenten mit Sortiermöglichkeit gelten folgende Standardsortierregeln (abweichendes Verhalten muss in User Stories definiert werden):

• Einträge ohne Zeitangaben werden alphanumerisch aufsteigend nach ISO 14651 /UCA case-insensitive sortiert. (mehr Informationen siehe https://de.wikipedia.org/wiki/Unicode_Collation_Algorithm)
• Einträge mit Zeitangaben werden chronologisch absteigend sortiert (neue Einträge zuerst).
• Als sekundäres Sortierkriterium wird standardmäßig die verknüpfte Datenbank-ID in absteigender Sortierung verwendet, welche immer eindeutig ist (damit ist sekundär in der Regel nach dem Anlagezeitpunkt des Objekts sortiert: neuestes zuerst). Dieses sekundäre Sortierkriterium kommt nur dann zum Tragen, wenn zwei Objekte, für das Attribut nach dem sortiert wird, den gleichen Wert besitzen. In User Stories kann auch ein anderes zweites oder drittes Sortierkriterium definiert werden, die Datenbank-ID wird dann als letztes Sortierkriterium verwendet.

[Grafik Sortierung wurde aktualisiert]

ℹ️ Änderung in Bold dargestellt

Funktion “Suchparameter hinzufügen”

Über den “Suchparameter hinzufügen”-Button können weitere Suchparameter ergänzt werden. Es öffnet sich dafür ein als Modal umgesetzter Container, welcher eine Parameter-Liste mit Suchfeld enthält.

Für die Grunddefinitionen des Containers (Größe, Positionierung, Header, Footer) siehe Element “Filter-Container”. Details:

• Der Header enthält immer nur den Titel “Suchparameter hinzufügen” (kein Weitere-Aktionen-Button)
• Der Footer enthält immer nur den sekundären Button “Schließen” (kein “Anwenden”)
• Positionierung: Das Modal öffnet sich, wenn genügend Platz vorhanden ist, under dem Plus-Button, von dem aus es aufgerufen wurde. Bei weniger Platz, siehe Spezifikationen des Filtercontainers.

Der Tastaturfokus liegt bei Öffnen des Containers im Suchfeld.

Die Liste kann (je nach fachlicher Anforderung) mit Trennblöcken in weitere Unterkategorien unterteilt sein.

Nach Auswahl eines der Listenelemente schließt sich das Modal und das Element wird der entsprechenden Suchparameter-Gruppe hinzugefügt. Jedes Suchparameter-Element kann innerhalb einer Gruppe nur einmal hinzugefügt werden, das heißt nach Hinzufügen und erneutem Öffnen des “Suchparameter hinzufügen”-Modals taucht es in der Liste nicht mehr auf. Die Liste wird also mit jedem hinzugefügten Element kürzer. Wird das letzte Element aus der Liste hinzugefügt, so wird bei Schließen des Modals der “Suchparameter hinzufügen”-Button deaktiviert. Sobald ein Element aus der Gruppe entfernt wird, wird er wieder aktiv.

[Grafik Hinzufügen eines Suchparameters]

ℹ️ Änderung in Bold dargestellt

Tastaturbedienung

• Siehe: Link
• Siehe: Pop-up Menü
• Fokussetzung nach Aufruf einer neuen Seite via Link oder Pop-Up-Menü-Eintrag siehe Standardokussetzung des entsprechenden Seitentyps.
• Enter- oder Leertaste bei fokussierter Ladeanimation löst keine Aktion aus.

Mausbedienung

• Siehe: Link
• Siehe: Pop-up Menü
• Fokussetzung nach Aufruf einer neuen Seite via Link oder Pop-Up-Menü-Eintrag siehe Standardokussetzung des entsprechenden Seitentyps.
• Bei Klick mit linker Maustaste auf die Ladeanimation passiert nichts, außer dass diese fokussiert wird.

ℹ️ Änderung in Bold dargestellt

Tastaturbedienung Formular Header

• 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. Accordion oder Eingabefeld).
• Das Pop-up Menü verhält sich wie definiert.

ℹ️ Änderung in Bold dargestellt

Ein Wert: Freitext

Beispiel:

• Nachname: [Text]
• Straße: [Text]
• Justizbehörde: [Text]

Über ein einzeiliges Eingabefeld kann ein beliebiger Wert eingegeben werden. 

Außerdem wird bei Freitext-Filtern für Texteingaben immer ein Toggle-Schalter unter dem Feld angezeigt, mit welchem eine Phonetische Suche aktiviert bzw. deaktiviert werden kann. Beim hinzufügen eines neuen Filters ist der Toggle zunächst nicht ausgewählt.

Der Toggle-Schalter wird nicht angezeigt, wenn im Eingabefeld Zahlenwerte (ggf. inkl. Sonderzeichen) eingegeben werden sollen.

[Grafik Freitext ohne Toggle]

Im Read-Only-Zustand wechselt das Eingabefeld entsprechend in den Read-Only-Status. Toggle-Buttons werden durch Read-Only-Checkboxen ersetzt.

[Grafik Freitext mit phonetischer Suche]

[Grafik Read-Only]

Auswahl eines/Mehrerer Werte aus Statischer Liste

Beispiele:

• Registerzeichen: C; AR; Qt; T
• Amts-/Dienstbezeichnung: [Erste]; [Zweite]
• Fachbereich: Zivil; Straf; Betreuung

Abhängig von der Anzahl der zur Auswahl stehenden Parameter, sind verschiedene Elemente zu verwenden:

• Unter 6 Möglichkeiten: Checkbox-Group
• Über 6 Auswahlmöglichkeiten: Multi-Select-Picker

(Maus- und Tastaturbedienung siehe entsprechendes Element)

Das auswählbare Attribut ist im Standardfall die Spalte “Name lang” der zugrundeliegenden Statischen Liste. Falls ein abweichender Wert gewählt werden soll, ist dies in den Userstories zu definieren.

[Grafik Durchsuchbares Auswahlfeld über 6 Einträge]

Im Read-Only-Zustand werden die interaktiven Elemente im Inhaltsbereich folgendermaßen ersetzt:

• Checkbox-Group > Gleiches Element im Read-Only-Zustand
• Multi-Select > Multi-Select Read-Only

(Labels entsprechen weiterhin den Labels der vorher verwendeten Elemente).

[Grafik Read-Only]

ℹ️ Änderung in Bold dargestellt

Footer

Dieser enthält den primären Button “Anwenden” und den sekundären Button “Schließen”. Der Anwenden-Button ist bei Öffnen des Filtercontainers inaktiv und er wird aktiv (klickbar), sobald eine Änderung im Filtercontainer vorgenommen wurde (bspw. Wertänderung in einem Auswahlelement oder Eingabe/Änderung/Löschung eines Zeichens in einem Eingabefeld). Bei Änderung in Eingabefeldern wird der Button bereits mit der Änderung, nicht erst bei Verlassen des Feldes aktiv.

Wird die Aktion “Anwenden” ausgeführt, so wird die Auswahl übernommen und der Filter-Container schließt sich. Der Tastaturfokus befindet sich danach auf der entsprechenden Filter-Pille. Die ausgewählten Parameter werden dann in der Pille angezeigt bzw. geändert (falls vorher bereits Parameter gewählt waren).             
Zur Ergebnisanzeige nach Anwenden eines Filters in der Tabelle siehe “Tabellen - Durchsuchen & Filtern von Tabelleninhalten”.            

Falls unvollständige oder fehlerhafte Eingaben vorliegen und Nutzende auf “Anwenden” drücken, so erscheint ein Banner vom Typ Fehlermeldung mit der Überschrift “Anwenden nicht möglich”. Diese ist als “H3” gekennzeichnet.” Details zu Aussehen, Verhalten, Maus- und Tastaturbedienung siehe “Fehlermeldungen in Formularen”.

Wird die Aktion “Schließen” ausgeführt, so schließt sich der Filter-Container, ohne, dass die Auswahl übernommen wird.

Beim Verlassen eines Filtercontainer mit un-angewendeten Eingaben erscheint keine Sicherheitsabfrage. In dem Moment, wo der FIltercontainer geschlossen wird, werden alle noch un-angewendete Inhalte verworfen. Beim erneutem Öffnen sind die Inhalte wieder zurückgesetzt auf die zuletzt angewandten Werte bzw. die Standardwerte dieses Filters.

Je nach Art des Filters sind manche Aktionen im Filter-Container nicht klickbar/verfügbar:

• Vorgegebene Read-Only Filter: Diese Filter sind vorgegeben, nicht veränderbar und nicht löschbar. Sie lassen sich öffnen, aber nicht modifizieren. Der “Weitere Aktionen”-Button im Header wird nicht angezeigt. Der Inhaltsbereich enthält keine interaktiven Elemente, sondern nur read-only-Elemente. Der Footer enthält nur den “Schließen Button”. Der “Anwenden-Button” wird nicht angezeigt.
• Vorgegebene editierbare Filter: Bei diesem Filter ist der Inhaltsbereich modifizierbar. Der Footer enthält den primären Button “Anwenden” und den sekundären Button “Schließen”. Der Filter kann nicht entfernt werden. Der “Weitere Aktionen”-Button im Header wird angezeigt und enthält nur den Button “Zurücksetzen” (deaktiviert, bis Änderungen gemacht wurden). Die Funktion “Entfernen” gibt es hier nicht.
• Neu hinzugefügte Filter (editierbar- und löschbar): Da dieser Filter von Nutzern manuell hinzugefügt wurde, kann er nicht nur modifiziert, sondern auch wieder entfernt werden. Der “Weitere Aktionen”-Button im Header wird angezeigt und das Pop-Up-Menü enthält beide Funktionen: “Zurücksetzen” (deaktiviert, bis Änderungen gemacht wurden) und “Entfernen”.

[Grafik Header]

[Grafik Footer]

[Grafik Header mit langem Titel]

ℹ️ Änderung in Bold dargestellt

Verhalten der Funktion “Suche zurücksetzen” ausführen

Der Button ist bereits beim initialen Aufruf der Seite aktiv & klickbar, auch wenn noch keine Änderungen im Suchparameter-Bereich vorgenommen wurden (damit wahrnehmbar).

Wird die Aktion ausgeführt und es liegen keine Änderungen auf der Seite vor, so geschieht nichts, außer dass der Fokus auf das erste Suchparameter-Element gelegt wird.

Wird die Zurücksetzen-Funktion ausgeführt und es liegen Änderungen auf der Seite vor, so wird der default-Zustand des Sucheingabe-Eingabebereichs wiederhergestellt:

• Änderungen an Suchparameter-Elementen werden zurückgesetzt.
• Neu hinzugefügte Suchparameter-Elemente und Objektgruppen werden entfernt.
• Entfernte Standard-Suchparameter-Elemente sowie Objektgruppen werden wieder eingeblendet.

Nach Ausführen der Aktion bleibt der Button aktiv und der Tastaturfokus wird auf das erste Suchparameter-Element gelegt.

[Grafik Ablauf "Suche zurücksetzen" wurde aktualisiert]

ℹ️ Änderung in Bold dargestellt

Verhalten

Dieser Seitentyp besteht aus folgenden Elementen. Nicht alle Elemente sind auf jeder Seite sichtbar. Je nach fachlicher Anforderung können Elemente wie Suche oder Filter ausgeblendet werden. Die Reihenfolge (von oben nach unten) bleibt jedoch immer gleich. Die Reihenfolge der hier genannten Elemente entspricht auch der Fokusreihenfolge, wenn mit der Tastatur navigiert wird. Beim initialen Seitenaufruf liegt der Fokus auf einem der folgenden Element im Formular-Inhaltsbereich (je nach dem, was davon vorhanden):

1. Titel im Meldungsbanner
2. Titel im Hinweisbanner Typ 1 (sofern dieser im oberen Teil des Formulars platziert ist) 
3. Erstes Akkordeon
4. Erstes Formularfeld

Verhalten der Seite mit Schnellnavigations-Sidebar innerhalb eines Verfahrens

Der genau gleiche Aufbau (siehe oben) gilt auch für diesen Seitentyp innerhalb eines Verfahrens. Die einzigen Unterschiede sind: 

Beim initialen Seitenaufruf liegt der Fokus auf einem der folgenden Elemente im Formular-Inhaltsbereich (je nach dem, was davon vorhanden ist):

1. Titel im Meldungsbanner
2. Titel im Hinweisbanner Typ 1 (sofern dieser im oberen Teil des Formulars platziert ist) 
3. Erstes Akkordeon
4. Erstes Formularfeld

Zwischen Headerleiste und Pfadnavigation wird der Verfahrensheader eingeschoben. Dieser füllt die komplette Fensterbreite.

ℹ️ Änderung in Bold dargestellt

Verhalten außerhalb eines Verfahrens

Dieser Seitentyp besteht immer aus folgenden Elementen. Die Reihenfolge der hier genannten Elemente enspricht auch der Fokusreihenfolge, wenn mit der Tastatur navigiert wird. Beim initialen Seitenaufruf liegt der Fokus auf einem der folgenden Elemente im Formular-Inhaltsbereich (je nach dem, was davon vorhanden ist):

1. Titel im Meldungsbanner
2. Titel im Hinweisbanner Typ 1 (sofern dieser im oberen Teil des Formulars platziert ist) 
3. Erstes Akkordeon
4. Erstes Formularfeld

Verhalten innerhalb eines Verfahrens

Der genau gleiche Aufbau (siehe oben) gilt auch für Detailformulare innerhalb eines Verfahrens. Die einzigen Unterschiede sind:

Beim initialen Seitenaufruf liegt der Fokus auf einem der folgenden Elemente im Formular-Inhaltsbereich (je nach dem, was davon vorhanden):

1. Titel im Meldungsbanner
2. Titel im Hinweisbanner Typ 1 (sofern dieser im oberen Teil des Formulars platziert ist) 
3. Erstes Akkordeon
4. Erstes Formularfeld

Zwischen Headerleiste und Pfadnavigation wird der Verfahrensheader eingeschoben. Dieser füllt die komplette Fensterbreite.

ℹ️ Änderung in Bold dargestellt

Fehler- und Erfolgsmeldungen in Formularen

Arten von Validierungen

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 (siehe Definition der Wertübernahme-Zeitpunkte pro Feldtyp) 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 “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 (Details zum Validierungszeitpunkt pro Elementtyp siehe “Validierungsfehler an Formularfeldern”). 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 Validierung
• Übergreifende Validierung zwischen Haupt- und Unterformularen
• Wizard Validierungsverhalten

Validierungsfehlern an Formularfeldern

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, 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 auch Checkboxen).

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 “Ablauf Front-/Backendvalidierung” und “Übergreifende Validierung zwischen Haupt- und Unterformularen”).

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

[Grafik Eingabe]

[Grafik Auswahl]

[Grafik Checkboxgruppe]

[Grafik Radio-Button-Gruppe]

ℹ️ Änderung in Bold dargestellt

Verlassen des aktuellen (noch nicht zuvor validierten) Arbeitsschritts

Weiter navigieren:    
Wird der Arbeitsschritt vorwärts zu einem folgenden Arbeitsschritt verlassen, wird das Formular validiert und der nächste Schritt wird geöffnet, wenn es keine Validierungsfehler gibt. 

Fehlerverhalten siehe Bereich “Meldungsbanner in Formularen”. Der Titel der Fehlermeldung ist “Fehlerhafte Eingaben”.

Zurück navigieren:            
Vorherige Schritte können jederzeit angesprungen werden und das Formular wird dafür nicht validiert. Eingaben bleiben erhalten. Der verlassene Arbeitsschritt wird als besucht angezeigt.

[Grafik Validierungsfehler wurde aktualisiert]

Darstellung der Validierungsfehler in der Schrittübersicht

Werden nach Klick auf einen Primärbutton im Wizardfooter (z. B. “Weiter” oder “Anlegen”) oder bei Verlassen eines Wizardschritts über die Schrittübersicht Validierungsfehler in einem oder mehreren Arbeitsschritten festgestellt, so werden die entsprechenden Einträge in der Schrittübersicht folgendermaßen markiert:

• In der Standardansicht – Schrittübersicht geöffnet: Nach der Beschriftung des Schritts wird ein Fehlersymbol mit dem Alternativtext “– Fehlerhafte Eingaben” angehängt. Dieser wird vom Screenreader bei Fokuserhalt des Schritts mit ausgelesen.
• In der Standardansicht – Schrittübersicht geschlossen: An der Schrittnummer wird ein roter Punkt ergänzt. Der Alternativtext des Schritteintrags, welcher bei Hover oder Fokuserhalt auch als Tooltip dargestellt wird und vom Screenreader bei Fokuserhalt mit ausgelesen wird lautet “[Arbeitsschritt] – Fehlerhafte Eingaben”.
• In der Dropdown-Ansicht (bei Fensterbreiten unter 960px) – Geschlossener Zustand: An den fehlerhaften Schritten in der Grafik wird ein roter Punkt ergänzt. Der Alternativtext für Screenreader lautet “Arbeitsschritt [Schrittnummer Aktueller Schritt] von [Gesamtzahl aller Schritte] – Fehlerhafte Eingaben in Schritt [Nr], [Nr] und [Nr]”. Beispiel: “Arbeitsschritt 3 von 8 – Fehlerhafte Eingaben in Schritt 1 und 3”.
• In der Dropdown-Ansicht (bei Fensterbreiten unter 960px) – Geöffneter Zustand: In der Ausklappliste wird bei jedem fehlerhaften Schritt der Text “– Fehlerhafte Eingaben” hinter der Eintragsbeschriftung ergänzt.

Für die detailierte Beschreibung des Verhaltens, wann die Darstellung der Schrittübersicht aktualisiert wird, siehe Abschnitt “Ablauf von Frontend/Backend Validierungen in Wizardprozessen”.

[Grafik Validierungsfehler in der Schrittübersicht wurde aktualisiert]

[Grafik Validierungsfehler in der Schrittübersicht mit Dropdown wurde aktualisiert]

Ablauf von Validierungen in Wizardprozessen

Es wird unterschieden zwischen Frontend-, Frontend-Crossvalidierungen (über ein oder mehrere Wizardseiten hinweg) und Backend-Validierungen. Dabei unterscheiden sich die Validierungszeitpunkte und Fehlerdarstellungen. Details siehe “Formulare: Arten von Validierungen”.

Detailablauf im Wizard

1. Wird in einem Arbeitsschritt auf “Weiter” geklickt oder wird der Arbeitsschritt durch Auswahl eines aktiven (da vorher bereits besuchten) Folgeschritts über die Schrittübersicht verlassen, so werden Frontend- und ggf. Cross-Validierungen für diesen Wizardschritt durchgeführt. Die Fehler können auch schon vorher direkt am fehlerhaft befüllten Feld erscheinen (siehe Validierungszeitpunkte pro Elementtyp). Liegen Frontend-/Cross-Validierungsfehler in dem Schritt, der gerade verlassen werden soll, vor, so erscheint bei Klick auf “Weiter” bzw. einen aktiven Folgeschritt in der Schrittnavigation ein Fehlerbanner, welches alle Fehler im aktiven Schritt listet. Nutzende müssen diese zunächst beheben, bevor zum nächsten Arbeitsschritt gewechselt werden kann. Möglicherweise aktive Folgeseiten in der Schrittübersicht werden deaktiviert (im Moment, wenn auf “Weiter” oder einen Folgeschritt in der Schrittübersicht geklickt wird) und sind erst wieder aufrufbar, wenn alle Frontend-/Crossvalidierungsfehler auf der Seite behoben wurden. Die in Folgeschritten ggf. bereits eingegebenen Daten werden allerdings auch bei deaktivieren der Schritte weiterhin vorgehalten. Gleichzeitig mit Erscheinen des Fehlerbanners wird der aktive Schritt in der Schrittübersicht als fehlerhaft markiert (siehe Schrittübersicht). Wird erneut auf “Weiter” bzw. den aktiven Folgeschritt in der Schrittnavigation geklickt und es wurden vorher alle Fehler auf der Seite behoben, so verschwindet die Markierung als fehlerhaft wieder aus der Schrittübersicht und möglicherweise vorher bereits aktiv gewesene Folgeschritte werden wieder klickbar und enthalten dann wieder die vorher bereits befüllten Eingaben.
2. Ein Formular mit Frontend-/Crossvalidierungsfehlern kann über Zurück bzw. Klick auf einen vorherigen Schritt in der Schrittübersicht verlassen werden. Falls zu diesem Zeitpunkt bereits Folgeschritte besucht wurden und aktiv sind, so erscheint bei Verlassen eine Sicherheitsabfrage mit folgendem Text: “Schritt verlassen?” (Meldungstext 1) “Der aktuelle Schritt enthält Validierungsfehler. Bei Verlassen werden die Folgeschritte deaktiviert. Die darin bereits eingegebenen Daten bleiben erhalten. Möchten Sie den aktuellen Schritt verlassen?” (Meldungstext 2) und den Aktionen “Abbrechen” und “Verlassen”. Nach Bestätigen der Sicherheitsabfrage wird der Schritt verlassen und die bereits aktiv gewesenen Folgeschritte des verlassenen Schritts in der Schrittnavigation werden deaktiviert. Die darin bereits eingegebenen Daten werden allerdings weiterhin vorgehalten. Erst nach Verlassen des fehlerhaften Schritts vorwärts (über “Weiter”) und wenn die Frontend-/Crossvalidierungsfehler behoben wurden, können Folgeschritte wieder aktiv werden und enthalten dann wieder die vorher bereits befüllten Eingaben. Wurde die fehlerhafte Seite rückwärts (zu vorherigem Schritt) verlassen und Nutzer kehren anschließend wieder auf die Seite zurück, so sind die fehlerhaften Eingaben, die vor oder bei Verlassen der Seite bereits validiert wurden, sichtbar (Fehlermarkierungen an Formularelementen und ggf. zusätzlich das Meldungsbanner, falls bereits vorher versucht wurde, den Schritt in Vorwärts-Richtung zu verlassen). Erst nach Beheben aller Frontend-/Crossvalidierungsfehler in diesem Schritt, kann wieder vorwärts navigiert werden (über Weiter oder Schrittübersicht). Wird ein Formular ohne Frontend-/Crossvalidierungsfehlerrückwärts über “Zurück” oder die Schrittübersicht verlassen, so führt dies nicht zu einem deaktivieren der ggf. bereits aktiven Folgeschritte in der Schrittnavigation.
3. Wird am Ende auf der Zusammenfassungs- bzw. letzten Wizardseite die Primäraktion im Footer (bspw. “Anlegen”) ausgeführt, so werden nun Backend-Validierungen für die in allen Schritten des Wizards getätigten Eingaben durchgeführt. Alle gefundenen Fehler werden in einem Fehlerbanner auf der Zusammenfassungs- bzw. letzten Wizardseite aufgelistet. Gleichzeitig mit Erscheinen des Banners werden die Schritte, in denen die fehlerhaften Eingaben identifiziert wurden, in der Schrittübersicht mit dem Fehlersymbol markiert (Markierung siehe Schrittübersicht). Die Zusammenfassungsseite des Wizards, welche ausschließlich nicht bearbeitbare Anzeigefelder enthalten kann, wird dabei nie als fehlerhaft markiert, sondern nur Seiten, auf denen die Fehler auch behoben werden können. Falls es sich um einen Wizard ohne Zusammenfassungsseite handelt, und die letzte Seite editierbare Felder enthält, so kann es hier auch zu einer Fehlermarkierung in der Schrittübersicht kommen. Dem Fehlertext im Banner der Zusammenfassungs- bzw. letzten Wizardseite wird immer die Schrittnummer und -bezeichnung, in dem sich das fehlerhafte Element befindet, vorangestellt. Es gibt nun drei Möglichkeiten, wie für die Fehlerbehebung zu den fehlerhaften Feldern zu navigiert werden kann:
4. 1. Jeder einzelne Fehler im Banner ist klickbar. Es öffnet sich dadurch der entsprechende Prozessschritt (im gleichen Browsertab) und der Tastaturfokus wird auf das fehlerhafte Element bzw. bei Formularfeldunabhängigen Fehlern auf dem Fehlertext gelegt.
   2. Über die Schrittübersicht kann ebenfalls manuell zu der entsprechenden Stelle navigiert werden (Details siehe Schrittnavigation)
   3. Auch die manuelle Rücknavigation Schritt für Schritt über den “Zurück”-Button im Footer ist möglich.
4. Im angesprungenen Schritt sind erneut die Backend-Fehler im Fehlerbanner aufgelistet, welche diesen einen Prozessschritt betreffen. Sobald eine Änderung an einem betroffenen Feld erfolgt ist und die Wertübernahme stattgefunden hat (Zeitpunkt Wertübernahme pro Feldtyp siehe “Validierungsfehler an Formularfeldern”) wird der entsprechende Eintrag im Fehlerbanner des Schritts als deaktiviert dargestellt (auch wenn die erneute Backendprüfung erst wieder auf der Zusammenfassungs- bzw. letzten Wizardseite geschieht). Entsteht durch die Korrektur ein neuer Frontendfehler, so wird dieser zum Zeitpunkt der Wertübernahme am Element angezeigt. Im Meldungsbanner werden die neu hinzugekommenen Frontend-/Crossvalidierungsfehler erst nach erneutem Klick auf “Weiter” bzw. Klick auf einen Folgeschritt in der Schrittübersicht mit gelistet. Neu hinzugekommene Frontend-/Crossvalidierungsfehler werden dann zusätzlich zu den ggf. bereits deaktivierten Backendfehlern des Schritts im Banner angezeigt. Dabei entspricht die Reihenfolge der gelisteten Fehler der Formularreihenfolge der betroffenen Felder (siehe auch Standardverhalten des Fehlerbanners in Formularen). 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-/Crossvalidierungsfehler auf der Wizardseite behoben werden müssen, bevor zur nächsten Seite gewechselt werden kann. Auch die Folgeseiten in der Schrittübersicht werden in dieser Zeit deaktiviert und sind erst wieder aufrufbar, wenn alle Frontend-/Crossvalidierungsfehler behoben wurden. Noch offene Backend-Fehler führen nicht zu einer temporären Sperrung der Weiter-Navigation bzw. zu Deaktivierung nächster Schritte in der Schrittübersicht, verhindern also nicht, dass ein Schritt verlassen werden kann.
5. Wurden alle Frontend-/Crossvalidierungsfehler in einem Wizardschritt behoben und alle Elemente mit Backend-Fehlern bearbeitet und Nutzende verlassen den Schritt mit Klick auf “Weiter” oder durch Klick auf einen der wieder aktivierten Folgeschritte in der Schrittnavigation, so wird die Fehlermarkierung des verlassenen Schritts in der Schrittnavigation entfernt. Wären noch Backendfehler unbearbeitet, so bliebe die Markierung nach Verlassen des Schritts erhalten. Wird ein Schritt, in dem alle Fehler behoben und entsprechende Einträge im Fehlerbanner deaktiviert wurden, rückwärts über die Schrittübersicht verlassen und bei Verlassen werden keine neuen Fehler festgestellt, so wird bei Verlassen auch die Fehlerhaft-Markierung in der Schrittübersicht entfernt.
6. Kehren Nutzer mit Klick auf “Weiter” oder über die Schrittnavigation auf die Zusammenfassungs- bzw. letzte Wizardseite zurück, dann werden dort alle bereits bearbeiteten Backend-Fehlereinträge im Banner deaktiviert dargestellt. Noch unbearbeitete Fehlereinträge sind im Fehlerbanner weiterhin aktiv und klickbar.
7. Wird erneut die Abschlussaktion (z. B. “Anlegen”) auf der Zusammenfassungs- bzw. letzten Wizardseite ausgeführt, so findet erneut eine Validierung über alle Prozessschritte statt und das oben beschriebene Verhalten (ab Punkt 2) wiederholt sich gegebenenfalls.

Benennung der Meldungen

Der Titel des Fehlerbanners lautet:

• Auf der Zusammenfassungs- bzw. letzten Wizardseite: “[Bezeichnung primärer Button] nicht möglich”
• Auf alleren vorherigen Schritten des des Wizards “Fehlerhafte Eingaben”

Der Buttontext in der Fehlerliste darunter auf der Zusammenfassungs- bzw. letzten Wizardseite setzt sich zusammen aus:

• “[Schrittnummer]. [Arbeitsschritt] –”
• Dem für das fehlerhafte Element definierten Zusatz (siehe Element “Fehlerbanner in Formularen: Schema Benennung”)

Beispiel: Ein fehlerhaftes einzeiliges Eingabefeld “Bezeichnung” im ersten Wizard-Schritt wird folgendermaßen beschrieben:
“1. Grunddaten – Bezeichnung: Objekt mit gleicher Bezeichnung im gleichen Gültigkeitszeitraum existiert bereits”

[Grafik Backend-Validierungen wurde aktualisiert]

Tastaturbedienung Wizard Schrittübersicht

Sidebar-Variante (über 960px Fensterbreite)

• Mit Tab-Taste wird der aktuell ausgewählte Schritt in der Schrittübersicht angesprungen.
• Mit den Pfeiltasten nach unten bzw. oben kann der nächste bzw. vorherige Arbeitsschritt fokussiert werden.
• Leertaste oder Enter öffnet den fokussierten Arbeitsschritt. Der Fokus liegt anschließend im Formularinhalt (exakte Fokussetzung siehe Seitentyp Wizard).
• Nach Öffnen eines Arbeitsschritts liegt der Fokus auf dem ersten interaktiven Element des Formulars.

Dropdown-Variante (unter 960px Fensterbreite)

• Mit der Tab-Taste wird die Schrittübersicht fokussiert.
• (Weitere Tastaturbedienung siehe “Einfachauswahlfeld”)

Tastaturbedienung Back-end Validierungen in Wizard-Neuanlagen

• Siehe Meldungsbanner in Formularen
• Siehe Validierungsfehler an Formularfeldern
• Siehe Formularfeldunabhängige Validierungefehler

Mausbedienung Wizard Schrittübersicht

Sidebar-Variante (über 960px Fensterbreite)

• Klick mit linker Maustaste auf einen Schritt öffnet die jeweilige Seite. Der Fokus liegt anschließend im Formularinhalt (exakte Fokussetzung siehe Seitentyp Wizard).

Dropdown-Variante (unter 960px Fensterbreite)

• Klick mit linker Maustaste auf das Dropdownelement öffnet die Ausklappliste.
• (Weitere Mausbedienung im Dropdown siehe “Einfachauswahlfeld”). Der Fokus wird nach Auswahl eines aktiven Schritts und schließen des Dropdowns auf das erste interaktive Element in dessen Formularinhalt gelegt.

Mausbedienung Back-end Validierungen in Wizard-Neuanlagen

• Siehe Meldungsbanner in Formularen
• Siehe Validierungsfehler an Formularfeldern
• Siehe Formularfeldunabhängige Validierungefehler

ℹ️ Änderung in Bold dargestellt

Verhalten von Formular Footern (Fußzeile)

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. 

[Grafik Formular-Footer mir Schlißen-Button]

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.

[Grafik 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 auch “Validierung: 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 Meldungsbanner in 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 Validierung: Meldungsbanner in Formularen).

[Grafik Ablauf der Speicherung]

Erfolgsindikatoren

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

Beispiel 1 – Speichern eines Hauptformulars

• 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 Formular-Fußzeile): 
• 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 Fahlerbanner angezeigt (siehe Meldungsbanner in 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. Fokussetzung siehe Formular Footer > Tastaturbedienung.

[Grafik Erfolgsindikatoren im Speichern-Button eines Formulars]

[Grafik Formular vor und während dem Speichern]

Beispiel 2 – Neuanlage eines Objekts & Rückkehr auf Datenübersicht

• 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 Meldungsbanner in Formularen). 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 Formular Footer > Tastaturbedienung.

Beispiel 3 – Neuanlage eines Verfahrens

• 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 Formular Footer > Tastaturbedienung.

Beispiel 4 – Hinzufügen und Bearbeiten von Unterobjekten

• 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 Meldungsbanner in Formularen). 
• Solange keine Validierungsfehler vorliegen, wird das Formular des Unterobjekts ohne Buttonanimation oder Ton geschlossen. Fokussetzung siehe Formular Footer > Tastaturbedienung.

[Grafik Bestätigungsbanner nach Neuanlage eines Hauptobjekts]

Tastaturbedienung > Formular Footer (Fußzeile)

• 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 > “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 “Seitentypen”).
  • 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 > Bestätigungsbanner). 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 “Seitentypen”).
  • 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 auchj “Fehlermeldungsbereich in Formularen”).
• Für Verhalten des “Mehr Aktionen” Buttons (bei kleinen Screenbreiten) siehe Beschreibung Pop-Up-Menü

Tastaturbedienung > Erfolgsindikatoren

• Siehe Elemente “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 Element “Bestätigungsbanner”

Mausbedienung > Formular Footer (Fußzeile)

• 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ü

Mausbedienung > Erfolgsindikatoren

• Siehe Elemente “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 Element “Bestätigungsbanner”

ℹ️ Änderung in Bold dargestellt

Tastaturbedienung

• Bei einer Gruppe mit einer bereits ausgewählten Option wird mit Tab immer der aktive Radio-Button fokussiert. Ist in einer Radiobuttongruppe mit auswählbaren Werten noch keine Option ausgewählt, dann sind die einzelnen Optionen der Gruppe entsprechend des jeweiligen Browserstandardverhaltens mit der Tastatur erreichbar.
• Leertaste aktiviert den fokussierten Radiobutton.
• Die Pfeiltasten nach oben oder unten wechseln sowohl den Fokus als auch den Aktiv-Status.
• Tab wechselt zum nächsten interaktiven Element außerhalb der Radiobuttongruppe.
• Im Read-only-Status wird mit Tab nur der aktivierte Radiobutton fokussiert.

ℹ️ Änderung in Bold dargestellt

Verhalten Tabellen-Header

Der Tabellenheader beinhaltet aussagekräftige Titel in jeder Spalte der Tabelle. Er bleibt beim Scrollen der Tabelle sticky stehen, sodass die Spaltenüberschriften jederzeit sichtbar sind.

Standardsortierung von Tabellen:

• Alle Spalten einer Tabelle sind sortierbar (mit Ausnahme der “Auswahl”- und “Aktionen”-Spalten).
• Sollen weitere Spalten nicht sortierbar sein, muss dies in den User Stories beschrieben werden.
• Tabellen werden bei Seitenaufruf anhand der ersten Spalte sortiert (Tabellen mit Auswahlspalte werden anhand der zweiten Spalte sortiert). In User Stories kann auch eine andere eingeblendete Spalte für die Sortierung bei Seitenaufruf definiert werden. Es gelten folgende Sortierungen je nach Datentyp:
• • Spalten mit Zeitangaben werden chronologisch absteigend (neue Einträge zuerst) sortiert. 
  • Alle anderen Spalten werden alphanumerisch aufsteigend (A–Z) sortiert.
  • Sortierungen die weder chronologisch noch alphanumerisch sind (z.B. nach Status), müssen in User Stories beschrieben werden.
• Bei einer “starren” Tabelle ohne Sortierfunktion muss die Sortierung nicht anhand des Spaltenkopfs erkennbar sein. Die Inhalte sollten dennoch einer logischen / kontextabhängigen Sortierung folgen, die über die User Story definiert werden muss.

[Grafik Tabellen-Header]

Spalten, die sich sortieren lassen, sind Tertiäre Buttons mit einem Sonderdesign. Die Punkt-Grafik neben dem Spaltentitel (Sortierindikator), gibt einen visuellen Hinweis, dass sich die Spalte sortieren lässt und muss als Layoutgrafik definiert sein. Die Grafik wechselt zu einem Pfeilsymbol, um die Sortierung anzuzeigen (aufsteigend oder absteigend). Der Alternativtext für die Pfeilgrafiken lautet: “Absteigend sortiert” bzw. “Aufsteigend sortiert”.

Bei sortierten Spalten gibt der Screenreader die Sortierung mit aus, bei unsortierten wird nur der Name ausgegeben.

Durch Klicken auf eine der Spaltenüberschriften, kann diese als Sortierkriterium ausgewählt werden. Durch erneutes Klicken kann die Sortierrichtung gewechselt werden. Daraufhin dreht sich der Pfeil in die entsprechend andere Richtung um.

Ist die Tabelle paginiert und der Nutzer befindet sich aktuell nicht auf Seite 1 und der Nutzer führt eine Umsortierung über den Spaltenheader aus, so wird dadurch automatisch wieder auf Seite 1 gewechselt.

Sind die Werte der Zellen rechtsbündig ausgerichtet, ist auch die Spaltenüberschrift rechtsbündig ausgerichtet und andersrum. Werden die Inhalte einer Spalte mit Einheiten, wie z.B. Währungen, Prozentangaben, oder einer Anzahl angegeben, so wird die Einheit nur im Spaltentitel und der Wert ohne Einheit in den Tabellenzellen aufgeführt.

Sonderfall: Werden innerhalb einer Spalte mehrere Einheiten verwendet, werden die Einheiten in die Zelle geschrieben. Spaltenüberschrift und Zelleninhalt werden dann linksbündig ausgerichtet. Diese Ausnahme gilt nur für die betroffene Spalte. Weitere Spalten der selben Tabelle folgen dem Standardverhalten.

Wenn ein Spaltentitel mehrzeilig wird, nimmt die gesamte Headerzeile diese Höhe ein und alle Spaltentitel sind an der Unterkante ausgerichtet.

[Grafik Header mit zweizeiliger Spalte]

Spalten, die aus Checkboxen oder Radiobuttons bestehen (Beispielsweise um ganze Zeilen zu selektieren) werden als eigene Spalte dargestellt. Spalten mit Radiobuttons haben den Spaltentitel “Auswahl”. Spalten aus Checkboxen haben nur eine Checkbox im Spaltentitel mit der Funktion: alle Einträge auswählen, solange nicht alle ausgewählt sind und alle Einträge abwählen, wenn alle Checkboxen ausgewählt sind. Diese Checkbox erhält einen Tooltip “Alle Einträge auswählen”. Bei der Navigation innerhalb der Zellen wird die Beschriftung “Auswahl” ausgegeben.

ℹ️ Änderung in Bold dargestellt

Verhalten bei Eingabe einer IBAN

Das IBAN-Eingabefeld ist ein Sonderfall des einzeiligen Eingabefeldes. Es unterscheidet sich in folgendem: 

Die Zeichenzahl ist auf 48 Zeichen begrenzt.

Erklärung: 34 Zeichen ist die maximale Zeichenzahl bei internationalen IBANs (bei deutschen IBANS 22 Stellen) + max. 9 Leerzeichen (für deutsche IBANS 5 Leerzeichen).

Nutzende können die IBAN mit oder ohne Leerzeichen eingeben. Buchstaben können groß oder klein geschrieben werden. Während der Eingabe wird keine Umformatierung vorgenommen.

Nach Verlassen des Feldes wird der Inhalt umformatiert: 

• Nach jedem vierten eingegebenen Zeichen wird ein Leerzeichen eingefügt. 
• Ggf. überflüssige Leerzeichen werden entfernt.
• Ggf. klein geschriebene Buchstaben zu Beginn der IBAN werden in Großbuchstaben umformatiert

[Grafik Ablauf der automatischen Formatierung]

Bei erneuten Fokuserhalt des Eingabefeldes bleiben die Leerzeichen erhalten und Nutzer:innen müssen diese ggf. händisch löschen. Wird das Feld wieder verlassen, werden erneut die Umformatierung (siehe oben) durchgeführt.

Wenn Nutzende den Feldinhalt kopieren, so wird der Wert inklusive Leerzeichen, so wie er im Feld steht, in die Zwischenablage eingefügt.

Der Speicherwert des Feldes in der Datenbank ist weiterhin der unformatierte Wert ohne Leerzeichen (ist noch technisch zu entscheiden).

Die Standardfehlermeldung bei falscher IBAN lautet, unabhängig davon, ob der Fehler durch fehlerhaftes Eingabeformat oder eine falsche Prüfsumme entsteht:

• “Keine gültige IBAN”

(siehe auch Meldungsliste aller Eingabe-/Auswahlelemente).

[Grafik Standard-Fehlermeldung bei fehlerhafter IBAN wurde aktualisiert]

ℹ️ Änderung in Bold dargestellt

Seiteninhalt: Datennavigation
(z.B. Tabelle, Liste, Baumstruktur, Kalender)

Die Datennavigation im Haupt-Seiteninhalt dient in der Regel zur Übersicht und Navigation über mehrere identische oder ähnliche Elemente. Sie füllt den gesamten Inhaltsbereich aus.

Je nach Inhalt können die Elemente in der Datenübersicht dargestellt sein als:

• Tabelle: Sortierbare mehrspaltige Aufstellung gleichartiger Elemente.
• Liste: Sortierbare einspaltige Aufstellung gleichartiger Elemente.
• Baumstruktur: Darstellung einer Baumstruktur als Graph, geschachtelte Liste o.ä.
• Kalenderansicht: Elemente können in Tages- oder Wochenansicht dargestellt sein.
• Andere: Darstellung mehrere gleichartiger oder unterschiedlicher Elemente

Die Auswahl eines Elements öffnet in der Regel ein Formular, das die Objektdetails anzeigt und bearbeitbar macht. In der Regel öffnet sich das Detailformular des ausgewählten Objekts im gleichen Browsertab. Nutzende haben jedoch immer auch die Möglichkeit, die Objektdetails in einem neuen Tab zu öffnen (je nach Element durch Browsernatives- oder Gefa-internes Kontextmenü.

Gegebenenfalls kann aus der Datennavigation auch eine Neuanlage ausgelöst werden, die dann ein Formular zur Neuanlage öffnet (siehe unten). Diese öffnet sich immer im gleichen Browsertab.

[Grafik Navigation und Inhaltsbereich]

Seiteninhalt Formular

Formulare bestehen immer aus folgenden Bereichen:

• Titelbereich (Formular Header), welcher den Formulartitel sowie optional weitere Aktionen enthält, welche das ganze Formular betreffen
• Inhaltsbereich mit beliebig vielen Anzeige- und/oder Eingabeelementen, optional in Zwischensektionen (Akkordeons) untergliedert
• Fußleiste mit Aktionsbuttons (Formular Footer)

Formulare können verwendet werden für Haupt-, Unter- oder Nebenobjekte (siehe Objekttypen).
Dabei wird jeweils nochmal unterschieden zwischen Anlage/Hinzufügen/Zuordnung eines neuen Objekts und der Bearbeitung eines existierenden.
Abhängig vom jeweiligen Anwendungsfall gelten unterschiedliche Formulierungsregeln für den Formulartitel sowie die Primärbuttons im Formular Footer. Außerdem unterscheiden sich Navigation und Fokussetzung nach Ausführen der Aktionen im Footer von Fall zu Fall (siehe Formular Footer > Tastaturbedienung).

Modaler Meldungsdialog

Einfache Dialoge dienen der Information des Nutzers während der Bearbeitung der eigentlichen Inhalte, z.B. um auf Fehler oder Entscheidungen hinzuweisen. Im Unterschied zu modalen Formularen (siehe unten) werden in ihnen aber keine Inhalte bearbeitet.

Einfache Dialoge

• Sind immer als Popup gelöst, das sich mit halbtransparentem Overlay über die gesamte Oberfläche einblendet.
• Sind modal, d.h. benötigen eine Entscheidung oder Zurkenntnisnahme durch Nutzende.

Dialogtypen

• Sicherheitsabfrage: Entscheidung zwischen Fortfahren und Abbrechen
• Hinweis: Zurkenntnisnahme (Standardaktion “Okay”)
• Fehler: Zurkenntnisnahme (Standardaktion “Okay”)

Weitere Details siehe Dialoge und Formulierungsregeln für die jeweiligen Meldungstypen.

Modales Formular

Formulare können auch modal eingeblendet werden. Sie werden dann wie alle Modale über die Benutzeroberfläche eingeblendet und erfordern eine Interaktion. Im Unterschied zu modalen Meldungsdialogen (siehe oben) enthalten modale Formulare Eingabefelder, und richten sich in ihrem Design nach Formularen.

Ob ein Formular modal oder auf einer Unterseite dargestellt wird, wird in der Regel durch dessen Inhaltsumfang bestimmt (Wenig Inhalt > eher Modal; viel Inhalt > eher Unterseite, siehe Seitentyp: Modul-Unterseite vom Typ Formular).

Anwendungsfälle für modale Formulare können beispielsweise das Hinzufügen eines neuen- oder Bearbeiten eines extistierenden Objekts innerhalb eines Formulars sein. Aufgerufen werden sie in diesem Fall über Buttons im übergeordneten Formular (diese können auch Teil von Tabellen oder Karten im Formular sein). Auch ein Modalaufruf von einer Datenübersicht aus bspw. über Buttons oder Pop-Up-Menüs ist möglich.st aktiv, nachdem mindestens ein Feld editiert wurde. Nach Ausführen der Aktion wird das Objekt hinzugefügt und das Formular wird geschlossen. Es ist anschließend wieder die Seite sichtbar, von der aus das Modal geöffnet wurde und das neu angelegte Objekte ist auf der Seite zu sehen (in der Regel in einer Tabelle).

Abhängig vom jeweiligen Anwendungsfall gelten unterschiedliche Formulierungsregeln für den Formulartitel sowie die Primärbuttons im Formular Footer. Außerdem unterscheiden sich Navigation und Fokussetzung nach Ausführen der Aktionen im Footer von Fall zu Fall (siehe Formular Footer > Tastaturbedienung).

Wenn modale Formulare Teil eines übergeordneten Formulars/Prozesses sind, findet hier im Regelfall kein Speichern statt, sondern Eingaben und Änderungen werden nur bestätigt. Erst nach Rückkehr ins übergeordnete Objekt können die Änderungen final gespeichert werden. (Ausnahmen, in denen in Modalen direkt gespeichert wird sind in seltenen Fällen möglich)

[Grafik Fall 1]

[Grafik Fall 2]

Sprung in und aus einem Element

Wird ein Objekt aus der Datennavigation ausgewählt, öffnet sich ein entsprechendes Formular – entweder im Modal oder auf einer Unterseite.

Falls das Formular sich auf einer Unterseite öffnet, so blendet sich darüber ein Objektpfad ein (ähnlich Breadcrumbs), der alle übergeordneten Objekte bzw. Ebenen anzeigt und navigierbar macht.

Falls fachlich gewünscht, kann neben dem Formular zusätzlich eine Schnellnavigations-Sidebar mit der Datenübersicht in Listenform angezeigt werden (siehe unten). Nicht vorkommen kann die Sidebar bei modalen Formularen.

Die Fußzeile eines Formulars enthält Schaltflächen zum Schließen und Speichern. Nach Speichern eines Objektformulars bleibt dieses geöffnet und der Speichern-Button zeigt das erfolgreich durchgeführte Speichern an (siehe Formular-Fußzeile). Nach Schließen wird zur Datenübersicht zurücknavigiert.
Zur Fokussetzung nach Ausführen der Aktionen im Formularfoooter siehe Formular Fußzeile > Tastaturbedienung.

Bei Abbruch über die Schließen-Schaltfläche, den Objekpfad, oder den Zurück-Button des Browsers erfolgt bei ungespeicherten Änderungen eine Sicherheitsabfrage (siehe Modaldialoge).

[Grafik Benennung und Speicherverhalten wurde aktualisiert]

Neuanlage von Objekten und Unterobjekten

Ein Neuanlage-Formular kann vollflächig, modal oder als Seite mit Schnellnavigations-Sidebar geöffnet werden.

Im Fall einer Neuanlage mit Schnellnavigations-Sidebar, dient die Datenübersicht in der Sidebar ausschließlich der Übersicht der bereits angelegten Daten. Auswählen eines Objekts in der Datenübersicht resultiert in einer Sicherheitsabfrage und anschließendem Abbruch der Neuanlage.

Innerhalb eines Neuanlage-Formular kann bei komplexerem Inhalt auch mit Unterformularen gearbeitet werden. (Beispiel: Neuanlage einer Person > Hinzufügen von 1-n Kontoverbindungen). 

Wenn diese Unterobjekte aufgrund ihrer Inhaltsmenge oder Art nicht als Formularfeldgruppe innerhalb des Formulars darstellbar sind, so können sie dargestellt werden als:

• Modale Formulare
• Vollbild-Formulare auf neuer Seite

In Unterformularen führen jeweils die Buttons Hinzufügen bzw. Schließen (mit Sicherheitsabfrage) zum Haupt-Formular zurück. Auf dem Hauptformular sind die angelegten Unterobjekte meist tabellarisch dargestellt und können auch nachträglich noch bearbeitet oder gelöscht werden.

Durch Ausführen der Aktion “Anlegen” im Hauptformular wird dessen Inhalt inklusive der Inhalte aller ggf. enthaltenen Unterobjekte gespeichert und angelegt. Nach Rückkehr in die Datenübersicht informiert ein Bestätigungsbanner über die erfolgreiche Anlage des Objekts.
Hinweis: Das Bestätigungsbanner wird nur nach Anlage von Hauptobjekten, nicht aber nach Hinzufügen von Unterobjekten und anschließender Rückkehr ins Elternformular angezeigt.
Zur Fokussetzung nach Ausführen der Aktionsbuttons in Haupt- sowie Unterformularen siehe Formular Fußzeile > Tastaturbedienung.

[Grafik Neuanlage mit modal angelegten Objekten]

[Grafik Neuanlage mit Unterobjekten in Vollbild-Formular]

Wird eine Neuanlage nicht von einer Datenübersichts-Seite aus geöffnet sondern über den Neuanlage-Button in der Schnellnavigations-Sidebar, so kehren Nutzende nach Abschluss der Neuanlage (“Anlegen” oder “Schließen”) trotzdem auf die Datenübersichts-Seite zurück (NICHT wieder auf der vorherigen Maske mit Schnellnavigations-Sidebar).

Zusatzhinweis: Je nach fachlicher Anforderung kann die Neuanlage als Modal, als Seite mit Splitview oder auf ganzer Seite aufgehen. Falls die Neuanlage ebenfalls im Splitview dargestellt ist, wird das Platzhalterelement dazu in der Liste an erster Stelle angezeigt (siehe Element Liste).

Wird der Neuanlage-Button gedrückt und es liegen ungespeicherte Änderungen im aktuell geöffneten Formular vor, so erscheint vor Öffnen der Neuanlage eine Sicherheitsabfrage (siehe Modaldialoge).

Alternativ kann eine Neuanlage auch als geführter Neuanlageprozess dargestellt werden (siehe unten: Wizard/Prozess).

[Grafik Neuanlage von Hauptseite oder aus Splitview - A (Neuanlage ohne Splitview)]

[Grafik Neuanlage von Hauptseite oder aus Splitview B (Neuanlage mit Splitview)]

Bearbeiten eines bereits angelegten Objekts mit Unterobjekt

Das Detailformular eines Objekts kann vollflächig oder als Seite mit Schnellnavigations-Sidebar geöffnet werden oder in Ausnahmefällen auch als modales Formular geöffnet werden.

Die Auswahl eines anderen Objekts in der Schnellnavigations-Sidebar führt zum Wechsel des geöffneten Formulars. Falls bereits Änderungen vorliegen, so erscheint vor Wechsel des Formulars ein Modaldialog vom Typ Sicherheitsabfrage.

Vom Detailformular des Objekts aus können (falls vorhanden) Unterobjekte geöffnet oder bearbeitet werden. Diese können, je nach Inhaltsmenge und Art geöffnet werden als: 

• Modale Formulare
• Vollbild-Formulare auf neuer Seite

Die Änderungen in Unterformularen müssen zunächst bestätigt werden (Button “Übernehmen”). Erst durch Ausfühen der Aktion “Speichern” im Hauptformular werden die Änderungen am Objekt inklusive aller Unterobjekte gespeichert. 

Wichtig: Die Absprungpunkte zu Kindobjekten eines Detailformulars müssen immer als Buttons dargestellt sein. Wenn als Link dargestellt, kann nicht verhindert werden, dass Unterobjekte in neuen Tabs geöffnet werden können, wodurch die eingegebenen Daten des Haupt- oder Unterformulars verloren gehen könnten. 

Wird eine der Formularaktionen (Hinzufügen/Übernehmen/Schließen/Entfernen) im Unterobjekt ausgeführt, so schließt sich das Unterobjekt und Nutzende werden zum Elternformular zurückgeleitet. Zur Fokussetzung nach Ausführen der Aktionsbuttons siehe Formular Fußzeile > Tastaturbedienung und Konzept für Löschen und Entfernen.

[Grafik Unterobjekt zu einem Objekt hinzufügen]

[Grafik Unterobjekt eines Objekts bearbeiten]

[Grafik Detailformular mit Schnellnavigations-sidebar und Unterobjekten]

Zuordnung und Bearbeitung von Nebenobjekten

Dem Hauptobjekt nebengeordnete Objekte können über Links im Formular erreicht werden. 

Es öffnen sich Unterseiten, auf denen Objekte, die auch an anderer Stelle in GeFa verwaltet werden können, dem Hauptobjekt zugeordnet und editiert werden können. 

Es handelt sich also um einen Auszug aus einer Komplett-Liste, welche auf die dem Hauptformular zugeordneten Objekte hin gefiltert ist. Der Seitentitel lautet jeweils “[Objekttyp] „[Bezeichnung Hauptobjekt]””. Beispiel:

• Besetzung „Abteilung Zivilsachen” (Die Seite enthält eine Liste von Personen, die im Modul Personenverwaltung angelegt wurden, jedoch in der Gerichtsverwaltung der Abteilung zugeordnet werden können.)

Auf Unterseiten dieser Art können neue Objekte zugeordnet, bereits zugeordnete bearbeitet bzw. Zuordnungen wieder aufgehoben werden. 

Wurden in Hauptformular bereits Änderungen durchgeführt, so müssen diese vor Absprung in eine Unterseite erst gespeichert werden. Falls dies noch nicht geschehen ist, erscheint ein Modaldialog vom Typ Sicherheitsabfrage.

Von den Unterseiten kann über die Pfadnavigation zurück zum Hauptformular navigiert werden. 

Die Zuordnung von Nebenobjekten ist meist erst nach vollständiger Anlage eines Objekts möglich. In der Neuanlage werden die entsprechenden Absprung-Optionen noch nicht angeboten bzw. als deaktiviert und ggf. mit Hinweistext “erst nach Anlage des Objekts möglich” angezeigt.

Hinweis: Durch die getrennte Datenhaltung ist es auch möglich, dass Nebenobjekte in einem neuen Tab geöffnet und parallel bearbeitet werden können, ohne dass Daten des Hauptformulars dadurch verloren gehen können.

Nach Abschluss einer Neu-Zuordnung wird zur Datenübersicht zurückgekehrt (= in diesem Fall die dem Hauptobjekt untergeordnete Übersicht der Nebenobjekte) und ein Bestätigungsbanner informiert über die erfolgreich ausgeführte Aktion (siehe Element “Bestätigungsbanner”).

Zur Fokussetzung nach Ausführen aller Aktionsbuttons im Formular (“Schließen” sowie “Zuordnen” in Neu-Zuordnungen bzw. “Speichern” bei Bearbeitung existierender Zuordnungen) sie Formular Fußzeile > Tastaturbedienung.

[Grafik Detailformular mit Unter- und neben bzw. zugeordneten Objekten]

Wizard/Prozess (z.B. bei Neuanlage)

Komplexe Objekte oder Prozesse mit Abhängigkeiten untereinander können oft schwer in einem statischen Formular abgebildet werden. In diesem Fall kann ein “Wizard”/Prozess verwendet werden.

Der Prozess oder Neuanlageprozess wird schrittweise, mittels einer Folge von Formularen bearbeitet. 

Dabei können Dateneingaben oder Abfragen in einem Schritt die nachfolgenden Schritte verändern. Beispielsweise könnte die Auswahl des anzulegenden Objekttyps in Schritt 1 zu verschiedenen Formularen in den Schritten 2-n führen.

Die Formulare innerhalb der Schritte enthalten die Optionen:

• Weiter: Einen Schritt weiter, bzw. beim letzten Schritt abschließen
• Zurück: Einen Schritt zurück
• Abbrechen: Gesamtprozess abbrechen

Zusätzlich kann der Fortschritt als Text (Schritt 3/4) und/oder Navigationselement eingeblendet sein.

Aus Sicht des Objektpfads handelt es sich beim gesamten Prozess um eine Ebene.

Nach Abschluss einer Neuanlage wird standardmäßig in die Datenübersicht zurückgekehrt. Nach Rückkehr informiert ein Bestätigungsbanner über der Tabelle/Liste/Baumstruktur/Kalender über die erfolgreiche Neuanlage und dieses ist fokussiert (siehe auch Element Bestätigungsbanner).
Sofern fachlich sinnvoll, kann nach Abschluss eines Wizards statt der Datenübersicht auch das gerade angelegte bzw. bearbeitete Objekt geöffnet werden (ist in Userstories zu beschreiben). In diesem Fall gilt die Standardfokussetzung des jeweiligen Seitentyps (siehe Seitentypen).

Wenn der Wizard über die “Schließen”-Schaltfläche verlassen wird, wird die vorher geöffnete Seite, von der aus der Wizard geöffnet wurde, wieder angezeigt. Falls bereits Eingaben gemacht wurden, erscheint vorher eine Sicherheitsabfrage. Zur anschließenden Fokussetzung siehe Element “Wizard Header”.

[Grafik Neuanlage mit Wizard]

ℹ️ Änderung in Bold dargestellt

Einleitung

Der Wizard erlaubt es, lange und komplexe Formulare in einzelne Schritte aufzuteilen um die Bearbeitung zu erleichtern.

Der Benutzer wird durch das Formular geführt und Eingabefelder mit Abhängigkeiten zu anderen Angaben können auf mehrere Schritte verteilt werden. Ein Wizard schließt standardmäßig mit einer Zusammenfassung ab, auf der die Eingaben überprüft werden können.

[Grafik Wizard-Element]

Zusammenfassungsseite

Auf der Zusammenfassungsseite (sofern vorhanden) werden die Eingaben der vorherigen Arbeitsschritte als Read-only Ansicht dargestellt. 

Um Fehler bearbeiten zu können, enthält jeder Abschnitt einen Button, der den zugehörigen Arbeitsschritt aufruft. 

Wird ein früherer Arbeitsschritt aufgerufen, kann von diesem auch wieder direkt zur Zusammenfassung navigiert werden, soweit die Bearbeitung keine neuen Angaben auf anderen Seiten erfordert. Alle Eingaben bleiben erhalten. 

(Im Abschnitt “Änderungen auf besuchten Seiten” wird beschrieben, wie sich die Navigation verhält, wenn Angaben bearbeitet werden, die andere Arbeitsschritte beeinflussen.)

Erst nach Klick auf den primären Aktionsbutton (Wording bspw. Anlegen/Erledigen) auf der Zusammenfassungsseite (bzw. auf der letzten Wizardseite) werden Daten auf die Datenbank gespeichert.

Sonderfall: Liegt die Hauptaufgabe des Wizards darin Daten zu überprüfen (sind also mehr als 50% der Formularelemente vorbefüllt oder nicht editierbar), dann kann auf die Zusammenfassungsseite verzichtet werden. Alle Validierungen, die sonst auf der Zusammenfassungsseite durchgeführt werden, werden dann auf der letzten Seite des Wizards durchgeführt.

[Grafik Zusammenfassungsseite]

[Grafik Zusammenfassungsseite reponsiv]

Wizard Formular Footer (Fußzeile)

Der Wizard-Formular Footer enthält auf Formularseiten die Buttons: “Rückgängig machen”, “Wiederholen”, “Zurück” und “Weiter”.

Der “Weiter” Button wird aktiv, auch wenn noch keine Änderungen vorgenommen wurden.

Auf der ersten Seite im Wizard, ist der “Zurück” Button immer deaktiviert.

[Grafik Footer Formularseiten]

ℹ️ Änderung in Bold dargestellt

Einleitung

Der Hauptinhalt dieses Seitentyps kann eine Liste, Tabelle, Baumstruktur oder Kalenderansicht enthalten. 

Welcher Typ im jeweiligen Modul verwendet wird und ob ggf. ein Wechsel zwischen diesen Darstellungsformen möglich sein soll, ist vom jeweiligen Teilprojekt zu definieren.

Ansichts-Wechsel-Schalter (optional)

Über diesen Auswahlschalter kann (falls fachlich im jeweiligen Modul vorgesehen) zwischen verschiedenen Ansichten wie beispielsweise einer Tabellen-, Listen-, Baum- oder Kalenderdarstellung gewechselt werden (siehe Auswahlschalter).

Funktionsbutton (nur im Modul KTR in der Tabellenansicht zur Terminsfindung)

Dieser Button öffnet ein Modal, welches beim Finden freier Terminszeiträume unterstützt (siehe Buttons).

Inhaltsbereich (Tabelle/Liste/Baumstruktur/Kalender)

Im Inhaltsbereich werden alle Elemente angezeigt, die zu den oberhalb definierten Such- und Filterkriterien passen (siehe Tabellen/Listen/Baumstrukturen/Kalender)

Detaildefinition für Kalender ist aktuell in Arbeit.

Responsives Verhalten

Bei allen Fensterbreiten überhalb von 720 Pixeln gilt:

[Grafik Responsives Verhalten 1]

Zwischen Suchfeld und Neuanlage-Button + Ansichts-Switch bleibt ein Mindestabstand von 16 Pixeln. Das Suchfeld wird ggf. kleiner. Sobald das Suchfeld seine minimale Größe von 212 Pixeln nicht mehr erreichen kann, wird der Neuanlage-Button zu einem Primären Button ohne Text und enthält nur noch ein Plus-Icon. Der Tooltip-Text lautet dann “[Objekt] anlegen”. Handelt es sich bei dem Neuanlage-Button um einen Button mit Untermenü, so wird nur noch das Dreiecks-Icon angezeigt und der Tooltip-Text entspricht dem vorherigen Buttontext.

Ab einer Fensterbreite unterhalb von 720 Pixeln gilt:

• Der Funktionsbutton (KTR) wird zu einem reinen Icon-Button mit Such-Icon und dem vorherigen Buttontext als Alternativtext.

[Grafik ResponsivesVerhalten 2]

Ab einer Fensterbreite unterhalb von 400 Pixeln gilt:

• Ein 16px-Einrückung (margin) der Elemente Suchfeld (links) Neuanlage-Button + Ansichts-Switch (rechts), Filter (links und rechts) und [Anzahl] Einträge (links und rechts) wird entfernt und die Elemente sitzen jeweils bündig auf dem Spaltenraster.
• Der Ansichts-Switch wechselt zur Responsiven Version, in der er als Einfachauswahlfeld funktioniert.
• Die Elemente [Anzahl] Einträge und Sortierfunktion werden untereinander statt nebeneinander angeordnet.
• Bei Baumstrukturen: Der Alle Auf/Zuklappen-Button wird als reiner Icon-Button ohne Text dargestellt.

[Grafik ResponsivesVerhalten 3]

ℹ️ Änderung in Bold dargestellt

ℹ️ Änderung in Bold dargestellt

Verhalten

Es wird immer die Objektstruktur (Vererbung/Einordnung) und nicht die Navigationsstruktur (welche Masken wurden geklickt) dargestellt. Der Aufbau als Link-Liste ermöglicht es gleichzeitig diese übergeordneten Bereiche direkt anzusteuern.

Das letzte Element stellt immer die aktuelle Seite dar und ist nicht interaktiv. Es wird immer der Text “[Aktuell geöffnete Seite]” angezeigt.

Ausnahme: Auf Modul-Unterseiten, wo im Seitentitel noch der Name der vorher geöffneten Seite (übergeordnetes Objekt) in Anführungsstrichen angehängt wird, wird dieser Anhang in der Pfadnavigation weggelassen, um Dopplung von Information zu vermeiden.

ℹ️ Änderung in Bold dargestellt

Alle Auswählen

In Mehrfachauswahlfeldern wird vor dem ersten Eintrag immer die Alle-Auswählen-Option angeboten. Dafür trägt die erste Checkbox die Bezeichnung “Alle Einträge auswählen” und darunter wird eine graue Linie angezeigt. Diese dient nur zur visuellen Darstellung.

Wird die Checkbox im Alle-auswählen-Eintrag aktiviert, so werden alle im Dropdown enthaltenen anderen Einträge automatisch auf “Ausgewählt” gesetzt. Wird die Checkbox wieder deaktiviert, so werden alle im Dropdown enthaltenen Elemente auf “Nicht ausgewählt” gesetzt. Wurden alle Werte selektiert, so wird im Auswahlfeld (egal ob Ausklappliste geöffnet oder geschlossen) das Wort “Alle” angezeigt, anstatt jeden Einzelwert zu listen. Dies gilt jedoch nur für bearbeitbare Felder.

ℹ️ Änderung in Bold dargestellt

Verhalten

[Neuer Abschnitt Sortierung von Elementgruppen hinzugefügt]

Sortierung von Elementgruppen

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.

(...)

Verhalten Read-Only Einträge

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.

[Grafik Eintrag ersetzen]

[Grafik Eintrag ersetzen mit mehreren Attributen hinzugefügt]

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 „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.

[Grafik Beispiele von Eintragsersetzungen]

[Grafik Beispiel von Eintragsersetzungen mit mehreren Attributen hinzugefügt]

(...)

Responsives Verhalten von Karten

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 “Formular Footer: Tastaturbedienung” und “(Navigationskonzept) Entfernen von Unterobjekten”).

 ℹ️ Änderung in Bold dargestellt

Aufbau

[Grafik Aufbau Tabelle wurde aktualisiert]

1. Ansichtswechsel-Schalter (optional)
2. Neuanlage-Button (optional)
3. Suche (optional)
4. Filter (optional)
5. Text “[Anzahl] Einträge” (nicht fokussierbar)
6. Funktionsbutton (optional - aktuell nur im Modul KTR zur Terminsfindung über Tabellen zulässig)
7. Menu-Button “Tabellen-Einstellungen”
8. Tabellen-Header
9. Tabelleninhalt
10. Tabellen-Footer

[Grafik Aufbau Bestätigungsbanner]

1. Häkchen-Symbol
2. Bestätigungstext
3. Schließen-Symbol

[Grafik Mehrfachauswahl-Fußzeile]

1. [Anzahl] Ausgewählte Elemente
2. “Auswahl aufheben”-Button
3. 1-n Aktionsbuttons

Verhalten

Jede Tabelle besitzt eine Header-Zeile, wo jede Spalte eine kurze sowie aussagekräftige Spaltenüberschrift enthält. Bei langen Tabellen kommt noch ein Footer hinzu, der die Navigation der Paginierung enthält. 

Der Header verhält sich sticky und bleibt beim Scrollen immer sichtbar.

Jede Tabelle trägt eine visuell nicht sichtbare programmatische Beschriftung. Diese sollte identisch sein mit der visuell sichtbaren Beschriftung, welche die Tabelle inhaltlich entweder direkt (z. B. Tabellenüberschrift) oder im Kontext (z. B. Seitentitel) beschreibt. Die sichtbare Beschriftung kann sein:

• Seitentitel (bei Tabellen auf Modul-Startseiten bzw. Modul-Unterseiten, wenn unter dem Seitentitel keine Tabs vorkommen)
• Beschriftung des aktiven Tabs (bei Tabellen auf Modul-Startseiten bzw. Modul-Unterseiten mit Tabs unter dem Seitentitel)
• Akkordeontitel (bei Tabellen in Formularen, die sich direkt einem Akkordeon unterordnen)
• Tabellenüberschrift (in Formularen bei Tabellen, die sich nicht direkt unter einem Akkordeon befinden)

In der Regel ist die erste Spalte als Row-Header definiert und enthält die Haupt-Informationen, die die Zeile aussagekräftig beschreibt. Wenn eine zusätzliche Spalte mit Radiobuttons oder Checkboxen vorangestellt wird, so ist die zweite Spalte der Row-Header.

In einer nächsten Implementierung sollten Row-Header als auch eine potentielle zusätzliche Checkbox-/Radiobutton-Spalte sticky umgesetzt werden.

Interaktive Elemente sollten so gering wie möglich eingesetzt werden und wo möglich die Anzahl von drei pro Zeile nicht überschreiten.

Oberhalb von Tabellen können sich außerdem Such- und Filtermöglichkeiten befinden, mit denen die Anzahl der angezeigten Inhalte reduziert werden kann. 
(siehe Elemente “Suchfeld” und “Filter”) 
(“Such- und Filterergebnisanzeige” in der Tabelle siehe unten)

Die Elementreihenfolge ist wie folgt (definiert die Vorlesereihenfolge für Screenreader und Tab-Reihenfolge, falls fokussierbare Elemente enthalten sind):

1. Ansichtswechsel-Schalter (optional)
2. Neuanlage-Button (optional)
3. Suche (optional)
4. Filter (optional)
5. Text “[Anzahl] Einträge” (nicht fokussierbar)
6. Funktionsbutton (optional - aktuell nur im Modul KTR zur Terminsfindung über Tabellen zulässig)
7. Menu-Button “Tabellen-Einstellungen”
8. Tabellen-Header
9. Tabelleninhalt
10. Tabellen-Footer
11. Hinzufügen-Button (optional - Wird eine Tabelle innerhalb eines Formulars angezeigt, so ist der Hinzufügen-Button immer direkt unterhalb der Tabelle positioniert)

Der Text “[Anzahl] Einträge” oberhalb der Tabelle ist immer verpflichtend anzuzeigen (in Formularen oder Hauptseiten, mit oder ohne Such- und Filtermöglichkeiten).
Falls genau ein Eintrag vorhanden ist, wird das Wort “Eintrag” statt “Einträge verwendet.
Der Text “[Anzahl] Einträge” entspricht visuell dem Schrifttyp “Subhead”. Die semantische Überschriftenauszeichnung variiert je nach Seitentyp (siehe entsprechender Seitenaufbau).

[Grafik Tabellen in Formularen]

ℹ️ Änderung in Bold dargestellt

Positionierung

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.

Benennung der Meldungen

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

[Grafik Unabhängige Validierungsfehler]

[Grafik Zusammengesetzte Eingabe existiert bereits]

[Grafik Beispiel für fehlerhafte Unterobjekte in einer Formulartabelle]

[Grafik Fehlermeldungsbereich in Formularen (Fehlerbanner)]

[Grafik Masse der Fehlermeldungen]

ℹ️ Änderung in Bold dargestellt

Sortierung

Für Komponenten mit Sortiermöglichkeit gelten folgende Standardsortierregeln (abweichendes Verhalten muss in User Stories definiert werden):

• Einträge ohne Zeitangaben werden alphanumerisch aufsteigend nach ISO/IEC 14651:2011 case-insensitive sortiert.
• Einträge mit Zeitangaben werden chronologisch absteigend sortiert (neue Einträge zuerst).
• Als sekundäres Sortierkriterium wird standardmäßig die verknüpfte Datenbank-ID in absteigender Sortierung verwendet, welche immer eindeutig ist (damit ist sekundär in der Regel nach dem Anlagezeitpunkt des Objekts sortiert: neuestes zuerst). Dieses sekundäre Sortierkriterium kommt nur dann zum Tragen, wenn zwei Objekte, für das Attribut nach dem sortiert wird, den gleichen Wert besitzen. In User Stories kann auch ein anderes zweites oder drittes Sortierkriterium definiert werden, die Datenbank-ID wird dann als letztes Sortierkriterium verwendet.

[Grafik Sortierung wurde aktualisiert]

ℹ️ Änderung in Bold dargestellt

Aufbau

[Grafik Default + Long Title unter 1024 Pixel wurde aktualisiert]

1. Titel
2. Badges
3. Umsystem-Buttons
4. Verfahrenstabs

Titel

Der Titel besteht aus Aktenzeichen und Kurzrubrum. Er ist folgendermaßen aufgebaut: “[Aktenzeichen] – [Kläger/in] / [Beklagte/r] wg. [Streitgegenstand]”. Bei längerem Text bricht der Titel um und wird mehrzeilig. Der Titel ist als “H1” zu deklarieren, auch wenn es sich visuell um den Schrifttyp H3 handelt.

[Grafik Verfahrensheader Beispiel wurde aktualisiert]

Umsystem-Buttons

Je nach fachlicher Anforderung ist hier eine beliebige Anzahl an tertiären Buttons möglich. Diese sind als Liste umgesetzt. Jeder der Buttons öffnet ein externes System mit entsprechendem Verfahrenskontext. Die exakten Umsysteme sind fachlich zu definiert. Beispiele sind: eAkte, Textsystem, ...
(siehe auch Element “Buttons”)

Verhalten abhängig von Fensterbreite

[Grafik Verfahrensheader Large wurde aktualisiert]

• Die Breite des Platzes für den Titel ist abhängig von der Anzahl der vorhandenen Umsystem-Buttons. Bei ausreichendem Platz werden alle Buttons nebeneinander dargestellt.
• Sobald der Titel eine Breite von 720 Pixeln nicht mehr erreicht werden kann, wird aus den nebeneinanderliegen Umsystem-Buttons ein einziger sekundärer Button mit der Bezeichnung “Umsysteme” und dem Pfeil-Icon, welches zur Auszeichnung externen Links verwendet wird. Dieser verhält sich wie ein Pop-Up-Menu-Button. Wenn Nutzende darauf klicken, werden alle enthaltenen Umsystem-Einträge im Pop-Up-Menü gelistet.
• Sobald der Titel eine Breite von 400 Pixeln nicht mehr erreicht werden kann, wird aus dem Umsystem-Button ein Sekundärer Button ohne Text, bei dem nur noch das “Externer Link”-Icon sichtbar ist. Er hat den Tooltip “Umsysteme”.
• Ab einer Fensterbreite unter 480px verkleinert sich die Schriftgröße des Titels sowie vertikale Abstände.

[Grafik Default + Long Title wurde aktualisiert]

[Grafik Medium]

Verhalten abhängig von Fensterhöhe

• Ab einer Fensterhöhe unter 1024px verkleinert sich die Schriftgröße des Titels sowie vertikale Abstände innerhalb des Verfahrensheaders.

[Grafik Verfahrensheader large bei Fensterhöhe unter 1024 Pixel wurde aktualisiert]

[Grafik Verfahrensheader medium bei Fensterhöhe unter 1024 Pixel]

[Grafik Verfahrensheader small bei Fensterhöhe unter 1024 Pixel]

Tastaturbedienung

• Nach Öffnen der Verfahrensseite ist der Fokus auf dem ersten Verfahrenstab (Tastaturbedienung und Statuus siehe Element “Tabs”)
• Mit Shift-Tab kann zu den Umsystem-Buttons gesprungen werden. (Tastaturbedienung siehe “Buttons” und zur responsiven Version der Umsystem-Buttons siehe “Pop-Up-Menü”)

Mausbedienung

• Mausbedienung der Verfahrenstabs siehe Element “Tabs”
• Mausbedienung der Umsystem-Buttons siehe “Buttons” und zur responsiven Version siehe “Pop-Up-Menü”

Alle für Suchfelder in GeFa definierten Wildcards können auch hier genutzt werden (siehe Suchfeld > Wildcards).

Spezifikation > Verhalten 

 ℹ️ Änderung in Bold dargestellt

Durchsucht werden kann bei mehrzeiligen Ausklapplisteneinträgen immer nur der Wert in der ersten Zeile (In den Beispielen: “Raum 2.04” und “Nachname, Vorname”). Basierend auf fachlicher Anforderung sollte definiert werden, ob eine der folgenden Suchverhalten gilt:

• “Beinhaltet [...]” – Sucht nach Zeichenabfolgen, die irgendwo innerhalb der Bezeichnung vorkommen.
• “Startet mit [...]” – Sucht nur nach Zeichenabfolgen die am Anfang der Bezeichnung stehen. 
   

Falls nicht definiert gilt die Regel “Beinhaltet [Suchbegriff]”. 

Alle für Suchfelder in GeFa definierten Wildcards können auch in Comboboxen genutzt werden (siehe  > Wildcards).

Spezifikation > Verhalten > Verhalten des Suchparameter-Element

 ℹ️ Änderung in Bold dargestellt

Das Suchparameter-Element kommt ausschließlich in der erweiteten Suche zum Einsatz. Es ermöglicht es den Nutzenden gezielt mit Eingabe mehrerer Suchparameter eine große Menge von Ergebnissen einzuschränken und die Eingaben bei Bedarf schnell zu verändern.

Jedes Suchparameter-Element ist als Formularfeldgruppe umgesetzt und beinhaltet folgende Einzelelemente: 

• Titel: Dieser gibt den zu durchsuchenden Attributstyp an. 
• Eingabebereich: Dieser kann entweder ein einzelnes Eingabe- oder Auswahlfeld (alle Typen: Einzeiliges Eingabefeld, Einfach-, Mehrfach-, Baum-Auswahlfeld, Durchsuchbares Einfachauswahlfeld, Datums-/Uhrzeitfelder) bzw. ein Wertebereichs-Feld bestehend aus zwei Feld-Teilen beinhalten. Dabei wird bei allen Typen nur der Feldinhalt jedoch ohne das Feldlabel angezeigt, denn das Feldlabel ist immer mit dem Suchparameter-Titel identisch. Handelt es sich um ein Einzelfeld, so wird vom Screenreader bei fokussieren des Feldes immer das Wort “Wert” mit ausgelesen. Handelt es sich um ein Wertebereichs-Feld, so wird nur das Label des Teilfeldes (von bzw. bis) und kein zusätzliches Feldlabel ausgelesen. Die Teillabel der Einzelfelder bleiben dabei sichtbar und das originale Feldlabel des Wertebereichfelds wird komplett durch den Titel des Suchparameters ersetzt.
• (Optional) Einstellungen: Hier können über eine Pop-Up-Menü weitere Einstellungen zum Element vorgenommen werden. Die Beschriftung des Einstellungs-Buttons lautet immer “Einstellungen öffnen”. Beispiele: 
• • Bei Freitexteingaben kann im Einstellungsmenü zwischen verschiedenen Suchoptionen gewählt werden: Standardsuche (dieser Eintrag ist standardmäßig ausgewählt), Phonetische Suche und Ähnlichkeitssuche. (Detailbeschreibung des Menüs siehe Element Pop-Up Menü). Weitere Informationen zur Erklärung einer Einstellung können, falls benötigt über die Kontextsensitive Hilfe (Konzeption noch ausstehend) übermittelt werden. Wurde eine Suchoption gewählt, welche nicht die Standardsuche ist, dann erscheint neben dem Einstellungsrad ein Ausrufezeichen-Symbol. Der Tooltip des Einstellungs-Buttons wird dann geändert zu “Einstellungen öffnen ([Bezeichnung der Suche] aktiv)”. Dabei wird der Teil vor dem Zusatz (“Einstellungen öffnen”) in fetter Schrift dargestellt. Wird die Standardsuche wieder aktiviert, so verschwindet das Symbol und der Tooltip-Zusatz wieder.
  • Bei Zahlen- oder Datumseingaben kann über das Einstellungsmenü zwischen Einzelwert und Wertebereich gewechselt werden. Standardmäßig ist “Exakter Wert” aktiv (Detailbeschreibung des Menüs siehe Element Pop-Up Menü).
• (Optional) Button “Suchparameter entfernen”: Dieser Button wird nur bei Suchparametern angezeigt, die von Nutzenden manuell hinzugefügt wurden. Der Alternativtext lautet “Suchparameter „[Titel]” entfernen”.

Spezifikation > Verhalten > Sonderfall: Eingabebereich mit Pop-Up-Menü

 ℹ️ Änderung in Bold dargestellt

In Ausnahmefällen kann der Eingabebereich auch einen Button enthalten, welcher das Öffnen eines Pop-Up-Menüs auslöst. Visuell wird der Button identisch zum Einfachauswahlfeld angezeigt. Die Screenreaderausgabe bei Fokuserhalt des Eingabebereichs lautet in diesem Fall “Wert: [Buttontext]”. Das Wort “Wert:” wird nur vom Screenreader ausgegeben, jedoch nicht im Button angezeigt.
Im Pop-Up-Menü ist immer ein Eintrag als aktiv ausgewählt. Abhängig von der aktuellen Auswahl kann der Text des Buttons, welcher das Pop-Up-Menü öffnet, sich ändern. Die Auswahl eines Eintrags im Pop-Up-Menü kann entweder zum direkten Schießen des Pop-Ups und Übernahme des Wertes führen oder zum Öffnen eines Modals mit Zusatzoptionen. Im zweiten Fall findet die Übernahme des Wertes und ggf. Änderung des Buttontextes erst nach Ausführen der Primäraktion im Folgemodal statt. Der Tastaturfokus wird bei Öffnen eines Modals ins erste interaktive Element im Inhaltsbereich gelegt. Nach Abschluss der Primäraktion im Modal wird das Modal sowie Pop-Up-Menü geschlossen und der Fokus liegt wieder auf dem Button im Eingabebereich. Wird im Modal die Aktion “Schließen” ausgeführt so wird sowohl Modal als auch Pop-Up-Menü geschlossen und der Fokus liegt wieder auf dem Eingabebereich des Suchparameterelements. Die vorherige Auswahl im Pop wird nicht übernommen und der Buttontext bleibt der alte.
Standardmäßig entspricht der Buttontext immer der Primärinformation des ausgewählten Eintrags im Pop-Up-Menü. Wenn fachlich sinnvoll (z.B. nach Öffnen von Modalen) sind Abweichungen in Userstories zu beschreiben. Beispiel: Suchparameterelement “Zuständige Stelle” in erweiterter Suche: Aktion “Manuell auswählen” im Pop-Up-Menü öffnet Modal zur Stellenauswahl > Buttontext anschließend “Manuell ausgewählt ([Anzahl Stellen]).

[Grafik „Eingabebereich mit Umsetzung als Button & Pop-Up-Menü“ wurde hinzugefügt]

Spezifikation > Bedienung > Tastaturbedienung > Suchparameter-Element

 ℹ️ Änderung in Bold dargestellt

• Mit Tab wird das erste interaktive Element innerhalb eines Suchparameter-Elements fokussiert. 
• Drücken der Tab-Taste bei fokussiertem Suchparameter-Teilelement legt den Fokus auf das nächste interaktive Element in diesem Suchparameter-Element. Handelt es sich bei dem fokussierten Teil um den letzten, so wird der Fokus auf das darauf folgende interaktive Element gelegt (in das nächste Suchparameter-Element bzw. den “Suchparameter hinzufügen”-Button).
• Zur Tastaturbedienung im Eingabebereich siehe jeweiliges Element (Eingabefelder / Datumseingabe / Einfachauswahlfeld / Mehrfachauswahlfeld / Buttons)
• Zur Tastaturbedienung des Einstellungselements sowie Pop-Up-Menüs im Eingabebereich siehe Element . Ausnahme bei Pop-Up-Menüs im Eingabebereich kann Enter/Leertaste bei fokussiertem bereits selektierten Eintrag auch eine Aktion auslösen (bspw. Öffnen eines Modals). Dieser Fall ist in Userstories zu beschreiben.
• Nach Ausführen der Aktion “Suchparameter entfernen” wird das Suchparameter-Element entfernt und der Tastaturfokus wird auf das erste interaktive Element im darauf folgenden Suchparameter-Element gelegt. Handelt es sich bei dem entfernten Suchparameter um das letzte, so wird der Tastaturfokus auf den “Suchparameter hinzufügen”-Button gelegt.

Spezifikation > Bedienung > Mausbedienung > Suchparameter-Element

 ℹ️ Änderung in Bold dargestellt

• Durch einfachen Klick mit linker Maustaste auf einen interaktiven Teil des Suchparameter-Elements wird dieser fokussiert bzw. geöffnet (bei Auswahlfeldern).
• Bei einfachem Klick mit linker Maustaste auf den Suchparameter-Titel wird das erste interaktive Element in der Gruppe fokussiert.
• Zur Mausbedienung im Eingabebereich siehe jeweiliges Element (Eingabefelder / Datumseingabe / Einfachauswahlfeld / Mehrfachauswahlfeld / Buttons)
• Zur Mausbedienung des Einstellungselements sowie Pop-Up-Menüs im Eingabebereich siehe Element . Ausnahme bei Pop-Up-Menüs im Eingabebereich kann der Klick mit linker Maustaste auf einen bereits selektierten Eintrag auch eine Aktion auslösen (bspw. Öffnen eines Modals). Dieser Fall ist in Userstories zu beschreiben.

Spezifikation > Verhalten > Verhalten des Listen-Footers (Fußzeile) mit Paginierung

 ℹ️ Änderung in Bold dargestellt

Der Listenfooter mit Paginierung erscheint, sobald in einer Liste eine bestimme Eintragsanzahl überschritten wird. 

Der Listenfooter ist im Regelfall sticky und somit (sofern vorhanden) immer am Ende des Listenbereichs sichtbar. Ab einer Listenhöhe unter 400px ist die Paginierungsfußzeile nicht mehr sticky, scrollt mit der Gesamtliste mit und ist unter dem jeweils letzten Listeneintrag positioniert. 

Details siehe Navigationselement “”.

Spezifikation > Verhalten > Tabellhöhe und Scrollbarkeit

 ℹ️ Änderung in Bold dargestellt

Bei nicht-paginierten Tabellen/Listen (bis 10 Einträge) entspricht deren Höhe immer der summierten Eintragshöhe. 
Bei paginierten Tabellen/Listen (ab 11 Einträge) muss sichergestellt werden, dass sich er Paginations-Footer immer an der gleichen Stelle befindet und beim Wechseln zwischen Seiten nicht in der Y-Position springt. Daher haben paginierte Tabellen-/Listen immer eine fixe Höhe. Es wird dabei unterschieden zwischen Tabellen/Listen außerhalb von Formularen und Tabellen innerhalb von Formularen. Listen kommen innerhalb von Formularen nicht vor. Der Paginations-Footer ist in der Regel sticky, bis eine gewisse Tabellen-/Listenhöhe unterschritten wird (siehe Definitionen zur Paginierungsfußzeile bei Tabelle und Liste). 

[Grafik SCROLLVERHALTEN UND PAGINIERUNG EINER TABELLE]
[Grafik BEISPIEL TABELLE AUF KLEINEM BILDSCHIRM]

Außerhalb von Formularen gilt: 
- Tabellen/Listen mit bis zu 10 Einträgen sind nicht paginiert. Ihre Höhe entspricht der Summe Eintragshöhe. Ist im Seitenlayout zu wenig Platz in der Horizontalen zur Darstellung aller Einträge verfügbar, so wird die Liste scrollbar. 
- Tabellen/Listen mit über 10 Einträgen werden paginiert. Die Tabellen-/Listenhöhe passt sich dann immer dem maximal auf der Seite verfügbaren Platz an. Bei großen Fensterhöhen kann so ein nicht fokussierbarer Weißraum zwischen dem letzten Eintrag auf einer Seite und dem Paginationsfooter am unteren Seitenrand entstehen. Reicht die Tabellen-/Listenhöhe nicht aus, um alle Einträge auf einer Seite darzustellen, so wird die Tabelle/Liste bzw. die Seite scrollbar (für Details zum Scrollverhalten siehe auch Seitentypen “Unterseite eines Moduls: Formular mit Schnellnavigations-Sidebar” oder “Einstiegsseite eines Moduls: Typ Tabelle”).

Innerhalb von Formularen gilt: 
- Bei bis zu 10 Einträgen werden Tabellen nicht paginiert. Die Tabellen-/Listenhöhe entspricht der summierten Höhe aller Einträge. 
- Ab 11 Einträgen werden Tabellen paginiert. Die Tabellenhöhe ist fix und entspricht dem 5,5 fachen der Eintragshöhe.

Spezifikation > Bedienung

 ℹ️ Änderung in Bold dargestellt

Tastaturbedienung

• Tab fokussiert das erste interaktive Element der Paginierung.
• Nächster Tab springt zum nächsten interaktiven Element der Paginierung.
• Enter löst die fokussierte Aktion aus.
• Fokus bleibt nach Seitenwechsel auf dem ausgelösten Element, es ist jedoch nicht mehr interaktiv. Wenn der Listen/Tabellenfooter sticky ist (bei ausreichender Höhe), dann wird durch einem Seitenwechsel über den Paginierungsfooter die Scrollposition im Listen/Tabellen-Inhaltsbereich der neu geöffneten Seite zurückgesetzt, d. h. der oberste Listen- bzw. Tabelleneintrag auf der neu geöffneten Seite ist anschließend sichtbar. Falls der Listen/Tabellenfooter (auf Grund geringer Listen/Tabellenhöhe unter 400px) nicht mehr sticky ist, dann wird die Scrollposition beibehalten, damit der Tastaturfokus, welcher im Footer verbleibt, nicht aus dem sichtbaren Bereich verschwindet.
• Drücken der Home-Taste setzt den Tastaturfokus auf die ersten Seite.
• Mit End-Taste wird der Tastaturfokus auf die letzte Seite gesetzt.
• Für Tastaturbedienung und Fokussetzung innerhalb des “Ausgeblendete Seiten anzeigen”-Menüs siehe Pop-Up Menü
• Mit Tab-Taste kann der Ladezustand im Inhaltsbereich der Tabelle/Liste fokussiert werden.

• Klick mit linker Maustaste löst die Aktion aus.
• Fokus bleibt nach Seitenwechsel auf dem ausgelösten Element, es ist jedoch anschließend nicht mehr klickbar. Wenn der Listen/Tabellenfooter sticky ist (bei ausreichender Höhe), dann wird durch einem Seitenwechsel über den Paginierungsfooter die Scrollposition im Listen/Tabellen-Inhaltsbereich der neu geöffneten Seite zurückgesetzt, d. h. der oberste Listen- bzw. Tabelleneintrag auf der neu geöffneten Seite ist anschließend sichtbar. Falls der Listen/Tabellenfooter (auf Grund geringer Listen/Tabellenhöhe unter 400px) nicht mehr sticky ist, dann wird die Scrollposition beibehalten, damit der Tastaturfokus, welcher im Footer verbleibt, nicht aus dem sichtbaren Bereich verschwindet.
• Für Tastaturbedienung und Fokussetzung innerhalb des “Ausgeblendete Seiten anzeigen”-Menüs siehe Pop-Up Menü
• Klick mit linker Maustaste auf den Ladezustand einer Tabellen-/Listenseite fokussiert diesen.

 ℹ️ Änderung in Bold dargestellt

[Sektion Beere-Farbthema hinzugefügt]

[Sektion Wald-Farbthema hinzugefügt]

ℹ️ Änderung in Bold dargestellt

Namen

Namen sind einheitlich folgendermaßen darzustellen:  
“<Nachname>, <Titel> <Vorname> <Namensvorsatz>”

Der Titel wird in der Regel über ein optionales Freitextfeld erfasst, so dass keine Kurz-/Langschreibweisen vorliegen. Nutzende können sowohl “Prof.” als auch “Professor” eingeben und die gewählte Schreibweise wird 1 zu 1 übernommen. 

Beispiele: 

• Yilmaz, Karim
• Müller-Lüdenscheid, Henrik Paul
• Reis, Doktor Renata 
• Schmidt, Prof. Maria

Verwendung von natürlichen Personennamen in Browsertiteln 

Um den Schutz personenbezogener Daten zu gewährleisten, müssen Namen von Beteiligten im Browsertitel mit Initialen abgekürzt werden. Die Abkürzung setzt sich aus der abgekürzten Personenart und den Initialen des ersten Nach- und des ersten Vornamens zusammen. Titel, Namensvor- und Namenszusätze werden in der Abkürzung nicht berücksichtigt. Zwischen der abgekürzten Personenart und des Namens befindet sich ein Leerzeichen. 

Natürliche Person wird mit NP abgekürzt. 

Beispiele: 

• Yilmaz, Karim -> NP YM 
• Müller-Lüdenscheidt, Henrik Paul -> NP MH 
• Schmidt, Prof. Maria -> NP SM 
• Graf von Hinckelstein, Dr. Theo -> NP HT 

Verwendung von Bezeichnungen von juristischen Personen und Rechtsanwälten/Kanzleien

Namen von juristischen Personen werden ebenfalls im Browsertitel abgekürzt. Die Abkürzung setzt sich aus der abgekürzten Personenart und des ersten Buchstabens der Bezeichnung zusammen. Zwischen der abgekürzten Personenart und der Bezeichnung befindet sich ein Leerzeichen. 

Juristische Person wird mit JP abgekürzt.
Rechtsanwalt/Kanzlei wird mit RA/K abgekürzt. 

Beispiele: 

• Erdmann Betonstein GmbH -> JP E 
• Freshfields Bruckhaus Deringer Rechtsanwälte Steuerberater PartGmB -> RA/K F 
• Freie und Hansestadt Hamburg, vertreten durch die Behörde für.. -> JP F 
• HUK-Coburg Haftpflicht-Unterstützungs-Kasse... -> JP H 

Verwendung von Personennamen mit Auskunftssperre:

Bei Personen mit dem Status Auskunftssperre, wird nur das Wort “Person” im Browsertitel verwendet.

ichtlinien > Darstellung nicht verfügbarer Funktionalitäten > Ausführbarkeit von Aktionen

 ℹ️ Änderung in Bold dargestellt

Regel für die Darstellung von temporären oder permanent nicht verfügbarer Funktionalitäten (Buttons/Links/Tabs) in GeFa – Wann wird ausgeblendet, wann deaktiviert.

Grundsätzlich gilt: 

Ist eine Funktion auf Grund von fehlenden Berechtigungen für den Nutzer aktuell nicht verfügbar, so wird die Funktionalität auf der Seite als deaktiviert angezeigt. Beispiele: 

• Der Button “Verfahren anlegen” wird deaktiviert angezeigt, wenn ein Nutzer kein Recht zur Anlage von Verfahren besitzt. 
• Der Link “Verfahrenssperre” wird deaktiviert, wenn ein Nutzer kein Recht dazu hat, die von der Sperre ausgenommenen Personen eines Verfahrens zu sehen.

Ausnahme: Links innerhalb von Tabellenzellen werden bei fehlenden Rechten zum Öffnen als normaler Text (ohne Link) dargestellt. Beispiel:

• Für ein über die erweiterte Suche gefundenes Verfahren liegen keine Rechte zum Öffnen vor.

[Grafik „NUTZER HAT KEIN RECHT ZUM BEARBEITEN DES FORMULARS“ wurde hinzugefügt]

Ist eine Funktion auf Grund eines fachlich definierten Objektstatus nicht mehr verfügbar, kann aber über eine Änderung des Objektstatus potentiell wieder reaktiviert werden, so wird die entsprechende Funktion als deaktiviert angezeigt. Die Statusänderung zum Beispiel durch eine Nutzeraktion des aktuell angemeldeten Nutzers, eines anderen Nutzers (mit potentiell anderen Rechten) oder durch eine andere fachlich definierte Logik (z. B. Ablauf eines Gültigkeitszeitraums) erfolgen. Beispiele:

• Ein GVP im Status “Vorbereitet” kann zwar nicht mehr bearbeitet werden, kann jedoch vom Nutzer wieder in den bearbeitbaren Entwurfsstatus zurückgeholt werden.
• Ein Verfahren im Status “xxx” kann zwar nicht mehr bearbeitet werden, durch Änderung des Status zu “xxx” ist die Bearbeitung jedoch wieder möglich. 

[Grafik „FORMULAR IST AUF GRUND SEINES STATUS NICHT BEARBEITBAR & STATUS ÄNDERBAR“ wurde hinzugefügt]

Ist eine Funktion auf Grund eines fachlich definierten Objektstatus nicht mehr verfügbar und kann auch nicht durch eine Änderung des Objektstatus wieder reaktiviert werden, so wird die entsprechende Funktion komplett ausgeblendet. Beispiele: 

• Ein GVP im Status “In Verwendung” kann nachträglich nie mehr bearbeitet werden. 
• Eine Besetzungslisten-Zuordnung, deren Gültigkeitszeitraum einmal begonnen hat, kann nie mehr komplett gelöscht werden (nur beendet).
• Ein Verfahren im Status “xxx” kann nie mehr bearbeitet werden. 

(Details siehe Elemente “Formular-Fußzeile”, “Tabelle-Zellen” und “Tabellen Read-Only” und “Tabs”)

[Grafik „FORMULAR IST AUF GRUND SEINES STATUS NICHT BEARBEITBAR & STATUS NICHT ÄNDERBAR“ wurde hinzugefügt]

Modul-Links, welche in der Modulübersicht auf der GeFa-Startseite bzw. im GeFa-Hauptmenü vorkommen, werden komplett ausgeblendet (statt deaktiviert), wenn der Nutzer keine Berechtigung zum Öffnen dieses Moduls besitzt. Das selbe gilt für den Button “ Zentrale Administration öffnen im GeFa Hauptmenü”. 
Grund für diese Ausnahme ist, dass Hauptmenü- und Startseite für den Nutzer sehr schnell und mit wenig Scrollen navigierbar sein sollten. Die deaktivierte Anzeige von Module, für die kein Zugriffsrecht vorliegt, würden hier zu sehr von den wesentlichen und verfügbaren Einstiegsmöglichkeiten ablenken und wenig Mehrwert für die tägliche Arbeit bieten. Spontane Zugriffsrechtänderungen auf Modulebene kommen sehr selten bis nie vor, da die Modul-Zugriffsrechte in der Regel fix pro Nutzerrolle definiert sind: Zum Beispiel haben administrative Rollen Zugang zu Verwaltungsmodulen, aber nicht unbedingt zu Verfahrensmodulen und umgekehrt).
(siehe auch Navigationskonzept > Hauptmenü)

Richtlinien > Darstellung nicht verfügbarer Funktionalitäten > Darstellung von Informationen

 ℹ️ Änderung in Bold dargestellt

Regeln für die Darstellung von Informationen (z.B. Formularinhalte oder Inhalte von Tabellen/Listen/Baumstrukturen/Kalenderansichten), je nach Berechtigung des Nutzers:

Besitzt ein Nutzer Bearbeitungsrechte für gewisse Daten, so sind die entsprechenden Formularinhalte (Eingabe-/Auswahlelemente etc.) bearbeitbar. Links oder Buttons, welche zum Bearbeitungsformular des Objekts führen, sind aktiv und klickbar. Buttons zum Öffnen solcher Objekte sind im Regelfall mit “[Objektbezeichnung] bearbeiten” betitelt und enthalten ein Stift-Symbol.

[Grafik „FORMULAR MIT BEARBEITUNGSRECHTEN“ wurde hinzugefügt]

Besitzt ein Nutzer keine Bearbeitungsrechte für gewisse Daten, ist allerdings zum Lesen der Inhalte berechtigt, so sind die entsprechenden Formularinhalte (Eingabe-/Auswahlelemente etc.) im Read-Only-Zustand dargestellt. Links oder Buttons, welche zum Bearbeitungsformular des Objekts führen, sind aktiv und klickbar. Buttons zum Öffnen solcher Objekte sind im Regelfall mit “[Objektbezeichnung] anzeigen” betitelt und enthalten ein Auge-Symbol. Andere Funktionsbuttons innerhalb von Read-Only-Formularen (z. B. Funktionen wie “Hinzufügen”, “Duplizieren”, “Entfernen” etc.) werden deaktiviert angezeigt.

[Grafik „BEISPIEL EINES FORMULARS MIT NUR LESERECHTEN“ wurde hinzugefügt]

Es darf keine Aufrufmöglichkeiten für Objektformulare geben, die vom Nutzer weder gelesen noch bearbeitet werden dürfen. Wird eine solche Seite vom Nutzer über einen Direktlink aufgerufen, so erscheint die Seitenfüllende Fehlermeldung “Sie sind nicht authorisiert”. 

Dürfen einzelne Inhalte von Objekten in Übersichtstabellen/Listen/Baumstrukturen auf Grund von Berechtigungslimitierungen nicht angezeigt werden, so wird in an Stelle der gesperrten Werte ein Symbol mit dem Alternativtext “Keine Zugriffsrechte” angezeigt. Die Primärinformation eines Elements in Tabellen/Listen/Baumstrukturen (bei Tabellen der Row-Header) muss einen Inhalt haben, sonst wird das Element komplett ausgeblendet. 

[Grafik „TABELLE – EINZELNER EINTRAG OHNE LESERECHTE“ wurde hinzugefügt]

Wenn generell kein Recht zur Anzeige einer ganzen Seite vorliegt, dann wird die seitenfüllende Fehlermeldung mit dem Titel “Sie sind nicht authorisiert” angezeigt. (Details siehe Seitenfüllende Fehlermeldungen)

Spezifikation > Verhalten > Ablauf Front-/Backend-Validierung

 ℹ️ Änderung in Bold dargestellt

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 “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.

Spezifikation > Verhalten > Ablauf Front-/Backend-Validierung > 1. Frontend-Validierung

 ℹ️ Änderung in Bold dargestellt

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 “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 Buttons). 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”.

[Grafik „Fehlermeldung“]

[Grafik „Fehlermeldung auf kleinem Bildschirm“]

Spezifikation > Bedienung > Tastaturbedienung > Fehlermeldungsbereich in Formularen (Fehlerbanner)

 ℹ️ Änderung in Bold dargestellt

• 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 Spezifikationen zu  und ).
• 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 Spezifikationen zu Eingabe- und Auswahlfeldern).
• 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: 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)

Spezifikation > Bedienung > Mausbedienung > Fehlermeldungsbereich in Formularen (Fehlerbanner)

 ℹ️ Änderung in Bold dargestellt

• 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  und ).
• Klick mit linker Maustaste auf den Speichern-Button führt die Aktion aus (siehe auch 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.

Spezifikation > Verhalten > Verhalten von Validierungsfehlern an Formularfeldern

 ℹ️ Änderung in Bold dargestellt

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 werden Frontendvalidierungen zu folgenden Zeitpunkten 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, 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 auch ).

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 “Ablauf Front-/Backendvalidierung” und “Übergreifende Validierung zwischen Haupt- und Unterformularen”).

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

[Grafik „Eingabe“]

[Grafik „Auswahl“]

[Grafik „Mit Checkbox“]

[Grafik „Mit Radio-Button“]

Spezifikation > Verhalten > Fehlerfälle / Validierung

 ℹ️ Änderung in Bold dargestellt

Im Fehlerfall (Ablauf siehe “Formulare” > “Ablauf Front-/Backend-Validierung”) erscheint ein Ausrufezeichen-Icon mit erklärendem Text, dieses muss als Layoutgrafik deklariert werden.

[Grafik „Checkbox mit Fehlermeldung in den Varianten checked und unchecked“]

Die Standardfehlermeldung bei einer unbefüllten Checkboxgruppe lautet: “Mindestens eine Selektion erforderlich”. Bei einer einzelnen nicht befüllten Checkbox gilt die Standardmeldung “Pflichtfeld nicht befüllt” (siehe auch Meldungsliste aller Eingabe-/Auswahlelemente).

[Grafik „Checkboxgruppe mit Fehlermeldung“]

Während bei Einzelcheckboxen bereits bei Wertänderung validiert werden kann, findet bei Checkboxgruppen eine Validierung immer erst bei Ausführen der Primäraktion im Formularfooter statt (siehe Übersicht der Validierungszeitpunkte aller Formularelemente). Besonderheit bei Checkboxgruppen: Jede Wertänderung innerhalb der Gruppe führt immer zur Deaktivierung ggf. bereits vorhandener Validierungsfehlermeldungen an der Gruppe und deaktiviert den entsprechenden Eintrag im Meldungsbanner. 

Spezifikation > Verhalten

 ℹ️ Änderung in Bold dargestellt

Listen bestehen immer aus einem Inhaltsbereich und der darüberliegenden Sortierfunktion. Wie auch bei Tabellen, können sich oberhalb von Listen außerdem Such- und Filtermöglichkeiten befinden, mit denen die Anzahl der angezeigten Inhalte reduziert werden kann (siehe Elemente Suchfeld und Filter. Für Such- und Filterergebnisanzeige siehe Spezifikationen).

Jede Liste trägt eine visuell nicht sichtbare programmatische Beschriftung. Diese sollte identisch sein mit der visuell sichtbaren Beschriftung, welche die Liste inhaltlich beschreibt. Die sichtbare Beschriftung kann sein:

• Seitentitel (bei Listen auf Modul-Startseiten bzw. Modul-Unterseiten, wenn unter dem Seitentitel keine Tabs vorkommen)
• Beschriftung des aktiven Tabs (bei Listen auf Modul-Startseiten bzw. Modul-Unterseiten mit Tabs unter dem Seitentitel)
• Schnellnavigations-Titel (bei Listen in der Schnellnavigations-Sidebar)
• Akkordeontitel (bei Listen in Formularen, die sich direkt einem Akkordeon unterordnen)

Der Text “[Anzahl] Einträge” oberhalb der Liste ist nur verpflichtend zu verwenden, wenn sich Such- oder Filtermöglichkeiten über der Liste befinden. Falls die Anzahl 0 oder eine beliebige Zahl über 1 ist, wird das Wort “Einträge” verwendet. Falls die Anzahl genau 1 ist, wird statt “Einträge” das Wort “Eintrag” verwendet. Die [Anzahl] der Einträge ist als H3 zu kennzeichnen (visuell und semantisch).

Listen dürfen nur außerhalb von Formularen verwendet werden und dienen beispielsweise dem Wechsel zwischen Objektdetailformularen im Seitentyp “”.
Soll innerhalb von Formularen eine Auflistung von Unterobjekten angezeigt werden, so sind dafür Tabellen oder ggf. Karten zu verwenden.

[Grafik „Auf grauem Hintergrund“]

[Grafik „Auf weissem Hintergrund“]

Spezifikation > Verhalten

 ℹ️ Änderung in Bold dargestellt

Die Sektionsbezeichnungen sollten möglichst kurz und präzise formuliert sein. Lange Titel sollten vermieden werden, ist dies nicht möglich kann die Sektion auch mehrzeilig dargestellt werden.

Standardverhalten der Formular-Akkordeons:

• In Neuanlageformularen sind alle Sektionen geöffnet.
• Beim Öffnen des Detailformulars eines bereits angelegten Elements sind zunächst alle Sektionen bis auf die erste Sektion (enthält in der Regel Grunddaten) geschlossen.
• Wird aus einem Kindformular ins Elternformular zurückgekehrt, so sind die Akkordeonzustände im Elternformular identisch mit dem Zustand, in dem sie sich vor Absprung ins Kindformular befunden haben.

Zusätzlich zum Titel kann ein Akkordeon optional auch 1-n Status-Badges beinhalten.

Der Badge-Status im Titel ist nur dann zu verwenden, wenn sich der Status auf den gesamten Akkordeon-Inhalt bezieht. 
Enthält das Akkordeon mehrere Objekte mit unterschiedlichem Status, dann ist der Status an der jeweiligen Inhaltsgruppe darzustellen.

[Grafik „Sektion mit Badge“]

[Grafik „Mit mehreren Badges“]

Spezifikation > Verhalten > Filter-Container > Footer

 ℹ️ Änderung in Bold dargestellt

Dieser enthält den primären Button “Anwenden” und den sekundären Button “Schließen”. Der Anwenden-Button ist direkt beim Öffnen des Filter-Pop-Ups aktiv. Der Anwenden-Button ist bei Öffnen des Filtercontainers inaktiv und er wird aktiv (klickbar), sobald eine Änderung im Filtercontainer vorgenommen wurde (bspw. Wertänderung in einem Auswahlelement oder Eingabe/Änderung/Löschung eines Zeichens in einem Eingabefeld). Bei Änderung in Eingabefeldern wird der Button bereits mit der Änderung, nicht erst bei Verlassen des Feldes aktiv.

Wird die Aktion “Anwenden” ausgeführt, so wird die Auswahl übernommen und der Filter-Container schließt sich. Der Tastaturfokus befindet sich danach auf der entsprechenden Filter-Pille. Die ausgewählten Parameter werden dann in der Pille angezeigt bzw. geändert (falls vorher bereits Parameter gewählt waren).             
Zur Ergebnisanzeige nach Anwenden eines Filters in der Tabelle siehe “Tabellen - Durchsuchen & Filtern von Tabelleninhalten”.            

Falls unvollständige oder fehlerhafte Eingaben vorliegen und Nutzende auf “Anwenden” drücken, so erscheint ein Banner vom Typ Fehlermeldung mit der Überschrift “Anwenden nicht möglich”. Diese ist als “H3” gekennzeichnet.” Details zu Aussehen, Verhalten, Maus- und Tastaturbedienung siehe “Fehlermeldungen in Formularen”.

Wird die Aktion “Schließen” ausgeführt, so schließt sich der Filter-Container, ohne, dass die Auswahl übernommen wird.

Beim Verlassen eines Filtercontainer mit un-angewendeten Eingaben erscheint keine Sicherheitsabfrage. In dem Moment, wo der FIltercontainer geschlossen wird, werden alle noch un-angewendete Inhalte verworfen. Beim erneutem Öffnen sind die Inhalte wieder zurückgesetzt auf die zuletzt angewandten Werte bzw. die Standardwerte dieses Filters.

Je nach Art des Filters sind manche Aktionen im Filter-Container nicht klickbar/verfügbar:

• Vorgegebene Read-Only Filter: Diese Filter sind vorgegeben, nicht veränderbar und nicht löschbar. Sie lassen sich öffnen, aber nicht modifizieren. Der “Weitere Aktionen”-Button im Header wird nicht angezeigt. Der Inhaltsbereich enthält keine interaktiven Elemente, sondern nur read-only-Elemente. Der Footer enthält nur den “Schließen Button”. Der “Anwenden-Button” wird nicht angezeigt.
• Vorgegebene editierbare Filter: Bei diesem Filter ist der Inhaltsbereich modifizierbar. Der Footer enthält den primären Button “Anwenden” und den sekundären Button “Schließen”. Der Filter kann nicht entfernt werden. Der “Weitere Aktionen”-Button im Header wird angezeigt und enthält nur den Button “Zurücksetzen” (deaktiviert, bis Änderungen gemacht wurden). Die Funktion “Entfernen” gibt es hier nicht.
• Neu hinzugefügte Filter (editierbar- und löschbar): Da dieser Filter von Nutzern manuell hinzugefügt wurde, kann er nicht nur modifiziert, sondern auch wieder entfernt werden. Der “Weitere Aktionen”-Button im Header wird angezeigt und das Pop-Up-Menü enthält beide Funktionen: “Zurücksetzen” (deaktiviert, bis Änderungen gemacht wurden) und “Entfernen”.

Spezifikation > Verhalten > Verhalten bei Eingabe einer IBAN

 ℹ️ Änderung in Bold dargestellt

Das IBAN-Eingabefeld ist ein Sonderfall des einzeiligen Eingabefeldes. Es unterscheidet sich in folgendem: 

Die Zeichenzahl ist auf 48 Zeichen begrenzt.

Erklärung: 34 Zeichen ist die maximale Zeichenzahl bei internationalen IBANs (bei deutschen IBANS 22 Stellen) + max. 9 Leerzeichen (für deutsche IBANS 5 Leerzeichen).

Nutzende können die IBAN mit oder ohne Leerzeichen eingeben. Buchstaben können groß oder klein geschrieben werden. Während der Eingabe wird keine Umformatierung vorgenommen.

Nach Verlassen des Feldes wird der Inhalt umformatiert: 

• Nach jedem vierten eingegebenen Zeichen wird ein Leerzeichen eingefügt. 
• Ggf. überflüssige Leerzeichen werden entfernt.
• Ggf. klein geschriebene Buchstaben zu Beginn der IBAN werden in Großbuchstaben umformatiert)

[Grafik „Ablauf der automatischen Formatierung“]

Bei erneuten Fokuserhalt des Eingabefeldes bleiben die Leerzeichen erhalten und Nutzer:innen müssen diese ggf. händisch löschen. Wird das Feld wieder verlassen, werden erneut die Umformatierung (siehe oben) durchgeführt.

Wenn Nutzende den Feldinhalt kopieren, so wird der Wert inklusive Leerzeichen, so wie er im Feld steht, in die Zwischenablage eingefügt.

Der Speicherwert des Feldes in der Datenbank ist weiterhin der unformatierte Wert ohne Leerzeichen (ist noch technisch zu entscheiden).

Die Standardfehlermeldungen bei falsch eingegebener IBAN lautem: 

• Bei fehlerhaftem Eingabeformat: “IBAN im Format DE12 3456 7890 1234 56 angeben”
• Bei fehlerhafter IBAN (z.B. durch falsche Prüfsumme): “Keine gültige IBAN”

[Grafik „Fehlerhafte Eingabe“ wurde aktualisiert]

Spezifikation > Verhalten

 ℹ️ Änderung in Bold dargestellt

Die Sektionsbezeichnungen sollten möglichst kurz und präzise formuliert sein. Lange Titel sollten vermieden werden, ist dies nicht möglich kann die Sektion auch mehrzeilig dargestellt werden.

Standardverhalten der Formular-Akkordeons:

• In Neuanlageformularen sind alle Sektionen geöffnet.
• Beim Öffnen des Detailformulars eines bereits angelegten Elements sind zunächst alle Sektionen bis auf die erste Sektion (enthält in der Regel Grunddaten) geschlossen.
• Wird aus einem Kindformular ins Elternformular zurückgekehrt, so sind die Akkordeonzustände im Elternformular identisch mit dem Zustand, in dem sie sich vor Absprung ins Kindformular befunden haben.

Zusätzlich zum Titel kann ein Akkordeon optional auch 1-n Status-Badges beinhalten.

Der Badge-Status im Titel ist nur dann zu verwenden, wenn sich der Status auf den gesamten Akkordeon-Inhalt bezieht. 
Enthält das Akkordeon mehrere Objekte mit unterschiedlichem Status, dann ist der Status an der jeweiligen Inhaltsgruppe darzustellen.

[Grafik „Sektion mit Badge“]

[Grafik „Mit mehreren Badges“]

Spezifikation > Verhalten > Verhalten bei Tabellen mit fehlerhaften Unterelementen

 ℹ️ Änderung in Bold dargestellt

Bei Tabellen in Formularen können Tabelleneinträge als fehlerhaft markiert sein. 
Die Markierung taucht auf, sobald bei Validierungen im Hauptformular Fehler in Unterobjekten festgestellt werden. Dabei wird das Icon immer nur am Rowheader ergänzt – es kann also nicht mehrmals pro Zeile vorkommen. (Details zur Markierung siehe Tabellen > Zellen)

Zusätzlich wird über der Tabelle eine formularfeldunabhängige Validierungsfehlermeldung pro in der Tabelle enthaltenem fehlerhaftem Objekt angezeigt. 
(siehe auch “Formularfeldunabhängige Validierungsfehler”)

[Grafik „Unterobjekttabelle vor Validierung: Keine Fehlerhaften Unterobjekte“ wurde hinzugefügt]

[Grafik „Unterobjekttabelle Nach validierung:
Fehlerhafte Unterobjekte vorhanden“ wurde hinzugefügt]

Spezifikation > Bedienung > Tastaturbedienung > Tabellen mit fehlerhaften Unterelementen

 ℹ️ Änderung in Bold dargestellt

• siehe „Tabellenzellen” und „Formularfeldunabhängige Validierungsfehler”

Spezifikation > Bedienung > Mausbedienung > Tabellen mit fehlerhaften Unterelementen

 ℹ️ Änderung in Bold dargestellt

• siehe „Tabellenzellen” und „Formularfeldunabhängige Validierungsfehler”

Spezifikation > Verhalten > Verhalten von Tabellenzeilen/-inhalten

 ℹ️ Änderung in Bold dargestellt

Eine Tabellen-Zelle kann folgende Elemente enthalten: 

• Checkbox / Radio-Button (interaktiv)

[Grafik Tabellen-Zelle Checkbox / Radio-Button (interaktiv)]

• Text

[Grafik Tabellen-Zelle Text]

• Link (interaktiv) Sonderfall: Inhalte mit fehlenden Zugriffsrechten werden als dunkel grauen Text und nicht als Link dargestellt und es wird zusätzlich ein Icon angehängt, welches auf die fehlenden Zugriffsrechte hinweist. Dieses trägt den Alternativtext “Keine Zugriffsrechte”. Wenn der Eintragstext länger ist, als in der Zelle darstellbar, so wird der Text am Ende mit “...” abgekürzt. Das Symbol führ fehlende Zugriffsrechte wird dabei weiterhin am Zellenende angezeigt, wird aber nicht im Tooltip angezeigt.

[Grafik Tabellen-Zelle Link]

[Grafik Tabellen-Zelle Keine Zugriffsrechte]

• Bei Links die sich separat öffnen, also den aktuellen Browsertab nicht überschreiben, wird eine Pfeil-Grafik auf der rechten Seite des Links hinzugefügt. In diesem Fall trägt der Link die zusätzliche Beschreibung “Öffnet sich im neuen Tab oder Fenster” und die Pfeil-Grafik muss als Layoutgrafik deklariert werden.

[Grafik Tabellen-Zelle Link der sich im neuen Tab öffnet wurde hinzugefügt]

[Grafik Tabellen-Zelle Link der sich im neuen Tab öffnet (Mehrzeilig) wurde hinzugefügt]

• Bildmarke/Icon + Text/Link: Kommt eine Grafik gemeinsam mit Text in einer Zelle vor, so ist diese als Layoutgrafik zu deklarieren und die Information muss über den Eintragstext wahrnehmbar sein. 

[Grafik Beispiel Icon mit Link]

• Grafik: Wird eine Grafik allein in einer Zelle angezeigt, so muss ein Alternativtext hinterlegt werden. Dieser wird bei fokussieren der Zelle bzw. Mouse-Hover auch als Tooltip angezeigt.

[Grafik Beispiel Inhalt nur Grafik]

• Numerische Inhalte: Numerische Werte, mit denen statistische und arithmetische Berechnungen möglich sind, werden rechtsbündig und an Kommastellen ausgerichtet. Alle anderen, aus Ziffern bestehenden Werte, wie z.B. Zeitstempel (bestehend aus Datum und Uhrzeit), Raumnummern, durch Semikolon getrennnte Werte o.ä., sind linksbündig ausgerichtet. Siehe auch “Übergreifende Basisdefinitionen: Textausrichtung”.

[Grafik Numerische Inhalte]

• Zeitstempel, bestehend aus Datum + Uhrzeit als absolute oder relative Angabe (Detaildefinitionen siehe Übergreifende Basisdefinitionen > Darstellung von Zeitstempeln): Diese werden linksbündig ausgerichtet. Die Spalte für Zeitstempel ist immer fix 200px breit, so dass hier keine Umbrüche entstehen.
  Datum und Uhrzeit-Zeitraum: In Tabellen wo ein Datum und ein Uhrzeit-Zeitraum in einer Zelle dargestellt werden, kommt nach dem Datum immer ein Umbruch. Der Zelleninhalt kann auch als Link dargestellt werden. Format: “[Wochentag in Kurzform], [Datum], [Umbruch] [Zeitraum]”. Beispiel: 

[Grafik Zeitstempel]

• Badge

[Grafik Badge]

[Grafik Badge Auskunftssperre]

• Markierung für fehlerhafte Einträge: Diese kann in normalen Textzellen oder Textzellen mit vorangestelltem Icon/Personensymbol an den Text angehängt werden (nicht bei Links). Die Markierung dient dazu, in Formulartabellen fehlerhafte Unterobjekte grafisch hervorzuheben. Dabei wird das Icon immer nur am Rowheader ergänzt – es kann also nicht mehrmals pro Zeile vorkommen. Der Alternativtext des Symbols, welcher bei Fokuserhalt der Zelle vom Screenreader nach dem Eintragstext ausgelesen wird lautet “– Fehlerhaft”.

[Grafik „Markierung für fehlerhafte Einträge“ wurde hinzugefügt]

• Aktionsbuttons (interaktiv): Diese befinden sich in der Regel in der letzten Tabellenspalte. Es können bis zu 2 Buttons nebeneinander dargestellt werden. Sind mehr als zwei Aktionen zu einer Zeile verfügbar, so werden diese zu einem “Weitere Aktionen”-Button zusammengefasst. Der Button öffnet ein Pop-Up-Menü, von dem aus die Einzelaktionen aufrufbar sind. Die programmatische Beschriftung des Buttons lautet “Weitere Aktionen zu [Inhalt Spate 1]”. Der Tooltip des Buttons lautet nur “Weitere Aktionen”. Wenn eine Tabellenzeile über einen Aktionen-Button gelöscht wird, dann liegt der Tastaturfokus anschließend auf der ersten Zelle der nächsten Zeile. Falls es sich bei der gelöschten Zeile um die letzte gehandelt hat, dann liegt der Fokus auf der ersten Zelle der vorherigen Zeile.

[Grafik eine Aktion]

[Grafik zwei Aktionen]

[Grafik weitere Aktionen]

• Info-Button in Spalte “Details”: Dieser Button kann in einer Tabellenspalte verwendet werden, um zusätzliche Informationen in einem Info-Modal anzeigen zu lassen. Die programmatische Beschriftung des Buttons lautet “Weitere Informationen”. Der Tooltip des Buttons lautet nur “Weitere Informationen”. (Detailbeschreibung siehe Element Infobox).

[Grafik Info-Button wurde hinzugefügt]

[Grafik Beispiele Tabelleninhalt wurde aktualisiert]

Spezifikation > Verhalten > Von Formularfeldern unabhängige Validierungsfehler

 ℹ️ Änderung in Bold dargestellt

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, sondern an einer Kombination aus getätigten oder fehlenden Eingaben entstehen. 
Daher erscheinen diese Validierungsfehler in der Regel erst dann, wenn im Formular die Abschlussaktion wie “Speichern” oder “Anlegen” ausgeführt wird (Details siehe unten: Fehlermeldungsbereich in Formularen). Die Fehlermeldungen tauchen dann auch in der Liste am Anfang des Formulars auf 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.

Spezifikation > Verhalten > Von Formularfeldern unabhängige Validierungsfehler > Bennenung der Meldungen

 ℹ️ Änderung in Bold dargestellt

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

[Grafik „Formularfeld-unabhängige Validierungsfehler“]

[Grafik „Zusammengesetzte Eingabe existiert bereits“]

[Grafik „Beispiel für fehlerhafte Unterobjekte in einer Formulartabelle“ wurde hinzugefügt]

Spezifikation > Verhalten > Fehlerbanner Schema Benennung > Titel Fehlerbanner

 ℹ️ Änderung in Bold dargestellt

• 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 Validierung zwischen Haupt-/Unterformularen > Benennung der Meldungen)

Spezifikation > Verhalten

 ℹ️ Änderung in Bold dargestellt

Die Anzeigereihenfolge der Werte innerhalb des Auswahlfeldes entspricht der Reihenfolge, in der die Werte ausgewählt wurden. Diese Reihenfolge wird auch nach Verlassen des Feldes nicht geändert. Nach Speichern/Anlegen des Formulars und erneutem Aufruf wird die Anzeigereihenfolge standardmäßig zu alphanumerischer Sortierung geändert (Details zur Sortierung siehe Sortierung). Wurde in ENUMs eine abweichende Reihenfolge für die Ausklapplisteninhalte festgelegt (bspw. Wochentage “Montag”, “Dienstag” usw. nach Chronologie), so wird diese nach erneutem Öffnen des Formulars auch als Anzeigenreihenfolge im Feld genutzt.

Sobald mehr als ein Eintrag ausgewählt ist und deren Texte summiert eine Zeichenzahl von 24 überschreiten (inkl. Komma, Semikolon und Leerzeichen) bzw. ab 18 Zeichen, wenn die Einträge Bildmarken enthalten, so werden diese im Auswahlfeld nicht mehr komplett ausgeschrieben. Statt dessen wird dort der Text “[Anzahl] ausgewählt” angezeigt. Dies gilt sowohl bei geschlossener, als auch bei geöffneter Ausklappliste, jedoch nur bei editierbaren Feldern. 
Wenn nur ein Eintrag ausgewählt ist, wird der Eintragstext ausgeschrieben. Wenn der Eintragstext eine Zeichenzahl von 24 überschreitet (inkl. Komma, Semikolon und Leerzeichen) bzw. ab 18 Zeichen, wenn der Eintrag eine Bildmarke enthält, so wird dieser nach den 24 bzw. 18 Zeichen mit “...” abgekürzt.

Spezifikation > Verhalten > Übergreifende Validierungen zwischen Haupt- und Unterformularen

 ℹ️ Änderung in Bold dargestellt

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 auch Standardverhalten des Fehlerbanners in Formularen). 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.

Spezifikation > Verhalten > Übergreifende Validierungen zwischen Haupt- und Unterformularen > Benennung der Meldungen

 ℹ️ Änderung in Bold dargestellt

“[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 Element Fehlerbanner in Formularen: Schema Benennung)

Beispiel.

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

[Grafik „Cross-Validierung von Gültigkeitszeiträumen“ wurde aktualisiert] 

Spezifikation > Verhalten > Verhalten des Suchparameter-Element

 ℹ️ Änderung in Bold dargestellt

Das Suchparameter-Element kommt ausschließlich in der erweiteten Suche zum Einsatz. Es ermöglicht es den Nutzenden gezielt mit Eingabe mehrerer Suchparameter eine große Menge von Ergebnissen einzuschränken und die Eingaben bei Bedarf schnell zu verändern.

Jedes Suchparameter-Element ist als Formularfeldgruppe umgesetzt und beinhaltet folgende Einzelelemente: 

• Titel: Dieser gibt den zu durchsuchenden Attributstyp an. 
• Eingabebereich: Dieser kann entweder ein einzelnes Eingabe- oder Auswahlfeld (alle Typen: Einzeiliges Eingabefeld, Einfach-, Mehrfach-, Baum-Auswahlfeld, Durchsuchbares Einfachauswahlfeld, Datums-/Uhrzeitfelder) bzw. ein Wertebereichs-Feld bestehend aus zwei Feld-Teilen beinhalten. Dabei wird bei allen Typen nur der Feldinhalt jedoch ohne das Feldlabel angezeigt, denn das Feldlabel ist immer mit dem Suchparameter-Titel identisch. Handelt es sich um ein Einzelfeld, so wird vom Screenreader bei fokussieren des Feldes immer das Wort “Wert” mit ausgelesen. Handelt es sich um ein Wertebereichs-Feld, so wird nur das Label des Teilfeldes (von bzw. bis) und kein zusätzliches Feldlabel ausgelesen. Die Teillabel der Einzelfelder bleiben dabei sichtbar und das originale Feldlabel des Wertebereichfelds wird komplett durch den Titel des Suchparameters ersetzt.
• (Optional) Einstellungen: Hier können über eine Pop-Up-Menü weitere Einstellungen zum Element vorgenommen werden. Die Beschriftung des Einstellungs-Buttons lautet immer “Einstellungen öffnen”. Beispiele: 
• • Bei Freitexteingaben kann im Einstellungsmenü zwischen verschiedenen Suchoptionen gewählt werden: Standardsuche (dieser Eintrag ist standardmäßig ausgewählt), Phonetische Suche und Ähnlichkeitssuche. (Detailbeschreibung des Menüs siehe Element Pop-Up-Menü). Weitere Informationen zur Erklärung einer Einstellung können, falls benötigt über die Kontextsensitive Hilfe (Konzeption noch ausstehend) übermittelt werden. Wurde eine Suchoption gewählt, welche nicht die Standardsuche ist, dann erscheint neben dem Einstellungsrad ein Ausrufezeichen-Symbol. Der Tooltip des Einstellungs-Buttons wird dann geändert zu “Einstellungen öffnen ([Bezeichnung der Suche] aktiv)”. Dabei wird der Teil vor dem Zusatz (“Einstellungen öffnen”) in fetter Schrift dargestellt. Wird die Standardsuche wieder aktiviert, so verschwindet das Symbol und der Tooltip-Zusatz wieder.
  • Bei Zahlen- oder Datumseingaben kann über das Einstellungsmenü zwischen Einzelwert und Wertebereich gewechselt werden. Standardmäßig ist “Exakter Wert” aktiv (Detailbeschreibung des Menüs siehe Element Pop-Up-Menü).
• (Optional) Button “Suchparameter entfernen”: Dieser Button wird nur bei Suchparametern angezeigt, die von Nutzenden manuell hinzugefügt wurden. Der Alternativtext lautet “Suchparameter „[Titel]” entfernen”.

Spezifikation > Verhalten > Sonderfall: Eingabebereich mit Pop-Up-Menü

 ℹ️ Änderung in Bold dargestellt

In Ausnahmefällen kann der Eingabebereich auch einen Button enthalten, welcher das Öffnen eines Pop-Up-Menüs auslöst. Visuell wird der Button identisch zum Einfachauswahlfeld angezeigt. Die Screenreaderausgabe bei Fokuserhalt des Eingabebereichs lautet in diesem Fall “Wert: [Buttontext]”. Das Wort “Wert:” wird nur vom Screenreader ausgegeben, jedoch nicht im Button angezeigt.
Im Pop-Up-Menü ist immer ein Eintrag als aktiv ausgewählt. Abhängig von der aktuellen Auswahl kann der Text des Buttons, welcher das Pop-Up-Menü öffnet, sich ändern. Die Auswahl eines Eintrags im Pop-Up-Menü kann entweder zum direkten Schießen des Pop-Ups und Übernahme des Wertes führen oder zum Öffnen eines Modals mit Zusatzoptionen. Im zweiten Fall findet die Übernahme des Wertes und ggf. Änderung des Buttontextes erst nach Ausführen der Primäraktion im Folgemodal statt. Der Tastaturfokus wird bei Öffnen eines Modals ins erste interaktive Element im Inhaltsbereich gelegt. Nach Abschluss der Primäraktion im Modal wird das Modal sowie Pop-Up-Menü geschlossen und der Fokus liegt wieder auf dem Button im Eingabebereich. Wird im Modal die Aktion “Schließen” ausgeführt so wird sowohl Modal als auch Pop-Up-Menü geschlossen und der Fokus liegt wieder auf dem Eingabebereich des Suchparameterelements. Die vorherige Auswahl im Pop wird nicht übernommen und der Buttontext bleibt der alte.
Standardmäßig entspricht der Buttontext immer der Primärinformation des ausgewählten Eintrags im Pop-Up-Menü. Wenn fachlich sinnvoll (z.B. nach Öffnen von Modalen) sind Abweichungen in Userstories zu beschreiben. Beispiel: Suchparameterelement “Zuständige Stelle” in erweiterter Suche: Aktion “Manuell auswählen” im Pop-Up-Menü öffnet Modal zur Stellenauswahl > Buttontext anschließend “Manuell ausgewählt ([Anzahl Stellen]).

[Grafik „Eingabebereich mit Umsetzung als Button & Pop-Up-Menü“ wurde hinzugefügt]

Spezifikation > Bedienung > Tastaturbedienung > Suchparameter-Element

 ℹ️ Änderung in Bold dargestellt

• Mit Tab wird das erste interaktive Element innerhalb eines Suchparameter-Elements fokussiert. 
• Drücken der Tab-Taste bei fokussiertem Suchparameter-Teilelement legt den Fokus auf das nächste interaktive Element in diesem Suchparameter-Element. Handelt es sich bei dem fokussierten Teil um den letzten, so wird der Fokus auf das darauf folgende interaktive Element gelegt (in das nächste Suchparameter-Element bzw. den “Suchparameter hinzufügen”-Button).
• Zur Tastaturbedienung im Eingabebereich siehe jeweiliges Element (Eingabefelder / Datumseingabe / Einfachauswahlfeld / Mehrfachauswahlfeld / Buttons)
• Zur Tastaturbedienung des Einstellungselements sowie Pop-Up-Menüs im Eingabebereich siehe Element . Ausnahme bei Pop-Up-Menüs im Eingabebereich kann Enter/Leertaste bei fokussiertem bereits selektierten Eintrag auch eine Aktion auslösen (bspw. Öffnen eines Modals). Dieser Fall ist in Userstories zu beschreiben.
• Nach Ausführen der Aktion “Suchparameter entfernen” wird das Suchparameter-Element entfernt und der Tastaturfokus wird auf das erste interaktive Element im darauf folgenden Suchparameter-Element gelegt. Handelt es sich bei dem entfernten Suchparameter um das letzte, so wird der Tastaturfokus auf den “Suchparameter hinzufügen”-Button gelegt.

Spezifikation > Bedienung > Mausbedienung > Suchparameter-Element

 ℹ️ Änderung in Bold dargestellt

• Durch einfachen Klick mit linker Maustaste auf einen interaktiven Teil des Suchparameter-Elements wird dieser fokussiert bzw. geöffnet (bei Auswahlfeldern).
• Bei einfachem Klick mit linker Maustaste auf den Suchparameter-Titel wird das erste interaktive Element in der Gruppe fokussiert.
• Zur Mausbedienung im Eingabebereich siehe jeweiliges Element (Eingabefelder / Datumseingabe / Einfachauswahlfeld / Mehrfachauswahlfeld / Buttons)
• Zur Mausbedienung des Einstellungselements sowie Pop-Up-Menüs im Eingabebereich siehe Element . Ausnahme bei Pop-Up-Menüs im Eingabebereich kann der Klick mit linker Maustaste auf einen bereits selektierten Eintrag auch eine Aktion auslösen (bspw. Öffnen eines Modals). Dieser Fall ist in Userstories zu beschreiben.

Spezifikation > Verhalten > Verhalten von Tabellenzeilen/-inhalten

 ℹ️ Änderung in Bold dargestellt

Eine Tabellen-Zelle kann folgende Elemente enthalten: 

• Checkbox / Radio-Button (interaktiv)

[Grafik Tabellen-Zelle Checkbox / Radio-Button (interaktiv)]

• Text

[Grafik Tabellen-Zelle Text]

• Link (interaktiv) Sonderfall: Inhalte mit fehlenden Zugriffsrechten werden als dunkel grauen Text und nicht als Link dargestellt und es wird zusätzlich ein Icon angehängt, welches auf die fehlenden Zugriffsrechte hinweist. Dieses trägt den Alternativtext “Keine Zugriffsrechte”. Wenn der Eintragstext länger ist, als in der Zelle darstellbar, so wird der Text am Ende mit “...” abgekürzt. Das Symbol führ fehlende Zugriffsrechte wird dabei weiterhin am Zellenende angezeigt, wird aber nicht im Tooltip angezeigt.

[Grafik Tabellen-Zelle Link]

[Grafik Tabellen-Zelle Keine Zugriffsrechte]

• Bei Links die sich separat öffnen, also den aktuellen Browsertab nicht überschreiben, wird eine Pfeil-Grafik auf der rechten Seite des Links hinzugefügt. In diesem Fall trägt der Link die zusätzliche Beschreibung “Öffnet sich im neuen Tab oder Fenster” und die Pfeil-Grafik muss als Layoutgrafik deklariert werden.

[Grafik Tabellen-Zelle Link der sich im neuen Tab öffnet wurde hinzugefügt]

[Grafik Tabellen-Zelle Link der sich im neuen Tab öffnet (Mehrzeilig) wurde hinzugefügt]

• Bildmarke/Icon + Text/Link: Kommt eine Grafik gemeinsam mit Text in einer Zelle vor, so ist diese als Layoutgrafik zu deklarieren und die Information muss über den Eintragstext wahrnehmbar sein. 

[Grafik Beispiel Icon mit Link]

• Grafik: Wird eine Grafik allein in einer Zelle angezeigt, so muss ein Alternativtext hinterlegt werden. Dieser wird bei fokussieren der Zelle bzw. Mouse-Hover auch als Tooltip angezeigt.

[Grafik Beispiel Inhalt nur Grafik]

• Numerische Inhalte: Numerische Werte, mit denen statistische und arithmetische Berechnungen möglich sind, werden rechtsbündig und an Kommastellen ausgerichtet. Alle anderen, aus Ziffern bestehenden Werte, wie z.B. Zeitstempel (bestehend aus Datum und Uhrzeit), Raumnummern, durch Semikolon getrennnte Werte o.ä., sind linksbündig ausgerichtet. Siehe auch “Übergreifende Basisdefinitionen: Textausrichtung”.

[Grafik Numerische Inhalte]

• Zeitstempel, bestehend aus Datum + Uhrzeit als absolute oder relative Angabe (Detaildefinitionen siehe Übergreifende Basisdefinitionen > Darstellung von Zeitstempeln): Diese werden linksbündig ausgerichtet. Die Spalte für Zeitstempel ist immer fix 200px breit, so dass hier keine Umbrüche entstehen.
  Datum und Uhrzeit-Zeitraum: In Tabellen wo ein Datum und ein Uhrzeit-Zeitraum in einer Zelle dargestellt werden, kommt nach dem Datum immer ein Umbruch. Der Zelleninhalt kann auch als Link dargestellt werden. Format: “[Wochentag in Kurzform], [Datum], [Umbruch] [Zeitraum]”. Beispiel: 

[Grafik Zeitstempel]

• Badge

[Grafik Badge]

[Grafik Badge Auskunftssperre]

• Aktionsbuttons (interaktiv): Diese befinden sich in der Regel in der letzten Tabellenspalte. Es können bis zu 2 Buttons nebeneinander dargestellt werden. Sind mehr als zwei Aktionen zu einer Zeile verfügbar, so werden diese zu einem “Weitere Aktionen”-Button zusammengefasst. Der Button öffnet ein Pop-Up-Menü, von dem aus die Einzelaktionen aufrufbar sind. Die programmatische Beschriftung des Buttons lautet “Weitere Aktionen zu [Inhalt Spate 1]”. Der Tooltip des Buttons lautet nur “Weitere Aktionen”. Wenn eine Tabellenzeile über einen Aktionen-Button gelöscht wird, dann liegt der Tastaturfokus anschließend auf der ersten Zelle der nächsten Zeile. Falls es sich bei der gelöschten Zeile um die letzte gehandelt hat, dann liegt der Fokus auf der ersten Zelle der vorherigen Zeile.

[Grafik eine Aktion]

[Grafik zwei Aktionen]

[Grafik weitere Aktionen]

• Info-Button in Spalte “Details”: Dieser Button kann in einer Tabellenspalte verwendet werden, um zusätzliche Informationen in einem Info-Modal anzeigen zu lassen. Die programmatische Beschriftung des Buttons lautet “Weitere Informationen”. Der Tooltip des Buttons lautet nur “Weitere Informationen”. (Detailbeschreibung siehe Element Infobox).

[Grafik Info-Button wurde hinzugefügt]

[Grafik Beispiele Tabelleninhalt wurde aktualisiert]

Spezifikation > Verhalten > Ladezustand des Suchparameterbereichs

 ℹ️ Änderung in Bold dargestellt

Wenn das Laden des Suchparameterbereichs länger dauert, dann wird stattdessen ein Platzhalter mit rotierendem Ladesymbol angezeigt. Der “Suche starten”-Button ist solange deaktiviert.

Der Ladezustand ist fokussierbar und trägt den Alternativtext “Suchparameter werden geladen”. Der Alternativtext wird auch als Tooltip angezeigt, wenn mit der Maus exakt über dem Lade-Icon gehovert wird. 
Der Alternativtext des Ladezustands wird automatisch vom Screenreader ausgegeben, auch wenn sich der Fokus nicht auf dem Element befindet. Allerdings wird er, um Audionoise zu vermeiden, erst dann ausgegeben, wenn 2 Sekunden nach Öffnen der Seite der Suchparameterbereich noch nicht vollständig geladen sind.
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.

Nach vollständigem Laden der Suchparameter wird der Text “Suchparameter geladen” vom Screenreader ausgegeben. Dies wird nur ausgegeben, wenn das Laden davor länger als 2 Sekunden gedauert hat. Die Ausgabe erfolgt unabhängig davon, wo sich der Fokus auf der Seite zu der Zeit befindet. 
Der Ladebereich verschwindet und die initialen Parameter werden (je nach fachlicher Definition ggf. inklusive einer Vorbelegung) angezeigt. Gleichzeitig wird der “Suche starten”-Button aktiv. Befindet sich der Tastaturfokus zu diesem Zeitpunkt auf dem Ladezustand, so springt er auf das erste Suchparameter-Element. Befindet sich der Tastaturfokus zu diesem Zeitpunkt auf einem anderen Element auf der Seite, so ändert sich dieser nicht.

[Grafik Ladezustand des Suchparameterbereichs wurde hinzugefügt]

Spezifikation > Verhalten > Bedienung > Tastaturbedienung > Ladezustand des Suchparameterbereichs

 ℹ️ Änderung in Bold dargestellt

• Mit Tab wird der Ladebereich fokussiert
• Erneutes Drücken der Tab-Taste setzt den Fokus auf das nächste interaktive Element

Spezifikation > Verhalten > Bedienung > Mausbedienung > Ladezustand des Suchparameterbereichs

 ℹ️ Änderung in Bold dargestellt

• Klicken mit linker Maustaste auf den Ladezustand fokussiert diesen

Spezifikation > Verhalten > Ladezustand des Suchparameterbereichs

 ℹ️ Änderung in Bold dargestellt

Wenn das Laden des Suchparameterbereichs länger dauert, dann wird stattdessen ein Platzhalter mit rotierendem Ladesymbol angezeigt. Der “Suche starten”-Button ist solange deaktiviert.

Der Ladezustand ist fokussierbar und trägt den Alternativtext “Suchparameter werden geladen”. Der Alternativtext wird auch als Tooltip angezeigt, wenn mit der Maus exakt über dem Lade-Icon gehovert wird. 
Der Alternativtext des Ladezustands wird automatisch vom Screenreader ausgegeben, auch wenn sich der Fokus nicht auf dem Element befindet. Allerdings wird er, um Audionoise zu vermeiden, erst dann ausgegeben, wenn 2 Sekunden nach Öffnen der Seite der Suchparameterbereich noch nicht vollständig geladen sind.
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.

Nach vollständigem Laden der Suchparameter wird der Text “Suchparameter geladen” vom Screenreader ausgegeben. Dies wird nur ausgegeben, wenn das Laden davor länger als 2 Sekunden gedauert hat. Die Ausgabe erfolgt unabhängig davon, wo sich der Fokus auf der Seite zu der Zeit befindet. 
Der Ladebereich verschwindet und die initialen Parameter werden (je nach fachlicher Definition ggf. inklusive einer Vorbelegung) angezeigt. Gleichzeitig wird der “Suche starten”-Button aktiv. Befindet sich der Tastaturfokus zu diesem Zeitpunkt auf dem Ladezustand, so springt er auf das erste Suchparameter-Element. Befindet sich der Tastaturfokus zu diesem Zeitpunkt auf einem anderen Element auf der Seite, so ändert sich dieser nicht.

[Grafik Ladezustand des Suchparameterbereichs wurde hinzugefügt]

Spezifikation > Verhalten > Bedienung > Tastaturbedienung > Ladezustand des Suchparameterbereichs

 ℹ️ Änderung in Bold dargestellt

• Mit Tab wird der Ladebereich fokussiert
• Erneutes Drücken der Tab-Taste setzt den Fokus auf das nächste interaktive Element

Spezifikation > Verhalten > Bedienung > Mausbedienung > Ladezustand des Suchparameterbereichs

 ℹ️ Änderung in Bold dargestellt

• Klicken mit linker Maustaste auf den Ladezustand fokussiert diesen

Navigation mit Browsermitteln > Seite neu Laden

 ℹ️ Änderung in Bold dargestellt

Wird ein Reload der Browserseite ausgeführt (per Button im Browser oder per Tastaturshortcut), so passiert folgendes:

• Es erscheint eine Sicherheitsabfrage (Standardmeldung des Browsers), falls ungespeicherte Daten vorliegen. Wird hier abgebrochen wird, bleibt die bestehende Seite (inkl. aller möglicherweise bereits eingegeben Daten, Undo+Redo-Stack, Such- und Filterkriterien) unverändert bestehen. Wird trotz Sicherheitsabfrage der Reload bestätigt, so wird die gerade geöffnete Seite neu geladen.
• Falls Tabs auf der Seite vorhanden sind, bleibt der Nutzer nach Reload im vorher geöffneten Tab (Es wird nicht standardmäßig zurück auf den ersten Tab navigiert.)
• Falls ein Formular geöffnet ist, so bleibt dieses nach Reload geöffnet. Ausnahme: Bei geöffneten Kindformularen (inkl. modalen Formularen) wird immer zum Elternformular zurücknavigiert. Die Kindformulare werden geschlossen.
• Falls Modaldialoge (Sicherheitsabfragen, Fehler, modale Formulare), Filtercontainer, Pop-Up-Menüs oder Ausklapplisten geöffnet sind, werden diese durch den Reload geschlossen.
• Falls ein Wizard geöffnet ist, so wird nach Reload immer auf Schritt 1 zurückgekehrt, unabhängig davon, in welchem Schritt sich Nutzende vorher befanden.
• Alle ggf. bereits eingegebenen Daten werden durch den Reload zurückgesetzt. Dies gilt auch für die Eltern- und Kindformulare der aktuell geöffneten Seite.
• Gesetzte Such- und Filterkriterien werden durch Reload zurückgesetzt.
• Die Fokussetzung nach Reload folgt den bei den Seitentypen definierten Standardfokussetzungen pro Seitentyp.

Navigation mit Browsermitteln > Zurück-Navigation

 ℹ️ Änderung in Bold dargestellt

Wird der Zurück-Button des Browsers gedrückt, so passiert folgendes: 

• Es erscheint eine GeFa-Sicherheitsabfrage, falls ungespeicherte Daten vorliegen. In der Sicherheitsabfrage werden alle betroffenen Eltern- sowie Kindformulare aufgezählt (siehe Standardmeldungen: Dialoge vom Typ Sicherheitsabfrage). Wird hier abgebrochen, so bleibt die bestehende Seite (inkl. aller möglicherweise bereits eingegeben Daten, Undo+Redo-Stack, Such- und Filterkriterien) unverändert bestehen. Wird trotz Sicherheitsabfrage der Reload bestätigt, wird auf die vorher geöffnete Seite navigiert.
• Vorher eingegebene Daten, welche nicht aktiv von Nutzern gespeichert wurden, werden nach Rücknavigation nicht wieder angezeigt.
• Falls es sich bei der aktuell geöffneten Seite um ein Formular handelt, so wird nach Rück-Navigation immer die Datenübersicht angezeigt, von der dessen Hauptformular geöffnet wurde - unabhängig davon, ob Nutzer sich im Haupt-, Unterformular oder Untermodal befunden haben. Ausnahme: Ist ein Formular in einer Splitview geöffnet und es wurden vorher durch Auswahl anderer Objekte in der Splitview zwischen verschiedenen Formularen hin- und hergewechselt, so wird durch Ausführen der Browser-Back-Funktion zunächst zu den vorher geöffneten Formularen gewechselt, bevor zur Datenübersicht zurück navigiert wird.
• Ggf. vorher in der Datenübersicht gesetzte Such- und Filterkriterien werden nicht wiederhergestellt.
• Handelt es sich bei der aktuell geöffneten Seite um eine beliebige Seite eines Wizards, so wird nach Rück-Navigation immer die Seite angezeigt, von der aus der Wizard geöffnet wurde. Dies geschieht unabhängig davon, in welchem Wizard-Schritt sich Nutzer befunden haben.
• Zur Fokussetzung nach Rücknavigation siehe Standardefinition bei “Seitentypen”.

Spezifikation > Verhalten > Interaktion bei Listen in der Schnellnavigations-Sidebar

 ℹ️ Änderung in Bold dargestellt

Wenn Nutzende einen Listeneintrag auswählen, so wird auf der rechten Bildschirmhälfte das entsprechende Formular geöffnet und der geöffnete Listeneintrag wird in der Liste links als selektiert dargestellt.

[Grafik Geöffneter Listeneintrag]

Falls im rechten Bildschirmbereich ein Formular geöffnet ist, welches ungespeicherte Änderungen enthält und Nutzende wählen in der Schnellnavigations-Sidebar einen anderen Listeneintrag aus, so erscheint eine Sicherheitsabfrage, in der abgefragt wird, ob die Änderungen verworfen werden sollen (siehe Modaldialoge: Beispiel 1: Sicherheitsabfrage bei 
ungespeicherten Eingaben). Wird die Meldung bestätigt, werden die Änderungen verworfen, das Formular wird geschlossen und durch das neue soeben ausgewählte Formular ersetzt.
Wird in der Sicherheitsabfrage auf “Abbrechen” gedrückt, so bleibt das Formular mit den ungespeicherten Änderungen geöffnet.

(Details zur Interaktion zwischen Sidebar und Formular siehe Navigationskonzept > Formulare mit Schnellnavigationssidebar)

Falls bei Neuanlage eines Objekts ein Seitentyp mit Schnellnavigations-Sidebar verwendet wird, so wird das Neue Objekt auch in der Liste in der Sidebar dargestellt. 

Dabei wird das Neu-Listenelement an oberster Stelle der Liste positioniert. Falls die Liste Trennblöcke enthält (siehe unten “Liste mit Trennblöcken”), so wird das Neu-Listenelement während der Anlage noch über dem ersten Trennblock positioniert. Die Objektbezeichnung lautet “Neue/r/s [Objekttyp]”. Beispiele: 

• “Neue Abteilung”
• “Neuer Termin”

Nach fertig ausgeführter Anlage wird das Formular geschlossen und der Nutzer wird wieder auf die Übersichtstabelle (ohne Schnellnavigations-Sidebar) zurückgeleitet. Ein Bestätigungsbanner informiert über die erfolgreich durchgeführte Anlage.

Spezifikation > Verhalten 

 ℹ️ Änderung in Bold dargestellt

Die Infobox wird mit den Regionen Header (Regionsbeschriftung “Titelzeile-Infobox”), Main (Regionsbeschriftung “Inhalt-Infobox”) und Footer (Regionsbeschriftung “Fußzeile-Infobox”) ausgezeichnet.

[Grafik Beispiele für Infobox wurde hinzugefügt]

Der Kopfbereich (Header) der Infobox enthält: 

• Titel “Weitere Informationen zu „[Bezeichnung]”” (Im Code H2 gekennzeichnet): Dabei benennt die Bezeichnung das Objekt, auf das sich die dargestellten Detailinformationen beziehen 
• Badge (optional): Dieser wird falls vorhanden gemeinsam mit dem Titel von Screenreadern ausgelesen. 
• Hinweistext (optional)

Es darf kein Info-Button innerhalb einer Infobox platziert werden.  

Um die Größe des Inhaltsbereichs zu beschränken, darf der Inhaltsbereich jedoch nie mehr als drei Eingabe- bzw. Auswahlfelder und zusätzlich drei Buttons oder Links beinhalten (also maximal sechs Elemente). 

Der Fußbereich (Footer) enthält einen Tertiär-Button mit Icon auf der linken Seite. Der Button hat das Label “Schließen”.

[Grafik Beispiele für Infobox wurde aktualisiert]

Die Infobox wird mit dem Info-Button geöffnet (Programmatische Beschriftung “Weitere Informationen”). Nach dem Öffnen der Infobox liegt der Tastaturfokus auf dem ersten fokussierbaren Element.

Der Tastaturfokus kann die Infobox nicht verlassen, solange die Infobox geöffnet ist.
Interaktive Elemente außerhalb der Infobox reagieren nicht auf Mausinteraktion. 

Die Infobox kann durch den Button “Schließen” im Footer geschlossen werden.
Der Tastaturfokus liegt dann wieder auf dem Info-Button.

[Grafik Infobox Öffnen und Schließen wurde aktualisiert]

Spezifikation > Responsives Verhalten 

[Grafik Umbruchverhalten der Buttons wurde aktualisiert]

Spezifikation > Zustände

[Grafik Info-buttons aktualisiert]

Spezifikation > Verhalten > Responsives Verhalten

 ℹ️ Änderung in Bold dargestellt

Verhalten abhängig von Fensterbreite:

[Grafik Verfahrensheader Large]

Die Breite des Platzes für den Titel ist abhängig von der Anzahl der vorhandenen Umsystem-Links. Bei ausreichendem Platz werden alle Links nebeneinander dargestellt. 
 

• Sobald der Titel eine Breite von 720 Pixeln nicht mehr erreicht werden kann, wird aus den nebeneinanderliegen Umsystem-Links ein einziger Sekundärer Button mit der Bezeichnung “Umsysteme” und dem Pfeil-Icon, welches zur Auszeichnung externen Links verwendet wird. Dieser verhält sich wie ein Pop-Up-Menu-Button. Wenn Nutzende darauf klicken, werden alle enthaltenen Umsystem-Einträge im Pop-Up-Menü gelistet.      
   
• Sobald der Titel eine Breite von 400 Pixeln nicht mehr erreicht werden kann, wird aus dem Umsystem-Button ein Sekundärer Button ohne Text, bei dem nur noch das “Externer Link”-Icon sichtbar ist. Er hat den Tooltip “Umsysteme”.     
   
• Ab einer Fensterbreite unter 480px verkleinert sich die Schriftgröße des Titels sowie vertikale Abstände. 

[Grafik Default + Long Title]

[Grafik Verfahrensheader Medium]

[Grafik Verfahrensheader Small wurde entfernt]

[Grafik Verfahrensheader Small mit Dropdown wurde entfernt]

Verhalten abhängig von Fensterhöhe:

[Grafik Verfahrensheader Large bei Fensterhöhe unter 1024 Pixel wurde hinzugefügt]

• Ab einer Fensterhöhe unter 1024px verkleinert sich die Schriftgröße des Titels sowie vertikale Abstände innerhalb des Verfahrensheaders. 

[Grafik Default + Long Title unter 1024 Pixel wurde hinzugefügt]

[Grafik Verfahrensheader Medium unter 1024 Pixel wurde hinzugefügt]

[Grafik Verfahrensheader Small unter 1024 Pixel wurde hinzugefügt]

Spezifikation > Verhalten > Verhalten des Suchparameter-Element

 ℹ️ Änderung in Bold dargestellt

• Bei Zahlen: Weder bei Verlassen eines unbefüllten Von- noch Bis-Teilfeldes werden im Feld Platzhaltertexte wie “0” oder “Unbegrenzt” eingefügt. 
• Bei Daten: Sowohl bei unbefülltem Von- als auch Bis-Datum wird das Feld nach Verlassen weiterhin als leer angezeigt.

Spezifikation > Verhalten > Schließen-Funktion

 ℹ️ Änderung in Bold dargestellt

Die Schließen-Funktion im oberen Bereich wird als Tertiärer-Icon-Button ohne Text mit X-Icon umgesetzt und trägt den Alternativtext “[Menü-Titel] schließen”. Die Schließen-Funktion in der Fußzeile des Overlays ist ein rechtsbündig angeordneter teritärer Button mit Icon und Text “Menü schließen”.

Der Fokus wird nach dem Schließen eines Fensters auf den Menüpunkt der Headerleiste gesetzt, mit dem zuvor das Fenster geöffnet wurde.

Beim Öffnen fährt der Container, abhängig davon, ob sich das öffnende Element auf der linken oder rechten Seite des Headers befindet, entweder von links oder rechts in den Bildschirm. Wird auf der rechten Seite ein anderes Overlay geöffnet, ohne das vorherige zu schließen, findet der Wechsel ohne Animation statt.

Spezifikation > Bedienung

 ℹ️ Änderung in Bold dargestellt

• Fokus liegt beim Erscheinen der Meldung auf dem ersten interaktiven Element im Modal.
• Mit Tab-Taste kann zum nächsten Interaktiven Element navigiert werden.
• Enter oder Leertaste bei fokussiertem Button führt die jeweilige Aktion aus und schließt den Dialog.
• Enter oder Leertaste bei einem fokussierten Link öffnet diesen in einem neuen Browertab (Abweichung vom Standardverhalten des Elements “Link”)
• Drücken der Escape-Taste löst in Sicherheitsabfragen die Aktion “Abbrechen” aus. Drücken der Escape-Taste in Fehlerdialogen löst keine Aktion aus.

Spezifikation > Aufbau > Liste mit suche, Filter, Neuanlage und Paginierung

 ℹ️ Änderung in Bold dargestellt

Die Grafik “LISTE MIT SUCHE, FILTER, NEUANLAGE UND PAGINIERUNG” wurde aktualisiert.

1. Neuanlage-Button (optional)
2. Suche (optional)
3. Filter (optional)
4. Text “[Anzahl] Einträge”
5. Sortierfunktion
6. Eintrag
7. Geöffneter Eintrag
8. Fußzeile mit Paginierung (optional, je nach Menge der Listeneinträge)

*Änderung in Bold dargestellt

Spezifikation > Verhalten > Verhalten von Zwischensektionen (Akkordeons)

Die Inhalte von Formularen können in aus- und einklappbare Sektionen unterteilt werden. 

Die Sektionsbezeichnungen sollten möglichst kurz und präzise formuliert sein. Lange Titel sollten vermieden werden, ist dies nicht möglich kann die Sektion auch mehrzeilig dargestellt werden.

Die Sektionstitel sind Überschriften vom Schrifttyp H3. Je nach Seitentyp ist der Sektionstitel aber im Code als “H2” oder “H3” auszuzeichnen (siehe Unterseite eines Moduls - Inhaltstyp Formular).

Jedes Akkordeon (inkl. Titel, Badges, Auf-/Zuklappenbutton und Inhaltsbereich) ist als Region mit der Beschriftung “[Akkordeontitel]” ausgezeichnet.

*Änderung in Bold dargestellt

Spezifikation > Verhalten

Jede Inhaltskachel enthält immer eine Überschrift und einen Inhaltsbereich. Die Überschrift entspricht visuell dem Schrifttyp H3. Die Überschriftenhierarchie im Code ist je nach Seitentyp von Designern festzulegen (in der Regel “H3” oder “H2”).

Der Titel der Kachel sollte so kurz und präzise wie möglich formuliert sein. Ist der Titel dennoch länger, so wird er bei Bedarf mehrzeilig.

Jede Kachel (inkl. Titel, Badges, Auf-/Zuklappenbutton und Inhaltsbereich) ist im Code als Region gekennzeichnet und die Regionsbeschriftung entspricht der Kachelüberschrift.

Außerdem kann optional im Header der Kachel:

• Eine Funktion zum Auf- und Zuklappen der Kachel (Bedienung wie beim Element Zwischensektionen/Akkordeons in Formularen).
• Maximal ein Badge, zur Darstellung des Status des Kachelinhalts. Der Badge ist Teil des Titels.

[…]

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)
• […]

• […]
• Die Gültigkeitszeiträume von „[Titel Gruppe 1]” und „[Titel Gruppe 2]” überschneiden sich.

Die Grafik “FORMULARFELD-UNABHÄNGIGE VALIDIERUNGSFEHLER” wurde aktualisiert.

[…]

Die Schnellnavigations-Seitenleiste neben geöffneten Formularen beinhaltet die Datennavigation in Listenform. Such-, Filter- und Sortierparameter werden bei der Navigation zwischen Datenübersicht und Detailformular mit Sidebar in beide Richtungen übernommen 
(Datenübersicht <> Detailformular mit Splitview). Dies gilt für jede Vor- und Rücknavigation innerhalb eines Arbeitsprozesses. Beispiel:

• Wird innerhalb dieses Pfades z. B. über die Pfadnavigation zurücknavigiert, so bleiben vorher gesetzte Such-, Sortier- und Filterkriterien erhalten: “Stellenübersicht in GRVW > Detailformular einer Stelle > Übersicht Nummernkreise der Stelle > Detailformular des Nummernkreises” 

Beim Wechsel in ein anderes Modul müssen die Such- und Filtereinstellungen der vorher geöffneten Seiten ebenfalls nicht weiter vorgehalten werden.

Die Nutzung der Schnellnavigations-Sidebar ist optional. Nutzer können diese pro Maske ausblenden oder in den Nutzereinstellungen definieren, dass keine Schnellnavigationsleisten angezeigt werden sollen.

Über die Schnellnavigations-Seitenleiste kann ein anderes Objekt geöffnet werden, ohne dass Nutzende es zuerst das aktuell geöffnete Formular schließen müssen. Wird zu einem anderen Objekt gewechselt, während im Formular ungespeicherte Änderungen vorliegen, so erscheint eine Sicherheitsabfrage (siehe Modaldialoge).

Wird ein Objekt (aus der Datenübersicht oder aus der Schnellnavigations-Sidebar) in einem neuen Browsertab geöffnet, so wird dort keine Schnellnavigations-Sidebar angezeigt. Such- und Filterkriterien der Datenübersicht werden in diesem Fall auch nicht mit in den neuen Tab übernommen.

Während rechts ein Formular geöffnet ist, können links in der Seitennavigation beliebige Änderungen (wie das Ändern der Suche, Filterung oder Sortierung) vorgenommen werden. Das Formular rechts bleibt davon unbeeinflusst weiterhin sichtbar, bis ein anderer Listeneintrag ausgewählt wurde. 
Das gilt ebenfalls wenn durch Ändern der Suche oder Filter oder Wechsel auf eine andere Seite in der Listenpagination der selektierte Listeneintrag nicht mehr sichtbar ist. Erst durch Auswahl eines anderen Eintrags in der Schnellnavigation wird das Formular rechts aktualisiert und der gewählte Listeneintrag wird wieder selektiert dargestellt. (siehe auch Element “Liste”)

Die Fußzeile des geöffneten Formulars enthält Schaltflächen zum Schließen und Speichern/Anlegen. 
Bei Abbruch über die Schließen-Schaltfläche, den Objekpfad, oder den Zurück-Button des Browsers erfolgt bei ungespeicherten Änderungen eine Sicherheitsabfrage (siehe Modaldialoge).

Wird die Aktion “Speichern” in einem Formular mit danebenliegender Splitview durchgeführt, so bleibt das Formular geöffnet, es werden jedoch alle Daten, die auf der Seite (auch außerhalb des Formularinhalts) sichtbar sind, aktualisiert. Dies kann also zur Aktualisierung folgender Elemente führen:

• Formulartitel
• Pfadnavigation: Bezeichnung letzter (geöffneter) Eintrag
• Anzahl Einträge in der Splitviewliste
• Primäre, sekundäre, tertiäre Information (Texte, Statusbadges, etc.) des Objekts in der Splitviewliste 
• Sortierung der Splitviewliste

Bei paginierten Splitviewlisten gilt: Die Durchführung der Aktion “Speichern” hat keine Auswirkungen auf die zu dem Zeitpunkt geöffnete Seite, d.h. die davor geöffnete Seite (bspw. Seite 3) bleibt geöffnet. Durch die möglichen Änderungen von Objekttexten und Aktualisierung der Sortierung kann es dazu kommen, dass das gerade geöffnete Objekt sich nach dem Speichern nicht mehr im sichtbaren Bereich der Splitview befindet (weil auf andere Seite gerutscht). 
Falls es durch eine aktalisierte Eintragszahl in einer paginierten Splitviewliste dazu kommt, dass die vorher geöffnete Seite nicht mehr existiert, so wird die letzte verfügbare Seite der Liste geöffnet. (siehe auch Element “Formular”)

GeFa ändert bzw. verhindert die standardmäßig im Browser verwendbaren Tastaturkürzel nicht (Beispiel: Alt + Pfeiltaste nach links/rechts um die vorherige/nächste Seite im Browserverlauf zu öffnen).

Wird ein Reload der Browserseite ausgeführt (per Button im Browser oder per Tastaturshortcut), so passiert folgendes:

• Es erscheint eine Sicherheitsabfrage (Standardmeldung des Browsers), falls ungespeicherte Daten vorliegen. Wird hier abgebrochen wird, bleibt die bestehende Seite (inkl. aller möglicherweise bereits eingegeben Daten, Undo+Redo-Stack, Such- und Filterkriterien) unverändert bestehen. Wird trotz Sicherheitsabfrage der Reload bestätigt, so wird die gerade geöffnete Seite neu geladen.
• Falls Tabs auf der Seite vorhanden sind, bleibt der Nutzer nach Reload im vorher geöffneten Tab (Es wird nicht standardmäßig zurück auf den ersten Tab navigiert.)
• Falls ein Formular geöffnet ist, so bleibt dieses nach Reload geöffnet. Ausnahme: Bei geöffneten Kindformularen (inkl. modalen Formularen) wird immer zum Elternformular zurücknavigiert. Die Kindformulare werden geschlossen.
• Falls Modaldialoge (Sicherheitsabfragen, Fehler, modale Formulare), Filtercontainer, Pop-Up-Menüs oder Ausklapplisten geöffnet sind, werden diese durch den Reload geschlossen.
• Falls ein Wizard geöffnet ist, so wird nach Reload immer auf Schritt 1 zurückgekehrt, unabhängig davon, in welchem Schritt sich Nutzende vorher befanden.
• Alle ggf. bereits eingegebenen Daten werden durch den Reload zurückgesetzt. Dies gilt auch für die Eltern- und Kindformulare der aktuell geöffneten Seite.
• Gesetzte Such- und Filterkriterien werden durch Reload zurückgesetzt.

Wird der Zurück-Button des Browsers gedrückt, so passiert folgendes: 

• Es erscheint eine GeFa-Sicherheitsabfrage, falls ungespeicherte Daten vorliegen. In der Sicherheitsabfrage werden alle betroffenen Eltern- sowie Kindformulare aufgezählt (siehe Standardmeldungen: Dialoge vom Typ Sicherheitsabfrage). Wird hier abgebrochen, so bleibt die bestehende Seite (inkl. aller möglicherweise bereits eingegeben Daten, Undo+Redo-Stack, Such- und Filterkriterien) unverändert bestehen. Wird trotz Sicherheitsabfrage der Reload bestätigt, wird auf die vorher geöffnete Seite navigiert.
• Vorher eingegebene Daten, welche nicht aktiv von Nutzern gespeichert wurden, werden nach Rücknavigation nicht wieder angezeigt.
• Falls es sich bei der aktuell geöffneten Seite um ein Formular handelt, so wird nach Rück-Navigation immer die Datenübersicht angezeigt, von der dessen Hauptformular geöffnet wurde - unabhängig davon, ob Nutzer sich im Haupt-, Unterformular oder Untermodal befunden haben.
• Ggf. vorher in der Datenübersicht gesetzte Such- und Filterkriterien werden nicht wiederhergestellt.
• Handelt es sich bei der aktuell geöffneten Seite um eine beliebige Seite eines Wizards, so wird nach Rück-Navigation immer die Seite angezeigt, von der aus der Wizard geöffnet wurde. Dies geschieht unabhängig davon, in welchem Wizard-Schritt sich Nutzer befunden haben.

Es gilt das gleiche Verhalten, wie bei Navigation ohne Shift, mit folgenden Unterschieden: 

• Die Seite öffnet sich in einem neuen Browsertab. 
• Vorher gesetzte Such- und Filterkriterien werden nicht wiederhegestellt.


An Datumsfeldern steht immer der Hinweistext “TT.MM.JJJJ”, welcher als Formatvorlage dient. Bei Bedarf können zusätzliche fachliche Hinweistexte ergänzt werden. Diese werden mit einem Gedankenstrich getrennt vor dem Formathinweis angezeigt: “[Fachlicher Hinweis] – TT.MM.JJJJ”.

Ergänzung Grafik “Datumsfeld mit fachlichem Hinweistext”.

Die Tabreihenfolge ist: 

• Neuanlage-Button (optional)
• Suche (optional)
• Filter (optional)
• Text “[Anzahl] Einträge”
• Menu-Button “Tabellen-Einstellungen”
• Tabelle 
• Hinzufügen-Button (optional)

Die Grafik “Tabellen in Formularen” wurde hinzugefügt.

Wird eine Tabelle innerhalb eines Formulars angezeigt, so ist der Hinzufügen-Button immer unterhalb der Tabelle positioniert.

[…]

Wenn eine Tabelle mit Null Einträgen innerhalb eines Formulars angezeigt wird und sich unter der Tabelle ein “[Element] hinzufügen”-Button befindet, so wird statt des Leer-Eintrags die ganze Tabelle ausgeblendet. Die Information “Keine Einträge vorhanden” wird in diesem Fall durch den Seiten- oder Akkordeontitel bzw. falls die Tabelle nicht an erster Stelle eines Formulars oder Akkordeons steht durch die Tabellenüberschrift und den direkt nachfolgenden Hinzufügen-Button vermittelt. 

Falls nur durch das Setzen von Filtern eine leere Tabelle zustande kommt, die Tabelle im ungefilterten Zustand aber Einträge hätte, dann wird der Leerzustand mit dem Text “Kein Treffer für diese Such- und Filterkriterien gefunden.” (siehe “Durchsuchen und Filtern von Tabellen”) weiterhin angezeigt.

Ergänzung zu Verhalten des Fehlerbanners: 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.

• Seite existiert nicht. 
• • Anwendungsbeispiel: Nutzende haben einen GeFa-Link eingegeben, der nicht bzw. nicht mehr existiert.

Aktualisierung der Grafik “SEITENAUFRUF & SEITE EXISTIERT NICHT” 

Aktualisierung der Graphiken “Modaldialoge”, “Beispiel Modaldialoge” und “Responsiver Fehlerdialog”.

• Link (interaktiv) Sonderfall: Inhalte mit fehlenden Zugriffsrechten werden als dunkel grauen Text und nicht als Link dargestellt und es wird zusätzlich ein Icon angehängt, welches auf die fehlenden Zugriffsrechte hinweist. Dieses trägt den Alternativtext “Keine Zugriffsrechte”. Wenn der Eintragstext länger ist, als in der Zelle darstellbar, so wird der Text am Ende mit “...” abgekürzt. Das Symbol führ fehlende Zugriffsrechte wird dabei weiterhin am Zellenende angezeigt, wird aber nicht im Tooltip angezeigt.

Aktualisierung der Graphik “Zellentypen”.

• […] Sonderfall: Bei Listeneinträgen mit fehlenden Zugriffsrechten wird die Primäre Information nicht als Link, sondern als Text dargestellt und es wird zusätzlich ein Icon an die Primäre Information angehängt (State disabled). Diese muss als Layoutgrafik deklariert werden.

Aktualisierung der Graphiken “Liste mit unterschiedlich hohen Einträgen”, “Listeneinträge mit Primär- und Sekundärinformationen” und “Listeneinträge mit Primärinformation”.

• Mit Pfeiltasten nach unten/oben kann der Fokus zum nächsten/vorherigen Listeneintrag gewechselt, unabhängig davon, ob diese aktiv oder deaktiviert dargestellt ist.
• Ausnahme: Bei Listeneinträgen ohne Zugriffsrechte (State Disabled) hat die Leer- und Entertaste keine Auswirkung und der Fokus verbleibt unverändert.

• […] Ausnahme: Klick mit linker Maustaste auf einen deaktivierten Listeneintrag setzt die visuelle Hervorhebung auf diesen, es wird jedoch keine Aktion ausgeführt.

Zur weiteren Untergliederung von Listen können Trennblöcke zwischen den einzelnen Einträgen eingezogen werden. Beispiele: 

• Liste von Geschäftsverteilungsplänen: Trennblöcke nach Jahren (2021; 2022; ...)
• Liste von Verfahrensbeteiligten: Trennblöcke nach Parteien (Klagend/Beklagt/Sonstige Beteiligte)
• Liste von Terminen: Trennblöcke nach Tagen/Wochen/Monaten

Jeder Trennblock enthält:

• Titel “[Trennparameter]”: Hier wird die Kategorie benannt, nach der getrennt wird. Der Kategorie-Titel (Trennparameter) sollte möglichst kurz sein (1 bis max. 2 Wörter). Falls ein längerer Titel nicht vermeidbar ist, bricht dieser um. 
• “([Anzahl] Einträge)”. Dabei wird nur die Anzahl der Einträge des jeweiligen Blocks genannt. Falls genau ein Eintrag vorhanden ist, wird das Wort “Eintrag” statt “Einträge verwendet.

Trennblöcke sind nur dann zu verwenden, wenn die Kategorien fix sind und kein Listeneintrag zu zwei Kategorien gleichzeitig gehören kann. Bei Sortierung der Liste bleiben die Blöcke fix bestehen und die Sortierung wirkt sich nur auf die Einträge innerhalb der Blöcke aus. Blockinhalte werden also nie (auch nicht durch Umsortierung) durchmischt. Auch die Reihenfolge der Blöcke selbst bleibt konstant.

Im über der Liste stehenden Text “[Anzahl] Einträge” werden nur die wirklichen Listeneinträge gezählt. Die Trennblöcke (Kategorien) sind zwar Teil der Liste, werden aber nicht als Einträge mitgezählt.

Wenn die Liste ab einer gewissen Anzahl von Einträgen paginiert wird und Kategorie-Blöcke sich dadurch über mehrere Seiten erstrecken, dann ändert sich die Betitelung dieser Trennblöcke in:
“[Trennparameter] (Einträge [Anzahl von]–[Anzahl bis] von [Gesamtanzahl])”. Das “–” sollte von Screenreadern als “bis” ausgelesen werden. Auf der folgenden Seite, auf der die Inhalte eines Trennblocks fortgesetzt werden, wird der Trennblock als erster Eintrag erneut wiederholt.
Trennblöcke, die sich ausschließlich auf einer Seite befinden, behalten die Standard-Betitelung (siehe oben).

Der Trennblock-Text (Titel der Kategorie und Anzahl Einträge) wird jeweils mit Fokuserhalt des ersten enthaltenen Listenelements mit ausgelesen. Je nach Navigationsrichtung, kann es das erste oder das letzte Element eines Trennblocks sein.

Wenn ein Trennblock keine Einträge enthält, so wird im Regelfall ein Leer-Eintrag innerhalb mit der Beschriftung “Keine Einträge vorhanden” angezeigt. Falls es fachlich gewünscht ist, dass leere Trennblöcke statt dessen komplett ausgeblendet werden, so kann dies in Userstories beschrieben werden.

Beim Scrollen der Liste bleibt der Trennblock, zu dem der oberste sichtbare Eintrag gehört, sticky am oberen Listenrand stehen, während die dazugehörigen Einträge scrollbar bleiben. Bei Erreichen des nächsten Blocks, wird dieser dann aus dem sichtbaren Bereich heraus geschoben und durch den folgenden Trennblock ersetzt. 
Ausnahme: Bei einer Fensterhöhe von unter 400px bleiben die Trennblöcke nicht mehr sticky stehen.

Beispiel für Scrolling-Verhalten: https://camo.githubusercontent.com/f13f3d18be3a7e9392e115bd3c04531e9be4a1d6/68747470733a2f2f6d656469612e67697068792e636f6d2f6d656469612f534730426f795a5942504f6d67523367624c2f67697068792e676966

Aktualisierung aller Graphiken dieses Bereichs.

Mit der Listenelement-Trennblöcken ist keine Interaktion möglich.

Mit der Listenelement-Trennblöcken ist keine Interaktion möglich.

Entfernung der Graphik “Beispiel in einer Liste im Formularbereich”.

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

1. […] nach Wertänderung bei Verlassen […]

• wurde ein Pflichtfeld nicht befüllt

Auf fehlerhafte Eingabe werden Nutzende nach einer Wertänderung direkt nach Verlassen des entsprechenden Feldes hingewiesen, sowohl visuell als auch über ein akustisches Signal (siehe Spezifikationen zu Eingabe- und Auswahlfeldern).

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:

Tastaturbedienung

[…] sofern eine Wertänderung stattgefunden hat, bei Verlassen […].

Aktualisierung der Graphik “Fehler im Formular” und “Fehlerentstehung bis Behebung bei 320 Pixeln”.

Es können auch deaktivierte (disabled) Elemente im Dropdown angezeigt werden. Diese können auch fokussiert werden. Vom Screenreader werden sie als deaktivierte Elemente ausgegeben. Wichtig ist: Es muss für die Nutzenden fachlich einen Mehrwert bieten, dass die Einträge noch in deaktivierter Form als Teil der Ausklappliste angezeigt werden und es muss aus dem Maskenkontext klar hervorgehen, warum die Einträge deaktiviert sind. Kann dies nicht garantiert werden, so sollten die entsprechenden Werte in der Ausklappliste ganz ausgeblendet statt nur deaktiviert werden. 

Aktualisierung der Graphik “Dropdown Einträge”.

Tastaturbedienung

• Mit Pfeiltasten nach unten/oben springt der visuelle Fokus auf die nächste/vorherige Auswahloption, unabhängig davon, ob diese aktiv oder deaktiviert dargestellt ist.
• […] Das Auswahlfeld bleibt selektiert. Ausnahme: Ist ein deaktiviertes Elemente visuell hervorgehoben, so hat die Entertaste keine Auswirkung (Ausklappliste bleibt geöffnet und Hervorhebung bleibt unverändert).

Mausbedienung

• […] Ausnahme: Klick mit linker Maustaste auf einen deaktivierten Listeneintrag setzt die visuelle Hervorhebung auf diesen, es wird jedoch keine Aktion ausgeführt und die Ausklappliste bleibt geöffnet.

Es kann zwischen sechs verschiedenen Hervorhebungen unterschieden werden: 

• Vollflächig farbig 
• Gestreift 1
• Gestreift 2
• Gestreift 3
• Gestreift 4
• Gestreift 5
• Gestreift 6

Hinzufügen der Graphik “Hervorhebungsvarianten”.

Es kann zwischen sechs verschiedenen Hervorhebungen unterschieden werden: 

• Vollflächig farbig 
• Gestreift 1
• Gestreift 2
• Gestreift 3
• Gestreift 4
• Gestreift 5
• Gestreift 6

Hinzufügen der Graphik “Hervorhebungsvarianten”.

Der Titel jedes Schritts beschreibt so kurz und präzise wie möglich (1-2 Wörter), welche Art von Daten in diesem Schritt erfasst werden müssen. Verben sollten darin nicht vorkommen. Die Schrittbezeichnung ist immer identisch mit dem Formulartitel des jeweiligen Wizardschritts. Der Titel der Zusammenfassungsseite (sofern vorhanden) lautet immer “Zusammenfassung”.

Wird der Initialzustand durch Auswahl des Wertes “–” (wenn kein Pflichtfeld) oder mit der Rückgängig-Funktion wiederhegestellt, 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.

Aktualisierung der Graphiken “Standardverhalten” und hinzufügen der Graphik "Nachträgliche Auswahl eines ungültigen Werts im Durchsuchbaren Auswahlfeld".

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.

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]”

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)

Wird die Gruppe wieder aktiviert, so verschwindet der Labelzusatz "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 fokussiertem “Gruppe hinzufügen-Button” führt […]
• […] bzw. bei deaktivierten Gruppen der “Auf-/Zuklappen-Button” fokussiert werden.
• Durch Enter oder Leertaste bei fokussiertem “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).

• 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.

Hinzufügen der Graphik “Deaktivierte Formulargruppen”.

• Pfeiltasten nach unten/oben wechseln den Fokus zur nächsten/vorherigen Auswahloption, unabhängig davon, ob diese aktiv oder deaktiviert dargestellt ist.
• Ist ein deaktiviertes Element fokusiert, so hat die Enter oder Leertaste keine Auswirkung ( Pop-Up bleibt geöffnet und hervorhebung bleibt unverändert)

Klick mit linker Maustaste auf deaktivierte (disabled) Elemente setzt den Fokus auf diese, es wird jedoch keine Aktion ausgeführt und das Pop-Up Menü bleibt geöffnet. 

Auch die Überschrift, der Badge und der Auf-/Zuklappen-Button der Inhaltskachel befindet sich (falls vorhanden) innerhalb dieser Region.

Was wird gesucht:

• Wurde die Option “Phonetischen Suche” aktiviert, so wird nach dem Regelwerk der Kölner Phonetik gesucht. Dies beinhaltet beispielsweise, dass Umlaute auch durch Eingabe ihrer ausgeschriebenen Version gefunden werden und umgekehrt. Beispiel: “ue” findet auch “ü”. “ä” findet auch “ae” usw.

• Leerzeichen, welche in einer Suchphrase zu einer String-Trennung führen, werden selbst nicht hervorgehoben – dafür werden alle durch die Trennung entstandenen einzelnen Suchphrasen-Teile separat hervorgehoben. Beispiel: Bei Suche nach "Maier Peter" wird "Maier, Hans Peter" gefunden und “Maier” und “Peter” wird jeweils hervorgehoben. Auch die Reihenfolge der eingegebenen Begriffe spielt keine Rolle für die visuelle Hervorhebung. Wird “Peter Maier” gesucht, werden ebenfalls die beiden Wörter in “Maier, Peter Hans” hervorgehoben.
• Wurde die Phonetische Suche aktiviert, so werden auch die Suchergebnisse hervorgehoben, welche auf Grund der kölner Phonetik gefunden werden. Beispiele: Wurde “ae” eingegeben, so wird auch “ä” gehighlighted. Wurde “ü” eingegeben, so wird auch “ue” gehighlighted. "Škoda" findet auch "Skoda" und umgekehrt.

• […] unabhängig davon, ob diese aktiv oder deaktiviert dargestellt ist.
• […] Ausnahme: Ist ein deaktiviertes Elemente visuell hervorgehoben, so hat die Entertaste keine Auswirkung (Ausklappliste bleibt geöffnet und Hervorhebung bleibt unverändert).

• Pfeiltaste nach rechts öffnet den Baum-Zweig unabhängig davon, ob diese aktiv oder deaktiviert dargestellt ist.

• […] und das Dropdown bleibt geöffnet.

• Klick mit linker Maustaste auf deaktivierte (disabled) Eintragstexte setzt den Fokus auf das Element, es wird jedoch keine Aktion ausgeführt und das Dropdown bleibt geöffnet (Wert kann nicht ausgewählt werden).

• Die Pfeil-Grafik auf der rechten Seite des Links kommt immer dann zum Einsatz, wenn der Link sich separat öffnet, also nicht den aktuellen Browsertab überschreibt. Dies kann ein neuer Browsertab sein oder eine neue Anwendung (z.B Desktopanwendung). In diesem Fall trägt der Link die zusätzliche Beschreibung “Öffnet sich im neuen Tab oder Fenster” und die Pfeil-Grafik muss als Layoutgrafik deklariert werden.

Wenn Nutzer sich in ihren Einstellungen (GeFa oder Browser) konfiguriert haben, dass Links immer im neuen Tab aufgehen sollen, so hat das keinen Einfluss auf die Pfeil-Grafik. Diese wird weiterhin nur bei Links angezeigt die sich standardmäßig im neuen Tab öffnen.

• Hinzufügen eines Unterobjekts: Dabei ist nur das Hinzufügen des Objekts als ganzes Rückgängig machbar, nicht die enthaltenen Einzelaktionen.
• Bearbeiten von Unterobjekten: Dabei ist nur die Bearbeitung des Objekts als ganzes Rückgängig machbar, nicht die enthaltenen Einzelaktionen.
• Entfernen von Unterobjekten (z. B. über die Tabellenaktionen einer Unterobjektübersicht im Elternformular oder über den Formularheader im Kindformular anschließende Rückkehr ins Elternformular)

• Der Undo-Button im Formular-Footer wird erst aktiv, wenn eine Änderung im Formular durchgeführt wurde (mind. 1 Zeichen) – bei Eingabefeldern erst bei Verlassen des Feldes. Entsprechend wird bei Eingabefeldern auch nur die komplette Wertänderung im Stack gelistet, nicht jede einzelne Aktion (Zeichen hinzufügen/ändern/entfernen) innerhalb des Feldes.
• • Entfernen einer Gruppe führt zu entfernen aller enthaltener Felder. Es wird nur die Entfernen-Aktion im Undo- bzw. Redo-Stack gelistet.
• Bei Verlassen eines Elternformulars in ein Kindobjekt (egal ob Modales Formular oder Unterseite) wird die Undo/Redo-Historie des gerade verlassenen Elternobjekts gespeichert, ist allerdings erst nach Rückkehr in dieses Elternobjekt wieder abrufbar. 
• Jedes Öffnen eines Kindformulars startet in diesem mit einem leeren Stack und Undo+Redo-Button sind entsprechend deaktiviert, bis Änderungen durchgeführt werden.
• Wird ein Kindformular über “Schließen”, “Hinzufügen” oder “Übernehmen” verlassen, so wird dessen Undo/Redo-Stack endgültig zurückgesetzt. Anschließend ist der vorherige Stand des Undo/Redo-Stackis im Elternformular wieder verfügbar.
• Wird das Hauptobjekt über “Speichern”, “Anlegen” oder “Schließen” verlassen, so wird dessen Undo/Redo-Stack endgültig zurückgesetzt.

Wird der ein Wizardschritt verlassen, unabhängig ob über den Weiter-, Zurück-Button oder die Schrittnavigation, wird der Undo/Redo-Stack des verlassenen Schritts zurückgesetzt.

• Wenn ein Kindformular über das Aktionsmenü in dessen Formularheader entfernt wird, dann erscheint keine Sicherheitsabfrage. Die Aktion zum Einen über Undo im Elternformular rückgängig gemacht werden und zum Anderen wird die Änderung erst durch Speichern/Anlegen des Hauptformulars final übernommen.
• Wird das Hinzufügen eines Kindformulars über den Undo-Button im Elternformular rückgängig gemacht, so erscheint im Regelfall keine Sicherheitsabfrage. Falls jedoch die dadurch entfernte Datenmenge sehr groß ist (riesige Kindformulare mit ggf. weiteren Unterformularen), so kann fachlich definiert werden, dass beim Klick auf Undo eine Sicherheitsabfrage erscheint. Beispiel: 
• • Hinzufügen von „[Kindobjekt]” rückgängig machen? – Durch diese Aktion gehen ggf. große Datenmengen verloren. Hinzufügen rückgängig machen? – Aktionen: Abbrechen / Rückgängig machen

Aktualisierung der Graphik “Formular mit Unterobjekten”.

Für die Einzelschritt-Formulare innerhalb von Wizards gelten abweichende Formulierungsregeln (siehe auch “Wizard > Formular Header”): Hier wird nur in max. 1-2 Wörtern die Art von Daten benannt, um deren Eingabe es im jeweiligen Schritt geht (vergleichbar mit Benennung von Akkordeons in Standardformularen). Verben sollten in der Schrittüberschrift nicht vorkommen.

Hinzufügen der Graphik “Formulare innerhalb von Wizard-Neuanlageprozessen”.

• Mit der Tab-Taste wird das Eingabefeld fokussiert. 
• Bei ggf. bereits vorhandenem Text wird dieser komplett ausgewählt, bis neuer Text eingegeben oder die Markierung durch Pfeil links oder rechts aufgehoben wird und der Cursor an den Anfang oder das Ende der jeweiligen Zeile springt.
• Dann kann Text eingegeben werden. 
• Mit Return können Zeilenumbrüche oder Absätze eingefügt werden.
• Durch erneuten Klick auf die Tab-Taste, wird das nächste Interaktionselement fokussiert, und das aktuelle springt zurück zum Default-Zustand (leer oder gefüllt, je nach Eingabe).

Hinzufügen der Graphiken des Positiv- und Negativbeispiels.

Für Komponenten mit Sortiermöglichkeit gelten folgende Standardsortierregeln (abweichendes Verhalten muss in User Stories definiert werden):

• Einträge ohne Zeitangaben werden alphanumerisch aufsteigend nach ISO/IEC 14651:2011 case-insensitive (GENERIC_M_CI) sortiert. 
• Einträge mit Zeitangaben werden chronologisch absteigend sortiert (neue Einträge zuerst). 
  Als sekundäres Sortierkriterium wird standardmäßig die verknüpfte Datenbank-ID in absteigender
• Sortierung verwendet, welche immer eindeutig ist (damit ist sekundär in der Regel nach dem Anlagezeitpunkt des Objekts sortiert: neuestes zuerst). Dieses sekundäre Sortierkriterium kommt nur dann zum Tragen, wenn zwei Objekte, für das Attribut nach dem sortiert wird, den gleichen Wert besitzen. In User Stories kann auch ein anderes zweites oder drittes Sortierkriterium definiert werden, die Datenbank-ID wird dann als letztes Sortierkriterium verwendet.

Titel des aktuellen Schritts: Dieser beschreibt so kurz und präzise wie möglich (1-2 Wörter) den Inhalt des geöffneten Formulars, also die Art der Daten, die in diesem Schritt erfasst werden müssen. Verben sollten im Titel nicht vorkommen. Der Formulartitel ist immer identisch mit der Bezeichnung des entsprechenden Schritts in der Schrittübersicht. Der Formulartitel der Zusammenfassungsseite (sofern vorhanden) lautet immer “Zusammenfassung”.

Ablauf von Frontend/Backend Validierungen in Wizard-Neuanlagen

Dadurch, dass erst nach Klick auf “Anlegen” auf der Zusammenfassungsseite (bzw. auf der letzten Wizardseite) Backend-Validierungen durchgeführt […].

[…] Wird am Ende auf der Zusammenfassungsseite (bzw. auf der letzten Wizardseite) auf “Anlegen” geklickt, so werden Backend-Validierungen für alle Einzelschritte des Neuanlage-Wizards durchgeführt. Alle gefundenen Fehler werden in einem Fehlerbanner auf der Zusammenfassungsseite (bzw. auf der letzten Wizardseite) aufgeführt. Gleichzeitig werden die entsprechenden Schritte in der Schrittübersicht als fehlerhaft markiert (siehe Schrittübersicht). Dem Fehlertext auf der Zusammenfassungsseite (bzw. auf der letzten Wizardseite) wird jeweils die Prozessschrittnummer und -bezeichnung vorangestellt. Um zur Behebung der einzelnen Fehler in die jeweiligen Arbeitsschritte zu springen, gibt es zwei Möglichkeiten: […].

[…] (auch wenn die erneute Backend-Überprüfung erst wieder auf der Zusammenfassungsseite (bzw. auf der letzten Wizardseite) passiert). […]

[…] auf die Zusammenfassungsseite (bzw. auf die letzte Wizardseite) zurück, dann verschwinden alle auf den Unterseiten bereits bearbeiteten Fehler-Einträge aus dem Fehlerbanner der Zusammenfassungseite (bzw. auf die letzte Wizardseite). Gleichzeitig wird die Fehler-Markierungen in der Schrittnavigation entfernt (sowohl bei den Unterformularen als auch auf der Zusammenfassungsseite (bzw. auf der letzten Wizardseite)).

[…] auf der Zusammenfassungsseite (bzw. auf der letzten Wizardseite) ausgeführt, dann findet erneut […].

Der Titel des Fehlerbanners lautet: 

• Auf der Zusammenfassungsseite (bzw. auf der letzten Wizardseite) […]

[…] auf der Zusammenfassungsseite (bzw. auf der letzten Wizardseite) setzt sich zusammen aus: […].

Standardsortierung von Tabellen:

• Alle Spalten einer Tabelle sind sortierbar (mit Ausnahme der “Auswahl”- und “Aktionen”-Spalten).
• Sollen weitere Spalten nicht sortierbar sein, muss dies in den User Stories beschrieben werden.
• Tabellen werden bei Seitenaufruf anhand der ersten Spalte sortiert (Tabellen mit Auswahlspalte werden anhand der zweiten Spalte sortiert). In User Stories kann auch eine andere eingeblendete Spalte für die Sortierung bei Seitenaufruf definiert werden. Es gelten folgende Sortierungen je nach Datentyp:
• • Spalten mit Zeitangaben werden chronologisch absteigend (neue Einträge zuerst) sortiert. 
  • Alle anderen Spalten werden alphanumerisch aufsteigend (A–Z) sortiert.
  • Sortierungen die weder chronologisch noch alphanumerisch sind (z.B. nach Status), müssen in User Stories beschrieben werden.
• Bei einer “starren” Tabelle ohne Sortierfunktion muss die Sortierung nicht anhand des Spaltenkopfs erkennbar sein. Die Inhalte sollten dennoch einer logischen / kontextabhängigen Sortierung folgen, die über die User Story definiert werden muss.

Bei sortierten Spalten gibt der Screenreader die Sortierung mit aus, bei unsortierten wird nur der Name ausgegeben.

Bestätigungsbanner informieren Nutzende nach Rückkehr in eine Datenübersicht mit Tabelle über den erfolgreichen Abschluss einer Aktion mit einem Hauptobjekt.

Bestätigungsbanner informieren Nutzende nach Rückkehr in eine Datenübersicht mit Liste über den erfolgreichen Abschluss einer Aktion mit einem Hauptobjekt.

Nach Abschluss einer Neu-Zuordnung und Rückkehr in die Datenübersicht (= in diesem Fall die dem Hauptobjekt untergeordnete Übersicht der Nebenobjekte) liegt der Tastaturfokus auf dem Objektlink des Bestätigungsbanners über der Tabelle/Liste/Baumstruktur/Kalenderansicht. Das Bestätigungsbanner informiert über die erfolgreiche Zuordnung (siehe Element “Bestätigungsbanner”).

Können Objekte 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 werden die nicht mehr ausführbaren Buttons in der Tabellen-Aktionsspalte komplett ausgeblendet, statt nur deaktiviert.

Wenn Objekte generell editierbar sind, nur der Nutzer keine Bearbeitungsrechte dafür besitzt, werden die Buttons deaktiviert angezeigt.

Listeneinträge können folgende Elemente beinhalten: 

• Sekundäre Information: Diese enthält den Wert, der oberhalb der Liste als Sortierkriterium gewählt wurde (siehe oben: Sortierfunktion). Die sekundärinformation wird nach der Primärinformation vom Screenreader ausgegeben. Wurde alphabetisch nach der primären Information sortiert, so wird die sekundäre Information nicht angezeigt oder ausgegeben.

Ein Listeneintrag kann folgende Elemente optional enthalten (diese Elementen werden vom Screenreader, falls vorhanden, in der hier aufgeführten Reihenfolge nach der primären Information bzw. nach der sekundären Information (falls vorhanden ausgegeben):

• (optional) Ein Icon oder eine Bildmarke (z.B. Avatar oder Foto einer Person): Die Funktion des Eintrags muss eindeutig aus dem angezeigten Text hervorgeht und die Grafik hat nur gestalterischen Charakter. Die Bildmarke muss als Layoutgrafik deklariert sein.
• (optional) Eine weitere Bezeichnung, falls fachlich absolut notwendig, darf nur in Ausnahmefällen benutzt werden, um Objekte zu differenzieren.
• (optional) Ein Badge, z. B. zur Anzeige des Objektstatus (siehe Element Badge).
• (optional) Weitere-Aktionen-Button: Öffnet ein Pop-Up-Menü. Der Tooltip lautet “Weitere Aktionen”. Dieser wird von Screenreadern nicht ausgelesen.

Es kann nur Grafik oder Badge verwendet werden. Beides gemeinsam ist nicht möglich. 
Die Grafik bei fehlenden Zugriffsrechten kann auch angezeigt werden, wenn ein Badge vorkommt.

Hinzufügen der Grafik “Listeneintrag mit weiterer Bezeichnung”.

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

• 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 Meldungsbanner in Formularen). 
• Solange keine Validierungsfehler vorliegen, wird das Formular des Unterobjekts ohne Buttonanimation oder Ton geschlossen. Die Fokussetzung folgt der Definition im Navigationskonzept: “Tiefennavigation in Inhaltsbereichen”

Der Formularfooter 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/Übernehmen
  • 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 Formularfooter nur noch der Schließen-Button angezeigt und alle Formularfelder werden im Read-only-Zustand angezeigt. 

FORMULA-FOOTER MIT SCHLIESSEN-BUTTON

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 sowie der Rückgängig-Button (Undo) im Footer des Formulars aktiv und klickbar. 

Pflicht-Radiobutton-Gruppen sind mit “*” (Sternchen”) nach dem TextLabel (Gruppenlabel) markiert. Bei Read-Only-Feldern gibt es keine visuelle Pflichtfeldauszeichnung, auch wenn diese im Backend ggf. als Pflichtfelder geprüft werden.

Aktualisierung der Grafik “Radiobutton-Gruppen mit Pflichtfeldkennzeichnung”.

Pflichtcheckboxen (Checkboxgruppen) sind mit “*” (Sternchen”) nach dem TextLabel (Gruppenlabel) markiert. Bei Read-Only-Feldern gibt es keine visuelle Pflichtfeldauszeichnung, auch wenn diese im Backend ggf. als Pflichtfelder geprüft werden.

Aktualisierung der Grafik “Einzelende und Checkboxgruppen mit Pflichtfeldkennzeichnung".

Telefonnummern werden in einem einzeiligen Eingabefeld (ohne Umformatierungen) erfasst, dabei wird zwischen Festnetz- und Mobilfunknummer unterschieden.

Die Standardfehlermeldung bei falsch eingegebener Telefonnummer lautet “Falsches Eingabeformat” (siehe auch Meldungsliste aller Eingabe-/Auswahlelemente).

Unter Festnetznummernfelder wird immer folgender Hinweistext zum Eingabeformat angezeigt: “Formatbeispiel: 030 12345-67 (nur für Deutschland) oder +31 20 1234567 (international)“. Bei Mobilfunknummernfeldern lautet der Hinweistext: “Formatbeispiel: 0171 123456 (nur für Deutschland) oder +31 6 1234567 (international)“.

Aktualisierung der Grafik “Eingabefelder mit Telefonnummer” und “Telefonnummerneingabefeld mit fachlichem Hinweistext”. 

• Bei Nutzeraktionen, welche Änderung an mehreren Feldern zur Folge haben, wird nur das auslösende Event als ein Eintrag im Undo- bzw. Redo-Stack gelistet (statt 1 Eintrag pro geändertem Feld und damit einzelner Rückgängigmachbarkeit). Beispiele:
• • Änderung an Feld A führt zu Zurücksetzen oder Vorbefüllen der Felder B, C & D. Es wird nur die Änderung am Feld A im Undo- bzw. Redo-Stack gelistet.
  • Entfernen einer Gruppe führt zu entfernen aller enthaltener Felder. Es wird nur die Entfernen-Aktion im Undo- bzw. Redo-Stack gelistet.

• Wenn Gruppen/Objekte innerhalb eines Formulares gelöscht werden, dann erscheint im Regelfall keine Sicherheitsabfrage, da die Aktion über den Formularfooter rückgängig gemacht werden kann. (Optional kann, wenn fachlich relevant aber eine Sicherheitsabfrage in Userstories definiert werden. In diesem Fall bleibt der Undo-Stack erhalten, egal welche der beiden Optionen gewählt wurde.)

Sind die Werte der Zellen rechtsbündig ausgerichtet, ist auch die Spaltenüberschrift rechtsbündig ausgerichtet und andersrum. Werden die Inhalte einer Spalte mit Einheiten, wie z.B. Währungen, Prozentangaben, oder einer Anzahl angegeben, so wird die Einheit nur im Spaltentitel und der Wert ohne Einheit in den Tabellenzellen aufgeführt.

• Numerische Inhalte: Numerische Werte, mit denen statistische und arithmetische Berechnungen möglich sind, werden rechtsbündig und an Kommastellen ausgerichtet. Alle anderen, aus Ziffern bestehenden Werte, wie z.B. Zeitstempel (bestehend aus Datum und Uhrzeit), Raumnummern, durch Semikolon getrennnte Werte o.ä., sind linksbündig ausgerichtet. Siehe auch “Übergreifende Basisdefinitionen: Textausrichtung”.
• Zeitstempel, bestehend aus Datum + Uhrzeit als absolute oder relative Angabe (Detaildefinitionen siehe Übergreifende Basisdefinitionen > Darstellung von Zeitstempeln): Diese werden linksbündig ausgerichtet. Die Spalte für Zeitstempel ist immer fix 200px breit, so dass hier keine Umbrüche entstehen.
• Datum und Uhrzeit-Zeitraum: In Tabellen wo ein Datum und ein Uhrzeit-Zeitraum in einer Zelle dargestellt werden, kommt nach dem Datum immer ein Umbruch. Der Zelleninhalt kann auch als Link dargestellt werden. Format: “[Wochentag in Kurzform], [Datum], [Umbruch] [Zeitraum]”. Beispiel: 
  “Fr, 31.03.2023,
11:00 Uhr - 12:00 Uhr”

Aktualisierung der Grafik “Darstellung von Zellen mit Datum + Uhrzeit-Zeitraum”.

Aktualisierung der Grafik “Ausnahme 2 - Beispiel GVP”. 

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.

Hinzufügung der Grafik “Zurücksetzen von Feldern mit Validierungsfehlern”. 

1. Hauptmenü-Button: Dieser ist als Region mit dem Landmark “Navigation” und der Beschriftung “Hauptmenü” gekennzeichnet.
2. Name der Justizbehörde
3. 1-n weitere Menü-Buttons: Die Buttongruppe ist als Region mit dem Landmark “Navigation” und der Beschriftung “Schnellaktionen” gekennzeichnet.

Der Anwenden-Button ist bei Öffnen des Filtercontainers inaktiv und er wird aktiv (klickbar), sobald eine Änderung im Filtercontainer vorgenommen wurde (bspw. Wertänderung in einem Auswahlelement oder Eingabe/Änderung/Löschung eines Zeichens in einem Eingabefeld). Bei Änderung in Eingabefeldern wird der Button bereits mit der Änderung, nicht erst bei Verlassen des Feldes aktiv.

Aktualisierung der Grafik “Footer”.

Der Alternativtext lautet “Suchparameter „[Titel]” entfernen”.

Der Formularheader 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 Formularheader 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).
• (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 Formularheader ist bis zu einer Formularhöhe von 672 Pixeln sticky. Bei kleineren Formularhöhen verschwindet er beim Scrollen.

Dabei bilden Titel und Badge zusammen die Kartenüberschrift und werden vom Screenreader gemeinsam ausgelesen im Format “[Kartentitel] – [Badgebeschriftung]”.

Jede Kachel ist außerdem im Code als Region gekennzeichnet und die Regionsbeschriftung entspricht der Kachelüberschrift.

Es handelt sich visuell um eine Überschrift des Typs “Label” in der Farbe Schwarz.

Aktualisierung alles Graphiken. 

Es handelt sich visuell um eine Überschrift des Typs “Label” in der Farbe Schwarz.

Aktualisierung aller Graphiken.

Modaldialoge sind technisch als solche ausgezeichnet. 
Sie enthalten keine zusätzlichen Regionsauszeichnungen für Header, Footer & Inhaltsbereich.

Dialoge vom Typ Fehler erscheinen entweder direkt anschließend auf eine Nutzeraktion, die z.B. auf Grund eines Fehlers nicht ordnungsgemäß ausgeführt werden kann oder auch unabhängig von einer Nutzeraktion, wenn es wichtig ist, dass der Nutzer die Meldung sofort wahrnimmt.
Dabei kann es sich um technische Fehler (z. B. Server nicht erreichbar) oder fachliche Fehler (z.B. Weglegen eines Verfahrens auf Grund noch nicht erledigter Unterobjekte nicht möglich) handeln.

Bei technischen Fehlern ist eine Trace ID mit in der Meldung anzuzeigen, um eine eindeutige Identifizierung des Fehlers zu gewährleisten. 
Diese wird in folgendem Format an den Fehlertext angehängt: „[Detailbeschreibung Fehler] [Umbruch] (Trace ID: [ID])“.

Nutzende müssen das Modal schließen (in der Regel über den primären Button), um fortfahren zu können. In Ausnahmefällen können auch bei diesem Fehlertyp mehrere Aktionen (primär/sekundär) zur Auswahl stehen. Eine gleichzeitige Bearbeitung der im Hintergrund liegenden Seite ist nicht möglich.

Das Auslösen von technischen Fehlermeldungen kann aus unterschiedlichen Fällen entstehen, die entweder mit den Anwendern oder dem System zusammenhängen. Beispiele:

• Optimistic Locking: Bearbeiten zwei Personen dasselbe Formular, so werden die Änderungen der Person übernommen, die zuerst speichert.
• Ein Objekt wird von einem anderen Anwender, oder demselben Anwender in einem neuen Tab gelöscht, bevor Änderungen übernommen wurden. 
• Der Server reagiert nicht.
• Das Umsystem ist nicht erreichbar.

Fokussetzung nach Ausführen der Aktionsbuttons kann zwei Standardfälle haben:

• Fall 1, klick auf “Seite neu Laden”/”Formular schließen”: der Fokus wird nach neu Laden der Seite und aktualisieren der Inhalte, auf das erste interaktive Element im Inhaltsbereich der Seite (main) gesetzt. Dabei springt die Ansicht immer zurück auf die Übersichtsseite. Falls fachlich sinnvoll, können Ausnahmen entstehen, welche in den User Stories definiert werden müssen. 
• • Ausnahme Fall 1, klick auf “Seite neu laden” nach Optimistic Locking: Fokus wird, nach neu Laden der Seite, auf das erste interaktive Element im Formular gesetzt.
• Fall 2, klick auf “Okay”: es passiert keine Navigation und der Fokus wird nach Schließen des Modals wieder auf das Element gesetzt, mit dem der Dialog geöffnet wurde. Falls fachliche sinnvolle Ausnahmen entstehen, müssen diese in den User Stories definiert werden.

Hinzufügen aller Graphiken. 

Aktualisierungen der Graphiken:

“Tabelle mit Auskunftssperre-Person”, “Tabelle mit Trennblöcken auf grauem Hintergrund”, “Tabelle mit Trennblöcken auf weißem Hintergrund”, “Tabelle mit Paginierung”, “Tabellen mit Trennlinie vor der Summenspalte”, und “Responsive Tabellen”.

Ist bei einer Zelle kein Inhalt vorhanden (z.B. weil Attribut kein Pflichtattribut und im Objektformular kein Wert eingetragen wurde), so wird visuell ein Gedankenstrich “–” in Textform in der Zelle angezeigt. Das gilt für Spalten aller Inhaltstypen (Text, Badge, Zahl, Datum usw.). Vom Screenreader wird statt des Gedankenstrichs das Wort “leer” bei Fokuserhalt dieser Zelle ausgegeben.

Graphik “Tabelle mit ”Leer"-Einträgen".

Anlage der Seite.

Graphik “Änderungshinweis” aktualisiert.

Der Alternativext lautet “Suchparameter „[Titel]” entfernen”.

Graphiken “Fehler bei Feldteilen” und “Felder mit Validierungsfehler” aktualisiert.

• Mülltonnen-Symbol: “Löschen” (kann nur bei Hauptobjekten vorkommen)
• Minus-Symbol: “Entfernen”, kann nur bei Unterobjekten vorkommen

Die Reihenfolge der hier genannten Aktionen entspricht auch der Anzeigereihenfolge, falls mehrere dieser Buttons vorkommen. 

Wenn diese Aktionen im Pop-Up-Menü dargestellt werden (entweder in einem Formularheader, oder weil die Aktionsspalte der Tabelle mehr als 2 Aktionen enthält) wird auch im Menü das jeweilige Icon mit angezeigt.

Update der Graphiken. 

• […]Die Scrollposition im Formular sowie ggf. geöffnete/geschlossene Akkordeons werden vom vorherigen übernommen. […] und die Scrollposition wird zurückgesetzt.
• […] Die Scrollposition wird zurückgesetzt, ebenso im vorherigen Formular geöffnete/geschlossene Akkordeons werden ebenfalls auf den Standard zurückgesetzt. Offener Punkt: Für Screenreadernutzende ist noch ein Shortcut zu definieren, mit dem hier die Enter-Funktion ausgelöst werden kann.

• […] Die Scrollposition im Formular sowie ggf. geöffnete/geschlossene Akkordeons werden vom vorherigen übernommen. […] und die Scrollposition wird zurückgesetzt.
• […] Die Scrollposition wird zurückgesetzt, ebenso im vorherigen Formular geöffnete/geschlossene Akkordeons werden ebenfalls auf den Standard zurückgesetzt. Offener Punkt: Für Screenreadernutzende ist noch ein Shortcut zu definieren, mit dem hier die Enter-Funktion ausgelöst werden kann.

Zusätzlich zum Titel kann ein Akkordeon optional auch 1-n Status-Badges beinhalten. Sie werden mit dem Akkordeontitel von Screenreadern ausgelesen.

Beispiele:

Anlage eines Altverfahrens: Das Aktenzeichen, welches sich aus den Eingaben in mehreren Einzelfeldern zusammensetzt, existiert bereits.

Positionierung:

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.

Update der Graphiken.