Header: Der Header ist ohne Hauptnavigation darzustellen. Aufbau, Landmark-Struktur und Fokusverhalten haben den allgemeinen Vorgaben des Header Bereich zu entsprechen. Die visuelle Höhe ist konsistent zu halten.

Seitenrahmen: Der Login-Bereich ist zentriert in einem responsiven Container anzuordnen. Die Seite folgt einem klaren, einspaltigen Aufbau ohne zusätzliche Layoutspalten.

Hilfe und Kontakt: Hinweise zu Hilfe und Support sind unterhalb des Login-Formulars in den Inhaltsfluss zu integrieren, entweder als kompakter Support-Block oder über einen „Hilfe & Kontakt“-Expander. Eine separate, dauerhaft platzierte Spalte für Hilfe-, Support- oder andere funktionale Inhalte ist nicht vorgesehen.

Felder: Das Login-Formular enthält mindestens Benutzername und Passwort. Optionale Ergänzungen wie „Angemeldet bleiben“ oder „Passwort vergessen?“ sind zulässig.

Validierung: Fehlermeldungen werden verständlich und in unmittelbarer Nähe zum betroffenen Feld angezeigt. Zusätzlich kann eine kompakte globale Rückmeldung vorgesehen werden.

Passwortmanager: Funktionen wie „Passwort anzeigen“ oder Autofill sind nutzerfreundlich und konsistent bereitzustellen.

Headerbereich: Der Aufbau entspricht vollständig dem definierten Header Bereich.

Inhaltsbereich: Der Inhaltsbereich ist in drei Teilbereiche zu strukturieren:

Struktur: Die Teilbereiche sind klar voneinander abgegrenzt und folgen einem responsiven Raster (vgl. Layout und Resizing).

Relevanz: Inhalte werden abhängig von Rolle und Nutzungskontext angezeigt. Nicht relevante Inhalte werden nicht dargestellt.

Widget-Prinzip: Jedes Widget repräsentiert genau einen Inhaltstyp. Es enthält einen Titel, optional ein Icon und klare Aktionen.

Zustände: Lade-, Leer- und Fehlerzustände sind klar erkennbar, verständlich formuliert und stabil dargestellt.

Platzierung: Teilbereich A liegt auf dem Desktop in der linken bzw. ersten Spalte. Auf mobilen Geräten und Tablets wird er oberhalb der Applikations-Widgets dargestellt.

Zweck: Quicklinks bieten Direkteinstiege zu häufig genutzten Funktionen oder Objekten (z. B. „Wiedervorlagen“, „Abgelegte Vorgänge“, „Häufig benutzte Funktionen“).

Gruppierung und Umfang: Quicklinks werden in logischen Gruppen (Widgets) zusammengefasst. Pro Gruppe sind in der Regel 5 Links vorzusehen. Abweichungen sind zu begründen.

Interaktion: Ziele sind im selben Fenster zu öffnen. Bestätigungspflichtige Aktionen erfolgen bevorzugt inline.

Platzierung: Teilbereich B liegt auf dem Desktop in der mittleren Spalte.

Zweck: Applikations-Widgets dienen als Einstieg zu Applikationen oder Applikationsgruppen. Sie werden als Kacheln oder Panels mit Titel, optionalem Icon und kurzer Beschreibung umgesetzt.

Gruppierung: Applikationen sind thematisch zu bündeln; einzelne Applikationen können eigene Widgets erhalten.

Nav-Parität: Links innerhalb eines Widgets entsprechen inhaltlich der Navigationsebene 2 (siehe Kapitel Navigation).

Sichtbarkeit: Die Sichtbarkeit erfolgt rollen- bzw. berechtigungsbasiert.

Kennzeichnung: Applikationsfarben und ggf. Applikationsicons sind konsistent einzusetzen.

Platzierung: Auf dem Desktop liegt Teilbereich C rechts in der dritten Spalte. Auf mobilen Geräten ist er unterhalb der Applikations-Widgets anzuordnen.

Zweck: Teilbereich C enthält Benachrichtigungen, Benutzerinformationen oder Kontaktangaben. Er wird nur angezeigt, wenn entsprechende Inhalte vorliegen.

Mehr Inhalte: Weitere Inhalte sind über „Mehr anzeigen“ auf eine Unterseite auszulagern.

Typ A/C:

Typ B:

Headerbereich: Aufbau und Verhalten entsprechen vollständig dem definierten Header Bereich.

Seiten-Toolbar: Kontextbezogene Aktionen wie „Zurück zur Übersicht“, „Drucken“ oder „Hilfe“ sind konsistent bereitzustellen.

Inhaltsbereich: Inhalte sind modular aufgebaut und folgen denselben Strukturprinzipien wie das Dashboard.

Bezug und Orientierung: Titel, Icon und Farbmarkierung entsprechen der auslösenden Dashboard-Kachel bzw. -Gruppe.

