WCAG 3.3.9: Barrierefreie Authentifizierung (Erweitert)

Was diese Regel bedeutet

WCAG 3.3.9 — Accessible Authentication (Enhanced) ist das AAA-Pendant zu WCAG 3.3.8 (Accessible Authentication — Minimum, AA). Zusammen bilden sie ein Kriterienpaar, das in WCAG 2.2 eingeführt wurde, um sicherzustellen, dass der Prozess des Nachweises der Identität gegenüber einer Website oder Anwendung selbst nicht zu einer Barriere für die Barrierefreiheit wird.

Auf AAA-Niveau verschärft 3.3.9 die Anforderungen erheblich. Das Kriterium lautet: Ein kognitiver Funktionstest darf für keinen Schritt in einem Authentifizierungsprozess erforderlich sein, es sei denn, dieser Schritt bietet mindestens eines der folgenden: eine alternative Authentifizierungsmethode, die nicht auf einem kognitiven Funktionstest beruht; ein Mechanismus ist verfügbar, um den Nutzer bei der Durchführung des kognitiven Funktionstests zu unterstützen; oder der kognitive Funktionstest besteht im Erkennen von Objekten. Entscheidend ist, dass im Gegensatz zur AA-Version (3.3.8) das AAA-Kriterium die Ausnahme entfernt, die das Erkennen von Nicht-Objekt-Inhalten erlaubte (wie z. B. Bilder von Nicht-Objekt-Elementen, die ein Nutzer zuvor ausgewählt hat). Auf diesem Niveau ist nur echtes Objekterkennen — das Erkennen gängiger realer Objekte wie Bilder einer Katze, eines Fahrrads oder eines Hauses — als kognitiver Funktionstest zulässig, und nur, wenn die anderen Bedingungen nicht erfüllt sind.

Ein kognitiver Funktionstest ist definiert als jede Aufgabe, die vom Nutzer verlangt, Informationen zu merken, zu manipulieren oder zu transkribieren. Dazu gehören: sich einen Benutzernamen oder ein Passwort zu merken, ein mathematisches Rätsel zu lösen, ein CAPTCHA mit verzerrtem Text zu entschlüsseln, eine Sicherheitsfrage zur persönlichen Historie zu beantworten (z. B. „Wie hieß Ihr erstes Haustier?“) oder eine Zeichenfolge zu transkribieren. All dies sind Gedächtnis- oder Transkriptionsaufgaben, die viele Nutzer nicht zuverlässig ausführen können.

Was als bestanden gilt: Ein Authentifizierungsschritt besteht 3.3.9, wenn er keinen kognitiven Funktionstest erfordert oder wenn eine der folgenden Bedingungen erfüllt ist: (1) Es wird ein vollständig separater, nicht-kognitiver Authentifizierungspfad angeboten (z. B. ein Magic Link per E-Mail, WebAuthn/Passkey, biometrischer Login); (2) ein Mechanismus unterstützt die Durchführung des Tests (z. B. der Passwortmanager des Browsers wird nicht blockiert oder Copy & Paste ist erlaubt); oder (3) der einzige beteiligte kognitive Test besteht darin, ein gängiges reales Objekt aus einer Menge von Bildern zu erkennen.

Was als nicht bestanden gilt: Jeder Ablauf, der den Nutzer — ohne Umgehungsmöglichkeit oder Alternative — dazu zwingt, ein Passwort aus dem Gedächtnis abzurufen, einen Code zu transkribieren, der nicht eingefügt werden kann, ein visuelles oder Audio-CAPTCHA ohne Alternative zu lösen, wissensbasierte Sicherheitsfragen zu beantworten oder zuvor ausgewählte Bilder von Nicht-Objekt-Inhalten (z. B. abstrakte Formen oder persönliche Fotos) ohne alternativen Authentifizierungspfad zu identifizieren.

Offizielle Ausnahmen: Die WCAG-Spezifikation selbst stellt fest, dass das Erkennen von Objekten (Fotografien realer Dinge) die einzige Bild-Erkennungsaufgabe ist, die auf diesem AAA-Niveau zulässig ist. Das AA-Kriterium (3.3.8) erlaubte auch das Erkennen „nicht-objektbezogener“ persönlich ausgewählter Bilder, aber 3.3.9 entfernt diese Ausnahme vollständig. Es gibt keine Ausnahme für „weit verbreitete“ Authentifizierungsmuster — wenn ein Muster einen kognitiven Test ohne Alternative erfordert, fällt es bei 3.3.9 durch.

