Accessible Authentication: WCAG 3.3.8 and Passwordless Login

For a lot of users, the login screen is the hardest part of a website — harder than anything they came to do. Remembering a unique password, reading a distorted CAPTCHA, or copying a six-digit code from one app to another all lean on memory, attention, and processing that people with cognitive and learning disabilities may not be able to rely on. When they cannot get past the login, everything behind it is inaccessible, no matter how well built.

WCAG 2.2 addressed this directly with a new requirement aimed at the login process itself. The principle: authentication should verify who you are, not how good your memory is. Meeting it happens to push you toward methods — password managers, passkeys, magic links — that are also more secure, so accessibility and security pull in the same direction here.

Two authentication criteria arrived in WCAG 2.2, plus a related one about not re-entering information.

3.3.8 does not ban passwords. A step that is a cognitive function test still passes if it offers at least one of these:

• An alternative that is not a cognitive function test — for example, a "sign in with a passkey" or "email me a login link" option beside the password form.
• A mechanism to assist — most commonly, letting a password manager fill and submit the credential. This is why supporting password managers (and never blocking paste) is the usual way password logins stay compliant.
• Object recognition — asking the user to identify common objects (this is the exception CAPTCHAs sometimes lean on; note it is removed at AAA).
• Personal content — recognizing non-text content the user themselves provided to the site.

The single most common way sites fail 3.3.8 is by fighting the tools that make passwords manageable. Two rules cover most of it: never block paste, and mark up fields so managers and browsers recognize them.

<form action="/login" method="post">
  <label for="email">Email</label>
  <input id="email" name="email" type="email"
         autocomplete="username" autocapitalize="none">

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

  <button type="submit">Sign in</button>
</form>

<!-- One-time code field: let the browser fill it from SMS -->
<input name="otp" type="text" inputmode="numeric"
       autocomplete="one-time-code">

The right autocomplete tokens do a lot of work: username on the identifier, current-password on the login password (new-password on sign-up and change forms), and one-time-code on OTP fields so mobile browsers offer the code straight from the SMS. These reduce typing and memory load for everyone, not just users with disabilities.

The cleanest way to satisfy accessible authentication is to remove the memory test entirely. Passwordless methods carry no cognitive load and are, as a bonus, more resistant to phishing and credential theft.

Passkeys are the strongest option on both axes — accessibility and security — and are now widely supported across browsers and platforms. Offer them as the primary path where you can, with a magic link or an autofill-friendly password form as the fallback. A one-time code is fine provided it can be pasted or auto-filled; the moment you split it into single-character boxes or block paste, it becomes a transcription test again.

The classic CAPTCHA — transcribe the wavy text, pick the traffic lights, solve the puzzle — is a cognitive function test by definition, and often a visual one too, so it can fail multiple criteria at once. On its own, a puzzle CAPTCHA does not meet 3.3.8.

The better direction is to stop asking the user to prove they are human at all, and detect bots invisibly instead:

• Invisible / behavioral checks that score risk from interaction signals without a challenge.
• Honeypot fields — hidden inputs that only bots fill — which cost legitimate users nothing.
• Device or token-based verification that runs in the background.
• Rate limiting and server-side heuristics that never touch the user at all.

• Blocking paste on password or code fields. The most direct 3.3.8 failure — it forces manual transcription. Remove it.
• autocomplete="off" on credentials. Stops managers and browsers from filling; use the correct tokens instead.
• Split one-time-code inputs. Separate single-character boxes look tidy but break autofill and force character-by-character copying.
• Puzzle CAPTCHAs with no alternative. A cognitive (and often visual) test with no accessible path.
• Re-asking for known data. Making users retype an email or address they already entered in the same flow fails 3.3.7 — pre-fill or let them pick it.
• Forcing frequent re-authentication. Short sessions that demand the whole login dance repeatedly multiply the barrier. Keep sessions reasonable and remember trusted devices.