Skip to main content
WCAGrules
Quick navigation

Guides · Testing and tools

Every Step of Signing In Gets Tested Separately

The rule asks whether a complete path exists that never makes somebody remember or transcribe anything. One step can break it, so the audit has to reach all of them.

Last reviewed August 31, 2026

WCAG 2.2's authentication rule is evaluated at each step of the process, and it asks for one complete path through that never requires a cognitive function test. Not a majority of steps. A path. Which means an audit of your sign-in is an audit of every state it can put somebody in, and the interesting work is reaching them rather than judging them.

That framing is why this page is a worksheet rather than an explainer. The judgment calls are mostly easy once you are standing in the state. Getting into a locked account, an expired code, a device-not-recognised challenge and a password reset, on a system somebody else runs, is the part that needs planning.

What the Rule Actually Prohibits, and the Four Ways Out

Accessible Authentication (Minimum) prohibits a cognitive function test at any step of authentication unless that step provides at least one of four things. An alternative method that does not rely on one. A mechanism that helps the user complete it. Object recognition, where the test is to identify objects. Or personal content, where the test is to identify non-text content the user provided.

A cognitive function test is a task that requires somebody to remember, manipulate or transcribe information. The definition names five example categories, and it explicitly carves out three things people assume are covered. Your name, your email address and your phone number are not cognitive function tests, because they are common identifiers rather than things you were asked to memorise.

At Level AAA the list shrinks to two. The enhanced version keeps alternative and mechanism, and drops object recognition and personal content. So the same image CAPTCHA passes at AA and fails at AAA, which is a clean answer to a question people ask constantly.

This rule does not ban passwords

H100, a properly marked up email and password form, is listed by W3C as a sufficient technique for both the AA and the AAA version. A password field is fine, because a password manager can fill it and a person can paste into it. What breaks the rule is a field that stops them, which is why the only documented failure here, F109, is about preventing a password or code from being re-entered in the same format. The six-box one-time-code widget is the version you will meet most often, because it defeats a single paste.

Where the Rule Starts and Stops

Three scope facts change a test plan more than any amount of technique reading, and all three surprise people.

  • Account recovery is in scope. Password reset and credential change are authentication for this criterion, so the reset journey gets the same treatment as the sign-in.
  • Account creation is not. The criterion covers authenticating existing users. Signup is outside it, though every other rule about forms, labels, errors and redundant entry still applies to it.
  • Getting the code from your phone to your laptop is outside the test. W3C says so directly. When a code arrives on a second device, whether it can travel to the first is not part of evaluating this criterion. All that is tested is whether the field accepts a paste. The difficulty is real, and it belongs in the report as an observation rather than a criterion failure.

One more, which is good news for anybody being told to rip out their security. Hardware keys, push confirmations and platform biometrics are explicitly cleared. They are not cognitive function tests, because nobody is being asked to remember anything.

The Authentication Test-State Worksheet

This is the artifact. Every row is a state somebody has to be put into, and the middle column is the one that decides whether the engagement can start, because most of these states need something from your side.

StateWhat the tester needs to reach itWhat is in play
First sign-in with a passwordA working test accountLabels, autocomplete tokens, paste behaviour, the show-password control
Wrong passwordPermission to fail a few timesError identification, and whether focus goes to the message
Locked or throttled accountA disposable account, and a way to clear the lockThe message, the wait, and whether the wait is announced
MFA prompt appearsA test account with MFA enrolledWhether the second factor is announced as a new step or just redraws
Code entryA code delivery route the tester can readPaste into a single field, or the F109 failure if the field is split
Code resend and expiryTime, and patienceA time limit set by the content, so Timing Adjustable applies
Backup or recovery codeCodes issued in advanceSame paste question, usually a longer string
Passkey enrolmentA device with a platform authenticatorThe browser's own dialog is not your content, but everything around it is
Passkey sign-inAn enrolled accountWhether a keyboard-only route to trigger it exists
Unrecognised device challengeA clean browser profile, or a VPNOften the state nobody tests, and often the worst one
CAPTCHA appearsA trigger, which may need repeated failuresTwo criteria at once, covered below
Password reset requestedAccess to the mailboxIn scope, because recovery is authentication
Reset link followedThe email, opened where the tester isA new page, often on a different template
New password setNothing extraRequirements stated up front, and paste allowed
Re-authentication after timeoutA long enough waitRe-authenticating and whether data survives
Illustrative authentication test states. Build your own against your real flow, and settle the access column before testing starts.

