WCAG 3.3.8 Accessible Authentication (Minimum): A Computable Checklist for Login Flows

Thesis: Flag by Machine, Verify by Human

Most WCAG success criteria resist automation because their outcomes depend on perception, meaning, or context. Accessible Authentication (Minimum) is an outlier: the signals that drive most of its failures — suppressed paste handlers, segmented code inputs, nth-character prompts, transcription challenges — live in the DOM and in the strings the page renders. That makes the criterion unusually auditable by an AI design agent working from markup and source. What does not compute is exception adequacy: whether a mechanism genuinely assists, whether a challenge is recognition-only, and whether runtime behavior matches the code. The defensible division of labor is therefore strict. The agent enumerates and flags; the human verifies behavior; nobody certifies conformance from a static pass. This essay sets out the criterion verbatim, a step-level decision procedure, seven computable rules with their failure modes, and the boundary the agent must refuse to cross.

The Criterion, Verbatim

Success Criterion 3.3.8 Accessible Authentication (Minimum), Level AA, is normative text in WCAG 2.2 (W3C). Its operative sentence:

“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:”

The four exceptions, with their labels and texts:

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

And the two notes:

Note 1: “‘Object recognition’ and ‘Personal content’ may be represented by images, video, or audio.”

Note 2 names two mechanisms: support for password entry by password managers to reduce memory need, and copy and paste to reduce the cognitive burden of re-typing.

The term doing all the work is defined in the normative document at the definition of cognitive function test:

“A task that requires the user to remember, manipulate, or transcribe information. Examples include, but are not limited to: memorization, such as remembering a username, password, set of characters, images, or patterns. The common identifiers name, e-mail, and phone number are not considered cognitive function tests as they are personal to the user and consistent across websites; transcription, such as typing in characters; use of correct spelling; performance of calculations; solving of puzzles.”

Two reading rules follow immediately. First, a memorized password is a cognitive function test, so an ordinary username-and-password login passes only through an exception — in practice the Mechanism exception. Second, name, e-mail, and phone fields are excluded from the definition, which means an auditor that flags them as tests has already miscalibrated.

The Decision Procedure

The procedure operates per authentication step, not per page:

Is this step a cognitive function test under the definition (remember, manipulate, or transcribe)?
If yes, does the step provide at least one of the four exceptions?
Fail condition: a cognitive function test is required and no exception is provided.

Two scoping rules bound the procedure. For multi-step flows, Understanding 3.3.8 (W3C) states: “If there is more than one step in the authentication process, such as with multi-factor authentication, all steps need to comply with this success criterion to pass. There needs to be a path through authentication that does not rely on cognitive function tests.” On scope: “This success criterion is focused on authentication of existing users. It does not cover creation of a username or initiation of an account.” The same page extends the logic to recovery: if a user authenticates with alternative information to recover an account, “there needs to be a method that is not a cognitive function test.”

The Alternative branch is the cheapest to satisfy and the easiest to check: W3C technique G218: Email link authentication is listed as Sufficient for both 3.3.8 and 3.3.9, so a flow that offers a mailed sign-in link provides a non-cognitive path even when the password step itself demands recall.

for each step in authentication_process:
    if step requires cognitive_function_test:
        if not any(Alternative, Mechanism, Object Recognition, Personal Content):
            flag("CFT with no exception — flagged for review")
    else:
        pass_step

The Computable Surface: Seven Rules

Each rule below pairs an observable signal with its false-positive and false-negative risk. All signals are drawn from Understanding 3.3.8 (W3C), which also indexes the criterion’s techniques in the WCAG 2.2 Quick Reference; all verdicts are conditional flags for human review, never site-level certifications.

R1 — Paste blocked

Signal: paste-event handlers or onpaste suppression on authentication inputs, or an error string in the style of the Understanding page’s Figure 2 (“Function not allowed, please type password manually.”). Risk: a handler can exist without blocking paste, producing a false positive; a server-side or visually hidden block can be invisible to a static pass, producing a false negative. Whether paste actually lands in the field is behavioral and human-verified.

R2 — Autofill blocked

Signal: the source’s own wording for the failure mode — “a script that prevents form fields from being automatically populated.” Risk: runtime scripts are frequently invisible to a static source pass, and the absence of a blocking script is not evidence that autofill succeeds. Absence of evidence is not evidence of assistance. Do not substitute a neighbouring success criterion for an exception here: 3.3.7 Redundant Entry states that it “does not impact Accessible Authentication (Minimum)”, so it is never a 3.3.8 defence.

R3 — Segmented one-time-code entry

Signal: adjacent single-character inputs for a verification code. The Understanding page’s Figure 3 caption reads: “A time-based one-time password (TOTP) challenge that requires users to enter each digit of the 6-digit code into separate input fields – trying to paste the entire code only fills in one digit in the first input.” The governing rule is separate and general: “A service that requires manual transcription of a verification code is not compliant.” Two caveats discipline the wording. The excerpts do not attach the word “fail” to this figure in a standalone sentence, and nothing in the sources establishes that every segmented input mishandles paste — an implementation that distributes a pasted code across all boxes is a different observable. The grounded flag is therefore: flagged for review against the transcription rule, with paste behavior human-verified.

