Login- und Registrierungsseite gestalten

Kurz gesagt

Login- und Registrierungsscreens sind kurze Formulare, aber sie sind die Tür zum Produkt. Wer an der Tür hängen bleibt, sieht nie, was drinnen ist.

Bei diesem Muster prüfe ich zuerst, ob die Tür überhaupt nötig ist. Dann gehe ich zu den Passwortregeln und zur Fehlermeldung. Zum Schluss prüfe ich, ob der Browser die Felder ausfüllen kann. Allgemeine Regeln zu Feldanordnung und Validierungszeitpunkt stehen auf der Seite zum Formulardesign.

Schlechter und guter Login-Screen

Unten sehen Sie zwei Screens für dasselbe Konto. Links das schlechte Beispiel, das ich in Audits oft sehe, rechts ein Screen, der den Regeln dieser Seite folgt. Auf schmalen Bildschirmen stehen beide untereinander.

Schlechter und guter Login-Screen

Testkonto: [email protected], Passwort blaue-tuer-42. Kopieren Sie das Passwort und fügen Sie es in beide Screens ein.

Schlecht

Gesperrtes Passwort, vage Fehlermeldung

Beim Einfügen: Das Passwortfeld blockiert das Einfügen. Es gibt keinen Anzeigen-Button, autocomplete ist aus.

Beim Klick auf Anmelden: Oben steht „Ungültige Eingabe“ und beide Felder werden geleert. Einen Link „Passwort vergessen“ gibt es nicht.

Gut

Sichtbares Label, Fehler am Feld

E-Mail

PasswortPasswort vergessen?

Beim Einfügen: Das Passwort landet im Feld. Mit „Passwort anzeigen“ prüfen Sie Ihre Eingabe.

Beim Klick auf Anmelden: Neben einem leeren oder falsch formatierten Feld steht, was Sie tun müssen. Passen die Daten nicht, wird nur das Passwortfeld geleert.

Passwort vergessen: Im echten Produkt öffnet sich eine Seite mit nur einem Feld für die E-Mail. Danach steht dort „Wenn diese Adresse registriert ist, haben wir einen Link zum Zurücksetzen gesendet“.

Beide Screens haben dieselben zwei Felder. Schicken Sie beide zuerst leer ab. Fügen Sie dann das Passwort ein und probieren Sie ein falsches Passwort. Die Demo sendet keine Daten.

Den Unterschied sehen Sie am schnellsten, wenn Sie das Passwort einfügen. Der schlechte Screen sperrt den Passwortmanager aus. Beim guten funktioniert Kopieren und Einfügen, und der Anzeigen-Button hilft, Tippfehler zu finden.

Login und Registrierung sind zwei Türen

Wer sich anmelden will, sucht etwas anderes als jemand, der ein Konto eröffnet. Der eine will zwei Felder, der andere will wissen, wofür er sich registriert. Deshalb baue ich die beiden Abläufe auf getrennten Screens oder in zwei klar getrennten Tabs.

Die Überschrift jedes Screens sollte sagen, was er tut: „Anmelden“ oder „Konto erstellen“. Darunter steht ein kurzer Weg zur anderen Tür: „Noch kein Konto? Konto erstellen.“

Warum diese Trennung wichtig ist, zeigt Jared Spools Artikel von 2009. Bei einem Onlineshop hatten 45 % der Kunden mehrere Einträge im System, manche sogar bis zu 10. Wiederkehrende Kunden wussten oft nicht mehr, mit welcher E-Mail oder welchem Passwort sie sich registriert hatten.

Die Gastoption

Wenn der Nutzer seine Aufgabe ohne Konto erledigen kann, zwingen Sie ihn nicht zur Registrierung. Dazu gehören Bezahlung, Terminbuchung oder ein einmaliger Antrag.

