Requires that signing in does not depend on remembering, transcribing or solving a puzzle, unless an alternative or assisting mechanism exists.
Remembering a password, copying a code from one device to another or solving a puzzle is hard for many people. People with memory, reading, number or perception difficulties can be locked out of services for reasons that have nothing to do with security.
This criterion, new in WCAG 2.2, requires that a cognitive function test, such as remembering a password or solving a puzzle, is not required for any step in an authentication process, unless an alternative is available, a mechanism helps the user, the test is object recognition, or it asks the user to identify content they provided.
People with cognitive disabilities affecting memory, reading such as dyslexia, number processing such as dyscalculia, or perception and processing. People who cannot reliably transcribe a code. People who rely on password managers or assistive technology to enter credentials.
The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Authentication without cognitive barriers is part of "understandable".
The technical counterpart is the standard EN 301 549, which incorporates WCAG 3.3.8 by reference and turns it into separate clauses for each kind of ICT.
| Clause | Type of ICT | What it requires |
|---|---|---|
| 9.3.3.8 | Web pages | Web content must satisfy WCAG success criterion 3.3.8. |
Because this criterion is new in WCAG 2.2, it is not part of EN 301 549 V3.2.1. Check clauses 10 and 11 of V4.1.1 for the rows that apply to documents and software. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.
Standard version: Criterion 3.3.8 is new in WCAG 2.2, so it is not part of EN 301 549 V3.2.1, which is based on WCAG 2.1. It appears in EN 301 549 V4.1.1 (September 2026), the first version prepared specifically for the EAA. V4.1.1 has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. It is a Level AA criterion.
A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.
Directive (EU) 2019/882, EUR-Lex, opens in a new tab
Mark up the fields so browsers and password managers can fill them, and never block paste.
<input type="password" onpaste="return false"><label for="email">Email</label>
<input id="email" type="email" autocomplete="email">
<label for="pw">Password</label>
<input id="pw" type="password" autocomplete="current-password">Asking for the 3rd and 7th character requires the user to transcribe and manipulate (F109).
<label>Enter character 3 <input maxlength="1"></label>
<label>Enter character 7 <input maxlength="1"></label><label for="pw">Password</label>
<input id="pw" type="password" autocomplete="current-password">Signing in with a link sent by email avoids remembering or transcribing anything.
<!-- Only a password and a transcribed code --><form>
<label for="e">Email</label>
<input id="e" type="email" autocomplete="email">
<button>Email me a sign-in link</button>
</form>Device authentication through WebAuthn does not need a cognitive function test.
<!-- Password is the only way to sign in --><button type="button" id="pk">Sign in with a passkey</button>
<script>
pk.addEventListener("click", () => navigator.credentials.get({ publicKey: options }));
</script>Allow paste, and tell browsers it is a one-time code, so the user does not retype it.
<input maxlength="6" onpaste="return false"><label for="otp">Verification code</label>
<input id="otp" inputmode="numeric" autocomplete="one-time-code">A puzzle or transcribed text is a cognitive function test. Object recognition and personal content are exceptions, but offer an alternative where you can.
<img src="distorted-text.png" alt="">
<input name="captcha"> <!-- transcribe the characters --><!-- Use a method with no puzzle, or provide an alternative sign-in route -->On mobile, device authentication is the easiest accessible route. Support the platform password manager and biometrics, and do not block pasting.
import SwiftUI
struct SignIn: View {
@State private var email = ""
@State private var password = ""
var body: some View {
Form {
// Content types let the system password manager fill the fields
TextField("Email", text: $email)
.textContentType(.username)
.keyboardType(.emailAddress)
SecureField("Password", text: $password)
.textContentType(.password)
}
}
}<!-- res/layout/sign_in.xml : autofill hints let the password manager fill the fields -->
<EditText
android:id="@+id/email"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:autofillHints="emailAddress"
android:inputType="textEmailAddress"
android:hint="Email" />
<EditText
android:id="@+id/password"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:autofillHints="password"
android:inputType="textPassword"
android:hint="Password" />autocomplete attributes and paste blocking in code, but cannot judge a whole flow. A person must walk through each step.autocomplete attributes: Password managers cannot fill the fields.