Skip to main content
お使いのブラウザは古いため、このサイトを正しく表示できません。Chrome、Edge、Firefox、Safari の最新版に更新してください。
ブログに戻る
WCAGFormsCognitive

Logins without memory tests: WCAG 3.3.8 Accessible Authentication in practice

WCAG 2.2 says a login step cannot depend on a memory or puzzle test unless there is an alternative or help. What that means for passwords, paste blocking, one-time codes and CAPTCHAs.

AccessiSight team
Accessibility engineering
2026年10月1日

Logging in is where a lot of sites quietly fail people with memory, attention or dyslexia-related disabilities. Remember a password. Retype a six-digit code from another device. Pick out the letters in a distorted image. WCAG 2.2 added success criterion 3.3.8 Accessible Authentication (Minimum), Level AA, to deal with exactly this.

The rule

"A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:"

  • Alternative: "Another authentication method that does not rely on a cognitive function test."
  • Mechanism: "A mechanism is available to assist the user in completing the cognitive function test."
  • Object Recognition: "The cognitive function test is to recognize objects."
  • Personal Content: "The cognitive function test is to identify non-text content the user provided to the website."

Passwords are allowed. What the criterion targets is making people remember or transcribe them with no help.

Passwords: let the browser help

The "Mechanism" exception is what makes ordinary password fields pass: browsers and password managers fill them in, and people can paste. The W3C's Understanding document is explicit that sites must let "the user agent (browser) and any third-party password managers" fill in the fields. So:

<label for="user">Email</label>
<input id="user" name="username" type="email" autocomplete="username">

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

The autocomplete values help password managers find the right fields. Things that break the mechanism and fail 3.3.8:

  • Blocking paste in the password field (onpaste="return false", or a script that clears it).
  • Splitting the password over several fields so password managers can't fill it.
  • Asking for "the 3rd and 5th characters of your password", which forces people to work it out from memory.

One-time codes

A code sent by text message is fine if people can copy and paste it or let the device fill it. Add autocomplete="one-time-code" so phones can offer the code automatically. The common failure is the row of six separate boxes, one per digit, that ignores a paste. If you like the look, make it one field styled as six, or handle paste into the first box by spreading the digits across all of them.

CAPTCHAs

At AA, object recognition ("select the pictures with bicycles") is an exception, though it is still a barrier for many people. A text CAPTCHA that asks you to read and retype distorted characters is a transcription test, and it needs an alternative. Better options don't test the person at all: server-side risk scoring, rate limiting and honeypot fields.

Note that Level AAA, 3.3.9 Accessible Authentication (Enhanced), removes the object recognition and personal content exceptions.

Better alternatives

Passkeys, sign-in links sent by email and signing in with an existing account all avoid memory tests completely. Offering one of them alongside a password satisfies the "Alternative" exception and is simply less work for everyone.

How we check this

AccessiSight looks at the login and sign-up forms it finds and reports blocked paste in password and code fields, partial-password prompts, CAPTCHAs with no alternative method, and security questions used as a login step. Whether a code arrives in a way someone can paste depends on your SMS or email provider, so test that part with a real phone.

References: Understanding 3.3.8 Accessible Authentication (Minimum) (W3C).