In dem Fall, den Spool beschreibt, ersetzten die Designer den Registrieren-Button durch einen Weiter-Button. Daneben schrieben sie, dass man für den Einkauf kein Konto braucht. Die Zahl der kaufenden Kunden stieg um 45 %. Der Mehrumsatz lag im ersten Monat bei 15 Millionen Dollar, im ersten Jahr bei 300 Millionen Dollar. Die ganze Geschichte steht auf der Seite Der 300-Millionen-Dollar-Button.

In der Liste des Baymard Institute zum Kaufabbruch nennen 18 % der Abbrecher (ohne die Antwort „nur gestöbert“) den Grund „Die Seite wollte, dass ich ein Konto erstelle“. Raluca Budiu von NN/g empfiehlt 2014 ebenfalls einen Gast-Checkout. Das Kontoangebot sollte nach ihr erst nach dem Kauf kommen.

Bei persönlichen Produkten wie Onlinebanking oder E-Mail ist eine Login-Wand unvermeidlich. Bei anderen Produkten versuche ich, die Tür erst aufzustellen, nachdem das Produkt seinen Wert gezeigt hat. Wo der Gastablauf hingehört, beschreibe ich im Muster Checkout.

Passwortregeln

Für Passwortregeln schaue ich in das Dokument SP 800-63B-4 des US-Standardinstituts NIST. Die endgültige Fassung erschien im Juli 2025. Diese Punkte betreffen den Registrierungsscreen direkt:

• Ein Passwort, das allein verwendet wird, muss mindestens 15 Zeichen lang sein. Ist es nur Teil einer Zwei-Faktor-Anmeldung, liegt die Untergrenze bei 8 Zeichen.
• Passwörter mit mindestens 64 Zeichen müssen erlaubt sein. Das System prüft das ganze Passwort, ohne es abzuschneiden.
• Kompositionsregeln wie „Großbuchstabe, Ziffer und Sonderzeichen“ soll es nicht geben.
• Nutzer sollen nicht in festen Abständen zum Passwortwechsel gezwungen werden. Ein Wechsel wird verlangt, wenn es Hinweise gibt, dass das Konto kompromittiert ist.
• Ein neues Passwort wird mit einer Liste häufiger und geleakter Passwörter verglichen. Auch der Name des Dienstes und der Benutzername gehören auf diese Liste.
• Passwortmanager und automatisches Ausfüllen sollen erlaubt sein. Einfügen zu erlauben wird empfohlen.
• Passworthinweise werden nicht gespeichert, Sicherheitsfragen werden nicht gestellt.

Nennen Sie die Regel von Anfang an. Katie Sherwin von NN/g verlangt 2015, dass die Anforderungen sichtbar sind, während das Passwort erstellt wird. Sie rät auch davon ab, die Anforderung ins Label zu quetschen.

Ein Feld „Passwort wiederholen“ ist meist unnötig. Das GOV.UK Design System rät davon ab, weil der Anzeigen-Button reicht, damit der Nutzer seine Eingabe prüfen kann.

Passwort anzeigen

Ein verdecktes Passwortfeld versteckt Tippfehler. Der Nutzer merkt seinen Fehler erst an der Fehlermeldung. Auch NIST empfiehlt die Option, das Passwort beim Tippen anzuzeigen.

Ob das Passwort von Anfang an sichtbar sein soll, sehen die Quellen unterschiedlich. GOV.UK verbirgt es standardmäßig, weil der Nutzer an einem öffentlichen Ort sein kann. Sherwin empfiehlt dagegen, das Passwort auf Smartphone und Tablet von Anfang an zu zeigen, mit einem Verbergen-Button daneben.

Ich starte verdeckt und setze den Button direkt neben das Feld. Der Zustand des Buttons muss auch beim Screenreader ankommen. Im Beispiel oben habe ich das mit aria-pressed gelöst.

Passwort vergessen

Dieser Link steht direkt neben dem Passwortfeld und ist immer sichtbar. Ein Link, der erst nach einem Fehler erscheint, kommt für den, der ihn braucht, zu spät.

Die Website aus Spools Fall bekam etwa 160.000 Passwortanfragen am Tag. 75 % derer, die ein Passwort anforderten, versuchten den Kauf nie wieder. Ein vergessenes Passwort kostet also direkt Umsatz.

