Ratgeber

Barrierefreie Anmeldung: WCAG 3.3.8 beim Login selbst prüfen

Veröffentlicht am 1. November 2026

Barrierefreie Authentifizierung nach WCAG-Kriterium 3.3.8 heißt: Kein Schritt der Anmeldung darf verlangen, dass Kunden ein Passwort aus dem Kopf wissen, einen Code abtippen oder ein Rätsel lösen, außer es gibt eine Hilfe dafür (etwa Passwortmanager und Einfügen), einen zweiten Anmeldeweg ohne solche Aufgabe, oder die Aufgabe besteht nur darin, Objekte oder selbst hochgeladene Bilder zu erkennen. Für die meisten Shops bedeutet das: Ein normales Login mit E-Mail und Passwort besteht, solange der Browser die Felder ausfüllen darf und Einfügen nicht gesperrt ist; durchfallen lassen ihn vor allem Einfügesperren, aufgeteilte Codefelder und Abfragen wie „das 3. und 5. Zeichen Ihres Passworts“.

3.3.8 ist Stufe AA und kam mit WCAG 2.2 neu hinzu (WCAG 2.2, Erfolgskriterium 3.3.8). Welche WCAG-Version für Ihren Shop zählt und welche Kriterien sonst neu sind, erklärt unser Überblick WCAG 2.2 für Onlineshops. Dieser Artikel nimmt sich nur die Anmeldung vor und führt Sie durch zehn Prüfschritte für Login, „Passwort vergessen“, Registrierung, Gastbestellung und Zwei-Faktor-Codes. Captchas beim Login behandelt ausführlich der Ratgeber Captcha barrierefrei: Alternativen für Kontakt, Login und Checkout; Beschriftungen, Pflichtfelder und Fehlermeldungen stehen in Barrierefreie Formulare im Shop. Eine deutsche Übersetzung der WCAG 2.2 listet das W3C auf seiner Übersetzungsseite nicht; „Barrierefreie Authentifizierung (Minimum)“ ist unsere Übersetzung von „Accessible Authentication (Minimum)“.

Was 3.3.8 genau verlangt

Der Normtext in WCAG 2.2 lautet: „A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following“. Es folgen vier Ausnahmen (Tabelle unten).

Was ein „cognitive function test“ ist, legt die Begriffsbestimmung fest: „A task that requires the user to remember, manipulate, or transcribe information.“ Als Beispiele nennt sie Auswendigwissen (Benutzername, Passwort, Zeichenfolgen, Bilder, Muster), Abtippen, richtige Rechtschreibung, Rechnen und Rätsel. Ausdrücklich keine solche Aufgabe sind Name, E-Mail-Adresse und Telefonnummer, weil sie „personal to the user and consistent across websites“ sind.

Das Understanding-Dokument zu 3.3.8 (Stand laut Seite: 6. September 2026) fasst das Ziel so zusammen: „Don't make people solve, recall, or transcribe something to log in.“ Daraus folgen fünf Punkte, die für Shops wichtig sind:

• Jeder Schritt zählt. Bei mehreren Schritten, etwa Passwort und danach Code, „all steps need to comply“. Es muss einen Weg durch die ganze Anmeldung ohne solche Aufgabe geben.
• Wiederherstellung gehört dazu. Laut Understanding ist es ein wichtiger Teil der Authentifizierung, E-Mail-Adresse und Passwort wiederherstellen oder ändern zu können; auch dafür braucht es einen Weg ohne kognitive Aufgabe.
• Gelegentliche Hürden zählen. Erscheint eine Aufgabe nur nach mehreren Fehlversuchen, gilt das Kriterium trotzdem.
• Codes abtippen ist durchgefallen. „A service that requires manual transcription of a verification code is not compliant.“ Der Code muss sich mindestens einfügen lassen, und der Browser muss das Feld ausfüllen dürfen.
• Nur bestehende Konten. „This success criterion is focused on authentication of existing users. It does not cover creation of a username or initiation of an account.“ Die Registrierung ist also nicht erfasst; das W3C empfiehlt aber dieselben Techniken auch dort.