Navigation: „Zurück zur Übersicht“ führt zur auslösenden Stelle auf dem Dashboard (ggf. mit Anker). Listen bieten eine „Vorheriges/Nächstes“-Navigation innerhalb derselben Treffermenge.

Layout und Inhalte: Pro Abschnitt gilt das Ein-Inhaltstyp-Prinzip. Für umfangreiche Inhalte können Tabs oder Accordions eingesetzt werden.

Headerbereich: Aufbau und Verhalten entsprechen vollständig dem definierten Header Bereich.

Optionale Linksnavigation (A): Die Linksnavigation bildet applikationsinterne Bereiche und Funktionsgruppen ab.

Inhaltsbereich (B): Applikationsrelevante Inhalte sind in modularen Abschnitten darzustellen.

Eigene Applikationsseite: Jede Applikation verfügt über eine eigenständige Applikationsseite.

Inhaltsumfang je Applikation: Umfang und Struktur sind applikationsspezifisch festzulegen.

Optionale Linksnavigation: Die Applikationsseite kann eine optionale Linksnavigation enthalten, die applikationsinterne Bereiche und Funktionsgruppen abbildet (siehe Kapitel Linksnavigation).

Inhaltsbereich ohne Linksnavigation: Entfällt die Linksnavigation, nutzt der Inhaltsbereich die gesamte verfügbare Breite.

Erkennbarkeit der Applikation: Der Name der Applikation ist eindeutig erkennbar ausgewiesen, z. B. in der Linksnavigation oder in der ersten Gruppierungsüberschrift des Inhaltsbereichs.

Kennzeichnung über Applikationsfarben: Jede Applikationsgruppe bzw. jede eigenständige Applikation ist durch eine farbliche Markierung zu kennzeichnen (siehe Kapitel Applikationsfarben).

Einsatzorte der Farbcodierung: Die Applikationsfarbe ist an den folgenden Stellen der Anwendung konsistent einzusetzen:

Applikationsicon: Die Verwendung eines Applikationsicons ist optional. Wird ein Applikationsicon eingesetzt, ist es an allen vorgesehenen Stellen konsistent zu verwenden.

Einsatzorte des Applikationsicons: Das Applikationsicon kann an folgenden Stellen eingesetzt werden:

Headerbereich: Aufbau und Verhalten entsprechen vollständig dem definierten Header Bereich.

Titelzeile: Die Titelzeile benennt Objekt und Kontext eindeutig.

Seiten-Toolbar: Die Seiten-Toolbar enthält objektbezogene Aktionen wie „Zurück“, „Bearbeiten“, „Drucken“ oder „Hilfe“.

Inhaltsbereich: Der Inhaltsbereich stellt den Objektinhalt in Basisdaten (optional) und Objektdetails dar. Ein Informationsbereich (optional) kann ein- und ausgeblendet werden.

Titelzeile (A): Die Titelzeile besteht aus Varianten von Titel, Headline und einem Kontext-Breadcrumb (keine History-Breadcrumb). Ohne verständlichen, aussagekräftigen Text darf keine Detailseite bereitgestellt werden. Der Rücksprung in die auslösende Übersicht erfolgt über die Seiten-Toolbar („Zurück zur Liste“).

Seiten-Toolbar (B): Die Seiten-Toolbar bündelt die zentralen objektbezogenen Aktionen wie „Zurück zur Liste“, „Drucken“ und „Hilfe“ sowie - sofern vorgesehen - Aktionen zum Bearbeiten. Beschriftung und Reihenfolge sind innerhalb der Anwendung konsistent zu halten.

Informationsbereich (C, optional):

Inhaltsbereich (D):

Tabs und Accordion: Tabs dienen der Strukturierung gleichrangiger Inhalte. Accordions und Expander sind für nachgeordnete oder optionale Inhalte zu verwenden. Mischformen auf derselben Hierarchieebene sind zu vermeiden, um Orientierung und Reflow-Verhalten klar zu halten.

Tastaturbedienbarkeit: Alle interaktiven Elemente innerhalb von Overlays sind vollständig per Tastatur bedienbar. Der aktuelle Fokus ist jederzeit sichtbar.

Fokusführung: Beim Öffnen ist ein sinnvoller initialer Fokus zu setzen. Bei modalen Overlays ist eine Fokusfalle umzusetzen. Nicht-modale Muster dürfen den Fokus nicht einschließen; der Seitenkontext bleibt weiterhin erreichbar. Beim Schließen kehrt der Fokus in der Regel an das auslösende Element zurück. Wenn der Bedienfluss einen anderen sinnvollen Zielpunkt erfordert, wird der Fokus nachvollziehbar dorthin geführt.

Name, Rolle und Wert: Relevante Informationen sind programmatisch ermittelbar (z. B. aria-labelledby, aria-describedby, bei Modalen zusätzlich aria-modal="true").

