Accessible Authentication for E-Commerce: What WCAG 2.2’s SC 3.3.8 Actually Requires

Quick answer: WCAG 2.2’s SC 3.3.8 Accessible Authentication (Minimum) (Level AA) says a “cognitive function test” — remembering a password, transcribing a one-time code, solving a puzzle — can’t be required at any step of signing in or checking out unless that step also offers an alternative, an assistive mechanism, object recognition, or recognition of the user’s own previously-supplied content. In practice, that means three common e-commerce patterns fail it: blocking paste into a password field, requiring a one-time code to be manually retyped with no autofill support, and a CAPTCHA with no accessible alternative. None of these are exotic edge cases — they’re default behavior in a lot of checkout and account code.

This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.2 requires for login and authentication flows and how to meet it, not whether a specific implementation carries legal risk.

Why this matters specifically at checkout

Most WCAG guidance assumes a single moment of interaction — a button, a form field, an image. Login and authentication are different: they’re a process, often with several required steps, and WCAG 2.2 is the first version of the standard with a success criterion that treats the whole process as one thing to evaluate. E-commerce sites hit this constantly and in more places than a typical SaaS app:

• Signing in to check order status or reorder from history
• Creating an account at checkout (often gated behind a password with composition rules)
• Two-factor or one-time-code verification for high-value orders or saved payment methods
• Resetting a forgotten password mid-checkout, which is itself a second authentication process

Every one of these can force a user to remember, transcribe, or solve something with no way around it — and for people with cognitive disabilities, SC 3.3.8’s Intent section is direct about the stakes: “memorizing a username and password places a very high or impossible burden upon people with certain cognitive disabilities, as do additional steps often added to authentication processes… such as the need to transcribe a one-time verification code.”

What counts as a “cognitive function test”

The Understanding document defines it as “a task that requires the user to remember, manipulate, or transcribe information” — explicitly including memorizing a password, retyping a one-time passcode, and solving a puzzle or pattern-gesture challenge. The success criterion doesn’t ban these outright. It requires that when one is used, at least one of these is also true for that step:

• Alternative — another authentication method for that step that isn’t a cognitive function test (a password manager, a passkey, an email magic link).
• Mechanism — something available to help the user complete the test (autofill, paste support, a “show password” toggle).
• Object Recognition — the test is to identify a common object (most CAPTCHAs that ask “select all images with a bicycle” rely on this exception).
• Personal Content — the test is to recognize non-text content the user themselves provided earlier (an example the Understanding document gives is picking a previously-uploaded photo).

That fourth path — Mechanism — is the one most e-commerce checkout code fails without knowing it, because the “mechanism” in question is usually something a developer actively disabled.

The most common failure: blocking paste

A long-standing, mistaken security habit is disabling paste on password fields, on the theory that it discourages weak, reused passwords:

<!-- Fails SC 3.3.8: no way to use a password manager -->
<input type="password" onpaste="return false" name="password" />

This doesn’t stop anyone from choosing a weak password — it just breaks every password manager, which is precisely the “mechanism” that lets a user avoid memorizing a password in the first place. The Understanding document names this directly: “the techniques used to satisfy this criterion (particularly allowing pasting into inputs and not relying on transcription) can also reduce the cognitive burden in account creation.” The fix is simply not adding the block:

<!-- Passes: password managers and copy-paste both work -->
<input type="password" name="password" autocomplete="current-password" />

The autocomplete value matters too — current-password for sign-in, new-password for account creation or reset — because it’s what tells a browser or password manager which field to fill, independent of whether paste is blocked.

One-time codes: the same failure, a different field

Two-factor or SMS/email verification codes hit the same problem from a different angle. A code sent to a phone and manually retyped into six separate single-character boxes is a transcription task with no built-in mechanism to assist it:

<!-- No autofill hook — the code has to be read and retyped by hand -->
<input type="text" maxlength="1" />
<input type="text" maxlength="1" />
<input type="text" maxlength="1" />

