Verwendung
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. Wir definieren, welche Textelemente in Formularen eingesetzt werden, wo sie platziert werden und welche Art von Inhalt in sie gehört.
Ziel ist ein konsistentes Muster, das Nutzern hilft, sich in jedem Antrag schnell zu orientieren: Überschriften geben Orientierung beim Scannen, einleitende Texte setzen den kontextuellen Rahmen, Hilfe zum Ausfüllen findet sich in der Marginalspalte. Haben Nutzer dieses Muster einmal verstanden, fällt ihnen die Orientierung im nächsten Antrag leichter — sie können sich auf das Wesentliche konzentrieren.
Wie Texte bürgernah formuliert werden, ist in den Hilfen für Konzeption & Redaktion beschrieben.
1. Überschriften 
Überschriften fassen den Bereich über dem sie stehen kurz und sinnvoll zusammen, sodass Nutzer erkennen können, was sie erwartet. Nutzer scannen Überschriften zur Orientierung auf einer Seite — daher sollten Überschriften nicht mit generischen oder sich wiederholenden Begriffen beginnen.
Seitenüberschriften spiegeln sich in der Fortschrittsanzeige wider. Sie müssen nicht exakt gleich formuliert sein, sollten sich aber ähneln; in der Fortschrittsnavigation eher kürzer.
2. Einleitende Texte
Seiten und Sektionen haben nach ihrer Überschrift einen einleitenden Text, der den Kontext setzt. Einleitende Texte sind vor allem dann einzusetzen, wenn eine Information auf den gesamten jeweiligen Bereich zutrifft.
Dieser Text beschreibt, was auf dieser Seite oder in diesem Abschnitt zu tun ist bzw. abgefragt wird und idealerweise auch kurz warum. Das baut Verständnis auf und nimmt Nutzende mit, statt sie nur auszufragen.
3. Formular-Label
Der Zweck eines Formularelements muss sich aus dem zugeordneten Label erschließen. Die Kennzeichnung als Pflichtfeld muss innerhalb des Labels stattfinden, andere Stellen sind hierfür nicht vorgesehen.
Grundsätzlich sollen <label>-Elemente stets sichtbar sein. Lediglich in begründeten Ausnahmefällen können sie visuell „versteckt“ werden, wie z. B. im begrenzten Raum von Datentabellen oder Data Grids. Sie 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 Links enthalten, um auf weitere Sachverhalte wie z. B. Nutzungsbedingungen zu verweisen.
Wie Browser die Ausgabe von Labels und verknüpften Hilfetexten im Screenreader berechnen ist im Abschnitt „Eindeutigkeit der Beschriftungen und Hilfen“ beschrieben.
4. Hilfetexte
In Fällen, in denen der Text eines Labels nicht ausreicht oder nicht selbsterklärend genug ist, können zur Vermeidung von Falscheingaben Hilfetexte angezeigt werden. Gestalterische Vorgaben, Positionierung und weitere Regeln finden Sie bei den jeweiligen Formularelementen. Es gibt zwei Arten von Hilfetexten:
a. Hilfe in der Marginalspalte
Die Marginalspalte ist primär für Hilfetexte vorgesehen und soll am häufigsten genutzt werden. Idealerweise sind alle Angaben selbsterklärend und die Marginalspalte bleibt leer. Wenn aber eine Hilfe ausformuliert werden muss, dann ist hier der richtige Platz.
Neben Hilfetexten kann die Marginalspalte auch externe Links enthalten, z. B. weiterführende Informationen zu einer Auswahloption oder einem Verfahren in der Portal-Hilfe. Hilfetexte benötigen keine Headline.
b. Hilfetext am Feld
Kurze, kontextrelevante Infos werden direkt unter dem Formularelement angezeigt. Typische Beispiele sind Formatangaben (tt.mm.jjjj) oder Erläuterungen zur Herkunft der Daten bei Readonly-Feldern wie „von ELSTER“, „von BundID“.
Ausnahme: Einzelne Optionen bei Gruppen von Checkboxen oder Radiobuttons können bei Bedarf einen Hilfetext direkt unter ihrem Label haben. Labels müssen eigentlich selbsterklärend sein, wenn aber komplexe oder behördliche Begriffe verwendet werden und zu den meisten Optionen eine Erklärung vorliegt, dann darf diese direkt unter das jeweilige Label geschrieben werden.
Platzhaltertexte
Bitte beachten Sie, dass Platzhalter in Formularelementen als optionales Komfortmerkmal kein Ersatz für Hilfetexte oder 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 zugeordnete Label und Hilfetexte ist somit ein Verstoß gegen die Vorgaben der BITV.
5. Tooltips
Nicht jede Hilfe muss sofort sichtbar sein. Wenn eine Information nur für einen Teil der Nutzenden relevant ist, dann kann sie auch in einem Tooltip hinterlegt werden.
Diese optionalen Tooltips geben eine erweiterte kontextspezifische Hilfestellung zu Inhalten und Funktionen. Sie werden eingesetzt, wenn zusätzliche Erklärungen für das Verständnis einzelner Felder zwingend notwendig sind und es keine andere Möglichkeit gibt, diese Hilfen z. B. aus Platzgründen dauerhaft sichtbar zu platzieren.
Typische Fragen, die sich Nutzende vermutlich stellen würden, wie z. B. „Wo finde ich meine Steuer-ID?“ werden hier beantwortet. Dies spart Platz und hält die Marginalspalte aufgeräumt. Die Antwort erscheint erst bei Klick auf den Trigger-Button.
Zur Abgrenzung: Übergeordnete Informationen müssen jedoch zwingend dauerhaft sichtbar angezeigt werden, wenn sie gesamte Schritte im Prozess betreffen (s. o. bei 4. Hilfetexte). Gleiches gilt für Hinweise mit rechtlichen oder finanziellen Auswirkungen.
In Formularen stehen Tooltips grundsätzlich immer in der hierfür vorgesehenen Marginalspalte rechts. Im Aufbau des Layout-Grids muss darauf geachtet werden, dass Tooltips in der Tab-Reihenfolge unmittelbar auf das Formularelement folgen, dessen Funktion erklärt werden soll.
6. Fußnoten
Wenn der in einem Tooltip sinnvolle und zur Verfügung stehende Platz nicht ausreicht oder der Lesefluss nicht unterbrochen werden soll, dann können bei besonders erläuterungsbedürftigen Inhalten und Funktionen, aber auch zur Kommunikation juristischer Sachverhalte, Quellenangaben 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.
Fußnoten enthalten ausschließlich weiterführende Informationen, die zum unmittelbaren Ausfüllen des Formulars nicht relevant sind.
7. 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.
Do’s and Don’ts
So:
- Links zu Fußnoten oder der Portal-Hilfe nur in Fließtexten (inkl. einleitenden Texten sowie Hilfetexten in der Marginalspalte)
- Hilfetexte aussagekäftig, aber kurz und prägnant formulieren.
So nicht:
- Links zu Fußnoten oder der Portal-Hilfe in Überschriften oder in den Hilfetexten unterhalb von Formularfeldern.
- Rechtlich relevante Informationen in einem Tooltip “versteckt”.
8. 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 unmittelbar 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 per aria-describedby 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 und seine Verknüpfung müssen entfernt werden, sobald die clientseitige Validierung erkennt, dass der Fehler behoben wurde.
Ausnahme: Nur 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, werden 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.
Umgang mit fehlerhaften Daten
Daten in fachlich nicht korrekt ausgefüllten Feldern 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.
9. ARIA-Attribute
WAI-ARIA dient einerseits der Verbesserung der Barrierefreiheit für bestimmte Hilfsmittel, kann andererseits bei unbedachtem Einsatz auch negative Auswirkungen auf die BITV-Konformität haben. Gerade die Verwendung von Attributen wie aria-label birgt die Gefahr, dass hierdurch der programmatisch ermittelbare Bezeichner eines Elements vom sichtbaren Text abweicht, was dann zu Problemen zum Beispiel bei der Sprachbedienung führen wird. Daher dürfen Formular-Elemente und insbesondere Buttons, die bereits sichtbaren Text enthalten, keine aria-label enthalten.
Wie Browser und Hilfsmittel berechnen, welche Informationen zu welchem Zeitpunkt ausgegeben werden, ist im folgenden Abschnitt beschrieben.
Eindeutigkeit der Beschriftungen und Hilfen
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 zustande kommen, wenn nicht beachtet wird, wie Browser Accessible Names berechnen:
aria-labelledbyan 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.aria-labelgilt, wennaria-labelledbynicht verwendet wird, und auch hier werden weitere Inhalte ab 3. ff. ignoriert bzw. überschrieben.- Wenn 1. oder 2. nicht verwendet werden, dann gilt z. B. der Inhalt des Labels bei einem Eingabe- oder Auswahlelement oder der
valueeines Buttons; wenn dies ein Icon-Button ist, dann gilt dessen Alternativtext. - Wenn 1. – 3. fehlen, es aber ein
fieldsetmitlegendgibt, dann wird dessen Textinhalt einbezogen, allerdings nur als “Accessible Description” und mit erheblichem Potenzial für Fehlinformationen. - 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. - Wenn es auch kein
titlegibt, dann gilt der Inhalt eines eventuell vorhandenenplaceholder. - Wenn vorhanden, dann wird der Inhalt eines via
aria-describedbyreferenzierten 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> oder <input>, jedoch nicht bei generischen Elementen wie <div> und <span> ohne ein valides role-Attribut, wie die folgenden Beispiele zeigen:
Do’s and Don’ts
So:
<nav aria-labelledby="$IDREF"><h4 id="$IDREF">Subnavigation</h4>kennzeichnet eine von mehreren<nav>-Landmarks eindeutig als die Subnavigation und wird so auch durch Screenreader ausgegeben.<label>…<input … aria-describedby="fehlertext"><span id="fehlertext">Fehlerhinweis</span>kombiniert in der Ausgabe den Labeltext mit dem Hinweis auf einen Fehler.
So nicht:
<div aria-label="Ihre E-Mail-Adresse">wird ignoriert, es bleibt ein leeres Element ohne besondere Bedeutung und die vermeintliche Hilfe bleibt hier für Nutzende verborgen.<button aria-label="Abschicken">OK</button>überschreibt den sichtbaren Text, womit der Button nicht mehr auf den Sprachbefehl “OK” reagiert.