Der Zurücksetzen-Screen fragt nach einem einzigen Feld: der E-Mail. Die Meldung nach dem Absenden sollte nicht verraten, ob die Adresse registriert ist. Der Authentifizierungsleitfaden von OWASP nennt dafür als Beispiel sinngemäß: „Wenn diese E-Mail-Adresse in unserer Datenbank ist, senden wir eine E-Mail zum Zurücksetzen des Passworts.“ Die Übersetzung ist von mir.

Social Login

Anmelden mit Google oder Apple eröffnet ein Konto, ohne ein Passwort zu tippen. Ich biete diese Buttons neben dem E-Mail-Login an, nicht statt ihm. Nicht jeder hat eines dieser Konten, und wer eines hat, will es vielleicht nicht verknüpfen.

Das Problem, das ich in Audits sehe: Der Nutzer weiß nicht mehr, auf welchem Weg er sich zuletzt angemeldet hat. Deshalb halte ich die Reihenfolge der Buttons auf jedem Screen gleich. Wenn möglich, markiere ich den zuletzt genutzten Weg.

Fragen Sie Nutzer, die über Social Login kommen, nicht noch einmal nach ihren Daten. Zeigen Sie Name und E-Mail aus dem Konto an, und der Nutzer bestätigt nur.

Wann die E-Mail-Bestätigung kommen sollte

Ich verlange die Bestätigung nicht an der Tür, sondern dort, wo sie nötig ist. Nach der Registrierung kann der Nutzer das Produkt sofort verwenden. Die Bestätigung kommt vor einem Schritt wie Bezahlung oder Teilen oder in den ersten Tagen.

Eine Wand „Bestätigen Sie zuerst Ihre E-Mail“ direkt nach der Registrierung schickt den Nutzer aus der App ins Postfach. Wer von dort nicht zurückkommt, ist verloren.

Ist die Bestätigung ein Link per E-Mail, gehört das zu den ausreichenden Techniken, die das W3C für 3.3.8 nennt. Bei der Bestätigung per Code muss das Codefeld Einfügen erlauben. Ergänzen Sie am Feld autocomplete="one-time-code".

Fehlermeldungen beim Login

Auf dem Login-Screen gibt es zwei Arten von Fehlern, und beide werden unterschiedlich formuliert. Ein Formatfehler erscheint am Feld und sagt, was falsch ist: „Geben Sie die E-Mail-Adresse im Format [email protected] ein.“

Passen die Daten nicht zusammen, sollte die Meldung nicht sagen, welches Feld falsch ist. GOV.UK schreibt, dass dieses Detail Betrügern helfen kann, in Konten einzudringen. Auch OWASP verlangt eine allgemeine Antwort, die nicht verrät, ob das Konto existiert.

GOV.UK verlangt, das Passwortfeld nach einem fehlgeschlagenen Login zu leeren. Das E-Mail-Feld lasse ich stehen. Ans Ende der Meldung setze ich einen Ausweg: „Versuchen Sie es erneut oder setzen Sie Ihr Passwort zurück.“ Die Regeln zum Formulieren solcher Meldungen habe ich im Muster Fehlermeldungen gesammelt.

Autocomplete-Attribute

autocomplete sagt dem Browser und dem Passwortmanager, was ein Feld ist. Stimmt der Wert, füllt der Passwortmanager die Felder selbst aus. Die Bedeutungen der Werte nach MDN:

Feld	Wert	Bedeutung
Login: E-Mail oder Benutzername	username	Laut MDN der Benutzer- oder Kontoname.
Login: Passwort	current-password	Das aktuelle Passwort des Nutzers.
Registrierung und Passwortänderung: neues Passwort	new-password	Der Browser kann damit vermeiden, das alte Passwort versehentlich einzusetzen, und ein starkes Passwort vorschlagen.
Registrierung: E-Mail	email	Die E-Mail-Adresse.
Bestätigungscode	one-time-code	Einmalcode, der beim Login als zusätzlicher Schritt verlangt wird. Kommt meist per SMS, E-Mail oder Authenticator-App.

