WCAG 3.3.8: Barrierefreie Authentifizierung (Minimum)

WCAG 3.3.8 verlangt, dass Authentifizierungsprozesse nicht auf Tests der kognitiven Fähigkeiten beruhen – wie das Merken von Passwörtern, das Lösen von Rätseln oder das Abschreiben von Zeichen –, es sei denn, es steht eine alternative Methode oder Unterstützung zur Verfügung. Dies schützt Nutzer mit kognitiven Beeinträchtigungen davor, von digitalen Diensten ausgeschlossen zu werden.

Was diese Regel bedeutet

WCAG 3.3.8 Accessible Authentication (Minimum) ist ein Kriterium der Stufe AA, das in WCAG 2.2 eingeführt wurde. Es besagt, dass ein kognitiver Funktionstest – definiert als eine Aufgabe, die von einer Nutzerin oder einem Nutzer verlangt, sich Informationen zu merken, sie zu manipulieren oder zu transkribieren – nicht das einzige Mittel sein darf, um einen Authentifizierungsschritt abzuschließen, es sei denn, mindestens eine der folgenden Bedingungen ist erfüllt:

Alternative Methode: Es steht ein anderer Authentifizierungsweg zur Verfügung, der nicht auf einem kognitiven Funktionstest beruht (zum Beispiel ein Magic Link per E-Mail, biometrischer Login oder ein Passkey).
Mechanismus zur Unterstützung: Dem User Agent oder einem Drittanbieter-Tool ist es erlaubt, den Schritt im Namen der Nutzerin oder des Nutzers zu erledigen – zum Beispiel ein Passwortmanager, der Zugangsdaten automatisch ausfüllt, oder eine Copy-and-paste-Aktion für einen Einmalcode.
Ausnahme für Objekterkennung: Der kognitive Funktionstest besteht darin, ein Objekt in einem Bild zu identifizieren (zum Beispiel das Auswählen aller Bilder, die eine Ampel enthalten) – diese Art von Test ist auf der Mindeststufe (AA) zulässig.
Ausnahme für persönliche Inhalte: Der Test stützt sich auf Inhalte, die die Nutzerin oder der Nutzer selbst bereitgestellt hat, etwa das Auswählen eines zuvor hochgeladenen Fotos aus einem Raster.

Praktisch bedeutet das: Ein Login-Formular, das nur Benutzername und Passwort verlangt, erfüllt dieses Kriterium, sofern das Formular Browser-Autofill und Passwortmanager zulässt (d. h. die Felder verwenden standardmäßige <input type='password'>-Elemente und blockieren Einfügen nicht). Ein CAPTCHA, das das Abschreiben verzerrten Textes verlangt, ohne eine alternative Authentifizierungsroute anzubieten, ist ein klarer Verstoß. Ein CAPTCHA, das Nutzerinnen und Nutzer auffordert, Bilder auszuwählen, die zu einer Kategorie passen (Objekterkennung), ist auf AA-Ebene zulässig, wird aber auf AAA-Ebene (3.3.9) strenger behandelt.

Das Kriterium gilt für alle Schritte eines Authentifizierungsprozesses: initialer Login, Step-up-Authentifizierung, Multi-Faktor-Verifizierung, Kontowiederherstellung und Sitzungs-Re-Authentifizierung. Es gilt außerdem für jeden Prozess, der den Zugang zu Funktionalität schützt, nicht nur für den primären Anmeldebildschirm.

Eine wichtige technische Konsequenz ist, dass Entwicklerinnen und Entwickler autocomplete='off' bei Authentifizierungsfeldern nicht verwenden dürfen, das Einfügen per JavaScript-Event-Handler nicht deaktivieren dürfen und die standardmäßige Eingabesemantik, die Assistive Technologien und Browser-Autofill korrekt funktionieren lässt, nicht aufbrechen dürfen.

Warum das wichtig ist

Authentifizierung ist das Tor zu nahezu jedem digitalen Dienst, auf den Menschen täglich angewiesen sind – Banking, Gesundheitsportale, staatliche Dienste, E-Commerce und Kommunikationsplattformen. Wenn dieses Tor kognitive Hürden aufbaut, schließt es systematisch einen erheblichen Teil der Bevölkerung aus.