Warum es wichtig ist

Die Authentifizierung ist häufig die erste bedeutungsvolle Interaktion, die ein Nutzer mit einem digitalen Dienst hat. Wenn diese Interaktion selbst nicht barrierefrei ist, wird die restliche Barrierefreiheit der Website irrelevant — der Nutzer kommt überhaupt nicht zur Tür herein. WCAG 3.3.9 adressiert diese Barriere direkt, und seine Auswirkungen betreffen eine breite Palette von Personengruppen mit Behinderungen.

Nutzer mit kognitiven Beeinträchtigungen — einschließlich Menschen mit Dyslexie, ADHS, traumatischer Hirnverletzung, Demenz oder Lernschwierigkeiten — können es extrem schwierig oder unmöglich finden, komplexe Passwörter zu memorieren, zeitlich begrenzte Einmalcodes manuell zu transkribieren oder verzerrten CAPTCHA-Text zu entschlüsseln. Die Weltgesundheitsorganisation schätzt, dass etwa 1 von 6 Menschen weltweit irgendeine Form einer erheblichen Behinderung erlebt, und kognitive Beeinträchtigungen stellen eine der größten und am wenigsten bedienten Kategorien in der Web-Barrierefreiheit dar.

Nutzer mit motorischen Beeinträchtigungen — wie Menschen mit Parkinson, essenziellem Tremor, Rückenmarksverletzungen oder Bedingungen, die Schaltersteuerung oder Blicksteuerung erfordern — können Schwierigkeiten haben, Passwörter präzise einzugeben oder Codes Zeichen für Zeichen zu transkribieren. Das Blockieren des Einfügens aus der Zwischenablage (eine gängige Anti-Betrugs-Maßnahme, die aktiv schädlich ist) bedeutet, dass diese Nutzer jeden einzelnen Buchstaben mühsam über ihr Hilfsmittel eingeben müssen, was die Fehlerrate und Ermüdung drastisch erhöht.

Nutzer, die blind sind oder eine Sehbehinderung haben, sind möglicherweise vollständig auf Screenreader oder Vergrößerungswerkzeuge angewiesen. Visuelle CAPTCHAs sind ohne Audio-Alternative völlig unzugänglich, und selbst Audio-CAPTCHAs sind notorisch schwierig für Nutzer mit Hörbeeinträchtigungen oder auditiven Verarbeitungsstörungen. Bildbasierte Herausforderungen wie „Wählen Sie alle Ampeln aus“ können ebenfalls problematisch sein, wenn Bildbeschreibungen fehlen oder irreführend sind.

Nutzer, die taub oder schwerhörig sind, können auf Barrieren stoßen, wenn Authentifizierungsmethoden ausschließlich auf Telefonanrufen zur Zustellung von Einmalcodes beruhen, insbesondere wenn diese Anrufe nur Sprache enthalten und keine SMS-Alternative bieten.

Ein konkretes Szenario aus der Praxis: Stellen Sie sich eine 72-jährige Nutzerin mit leichter kognitiver Beeinträchtigung vor, die versucht, auf ihr Online-Banking-Portal zuzugreifen. Die Bank verlangt einen Benutzernamen (der erinnert werden muss, nicht die E-Mail-Adresse), ein komplexes Passwort (Einfügen aus der Zwischenablage ist blockiert) und ein CAPTCHA mit verzerrtem Text. Die Nutzerin scheitert zweimal am CAPTCHA, wird gesperrt und muss die Hotline der Bank anrufen — ein Prozess von 40 Minuten. Hätte die Bank Passkeys oder einen Magic Link implementiert, hätte diese Nutzerin sich in Sekunden authentifiziert. Dieses Szenario spielt sich täglich millionenfach im Web ab und ist vollständig vermeidbar.

