26. Oktober 2026

Barrierefreie Authentifizierung und CAPTCHA: Was WCAG 3.3.8 verlangt

Barrierefreie Authentifizierung im Sinne des WCAG-Erfolgskriteriums 3.3.8 (Stufe AA) bedeutet: Niemand muss beim Anmelden etwas lösen, sich merken oder abschreiben. Der W3C-Text ist eindeutig: Ein kognitiver Funktionstest, etwa sich an ein Passwort erinnern oder ein Rätsel lösen, darf in keinem Schritt der Authentifizierung verlangt werden, es sei denn, dieser Schritt bietet eine alternative Methode, einen unterstützenden Mechanismus, oder der Test besteht darin, Objekte zu erkennen oder Nicht-Text-Inhalte zu identifizieren, die die Person selbst der Website bereitgestellt hat. In der Praxis scheitern ein CAPTCHA mit verzerrtem Text oder einer Rechenaufgabe und ein Passwortfeld, das das Einfügen blockiert, an diesem Kriterium, wenn es keinen anderen Anmeldeweg gibt. Ein Formular mit Benutzername und Passwort bleibt dagegen zulässig, wenn Browser und Passwortmanager die Felder ausfüllen können und Kopieren und Einfügen funktioniert, sofern auch alle weiteren Schritte das Kriterium erfüllen. Im Folgenden erfahren Sie, was verboten und was erlaubt ist, wie Bestätigungscodes behandelt werden und welche CAPTCHA-Alternativen die auf der W3C-Website veröffentlichte Notiz „Inaccessibility of CAPTCHA“ vorstellt.

Was das Erfolgskriterium 3.3.8 Barrierefreie Authentifizierung (Minimum) besagt

Das Ziel formuliert das W3C klar: Anmeldungen sollen mit weniger geistigem Aufwand möglich sein. Manche Menschen mit kognitiven Beeinträchtigungen können keine Rätsel lösen, sich Benutzername und Passwort nicht merken oder Einmalcodes nicht erneut eintippen. Das W3C stuft das Merken eines websitespezifischen Passworts ausdrücklich als kognitiven Funktionstest ein und weist darauf hin, dass das Merken zufälliger Zeichenfolgen oder einer Wischgeste auf einem Touchscreen manche Menschen ausschließt.

Das Kriterium betrifft die Authentifizierung bestehender Nutzerinnen und Nutzer. Das Anlegen eines Benutzernamens oder Kontos deckt es nicht ab, auch wenn dieselben Techniken (Einfügen erlauben, nicht auf Abschreiben setzen) die Registrierung erleichtern. Die Wiederherstellung oder Änderung von E-Mail-Adresse und Passwort gehört dagegen zur Authentifizierung: Muss jemand zur Kontowiederherstellung andere Angaben machen, braucht es eine Methode ohne kognitiven Funktionstest.

Alternative: eine andere Authentifizierungsmethode, die nicht auf einem kognitiven Funktionstest beruht.
Mechanismus: etwas hilft beim Bestehen des Tests, etwa die Unterstützung von Passwortmanagern oder Kopieren und Einfügen.
Objekterkennung: Der Test besteht darin, Objekte zu erkennen (Bilder, Video oder Audio).
Persönliche Inhalte: Der Test besteht darin, Nicht-Text-Inhalte zu identifizieren, die die Person der Website bereitgestellt hat.

Barrierefreie Authentifizierung und CAPTCHA: Was nicht erlaubt ist

Jeder Schritt zählt. Bei Mehr-Faktor-Authentifizierung müssen alle Schritte das Kriterium erfüllen: Es muss einen durchgehenden Anmeldeweg ohne kognitive Funktionstests geben. Das Kriterium gilt auch für CAPTCHAs und Tests, die nur in bestimmten Situationen erscheinen, etwa bei aktivem Werbeblocker oder nach mehreren falschen Passworteingaben.

Das W3C führt das Fehlerbild F109: Verfehlen der Kriterien 3.3.8 und 3.3.9, weil die erneute Eingabe eines Passworts oder Codes im selben Format verhindert wird. Die Seite beschreibt außerdem konkrete Fälle, die zum Abschreiben zwingen oder auf einem kognitiven Test beruhen und problematisch sind, wenn keine andere Authentifizierungsmethode ohne kognitiven Test angeboten wird:

Ein Passwortfeld, das Einfügen verhindert und dazu auffordert, das Passwort von Hand einzutippen.
Ein Skript, das Browser oder Passwortmanager am automatischen Ausfüllen der Felder hindert.
Eine Aufforderung wie „Geben Sie das 1., 3. und 5. Zeichen Ihres Passworts ein“, die zum Abschreiben zwingt.
Ein sechsstelliger Einmalcode, verteilt auf 6 einzelne Felder, bei dem das Einfügen nur die erste Ziffer füllt.
Ein Bestätigungscode, der von Hand abgeschrieben werden muss, ohne Einfügen oder automatisches Ausfüllen.
Ein CAPTCHA mit verzerrtem Text: Seine Audio-Alternative zählt nicht als „Alternative“, wenn sie abgeschrieben werden muss.
Ein Mathe-CAPTCHA oder ein visuelles Rätsel, etwa das 3D-Modell eines Walrosses in eine vorgegebene Richtung zu drehen.
Textbasierte persönliche Inhalte: Sie fallen nicht unter die Ausnahme für persönliche Inhalte, weil sie auf Erinnern statt Wiedererkennen und auf Abschreiben statt Auswählen beruhen.

Was erlaubt ist: Passwortmanager, Kopieren und Einfügen, Methoden ohne Test

Benutzername (oder E-Mail) und Passwort bleiben zulässig, sofern Browser und Passwortmanager von Drittanbietern die Felder ausfüllen können. Laut W3C sollten Browser und Passwortmanager die Felder zuverlässig erkennen und ausfüllen können, wenn das Formular das Kriterium 1.3.5 (Input Purpose) erfüllt und die Steuerelemente einen passenden zugänglichen Namen nach 4.1.2 (Name, Role, Value) haben. Auch Kopieren und Einfügen vermeidet das Abschreiben: Zugangsdaten werden aus einem eigenständigen Passwortmanager kopiert und ins Formular eingefügt.

Zu den hinreichenden Techniken, die das W3C nennt, gehören die Authentifizierung per E-Mail-Link (G218) und korrekt ausgezeichnete E-Mail- und Passwortfelder (H100). Die Beispiele auf der Seite umfassen außerdem:

WebAuthn, um sich mit dem eigenen Gerät anzumelden (zum Beispiel Gesichtsscan, Fingerabdruck oder PIN, je nach Einrichtung durch die Person).
Anmeldung über einen Drittanbieter mit OAuth.
Zwei-Faktor-Authentifizierung mit mehreren Optionen, darunter eine USB-Methode, bei der man nur einen Knopf drückt, um ein zeitbasiertes Token einzugeben.
Ein QR-Code, der mit einer App auf dem eigenen Gerät gescannt wird.
Eine Benachrichtigung auf dem eigenen Gerät, bestätigt über dessen Authentifizierungsmechanismus.

CAPTCHAs mit Objekterkennung und persönliche Inhalte

Ein CAPTCHA, bei dem alle Bilder mit einem Auto ausgewählt werden sollen, fällt auf Stufe AA unter die Ausnahme Objekterkennung. Ein Objekt meint hier ein materielles Ding, das man sehen und anfassen kann, einschließlich Fahrzeugen und Tieren. Geht der Test über das Erkennen hinaus, etwa die Zahl der Katzen mit der Zahl der Hunde multiplizieren, greift die Ausnahme nicht mehr. Und ein Test auf Basis von etwas, das die Website vorgibt, etwa ein Wort merken oder abschreiben, ist ein kognitiver Funktionstest.

Persönliche Inhalte funktionieren so: Beim Anlegen des Kontos lädt die Person ein Bild hoch und wählt es bei der Anmeldung aus mehreren Optionen aus. Das W3C mahnt hier zu ausreichender Sicherheit, da Unbefugte das richtige Bild erraten könnten. Vor allem weist es darauf hin, dass beide Ausnahmen Menschen mit kognitiven Beeinträchtigungen nicht vollständig gerecht werden und möglichst vermieden werden sollten: Im Kriterium 3.3.9 Barrierefreie Authentifizierung (erweitert) der Stufe AAA sind sie nicht ausgenommen.

Zudem weist das W3C darauf hin, dass eine Option zum Anzeigen des Passworts manchen Menschen den Erfolg erleichtern kann, wenn Tippen doch nötig ist, zum Beispiel beim Erstellen eines Passworts, das ein Passwortmanager speichern soll.