Kognitive Beeinträchtigungen umfassen ein breites Spektrum: Dyslexie, Dyskalkulie, Aufmerksamkeitsdefizitstörungen, erworbene Hirnverletzungen, Demenz, intellektuelle Beeinträchtigungen und Angststörungen. Die Weltgesundheitsorganisation schätzt, dass weltweit etwa 1 von 6 Menschen eine Form einer erheblichen Behinderung erlebt, und kognitive sowie neurologische Erkrankungen stellen eine der größten Kategorien dar. Für diese Nutzerinnen und Nutzer können Aufgaben wie das genaue Abschreiben einer Zeichenfolge verzerrter Zeichen, das Lösen eines visuellen Puzzles unter Zeitdruck oder das Hin- und Herwechseln zwischen einer Authenticator-App und einem Login-Formular tatsächlich unmöglich oder zutiefst erschöpfend sein.

Betrachten wir ein konkretes Szenario: Eine Person mit Dyslexie versucht, sich in ihr Krankenversicherungsportal einzuloggen, um Testergebnisse einzusehen. Die Website präsentiert ein Text-CAPTCHA ohne Audio-Alternative und ohne Möglichkeit, es zu umgehen. Die verzerrten Buchstabenformen sind für diese Person nicht zu unterscheiden, und das Eingabefeld blockiert Einfügen. Nach mehreren fehlgeschlagenen Versuchen wird das Konto gesperrt. Die Person kann nicht auf zeitkritische medizinische Informationen zugreifen. Das ist kein hypothetischer Randfall – es ist eine Routineerfahrung für Millionen von Menschen.

Auch motorisch beeinträchtigte Nutzerinnen und Nutzer, die auf Switch-Zugriff oder Eye-Tracking-Geräte angewiesen sind, sind betroffen. Das erneute Eintippen eines komplexen Einmalpasscodes von einem separaten Gerät oder das Ziehen von Bildkacheln in eine bestimmte Reihenfolge kann mit diesen Eingabemethoden physisch unmöglich sein. Das Zulassen von Copy-and-paste oder passkey-basierter Authentifizierung beseitigt diese Barriere vollständig.

Ältere Erwachsene stellen eine weitere bedeutende Gruppe dar. Altersbedingter kognitiver Abbau beeinträchtigt Gedächtnis und Verarbeitungsgeschwindigkeit, wodurch komplexe CAPTCHAs und mehrstufige Merkaufgaben unverhältnismäßig schwierig werden. Da die Bevölkerung in der Türkei und weltweit altert, wird das geschäftliche und regulatorische Argument für barrierefreie Authentifizierung jedes Jahr stärker.

Aus Sicht von Usability und Conversion erhöht Reibung in Authentifizierungsabläufen direkt die Abbruchraten. E-Commerce-Plattformen, die Text-CAPTCHAs durch risikobasierte Authentifizierung oder Passkeys ersetzen, berichten durchweg von höheren Login-Abschlussraten und geringeren Supportkosten im Zusammenhang mit gesperrten Konten.

Wie man testet