Die vier Ausnahmen

Eine kognitive Aufgabe ist in einem Anmeldeschritt erlaubt, wenn dieser Schritt eine der Ausnahmen aus dem Normtext bietet. Die Erläuterungen stammen aus dem Understanding 3.3.8, die Shop-Beispiele sind unsere Einordnung.

Drei Grenzen der Ausnahmen, die oft übersehen werden:

• Der Mechanismus kann vom Browser kommen. Laut Begriffsbestimmung darf er im Inhalt selbst stecken oder von Plattform oder Browser bereitgestellt werden. Sie müssen keinen eigenen Passwortmanager bauen, Sie dürfen den des Browsers nur nicht aussperren.
• Sicherheitsfragen sind keine persönlichen Inhalte. Laut Understanding gilt die Ausnahme nicht für Text: „Text-based personal content does not qualify for this exception as it relies on recall“. Die Frage nach dem Namen des ersten Haustiers ist also eine kognitive Aufgabe ohne Ausnahme.
• Ein Audio-Captcha zum Abtippen ist keine Alternative. Laut Understanding „it cannot be used to meet the Alternative exception“.

Abgrenzung: 3.3.8 (AA) und 3.3.9 (AAA)

Laut Understanding 3.3.9 ist 3.3.9 „the same as 3.3.8 Accessible Authentication (Minimum) but without the exceptions for objects and user-provided content“. Für AA zählt 3.3.8. Unsere Einschätzung: Wer kein Bilder-Captcha beim Login einsetzt und die Prüfschritte unten besteht, erfüllt meist auch 3.3.9 ohne Mehraufwand.

Welche Formulare Sie prüfen

Vorbereitung

1. Testkonto anlegen. Eine eigene E-Mail-Adresse, ein langes Passwort, das Sie nicht auswendig kennen. Genau so geht es vielen Ihrer Kunden.
2. Passwort in die Zwischenablage legen. Schreiben Sie es in eine Textdatei und kopieren Sie es von dort. Das simuliert einen Passwortmanager, der nicht im Browser steckt.
3. Browser-Passwortspeicher nutzen. Lassen Sie Ihren Browser das Passwort beim ersten Login speichern, wenn er es anbietet.
4. Zwei Geräte bereithalten. Rechner und Smartphone, damit Sie Desktop- und Handyansicht prüfen.
5. Notizblatt. Je Prüfschritt: besteht, fällt durch, Stelle im Shop.

Prüfschritt 1: Einfügen ins Passwortfeld

So testen Sie: Abmelden, Login-Seite öffnen, E-Mail-Adresse einfügen (Strg + V, Mac: Cmd + V), dann das Passwort einfügen. Wiederholen Sie es mit Rechtsklick und „Einfügen“ und auf dem Smartphone mit langem Tippen.

Besteht: Beide Felder nehmen den eingefügten Text vollständig an, die Anmeldung klappt.

Fällt durch: Das Feld bleibt leer, eine Meldung wie „Bitte Passwort von Hand eingeben“ erscheint, oder es werden nur einige Zeichen übernommen. Laut Understanding 3.3.8 fällt eine Seite durch, wenn Nutzer am Kopieren und Einfügen gehindert werden und es keinen anderen Anmeldeweg gibt; Abbildung 2 dort zeigt genau die Meldung, das Passwort von Hand einzugeben. Wird das Passwort nur teilweise übernommen, beschreibt das W3C das als Fehler F109: Das Feld muss das ganze Passwort in der Form annehmen, in der es angelegt wurde.

Ebenso durch fällt eine Abfrage einzelner Zeichen („Geben Sie das 2., 6. und letzte Zeichen Ihres Passworts ein“) oder ein Passwort, das Zeichen für Zeichen aus Auswahllisten gewählt wird. Beides nennt F109 als Fehler, sofern es keinen anderen Anmeldeweg gibt. Ersetzen Sie solche Abfragen durch ein einziges Passwortfeld.

