Barrierefreie 2FA und OTP-Eingaben: so vermeiden Sie Login-Hürden im Kundenportal

Viele Teams sichern ihr Kundenportal mit Zwei-Faktor-Authentifizierung ab und bauen sich dabei unabsichtlich eine neue Barriere. Das Problem ist selten die 2FA selbst. Das Problem ist die Umsetzung: sechs getrennte Code-Felder, blockiertes Einfügen, hektische Timer, unklare Fehler und Fallbacks, die schlechter bedienbar sind als der eigentliche Login.

Genau hier liegt der eigenständige BFSG-relevante Angle dieses Themas: Nicht „Login allgemein“, sondern die konkrete Authentifizierungsstrecke mit OTP-Eingabefeldern, Autofill, Passkeys und Wiederherstellungspfaden. Wenn dieser Abschnitt scheitert, bleibt Ihr gesamter Service unzugänglich.

Wenn Sie den Gesamtzustand Ihres Portals erst einordnen möchten, starten Sie mit unserem Überblick zu BFSG für SaaS und Kundenportale.

Der 8-Minuten-Schnelltest für 2FA barrierefrei

Testen Sie einen echten Login-Fluss bewusst ohne Maus und ohne Vorwissen.

1. Öffnen Sie den Login und navigieren Sie nur mit Tab und Shift+Tab.
2. Geben Sie Benutzername und Passwort ein.
3. Aktivieren Sie, falls vorhanden, „Passwort anzeigen“.
4. Erreichen Sie den 2FA-Schritt und fügen Sie den kompletten OTP-Code per Paste ein.
5. Prüfen Sie, ob Browser oder Betriebssystem den Einmalcode automatisch anbieten.
6. Geben Sie absichtlich einen falschen Code ein.
7. Fordern Sie einen neuen Code an.
8. Testen Sie den Fallback, zum Beispiel „anderes Verfahren nutzen“ oder „Passkey verwenden“.

Wenn einer dieser Schritte stockt, Fokus verliert oder nur unter Zeitdruck funktioniert, haben Sie sehr wahrscheinlich ein reales Accessibility-Problem im Login.

Warum ausgerechnet OTP-Eingabefelder so oft scheitern

Viele Portale verwenden visuell attraktive, aber fragile OTP-Komponenten. Typische Risiken sind:

• sechs einzelne Inputs mit unvorhersehbaren Fokus-Sprüngen
• Auto-Advance, das Screenreader- und Tastaturnutzung erschwert
• Backspace-Verhalten, das inkonsistent oder frustrierend ist
• blockiertes Copy-and-Paste
• fehlendes autocomplete="one-time-code"
• Fehlermeldungen, die nur rot markiert oder nicht angesagt werden
• Countdown-Timer ohne klare Statuskommunikation

Für Nutzerinnen und Nutzer mit Sehbehinderungen, motorischen Einschränkungen, kognitiven Belastungen oder Screenreader-Nutzung wird aus einer Sicherheitsmaßnahme dann schnell eine Zugangssperre.

Was WCAG 2.2 bei accessible authentication praktisch von Ihnen verlangt

Für diesen Bereich ist vor allem WCAG 2.2 relevant, insbesondere Accessible Authentication (Minimum) und als strengere Zielmarke Accessible Authentication (Enhanced). Die Kernaussage für die Praxis lautet: Nutzer sollen nicht unnötig zu kognitiv belastenden Schritten gezwungen werden, wenn zugängliche Hilfen oder Alternativen möglich sind.

Das bedeutet für 2FA und OTP-Eingaben unter anderem:

• Browser- und Passwortmanager-Hilfen dürfen nicht unnötig blockiert werden.
• Das manuelle Abtippen von Codes sollte nicht die einzige praktikable Option sein.
• Eingabefelder brauchen eindeutige Labels und nachvollziehbare Hinweise.
• Fehlermeldungen, Sperren und Ablaufzustände müssen verständlich kommuniziert werden.
• Eine stärkere, aber leichter nutzbare Alternative wie Passkey/WebAuthn kann die bessere Lösung sein.

Wenn Sie die Prüfperspektive vertiefen möchten, ergänzt unser Beitrag zu automatischen und manuellen BFSG-Tests die Einordnung.

Die 5 wichtigsten Fixes mit dem besten 80/20-Effekt