R4 — Nth-character prompt

Signal: labels such as “1st, 3rd, and 5th” character or digit of a password or passnumber (Figure 4). Grounded verdict: the Understanding page states that using a different format between the copied text and the input field “would force the user to transcribe information and therefore fail this criterion, unless another method is available.” The flag is conditional on the absence of another method.

R5 — Transcription CAPTCHA

Signal: an image or audio challenge paired with a text input expecting typed characters. Risk: a separate, non-cognitive path through the flow may exist elsewhere in the journey, and detecting it requires flow exploration rather than inspection of the challenge node alone. Note the boundary on alternatives: “Some CAPTCHA systems have an audio alternative of the visible text. If the user needs to transcribe this audio, it cannot be used to meet the Alternative exception.”

R6 — Input purpose and accessible name

Signal: the Understanding page ties reliable automatic fill to two other success criteria. It states that “[i]f the login form meets Success Criterion 1.3.5 Input Purpose, user agents and password managers should be able to reliably recognize the fields and automatically fill them in,” and its passing example describes “a properly marked up username (or email) and password fields” meeting “Success Criterion 1.3.5 Input Purpose and Success Criterion 4.1.2 Name, Role, Value.” Risk: compliant markup makes fill likely, not certain; actual fill by a given user agent or password manager is human-verified. Two tool-side anchors make markup checkable without a browser: the axe-core autocomplete-valid rule fails invalid or misapplied autocomplete tokens, and W3C technique H98 documents correct use of the HTML autocomplete attribute for input purposes. Both check declaration, not whether a field is actually filled. This rule deliberately does not enumerate markup tokens beyond what the source names.

R7 — Non-CFT fields and non-code factors

Signal to suppress: name, e-mail, and phone inputs must not be flagged, because the definition excludes them. Signal to clear: two-factor steps that do not rely on codes are not cognitive function tests — the source names hardware authentication devices (such as YubiKey), secondary applications that ask the user to confirm the login attempt, and operating-system-provided authentication (such as Windows Hello, or Touch ID/Face ID on macOS and iOS), all as the source’s own examples. Risk in both directions: an agent that flags every authentication step cries wolf; an agent that assumes device-based authentication without evidence can miss a knowledge-based step wearing a device-shaped label.

Pattern	CFT per definition?	Exception in play	Observable signal	What an agent may say
Username + password, paste blocked	Yes — memorization of a password	Alternative required; Mechanism unavailable while paste is blocked	Paste suppression or a “type password manually” style error string (Fig. 2)	“Flagged for review: blocking paste fails the criterion unless another method is available”
Username + password, paste allowed, 1.3.5/4.1.2 markup	Yes — memorization remains	Mechanism — paste and password-manager fill	No paste suppression; properly marked up inputs with accessible names	“Mechanism exception plausibly available; actual fill success is human-verified”
One-digit-per-box TOTP entry	Yes — transcription of a verification code	Mechanism only if paste or autofill can complete the whole code	Six adjacent single-character inputs (Fig. 3)	“Flagged: a service requiring manual transcription of a verification code is not compliant; whether a given segmented control mishandles paste is not established by these sources”
Recognition-only image CAPTCHA	Yes — recognizing a website-provided picture	Object Recognition at AA; removed at AAA	Image grid with a selection instruction, no text transcription	“Object Recognition exception applies at AA for pure recognition; the exception breaks if the task adds manipulation, e.g. arithmetic on counted objects”

Any cell not directly supported by the quoted sources is marked “not established by these sources” rather than asserted.

AA versus AAA

The Level AAA counterpart narrows the table. Per the Understanding 3.3.9 page (W3C), the criterion “is the same as 3.3.8 Accessible Authentication (Minimum) but without the exceptions for objects and user-provided content,” so both Object Recognition and Personal Content drop out at AAA. The 3.3.8 Understanding page supplies the supporting sentence: “While recognizing objects, or a picture the user has previously provided, are cognitive function tests, these are excepted in this criterion at AA level. However, these cases are not excepted in Success Criterion 3.3.9 Accessible Authentication (Enhanced).” An agent auditing for AAA must therefore delete two of the four exception branches from its decision table. The AA-level boundary still applies within the surviving recognition exception: “An object in this context means the general English definition (‘a material thing that can be seen and touched’) and can include vehicles and animals. If the test goes beyond recognition (e.g. multiply the number cats by the number of dogs), that does not meet the exception.”

How to Verify: a Two-Pass Protocol

Pass one is static: the agent reads markup, source, and rendered strings, and emits R1–R7 flags. Pass two is human and behavioral: a person pastes, fills, and confirms. The Understanding page draws exactly this line: “Evaluating this criterion therefore only requires verification that the web content does allow pasting the clipboard content in the related authentication challenge field.” That sentence describes an act of verification — watching clipboard content enter the field — which no static parser can perform on the page’s behalf. The same passage fixes the scope of the clipboard question: for codes received on a secondary device, “Evaluating whether or not the code can be seamlessly transferred from the secondary device to the primary device is outside of the scope for this success criterion,” and evaluation assumes provisions exist that make the code available in the user’s clipboard. An agent must not fail a flow because the user’s cross-device bridge is awkward; it must check only whether the challenge field accepts the pasted clipboard content.