Reflow und Responsivität: Overlays sind im Rahmen der Reflow-Anforderungen nutzbar zu gestalten. Horizontales Scrollen ist zu vermeiden und nur einzusetzen, wenn es fachlich erforderlich ist. Layoutsprünge bei Zustandsänderungen sind zu vermeiden.

Titelzeile (A): Die Titelzeile ist aussagekräftig und benennt Aktion und Zielobjekt (z. B. „Personalie XY löschen“). Ein optionaler Subtitel kann die Situation präzisieren (z. B. „Personalie hinzufügen - Registerdatensatz XY“; Haupttitel „Personalie hinzufügen“, Subtitel „Registerdatensatz XY“). Eine Farbmarkierung im Rahmen der Applikation ist zulässig.

Inhaltsbereich (B): Der Inhaltsbereich bleibt kompakt und beschränkt sich auf die konkrete Eingabe bzw. Information. Optional kann ein oberer Hinweis- oder Validierungsbereich zur Rückmeldung genutzt werden.

Buttonleiste (C): Die Buttonleiste enthält Primäraktion (z. B. Löschen, Speichern), Sekundäraktion(en) und Abbrechen. Reihenfolge und Benennung sind in der gesamten Anwendung einheitlich zu halten.

Modalität: Modalität wird nur eingesetzt, wenn sie fachlich, rechtlich oder sicherheitsrelevant erforderlich ist. Inline-Muster oder kontextnahe Bestätigungen sind vorzuziehen.

Stapelung: Dialog-Kaskaden sind zu vermeiden. Eine zweite Ebene ist nur in Ausnahmefällen zulässig. Die Schließreihenfolge entspricht der Öffnungsreihenfolge.

Größe: Die Dialoggröße richtet sich nach dem Inhalt. Maximalmaße orientieren sich an Viewport bzw. Hauptfenster. Der Dialog darf intern scrollen; bei modaler Verwendung bleibt der Hintergrund gesperrt. Horizontales Scrollen ist zu vermeiden.

Konsistentes Raster: Formulare im Dialog folgen demselben Feldlayout wie im Ansichtsmodus. Die Anordnung passt sich responsiv an und bleibt auch in schmalen Viewports übersichtlich (vgl. Layout und Resizing).

Irreversible, rechtlich wirksame oder sicherheitskritische Aktionen sind abzusichern (z. B. Objekt löschen, Veröffentlichung freigeben, rechtlich bindend absenden).

Bei drohendem Datenverlust ist eine explizite Bestätigung erforderlich (z. B. „Ungespeicherte Änderungen verwerfen?“).

Nicht fortsetzbare Fehlerzustände erfordern eine unmittelbare Kenntnisnahme oder Handlung, z. B. Sitzung abgelaufen oder Authentifizierung fehlgeschlagen.

Meldungsdialoge sind nicht für reine Informationen oder reversible Aktionen einzusetzen. Dafür sind modalarme Alternativen zu verwenden (vgl. Bestätigen und Rückgängig).

Titelzeile (A): Die Titelzeile formuliert Aktion und Zielobjekt eindeutig (z. B. „Vorgang 4711 löschen“).

Meldungs-Icon (B): Das Meldungs-Icon ist optional und abhängig von der Severity. Es unterstützt die Einordnung der Meldung (Info, Warnung, Fehler), ohne dass Farbe als alleiniges Unterscheidungsmerkmal dient.

Beschreibung (C): Die Beschreibung ist als kurzer Satz zur Wirkung bzw. Folge zu formulieren. Technische Pfade oder IDs sind im Fließtext zu vermeiden. Zusätzliche Details (z. B. Fehlercodes oder Support-Hinweise) können bei Bedarf in einem Expander bereitgestellt werden (Progressive Disclosure).

Dialogbuttons (D): Die Dialogbuttons sind eindeutig und aktionsbezogen zu beschriften (statt „OK/Ja/Nein“). Es sind mindestens eine Primäraktion (z. B. „Löschen“) sowie „Abbrechen“ bereitzustellen. Redundante Kombinationen wie „Nein“ und „Abbrechen“ sind zu vermeiden.

Inline-Bestätigungsleiste: Am betroffenen Bereich erscheint eine kurze Bestätigung. Diese benennt Aktion und Objekt und zeigt eine eindeutig beschriftete Primär- sowie Alternativaktion.

Angedockte Bestätigung am Auslöser: Neben dem auslösenden Element erscheint eine kompakte, kontextnahe Bestätigung. Aktion und Objekt sind klar benannt; die Auswahl erfolgt direkt im Sichtkontext.

Rückgängig-Hinweis: Nach schnellen, reversiblen Aktionen ist eine Rückgängig-Option vorzusehen, die Nutzende unmittelbar ausführen können.

Kontextnah statt modal: Bestätigungen erfolgen bevorzugt inline oder direkt am Auslöser. Modale Dialoge kommen nur zum Einsatz, wenn eine Bestätigung rechtlich relevant, irreversibel oder sicherheitskritisch ist.