Fifteen rows, and a typical evaluation reaches maybe nine of them without help. That is the real message of the worksheet. The states you cannot reach are not clean, they are unevaluated, and the report has to say which is which.

CAPTCHA Answers to Two Rules, Not One

A CAPTCHA can satisfy the authentication rule through the object recognition exception and still fail a different criterion entirely, which is the part teams miss.

Non-text Content has a CAPTCHA situation, and it is conjunctive. It requires a text alternative that identifies and describes the purpose of the CAPTCHA and alternative forms using output modes for different types of sensory perception. Both halves. The sufficient techniques are named as a pair for exactly that reason. So a visual challenge with a clear label and no audio alternative has met one half of one rule.

None of which makes CAPTCHA forbidden. It makes it a control that needs a second modality and a described purpose, and at Level AAA it needs something that is not a cognitive function test at all.

Security Timers Are Covered, With One Named Exception

"It is a security requirement" is not an exception in WCAG. A security-motivated time limit is a limit set by the content, and the content-set limits are the ones the timing rule covers.

There is one carve-out and it is narrow. W3C says time-limited two-factor tokens specifically can be considered essential, and the essential exception is available where removing the limit would fundamentally change the activity and the same result cannot be achieved another conforming way. That covers the six-digit code that expires in thirty seconds. It does not cover the session timeout, which is why sessions and timeouts is a separate conversation with its own numbers, starting at 20 seconds of warning and ten available extensions.

No Scanner Is Going to Tell You Any of This

There is no ACT rule for either authentication criterion. W3C's index says so plainly for both, which puts them in the same position as 49 of the 86 success criteria, and it is why a clean automated report on a login page proves almost nothing about the login.

What automation does reach here is the ordinary form work underneath. Fields with no accessible name, missing autocomplete tokens, contrast on the submit button. Worth running, and finished in a minute. The states in the worksheet are a person, every time, which is the general case our automated versus manual guide covers.

One honest limit

We audit and never repair, so nothing here is an offer to rebuild your sign-in. And we have no opinion on whether your authentication design is secure, because that is a different profession. What an evaluation produces is the states that were reached with their findings, and a named list of the states that were not, which is usually the most useful page in the report. Scope it at contact or read what the login and signup audit covers.

Common questions

Does WCAG 2.2 ban passwords?
No. A properly marked up email and password form is listed by W3C as a sufficient technique for both the AA and the AAA authentication criteria, because a manager can fill it and a person can paste into it. What fails is preventing that paste, which is the only documented failure for either criterion.
Are CAPTCHAs allowed?
At Level AA an object-recognition CAPTCHA is excepted, so it can satisfy the authentication rule. It still has to satisfy Non-text Content, which requires both a text alternative describing its purpose and an alternative form using a different sensory modality. At Level AAA the exception is gone.
Is our six-box one-time-code field a failure?
It is the shape of the documented failure, because splitting a code across separate inputs defeats a single paste. The fix is a single field that accepts the whole code, and it is usually a small change.
Does the rule cover creating an account?
No. It covers authenticating existing users, so sign-in and account recovery are in and signup is out. Every other rule about labels, errors, redundant entry and input purposes still applies to signup, so it is not unregulated, just outside this one criterion.
Can a scanner check our login page?
It can check the form underneath, which is worth doing. It cannot check this criterion, because there is no ACT rule for either version of it. That puts authentication among the 49 of 86 criteria with no automated rule at all.
Our MFA code arrives on a phone. Is that a problem for the audit?
Getting the code from the second device to the first is explicitly outside the test for this criterion. What is tested is whether the field accepts a paste. If the cross-device step is painful, it goes in the report as an observation, which is honest and still useful.

Sources

Keep reading

More on testing and tools

Reading about it is the cheap part.

Find out where your site actually stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, keeps its 27 best-practice checks separate from WCAG findings, and names the rule behind every finding. The full audit adds an expert review and a real blind screen-reader user. From $499, with the report in 5 business days on Rapid and 10 on Standard, and the clock starting at cleared payment.

Go somewhere useful

Find tools, resources and your workspace.

29 destinations