Inhaltsbereich Navigation Navigation Fußzeile

Hilfen, Fehlerhinweise und Meldungen

Verwendung

Bildschirmfoto von beispielhaften Formularelementen mit den im Folgenden beschriebenen Hilfen.

Zur Unterstützung der Nutzenden bietet das Design System verschiedene Mittel, die je nach Kontext und Bedarf in der Anwendung zielgerichtet die jeweils richtigen Hilfen bieten.

1. Label

Idealerweise erschließt sich der Zweck eines Formularelements bereits aus dem eindeutig zugeordneten Label. Grundsätzlich sollen <label>-Elemente stets sichtbar sein. Lediglich in begründeten Ausnahmefällen, wie im begrenzten Raum von Datentabellen oder Data Grids, können sie visuell „versteckt“ werden, müssen aber weiterhin im Markup vorhanden und korrekt zugeordnet sein.

In logisch zusammenhängenden Gruppen von Formularelementen können die Labels durch weitere (Meta-)Informationen aus der Legende eines Fieldsets ergänzt werden.

Labels können in begründeten Ausnahmefällen auch Hyperlinks enthalten, um weitere Sachverhalte wie z. B. Nutzungsbedingungen zu verlinken.

2. Hilfetexte

In Fällen, wo der Text eines Labels nicht ausreicht oder nicht selbsterklärend genug ist, kann zur Vermeidung von Falscheingaben ein weiterer Hilfetext unterhalb des Formularelements angezeigt werden. Gestalterische Vorgaben, Positionierung und weitere Regeln finden sie bei den jeweiligen Formularelementen.

3. Tooltips

Optionale Tooltips geben eine erweiterte Kontext-spezifische Hilfestellung zu Inhalten und Funktionen. Sie werden eingesetzt, wenn zusätzliche Erklärungen für das Verständnis von einzelnen Feldern zwingend notwendig sind und es keine andere Möglichkeit gibt, diese Hilfen z. B. aus Platzgründen dauerhaft sichtbar zu platzieren. Übergeordnete Informationen müssen dauerhaft sichtbar angezeigt werden, wenn sie gesamte Schritte im Prozess betreffen.

Beispiel-Tooltip.

4. Fußnoten

Wenn der in einem Tooltip sinnvolle und zur Verfügung stehende Platz nicht ausreicht, dann können bei besonders erläuterungsbedürftigen Inhalten und Funktionen, aber auch zur Kommunikation juristischer Sachverhalte und Vorgaben, Fußnoten eingesetzt werden. Im Gegensatz zu Hilfetexten und Tooltips können diese auch weitere Strukturelemente und Links enthalten und sind in ihrer Länge nicht begrenzt.

5. Hilfeseiten

Dienstleistungen steht es frei, komplexere Sachverhalte auf eigenen Seiten im Hilfebereich des Zoll-Portals zu erklären. Da diese aber nur übergeordnete Themen und nicht einzelne Feldfunktionen erklären sollten, werden diese Hilfeseiten aus einem eigenständigen Bereich im Footer der Masken verlinkt.

6. Fehlerhinweise

Wenn trotz aller Hilfen ein Validierungs- oder anderer Fehler in einem Bearbeitungsschritt aufgetreten ist, der eindeutig einem Feld zuzuordnen ist, oder auch wenn ein Pflichtfeld nicht befüllt wurde, dann wird ein Fehlerhinweis am betroffenen Feld angezeigt. In der Regel ist dies der Fall, wenn ein Bearbeitungsschritt mit fehlenden Daten oder unzulässigen Eingabewerten durch die Nutzenden beendet werden soll.

Neben der Hervorhebung des jeweiligen Feldes durch Rahmenfarbe und -stärke (siehe hierzu die Fehlerzustände der Elemente im jeweiligen Design-Tab) muss es einen zugeordneten aussagekräftigen Fehlertext unmittelbar am betroffenen Formularelement geben. In diesem wird knapp und prägnant auf den Fehler hingewiesen und es werden, sofern möglich, Lösungen zur Behebung des Fehlers in kurzer Form erklärt, z. B.: „[Feldname] ist ein Pflichtfeld und darf nicht leer sein.“
Dieser Fehlertext muss entfernt werden, sobald die clientseitige Validierung erkennt, dass der Fehler behoben wurde.

Beispielhafte Globale Fehlermeldung, die auf ein unzureichendes Vertrauensniveau hinweist.