Über Behinderungen hinaus profitieren alle Nutzer von barrierefreier Authentifizierung. Passwortmanager, die von Hunderten Millionen Menschen genutzt werden, sind auf die Möglichkeit angewiesen, Zugangsdaten einzufügen. Das Blockieren von Einfügen, das Erzwingen manueller Transkription oder das Einbetten unzugänglicher CAPTCHAs frustriert auch Mainstream-Nutzer. Es gibt auch Sicherheitsargumente: Das Erzwingen komplexer manueller Passworteingabe erhöht die Wahrscheinlichkeit, dass Nutzer einfachere, schwächere Passwörter wählen oder sie über mehrere Websites hinweg wiederverwenden. Passkeys und Magic Links, die empfohlenen Alternativen, sind sowohl barrierefreier als auch sicherer als traditionelle Passwort-plus-CAPTCHA-Abläufe.

Verwandte Axe-core-Regeln

WCAG 3.3.9 ist als nur manuell testbar klassifiziert. Ab axe-core 4.10 gibt es keine automatisierte Regel, die dieses Kriterium vollständig bewertet. Um zu verstehen, warum automatisierte Tools diese Verstöße nicht erkennen können, muss man verstehen, was das Kriterium tatsächlich misst.

• Manuelle Tests erforderlich — Erkennung kognitiver Funktionen: Automatisierte Scanner können das Vorhandensein bestimmter HTML-Elemente erkennen (wie ein <input type='password'> oder ein iframe, das ein CAPTCHA-Widget eines Drittanbieters einbettet), aber sie können nicht feststellen, ob ein vollständiger Authentifizierungs-Flow einen kognitiven Funktionstest ohne barrierefreie Alternative erfordert. Das Kriterium bezieht sich auf die gesamte Nutzerreise über möglicherweise mehrere Schritte und Seiten hinweg, nicht auf die Eigenschaften eines einzelnen Elements. Ein Scanner kann nicht bewerten, ob Einfügen programmatisch über JavaScript blockiert wird, ob ein Zeitlimit für ein Codeeingabefeld angemessen ist oder ob ein alternativer Authentifizierungspfad tatsächlich kognitive Tests vermeidet. Dies sind Verhaltens- und Architekturfragen, die eine menschliche Bewertung erfordern, indem der tatsächliche Authentifizierungsprozess durchlaufen wird.
• Manuelle Tests erforderlich — Überprüfung alternativer Pfade: Selbst wenn ein Scanner ein CAPTCHA-Widget erkennt, kann er nicht überprüfen, ob eine barrierefreie alternative Authentifizierungsmethode auf derselben Seite oder im selben Flow existiert. Er kann nicht bewerten, ob eine Option „Stattdessen mit einem Passkey anmelden“ wirklich gleichwertig ist oder ob sie in einer sekundären Einstellungsseite versteckt ist, die selbst das Bestehen des unzugänglichen CAPTCHAs erfordert. Die Bewertung der Gleichwertigkeit alternativer Pfade erfordert menschliches Urteil über Vollständigkeit und Prominenz dieser Alternativen.
• Manuelle Tests erforderlich — Verhalten beim Einfügen aus der Zwischenablage: JavaScript, das paste-Ereignisse abfängt und sie abbricht (event.preventDefault() in einem Paste-Listener), ist für die statische HTML-Analyse unsichtbar. Ein Scanner sieht ein gültiges <input>-Element; er kann nicht wissen, dass das Einfügen darin deaktiviert wurde. Nur manuelle Tests — der physische Versuch, ein Passwort oder einen Code einzufügen — können diesen Fehler aufdecken.
• Manuelle Tests erforderlich — Kompatibilität von Auth-Widgets mit Hilfstechnologien: Authentifizierungs-SDKs von Drittanbietern (Social-Login-Buttons, CAPTCHA-Anbieter, biometrische Prompts) können in iframes oder Shadow DOM gerendert werden, die automatisierte Scanner nicht vollständig durchdringen können. Manuelle Tests mit Screenreadern wie NVDA, JAWS und VoiceOver sind unerlässlich, um zu bestätigen, dass alle interaktiven Elemente innerhalb des Authentifizierungsflows bedienbar und verständlich sind.

Wie man testet

