Start with the reassuring part, because this rule gets sold as a crisis and it is not one. W3C publishes a passing example of the WCAG 2.2 authentication rule, and it is an ordinary email and password form. A real label on each field, autocomplete set correctly, and a field that accepts a paste. That is the technique. Our fix guide has the markup, and it is about eight lines long.
So a password is not the problem. What people do around passwords is. A form somebody cannot complete is bad, and a sign-in somebody cannot complete is worse, because everything they own sits behind it. That is why WCAG 2.2 added 3.3.8 Accessible Authentication at Level AA, and it is one of the few criteria that asks you to remove something rather than add something.
The Rule, Plainly
No step in your sign-in may require a cognitive function test unless that step provides one of four escapes. Another authentication method that skips the test. A mechanism that helps the user get through it. A test that only asks somebody to recognize objects. A test that only asks them to identify content they supplied themselves. A cognitive function test means remembering something, solving a puzzle, or transcribing.
- Remembering a password is a cognitive function test. It passes because you let a password manager fill it, and paste is allowed. That is the mechanism escape, not the alternative one, and the difference costs real money. Naming the wrong escape tells a client they have to build a second way to sign in when supporting a password manager was enough.
- A puzzle CAPTCHA is a cognitive function test. Recognizing objects and identifying your own content are excepted, so picking out the pictures with a bus in them is permitted where solving a puzzle is not.
- Transcribing a code from another device is a transcription test. Allowing paste, and supporting the browser's one-time-code autofill, is what makes it pass.
Three scope facts decide what actually goes in a report. Every step has to pass, so a multi-factor flow needs a complete path through it that never asks for a cognitive function test, not merely a compliant first screen. Account recovery counts as authentication, so a recovery flow gated on a security question is a finding. And creating an account is outside the criterion entirely, so a CAPTCHA on your sign-up form is not a 3.3.8 problem, whatever else it might be. There is a small carve-out inside the definition as well. Name, email address and phone number do not count as memorization, because they are personal to the user and the same everywhere, which is why the passing example asks for an email rather than a username.
The failure we find most
Blocking paste into the password field. It is meant as a security measure, and the security profession has been arguing the other way for years, which is why W3C's own reading list for this criterion points at national cyber security guidance rather than at anything about accessibility. Whatever the security argument turns out to be, blocking paste removes the exact mechanism the standard relies on to tolerate passwords at all.
The Two-Step Test Anybody Can Run
W3C's technique comes with a test procedure that is two steps long, and it is a better first pass than anything a tool will give you. Does every authentication input have an appropriate accessible name. Does every authentication input allow pasting. Both have to be true. The first one is why the accessible name matters as much as the autocomplete attribute here, because browsers and password managers use the name to work out how to fill a field.
There is a bonus in that technique most people miss. The same markup is sufficient for 3.3.9, the Level AAA version of the rule, which is unusual. AAA removes the object recognition and personal content escapes and keeps the mechanism escape, so a properly built password form clears the enhanced criterion as well. If a public sector contract has put AAA in front of you, that is the sentence to read out.
Let the Password Manager Work
Everything about a password field should assume a manager is filling it, because that assumption is what the standard is built on.
- Use
type="password"and a reallabel, never a placeholder standing in for one. A field with no accessible name fails 4.1.2 and stops the manager recognizing it at the same time. - Set
autocomplete="current-password"on sign-in and"new-password"on registration, which is also 1.3.5 Identify Input Purpose. Use"one-time-code"on a verification code field. - Never block paste, and never strip characters on paste.
- Never split a code or a password across separate one-character inputs. This is a named failure with its own number, and the test is simpler than it looks. What fails is preventing a paste in a single action, whatever
autocompletetokens the boxes carry. The six-box one-time-code input where pasting fills only the first box is the classic. So is the bank asking for the first, third and fifth characters of your password, which is one of W3C's own worked failure figures.
CAPTCHA Passes at AA and Fails at AAA
Recognizing objects is excepted at Level AA, and the exception disappears at AAA. Object means the ordinary English sense, a material thing you can see and touch, and vehicles and animals count. What does not count is a test that goes past recognition. Asking somebody to multiply the number of cats by the number of dogs is arithmetic, and arithmetic is not recognition. A mathematical CAPTCHA fails. So does a visual logic puzzle.
Text-based personal content does not qualify either, and this is the sharp one. The personal content escape covers non-text content the user gave you, such as picking out a photo they uploaded. A security question fails, because remembering your first pet's name is recall rather than recognition and typing it is transcription rather than selection. Recovery flows in banking and insurance run on security questions and this is where they land.
Two more things about CAPTCHA that change how you test and how you argue. A CAPTCHA that only fires sometimes, after a few failed attempts or when an ad blocker is present, is in scope anyway, so one clean sign-in proves nothing about your login. And an audio alternative does not rescue a CAPTCHA if the audio has to be transcribed, because transcription is the thing the rule is about. When a security team says the CAPTCHA is not negotiable, W3C names three things that reduce how often one has to appear, which are rate-limited access, client geo-location, and private client authentication. None of them is fully effective, and W3C says so.
Worth knowing that W3C passes object recognition and personal content while recommending against both. Its own words are that these techniques do not fully support the cognitive accessibility community and should be avoided where possible. Personal content carries a security caution too, since somebody who is not you may well guess which photo is yours when shown a choice of four.
Two-Factor Is Not the Problem, Transcription Is
A second factor is fine and the standard says so explicitly. Hardware keys, a secondary app that asks you to confirm it is really you, and the operating system's own biometrics are all cleared by name, because none of them is a cognitive function test. Push to approve conforms with no further work from you.
What fails is the six-digit code you have to read off one screen and type into another. And the boundary here is narrower than people expect. Whether the code can travel cleanly from the phone to the laptop is outside the criterion. All the criterion asks is whether the field will accept a paste. That is the whole test, and it is one you can run in ten seconds.
Passkeys and third-party sign-in are good answers to this and neither is yet a documented sufficient technique, so treat them as sound practice rather than as a conformance route. The one alternative route W3C does publish is the email link, where somebody types their address and gets a time-limited link back that signs them in.
The Show-Hide Toggle
Letting somebody see what they typed is a genuine accessibility feature, and W3C names the audience more broadly than we used to. People with cognitive disabilities, and anybody who has difficulty typing accurately. It is recommended rather than required, and it is usually built as a bare icon with no name and no state.
- It is a button, not a checkbox styled as an eye.
- Pick one way of reporting the state and stick to it. Either the accessible name changes, from Show password to Hide password, and you set no
aria-pressedat all. Or the name stays put andaria-pressedcarries the state. Doing both is the common bug, and it announces the state twice with two different words for it. - Keep the target big enough to hit. 2.5.8 wants 24 by 24 CSS pixels, and an eye icon tucked inside the field's right-hand edge is the thing that usually misses it.
State the Rules Before They Type
Password requirements revealed only in an error message after a failed submission are the small cruelty of sign-up forms. Put them next to the field and tie them to it with aria-describedby, which is 3.3.2 Labels or Instructions.
If you validate as somebody types, announce it politely rather than assertively. A checklist that updates silently is invisible. One that interrupts on every keystroke is unusable. The balance is covered in notifications and toasts.
Errors That Do Not Help
Invalid credentials is deliberately vague, and that is a security decision rather than an accessibility one. The error rule asks that a failure be identified and described in text, and on a sign-in form the thing in error is the whole form, so a generic message is defensible. Where it stops being defensible is registration. Password too weak should say what would make it strong enough, and that is 3.3.3 Error Suggestion rather than the authentication rule, because creating an account sits outside 3.3.8 altogether. Write it up under the right criterion or it comes back.
Whatever the message says, it has to reach a screen reader rather than only appearing on screen, which is 3.3.1 doing its job.
One honest limit
No automated rule exists for this criterion at all. Not one has been written, so every part of it is a manual check, and the conditional CAPTCHA problem makes even a manual check harder than it looks. A login that behaves perfectly on your first attempt may put a puzzle in front of somebody on their fourth, or in front of anybody running an ad blocker, and that puzzle is in scope whether or not your tester ever saw it.