WCAG 3.3.8: Accessible Authentication (Minimum)

What This Rule Means

WCAG 3.3.8 Accessible Authentication (Minimum) is a Level AA criterion introduced in WCAG 2.2. It states that a cognitive function test—defined as a task that requires a user to remember, manipulate, or transcribe information—must not be the sole means of completing an authentication step, unless at least one of the following conditions is met:

• Alternative method: Another authentication pathway is available that does not rely on a cognitive function test (for example, a magic link sent by email, biometric login, or a passkey).
• Mechanism to assist: The user agent or a third-party tool is allowed to complete the step on behalf of the user—for example, a password manager autofilling credentials, or a copy-paste action for a one-time code.
• Object recognition exception: The cognitive function test involves identifying an object in an image (for example, selecting all images containing a traffic light) — this type of test is permitted at the Minimum (AA) level.
• Personal content exception: The test relies on content the user themselves provided, such as selecting a previously uploaded photo from a grid.

In practical terms, a login form that requires only a username and password does comply with this criterion, provided the form allows browser autofill and password managers to work (i.e., the fields use standard <input type='password'> and are not blocked from pasting). A CAPTCHA that requires transcribing distorted text without any alternative authentication route is a clear failure. A CAPTCHA that asks users to select images matching a category (object recognition) is permitted at the AA level but is addressed more strictly at AAA (3.3.9).

The criterion applies to all steps of an authentication process: initial login, step-up authentication, multi-factor verification, account recovery, and session re-authentication. It also applies to any process that guards access to functionality, not just the primary sign-in screen.

A key technical implication is that developers must not use autocomplete='off' on authentication fields, must not disable paste via JavaScript event handlers, and must not break the standard input semantics that allow assistive technology and browser autofill to operate correctly.

Why It Matters

Authentication is a gateway to nearly every digital service people rely on daily—banking, healthcare portals, government services, e-commerce, and communication platforms. When that gateway imposes cognitive hurdles, it systematically excludes a significant portion of the population.

Cognitive disabilities encompass a wide spectrum: dyslexia, dyscalculia, attention deficit disorders, acquired brain injuries, dementia, intellectual disabilities, and anxiety disorders. The World Health Organization estimates that approximately 1 in 6 people globally experience some form of significant disability, and cognitive and neurological conditions represent one of the largest categories. For these users, tasks such as accurately transcribing a string of distorted characters, solving a visual puzzle under time pressure, or switching between an authenticator app and a login form can be genuinely impossible or profoundly exhausting.

Consider a concrete scenario: a person with dyslexia attempts to log in to their health insurance portal to view test results. The site presents a text CAPTCHA with no audio alternative and no way to bypass it. The distorted letterforms are indistinguishable to this user, and the input field blocks pasting. After several failed attempts, the account is locked. The user cannot access time-sensitive medical information. This is not a hypothetical edge case—it is a routine experience for millions of people.

Motor-impaired users who rely on switch access or eye-tracking devices are also affected. Re-typing a complex one-time passcode from a separate device, or dragging image tiles into a specific order, may be physically impossible with these input methods. Allowing copy-paste or passkey-based authentication resolves the barrier entirely.

Older adults represent another significant group. Age-related cognitive decline affects memory and processing speed, making complex CAPTCHAs and multi-step memorization tasks disproportionately difficult. As populations in Turkey and globally age, the business and regulatory case for accessible authentication grows stronger each year.

From a usability and conversion perspective, friction in authentication flows directly increases abandonment rates. E-commerce platforms that replace text CAPTCHAs with risk-based authentication or passkeys consistently report higher login completion rates and lower support costs related to locked accounts.

Related Axe-core Rules

WCAG 3.3.8 is classified as requiring manual testing because automated tools cannot fully assess whether an authentication process imposes an inaccessible cognitive function test. Determining whether a login flow has no alternative pathway, or whether paste is blocked in a context-dependent way, requires human judgment and interaction with a live authentication flow. That said, certain automated checks support this criterion:

