Signing in asks whether you are the account holder. Proving your identity asks who you are in the world, and it does that by making you photograph a document, take a picture of your face, wait while something processes, and come back. Those are different screens, usually built by a different vendor, and a sign-in audit reaches none of them.
This page is about the browser-based version of that journey, because that is the one WCAG governs and the one we test. Where an identity check happens in a native application, it is outside this and outside what we sell.
What the Journey Actually Contains
The shape is fairly consistent across providers, which makes it inventoriable, and the inventory is the artifact worth building before anybody quotes.
| Step | Prerequisite for testing | What is in play |
|---|---|---|
| Explanation and consent | None | Whether the reader learns what is about to be asked of them, before the camera opens |
| Choose a document type | None | A radio group or a list of cards, and whether the options are grouped and named |
| Capture route offered | None | Whether an upload alternative exists alongside live capture, which is the whole ballgame for some readers |
| Camera permission prompt | A browser that has not already been granted | Browser interface rather than your content, but the instructions around it are yours |
| Live capture | A device with a camera | Instructions delivered as on-screen prompts, often the least accessible screen in the journey |
| Upload instead | A test document image | The file upload control, and error handling on rejected files |
| Selfie or liveness step | A camera, and a synthetic test identity | Timed prompts, motion instructions, and whether any of it is announced |
| Processing wait | Nothing | A waiting state, which is inside the status message definition |
| Result | A test identity that passes and one that fails | Whether the outcome is announced without focus moving |
| Retry after failure | A deliberately poor capture | Retry limits, which are time limits and error handling at once |
| Manual review or referral | A referral path in the sandbox | Often unreachable in testing, and often the state a real person ends up in |
| Return to the original service | The full round trip | Whether the reader is told where they are, and whether their place was kept |
Twelve steps, and the prerequisite column is why these engagements take planning. Three of them need a camera. Two need a document. One needs somebody at the provider to trigger a referral. And every one of them needs a synthetic identity, because nobody's real passport goes into a test.
The Rule About Recording What You Could Not Reach
Identity journeys are the clearest case for a discipline that matters in every evaluation and gets abandoned here more than anywhere. Four things go in separate columns, and collapsing any two of them makes the report wrong.
- The tested configuration. Which provider, which flow, which browser, which device, which assistive technology, on which date.
- The prerequisites that were met. Which credentials, which sandbox, which test identities were supplied.
- The observed blockers. Something a person actually hit. This includes a step that could not be completed because it was inaccessible, which is a finding rather than a gap.
- The states nobody reached. Steps that were unreachable for a reason unrelated to accessibility, such as an unavailable sandbox or a referral path nobody could trigger.
The distinction that gets lost most often
A missing credential is not a content failure. Nobody should write up we could not get a test account as an accessibility finding. But the reverse mistake is worse and more common. If a screen reader user genuinely could not complete the capture step, that is an observed blocker, and it must not disappear into a line saying the later states were untested. One of those is a gap in the evidence. The other is the finding the whole engagement existed to produce.
Not Every Identity Check Is a Legal or Financial Transaction
Error Prevention (Legal, Financial, Data) gets applied to identity journeys by reflex, and sometimes it does apply. The criterion has four triggering categories, and two of them use defined terms rather than everyday meanings.
Legal commitments is defined and has a broad example list. User-controllable data in data storage systems is defined more narrowly than it sounds, covering data the user can view and change through an intentional action and excluding system data they cannot see. So an identity check that opens a regulated financial account is plausibly inside the criterion. An identity check that lets somebody collect a parcel plausibly is not.
The point is to apply the conditions rather than assume the answer. Where the criterion does apply, it asks for at least one of three safeguards, reversible, checked, or confirmed, and one is enough.
A Published Example of What This Kind of Evaluation Finds
The UK government publishes an accessibility statement for its One Login service, which includes an identity-proving journey, and it is worth reading because it is an honest self-report rather than a sales document.
One entry is exactly the kind of thing only a journey evaluation finds. It records that if you use a screen reader and prove your identity by answering questions about benefits you receive, the landmarks on those pages are different from the landmarks in the rest of the journey. That is the identity step behaving like a different site, which is precisely what happens when a specialist flow is bolted onto a service, and no page-level audit of either half would have caught it.
Two more from the same document. A 60-minute inactivity limit that cannot be adjusted, extended or turned off, filed against Timing Adjustable. And footer links that are not the same on every page, filed against Consistent Help. Both are the sort of finding that only appears when somebody walks the whole journey rather than sampling pages from it.
Dates matter here as much as anywhere. That statement was last reviewed in June 2024, the service was last tested in October and November 2023, and the audit behind it was produced in December 2023. It describes one service at one moment, and reading it as a current description of anything would be a mistake.
Four Things an Identity Audit Cannot Tell You
This is worth stating plainly, because identity work attracts questions that look adjacent and are not.
- Whether your process satisfies any identity regulation. Know-your-customer and anti-money-laundering obligations are legal and regulatory questions with their own specialists. An accessibility evaluation says nothing about them.
- Whether the biometric check is accurate or fair. Face-matching performance across different groups is a serious question and it is not a WCAG question.
- Whether the check resists fraud. Not our field, and not this method.
- How the native app behaves. Many providers offer a phone application as an alternative route. We test browsers, and native application testing is not something we sell.
What an evaluation can tell you is whether a person using a screen reader, a keyboard, magnification or voice control can get through the browser journey you offer, which of the twelve states blocked them, and which nobody could reach. On a journey where failing means being locked out of a bank account or a government service, that is a useful thing to know.
One honest limit
We audit and never repair, and most of an identity journey belongs to a provider rather than to you, so the report keeps their findings in their own pile. Testing needs an authorised sandbox and synthetic test identities agreed in advance. Never send real identity documents through any public form, including ours. Scope it at contact or read what the fintech audit covers.