An accessible sign-in process lets people reach their account without an unnecessary memory task, transcription task, or puzzle blocking the way. Test the whole route: entering credentials, completing verification, recovering access, and arriving in the expected account state.
This guide explains the WCAG 2.2 authentication criteria and provides a practical audit checklist. It also separates those requirements from the surrounding checks on labels, keyboard access, and feedback. A login screen can support password entry correctly and still have an inaccessible dialog or error response.
Distinguish the AA and AAA authentication criteria
Success Criterion 3.3.8, Accessible Authentication (Minimum), is Level AA. It restricts cognitive function tests in authentication unless a step provides an alternative method, an assisting mechanism, object recognition, or recognition of non-text content supplied by the user. Password-manager support and copy-and-paste can provide assistance.
Success Criterion 3.3.9, Accessible Authentication (Enhanced), is Level AAA. It retains the alternatives and assistance options but removes the object-recognition and personal-content exceptions. Keep the agreed conformance level visible in the test plan; an exception available at AA is not automatically available at AAA.
The minimum criterion focuses on authentication for existing users, rather than initial account creation. If registration belongs to the commissioned audit, include it explicitly and evaluate the applicable requirements. Do not use that distinction to drop the later sign-in or account-recovery steps from the review.
Map every required step and available route
Before testing, list the supported sign-in methods, account roles, verification steps, and recovery routes. Required steps in a multi-factor authentication process need to satisfy the authentication criterion; assistance at the password field does not resolve a barrier at the next challenge.
Use an agreed test environment and safe accounts. Record which provider or component owns each step. A third-party identity screen needs an identified evaluation boundary and access plan, rather than an assumption that another team has already tested it.
| Part of the journey | What to investigate | What to retain |
|---|---|---|
| Credentials | Names, paste behavior, and supported autofill | Environment, entry method, and result |
| Verification | Whole-code entry or an available alternative route | Challenge type, reproduction state, and result |
| Additional challenge | The task required and applicable exception or alternative | Trigger conditions and evaluator reasoning |
| Recovery | A usable route back to the account | Recovery steps, access limitations, and observations |
| Completion | Arrival at the intended signed-in state | Final state with private information redacted |
Identify branches that appear only after an invalid attempt or an expired challenge. If the team cannot reproduce a conditional step, assign a follow-up instead of marking that step tested.
Test assistance on credential fields
W3C's H100 technique describes appropriately named email and password inputs, support for population by browsers and password managers, and allowing users to paste. The technique is a documented way to meet the relevant requirement, not the only implementation allowed by WCAG.
Use a supported password manager or browser credential feature with the test account. Check the actual result, including whether both fields populate and whether the form accepts the populated values. Then test pasting credentials from an approved local source. Do not store passwords in the audit report.
Inspect the field names and purpose information when population fails, and investigate scripts that interfere with entry. Record whether the problem occurs in one tested setup or across the agreed combinations. A screenshot of two empty fields cannot demonstrate that the password manager works.
Check one-time codes in the format supplied
A code split visually across several inputs is not automatically an accessibility failure. The important question is whether the user can enter the complete string without being forced to transcribe it character by character, or can use a qualifying alternative.
W3C failure technique F109 addresses password and code entry that requires a different format and prevents assistance. Its examples distinguish individual code inputs that block full-string paste from inputs that distribute a pasted code automatically.
For a practical test, obtain a synthetic verification code through the agreed test channel and paste the entire value into the challenge. Observe whether the full code is accepted, whether characters are lost, and whether the user can continue. If that route fails, inspect the actual alternative rather than assuming that a link labelled “Try another way” leads to a usable method.
Retain the field structure and reproduction steps while redacting the code itself. Re-test the same interaction after a fix, including any error and retry state needed to complete verification.
Examine challenges and alternatives in context
Write down what the challenge asks the user to do and why the evaluator considers it a cognitive function test. For an AA review, identify the specific permitted exception or assistance relied on. For an AAA review, assess the stricter criterion.
Alternative routes need an end-to-end observation. An email link can be one option: W3C technique G218 describes authentication through an emailed link. If a product uses that method, inspect the request, delivery, link activation, and final account state. An email that arrives but cannot complete sign-in does not establish the outcome.
Use the identity team's approved security design and testing boundaries when evaluating these routes. Record a barrier precisely so that remediation can support access while preserving the intended account protections. Passing an accessibility test does not, by itself, evaluate the security of an authentication method.
Include recovery and surrounding interaction
When recovery authenticates a user through alternative information, it also needs a route that satisfies the applicable authentication requirement. Test the offered process rather than treating recovery as a footer link outside the task.
Use the keyboard checklist to examine navigation, dialogs, and exit behavior. Use the form testing guide to inspect labels, error identification, correction, and status feedback. Keep these observations distinct from the conclusion about cognitive function tests.
For an expired link or rejected code, record whether the user understands the outcome and can reach the offered retry or recovery action. Describe the state you tested. Avoid a universal pass statement when an account permission, delivery dependency, or conditional challenge remains unverified.
Keep a record that supports a focused retest
For an illustrative finding, describe a verification screen where whole-code paste fills only the first input, the remaining digits require manual entry, and no qualifying alternative was found in the tested route. Include the environment, trigger, entry method, relevant requirement, and evaluator's reasoning. Explain any access limitations before generalizing the result.
Assign the correction to the component owner, including a provider owner where appropriate. Retest the complete authentication route after remediation and preserve the observed outcome. The audit evidence handoff guide helps keep those decisions and responsibilities connected.
Saved page evidence in OnChange can help identify changes that warrant review. It does not prove that an authenticated journey was completed, that code delivery worked, or that a password manager populated fields. Attach the manual test record to the release evidence and use the accessibility regression testing guide to select the next review.
Sources and interpretation
The linked W3C Understanding pages and techniques were checked on 6 October 2026. Understanding documents and techniques provide supporting guidance; WCAG defines the requirements. The test matrix and illustrative finding are planning examples from OnChange. Apply them within the agreed accessibility audit scope and document the routes actually evaluated.