Anmelden ist der Moment, in dem eine Website entscheidet, wer hereinkommt und wer draußen bleibt. Verlangt dieser Schritt ein Rätsel - verzerrte Zeichen abtippen, ein komplexes Passwort aus dem Gedächtnis eingeben oder einen Code fehlerlos übertragen -, dann werden ausgerechnet die Menschen ausgesperrt, die es am wenigsten verkraften. Mit WCAG 2.2 hat das W3C darum zwei neue Erfolgskriterien eingeführt: SC 3.3.8 Accessible Authentication (Minimum, Level AA) und SC 3.3.9 (Enhanced, Level AAA). Beide untersagen kognitive Funktionstests bei der Anmeldung, sofern keine barrierearme Alternative existiert (W3C WAI, 2023). Wie dringend das ist, zeigt der WebAIM Million Report 2025: 94,8 Prozent (WebAIM Million, 2025) aller untersuchten Startseiten wiesen mindestens einen automatisch erkennbaren WCAG-Verstoß auf. Dieser Leitfaden erklärt, was SC 3.3.8 konkret fordert und wie sich konforme Login-, Registrierungs- und CAPTCHA-Flows umsetzen lassen, ohne Nutzer an der Anmeldung zu verlieren.
Was SC 3.3.8 und 3.3.9 wirklich fordern
Im Zentrum steht der Begriff des kognitiven Funktionstests. Das W3C beschreibt ihn als Aufgabe, bei der Nutzer sich etwas merken, es verarbeiten oder abtippen müssen - etwa ein Passwort oder ein Muster aus dem Gedächtnis abrufen, verzerrte Zeichen entziffern oder eine Rechen- beziehungsweise Rätselaufgabe lösen (W3C WAI, 2023). Genau solche Aufgaben sind für Menschen mit eingeschränktem Gedächtnis, mit Legasthenie, Dyskalkulie oder verminderter Verarbeitungsgeschwindigkeit besonders schwer. SC 3.3.8 auf Level AA fordert deshalb, dass kein Schritt der Anmeldung einen solchen Test erzwingt, solange keine der zulässigen Ausnahmen greift.
Das Kriterium benennt vier Wege, um konform zu bleiben (W3C WAI, 2023). Erstens eine Alternative: eine zweite Anmeldemethode, die ohne kognitiven Test auskommt. Zweitens ein Mechanismus, der beim Bestehen hilft - etwa die ungehinderte Nutzung eines Passwort-Managers oder das Einfügen eines Codes aus der Zwischenablage. Drittens ein Test, der ausschließlich Objekterkennung verlangt, also das Benennen alltäglicher Dinge statt das Entziffern von Text. Und viertens ein Test, bei dem Nutzer selbst bereitgestellte Inhalte wiedererkennen. Sobald eine dieser Ausnahmen erfüllt ist, gilt der Anmeldevorgang im Sinne des Kriteriums als barrierefrei.
Unzulässig und zulässig auf einen Blick
Für die rechtliche Einordnung ist die Konformitätsstufe entscheidend. SC 3.3.8 liegt auf Level AA und damit auf der Stufe, die das Barrierefreiheitsstärkungsgesetz (BFSG) für viele digitale Angebote seit Juni 2025 verbindlich macht (BFSG, 2025). Die harmonisierte europäische Norm EN 301 549 verweist in ihrer aktuell gültigen Fassung 3.2.1 noch auf WCAG 2.1 und enthält SC 3.3.8 formal noch nicht (EN 301 549, 2021). Mit der für 2026 erwarteten Version 4.1.1 zieht die Norm auf WCAG 2.2 nach - und damit wird barrierefreie Authentifizierung auch im formalen Prüfmaßstab verankert. Wer heute nach WCAG 2.2 baut, ist darauf vorbereitet; die Zusammenhänge klärt der Beitrag zur EN 301 549 als Norm hinter dem BFSG.
Passwort-Manager nicht ausbremsen: autocomplete und Einfügen
Der wirksamste und zugleich einfachste Beitrag zu SC 3.3.8 kostet fast nichts: Login-Felder dürfen die Nutzung von Passwort-Managern nicht behindern. Das W3C nennt Passwort-Manager sowie das Kopieren und Einfügen ausdrücklich als Mechanismen, die die Merk- und Tippbelastung senken (W3C WAI, 2023). Technisch heißt das, das Feld für den Benutzernamen erhält autocomplete="username", das Passwortfeld autocomplete="current-password" und ein Registrierungsformular autocomplete="new-password". So können Browser und Passwort-Manager Zugangsdaten zuverlässig erkennen, ausfüllen und speichern - ganz ohne dass jemand sich eine Zeichenfolge merken muss.
<label for="benutzer">Benutzername oder E-Mail</label>
<input id="benutzer" name="username" type="text"
autocomplete="username" />
<label for="pw">Passwort</label>
<input id="pw" name="password" type="password"
autocomplete="current-password" />
<!-- Einmalcode in EINEM Feld, damit das Einfügen aus der Zwischenablage möglich bleibt -->
<label for="otp">Einmalcode</label>
<input id="otp" name="otp" inputmode="numeric"
autocomplete="one-time-code" />Genauso wichtig ist, was man unterlassen sollte. Ein Skript, das das Einfügen ins Passwortfeld unterbindet, zwingt Nutzer zum fehleranfälligen Abtippen und verstößt gegen das Kriterium, sofern keine Alternative besteht (W3C WAI, 2023). Auch das Aufsplitten eines Einmalcodes in sechs Einzelfelder, in die sich ein kopierter Code nicht am Stück einfügen lässt, erzeugt eine unnötige Transkriptionsaufgabe. Ein einzelnes Feld mit autocomplete="one-time-code" erlaubt dagegen das Einfügen und auf mobilen Geräten sogar die automatische Übernahme aus der SMS.
Das Einfügen nicht blockieren
Magic-Link und Passkeys als starke Alternative
Wo eine zweite, kognitiv entlastende Methode gefragt ist, haben sich zwei Ansätze bewährt. Der E-Mail-Magic-Link verschickt einen einmaligen Anmeldelink an die hinterlegte Adresse; ein Klick genügt, es gibt nichts zu merken und nichts abzutippen. Passkeys auf Basis der offenen Webstandards WebAuthn und FIDO2 ersetzen das Passwort durch einen kryptografischen Schlüssel, der im Gerät liegt und per Fingerabdruck, Gesichtserkennung oder Geräte-PIN freigegeben wird. Beide Verfahren erfüllen die Alternative-Ausnahme des Kriteriums, weil sie ohne kognitiven Funktionstest auskommen.
Wichtig ist, die Alternative gleichwertig anzubieten und nicht hinter einem CAPTCHA oder einem überlagernden Element zu verstecken. So wenig wie ein Cookie-Banner das Anmeldeformular verdecken darf - dazu zeigt der Leitfaden zu barrierefreien Cookie-Bannern die konforme Umsetzung -, so wenig sollte die entlastende Methode versteckt sein. Eine barrierefreie Anmeldung stellt sie sichtbar in den Vordergrund und hält den klassischen Passwort-Weg als gleichrangige Option offen. So bleibt der Zugang auch dann erhalten, wenn ein Verfahren einmal nicht verfügbar ist, etwa weil ein Nutzer sein biometrisches Gerät gerade nicht zur Hand hat.
E-Mail-Magic-Link
Einmaliger Anmeldelink per E-Mail. Kein Passwort im Gedächtnis, kein Code zum Abtippen - ein Klick meldet an.
Passkeys (WebAuthn)
Kryptografischer Schlüssel im Gerät, freigegeben per Fingerabdruck oder PIN. Erfüllt die Alternative-Ausnahme von SC 3.3.8.
Passwort-Manager
Korrekte autocomplete-Tokens lassen Manager Zugangsdaten erkennen und ausfüllen - der vom W3C genannte Hilfsmechanismus.
Einmalcode einfügen
Ein einzelnes Feld mit autocomplete=one-time-code erlaubt das Einfügen und die automatische Übernahme aus der SMS.
Biometrie
Fingerabdruck oder Gesichtserkennung ersetzen die Merkaufgabe vollständig, ohne dass Zeichen eingegeben werden.
Verbund-Anmeldung
Die Anmeldung über ein bereits bestehendes Konto verlagert die Prüfung, statt einen neuen kognitiven Test zu verlangen.
Barrierearme CAPTCHA-Alternativen
CAPTCHAs sind seit Jahren die meistgenannte Barriere unter Screenreader-Nutzern. In der WebAIM Screen Reader User Survey 10 (2024) mit 1.539 Teilnehmenden rangiert das verzerrte Text-CAPTCHA erneut an der Spitze der problematischsten Elemente; Menschen mit Behinderung nennen es rund doppelt so häufig (WebAIM Survey 10, 2024) als problematisch wie Menschen ohne Behinderung. Das Grundproblem ist nicht der Schutz vor Bots, sondern die Art der Aufgabe: verzerrte Zeichen zu entziffern ist ein visueller und kognitiver Test, den viele Nutzer nicht bestehen können.
| CAPTCHA-Typ | Barriere | Barrierearme Umsetzung |
|---|---|---|
| Verzerrter Text | Visuelle und kognitive Entzifferung, für Screenreader unlesbar | Durch Objekterkennung oder unsichtbare serverseitige Prüfung ersetzen |
| Bilderraster (Ampeln, Autos) | Feinmotorik und schnelle Bildanalyse nötig | Objekterkennung mit klarer Aufgabe plus gleichwertige Audio-Alternative |
| Rechen- oder Logikaufgabe | Kognitiver Funktionstest ohne Ausnahme | Unzulässig - durch Honeypot oder Ratenbegrenzung ersetzen |
| Kein sichtbarer Test | Erzeugt keine Nutzeraufgabe | Honeypot-Feld sowie Zeit- und Verhaltensheuristik serverseitig auswerten |
Der pragmatischste Weg ist häufig, den sichtbaren Test ganz wegzulassen. Ein Honeypot-Feld, das für Menschen unsichtbar bleibt, aber von automatisierten Skripten ausgefüllt wird, fängt einen großen Teil einfacher Bots ab, ohne irgendeine Nutzeraufgabe zu erzeugen. Ergänzt um serverseitige Heuristiken - Zeitmessung zwischen Seitenaufruf und Absenden, Ratenbegrenzung pro Adresse, Prüfung auffälliger Muster - entsteht ein Schutz, der die Anmeldung für niemanden erschwert. Solche unsichtbaren Verfahren setzen wir standardmäßig in der barrierefreien Webentwicklung ein.
Objekterkennung, serverseitige Prüfung und Audio-Alternative
Ist ein interaktiver Test unvermeidbar, nennt das W3C die Objekterkennung als zulässige Ausnahme (W3C WAI, 2023). Statt verzerrter Zeichen zeigt der Test alltägliche Gegenstände und bittet, etwa alle Bilder mit einem Hund oder einer Ampel zu markieren. Das ist eine Wahrnehmungsaufgabe, kein Gedächtnistest - und damit für Menschen mit Lese- oder Rechenschwäche deutlich zugänglicher. Entscheidend ist, dass die Aufgabe klar formuliert, die Bilder ausreichend groß und die Auswahl vollständig per Tastatur bedienbar ist.
Für blinde Nutzer reicht ein rein visueller Objekttest nicht aus. Deshalb gehört eine gleichwertige Audio-Alternative dazu, die eine gesprochene Aufgabe stellt, ergänzt um eine saubere Auszeichnung mit Beschriftungen und Live-Regionen, damit Screenreader Aufgabe und Ergebnis ansagen. Wie diese ARIA-Mechanismen zusammenspielen, vertieft der Beitrag zu ARIA-Rollen, Zuständen und Live-Regionen. Die eigentliche Prüfung sollte zudem serverseitig erfolgen, damit sie nicht im Browser ausgehebelt werden kann.
- Sichtbaren Text-CAPTCHA durch unsichtbaren Honeypot und serverseitige Heuristik ersetzen
- Wenn ein Test nötig ist: Objekterkennung alltäglicher Gegenstände statt verzerrter Zeichen
- Zu jedem visuellen Test eine gleichwertige gesprochene Audio-Alternative anbieten
- Aufgabe, Auswahl und Ergebnis vollständig per Tastatur bedienbar machen
- Die Prüfung serverseitig durchführen und Ergebnisse per Live-Region ansagen
- Passwort-Manager, Einfügen und autocomplete-Tokens durchgängig zulassen
SC 3.3.8 in Registrierung, Login und Checkout umsetzen
Barrierefreie Authentifizierung ist nicht nur eine Rechtsfrage, sondern ein Conversion-Hebel. Das Baymard Institute führt 26 Prozent (Baymard Institute) der Kaufabbrüche im Checkout auf einen erzwungenen Konto-Zwang und weitere 22 Prozent (Baymard Institute) auf einen zu langen oder komplizierten Ablauf zurück. Jede Hürde bei Registrierung und Login - vom CAPTCHA bis zum Passwort-Zwang - wirkt hier unmittelbar auf den Umsatz. Ein Gast-Checkout, eine Anmeldung per Magic-Link und ein Login, der Passwort-Manager zulässt, senken Abbrüche und erfüllen zugleich SC 3.3.8. Besonders sichtbar wird das im barrierefreien Checkout eines Online-Shops.
Barrierefreie Anmeldung zahlt doppelt
Eine Anmeldung ist erst barrierefrei, wenn ein Mensch sie ohne Gedächtnisleistung und ohne Rätsel abschließen kann - mit Passwort-Manager, per Magic-Link oder Passkey.
Ob eine Anmeldung tatsächlich konform ist, zeigt sich erst im manuellen Test. Automatische Prüfwerkzeuge erkennen viele technische Mängel - der WebAIM Million Report 2025 zählte im Schnitt 51 Fehler (WebAIM Million, 2025) pro Startseite -, doch ob ein Passwort-Manager greift, ein Code sich einfügen lässt und eine Audio-Alternative funktioniert, lässt sich nur mit Tastatur und Screenreader beurteilen. Genau das prüfen wir im WCAG-2.2-Audit und im laufenden Screenreader-Test. Welche weiteren Kriterien WCAG 2.2 mitbringt, ordnet der Überblick zu den neuen WCAG-2.2-Erfolgskriterien ein. Teams, die solche Muster selbst umsetzen möchten, begleiten wir mit Schulungen zur barrierefreien Entwicklung und der Umsetzung barrierefreier Anmeldeprozesse.