Eingabefelder vom Typ input type="file" bieten folgende Merkmale und Funktionalitäten:
Hochladen einzelner Dateien per Button und Auswahldialog des jeweiligen Browsers bzw. Betriebssystems,
paralleles Hochladen mehrerer Dateien gleichzeitig per Button und Auswahldialog.
Variante ohne Upload-Icon
Beschriftung
Wie alle Standard-Buttons besitzen auch Datei-Uploads einen sichtbaren Text, der als ausreichende Beschreibung der Funktionalität dient. Darüber hinaus ist auch eine Auflistung der erlaubten Dateiformate zwingend erforderlich (z. B. .PDF, .DOCX).
Die erforderliche Einschränkung auf bestimmte Dateiformate, die akzeptiert werden (sogenannte “MIME-Types”) geschieht je nach fachlichem Bedarf individuell über die Administrations-Oberfläche und ist somit vom Design System nicht festlegbar.
Tooltips
Die Komponente kann aus Platzgründen optional ein zugeordnetes Tooltip erhalten, das entweder Bestandteil der Feldbeschriftung ist, oder programmatisch verknüpft nach dem Formularelement steht.
Einschränkungen von erlaubten Dateiformaten oder Dateigrößen werden immer sichtbar dargestellt und nie in Tooltips oder title-Attributen.
Inaktive Elemente
Inaktive Elemente mit disabled-Attribut sind visuell deutlich als solche gekennzeichnet, z. B. wenn sie in der Applikationslogik aufgrund fehlender vorhergehender Auswahlen noch nicht aktiv sein können. Sie beinhalten keine Daten.
Readonly-File Inputs sind nicht vorgesehen und per HTML-Spezifikation nicht erlaubt.
Do’s and Dont’s
So:
Maximale Dateigröße anzeigen
Klar kommunizieren, welche Dateiformate erlaubt sind
So nicht:
Dateiformate clientseitig nicht validiert
Design
Typografie
default
Die initiale Darstellung ohne Interaktion durch die Nutzenden. Der input type=file besteht aus einem Standard-Button, der zusätzlich zur Beschriftung ein Icon enthält.
Spalte 1 enthält die Ziffern aus der Abbildung zu den nach Elementen gruppierten Regeln in Spalten 2 bis 4.
In den überwiegenden Fällen haben diese Formularelemente keine inhärenten Breiten in sich, sondern richten sich nach den Spalten des Gestaltungsrasters, in denen sie eingesetzt werden (siehe Kapitel Formularelemente im Grid).
Abstände
Spalte 1 enthält die Ziffern aus der Abbildung zu den nach Elementen gruppierten Regeln in Spalten 2 bis 4.
Upload-Felder, in denen die Validierung fehlende Dateien oder unerlaubte Dateiformate identifiziert hat, erhalten eine deutliche visuelle Hervorhebung und einen den Fehler beschreibenden Text. Der Fehlertext und die farbliche Hervorhebung müssen entfernt werden, sobald die clientseitige Validierung erkennt, dass der Fehler behoben wurde.
Spalte 1 enthält die Ziffern aus der Abbildung zu den nach Elementen gruppierten Regeln in Spalten 2 bis 4.
Der :hover-Zustand wird ausgelöst, sobald sich der Cursor über die Komponente bewegt (exkl. Label & Hilfetext).
Rahmen (oben)
border-top
.0625rem solid #CD1408
Rahmen (unten)
border-bottom
.0625rem solid #CD1408
Rahmen (rechts)
border-right
.0625rem solid #CD1408
Farbüberlagerung (Rahmen)
…
rgba(0, 0, 0, .12)
Schatten (innen)
box-shadow
inset 0 0 0 .0625rem #CD1408
Farbüberlagerung (Schatten)
…
rgba(0, 0, 0, .12)
Siehe Punkt [17]: Alle weiteren Angaben sind identisch zu “Active — Input-Container”
Code
HTML
Die Ausprägungen haben multiple-Attribute, damit das Hochladen mehrerer Dateien möglich ist, sofern dies fachlich gefordert wird und von der Applikationslogik unterstützt wird. Wenn nur eine einzige Datei hochgeladen werden darf oder kann, dann muss dieses Attribut entfernt werden.
Mittels accept-Attribut lassen sich die hochladbaren Dateien clientseitig auf die fachlich festgelegten und erlaubten Formate einschränken. Nur diese Formate sind dann im Dialog des Betriebssystems überhaupt auswählbar. Dies entbindet natürlich nicht von einer weitergehenden serverseitigen Überprüfung, hilft Nutzenden aber bei der Fehlervermeidung.
Pflichtfelder werden mit dem required-Attribut versehen.
WAI-ARIA
Formularelemente müssen zwingend über das aria-describedby-Attribut mit den dazugehörigen Info- und Fehler-Texten verknüpft sein. Bitte beachten Sie, dass Screenreader hier typischerweise die Reihenfolge der IDs berücksichtigen und verknüpfte Texte dementsprechend in der Sortierung der IDs vorlesen, d. h. diese muss der visuellen und logischen Reihenfolge der Oberfläche entsprechen.
JavaScript
Das kennzeichnende Asterisk * am korrespondierenden label eines Pflichtfeldes wird über die Einbindung der Datei requiredInput.js oder der gesamten main.js ermöglicht.
Aus Sicht der Barrierefreiheit, aber auch der allgemeinen Usability müssen zwingend verschiedene Eingabe-Modalitäten bedient werden. Eine alleinige Drag-and-Drop-Funktionalität ist nicht geeignet, um die Anforderungen zu erfüllen. Daher muss bei der Verwendung von Drag and Drop zwingend ein zusätzlicher tastaturbedienbarer Button <input type="file"> angeboten werden.
Inaktive Elemente sind visuell deutlich als solche gekennzeichnet, z. B. wenn sie in der Applikationslogik aufgrund fehlender vorhergehender Auswahlen noch nicht aktiv sein können. Erwartetes Verhalten in gängigen Hilfsmitteln ist, dass diese nicht Bestandteil der Tab-Reihenfolge sind, aber mit den gängigen Vorlese-Methoden erkundet werden können.
readonly
Readonly-File Inputs sind nicht vorgesehen und per HTML-Spezifikation nicht erlaubt.
autofocus
Von der Verwendung dieses Attributs zur automatischen Fokussierung von Formularelementen durch den Browser wird in den meisten Anwendungsfällen abgeraten. Begründete Ausnahmen kann es in Fällen geben, wenn eine Maske mit hoher Wahrscheinlichkeit genau diesen einen Zweck verfolgt, wie dies zum Beispiel bei einer Such-Seite der Fall sein kann.
accesskey
Das accesskey-Attribut darf in öffentlich zugänglichen Anwendungen nicht verwendet werden, da es signifikante Probleme in der Barrierefreiheit hervorruft. Weitere Informationen dazu finden Sie bei MDN accesskey.
tabindex
Das tabindex-Attribut darf nicht mit positiven Werten verwendet werden, sondern nur zum Fokusmanagement oder zur Herstellung der Tastaturbedienbarkeit von nicht auf Standardelementen basierten Widgets (tabindex="0" oder tabindex="-1"). Weitere Informationen dazu finden Sie bei MDN tabindex.
Testhinweise & Akzeptanzkriterien
Tastatur- & Maus-Bedienung:
Formularelemente reagieren grundsätzlich nur auf die Standard-Tasten bzw. -Tastenkombinationen der jeweiligen Betriebssysteme.
Prüfen Sie, ob es eine äquivalente tastaturbedienbare Funktionalität zum Hochladen von Dateien gibt.
Prüfen Sie, ob der Dateiauswahl-Dialog des jeweiligen Betriebssystems verwendet wird.
Prüfen Sie, ob eine ausrechend große Ablagefläche für die Mausbedienung per Drag’n’Drop verfügbar ist.
Darstellung:
Der Schriftgrad kann Browser- oder Systemseitig um bis zu 200 % vergrößert werden, ohne dass Informationen verloren gehen. Bis zu 400 % müssen Inhalte so umbrechen, dass sie ohne horizontales Scrollen verfügbar sind.