1. Alle Authentifizierungs-Einstiegspunkte identifizieren: Bevor Sie testen, erfassen Sie alle Stellen in der Anwendung, an denen ein Nutzer sich authentifizieren oder seine Identität verifizieren muss. Dazu gehören der initiale Login, die Kontoerstellung, das Zurücksetzen von Passwörtern, Zwei-Faktor-Authentifizierungsaufforderungen, Re-Authentifizierung nach Sitzungs-Timeout, Zahlungsbestätigungsseiten und Altersverifikations-Gates. Jeder dieser Abläufe muss separat bewertet werden.
2. Einen automatisierten Basisscan durchführen: Verwenden Sie axe DevTools (Browser-Erweiterung) oder Lighthouse in den Chrome DevTools auf jeder Authentifizierungsseite. Auch wenn diese Tools Verstöße gegen 3.3.9 nicht direkt kennzeichnen, machen sie verwandte Probleme sichtbar — fehlende Beschriftungen von Formularfeldern, unzugängliche iframe-Inhalte, fehlendes Fokus-Management —, die Authentifizierungsbarrieren verstärken. Notieren Sie alle markierten Probleme als Kontext für die manuelle Bewertung. In axe DevTools finden Sie im Tab „Needs Review“ Elemente, die eine manuelle Beurteilung erfordern.
3. Auf kognitive Funktionstests prüfen: Fragen Sie bei jedem Authentifizierungsschritt: Verlangt dieser Schritt vom Nutzer, (a) sich etwas zu merken, (b) etwas zu transkribieren oder (c) ein Rätsel zu lösen? Wenn ja, vergewissern Sie sich, dass mindestens eines der folgenden vorhanden und gleich prominent ist: ein nicht-kognitiver alternativer Pfad; ein Mechanismus (wie erlaubtes Einfügen aus der Zwischenablage oder ein Autofill-kompatibles Feld), der die Durchführung unterstützt; oder dass die einzige kognitive Aufgabe darin besteht, ein gängiges reales Objekt zu erkennen.
4. Verhalten beim Einfügen aus der Zwischenablage testen: Kopieren Sie in jedes Passwort- und Codeeingabefeld eine Textzeichenfolge in Ihre Zwischenablage und versuchen Sie, sie mit Strg+V (Windows/Linux) oder Cmd+V (macOS) einzufügen. Wenn Einfügen blockiert ist, ist dies ein Fehler. Testen Sie außerdem, ob das Autofill des Passwortmanagers des Browsers unterdrückt wird (prüfen Sie auf autocomplete='off' oder JavaScript, das Autofill-Werte beim Fokus löscht).
5. Mit NVDA + Firefox testen: Durchlaufen Sie den gesamten Authentifizierungsflow ausschließlich mit der Tastatur und dem Screenreader NVDA. Vergewissern Sie sich, dass alle Formularfelder mit aussagekräftigen Beschriftungen angekündigt werden, alle interaktiven Steuerelemente (Buttons, Links, CAPTCHA-Herausforderungen) erreichbar und bedienbar sind und dass Fehlermeldungen programmatisch mit dem betreffenden Feld verknüpft sind und sofort angekündigt werden, ohne dass zusätzliche Navigation erforderlich ist.
6. Mit VoiceOver + Safari (macOS/iOS) testen: Wiederholen Sie den vollständigen Authentifizierungsflow. Überprüfen Sie auf iOS außerdem, dass biometrische Authentifizierung (Face ID / Touch ID) als Alternative angeboten wird, wenn native Authentifizierung verwendet wird, und dass der webbasierte Flow vollständig mit Switch Control bedienbar ist, falls Biometrie nicht verfügbar ist.
7. Mit JAWS + Chrome testen: Wiederholen Sie den Flow und achten Sie besonders darauf, wie Widgets von Drittanbietern (OAuth-Social-Login, CAPTCHA-iframes) angekündigt werden. JAWS behandelt bestimmte ARIA-Muster anders als NVDA; beide müssen getestet werden.
8. Alternative Pfade auf echte Gleichwertigkeit prüfen: Wenn eine alternative Authentifizierungsmethode existiert (z. B. „Mit einem Magic Link anmelden“), durchlaufen Sie den gesamten Flow ausschließlich mit dieser Alternative. Bestätigen Sie, dass derselbe authentifizierte Zustand erreicht wird, ohne dass ein kognitiver Test erforderlich ist. Wenn der alternative Pfad selbst ein CAPTCHA oder einen Gedächtnistest enthält, ist er unter 3.3.9 keine gültige Alternative.
9. Ergebnisse mit Belegen dokumentieren: Erfassen Sie für jeden Fehler eine Bildschirmaufnahme oder einen annotierten Screenshot, der genau zeigt, welcher Schritt fehlschlägt und warum. Diese Dokumentation ist für die Übergabe der Behebung an Entwicklungsteams und für Prüfzwecke unerlässlich.