1) Ein robustes OTP-Feld ist meist besser als sechs getrennte Felder

Aus Accessibility-Sicht ist ein einziges Eingabefeld für den kompletten Einmalcode oft die stabilere Wahl. Es reduziert Fokuslogik, macht Paste trivial, funktioniert sauberer mit Screenreadern und unterstützt mobile AutoFill-Muster besser.

Mehrere Einzelfelder sind nur dann vertretbar, wenn Sie wirklich alle Randfälle sauber gelöst haben:

• logische Tab-Reihenfolge
• verlässliches Backspace-Verhalten
• vollständige Paste-Unterstützung für den ganzen Code
• sinnvolle Ansage pro Feld oder pro Gruppe
• keine unerwarteten Fokuswechsel

Wenn Sie diese Qualität nicht sicherstellen können, ist ein einzelnes Feld fast immer die bessere Produktentscheidung.

2) Paste und AutoFill dürfen nicht blockiert werden

Das ist einer der häufigsten und unnötigsten Fehler. Wer das Einfügen deaktiviert, zwingt Menschen zum Abschreiben und erhöht Fehlerquote, Frust und Abbrüche.

Sofort nutzbare Fixes:

• erlauben Sie Copy-and-Paste des kompletten Codes
• setzen Sie autocomplete="one-time-code" dort ein, wo ein Einmalcode erwartet wird
• blockieren Sie Passwortmanager und Browser-Autofill nicht künstlich
• verhindern Sie keine Zwischenablage-Nutzung mit fragilen JavaScript-Hooks

Dieser Punkt ist direkt anschlussfähig an das WCAG-Prinzip „accessible authentication“ und gehört zu den schnellsten Verbesserungen überhaupt.

3) „Passwort anzeigen“ und andere Hilfen müssen sauber benannt sein

Schon vor dem OTP-Schritt scheitern viele Logins an unklaren oder schlecht zugänglichen Passwortfeldern. Typische Probleme sind Placeholder statt Label, ein reines Augen-Icon ohne zugänglichen Namen oder Hilfetexte, die nicht mit dem Feld verknüpft sind.

Robuste Mindestlösung:

• sichtbares Label für Benutzername und Passwort
• klar benannter Toggle wie „Passwort anzeigen“
• Hinweise zu Format oder Anforderungen direkt am Feld
• keine reinen Icon-Bedienelemente ohne verständlichen Namen

Für diese Grundlagen sind auch unsere Ratgeber zu Placeholdern statt Labels und zu barrierefreien Kontaktformularen und Fehlermeldungen relevant.

4) Fehler, Ablauf und Sperren müssen Orientierung geben

Viele Teams zeigen nur „Ungültiger Code“. Das ist zu wenig. Gute Fehlermeldungen beantworten drei Fragen:

• Was ist passiert?
• Was kann die Person jetzt tun?
• Gibt es Zeitdruck oder verbleibende Versuche?

Besser sind Formulierungen wie:

• „Der Code ist abgelaufen. Bitte fordern Sie einen neuen Code an.“
• „Der eingegebene Code ist falsch. Sie haben noch zwei Versuche.“
• „Wir haben einen neuen Code gesendet. Bitte prüfen Sie Ihre SMS oder Authenticator-App.“

Zusätzlich wichtig:

• Fehlermeldung programmatisch mit dem Eingabefeld verknüpfen
• Statusänderungen per Screenreader ankündigen
• Ablaufzeiten nicht nur visuell oder farblich darstellen

5) Passkeys und WebAuthn sind oft nicht nur sicherer, sondern auch zugänglicher

Wenn Ihr Sicherheitsmodell es zulässt, können Passkeys auf Basis von WebAuthn eine bessere Alternative zu manuell übertragenen Einmalcodes sein. Sie reduzieren Transkriptionsaufwand, vermeiden Tippfehler und nutzen bekannte Betriebssystem-Dialoge.

Wichtig ist aber: Passkeys ersetzen schlechte UX nicht automatisch. Prüfen Sie trotzdem:

• ist die Option verständlich benannt?
• gibt es einen klaren Fallback?
• bleibt der Fokus stabil, wenn ein Systemdialog geöffnet und geschlossen wird?
• ist ersichtlich, welches Verfahren gerade aktiv ist?

Ein gutes Muster für otp eingabefelder barrierefrei