Automatischer Scan (axe DevTools / Lighthouse): Führen Sie axe DevTools auf jeder Authentifizierungsseite aus (Login, Registrierung, Kontowiederherstellung, MFA). Achten Sie auf autocomplete-valid-Verstöße bei Benutzername- und Passwortfeldern. Prüfen Sie in Lighthouse den Accessibility-Audit auf formularbezogene Probleme. Beachten Sie, dass keine automatisierte Regel einen 3.3.8-Verstoß eindeutig kennzeichnet – automatisierte Ergebnisse sind nur ein Ausgangspunkt.
Alle kognitiven Funktionstests identifizieren: Erfassen Sie manuell jeden Schritt im Authentifizierungsflow. Notieren Sie jeden Schritt, der von der Nutzerin oder dem Nutzer verlangt, Informationen abzurufen, die auf dem aktuellen Bildschirm nicht bereitgestellt werden, Zeichen zu transkribieren, ein Puzzle zu lösen oder eine Berechnung durchzuführen. Prüfen Sie, ob jeder dieser Schritte eine konforme Alternative hat (Objekterkennung, persönliche Inhalte, alternative Login-Methode oder unterstützender Mechanismus).
Einfügefunktionalität testen: Versuchen Sie bei jeder Authentifizierungseingabe (Benutzername, Passwort, OTP, Wiederherstellungscode), Text mithilfe der Tastenkombination einzufügen (Strg+V unter Windows/Linux, Cmd+V unter macOS). Bestätigen Sie, dass der eingefügte Inhalt im Feld erscheint. Wiederholen Sie dies über das Kontextmenü per Rechtsklick. Wenn Einfügen blockiert wird, ist dies ein Verstoß, sofern keine kognitionsfreie Alternative existiert.
Autofill mit einem Passwortmanager testen: Verwenden Sie einen Browser mit Passwortmanager (nativ oder als Erweiterung), speichern Sie Zugangsdaten während der Registrierung und kehren Sie dann zur Login-Seite zurück. Bestätigen Sie, dass der Passwortmanager die Felder erkennen und automatisch ausfüllen kann. Testen Sie in Firefox mit NVDA, Safari mit VoiceOver (macOS/iOS) und Chrome mit JAWS, um wichtige Kombinationen aus Assistiver Technologie und Browser abzudecken. Wenn die Felder nicht standardmäßiges Markup verwenden oder JavaScript automatisch ausgefüllte Werte löscht, ist dies ein Verstoß.
NVDA + Firefox – Screenreader-Durchlauf: Navigieren Sie das Login-Formular ausschließlich mit der Tastatur und NVDA. Bestätigen Sie, dass jedes Feld erreichbar ist, dass Feldbeschriftungen korrekt angesagt werden und dass jedes CAPTCHA-Widget eine barrierefreie Alternative hat. Wenn das CAPTCHA rein visuell ist, ohne Audio-Option und ohne alternative Login-Route, vermerken Sie einen Verstoß.
VoiceOver + Safari (iOS): Versuchen Sie auf einem mobilen Gerät, sich mit Face ID oder Touch ID anzumelden, sofern die Website biometrischen Login anbietet. Bestätigen Sie, dass die biometrische Option per Wischnavigation erreichbar ist und von VoiceOver korrekt angesagt wird. Dies stellt sicher, dass eine kognitionsfreie Alternative praktisch zugänglich ist und nicht nur nominell vorhanden.
Auf Zeitlimits bei kognitiven Schritten prüfen: Wenn ein CAPTCHA oder eine OTP-Eingabe ein Zeitlimit auferlegt, prüfen Sie, ob die Nutzerin oder der Nutzer es verlängern oder deaktivieren kann (relevant für 2.2.1), und vermerken Sie separat, ob der zeitlich begrenzte Schritt einen kognitiven Funktionstest ohne Alternative darstellt.

Wie man es behebt

Text-CAPTCHA ohne Alternative – falsch

<!-- Fails 3.3.8: only authentication method is transcribing distorted text;
     no alternative login path is offered, and paste is disabled -->
<form action='/login' method='post'>
  <label for='user'>Username</label>
  <input type='text' id='user' name='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='off'
         onpaste='return false;'>

  <img src='/captcha-image.png' alt=''>
  <label for='captcha'>Type the characters above</label>
  <input type='text' id='captcha' name='captcha'
         autocomplete='off'
         onpaste='return false;'>

  <button type='submit'>Log in</button>
</form>

Text-CAPTCHA ohne Alternative – korrekt

<!-- Passes 3.3.8: text CAPTCHA is replaced with a passkey / magic-link option;
     password field supports autofill and paste so password managers can assist -->
<form action='/login' method='post'>
  <label for='user'>Username or email</label>
  <input type='text' id='user' name='username'
         autocomplete='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='current-password'>

  <!-- No CAPTCHA; bot protection handled server-side via risk-based signals -->
  <button type='submit'>Log in</button>
</form>

<!-- Cognitive-function-free alternative always visible -->
<p><a href='/magic-link'>Send me a sign-in link by email instead</a></p>
<p><a href='/passkey-login'>Sign in with a passkey or biometrics</a></p>

OTP-Feld blockiert Einfügen – falsch

<!-- Fails 3.3.8: user must manually type a 6-digit OTP;
     paste is suppressed, forcing a transcription task -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='off'
       onpaste='event.preventDefault();'
       ondrop='event.preventDefault();'>

OTP-Feld blockiert Einfügen – korrekt