Wie man es behebt

CAPTCHA ohne Alternative — falsch

<!-- Fails 3.3.9: The only authentication path requires solving a visual CAPTCHA.
     No alternative is provided, and there is no object-recognition option. -->
<form method='post' action='/login'>
  <label for='username'>Username</label>
  <input type='text' id='username' name='username' autocomplete='username'>

  <label for='password'>Password</label>
  <input type='password' id='password' name='password' autocomplete='off'>

  <!-- Third-party CAPTCHA widget with no accessible alternative path -->
  <div class='g-recaptcha' data-sitekey='YOUR_SITE_KEY'></div>

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

CAPTCHA durch Passkey und Magic Link ersetzt — richtig

<!-- Passes 3.3.9: CAPTCHA removed entirely. Primary path uses a passkey
     (WebAuthn — no cognitive test). A magic link fallback is offered
     for devices without passkey support. Password entry allows paste
     and browser autofill. -->
<form method='post' action='/login'>
  <label for='email'>Email address</label>
  <input type='email' id='email' name='email' autocomplete='email'>

  <!-- Passkey login: no password to remember, no CAPTCHA -->
  <button type='button' id='passkey-btn'>Sign in with Passkey</button>

  <!-- Password fallback: paste and autofill explicitly enabled -->
  <label for='password'>Password (optional)</label>
  <input type='password' id='password' name='password'
         autocomplete='current-password'>
  <!-- NOTE: Do NOT add autocomplete='off' or paste-blocking JS here -->

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

<!-- Non-cognitive alternative: magic link -->
<p><a href='/send-magic-link'>Send me a sign-in link instead</a></p>

<script>
  // WebAuthn passkey authentication — no cognitive function test
  document.getElementById('passkey-btn').addEventListener('click', async () => {
    const credential = await navigator.credentials.get({ publicKey: publicKeyOptions });
    // submit credential to server
  });
</script>

Einfügen in OTP-Feld blockiert — falsch

<!-- Fails 3.3.9: The one-time code field blocks paste via JavaScript,
     forcing users to manually transcribe a time-limited code.
     This is a transcription cognitive function test with no bypass. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='off'>

<script>
  document.getElementById('otp').addEventListener('paste', function(e) {
    e.preventDefault(); // Blocks paste — FAILS 3.3.9
  });
</script>

OTP-Feld mit aktiviertem Einfügen und Autocomplete-Hinweis — richtig

<!-- Passes 3.3.9: Paste is allowed. The autocomplete='one-time-code' attribute
     enables browsers and password managers to automatically fill the OTP,
     eliminating the transcription requirement entirely. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='one-time-code'>

<!-- No paste-blocking JavaScript. autocomplete='one-time-code' allows
     the OS (iOS, Android, desktop browsers) to suggest the OTP
     automatically from SMS or authenticator apps. -->

Wissensbasierte Sicherheitsfragen — falsch

<!-- Fails 3.3.9: Requiring answers to knowledge-based security questions
     is a memory-recall cognitive function test. No alternative is offered. -->
<form method='post' action='/verify-identity'>
  <p>To verify your identity, please answer your security question:</p>
  <label for='sq-answer'>What was the name of your childhood pet?</label>
  <input type='text' id='sq-answer' name='sq-answer' autocomplete='off'>
  <button type='submit'>Verify</button>
</form>

Identitätsprüfung mit nicht-kognitiven Alternativen — richtig

<!-- Passes 3.3.9: Security questions replaced with email magic link
     and government ID upload options — neither requires memory recall.
     If security questions are retained for some users, a clearly labeled
     alternative path is provided upfront. -->
<form method='post' action='/verify-identity'>
  <p>We need to verify your identity. Choose one of the following methods:</p>

  <fieldset>
    <legend>Verification method</legend>

    <label>
      <input type='radio' name='verify-method' value='magic-link' checked>
      Send a verification link to my registered email
    </label>

    <label>
      <input type='radio' name='verify-method' value='id-upload'>
      Upload a photo of a government-issued ID
    </label>
  </fieldset>

  <button type='submit'>Continue</button>
</form>

Häufige Fehler