Eindeutige Sprache: Aktionslabels benennen die konkrete Aktion und das Ergebnis (z. B. „Löschen“, „Archivieren“). Formulierungen wie „Ja/Nein“ sind zu vermeiden.

Rücknahme ermöglichen: Reversible Aktionen erhalten eine Rückgängig-Option. Diese bleibt für eine angemessene Zeit verfügbar (in der Regel 5-10 s) und wird danach entfernt oder deaktiviert.

Barrierefreiheit & Fokus: Bestätigungen übernehmen den Fokus nicht dauerhaft. Beim Schließen kehrt der Fokus in der Regel an das auslösende Element zurück. Wenn der Bedienfluss einen anderen sinnvollen Zielpunkt erfordert, wird der Fokus nachvollziehbar dorthin geführt. Die Ankündigung von Statusmeldungen erfolgt über eine Live-Region, ohne dass sich der Fokus verschiebt.

Tastatur: Enter aktiviert die Primäraktion, Esc schließt Dialoge oder bricht ab (kontextabhängig). Die Tab-Reihenfolge ist logisch, stabil und folgt dem Lesefluss.

Screenreader: Kurztexte und Labels benennen Aktion und Objekt (z. B. „Datei löschen“). „Rückgängig“ wird von Screenreadern als Bedienelement (z. B. Button oder Link) angekündigt.

Mobil: Touch-Ziele erfüllen die Mindestgröße und den Mindestabstand gemäß den geltenden Barrierefreiheitsvorgaben. Platzierung und Größe von Popovers dürfen keine für den aktuellen Task erforderlichen Interaktionen verdecken.

Inline-Leiste: Inline-Bestätigungen werden direkt im betroffenen Inhaltsbereich angezeigt und enthalten klar beschriftete Aktionen.

Angedockt: Kontextnahe Bestätigungen werden nahe am auslösenden Element angezeigt und enthalten eindeutig benannte Entscheidungsoptionen.

Rückgängig-Option: Reversible Aktionen können über eine zeitlich begrenzte, nicht blockierende Statusmeldung mit Rückgängig-Aktion angeboten werden.

Inline-Edit im Kontext: Bearbeitungsbereiche erscheinen dort, wo die Information gelesen wird - z. B. in einem Detailabschnitt, einer Karte oder in einer Tabellenzeile. Orientierung und Vergleichbarkeit bleiben erhalten.

Feldnahe Hilfen und Fehler: Hinweise und Fehlertexte sind eindeutig dem Feld zugeordnet, z. B. über aria-describedby. Die Fehlertexte enthalten konkrete Hinweise zur Behebung.

Globale Statuszone: Im Abschnitt oder Seitenkopf erscheint eine kompakte Zusammenfassung (z. B. „3 Felder prüfen“). Die Zusammenfassung kann als Sprungliste zu den betroffenen Feldern umgesetzt werden.

Start des Editierens: Nach Aktivierung des Bearbeitungsmodus wechselt der Fokus auf das erste relevante Feld. Der Bearbeitungskontext ist visuell eindeutig erkennbar (z. B. durch Rahmen, Label „Bearbeitung aktiv“ oder Zeilenhervorhebung).

Speichern und Abbrechen im lokalen Kontext: Speichern und Abbrechen gelten nur für den aktuellen Bereich (Abschnitt oder Zeile) und verändern keine anderen Teile der Seite. Nach dem Speichern oder Abbrechen kehrt der Fokus zum Auslöser oder zur bearbeiteten Zeile zurück.

Grenze von Inline-Edit: Inline-Edit ist nicht zulässig, sobald viele Felder, mehrere Fachgruppen, feldübergreifende Validierung oder Anforderungen an Deeplinks und Browser-History vorliegen. In diesen Fällen ist das Drill-Down-Pattern zu verwenden.

Validierung und Barrierefreiheit: Die Validierung erfolgt feldnah (z. B. beim Verlassen des Feldes) oder beim Speichern; das Verhalten ist konsistent zu halten. Entweder ist die Primäraktion nur bei gültigen Eingaben aktiv, oder „Speichern“ löst die Validierung aus und setzt den Fokus zur Fehlerzusammenfassung oder auf das erste fehlerhafte Feld. Fehlerzustände erhalten die Kennzeichnung aria-invalid="true". Die Verknüpfung von Hilfs- und Fehlertexten erfolgt über aria-describedby.

Tastatur: Innerhalb des Bearbeitungsbereichs speichert Enter bei gültigen Eingaben; Esc verwirft die Änderungen im aktuellen Bereich. Ausgeblendete oder nicht relevante Bedienelemente sind von der Tab-Reihenfolge auszunehmen.

Rückmeldung: Erfolgsmeldungen erscheinen als nicht blockierende Hinweise, entweder direkt im Kontext oder als globale Benachrichtigung. Fehlermeldungen bleiben sichtbar und dem Feld zugeordnet, bis der Fehler behoben ist.

