Barrierefreie Authentifizierung verstehen

Was bedeutet barrierefreie Authentifizierung?

Authentifizierung umfasst alle Schritte, mit denen Nutzer:innen nachweisen, dass sie wirklich diejenigen sind, für die sie sich ausgeben — also typischerweise Login, Mehrfaktor-Bestätigung, Passwort-Zurücksetzen, Identitätsprüfung und auch der Logout. Genau hier konzentrieren sich die schwierigsten Barrieren: ohne erfolgreichen Login sehen Menschen den Rest einer Anwendung nie.

Barrierefrei ist eine Authentifizierung dann, wenn niemand sie auf Grund einer Behinderung, einer Beeinträchtigung oder einer ungewohnten Bedienform nicht abschließen kann. Das schließt motorische Einschränkungen, Sehbehinderungen, kognitive Belastungen, Stress und Konzentrationsschwankungen genauso ein wie Tastatur- oder Screenreader-Bedienung.

WCAG 2.2 — Kriterien 3.3.8 und 3.3.9 im Detail

Beide Kriterien fordern: ein Authentifizierungsschritt darf keinen kognitiven Funktionstest verlangen — es sei denn, es gibt eine zugängliche Alternative, einen Hilfsmechanismus oder eine andere im Kriterium erlaubte Lösung. Sie unterscheiden sich in der Härte der Ausnahmen.

WCAG 2.2 Kriterien 3.3.8 und 3.3.9 im Vergleich

Aspekt	3.3.8 (Minimum) — Level AA	3.3.9 (Enhanced) — Level AAA
Kerngedanke	Login ohne reine Gedächtnis- oder Rätsel-Aufgabe ermöglichen.	Identisch, aber ohne die Ausnahmen für Objekt- und Inhaltserkennung.
Erlaubt als Ausnahme	Alternativer Login ohne Test · Hilfsmechanismus · Objekt-Erkennung · Wiedererkennen eigener Inhalte.	Nur: alternativer Login ohne Test · Hilfsmechanismus.
Typisch erfüllt durch	Passwort + Browser-Autofill · Passkeys (WebAuthn) · Magic-Link · Foto eines eigenen Tieres als Wiedererkennen.	Passkeys (WebAuthn) · Hardware-Token · biometrischer Login am Endgerät.
Rechtliche Bedeutung	Pflicht im Sinne von BFSG, BITV 2.0 (sobald über EN 301 549 nachgeführt), EAA.	Empfehlung; AAA ist keine Pauschal-Anforderung gesetzlicher Regelungen.

Wichtig: Mehrfaktor-Anmeldung schaltet das Kriterium nicht aus. Jeder einzelne Schritt muss konform sein, und über den gesamten Auth-Flow hinweg muss ein Pfad bestehen, der ohne kognitiven Funktionstest auskommt.

Was zählt als kognitiver Funktionstest?

Der Begriff klingt abstrakt, beschreibt aber sehr alltägliche Hürden. WCAG 2.2 nennt drei Beispiele:

• Erinnern. Eine Information aus dem Gedächtnis abrufen — typischerweise ein Passwort, eine PIN oder Antworten auf Sicherheitsfragen.
• Übertragen / Transkribieren. Eine kurzlebige Information von einem Ort zum anderen kopieren — etwa eine SMS-TAN per Hand in ein Formular tippen.
• Rätsel lösen. Eine Aufgabe lösen, die nichts mit der eigentlichen Anwendung zu tun hat — Bilderrätsel, verzerrte Buchstaben, Mathe-Aufgaben.

Nicht jedes Eingabefeld ist automatisch ein Test. Wenn Nutzer:innen sich etwa per Browser-Autofill anmelden oder einen Passwort-Manager nutzen dürfen, verschwindet die kognitive Last — der Browser erinnert sich, die Person nicht. WCAG 2.2 nennt das ausdrücklich als gültigen Pfad.

Lösungswege, die das Kriterium erfüllen

Es gibt mehrere Wege, einen Login zu bauen, der 3.3.8 erfüllt. Sie lassen sich in vier Familien gruppieren:

1. Passwort plus Hilfsmechanismus. Klassisches Passwort, aber das Eingabefeld lässt Copy-Paste zu, akzeptiert Browser-Autofill und blendet das Passwort optional sichtbar ein ( type="password" plus Sichtbar-Schalten). Wer einen Passwort-Manager benutzt, hat keinen Gedächtnistest.
2. Passkeys / WebAuthn. Statt Passwort liegt der private Schlüssel sicher auf dem Gerät. Authentifiziert wird per Geräte-Entsperrung — biometrisch oder per PIN. Aus WCAG-Sicht ist eine PIN am eigenen Gerät kein Test im Sinne des Kriteriums, weil sie nicht bei der prüfenden Stelle abgefragt wird. Passkeys gelten als der zurzeit praxistauglichste Weg, sowohl 3.3.8 als auch 3.3.9 zu erfüllen.
3. Magic-Link. Statt Passwort wird eine E-Mail mit einem einmaligen Anmelde-Link verschickt. Der Klick auf den Link genügt — kein Code abtippen. Nachteil: die E-Mail wird zum Engpass.
4. Objekt- oder Inhalts-Wiedererkennung (nur 3.3.8). Nutzer:innen wählen aus mehreren Bildern „ihr" Tier oder ihre Wahl bei der Registrierung wieder. Das ist auf Level AA erlaubt, fällt auf Level AAA aber weg.

