A support ticket lands with a familiar line: “I can’t log in, and I know my password is right.” The engineer checks the logs and finds nothing broken. The user is typing a long, randomly generated password from a password manager, but the field blocks paste. They retype it by hand, mistype one character on the fourth attempt and get locked out.
Nothing crashed, yet the login failed. For people with dyslexia, memory impairments, ADHD, or motor conditions that make typing slow and error-prone, this is the everyday reality of authentication. WCAG 2.2 added a success criterion aimed squarely at it: 3.3.8 Accessible Authentication (Minimum), at Level AA.
What the criterion actually says
SC 3.3.8 says a cognitive function test cannot be required for any step in an authentication process, unless that step offers one of four exceptions. W3C defines a cognitive function test as a task that requires the user to remember, manipulate, or transcribe information. That covers memorizing a password, retyping a code from another device, solving a math problem, or spelling a word correctly.
The four exceptions are:
- Alternative: another authentication method that does not rely on a cognitive function test.
- Mechanism: a mechanism is available to help the user complete the test, such as password manager support or copy and paste.
- Object recognition: the test is to recognize objects.
- Personal content: the test is to identify non-text content the user provided to the site.
Two details trip teams up. First, W3C does not treat the common identifiers name, email address and phone number as cognitive function tests, so asking for those is fine. Second, “mechanism” is the exception most teams rely on, and it is the one most often broken by well-meaning security decisions.
Where logins fail in practice
Blocked paste and autofill. Scripts that cancel paste events on password or confirmation fields are common, usually added to stop “weak” behavior. W3C is explicit that blocking paste or autofill in authentication fields fails the criterion unless an alternative is provided.
Fields that password managers cannot recognize. A login form built from custom components, with no autocomplete attributes and unusual input names, makes autofill unreliable. The user is pushed back to remembering and typing.
One-time codes that must be transcribed. A six-digit code sent by SMS or shown in an authenticator app still requires the user to carry it between devices. W3C notes that a code the user must manually transcribe is not compliant, and that users should at least be able to paste it. On mobile, autocomplete="one-time-code" lets the browser offer the code from an incoming message.
Character-position prompts. “Enter the 2nd, 5th and 7th characters of your password” asks users to count and manipulate. W3C lists preventing password or code re-entry in the same format as a failure of 3.3.8 and 3.3.9.
Text-based CAPTCHAs and puzzles. Distorted text, math questions and “select all squares that contain” challenges depend on cognitive function. Object recognition is an exception, but it only helps users who can see and interpret the images, so a non-visual route still matters under other criteria. Audio CAPTCHAs that require transcription do not count as an alternative.
What compliant authentication looks like
The goal is not to remove security. It is to make sure a person can get through without relying on memory or transcription.
Start with the basics of the form:
html
<form> <label for="email">Email address</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"> <label for="otp">Verification code</label> <input id="otp" name="otp" inputmode="numeric" autocomplete="one-time-code"></form>
Real labels, correct type values and the right autocomplete tokens are what let password managers and browsers help. They also line up with the form guidance in our post on making online forms ADA-accessible and WCAG friendly.
Beyond markup, these patterns hold up well:
- Allow paste in every authentication field, including confirmation and code fields.
- Offer a second route that avoids cognitive tests, such as an email link, passkeys, or a hardware key. W3C names email link authentication (technique G218) and properly marked-up email and password inputs (H100) as sufficient techniques.
- Prefer approaches that use the device’s own authentication, such as fingerprint or face unlock. W3C notes that non-code methods like hardware keys and confirmation apps are not cognitive function tests.
- If you must use a CAPTCHA, choose a challenge that does not require transcription or calculation, and keep an alternative available.
- Do not time out silently. A short code lifetime with no way to request a new one pushes users into rushing, which compounds transcription errors.
A note on security
Teams sometimes worry that allowing paste or password managers weakens security. In practice the opposite is often true. Password managers encourage long, unique passwords, which are hard to remember and hard to type, and a form that blocks paste can push users toward shorter, reused ones. Treat the paste block as a risk to remove, not a control to keep.
How to test your own login
You do not need a lab to find most of these problems. Work through the flow with the tools users already have:
- Paste test. Paste a long password and a code into every field. If anything is rejected or cleared, note it.
- Password manager test. Use a mainstream password manager and your browser’s built-in one. Check that each field is detected and filled without manual typing.
- Keyboard and screen reader pass. Complete the full flow, including any CAPTCHA or second factor, using only the keyboard, then with NVDA or VoiceOver. Confirm each field has a clear label and error messages are announced.
- Mobile code test. On a real phone, trigger an SMS code and see whether the keyboard or browser offers to fill it.
- Recovery path. Run password reset and account unlock through the same checks. Recovery flows are often built last and tested least.
Record failures against the criterion so the fix can be prioritized with the same discipline as any other defect. Automated scanners cannot judge whether a step needs a cognitive function test, so this criterion depends on manual review.
Related criteria worth checking at the same time
Login flows rarely fail one criterion at a time. 3.3.7 Redundant Entry (Level A) asks that information a user already entered in the same process is auto-populated or available to select, which matters in multi-step sign-up. Our look at dragging movements and single-pointer alternatives covers another WCAG 2.2 criterion that tends to hide inside “slider” and “puzzle” style verification widgets. And if your team relies on scripted checks alone, our guide to adding accessibility testing to your CI/CD pipeline explains where automation helps and where manual review has to take over.
Where to start
Pick your most-used sign-in path and run the five checks above this week. Most teams find one or two quick wins, usually a paste handler or missing autocomplete attributes, and a couple of larger items such as an inaccessible CAPTCHA that need design and security input.
If you want an expert review of your authentication flows against WCAG 2.2, Wally’s team can audit the full journey, from sign-up to recovery, and help you scope fixes. You can book a call with an accessibility expert to talk through what a focused review would look like.