Strukturierung: Große Bereiche sind in Tabs oder Accordion-Panels zu gliedern. Die Panels bleiben einzeln validier- und speicherbar, sofern dies fachlich vorgesehen ist.

Formular-Implementierung: Eingaben werden feldnah validiert und mit klaren, verständlichen Fehlermeldungen versehen.

Tabellen-Edit: Die Bearbeitung in Tabellen kann als Zeilen- oder Zellenbearbeitung mit Speichern und Abbrechen erfolgen. Bei hoher Komplexität ist zusätzlich pro Zeile ein Drill-Down-Einstieg vorzusehen.

Fehlermeldungen: Feldnahe Rückmeldungen werden direkt am betroffenen Eingabeelement angezeigt. Zusammenfassende Hinweise können ergänzend als nicht blockierende Statusmeldung dargestellt werden.

Auslöser im Ausgangskontext: Pro Objekt ist eine eindeutig benannte Aktion vorgesehen (z. B. „Details“ oder „Bearbeiten“). Diese Aktion führt zur Detailansicht für die vollständige, strukturierte Bearbeitung.

Detailkopf: Der Kopfbereich enthält die Benennung von Objekt und Modus sowie eine eindeutig beschriftete Zurück-Aktion. Die Verwendung von Breadcrumbs ist optional.

Statuszone und Fehlerübersicht: Oberhalb des Formulars kann eine kompakte Statuszone stehen (z. B. „3 Felder prüfen“). Die Fehlerübersicht dient als Sprungliste mit direkter Navigation zu den betroffenen Feldern.

Formular und Aktionen: Die Inhalte sind nach Fachlogik gruppiert (Abschnitte, Tabs oder Accordion). Die Aktionen „Speichern“ und „Abbrechen“ sind konsistent platziert - immer an derselben Stelle, bei Bedarf oben und unten. Feldnahe Hilfen und Fehler bleiben sichtbar.

Einsatzkriterien: Drill-Down eignet sich bei vielen Feldern oder Gruppen, feldübergreifender Validierung, komplexen Abläufen (z. B. Rollen, Berechtigungen, mehrere Teilobjekte) insbesondere wenn klare Überschriften, Landmarks und stabile Navigation erforderlich sind.

Navigation und History: Die Browser-Navigation (Zurück/Vorwärts) funktioniert erwartungsgemäß ohne unerwartete Sprünge oder Datenverlust. Deeplinks auf Ansicht und Bearbeitung sind möglich. Routen und Zustände bleiben konsistent.

Rückkehr in den Kontext: Beim Zurückkehren erfolgt die Wiederherstellung von Filter, Sortierung, Pagination und Scrollposition. Das bearbeitete Objekt ist im Ausgangskontext leicht auffindbar (z. B. durch Fokussierung oder Scrollposition). Eine Markierung wie „Aktualisiert“ ist zulässig.

Validierung: Die Validierung erfolgt beim Speichern, optional zusätzlich beim Verlassen eines Feldes (on blur). Feldfehler erhalten die Kennzeichnung aria-invalid="true". Die Verknüpfung von erklärenden Texten erfolgt über aria-describedby. Eine optionale Fehlerübersicht oben erleichtert das Auffinden betroffener Felder.

Ungespeicherte Änderungen: Beim Verlassen mit ungespeicherten Änderungen erhalten Nutzende eine Entscheidungsmöglichkeit („Änderungen verwerfen“ oder „Weiter bearbeiten“). Modale Dialoge sind nur bei drohendem Datenverlust zulässig (vgl. Meldungsdialoge). Bestätigungen erfolgen standardmäßig nicht-modal (z. B. Inline-Leiste oder Popover).

Barrierefreiheit und Fokusführung: Beim Öffnen der Detailansicht erfolgt die Setzung eines sinnvollen Initialfokus (z. B. Seitenüberschrift oder erstes Eingabefeld). Beim Zurückkehren liegt der Fokus auf dem auslösenden Element oder der bearbeiteten Zeile.

Barrierefreiheit und Fehlerbehandlung: Bei Fehlern erfolgt die Anzeige einer Zusammenfassung (z. B. „3 Felder prüfen“) mit Links zu den betroffenen Feldern. Der Fokus wechselt zur Zusammenfassung oder zum ersten fehlerhaften Feld. Alle Links sind programmatisch fokussierbar und vollständig per Tastatur bedienbar.

Tastatur: „Speichern“ ist per Tastatur erreichbar; Formular-Submit per Enter ist zulässig. Nach erfolgreichem Speichern bleibt der Fokus stabil.

Screenreader: Titel und Struktur benennen Objekt und Modus eindeutig. Die Ankündigung von Statusmeldungen erfolgt über eine Live-Region ohne Fokusübernahme.

Rückkehrlogik: Beim Verlassen und Zurückkehren zur Detailansicht sollen Fokus und Scrollposition nachvollziehbar wiederhergestellt werden.