So beheben Sie: Lassen Sie im Theme oder Plugin nach Skripten suchen, die das Einfügen verhindern. Typische Suchbegriffe im Code: onpaste, paste, oncopy, preventDefault in Verbindung mit Passwort- oder Codefeldern. Diese Stellen werden entfernt. Begrenzt ein maxlength das Feld kürzer als erlaubte Passwörter, schneidet der Browser beim Einfügen ab; dann das maxlength entfernen oder an die Passwortregel angleichen.

Prüfschritt 2: autocomplete-Attribute und Feldnamen

Browser und Passwortmanager können Felder laut Understanding in der Regel zuverlässig erkennen, wenn das Formular 1.3.5 Eingabezweck bestimmen und 4.1.2 Name, Rolle, Wert erfüllt. Die Technik H100 zeigt das Muster: Beschriftung per label, E-Mail-Feld mit autocomplete="email", Passwortfeld mit autocomplete="current-password".

So testen Sie: Öffnen Sie auf der Login-Seite die Konsole der Entwicklertools (F12, Reiter Console), fügen Sie diese Zeile ein und drücken Sie Enter. Chrome verlangt beim ersten Einfügen laut Google, dass Sie „allow pasting“ eintippen; danach erscheint die Warnung nicht mehr.

Die Zeile listet jedes Eingabefeld außer type=hidden mit Typ, Name, autocomplete-Wert, ob ein label verbunden ist und ob im HTML ein onpaste steht. Einfügesperren, die per Skript nachträglich angehängt werden, findet sie nicht; dafür ist Prüfschritt 1 da.

Besteht: Diese Werte stehen an den passenden Feldern. Die Bedeutungen stammen aus der HTML-Spezifikation und MDN zu autocomplete.

Fällt durch: Fehlt an E-Mail-, Benutzernamen- oder Passwortfeld der passende Wert, verstößt das gegen 1.3.5 Eingabezweck bestimmen, denn „email“, „username“, „current-password“ und „new-password“ stehen in der Liste der Eingabezwecke. Nach unserer Lesart ist das allein noch kein Verstoß gegen 3.3.8, solange der Passwortmanager trotzdem ausfüllt (Prüfschritt 3); beheben sollten Sie es trotzdem. autocomplete="off" am Passwortfeld ist laut MDN in den meisten modernen Browsern wirkungslos gegen Passwortmanager, aber nach unserer Einschätzung ein Zeichen, dass jemand das Ausfüllen verhindern wollte. Prüfen Sie dann besonders gründlich.

So beheben Sie: Das Login-Formular sieht im HTML so aus:

Prüfschritt 3: Passwortmanager füllt aus

So testen Sie: Abmelden und die Login-Seite neu laden. Bietet der Browser das gespeicherte Passwort an oder füllt es selbst ein? Wiederholen Sie das auf dem Smartphone und, wenn Sie einen nutzen, mit einem Passwortmanager als Browsererweiterung.

Besteht: E-Mail und Passwort werden angeboten oder eingetragen, ein Klick auf „Anmelden“ genügt.

Fällt durch: Laut Understanding 3.3.8 fällt die Seite durch, wenn Browser und Passwortmanager „actively blocked from filling in the fields“ sind, etwa durch ein Skript, und es keine Alternative gibt. Typische Anzeichen: Das Feld wird nach dem Ausfüllen wieder geleert, oder die Anmeldung meldet trotz richtig ausgefülltem Passwort einen Fehler, bis man ein Zeichen von Hand tippt.

So beheben Sie: Skripte entfernen, die Felder leeren. E-Mail und Passwort auf derselben Seite in einem form-Element anbieten. Fragt Ihr Shop E-Mail und Passwort auf zwei Seiten nacheinander ab, prüfen Sie diesen Schritt auf beiden Seiten.