• Manual review — authentication flow audit: Testers must walk through every authentication step and determine whether a cognitive function test is present, and if so, whether a compliant alternative or assistive mechanism exists. No axe-core rule currently fires automatically for this criterion because the logic depends on understanding the purpose and context of form fields and surrounding UI, not just their markup.
• autocomplete attribute checks (related): Axe-core's autocomplete-valid rule flags input fields whose autocomplete attribute values are not drawn from the WCAG 1.3.5 token list. While this rule targets 1.3.5 directly, it is a supporting check for 3.3.8: if autocomplete='username' and autocomplete='current-password' are missing or incorrectly set, password managers cannot autofill, removing the assistive mechanism that makes standard password login compliant under 3.3.8.
• Paste-blocking detection — manual: Automated scanners cannot reliably detect JavaScript that intercepts paste events and suppresses them on authentication inputs. A manual tester must attempt to paste a credential or OTP into each relevant field and confirm the action succeeds.
• CAPTCHA alternative detection — manual: Axe-core can detect the presence of common CAPTCHA widgets (e.g., reCAPTCHA iframes) but cannot determine whether an alternative authentication path is offered elsewhere on the page or via a different route. This determination requires manual inspection of the full authentication UX.

How to Test

1. Automated scan (axe DevTools / Lighthouse): Run axe DevTools on each authentication page (login, registration, account recovery, MFA). Look for autocomplete-valid violations on username and password fields. In Lighthouse, review the Accessibility audit for form-related issues. Note that no automated rule will definitively flag a 3.3.8 failure — automated results are a starting point only.
2. Identify all cognitive function tests: Manually catalog every step in the authentication flow. Note any step that requires the user to recall information not provided on the current screen, transcribe characters, solve a puzzle, or perform a calculation. Check whether each such step has a compliant alternative (object recognition, personal content, alternative login method, or assistive mechanism).
3. Test paste functionality: On every authentication input (username, password, OTP, recovery code), attempt to paste text using the keyboard shortcut (Ctrl+V on Windows/Linux, Cmd+V on macOS). Confirm the pasted content appears in the field. Repeat using the right-click context menu. If paste is blocked, this is a failure unless a cognitive-function-free alternative exists.
4. Test autofill with a password manager: Using a browser with a password manager (native or extension-based), save credentials during registration and then return to the login page. Confirm that the password manager can detect the fields and autofill them. Test in Firefox with NVDA, Safari with VoiceOver (macOS/iOS), and Chrome with JAWS to cover major AT+browser combinations. If the fields use non-standard markup or JavaScript that clears autofilled values, this is a failure.
5. NVDA + Firefox — screen reader walkthrough: Navigate the login form using only the keyboard and NVDA. Confirm that every field is reachable, that field labels are announced correctly, and that any CAPTCHA widget has an accessible alternative. If the CAPTCHA is purely visual with no audio option and no alternative login path, record a failure.
6. VoiceOver + Safari (iOS): On a mobile device, attempt to log in using Face ID or Touch ID if the site offers biometric login. Confirm the biometric option is reachable via swipe navigation and that VoiceOver announces it correctly. This validates that a cognitive-function-free alternative is operationally accessible, not just nominally present.
7. Check for time limits on cognitive steps: If a CAPTCHA or OTP entry imposes a time limit, verify whether the user can extend or disable it (relevant to 2.2.1), and separately note whether the timed step constitutes a cognitive function test with no alternative.

How to Fix

Text CAPTCHA with no alternative — Incorrect

<!-- 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 with no alternative — Correct

<!-- 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 field blocking paste — Incorrect

<!-- 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 field blocking paste — Correct

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

Image-selection CAPTCHA with no fallback (AAA concern, AA pass) — Correct at 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>

Common Mistakes