• Hinzufügen von autocomplete='off' zu Passwortfeldern, um Browser-Autofill zu verhindern. Dies deaktiviert den primären Mechanismus, der es Nutzern ermöglicht, das Merken von Passwörtern zu vermeiden, und verstößt direkt gegen 3.3.9. Entfernen Sie autocomplete='off' und verwenden Sie stattdessen autocomplete='current-password' oder autocomplete='new-password'.
• Anhängen eines JavaScript-paste-Event-Listeners, der event.preventDefault() aufruft bei Authentifizierungs-Eingabefeldern, in der Annahme, dies erhöhe die Sicherheit. In Wirklichkeit blockiert es Passwortmanager und Hilfstechnologien und stellt eine Transkriptionsanforderung im Sinne von 3.3.9 dar.
• Die Audio-CAPTCHA-Alternative als ausreichende Umgehung für visuelle CAPTCHAs behandeln. Audio-CAPTCHAs sind weiterhin ein kognitiver Funktionstest (Transkription verzerrter Audiozeichen) und erfüllen 3.3.9 nicht. Ein wirklich nicht-kognitiver alternativer Pfad ist erforderlich.
• Anbieten einer Passkey- oder Social-Login-Option, diese aber hinter einem CAPTCHA zu verstecken. Wenn der Nutzer einen kognitiven Test bestehen muss, um auf die barrierefreie Alternative zuzugreifen, ist die Alternative nicht wirklich gleichwertig und der Flow verstößt gegen 3.3.9.
• Verwendung von sechs separaten einstelligen <input>-Feldern für die OTP-Eingabe (ein gängiges UI-Muster), ohne das Einfügen zum Ausfüllen über alle Felder zu unterstützen. Viele Implementierungen fügen nur in das erste Feld ein und erfordern manuelle Eingabe für die restlichen fünf, was eine Transkriptionsbarriere darstellt.
• Verlassen auf „Angemeldet bleiben“ oder persistente Session-Cookies als einzige Unterstützung für Nutzer, die sich nicht wiederholt authentifizieren können. Auch wenn die Verringerung der Authentifizierungshäufigkeit hilft, behebt sie keinen unzugänglichen Authentifizierungsprozess — Nutzer müssen den kognitiven Test mindestens einmal bestehen, und Sitzungen laufen ab oder werden gelöscht.
• Implementierung zeitlich begrenzter OTP-Felder, die nach Ablauf ohne Warnung geleert werden, wodurch Nutzer gezwungen sind, einen neuen Code anzufordern und die Transkription erneut zu versuchen. Dies verstärkt die kognitive Belastung für Nutzer mit langsamer motorischer oder kognitiver Verarbeitungsgeschwindigkeit.
• Verwendung bildbasierter CAPTCHA-Herausforderungen, die das Erkennen von Nicht-Objekt-Inhalten erfordern — wie abstrakte Muster, Farben oder Sequenzen persönlich ausgewählter Fotos — in der Annahme, dies erfülle 3.3.9. Das AAA-Kriterium erlaubt nur Objekterkennung (reale Objekte wie Autos, Fahrräder, Ampeln); die Erkennung von Nicht-Objekt-Bildern ist auf diesem Niveau nicht ausgenommen.
• Blockieren des Zugriffs auf den Credential Manager des Browsers über autocomplete='new-password' in Login-Feldern (anstatt in Registrierungsfeldern). Der Wert new-password signalisiert Browsern, dass es sich um ein Feld zur Erstellung eines neuen Passworts handelt, und verhindert das Autofill gespeicherter Zugangsdaten beim Login.
• Unterlassen, Authentifizierungsabläufe mit tatsächlichen Hilfstechnologien zu testen und sich stattdessen ausschließlich auf automatisierte Scan-Ergebnisse zu verlassen. Da 3.3.9 nur manuell testbar ist, werden Teams, die manuelle Screenreader- und Tastaturtests auslassen, systematisch Verstöße gegen dieses Kriterium in jedem Release-Zyklus übersehen.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung Nr. 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt umfassende Web- und Mobile-Barrierefreiheitsverpflichtungen für eine breite Palette öffentlicher und privater Einrichtungen fest, die in der Türkei tätig sind. Die Verfügung schreibt die Konformität mit WCAG 2.2 vor und ist damit das erste türkische Rechtsinstrument, das ausdrücklich auf die Version 2.2 des Standards Bezug nimmt.