Orientierung: Eine klare Orientierung kann über Breadcrumbs, Seitentitel und eine eindeutig platzierte Zurück-Aktion unterstützt werden.

Struktur: Umfangreiche Inhalte können über Karten, Panels, Tabs oder aufklappbare Bereiche gegliedert werden.

Validierung und Feedback: Feldnahe Rückmeldungen werden direkt im Kontext angezeigt. Zusammenfassende Hinweise können ergänzend als nicht blockierende Statusmeldung dargestellt werden.

Ungespeicherte Änderungen: Bei drohendem Datenverlust ist eine verständliche Bestätigung vorzusehen. Diese erfolgt bevorzugt nicht-modal; ein Meldungsdialog ist nur bei fachlicher Notwendigkeit zulässig.

Globale Benachrichtigungen: Asynchrone Ereignisse wie Erfolg, Hinweis, Warnung oder Fehler werden als nicht blockierende Benachrichtigungen angezeigt. Die Meldungen sind kurz und verständlich zu halten. Hinweise auf nächste Schritte sind zulässig.

Inline-Hinweise: Hinweise mit Bezug zu einem Bereich oder Feld erscheinen direkt am betroffenen Kontext. Ursache und Behebung bleiben im selben Sichtbereich.

Kombinierte Darstellung: Bei Validierungsfällen erfolgt eine feldnahe Beschreibung des Fehlers sowie eine kompakte globale Zusammenfassung. Die feldnahen Fehlertexte bleiben die Primärquelle.

Schließen und Timeout: Reine Informationsmeldungen dürfen automatisch ausblenden. Warnungen und Fehler erfordern in der Regel ein explizites Schließen oder bleiben sichtbar, bis der Zustand behoben ist.

Kein Fokus-Hijack: Die Ankündigung von Meldungen erfolgt über aria-live (in der Regel polite). Der Fokus verbleibt bei den Nutzenden.

Text statt Farbe: Schweregrade sind sprachlich zu benennen (z. B. „Warnung“, „Fehler“). Die Farbe dient als ergänzendes Unterscheidungsmerkmal.

Anzahl gleichzeitiger Meldungen: Mehrere Meldungen dürfen keine Primäraktionen verdecken. Der Abbau der Meldungen erfolgt in geordneter Reihenfolge. Kritische Meldungen bleiben ausreichend lange zugänglich.

Screenreader: Die Meldungstexte sind kurz und klar zu halten. Eine Option „Details anzeigen“ ist zulässig. Interaktive Elemente (z. B. Rückgängig-Link) sind per Tastatur erreichbar und aussagekräftig beschriftet.

Mobil: Platzierung und Größe der Meldungen dürfen keine primären Inhalte oder Aktionen verdecken. Wichtige Meldungen müssen auffindbar bleiben.

Global: Ereignisse außerhalb des direkten Feldkontexts werden als nicht blockierende, gut wahrnehmbare Benachrichtigung angezeigt.

Inline: Feld- oder abschnittsnahe Hinweise werden direkt im jeweiligen Kontext angezeigt.

Titelzeile (A): Die Titelzeile beschreibt die Aufgabe verständlich (z. B. „Neuen Antrag anlegen“) und verortet sie fachlich. Die Regeln für Titelzeilen entsprechen denen von Dialogen.

Schrittanzeige (B): Die Schrittanzeige zeigt eine lineare Abfolge von Schritten (horizontal oder vertikal). Der aktuelle Schritt ist visuell hervorgehoben; erledigte Schritte sind erkennbar (z. B. durch einen Haken). Optional ist die Anzeige des Fortschritts (n von gesamt) vorgesehen.

Inhaltsbereich (C): Der Inhaltsbereich enthält Formulare und Komponenten des aktiven Schritts. Leer-, Lade- und Fehlerzustände sind zu definieren. Das Layout folgt dem allgemeinen Raster gemäß Layout und Resizing.

Steuerleiste (D): Die Primäraktionen umfassen „Weiter“ sowie „Abschließen“ (im letzten Schritt) und „Zurück“. Die Sekundäraktionen umfassen „Abbrechen“ und „Zwischenspeichern“ oder „Ablegen“ (falls fachlich sinnvoll). Position, Beschriftung und Tastaturverhalten sind konsistent zu halten.

Linearität und Navigation: Standard ist ein linearer Stepper: „Weiter“ ist erst nach valider Eingabe aktiv. „Zurück“ ist jederzeit möglich; erledigte Schritte dürfen direkt angewählt werden. Die Vorwärtsnavigation per Schrittanzeige ist nur zulässig, wenn Folgeschritte inhaltlich unabhängig sind.