Bestätigungscodes und Zwei-Faktor-Authentifizierung

Ein Dienst, der das manuelle Abschreiben eines Bestätigungscodes verlangt, ist nicht konform. Mindestens muss sich der Code einfügen lassen (aus einem Passwortmanager, einer SMS-App oder einem softwarebasierten Sicherheitsschlüssel), und der Browser muss das Feld automatisch ausfüllen dürfen.

Kommt der Code auf einem zweiten Gerät an, etwa per SMS aufs Smartphone bei einer Anmeldung am Laptop, liegt die Übertragung zwischen den Geräten außerhalb des Kriteriums. Bei der Prüfung wird angenommen, dass der Code in der Zwischenablage liegt; geprüft wird nur, ob das Codefeld Einfügen zulässt. Das W3C stellt zudem klar, dass Zwei-Faktor-Systeme ohne Codes keine kognitiven Funktionstests sind: Hardware-Schlüssel wie ein YubiKey, Apps, in denen man bestätigt, dass man sich wirklich selbst anmeldet, und Methoden des Betriebssystems wie Windows Hello, Touch ID und Face ID.

Warum die Notiz „Inaccessibility of CAPTCHA“ CAPTCHAs für unzugänglich hält

„Inaccessibility of CAPTCHA“ ist eine Group Draft Note vom 16. Dezember 2021, veröffentlicht von der Accessible Platform Architectures Working Group als Aktualisierung der Notiz von 2019. Sie ist weder vom W3C noch von seinen Mitgliedern gebilligt und gilt als Arbeitsstand. Ihr Befund ist deutlich: Schon die Natur der interaktiven Aufgabe schließt viele Menschen mit Behinderungen aus und kommt einer Dienstverweigerung gleich.

Wer blinde, sehbehinderte oder legasthene Menschen verzerrte Zeichen lesen lässt, verlangt genau die Aufgabe, die ihnen am schwersten fällt; dasselbe gilt für Audio-CAPTCHAs und gehörlose oder schwerhörige Menschen. Klassische CAPTCHAs setzen zudem oft Englischkenntnisse voraus, und ein Design, das mehrere Versuche als selbstverständlich einplant, ist laut der Notiz wohl schon von seiner Anlage her unzugänglich für Menschen mit Angststörungen und für viele Menschen mit anderen kognitiven und Lernbehinderungen. Die Notiz zitiert außerdem Daten von Cloudflare, wonach das Lösen eines CAPTCHAs im Schnitt 32 Sekunden dauert.

Die Notiz betont außerdem, dass CAPTCHAs als Sicherheitsmaßnahme immer weniger wirksam sind: Bild-, Logik- und Audio-Ansätze lassen sich mit Algorithmen weitgehend knacken. Sie verweist auf eine Studie der University of Maryland mit 90 % Erfolgsquote gegen Googles Audio-reCAPTCHA.

CAPTCHA-Alternativen, die die Notiz vorstellt

Bei sonst gleichen Bedingungen bevorzugen die Autorinnen und Autoren der Notiz nicht interaktive Ansätze, weil sie keine Barrieren schaffen, warnen aber, dass sie personenbezogene Daten preisgeben können. Die Understanding-Seite zu 3.3.8 nennt zudem Ratenbegrenzung, Geolokalisierung des Clients und private Client-Authentifizierung: Keines dieser Verfahren ist zu 100 % wirksam, sie können aber die Wahrscheinlichkeit verringern, dass ein CAPTCHA angezeigt wird.

Spamfilter (Schlagwörter, Bayes-Filter): Gut eingestellte Systeme können mit einem visuellen CAPTCHA mithalten, ohne kognitive Last.
Proof of Work: eine JavaScript-Berechnung im Client, die der Server prüft; kein direktes Barriereproblem, kann aber ältere Hardware verlangsamen.
Heuristiken: Roboter anhand der angeforderten Datenmenge, besuchter Seiten, IP-Adressen oder der Art der Dateneingabe erkennen.
Honeypot: ein Feld, das für Roboter sichtbar, für Menschen aber verborgen ist, einfach umzusetzen.
Konten mit begrenzter Nutzung: die Interaktionshäufigkeit neuer Konten begrenzen.
Unter den interaktiven Ansätzen: Biometrie mit mehreren wählbaren Merkmalen oder kryptografische Bestätigung der Personeneigenschaft auf Basis von WebAuthn.
Tokens wie Privacy Pass: Sie beginnen weiterhin mit einer CAPTCHA-Aufgabe, verringern aber spätere interaktive Abfragen deutlich.
Wenn ein interaktives CAPTCHA nötig bleibt: es so selten wie möglich zeigen und mehrere Aufgaben anbieten, die unterschiedliche sensorische und kognitive Fähigkeiten ansprechen.