Wenn Sie kurzfristig eine belastbare Lösung brauchen, orientieren Sie sich an diesem Muster:

• ein OTP-Feld statt sechs Einzelinputs
• sichtbares Label, zum Beispiel „Einmalcode“
• kurzer Hilfetext, etwa „Geben Sie den 6-stelligen Code aus Ihrer App oder SMS ein“
• inputmode="numeric" nur wenn passend, aber keine unnötige Restriktion
• autocomplete="one-time-code"
• Paste erlaubt
• Fehlermeldung unter dem Feld, programmatisch verknüpft
• klarer Link oder Button „Neuen Code senden“
• alternativer Weg wie Passkey, Backup-Code oder anderes Verfahren
• sichtbarer Fokus in jedem Schritt

Das ist meist deutlich robuster als animierte OTP-Widgets mit viel JavaScript-Magie.

Quick-Review für Product, Design und Entwicklung

Nehmen Sie diese Fragen in Ihr Review oder Ihre Definition of Done auf:

1. Funktioniert der komplette 2FA-Flow ohne Maus?
2. Ist jederzeit klar sichtbar, wo der Fokus liegt?
3. Lassen sich Codes vollständig einfügen?
4. Unterstützt der Flow AutoFill oder Passwortmanager sinnvoll?
5. Hat jedes relevante Bedienelement einen verständlichen Namen?
6. Sind Fehlermeldungen konkret und technisch verknüpft?
7. Gibt es keinen unnötigen Zwang zur manuellen Transkription?
8. Ist „Code erneut senden“ klar erreichbar?
9. Gibt es einen verständlichen Fallback oder eine alternative Anmeldemethode?
10. Haben Sie den Flow mindestens einmal mit Screenreader und auf Mobilgeräten getestet?

Wenn Sie bei drei oder mehr Punkten unsicher sind, sollten Sie die Authentifizierungsstrecke priorisiert überarbeiten.

Typische Stolperfallen in Kundenportalen

Gerade in SaaS- und Portalumgebungen sehen wir immer wieder dieselben Muster:

• 2FA wird in einem Modal geöffnet, das den Fokus nicht sauber hält
• der Code-Dialog ist mobil schwer zoombar oder schneidet Hinweise ab
• „Code erneut senden“ ist erst nach Countdown sichtbar
• Fallbacks wie E-Mail oder Recovery-Codes sind schlechter zugänglich als der Hauptweg
• Sicherheitseinstellungen im Profil sind komplexer und schlechter beschriftet als der erste Login

Wenn Ihr 2FA-Schritt in Dialogen oder Layern läuft, prüfen Sie ergänzend auch unsere Anleitung zur Vermeidung von Tastaturfallen in Modals.

Fazit: accessible authentication ist ein Conversion- und Risikothema

Eine sichere Anmeldung muss nicht umständlich sein. Im Gegenteil: Die besten 2FA-Lösungen sind meistens die, die Sicherheit und Nutzbarkeit zusammen denken. Für BFSG-relevante Portale lohnt sich die Priorisierung besonders, weil Login-Hürden den gesamten Service faktisch unzugänglich machen können.

Wenn Sie schnell Wirkung erzielen wollen, starten Sie mit drei Punkten: OTP-Feld vereinfachen, Paste und AutoFill erlauben, Fehler und Fallbacks verständlich machen. Danach prüfen Sie, ob Passkeys oder WebAuthn für Ihren Anwendungsfall die robustere Lösung sind.

CTA: Prüfen Sie Ihren Login, Ihre Formulare und kritischen Nutzerpfade strukturiert auf BFSG- und WCAG-Risiken mit unserem BFSG-Scan.

Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Rechtsberatung.

Quellen

• W3C/WAI, Understanding Success Criterion 3.3.8 Accessible Authentication (Minimum)
• W3C/WAI, Understanding Success Criterion 3.3.9 Accessible Authentication (Enhanced)
• W3C, Web Authentication: An API for accessing Public Key Credentials Level 2
• MDN, HTML attribute: autocomplete
• MDN, One-time passwords in forms
• Bundesfachstelle Barrierefreiheit, FAQ zu Dienstleistungen im elektronischen Geschäftsverkehr
• Gesetze im Internet, Barrierefreiheitsstärkungsgesetz (BFSG)