WCAG 3.3.9: Accessible Authentication (Enhanced)

What This Rule Means

WCAG 3.3.9 — Accessible Authentication (Enhanced) is the AAA-level counterpart to WCAG 3.3.8 (Accessible Authentication — Minimum, AA). Together, they form a pair of criteria introduced in WCAG 2.2 designed to ensure that the process of proving identity to a website or application does not itself become an accessibility barrier.

At the AAA level, 3.3.9 tightens the requirements significantly. The criterion states: A cognitive function test must not be required for any step in an authentication process unless that step provides at least one of the following: an alternative authentication method that does not rely on a cognitive function test; a mechanism is available to assist the user in completing the cognitive function test; or the cognitive function test is to recognize objects. Critically, unlike the AA version (3.3.8), the AAA criterion removes the exception that allowed recognizing non-object content (such as pictures of non-object items a user selected earlier). At this level, only true object recognition — recognizing common real-world objects like images of a cat, a bicycle, or a house — is permissible as a cognitive function test, and only if the other conditions are not met.

A cognitive function test is defined as any task that requires the user to remember, manipulate, or transcribe information. This includes: remembering a username or password, solving a mathematical puzzle, completing a CAPTCHA that requires deciphering distorted text, answering a security question about personal history (e.g., "What was the name of your first pet?"), or transcribing a sequence of characters. These all represent memory or transcription tasks that many users cannot reliably perform.