Limitations: the Non-Computable Remainder

Five items sit permanently outside the static pass and are marked human-verified:

The mechanism actually assists (human-verified). Paste and autofill must work at runtime; markup can only make them likely.
Recognition-only judgment (human-verified). Whether a challenge is pure object recognition or covertly demands manipulation — the arithmetic example breaks the exception — is a semantic call, and the source adds that some object recognition carries cultural load (taxis differ by locale), which it treats as not an accessibility-specific issue.
The password manager actually fills (human-verified). 1.3.5-conformant purpose plus a 4.1.2 accessible name supports reliable recognition, but fill success is an observed fact, not a derived one.
Conditional CAPTCHAs (human-verified). “Some CAPTCHAs and cognitive function tests used for authentication may only appear in certain situations, such as when ad blockers are present, or after repeated incorrect password entry. This criterion applies when these tests are used regardless of whether they are used every time or only triggered by specific scenarios.” A crawl that never trips the trigger will never see the challenge.
The secondary-device clipboard assumption (human-verified, and out of scope). The criterion assumes the code reaches the clipboard; whether the user’s devices actually bridge that gap is explicitly outside the criterion’s scope.

One adjacent topic must not be promoted into a rule. The Understanding page notes that hiding characters while typing contributes to cognitive load and that providing an optional show-password feature “can improve the chance of success for some people with cognitive disabilities or those who have difficulties with accurately typing” — but the excerpts present this as a contributing factor and an improvement suggestion, not as a pass/fail requirement of 3.3.8. An agent should neither emit a 3.3.8 violation for a masked field nor claim a show-password toggle is required by this criterion.

FAQ

Does blocking paste fail the criterion? Yes, unless another method is available. The Understanding page states: “Blocking people from pasting into authentication fields (see the example in login forms), or using a different format between the copied text and the input field (for example, ‘Enter the 1st, 3rd, and 5th character of your password’), would force the user to transcribe information and therefore fail this criterion, unless another method is available.”

Does an audio CAPTCHA satisfy the Alternative exception? Not if it demands transcription: “Some CAPTCHA systems have an audio alternative of the visible text. If the user needs to transcribe this audio, it cannot be used to meet the Alternative exception.”

Are name, e-mail, or phone fields cognitive function tests? No. The definition excludes them: “The common identifiers name, e-mail, and phone number are not considered cognitive function tests as they are personal to the user and consistent across websites.” Rule R7 exists to prevent exactly this false flag.

Do conditionally triggered CAPTCHAs count? Yes. The criterion “applies when these tests are used regardless of whether they are used every time or only triggered by specific scenarios,” including challenges that appear only when ad blockers are present or after repeated incorrect password entry.

Does 3.3.8 cover account creation? No. “This success criterion is focused on authentication of existing users. It does not cover creation of a username or initiation of an account.” The page notes the same techniques that satisfy it can reduce cognitive burden during creation, but creation itself is out of scope.

What changes at AAA? The structure stays the same, but per the Understanding 3.3.9 page the criterion “is the same as 3.3.8 Accessible Authentication (Minimum) but without the exceptions for objects and user-provided content,” leaving only the Alternative and Mechanism branches — so a recognition-only CAPTCHA that clears AA has no exception at AAA.

How This Guide Was Built

The research basis is the W3C Understanding pages for 3.3.8, 3.3.9 and 3.3.7, the WCAG 2.2 normative text, two W3C techniques (G218 and H98), and the axe-core autocomplete-valid rule page, all fetched on 2026-11-06 by the research lane. The UK National Cyber Security Centre post “Let them paste passwords” appears in the Understanding page’s Related Resources; it is referenced here by title only, with the live URL provided as a pointer. Its body was not read and is not summarized anywhere in this guide. No hands-on testing of any login flow, password manager, CAPTCHA, or tool was performed by the author, and every behavioral statement above is attributed to the quoted sources rather than to observation. The verified link pool behind this post is ten unique URLs, each fetched successfully on 2026-11-06, and no URL outside that pool was added; fetching is attributed to the 2026-11-06 research run, not to the author.

The Bottom Line

An AI design agent can do real work here: enumerate the properties of each authentication step from the DOM, emit rule-level flags phrased as conditional W3C verdicts (“blocked paste fails unless an alternative exists”), and flag absent exception affordances such as a missing non-cognitive path. What it cannot do is certify. Actual paste and autofill behavior, the adequacy of a claimed mechanism, the recognition-only status of a challenge, the presence of conditionally triggered tests, and the assumed clipboard bridge to a secondary device all require human verification. The agent’s output vocabulary should contain “flagged for review” and never “certified” — and any conformance claim for a real login flow remains a human conclusion built on top of, not instead of, this checklist.