Accessible authentication: WCAG 3.3.8

WCAG 2.2 success criterion 3.3.8, Accessible Authentication (Minimum), says that no step of signing in may require a cognitive function test, such as remembering a password, typing in a code or solving a puzzle, unless that step meets one of four conditions. It is a Level AA criterion, new in WCAG 2.2.

A password field usually passes the criterion when a password manager can fill it and when paste works.

Our checklist has a failing and a passing sign-in form for 3.3.8.

What 3.3.8 requires

A cognitive function test is, in WCAG’s words, “a task that requires the user to remember, manipulate, or transcribe information”: memorising a username or password, typing in characters, spelling correctly, calculating or solving a puzzle. Typing your name, email address or phone number does not count, because those are personal to you and the same on every site.

No step of signing in may require such a test unless the step offers at least one of these:

1. Alternative: another way to sign in that does not rely on a cognitive function test.
2. Mechanism: something that helps you complete the test. WCAG names password managers and copy and paste.
3. Object recognition: the test only asks you to recognise objects, such as picking the pictures that show a bicycle.
4. Personal content: the test asks you to identify non-text content you gave the site, such as a photo you uploaded.

The criterion applies to every step of signing existing users in, including a second factor, and to recovering an account. It also applies to a test that appears only sometimes, such as a CAPTCHA after repeated wrong passwords. Creating an account is not covered. At Level AAA, 3.3.9 Accessible Authentication (Enhanced) keeps only the first two: object recognition and personal content no longer count.

3.3.8 is part of what WCAG 2.2 added to 2.1. Asking again for information someone already entered, at sign-up or at checkout, is a different criterion, 3.3.7 Redundant Entry; we go through the two Level A criteria WCAG 2.2 added together.

Sign-in patterns that fail

Paste is blocked

<label for="password">Password</label><input id="password" name="password" type="password"       onpaste="return false">

The same block is often added from a script, with addEventListener("paste", (event) => event.preventDefault()). Either way, someone who keeps passwords in a manager, or in a document, has to type a long password from memory or copy it character by character. The fix is to delete the handler.

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

Autofill is blocked

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

The W3C’s guidance is that a page fails 3.3.8 when password managers are “actively blocked from filling in the fields”, for example by a script, and no other method is offered. autocomplete="off" is a weaker request: in most browsers it does not stop a password manager filling a sign-in form, MDN notes. Where a browser or manager does honour it and paste is blocked too, people are left typing from memory, so remove it. Use autocomplete="username" and autocomplete="current-password" on a sign-in form, and autocomplete="new-password" where someone chooses a new password, as in the passing example above. Give each field a visible label and a name, so browsers and password managers can tell what it is.

A one-time code split across fields

<fieldset>  <legend>Enter the 6-digit code</legend>  <input aria-label="Digit 1" maxlength="1" inputmode="numeric">  <input aria-label="Digit 2" maxlength="1" inputmode="numeric">  <!-- four more --></fieldset>

WCAG failure F109 covers this: the code has to go in one character at a time. Six boxes pass only if pasting the whole code into the first one fills the rest, or another method is offered. A single field is simpler:

<label for="code">Sign-in code</label><input id="code" name="code" inputmode="numeric"       autocomplete="one-time-code">

autocomplete="one-time-code" tells the browser the field takes a one-time code, so some phones offer to fill a code that arrives by text message. A code sent to a phone while you sign in on a laptop is a special case: the W3C notes that the code can usually be passed to the laptop and pasted, and leaves that transfer out of scope.

“Enter characters 2, 6 and the last”

Asking for some characters of a password, rather than the whole of it, is another example in F109. A password manager cannot fill it, and paste does not help, so people have to work the characters out. NIST’s guidance, below, also asks for the password “in full (not a subset of it)”. Ask for the whole password in one field, or offer another method alongside it.

Puzzle and transcription CAPTCHAs

A CAPTCHA that asks you to type distorted characters, do a sum or solve a puzzle is a cognitive function test with no exception. It fails unless the step offers another method. An audio CAPTCHA that asks you to type what you hear is not that other method, because it is still transcription.

A CAPTCHA that asks you to pick the pictures of an object is allowed at AA under the object recognition exception, as long as it only asks you to recognise objects, not to do more with them, such as multiplying the number of cats by the number of dogs. The W3C still advises avoiding these tests where possible, and at AAA one fails unless another method is offered. Separately, under 1.1.1 a CAPTCHA needs a text alternative that identifies and describes its purpose, and a form for another sense, such as audio.

Sign-in methods at AA and AAA

Passkeys work through the Web Authentication API. With autocomplete="username webauthn" on the username field, and a conditional navigator.credentials.get() call, the browser can offer a saved passkey from that field.

Why allowing paste is the secure choice

Sites often block paste or autofill for security. The US National Institute of Standards and Technology’s current Digital Identity Guidelines, SP 800-63B-4 from July 2025, say the opposite in section 3.1.1.2: “Verifiers SHALL allow the use of password managers and autofill functionality”, and they “SHOULD permit claimants to use the ‘paste’ function when entering a password”. A password manager makes long, unique passwords practical, and paste is how people use one where autofill does not work. Allowing both is what the accessibility criterion and the security guidance ask for.

How to test it

1. Sign in with a password manager. Check that it offers to fill the username and password, and that the form accepts what it fills.
2. Copy the password and paste it into the field.
3. Go through every step after it: a one-time code, a CAPTCHA that appears after a failed attempt, a “confirm it’s you” screen. Paste the code into its field.
4. For each step that still asks you to remember, transcribe or solve something, check that another method is offered on that step.

axe-core 4.14.0 has no rule for 3.3.8 or 3.3.9. A check that reads markup can find an onpaste attribute that cancels the paste, or autocomplete="off" on a password field. It cannot see a paste blocked from a script, or whether split code fields accept a paste. A browser test that pastes into each field can, but what a CAPTCHA asks, and the steps that only appear after the first page, need a person.