What counts as a pass: An authentication step passes 3.3.9 if it does not require any cognitive function test, or if it meets one of these conditions: (1) a completely separate, non-cognitive authentication path is offered (e.g., a magic link sent by email, WebAuthn/passkey, biometric login); (2) a mechanism assists completion of the test (e.g., the browser's password manager is not blocked, or copy-paste is allowed); or (3) the only cognitive test involved is recognizing a common real-world object from a set of images.

What counts as a fail: Any flow that forces the user — with no bypass or alternative — to recall a password from memory, transcribe a code that cannot be pasted, solve a visual or audio CAPTCHA without an alternative, answer knowledge-based security questions, or identify previously selected images of non-object content (e.g., abstract shapes or personal photos) without an alternative authentication path.

Official exceptions: The WCAG specification itself notes that recognizing objects (photographs of real-world things) is the only image-recognition task permitted at this AAA level. The AA criterion (3.3.8) also permitted recognizing "non-object" personally chosen images, but 3.3.9 removes that exception entirely. There is no exception for "widely used" authentication patterns — if a pattern requires a cognitive test with no alternative, it fails 3.3.9.

Why It Matters

Authentication is frequently the first meaningful interaction a user has with a digital service. If that interaction is itself inaccessible, the rest of the site's accessibility is rendered irrelevant — the user cannot get in the door at all. WCAG 3.3.9 addresses this barrier directly, and its impact spans a wide range of disability groups.

Users with cognitive disabilities — including those with dyslexia, ADHD, traumatic brain injury, dementia, or learning disabilities — may find it extremely difficult or impossible to memorize complex passwords, transcribe time-limited one-time codes manually, or decode distorted CAPTCHA text. The World Health Organization estimates that approximately 1 in 6 people worldwide experience some form of significant disability, and cognitive disabilities represent one of the largest and most underserved categories in web accessibility.

Users with motor impairments — such as those with Parkinson's disease, essential tremor, spinal cord injuries, or conditions requiring switch access or eye-gaze technology — may struggle to accurately type passwords or transcribe codes character by character. Blocking clipboard paste (a common anti-fraud measure that is actively harmful) means these users must laboriously enter each character through their assistive device, dramatically increasing error rates and fatigue.

Users who are blind or have low vision may rely entirely on screen readers or magnification tools. Visual CAPTCHAs are completely inaccessible without an audio alternative, and even audio CAPTCHAs are notoriously difficult for users with hearing impairments or auditory processing disorders. Image-based "select all the traffic lights" challenges can also be problematic when image descriptions are absent or misleading.

Users who are deaf or hard of hearing may face barriers from authentication methods that rely solely on phone calls to deliver one-time codes, particularly when those calls are voice-only with no SMS alternative.

A concrete real-world scenario: Consider a 72-year-old user with mild cognitive decline attempting to access their online banking portal. The bank requires a username (which must be remembered, not the email address), a complex password (clipboard paste is blocked), and a CAPTCHA involving distorted text. The user fails the CAPTCHA twice, is locked out, and must call the bank's helpline — a 40-minute process. Had the bank implemented passkeys or a magic link, this user would have authenticated in seconds. This scenario plays out millions of times daily across the web, and it is entirely preventable.

Beyond disability, accessible authentication benefits all users. Password managers, which are used by hundreds of millions of people, depend on the ability to paste credentials. Blocking paste, requiring manual transcription, or embedding inaccessible CAPTCHAs frustrates mainstream users as well. There are also security arguments: forcing complex manual password entry increases the likelihood of users choosing simpler, weaker passwords or reusing them across sites. Passkeys and magic links, the recommended alternatives, are both more accessible and more secure than traditional password-plus-CAPTCHA flows.

Related Axe-core Rules

WCAG 3.3.9 is classified as requiring manual testing only. As of axe-core 4.10, there is no automated rule that fully evaluates this criterion. Understanding why automated tools cannot catch these violations requires understanding what the criterion is actually measuring.

• Manual testing required — cognitive function detection: Automated scanners can detect the presence of certain HTML elements (like an <input type='password'> or an iframe embedding a third-party CAPTCHA widget), but they cannot determine whether a complete authentication flow requires a cognitive function test with no accessible alternative. The criterion is about the entire user journey across potentially multiple steps and pages, not the properties of any single element. A scanner cannot evaluate whether pasting is programmatically blocked via JavaScript, whether a time limit on a code entry field is reasonable, or whether an alternative authentication path genuinely avoids cognitive tests. These are behavioral and architectural questions that require a human evaluator to walk through the actual authentication process.
• Manual testing required — alternative path verification: Even if a scanner detects a CAPTCHA widget, it cannot verify whether an accessible alternative authentication method exists on the same page or in the same flow. It cannot evaluate whether a "use a passkey instead" option is genuinely equivalent or whether it is buried in a secondary settings page that itself requires passing the inaccessible CAPTCHA first. Evaluating equivalence of alternative paths requires human judgment about the completeness and prominence of those alternatives.
• Manual testing required — clipboard paste behavior: JavaScript that intercepts paste events and cancels them (event.preventDefault() on a paste listener) is invisible to static HTML analysis. A scanner sees a valid <input> element; it cannot know that pasting into it has been disabled. Only manual testing — physically attempting to paste a password or code — can reveal this failure.
• Manual testing required — assistive technology compatibility of auth widgets: Third-party authentication SDKs (social login buttons, CAPTCHA providers, biometric prompts) may render in iframes or Shadow DOM that automated scanners cannot fully penetrate. Manual testing with screen readers such as NVDA, JAWS, and VoiceOver is essential to confirm that all interactive elements within the authentication flow are operable and understandable.

How to Test

1. Identify all authentication entry points: Before testing, map every place in the application where a user must authenticate or verify identity. This includes initial login, account creation, password reset, two-factor authentication prompts, session timeout re-authentication, payment confirmation screens, and age verification gates. Each of these flows must be evaluated independently.
2. Run an automated baseline scan: Use axe DevTools (browser extension) or Lighthouse in Chrome DevTools on each authentication page. While these tools will not directly flag 3.3.9 violations, they will surface related issues — missing labels on form fields, inaccessible iframe content, missing focus management — that compound authentication barriers. Note any flagged issues as context for manual evaluation. In axe DevTools, look at the "Needs Review" tab for items that require manual judgment.
3. Audit for cognitive function tests: For each authentication step, ask: does this step require the user to (a) remember something, (b) transcribe something, or (c) solve a puzzle? If yes, verify that at least one of the following is present and equally prominent: a non-cognitive alternative path; a mechanism (like allowed clipboard paste or an autofill-compatible field) that assists completion; or that the only cognitive task is recognizing a common real-world object.
4. Test clipboard paste behavior: In each password and code entry field, copy a string of text to your clipboard and attempt to paste it using Ctrl+V (Windows/Linux) or Cmd+V (macOS). If paste is blocked, this is a failure. Also test whether browser password manager autofill is suppressed (check for autocomplete='off' or JavaScript that clears autofill values on focus).
5. Test with NVDA + Firefox: Navigate the entire authentication flow using only the keyboard and NVDA screen reader. Verify that all form fields are announced with meaningful labels, all interactive controls (buttons, links, CAPTCHA challenges) are reachable and operable, and that any error messages are programmatically associated with the relevant field and announced immediately without requiring additional navigation.
6. Test with VoiceOver + Safari (macOS/iOS): Repeat the full authentication flow. On iOS, also verify that biometric authentication (Face ID / Touch ID) is offered as an alternative where native authentication is used, and that the web-based flow is fully operable with Switch Control if biometric is unavailable.
7. Test with JAWS + Chrome: Repeat the flow, paying particular attention to how third-party widgets (OAuth social login, CAPTCHA iframes) are announced. JAWS handles certain ARIA patterns differently from NVDA; both must be tested.
8. Evaluate alternative paths for true equivalence: If an alternative authentication method exists (e.g., "Sign in with a magic link"), complete the entire flow using only that alternative. Confirm it reaches the same authenticated state without requiring any cognitive test. If the alternative path itself contains a CAPTCHA or memory test, it is not a valid alternative under 3.3.9.
9. Document findings with evidence: For each failure, capture a screen recording or annotated screenshot showing exactly which step fails and why. This documentation is essential for remediation handoff to development teams and for audit trail purposes.

How to Fix

CAPTCHA with no alternative — Incorrect

<!-- 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 replaced with passkey and magic link — Correct

<!-- 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>

Clipboard paste blocked on OTP field — Incorrect

<!-- 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 field with paste enabled and autocomplete hint — Correct

<!-- 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. -->

Knowledge-based security questions — Incorrect

<!-- 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>

Identity verification with non-cognitive alternatives — Correct

<!-- 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>

Common Mistakes

• Adding autocomplete='off' to password fields to prevent browser autofill. This disables the primary mechanism that allows users to avoid memorizing passwords and directly fails 3.3.9. Remove autocomplete='off' and use autocomplete='current-password' or autocomplete='new-password' instead.
• Attaching a JavaScript paste event listener that calls event.preventDefault() on authentication input fields, believing this improves security. In reality, it blocks password managers and assistive technologies and constitutes a transcription requirement under 3.3.9.
• Treating the audio CAPTCHA alternative as a sufficient bypass for visual CAPTCHAs. Audio CAPTCHAs still constitute a cognitive function test (transcribing distorted audio characters) and do not satisfy 3.3.9. A truly non-cognitive alternative path is required.
• Offering a passkey or social login option but placing it behind a CAPTCHA challenge first. If the user must pass a cognitive test to access the accessible alternative, the alternative is not genuinely equivalent and the flow fails 3.3.9.
• Using six separate single-character <input> fields for OTP entry (a common UI pattern) without supporting paste-to-fill across the fields. Many implementations only paste into the first field and require manual keystroke-by-keystroke entry for the remaining five, which is a transcription barrier.
• Relying on "Remember me" or persistent session cookies as the sole accommodation for users who cannot authenticate repeatedly. While reducing authentication frequency helps, it does not fix an inaccessible authentication process — users must still pass the cognitive test at least once, and sessions expire or are cleared.
• Implementing time-limited OTP fields that clear on timeout without warning, forcing users to request a new code and attempt transcription again. This compounds the cognitive load for users with slow motor or cognitive processing speeds.
• Using image-based CAPTCHA challenges that require recognizing non-object content — such as abstract patterns, colors, or sequences of personally selected photos — and believing this satisfies 3.3.9. The AAA criterion only permits object recognition (real-world objects like cars, bicycles, traffic lights); non-object image recognition is not exempt at this level.
• Blocking access to the browser's credential manager via autocomplete='new-password' on login fields (as opposed to registration fields). The new-password value signals to browsers that this is a field for creating a new password, preventing autofill of saved credentials during login.
• Failing to test authentication flows with actual assistive technologies and instead relying solely on automated scan results. Because 3.3.9 is manually testable only, teams that skip manual screen reader and keyboard testing will systematically miss failures in this criterion across every release cycle.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular No. 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes comprehensive web and mobile accessibility obligations for a broad range of public and private entities operating in Turkey. The circular mandates conformance with WCAG 2.2, making it the first Turkish legal instrument to explicitly reference the 2.2 version of the standard.

The entities covered by the circular include: public institutions and agencies at all levels of government; e-commerce platforms and online marketplaces; banks and financial institutions; hospitals and healthcare providers; telecommunication operators with 200,000 or more subscribers; travel agencies; private transport companies; and private schools authorized by the Ministry of National Education (MoNE). For these organizations, digital services — including login portals, patient portals, banking dashboards, ticketing systems, and student information systems — must meet the accessibility requirements defined by the circular.

WCAG 3.3.9, as an AAA-level criterion, is not a minimum legal obligation under the circular. The legally mandated baseline corresponds to WCAG 2.2 Level A and AA conformance. However, the circular's spirit and scope make 3.3.9 highly relevant in practice for several reasons.

First, WCAG 3.3.8 (Accessible Authentication — Minimum) is an AA-level requirement and is therefore legally binding for all covered entities. Organizations working to comply with 3.3.8 will find that the path to 3.3.9 compliance is often a small incremental step — primarily removing the image recognition exception that 3.3.8 permits and ensuring that all cognitive tests have non-cognitive alternatives, not just assistive mechanisms.

Second, for entities providing services to populations with higher rates of cognitive or motor disability — particularly hospitals, public healthcare portals, and government service portals — achieving AAA conformance on authentication criteria represents a meaningful commitment to equal access that aligns with Turkey's broader constitutional equality principles and the country's obligations under the UN Convention on the Rights of Persons with Disabilities (CRPD), which Turkey has ratified.

Third, Turkish banks and fintech providers face particular scrutiny on authentication. The Banking Regulation and Supervision Agency (BDDK) and the Financial Crimes Investigation Board (MASAK) impose strong identity verification requirements, and organizations often implement complex, multi-step authentication flows to satisfy these requirements. Implementing 3.3.9-compliant authentication — using passkeys, WebAuthn, or magic link flows — is both more accessible and aligns with modern secure authentication best practices endorsed by international financial regulators, making it a design goal that serves compliance on multiple fronts simultaneously.

Organizations seeking to differentiate their accessibility posture, prepare for potential future regulatory tightening, or serve users in accessible and inclusive ways are strongly encouraged to treat WCAG 3.3.9 as a design standard, not merely an optional enhancement. Implementing fully non-cognitive authentication pathways is increasingly feasible with modern browser APIs (WebAuthn/passkeys) and authentication SDKs, making the cost of compliance lower than ever while the benefit — eliminating one of the most consequential accessibility barriers in any digital product — is substantial.