• Setting autocomplete='off' on password fields: This disables password manager autofill, removing the assistive mechanism that makes standard password authentication compliant. Use autocomplete='current-password' instead and let the browser manage credential storage.
• Blocking paste with onpaste='return false;' or addEventListener('paste', e => e.preventDefault()): This forces users to manually type credentials, creating an inaccessible transcription task. Remove all paste-prevention handlers from authentication inputs.
• Offering a passkey option that is not keyboard-accessible: A biometric alternative only satisfies 3.3.8 if it is reachable and operable via keyboard and assistive technology. A passkey button hidden behind a hover menu or rendered as a non-focusable <div> does not count as a compliant alternative.
• Using a text CAPTCHA as the only bot mitigation strategy: Switching to risk-based, server-side bot detection (analyzing device fingerprint, typing cadence, IP reputation) eliminates the cognitive function test entirely without sacrificing security. Relying solely on client-side CAPTCHA is both an accessibility failure and poor security practice.
• Splitting an OTP into multiple single-character inputs and blocking cross-field paste: Some implementations use six separate <input maxlength='1'> fields for OTP entry and auto-advance focus via JavaScript. This pattern routinely breaks paste from password managers and violates 3.3.8 unless the implementation explicitly handles pasting an entire code into the first field and distributes the characters correctly.
• Requiring image-based CAPTCHA on account recovery flows only: Teams often add accessible login alternatives to the main login page but forget step-up authentication, password reset, and account unlock flows. Each of these is a separate authentication step and must independently comply with 3.3.8.
• Treating audio CAPTCHA as a full alternative to text CAPTCHA: An audio alternative addresses blind users but does not help users with cognitive disabilities or those in noisy environments. Audio CAPTCHAs also present their own transcription requirement. The correct fix is to eliminate the CAPTCHA or provide a pathway that has no cognitive function test at all.
• Dynamically generating input field IDs that break password manager detection: When id attributes on username and password fields are randomized on each page load (a misguided anti-bot technique), password managers cannot reliably identify the fields. This effectively disables autofill and removes the compliant assistive mechanism.
• Assuming third-party CAPTCHA widgets are automatically compliant: Popular CAPTCHA services may offer accessible variants, but they are not enabled by default. Developers must explicitly configure the accessible version, and must still verify that it meets the standard's requirements rather than simply adding a new type of inaccessible test.
• Clearing autofilled values via JavaScript on focus: Some forms clear input content when a field receives focus to show placeholder text or prompt re-entry. If this behavior clears a password manager's autofilled value, it forces manual re-entry and fails 3.3.8.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in Official Gazette No. 32933 on June 21, 2025, establishes web and mobile accessibility obligations aligned with WCAG 2.2. The circular requires covered entities to meet Level AA conformance across their digital products and services. WCAG 3.3.8, as a Level AA criterion in WCAG 2.2, is therefore directly within scope of the mandatory compliance requirements introduced by this circular.

The circular covers a broad range of private and public sector entities. Public institutions and government agencies must achieve full AA conformance. In the private sector, the circular applies to e-commerce platforms, banks and financial institutions, hospitals and private healthcare providers, telecommunications 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, inaccessible authentication flows—such as login pages with unsupported CAPTCHAs or OTP fields that block paste—create direct regulatory exposure.

The Accessibility Logo (Erişilebilirlik Logosu), issued by the Ministry of Family and Social Services, is the official certification mark for digital accessibility conformance in Turkey. Attaining this logo requires demonstrated Level AA compliance, which encompasses 3.3.8. For e-commerce operators, banks, and other high-traffic digital service providers, the logo serves as a public trust signal and may be referenced in procurement and tender requirements. Authentication flows that rely on inaccessible cognitive tests would block certification and expose the organization to complaints and enforcement action.

From a practical compliance standpoint, Turkish organizations should audit every authentication touchpoint—including login, registration, MFA, password reset, and account unlock—against 3.3.8 before submitting for the Accessibility Logo assessment. Replacing text CAPTCHAs with risk-based server-side controls, enabling autocomplete on all credential fields, and offering passkey or magic-link alternatives are the highest-impact remediation actions. These changes simultaneously satisfy the regulatory requirement and improve the authentication experience for the estimated 8.5 million people with disabilities in Turkey who use digital services.