Validierung und Feedback: Die Validierung erfolgt feldnah (inline) mit verständlichen Fehlertexten, ergänzt um eine globale Meldungszone (role oder aria-live) pro Schritt. „Weiter“ und „Abschließen“ bleiben deaktiviert, bis die Pflichtfelder valide sind. Bei „Weiter“ wechselt der Fokus zur Fehlerzusammenfassung oder zum ersten fehlerhaften Feld (programmatisch fokussierbar, z. B. tabindex="-1" mit Fokussetzung). Modale Fehlermeldungen sind zu vermeiden.

Fokusführung und Tastatur: Beim Schrittwechsel erfolgt die Setzung des Fokus auf die Schritt-Überschrift oder den ersten sinnvollen Inhalt. Innerhalb des Steppers folgt die Tab-Reihenfolge der Sichtreihenfolge; Enter löst die jeweilige Primäraktion aus, Esc bricht ab (sofern kein Datenverlust droht, andernfalls erfolgt eine Bestätigung im Kontext). Die Schrittanzeige ist tastaturbedienbar (Links oder Buttons mit sichtbarem Fokus; semantisch als tablist oder region, abhängig von der Komponenten-API).

Zustände und Reflow: Zustandswechsel erfolgen stabil und ohne störende Layoutsprünge. Die Darstellung passt sich responsiv an; die Steuerleiste bleibt erreichbar.

Zwischenspeichern und Abbruch: Zwischenspeichern oder Ablegen ermöglicht die Unterbrechung und spätere Fortsetzung (z. B. Wiedervorlage im Dashboard). „Abbrechen“ verwirft Änderungen nur nach klarer, nicht-modaler Bestätigung im Kontext (Bestätigungsleiste oder Popover) mit optionaler Rückgängig-Option.

Anti-Pattern (vermeiden): Ein Stepper im modalen Dialog ist ohne zwingenden Grund nicht zulässig. Komplexe Branching-Szenarien mit stark divergierenden Pfaden erschweren die Orientierung (besser: Vorab-Entscheid, dann schlanke Linie). Uneinheitliche Primäraktionen wie „OK“ statt „Weiter“ oder „Abschließen“ sind zu vermeiden. Fehler dürfen nicht ausschließlich als globale Benachrichtigung ohne feldnahe Erklärung erscheinen. Der Formularzustand darf beim Navigieren (Zurück oder Weiter) nicht verloren gehen.

Tastatur: Enter aktiviert die Primäraktion; Esc bricht ab oder löst eine Bestätigung aus (bei drohendem Datenverlust). Nach erfolgreichem Schrittwechsel bleibt der Fokus stabil auf dem neuen Inhalt.

Screenreader: Titel und Struktur des Steppers benennen den aktuellen Schritt und den Gesamtfortschritt eindeutig. Die Ankündigung von Statusmeldungen erfolgt über eine Live-Region ohne Fokusübernahme.

Schrittanzeige: Die aktuelle Position innerhalb des Ablaufs ist jederzeit erkennbar. Schrittnamen und Fortschritt werden verständlich dargestellt.

Inhaltsbereich: Die Inhalte der einzelnen Schritte sind klar voneinander getrennt und logisch strukturiert.

Steuerleiste: Die Navigation zwischen den Schritten wird konsistent am unteren Rand des Inhaltsbereichs platziert.

Validierung und Feedback: Fehlermeldungen werden feldnah angezeigt. Zusammenfassende Hinweise können ergänzend als nicht blockierende Statusmeldung dargestellt werden.

Maus: Klick auf das Eingabefeld öffnet den Kalender, ein weiterer Klick auf das gewünschte Datum wählt dieses aus.

Tastatur: Tabulator zur Fokussierung, Pfeiltasten zur Navigation, Enter zur Auswahl.

Maus: Pfeilsymbole erhöhen oder verringern den Wert.

Tastatur: Direkte Eingabe von Zahlen, Pfeiltasten zur Erhöhung/Verringerung.

Maus: Klick auf die oberste Kategorie öffnet die Unterkategorien.

Tastatur: Navigation mit Tab und Pfeiltasten, Enter zur Auswahl.

Maus: Klick öffnet die Liste, ein weiterer Klick wählt den Eintrag.

Tastatur: Tab zur Navigation, Pfeiltasten zur Auswahl, Enter zur Bestätigung.

Maus: Klick auf Kontrollkästchen oder Listenpunkte zur Mehrfachauswahl.

Tastatur: Tabulator zur Fokussierung, Pfeiltasten zur Navigation, Space zur Auswahl.

Maus: Ein Klick auf "+ weiteres Element" erzeugt eine weitere Context Group und ein Klick auf Delete-Icon löscht die ausgewählte Context-Group.

Tastatur: Tabulator zur Fokussierung, Pfeiltasten zur Navigation, Enter zur Auswahl.

Klarer visueller Fokus bei Navigation mit der Tastatur.

Zustände (aktiviert, deaktiviert, teilweise ausgewählt) müssen durch Screenreader korrekt angesagt werden.

Mindestkontrast von 4,5:1 für alle Zustände (inklusive Hover und Fokus).