Prüfschritt 4: E-Mail statt Benutzername

So testen Sie: Verlangt der Login einen Benutzernamen, den der Kunde selbst erfunden hat, oder eine Kundennummer?

Besteht: Anmeldung mit E-Mail-Adresse. Die Begriffsbestimmung nimmt E-Mail, Name und Telefonnummer ausdrücklich aus.

Fällt durch: Ein Benutzername oder eine Kundennummer muss auswendig gewusst werden; „remembering a username“ ist laut Begriffsbestimmung eine kognitive Aufgabe. Nach unserer Lesart besteht der Schritt trotzdem, wenn Passwortmanager und Einfügen auch für dieses Feld funktionieren (Prüfschritte 1 bis 3), weil dann die Ausnahme Mechanismus greift.

So beheben Sie: Anmeldung mit E-Mail-Adresse erlauben; das Feld bekommt autocomplete="username" oder autocomplete="email".

Prüfschritt 5: Passwort anzeigen

So testen Sie: Gibt es neben dem Passwortfeld einen Knopf, der das Passwort im Klartext zeigt? Lässt er sich mit der Tastatur (Tab, dann Enter oder Leertaste) bedienen, und sagt er, was er tut?

Besteht oder nicht: 3.3.8 verlangt den Knopf nicht. Das Understanding empfiehlt ihn aber: „Providing a feature to optionally show a password can improve the chance of success for some people with cognitive disabilities or those who have difficulties with accurately typing.“ Unsere Einschätzung: Bei Registrierung und „Passwort ändern“, wo Kunden tippen müssen, lohnt er sich am meisten.

So beheben Sie: Ein echter Button mit Text, der seinen Zustand nennt:

type="button" verhindert, dass der Klick das Formular abschickt. Ist der Knopf nur ein Augen-Symbol, braucht er einen zugänglichen Namen; wie das geht, steht im Ratgeber zu barrierefreien Formularen.

Prüfschritt 6: Passwort vergessen

So testen Sie: Auf „Passwort vergessen“ klicken und den Ablauf bis zum neuen Passwort durchgehen.

Besteht: Sie geben Ihre E-Mail-Adresse ein, bekommen einen Link, öffnen ihn und vergeben ein neues Passwort in einem Feld mit autocomplete="new-password", in das Einfügen funktioniert. Ein Anmeldelink per E-Mail ist die W3C-Technik G218; ihr Testablauf: E-Mail kommt an, der Link öffnet die Website, das Konto ist angemeldet.

Fällt durch: Eine Sicherheitsfrage („Name Ihres ersten Haustiers“) ist der einzige Weg, ein Rechen-Captcha steht vor dem Absenden, oder der Code aus der E-Mail lässt sich nur abtippen. Zu Sicherheitsfragen siehe die Grenzen der Ausnahmen oben.

So beheben Sie: Wiederherstellung per E-Mail-Link als Standard. Ein Code statt Link muss sich einfügen lassen (Prüfschritt 7). Captchas an dieser Stelle ersetzen Sie mit den Wegen aus dem Captcha-Ratgeber.

Prüfschritt 7: Codes per SMS, E-Mail oder App

Betrifft Zwei-Faktor-Anmeldung und Shops, die statt Passwort einen Anmeldecode per E-Mail schicken.

So testen Sie:

1. Code anfordern, in der E-Mail oder SMS markieren und kopieren.
2. Ins Codefeld klicken und einfügen.
3. Auf dem Smartphone prüfen, ob die Tastatur den Code aus SMS oder E-Mail als Vorschlag anbietet.
4. Prüfen, ob ein Code-Formular mit sechs einzelnen Kästchen den eingefügten Code auf alle Kästchen verteilt.

Für Codes, die auf einem zweiten Gerät ankommen, sagt das Understanding: Prüferinnen und Prüfer gehen davon aus, dass der Code bereits in der Zwischenablage liegt, und prüfen nur, ob das Feld das Einfügen erlaubt. Wie der Code vom Handy auf den Rechner kommt, ist nicht Teil des Kriteriums.