Zu den von der Verfügung erfassten Einrichtungen gehören: öffentliche Institutionen und Behörden auf allen Ebenen der Regierung; E-Commerce-Plattformen und Online-Marktplätze; Banken und Finanzinstitute; Krankenhäuser und Gesundheitsdienstleister; Telekommunikationsbetreiber mit 200.000 oder mehr Abonnenten; Reisebüros; private Transportunternehmen; und Privatschulen, die vom Bildungsministerium (MoNE) zugelassen sind. Für diese Organisationen müssen digitale Dienste — einschließlich Login-Portale, Patientenportale, Banking-Dashboards, Ticketingsysteme und Schülerinformationssysteme — die in der Verfügung definierten Barrierefreiheitsanforderungen erfüllen.

WCAG 3.3.9 ist als AAA-Kriterium keine minimale gesetzliche Verpflichtung im Rahmen der Verfügung. Die gesetzlich vorgeschriebene Basis entspricht der Konformität mit WCAG 2.2 auf Level A und AA. Dennoch macht der Geist und die Reichweite der Verfügung 3.3.9 in der Praxis aus mehreren Gründen hoch relevant.

Erstens ist WCAG 3.3.8 (Accessible Authentication — Minimum) ein AA-Kriterium und daher für alle erfassten Einrichtungen rechtlich bindend. Organisationen, die an der Einhaltung von 3.3.8 arbeiten, werden feststellen, dass der Weg zur Einhaltung von 3.3.9 oft nur ein kleiner zusätzlicher Schritt ist — hauptsächlich die Entfernung der Bild-Erkennungs-Ausnahme, die 3.3.8 zulässt, und die Sicherstellung, dass alle kognitiven Tests nicht-kognitive Alternativen haben, nicht nur unterstützende Mechanismen.

Zweitens stellt das Erreichen der AAA-Konformität bei Authentifizierungskriterien für Einrichtungen, die Dienstleistungen für Bevölkerungsgruppen mit höheren Raten kognitiver oder motorischer Beeinträchtigungen erbringen — insbesondere Krankenhäuser, öffentliche Gesundheitsportale und Portale für staatliche Dienstleistungen — ein bedeutungsvolles Bekenntnis zu gleichberechtigtem Zugang dar, das mit den weiter gefassten verfassungsrechtlichen Gleichheitsgrundsätzen der Türkei und den Verpflichtungen des Landes aus dem Übereinkommen der Vereinten Nationen über die Rechte von Menschen mit Behinderungen (CRPD), das die Türkei ratifiziert hat, im Einklang steht.

Drittens stehen türkische Banken und Fintech-Anbieter bei der Authentifizierung unter besonderer Beobachtung. Die Bankenaufsichts- und Regulierungsbehörde (BDDK) und die Behörde für Finanzkriminalität (MASAK) stellen strenge Anforderungen an die Identitätsprüfung, und Organisationen implementieren häufig komplexe, mehrstufige Authentifizierungsabläufe, um diese Anforderungen zu erfüllen. Die Implementierung von 3.3.9-konformer Authentifizierung — unter Verwendung von Passkeys, WebAuthn oder Magic-Link-Flows — ist sowohl barrierefreier als auch im Einklang mit modernen Best Practices für sichere Authentifizierung, die von internationalen Finanzaufsichtsbehörden unterstützt werden, und macht sie zu einem Designziel, das die Compliance auf mehreren Ebenen gleichzeitig unterstützt.

Organisationen, die ihre Barrierefreiheitsposition differenzieren, sich auf mögliche zukünftige Verschärfungen der Regulierung vorbereiten oder Nutzer auf barrierefreie und inklusive Weise bedienen möchten, werden nachdrücklich ermutigt, WCAG 3.3.9 als Designstandard und nicht nur als optionale Verbesserung zu behandeln. Die Implementierung vollständig nicht-kognitiver Authentifizierungspfade ist mit modernen Browser-APIs (WebAuthn/Passkeys) und Authentifizierungs-SDKs zunehmend machbar, wodurch die Kosten der Einhaltung geringer sind als je zuvor, während der Nutzen — die Beseitigung einer der folgenreichsten Barrieren für die Barrierefreiheit in jedem digitalen Produkt — erheblich ist.