<!-- Passes 3.3.8: paste and autofill are permitted;
     autocomplete='one-time-code' enables OS-level SMS/OTP autofill on mobile -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='one-time-code'>
<!-- Remove all paste/drop prevention handlers.
     Risk of credential stuffing is managed server-side, not by blocking paste. -->

Bildauswahl-CAPTCHA ohne Fallback (AAA-Thema, AA-konform) – korrekt auf AA

<!-- Passes 3.3.8 (AA): object recognition CAPTCHAs are explicitly
     exempted at the Minimum level. Selecting images of bicycles
     qualifies as object recognition, not character transcription.
     Note: this would fail 3.3.9 (AAA) — provide an alternative for full conformance. -->
<fieldset>
  <legend>Select all images that contain a bicycle</legend>
  <ul role='list'>
    <li>
      <input type='checkbox' id='img1' name='captcha' value='1'>
      <label for='img1'>
        <img src='/grid/img1.jpg' alt='A city street with parked vehicles'>
      </label>
    </li>
    <!-- additional grid items -->
  </ul>
</fieldset>

Häufige Fehler

Setzen von autocomplete='off' bei Passwortfeldern: Dies deaktiviert das automatische Ausfüllen durch Passwortmanager und entfernt den unterstützenden Mechanismus, der Standard-Passwortauthentifizierung konform macht. Verwenden Sie stattdessen autocomplete='current-password' und überlassen Sie dem Browser die Verwaltung der Zugangsdaten.
Blockieren von Einfügen mit onpaste='return false;' oder addEventListener('paste', e => e.preventDefault()): Dies zwingt Nutzerinnen und Nutzer, Zugangsdaten manuell einzugeben, und erzeugt eine nicht barrierefreie Transkriptionsaufgabe. Entfernen Sie alle Handler zur Verhinderung von Einfügen aus Authentifizierungsfeldern.
Anbieten einer Passkey-Option, die nicht tastaturbedienbar ist: Eine biometrische Alternative erfüllt 3.3.8 nur, wenn sie über Tastatur und Assistive Technologien erreichbar und bedienbar ist. Eine Passkey-Schaltfläche, die hinter einem Hover-Menü versteckt ist oder als nicht fokussierbares <div> gerendert wird, zählt nicht als konforme Alternative.
Verwendung eines Text-CAPTCHAs als einzige Bot-Schutzstrategie: Der Umstieg auf risikobasierte, serverseitige Bot-Erkennung (Analyse von Geräte-Fingerabdruck, Tippverhalten, IP-Reputation) eliminiert den kognitiven Funktionstest vollständig, ohne die Sicherheit zu beeinträchtigen. Sich ausschließlich auf clientseitige CAPTCHAs zu verlassen, ist sowohl ein Barrierefreiheitsverstoß als auch eine schlechte Sicherheitspraktik.
Aufteilen eines OTP in mehrere Einzelzeichenfelder und Blockieren von feldübergreifendem Einfügen: Manche Implementierungen verwenden sechs separate <input maxlength='1'>-Felder für die OTP-Eingabe und lassen den Fokus per JavaScript automatisch weiterspringen. Dieses Muster verhindert regelmäßig das Einfügen aus Passwortmanagern und verstößt gegen 3.3.8, sofern die Implementierung nicht ausdrücklich das Einfügen eines vollständigen Codes in das erste Feld unterstützt und die Zeichen korrekt verteilt.
Verlangen eines bildbasierten CAPTCHAs nur bei Kontowiederherstellungsflows: Teams fügen häufig barrierefreie Login-Alternativen zur Haupt-Login-Seite hinzu, vergessen aber Step-up-Authentifizierung, Passwortzurücksetzung und Kontofreischaltung. Jeder dieser Schritte ist ein eigener Authentifizierungsschritt und muss unabhängig 3.3.8 erfüllen.
Audio-CAPTCHA als vollständige Alternative zu Text-CAPTCHA behandeln: Eine Audio-Alternative hilft blinden Nutzerinnen und Nutzern, aber nicht Menschen mit kognitiven Beeinträchtigungen oder Personen in lauten Umgebungen. Audio-CAPTCHAs bringen außerdem ihre eigene Transkriptionsanforderung mit sich. Die richtige Lösung ist, das CAPTCHA zu eliminieren oder einen Weg zu bieten, der überhaupt keinen kognitiven Funktionstest enthält.
Dynamisches Generieren von Eingabefeld-IDs, das die Erkennung durch Passwortmanager stört: Wenn id-Attribute von Benutzername- und Passwortfeldern bei jedem Seitenaufruf randomisiert werden (eine fehlgeleitete Anti-Bot-Technik), können Passwortmanager die Felder nicht zuverlässig identifizieren. Dies deaktiviert Autofill faktisch und entfernt den konformen unterstützenden Mechanismus.
Annahme, dass Drittanbieter-CAPTCHA-Widgets automatisch konform sind: Beliebte CAPTCHA-Dienste können barrierefreie Varianten anbieten, diese sind jedoch nicht standardmäßig aktiviert. Entwicklerinnen und Entwickler müssen die barrierefreie Version ausdrücklich konfigurieren und dennoch prüfen, ob sie die Anforderungen des Standards erfüllt, statt einfach eine neue Art eines nicht barrierefreien Tests hinzuzufügen.
Löschen automatisch ausgefüllter Werte per JavaScript beim Fokus: Manche Formulare löschen Eingabewerte, wenn ein Feld den Fokus erhält, um Platzhaltertext anzuzeigen oder zur erneuten Eingabe aufzufordern. Wenn dieses Verhalten einen vom Passwortmanager automatisch ausgefüllten Wert löscht, erzwingt es eine manuelle Neueingabe und verstößt gegen 3.3.8.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt Web- und Mobile-Barrierefreiheitsverpflichtungen fest, die sich an WCAG 2.2 orientieren. Die Verfügung verlangt von den erfassten Stellen, Konformität der Stufe AA über ihre digitalen Produkte und Dienstleistungen hinweg zu erreichen. WCAG 3.3.8 ist als Kriterium der Stufe AA in WCAG 2.2 daher direkt im Geltungsbereich der verbindlichen Compliance-Anforderungen, die durch diese Verfügung eingeführt wurden.