Besteht: Der ganze Code lässt sich in einem Zug einfügen. Bei einzelnen Kästchen nennt F109 eine Ausnahme: Es genügt, wenn der ganze Code ins erste Feld eingefügt werden kann „and the remaining inputs are populated automatically“.

Fällt durch: Nur die erste Ziffer kommt an (Abbildung 3 im Understanding), Einfügen ist gesperrt, oder der Code muss in anderer Form eingegeben werden, als er geschickt wurde.

So beheben Sie: Ein einziges Feld statt Kästchen:

inputmode="numeric" zeigt laut MDN auf dem Handy eine Zifferntastatur, type="text" statt type="number" ist unsere Empfehlung, weil ein Code keine Zahl zum Rechnen ist. Wer mehrere Wege anbietet, macht es leichter: Laut Understanding sind Hardware-Schlüssel, Bestätigung per App und die Anmeldung über das Betriebssystem (Windows Hello, Touch ID, Face ID) gar keine kognitive Aufgabe.

Prüfschritt 8: Registrierung und Passwort ändern

So testen Sie: Ein neues Konto anlegen und im Kundenkonto das Passwort und die E-Mail-Adresse ändern. Einfügen in alle Passwortfelder, auch in „Passwort wiederholen“, und prüfen, ob der Browser ein sicheres Passwort vorschlägt.

Besteht: Bei „Passwort ändern“ und „E-Mail ändern“ gelten die Prüfschritte 1 bis 3, weil das Understanding das Ändern zur Authentifizierung zählt. Bei der Registrierung verlangt 3.3.8 nichts; das W3C schreibt aber, dass Einfügen und Verzicht auf Abtippen „can also reduce the cognitive burden in account creation“.

Fällt durch: Einfügesperre im Feld „Passwort ändern“ oder bei der Abfrage des alten Passworts. Bei der Registrierung ist eine Sperre nach unserer Lesart kein Verstoß gegen 3.3.8, aber eine unnötige Hürde.

So beheben Sie: Neue Passwortfelder mit autocomplete="new-password", das alte mit current-password, keine Einfügesperre. new-password nutzt der Browser laut MDN auch, um beim Erstellen eines sicheren Passworts zu helfen.

Prüfschritt 9: Gastbestellung und Bestellstatus

So testen Sie: Gibt es eine Bestellung ohne Konto? Schickt der Shop Wiederkehrende zwingend in den Login, oder verlangt er einen Code zur Bestätigung der E-Mail-Adresse? Und wie fragen Kunden ohne Konto den Bestellstatus ab? Fügen Sie Code, Bestellnummer und E-Mail-Adresse jeweils per Einfügen ein.

Besteht: Die Gastbestellung meldet niemanden bei einem bestehenden Konto an; nach unserer Lesart gilt 3.3.8 dort nicht.

Fällt durch: Nach 3.3.8 nur der Pflicht-Login selbst (nach unserer Lesart). Schickt der Shop Wiederkehrende zwingend in den Login, prüfen Sie diesen Login mit den Prüfschritten 1 bis 7. Ein Code zur Bestätigung der E-Mail-Adresse, der sich nicht einfügen lässt, ist nach unserer Einschätzung eine unnötige Hürde; lassen Sie ihn wie in Prüfschritt 7 einfügbar machen.

So beheben Sie: Gastbestellung ohne Pflicht-Login anbieten; Bestellnummer und Codes in Feldern, in die Einfügen funktioniert. Den restlichen Kaufweg prüfen Sie mit Barrierefreier Checkout.

Prüfschritt 10: Ein zweiter Weg ohne Passwort

Ein Anmeldeweg, der gar keine kognitive Aufgabe enthält, erfüllt die Ausnahme Alternative und fängt alles ab, was am Passwort-Login hakt.