Fehler, die nicht eindeutig einem Feld zugeordnet werden können, werden als Globale Fehlermeldung in Form eines Toasts angezeigt. Auch bei einer Mehrzahl von Fehlern wird lediglich ein Toast angezeigt, das auf das Vorhandensein von Fehlern hinweist; die eigentlichen Hinweise zur Behebung befinden sich wie zuvor beschrieben an den betroffenen Eingabe- und Auswahl-Elementen.

Fehler in der Anwendung

Bei einem technischen Fehler, oder wenn die Fehlerursache nicht nur einem einzelnen Feld zugeordnet werden kann, wird eine Fehlermeldung und eine Verhaltensanweisung angezeigt (vgl. Abschnitte zu Modalen Dialogen sowie zu Hinweis- und Fehlermeldungen).

Serverseitige Anwendungsfehler werden Nutzenden durch die Verwendung einer entsprechenden Abfangseite der 50x-Serie kommuniziert.

7. Platzhaltertexte

Bitte beachten Sie, dass Platzhalter in Formularelementen als optionales Komfortmerkmal kein Ersatz für fehlende Formular-Labels sind, da sie nicht geeignet sind, um den in Erfolgskriterium 4.1.2 Name, Rolle, Wert geforderten sog. „Accessible Name“ zu bilden. Eine alleinige Verwendung an Formularelementen ohne ein weiteres zugeordnetes Label ist somit ein Verstoß gegen die Vorgaben der BITV.

Eindeutigkeit der Beschriftungen

Bei der Konzeption der verschiedenen Hilfen, Fehlerhinweise und Meldungen muss beachtet werden, dass diese in Summe ein eindeutiges und präzises Ergebnis liefern müssen. Gerade die Verwendung von ARIA-Attributen oder die beliebige Vergabe von title-Tooltips birgt die Gefahr, dass widersprüchliche oder falsche Informationen zustandekommen, wenn nicht beachtet wird, wie Browser Accessible Names berechnen:

  1. aria-labelledby an einem übergeordneten Element überschreibt alle folgenden Inhalte und Attributwerte von untergeordneten Elementen. Wenn vorhanden, dann wird an dieser Stelle bereits die Bildung des “Accessible Names” als vollständig beendet und alles Weitere wird ignoriert.
  2. aria-label gilt, wenn aria-labelledby nicht verwendet wird, und auch hier werden weitere Inhalte ab 3. ff. ignoriert bzw. überschrieben.
  3. Wenn 1. oder 2. nicht verwendet werden, dann gilt z. B. der Inhalt des Labels bei einem Eingabe- oder Auswahlelement oder der value eines Buttons; wenn dies ein Icon-Button ist, dann gilt dessen Alternativtext.
  4. Wenn 1. – 3. fehlen, es aber ein fieldset mit legend gibt, dann wird dessen Textinhalt einbezogen, allerdings nur als “Accessible Description” und mit erheblichem Potenzial für Fehlinformationen.
  5. Wenn kein Label zugeordnet ist, dann wird der Wert eines möglicherweise vorhandenen title-Attributs als Reparatur-Technik für defekten Code genommen, aber auch in diesem Fall nur als “Accessible Description”, was strenggenommen einen BITV-Verstoß darstellt.
  6. Wenn es auch kein title gibt, dann gilt der Inhalt eines eventuell vorhandenen placeholder.
  7. Wenn vorhanden, dann wird der Inhalt eines via aria-describedby referenzierten Elementes als “Accessible Description” zu 1. – 6. dazu addiert.

Wichtig: die genannten ARIA-Attribute funktionieren per Spezifikation nur an Elementen mit einer nicht-generischen Rolle wie z. B. <nav>, jedoch nicht bei generischen Elementen wie <div> und <span> ohne ein valides role-Attribut. Beispiel: <div aria-label="Ihre E-Mail-Adresse"> wird ignoriert, es bleibt ein Element ohne besondere Bedeutung und die vermeintliche Hilfe bleibt für Screenreader-Nutzende verborgen.

Umgang mit Daten

Daten in fachlich nicht korrekt ausgefüllten Felder werden nicht verändert, um die Nutzenden anhand der Eingaben oder Auswahlen in Kombination mit der Fehlermeldung klar auf den Ist- und Soll-Zustand aufmerksam zu machen.

Falls ein Bearbeitungsschritt mit nicht ausgefüllten Pflichtfeldern durch die Nutzenden abgebrochen wird, dann entfällt die Pflicht der Eingabe und es wird keine Fehlermeldung angezeigt.