Die Verfügung umfasst ein breites Spektrum privater und öffentlicher Stellen. Öffentliche Institutionen und Regierungsbehörden müssen vollständige AA-Konformität erreichen. Im Privatsektor gilt die Verfügung für E-Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsanbieter mit 200,000 oder mehr Abonnentinnen und Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind. Für diese Organisationen schaffen nicht barrierefreie Authentifizierungsabläufe – etwa Login-Seiten mit nicht unterstützten CAPTCHAs oder OTP-Felder, die Einfügen blockieren – ein direktes regulatorisches Risiko.

Das Barrierefreiheitslogo (Erişilebilirlik Logosu), herausgegeben vom Ministerium für Familie und Sozialdienste, ist das offizielle Zertifizierungszeichen für digitale Barrierefreiheitskonformität in der Türkei. Der Erhalt dieses Logos erfordert nachgewiesene Konformität der Stufe AA, die 3.3.8 einschließt. Für E-Commerce-Betreiber, Banken und andere stark frequentierte digitale Dienstanbieter dient das Logo als öffentliches Vertrauenssignal und kann in Beschaffungs- und Ausschreibungsanforderungen referenziert werden. Authentifizierungsabläufe, die auf nicht barrierefreien kognitiven Tests beruhen, würden die Zertifizierung verhindern und die Organisation Beschwerden und Durchsetzungsmaßnahmen aussetzen.

Aus praktischer Compliance-Perspektive sollten türkische Organisationen jeden Authentifizierungskontaktpunkt – einschließlich Login, Registrierung, MFA, Passwortzurücksetzung und Kontofreischaltung – vor der Einreichung zur Barrierefreiheitslogo-Bewertung gegen 3.3.8 prüfen. Das Ersetzen von Text-CAPTCHAs durch risikobasierte serverseitige Kontrollen, das Aktivieren von autocomplete bei allen Zugangsdatenfeldern und das Anbieten von Passkey- oder Magic-Link-Alternativen sind die wirkungsvollsten Maßnahmen zur Behebung. Diese Änderungen erfüllen gleichzeitig die regulatorische Anforderung und verbessern das Authentifizierungserlebnis für die geschätzten 8.5 Millionen Menschen mit Behinderungen in der Türkei, die digitale Dienste nutzen.