Felder vom Typ input type="password" dienen der Eingabe von Passwörtern. Die Komponente besteht aus dem eigentlich input-Feld und einem zugeordneten Button, der das Ein- und Ausblenden des eingegebenen Passworts ermöglicht.
Aufbau
Als Komfortmerkmal enthalten Passwort-Felder einen zusätzlichen Button, mit dem das initial per ••• maskierte Passwort im Klartext angezeigt werden kann; dies erleichtert die Überprüfung der Einhaltung von Passwortregeln. Obwohl es sich technisch um ein seperates Element handelt wird dieser Button optisch als integraler Bestandteil des Passwort-Felds dargestellt. Die Vorgaben zur Einbindung dieses Buttons finden sie als allgemeiner gehaltenes Muster bei input type="text".
Beschriftung
Felder vom Typ input type="password" benötigen zwingend eine visuell sichtbare Beschriftung, in welcher der Zweck beschrieben wird. Dies wird grundsätzlich über ein implizit oder explizit verknüpftes <label> erreicht. aria-label als Label-Ersatz sind nicht zulässig, auch Platzhalter-Texte mit dem HTML-Attribut placeholder als alleinige Beschriftung erfüllen die Anforderungen an die Barrierefreiheit nicht.
Tooltips
Passwort-Felder enthalten grundsätzlich keine Tooltips. Bei der erstmaligen Vergabe eines Passworts zum Beispiel im Verlauf eines Registrierungsprozesses ist die bevorzugte Variante die dauerhaft sichtbare Darstellung der Passwort-Regeln unmittelbar am Passwort-Feld.
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.
Rein darstellende Elemente mit readonly-Attribut sind bereits serverseitig mit Daten befüllt, die nicht mehr editierbar sind, und erhalten eine eigenständige Gestaltung, die ihren Zweck visualisiert. Optional können readonly-Felder zugeordnete weitere Inhalte haben, mit denen die Herkunft der vorbefüllten Daten vermittelt wird, z. B. durch ein ELSTER-Logo.
Do’s and Dont’s
So:
Ausreichende Breite, um auch lange Passwörter zuzulassen
So nicht:
Die Verwendung von Passwort-Managern durch Scripting unterbinden
Design
Das Design eines Passwort-Felds unterscheidet sich nicht von Feldern zur Texteingabe. Die Unterscheidung findet nur im Markup und über den Text des zugeordneten Labels sowie in der initialen Maskierung der Eingaben durch Mittelpunkt-Zeichen ••••• statt.
Die Bemaßungen des Felds und die Vorgaben zur Einbindung eines Buttons zum Ein- und Ausblenden von Passwörtern finden Sie daher als allgemeiner gehaltenes Muster bei input type="text".
Code
HTML
Pflichtfelder werden mit dem required-Attribut versehen. Das kennzeichnende * am korrespondierenden label wird über die Einbindung der Datei requiredInput.js oder der gesamten main.js ermöglicht.
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.
Das zugeordnete Label eines Passwort-Inputs bildet den sogenannten „Accessible Name“ und wird von Screenreadern zusammen mit der Rolle des Elements vorgelesen. Daher muss dieses möglichst prägnant, beschreibend, aber auch kurz betextet sein.
Inputs vom Typ Passwort und ihr Umfeld müssen grundsätzlich so gestaltet sein, dass ein sichtbares Label angezeigt werden kann. Passwort-Regeln sind nicht Bestandteil des Labels.
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
Rein darstellende Elemente sind bereits serverseitig mit Daten befüllt, die nicht mehr editierbar sind. Im Gegensatz zu disabled-Feldern sind sie Bestandteil der Tab-Reihenfolge, somit fokussierbar und erhalten eine eigenständige Gestaltung, die ihren Zweck visualisiert.
minlength / maxlength
Bei Feldern mit Mengenbegrenzung wird das Erreichen des Maximums in verschiedenen Screenreader-/Browser-Kombinationen nur unzureichend akustisch ausgegeben. Dies stellt keinen Mangel im Sinne der BITV-Konformität dar. Bei der Festlegung von Mindest- und Maximallängen von Passwörtern müssen die entsprechenden Vorgaben des BSI zwingend beachtet werden.
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:
Gemeinsam mit dem zugeordneten Label, fokussiert wird immer das Control, nicht das Label. Formularelemente reagieren grundsätzlich nur auf die Standard-Tasten bzw. -Tastenkombinationen der jeweiligen Betriebssysteme.
Sprachbedienung:
Der Sprachbefehl mit dem sichtbaren Label-Text fokussiert das zugeordnete Formularelement.
Zustände:
Default, Fokussiert.
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.
