CAPTCHA und 2FA barrierefrei nach BFSG: Sicherheit ohne Ausschluss

Alternative Authentifizierungen: Was WCAG 2.2 erlaubt

WCAG 2.2 definiert 'Accessible Authentication' (2.7.3) klar:

Nicht zulässig: Bilder-CAPTCHA, Zeichenfolgen abtippen, Rätsel, Schieberegler 'Ich bin kein Bot' ohne Alternative.

Zulässig: Einmalcodes per E-Mail oder SMS, biometrische Daten (Fingerabdruck, Gesicht), Hardware-Keys (FIDO2/WebAuthn), Multi-Faktor ohne kognitives Rätsel.

Der Authentifizierungs-Schritt darf nicht schwächer werden, nur weil er barrierefrei ist. Ein Code per E-Mail ist genauso sicher wie ein CAPTCHA. Praktisch: reCAPTCHA v3 (unsichtbar) mit Fallback auf E-Mail-Code, oder: Gar kein CAPTCHA für bekannte Nutzer (nach Login), nur für Registrierung.

Praktische Umsetzung: CAPTCHAs ersetzen

reCAPTCHA Enterprise oder v3: Google reCAPTCHA v3 bewertet Nutzerverhalten unsichtbar. Wenn Vertrauensscore zu niedrig: Fallback auf Check. Besser als nur v2.

Honeypot plus Verhaltensanalyse: Verstecke ein unsichtbares Feld. Bots füllen es aus, Menschen nicht. Kombiniert mit IP-Reputation und Versand-Timing erkennst du 80 bis 90 Prozent der Spambots ohne Reibung.

Einmalcodes per E-Mail: Nutzer tippt E-Mail, bekommt 6-stelligen Code, gibt ihn ein. Kein Passwort, keine Reibung. Sicherheit ist mindestens gleich hoch.

WebAuthn/FIDO2: Für Tech-affine Zielgruppen: Hardware-Key oder Biometrie des Geräts sind die sicherste Variante überhaupt.

Zwei-Faktor-Login BFSG-konform gestalten

Der Ablauf: Login-Formular standard (E-Mail und Passwort, klar beschriftet). Nach Login fragt Seite nach zweiter Authentifizierung (Zeit-basiert, SMS oder E-Mail-Code). Das 2FA-Formular hat klares Label, Eingabefeld mit Fehlermeldung, daneben Link 'Habe keinen Code' (mit Fallback).

Was oft schiefgeht: Code-Input hat kein Label (nur Platzhalter), Zeitlimit ist nicht sichtbar (nach 5 Min verfällt Code), es gibt keinen Fallback, Fehlermeldung sagt nur 'Ungültig' statt 'Code ist abgelaufen, bitte neuen anfordern'.

Nutzer-Test mit Screenreader und Tastatur offenbart diese Fehler in Minuten.

Passwortmanager und Autofill im Anmeldeprozess

Viele Menschen verwalten ihre Zugangsdaten in einem Passwortmanager oder lassen den Browser Formulare automatisch ausfüllen. Das gilt besonders für Nutzer, die sich komplexe Zeichenfolgen wegen kognitiver oder motorischer Einschränkungen nicht merken oder nicht fehlerfrei eintippen können. Blockiert ein Formular das Einfügen aus der Zwischenablage, um angeblich Bots fernzuhalten, trifft das vor allem Menschen, die auf diese Hilfsmittel angewiesen sind, während automatisierte Angriffe solche Sperren ohnehin leicht umgehen. Login-, Registrierungs- und Einmalcode-Felder sollten deshalb technisch so ausgezeichnet sein, dass Passwortmanager sie zuverlässig erkennen und befüllen können. Dazu gehört ein sauberes Label, ein passender Feldtyp und ein Attribut, das dem Browser mitteilt, ob es sich um einen Benutzernamen, ein neues oder ein bestehendes Passwort oder einen Einmalcode handelt. Bei Einmalcodes aus SMS oder E-Mail hilft ein Attribut, das mobilen Betriebssystemen erlaubt, den Code direkt vorzuschlagen, sodass Nutzer ihn nicht abtippen müssen. Wird der Code auf mehrere einzelne Kästchen verteilt, sollte das Einfügen des kompletten Codes trotzdem funktionieren und automatisch auf die Felder verteilt werden. Diese Details wirken klein, entscheiden aber häufig darüber, ob eine Anmeldung in wenigen Sekunden gelingt oder abgebrochen wird.

Sperrfristen und Wiederholungsversuche fair gestalten

Nach mehreren fehlgeschlagenen Anmeldeversuchen sperren viele Systeme das Konto oder verlangen eine Wartezeit, bevor ein neuer Versuch möglich ist. Diese Schutzmaßnahme trifft Menschen mit Screenreader oder Tastatursteuerung härter, weil sie beim Ausfüllen und Absenden von Formularen im Schnitt länger brauchen und dadurch eher versehentlich einen falschen Code oder ein falsches Zeichen erwischen. Wird die Sperre ohne Hinweis auf die verbleibende Wartezeit angezeigt, bleibt für den Nutzer unklar, ob das eigene Gerät, die eigene Eingabe oder ein technischer Fehler die Ursache ist. Eine verständliche Fehlermeldung sollte deshalb benennen, wie viele Versuche noch möglich sind oder wie lange die Sperre andauert, und sie sollte diesen Hinweis so einbetten, dass er auch von einem Screenreader vorgelesen wird. Sinnvoll ist außerdem ein Ausweichweg, etwa ein neuer Code per E-Mail oder ein Link zum Support, statt den Nutzer ohne weitere Option auf eine feste Wartezeit zu verweisen. Wer Sperrmechanismen ausschließlich an der Anzahl der Versuche und nicht an ungewöhnlich schnellen, automatisierten Anfragen ausrichtet, bestraft vor allem langsame, aber legitime Nutzer.

Zusammenspiel mit dem Kundensupport bei Anmeldeproblemen

Wenn ein Nutzer trotz aller Vorkehrungen an CAPTCHA oder Zwei-Faktor-Login scheitert, entscheidet der Weg zum Support darüber, ob der Kontakt verloren geht oder erhalten bleibt. Ein Hinweis wie 'Bei Problemen wenden Sie sich an den Support' ohne direkten Link oder erreichbaren Kontaktweg hilft in dem Moment niemandem, in dem die Anmeldung gerade fehlschlägt. Sinnvoller ist ein sichtbarer Link direkt neben dem Anmeldeformular, der zu einer alternativen Kontaktmöglichkeit führt, etwa einer Telefonnummer oder einem Kontaktformular ohne eigene Login-Pflicht. Support-Mitarbeiter sollten zudem wissen, welche Authentifizierungsprobleme bei assistiven Technologien typischerweise auftreten, damit sie nicht pauschal einen Cache-Reset oder einen anderen Browser vorschlagen, wenn eigentlich ein fehlendes Label oder ein blockiertes Einfügen die Ursache ist. Größere Anbieter richten dafür eine kurze interne Checkliste ein, die häufige Barrieren in der eigenen Anmeldestrecke auflistet, damit Rückfragen schneller und zielgerichteter beantwortet werden. So bleibt der Anmeldeprozess nicht die einzige Tür, sondern es gibt einen zweiten, ebenfalls zugänglichen Weg, wenn diese Tür für einzelne Nutzer geschlossen bleibt.

Häufig gestellte Fragen