CAPTCHA — der schwierige Sonderfall

CAPTCHAs sind das Lehrbuchbeispiel für ein nicht barrierefreies Authentifizierungselement: ein Rätsel, das die menschliche Eingabe von Bot-Eingaben trennen soll, indem es eine Aufgabe stellt, die für Maschinen schwierig sein soll. Für viele reale Personen ist sie das aber auch.

Bildbasierte CAPTCHAs schließen Menschen mit Sehbehinderung aus. Akustische Varianten sind für hörbehinderte Personen unbrauchbar, oft auch für hörende Menschen kaum verständlich. Klick-CAPTCHAs („Ich bin kein Roboter") setzen häufig Drittanbieter-Cookies voraus, die viele Browser inzwischen blockieren — wer den Schutz hochzieht, fällt zurück auf die Bildvariante. Die BFIT-Bund-Handreichung verlangt deshalb, dass mindestens zwei sensorische Modalitäten angeboten werden. Die W3C-Position dazu ist noch deutlicher: CAPTCHAs als alleiniges Mittel ausschließen.

Eine Untersuchung, die in der Smashing-Magazine-Analyse vom November 2025 zitiert wird, zeigt zusätzlich: Maschinen lösen reCAPTCHA schneller und zuverlässiger als Menschen. Der vermeintliche Schutz schwindet — die Barriere bleibt. Datenlage : die zitierte Zahl (85 % Bot-Erfolgsquote in 17,5 Sekunden) stammt aus einer Sekundärquelle; sie ist eine plausible Größenordnung, kein robuster Branchen-Mittelwert.

Session-Timeouts und Zeitdruck

Ein Login allein reicht nicht — die Sitzung muss auch lang genug halten, um Aufgaben zu erledigen. Genau hier hakt es regelmäßig: starre Timeouts, die nach 5 oder 10 Minuten zwangsweise abmelden, treffen Menschen mit Hand-Tremor, langsameren Lesetempi, kognitiver Belastung oder einfach kurzen Unterbrechungen besonders hart. Eine Smashing-Analyse aus April 2026 ordnet Session-Timeouts als „oft übersehene Authentifizierungs-Barriere" ein und verweist auf eine Größenordnung von rund 1,3 Milliarden Menschen mit relevanten Einschränkungen weltweit. Datenlage : die Zahl deckt sich mit WHO-Schätzungen, dient hier aber illustrativ; die WCAG-Pflicht hängt nicht am genauen Anteil.

WCAG 2.2 selbst regelt Zeitdruck über das ältere Kriterium 2.2.1 Anpassbare Zeit: Wenn ein Zeitlimit existiert, müssen Nutzer:innen es deaktivieren, anpassen oder mindestens 20-mal verlängern können. Für Authentifizierungs-Flüsse heißt das konkret: Warnung vor dem Logout, Möglichkeit zur Verlängerung, Auto-Speichern von Eingaben, fortsetzbare Sitzungen.

Praxis-Checkliste für Auth-Flows

Diese Checkliste lässt sich an einem realen Login-Flow Schritt für Schritt prüfen. Sie ersetzt keine vollständige WCAG-Prüfung, deckt aber die häufigsten Stolpersteine ab.

1. Copy-Paste erlaubt in Passwort- und Code-Feldern? (Kein onpaste -Block, keine Auto-Cut-Zähler.)
2. Browser-Autofill aktiv: richtige autocomplete -Werte gesetzt ( username , current-password , new-password , one-time-code ).
3. Passwort sichtbar schaltbar mit erkennbarem Steuerelement ( aria-pressed , klares Label „Passwort anzeigen / verbergen").
4. Mindestens ein Pfad ohne kognitiven Funktionstest: Passkey, Magic-Link oder Objekt-Wiedererkennung.
5. Kein Pflicht-CAPTCHA ohne barrierefreie Alternative — mehrere Modalitäten oder unsichtbares Risk-Scoring.
6. MFA-Codes werden nicht nur als Bild übermittelt, lassen sich aus der SMS oder Authenticator-App per Autofill übernehmen.
7. Session-Timeout mit Vorwarnung, Verlängerungsoption und Speichern von Eingaben.
8. Fokus sichtbar auf allen interaktiven Elementen (WCAG 2.4.7), Tab-Reihenfolge sinnvoll.
9. Fehlermeldungen beschreiben das Problem (WCAG 3.3.1) und sind nicht nur farblich markiert.
10. Logout-Bestätigung braucht keinen erneuten Test — eine Klick-Geste reicht.