Für Passkeys beschreibt MDN die Variante, bei der das Benutzerfeld autocomplete="username webauthn" bekommt und der Browser vorhandene Passkeys beim Antippen des Feldes anbietet; Kunden ohne Passkey melden sich laut MDN wie gewohnt mit Passwort oder Passwortmanager an. Das ist Arbeit für Entwickler oder ein fertiges Plugin, kein Eintrag im Theme.

Checkliste zum Abhaken

Besteht Ihr Shop 1 bis 3, 6 bis 8 und 11, erfüllt die Anmeldung nach unserer Lesart 3.3.8 auch ohne zweiten Weg, weil dann überall die Ausnahme Mechanismus greift. Den Login eines Zahlungsanbieters im Kaufprozess prüfen Sie zusätzlich mit denselben Schritten.

Hinweise zu Shopify, WooCommerce und Shopware

• Shopify: Laut Shopify-Hilfe melden sich Kunden in den neuen Kundenkonten ohne Passwort an: „They enter their email address and receive a one-time 6-digit verification code.“ Zusätzlich nennt Shopify die Anmeldung mit Google und Facebook sowie mit Shop-Zugangsdaten und Passkeys, wenn Shop Pay aktiv ist (Shopify Help Center: New customer accounts). Die alten Kundenkonten mit Passwort nennt Shopify „deprecated“. Das Upgrade ist laut Hilfe der letzte von neun Schritten unter Settings > Customer accounts mit Upgrade im Banner oben; vorher sollen Sie Ihre Anpassungen prüfen, die Konfiguration duplizieren und die neuen Kundenkonten in der Vorschau testen, und eigene Login-Formulare im Theme müssen eventuell entfernt werden (Shopify Help Center: Upgrading to customer accounts). Ob sich der Code in Ihrem Shop einfügen lässt, sagt die Dokumentation nicht; prüfen Sie Schritt 7 selbst. Mehr zum Theme in Shopify barrierefrei machen.
• WooCommerce und Shopware: Zu Einfügen, autocomplete-Werten oder Passkeys im Login haben wir in der Herstellerdokumentation keine belastbare Aussage gefunden. Login und „Passwort vergessen“ kommen dort meist aus dem Theme; gehen Sie die Prüfschritte 1 bis 8 mit Ihrem Theme durch und lassen Sie Fehler im Theme beheben.

Rechtliche Einordnung in einem Absatz

Für Onlineshops verlangt § 19 Nr. 3 BFSGV, dass „Identifizierungsmethoden, Authentifizierungsmethoden, elektronische Signaturen und Zahlungsdienste, wenn diese bereitgestellt werden, wahrnehmbar, bedienbar, verständlich und robust gestaltet werden“; Nr. 2 sagt dasselbe für Identifizierungs-, Authentifizierungs-, Sicherheits- und Zahlungsfunktionen, die im Rahmen einer Dienstleistung bereitgestellt werden. Die Verordnung nennt 3.3.8 nicht selbst. Ob und über welche Norm WCAG 2.2 für Sie gilt, erklärt der Überblick WCAG 2.2 für Onlineshops. Unsere Einschätzung: Die Prüfschritte oben sind der konkreteste verfügbare Maßstab dafür, ob Ihre Anmeldung „bedienbar“ und „verständlich“ ist.

Dieser Ratgeber ist keine Rechtsberatung. Im Zweifel klären Sie Ihren Fall mit der Bundesfachstelle Barrierefreiheit oder einer Anwältin oder einem Anwalt.

Ihr nächster Schritt

Ein kostenloser Scan Ihres Shops gibt Ihnen einen schnellen Überblick. Er prüft Startseite, Produktseite und Warenkorb und zeigt, was zuerst behoben werden sollte. Ein automatischer Scan findet nur einen Teil der Barrieren; Login, Codes und „Passwort vergessen“ prüfen Sie mit den Schritten oben selbst.

Stand: 01.11.2026. Quellen gelesen am 01.11.2026.