The autocomplete="one-time-code" attribute exists for exactly this case — MDN documents it as a value for “a one-time password (OTP) for verifying user identity… most commonly a code received via some out-of-channel mechanism, such as SMS, email, or authenticator application.” On supporting mobile browsers, it lets the OS suggest the just-received code for one-tap fill, removing the transcription step entirely:

<!-- Supports OS-level autofill from an SMS or email code -->
<input type="text" inputmode="numeric" autocomplete="one-time-code" name="otp" />

A single combined input with this attribute also has an accessibility advantage over the six-separate-boxes pattern regardless of 3.3.8: it’s one field with one accessible name, instead of six ambiguous ones a screen reader announces without context.

CAPTCHA: the exception that still needs a fallback

A standard image-selection CAPTCHA (“select all squares with a crosswalk”) can satisfy SC 3.3.8 at the Minimum level through the Object Recognition exception — but only if that’s genuinely all it requires. A text-distortion CAPTCHA that asks a user to transcribe garbled characters is a cognitive function test with none of the four exceptions available, and fails outright unless an audio or alternative-method fallback exists alongside it. It’s also worth knowing that SC 3.3.9 Accessible Authentication (Enhanced) — Level AAA, not required for the AA conformance level this article otherwise covers — removes the Object Recognition and Personal Content exceptions entirely, so an object-recognition CAPTCHA that passes 3.3.8 does not pass 3.3.9. Sites aiming past the AA floor shouldn’t treat any CAPTCHA as a solved problem.

A “show password” toggle needs a real accessible name

The eye-icon toggle that reveals a masked password is common, useful, and frequently built as an icon-only button with no accessible name — a SC 4.1.2 Name, Role, Value failure independent of 3.3.8, but one that shows up in the same form every time:

<button type="button" aria-label="Show password" aria-pressed="false">
  <svg aria-hidden="true"><!-- eye icon --></svg>
</button>

aria-pressed should flip to "true" and the label text should update to “Hide password” once toggled, so a screen reader user gets the same state feedback a sighted user gets from the icon changing.

What a scanner won’t tell you here

None of axe-core’s default rule set evaluates whether an authentication process requires a cognitive function test — that’s a judgment about flow and intent, not a single element’s markup. A scanner can flag a genuinely missing accessible name on the password-toggle button, but it can’t tell you that a CAPTCHA has no fallback, that an OTP field lacks autocomplete="one-time-code", or that a password field silently blocks paste via JavaScript. This is one of the clearer examples of why automated scanning and manual review catch different things — the failure here is behavioral, not structural.

FAQ

Does using a password at all fail SC 3.3.8? No. A password field is fine as long as at least one alternative or mechanism is available — in practice, allowing paste (so a password manager works) is usually enough to satisfy this for a standard password login.

Is SC 3.3.8 required for WCAG 2.1 AA conformance? No — it’s new in WCAG 2.2, published as a W3C Recommendation in October 2023. Quietramp audits scope to WCAG 2.1 AA by default and flag WCAG 2.2 criteria like this one separately, since not every client is targeting the newer version yet.

What about “Sign in with Google” or similar third-party login? That’s the Alternative exception in action — OAuth-style sign-in delegates authentication to a provider and doesn’t itself require the user to recall or transcribe anything on your site.

Get a human-reviewed audit, not just a scan

An automated scanner can catch a missing accessible name on a password-toggle button. It can’t tell you whether your checkout’s OTP field supports autofill, whether a CAPTCHA has a real fallback, or whether some inherited JavaScript is silently blocking paste on a password field — all judgment calls about how a flow actually behaves, not what a single element’s markup says. Quietramp’s audits pair an automated axe-core scan with a manual review of exactly this kind of process-level issue, delivered as a prioritized, developer-actionable PDF report. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.

---

This is educational content about technical accessibility standards, not legal advice. Meeting WCAG 2.1 AA or WCAG 2.2 AA does not guarantee legal compliance with the ADA or any other law, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.