Nutzung von aria-checked und aria-label zur Beschreibung.

Gruppierung ähnlicher Checkboxen mit fieldset und legend.

Click-Target-Area ist mindestens 44x44 Pixel.

Radiobuttons sollten immer beschriftet und in logischer Reihenfolge angeordnet sein.

Fokus- und Hover-Stile müssen klar erkennbar sein.

Verwendung von role="radiogroup" für zusammengehörige Optionen.

Klare Statusmeldung wie "ausgewählt" über Screenreader.

Click-Target-Area ist mindestens 44x44 Pixel.

Dropdowns sollten sich mit der Tastatur öffnen, navigieren und schließen lassen.

Keine automatische Auswahl beim Öffnen; Nutzende müssen die Auswahl explizit bestätigen.

Nutzung von aria-expanded und aria-haspopup zur Kommunikation des Zustands.

Liste muss tastaturzugänglich sein, und der Fokus sollte nicht verloren gehen.

Ausgewählte Elemente sollten visuell hervorgehoben werden.

Klarer Hinweis, wenn die maximale Auswahlanzahl erreicht ist.

Verwendung von aria-selected zur Kennzeichnung ausgewählter Elemente.

Unterstützung von Tastenkombinationen für das schnelle Auswählen/Deselektieren.

Logische Gruppierung: Filteroptionen sollten thematisch gruppiert und leicht zugänglich sein.

Interaktivität: Änderungen an Filtereinstellungen sollten das Ergebnis direkt aktualisieren (zum Beispiel durch Live-Aktualisierung).

Filterkomponenten sollten mittels fieldset und legend strukturiert sein.

Klarer visueller Fokus und hörbare Rückmeldungen für Screenreader bei Änderungen.

Eingabefeld: Sollte klar beschriftet und mit einer Autovervollständigungsfunktion ausgestattet sein, falls sinnvoll.

Filterbare Ergebnisse: Die Suchergebnisse sollten weiter eingegrenzt werden können (zum Beispiel durch zusätzliche Filteroptionen).

Einsatz von aria-live für dynamische Ergebnislisten.

Sicherstellung, dass Screenreader alle Interaktionen klar kommunizieren (zum Beispiel „X Ergebnisse gefunden“).

Die Kombination aus Such- und Filterfunktionen erhöht die Effizienz bei der Navigation durch große Datenmengen.

Alle Interaktionen müssen tastaturzugänglich und in dynamischen Kontexten (aria-live) barrierefrei implementiert werden.

Sicherstellung, dass Filtereinstellungen beim Verlassen der Seite erhalten bleiben, sofern es sinnvoll ist.

Übersichtliche Navigation: Inhalte sollten logisch gegliedert und mit Filter-, Such- und Selektionsmöglichkeiten kombinierbar sein.

Markierung und Rückmeldung: Markierte Elemente sollten visuell hervorgehoben und durch dynamische Hinweise bestätigt werden.

Sammlung bearbeiten: Benutzende müssen die Möglichkeit haben, gesammelte Elemente zu überprüfen, zu ändern oder zu entfernen.

Tastaturbedienung: Alle Aktionen müssen mit der Tastatur steuerbar sein, zum Beispiel durch Tab- und Enter-Tasten oder spezifische Pfeiltasten-Navigation.

Screenreader-Unterstützung: Markierte Elemente und deren Status müssen eindeutig angesagt werden.

Visuelle Kontraste: Hervorgehobene und markierte Elemente sollten mindestens ein Kontrastverhältnis von 4,5:1 erfüllen.

Tastaturzugänglichkeit für alle Funktionen.

Screenreader-Kompatibilität durch semantische ARIA-Attribute.

Visuelle Klarheit durch hohe Kontraste und verständliche Beschriftungen.

Klare Struktur: Überschriften müssen mit semantischen Tags (<th>) ausgezeichnet sein, um die Bedeutung der Inhalte zu verdeutlichen.

Responsives Design: Tabellen sollen sich an verschiedene Bildschirmgrößen anpassen und bei Platzmangel scrollbar sein.

Barrierefreiheit: Screenreader-Unterstützung durch ARIA-Attribute wie aria-labelledby und klare Fokusführung bei der Navigation.

Interaktivität: Sortier-, Filter- und Exportmöglichkeiten, die über Tastatur und Maus zugänglich sind.

Fokussierung aller interaktiven Elemente innerhalb der Zeile per Tabulator.

Klare visuelle und sprachliche Rückmeldungen bei Aktionen (zum Beispiel „Änderung gespeichert“).

Beschriftungen und ARIA-Attribute für Screenreader.

Klare visuelle und sprachliche Rückmeldungen bei Aktionen (zum Beispiel „Datensatz gelöscht“).

Beschriftungen und ARIA-Attribute für Screenreader.

Bei nicht blockierenden Rückgängig-Hinweisen erfolgt die Ankündigung über eine geeignete Live-Region, ohne den Fokus zu entziehen.