So prüfen Sie Ihren Anmeldeprozess

Gehen Sie jeden Schritt durch, auch Zwei-Faktor-Authentifizierung, Kontowiederherstellung und Tests, die erst nach Fehlern erscheinen. Fügen Sie ein Passwort und einen Code aus einem Passwortmanager ein: Beide müssen vollständig übernommen werden. Prüfen Sie, ob der Passwortmanager die Felder ausfüllt und ob sie einen zugänglichen Namen haben. Bleibt ein CAPTCHA, stellen Sie sicher, dass es einen anderen Anmeldeweg ohne kognitiven Test gibt. Für Ihre übrigen Seiten helfen ein kostenloser Test und die kontinuierliche Überwachung mit Conformly, Ihre Barrierefreiheit im Blick zu behalten.

Häufige Fragen

Sind CAPTCHAs nach WCAG verboten?

Nicht grundsätzlich. Kriterium 3.3.8 verlangt, dass ein Authentifizierungsschritt nicht auf einem kognitiven Test ohne Alternative oder unterstützenden Mechanismus beruht; ein CAPTCHA mit Objekterkennung bleibt auf Stufe AA zulässig. Die W3C-Notiz erinnert außerdem daran, dass die WCAG CAPTCHAs erlauben, wenn Textalternativen ihren Zweck benennen und beschreiben und alternative Formen für andere Sinneswahrnehmungen angeboten werden.

Verstößt das Blockieren von Einfügen im Passwortfeld gegen WCAG 3.3.8?

Ja. Wer das Einfügen in Authentifizierungsfelder verhindert, erzwingt Abschreiben und verfehlt das Kriterium, sofern keine andere Methode ohne kognitiven Test verfügbar ist.

Ist ein CAPTCHA „Wählen Sie alle Autos aus“ barrierefrei?

Es profitiert von der Ausnahme Objekterkennung in 3.3.8 (Stufe AA), doch diese Ausnahme gibt es in 3.3.9 (Stufe AAA) nicht. Das W3C rät, es möglichst zu vermeiden, die Ausnahme entfällt, sobald der Test über reines Erkennen hinausgeht, und alle anderen Authentifizierungsschritte müssen das Kriterium ebenfalls erfüllen.

Reicht eine Audio-Alternative zum CAPTCHA aus?

Nein, wenn das Gehörte abgeschrieben werden muss: Dann zählt sie nicht als Alternative im Sinne von 3.3.8. Die CAPTCHA-Notiz ergänzt, dass Audio-CAPTCHAs alle Nutzenden im Vergleich zum Verstehen normaler Sprache kognitiv überlasten und dass das Abschreiben eines Audio-CAPTCHAs genau die Aufgabe ist, die gehörlose und schwerhörige Menschen sowie Menschen mit auditiver Verarbeitungsstörung am wenigsten wahrscheinlich bewältigen.

Gilt WCAG 3.3.8 auch für die Registrierung?

Nein, es betrifft die Authentifizierung bestehender Nutzerinnen und Nutzer einschließlich der Kontowiederherstellung. Einfügen zu erlauben und Abschreiben zu vermeiden, erleichtert aber auch die Registrierung.

Was ist die barrierefreieste Alternative zum CAPTCHA?

Die Autorinnen und Autoren der W3C-Notiz bevorzugen nicht interaktive Ansätze wie Honeypot, Spamfilter, Heuristiken oder Proof of Work, die nach ihrer Einschätzung keine Barrieren schaffen, aber personenbezogene Daten preisgeben können. Sie raten, den Schutz am tatsächlichen Risiko auszurichten, zum Beispiel einen Honeypot zu nutzen, solange er genügt.

Weiterlesen bei Conformly

Quellen

Dieser Artikel stützt sich auf die am Seitenende genannten offiziellen Quellen.