Beim Login setze ich am E-Mail-Feld username, weil dieses Feld der Name des Kontos ist. MDN merkt außerdem an, dass Browser autocomplete="off" bei Login-Feldern ignorieren können. Ausschalten bewirkt meiner Meinung nach nur eins: Wer einen Passwortmanager nutzt, hat es schwerer.

Barrierefreie Authentifizierung: WCAG 3.3.8

Das Kriterium 3.3.8 Barrierefreie Authentifizierung (Minimum) in WCAG 2.2 hat die Stufe AA. In keinem Schritt der Authentifizierung darf ein kognitiver Funktionstest Pflicht sein. Ein Passwort im Kopf behalten oder ein Rätsel lösen sind Beispiele dafür.

Das Kriterium kennt vier Ausnahmen: einen anderen Weg ohne kognitiven Test, einen Mechanismus, der beim Test hilft, das Erkennen von Objekten und das Erkennen von Inhalten, die der Nutzer selbst bereitgestellt hat. Als Beispiele für einen solchen Mechanismus nennt das W3C den Passwortmanager und Kopieren und Einfügen.

Die Erläuterungsseite des W3C schreibt die Folgen klar auf:

• Ein Login, das Passwortmanager oder Einfügen blockiert, besteht das Kriterium nicht, wenn es keinen anderen Weg gibt.
• Ein Dienst, der den Bestätigungscode von Hand abtippen lässt, ist nicht konform. Das Codefeld muss Einfügen erlauben.
• Auch eine Rätsel-Prüfung braucht einen Weg ohne kognitiven Test. Eine Audio-Alternative, bei der man Gehörtes abtippt, ersetzt diesen Weg nicht.

Das Kriterium und die übrigen Neuerungen von WCAG 2.2 erkläre ich im WCAG-Ratgeber.

Meine Notiz

Der Fehler, den ich in Audits am Login-Screen am häufigsten sehe, ist die Einfügesperre. Das Team hält sie für eine Sicherheitsmaßnahme. Dabei empfiehlt NIST, Einfügen zu erlauben, und die WCAG werten die Sperre als Barrierefreiheitsfehler, wenn es keinen anderen Login-Weg gibt.

Auf Platz zwei stehen Meldungen wie „Ungültige Eingabe“. Eine allgemeine Meldung ist für die Sicherheit richtig, darf den Nutzer aber nicht ratlos lassen. Setzen Sie den Link zum Zurücksetzen in die Meldung, dann haben Sie beides.

Beim Registrierungsscreen zähle ich die abgefragten Felder. Vorname, Nachname, Telefon und Geburtsdatum braucht man am ersten Tag meist nicht. Ich starte nur mit E-Mail und Passwort und frage den Rest, wenn er gebraucht wird.

Checkliste

Bevor ein Login- und Registrierungsablauf live geht, gehe ich diese Liste durch. Wenn ich Ihre eigenen Screens anhand dieser Liste prüfen soll: Der UX Audit deckt alle Punkte ab.

• Kann der Nutzer seine Aufgabe ohne Konto erledigen, gibt es eine Gastoption.
• Login und Registrierung sind getrennt, die Überschriften sagen, was sie tun.
• Die Passwortregel steht von Anfang an auf dem Registrierungsscreen, ohne Kompositionsregel.
• Einfügen im Passwortfeld funktioniert, der Passwortmanager füllt das Feld aus.
• Es gibt einen Button „Passwort anzeigen“, sein Zustand wird an den Screenreader übermittelt.
• Der Link „Passwort vergessen?“ steht neben dem Passwortfeld und ist immer sichtbar.
• Formatfehler stehen am Feld, der Login-Fehler ist allgemein, zeigt aber einen Ausweg.
• E-Mail-, Passwort- und Codefelder haben den richtigen autocomplete-Wert.
• Der Bestätigungscode lässt sich einfügen.