What are the best ways to evaluate whether a customer sign-in journey is inclusive?

What makes a customer sign-in journey inclusive?

An inclusive sign-in journey works for more than the average user path. It supports different abilities, devices, input methods, and levels of familiarity without forcing people to compensate with extra steps. That means the evaluation needs to cover the whole flow, from entering credentials to recovering access, not just whether the form submits successfully.

Inclusivity is less about a single login screen and more about whether the journey remains usable when someone relies on a screen reader, keyboard navigation, magnification, voice input, or a mobile device. It also includes whether instructions, error handling, and recovery paths are clear enough that a user can complete the journey without outside help.

It is useful to treat the sign-in flow as a sequence of moments: discovery, credential entry, challenge or verification, error recovery, and completion. A journey can be technically functional and still exclude users if any one of those moments becomes ambiguous, time-sensitive, visually dependent, or difficult to recover from.

How do you test whether people can actually complete it?

The strongest test is to run the journey end to end with the assistive technologies and input methods your users actually rely on. If keyboard-only use breaks at any point, if a screen reader does not announce state changes, or if an error is only visible visually, the journey is not inclusive even if it passes a basic functional test.

Beyond tooling, the test should include real task completion, not just page inspection. Measure whether a user can understand the challenge, recover from a mistake, and finish the same journey across desktop and mobile without added friction. The question is whether the path is equally operable, not whether the UI is merely compliant in isolation.

Review the flow against the accessibility standard your organisation has committed to, then verify the details that standards often expose: focus order, labels, contrast, timeouts, error messaging, and whether the control sequence makes sense when navigation is linear. Standards help structure the review, but the journey outcome is what tells you whether the experience is inclusive.

Where do barriers usually appear in a sign-in flow?

Common barriers show up where the journey depends on perception or timing. Poorly labelled fields, unclear password rules, inaccessible multi-factor prompts, unexpected session timeouts, and errors that do not explain how to recover can all block completion. These issues often affect users differently depending on device, ability, and context.

Abandonment data is especially valuable because it shows where the journey loses people rather than where it merely frustrates them. A spike at one step can indicate a broken control, but it can also reveal that the step is too demanding for some users. Tracking completion by step helps separate a minor usability issue from a barrier that is effectively exclusionary.

Watch for patterns such as repeated retries, exits after challenge screens, and increased failures on mobile or at low bandwidth. Those signals often point to a journey that assumes stable vision, precise pointer use, or uninterrupted attention. For a good reference point on designing security that is usable by default, see CISA Secure by Design.

Practitioner Guidance

What to prioritise: Start with the steps that most often create exclusion, which are challenge screens, error handling, and recovery. Those are the points where a small design flaw can turn a valid sign-in attempt into a dead end.

What to verify: Confirm that each step is operable by keyboard, readable by assistive technology, and understandable without visual-only cues. Also verify that the same journey works on the lowest-capability device you still support, because inclusivity problems often surface there first.

What to measure: Track completion, abandonment, retries, and recovery success at each step, then segment by device and interaction mode where possible. A journey that is technically accessible but consistently drops users at one step is not inclusive in practice.

Practitioner takeaway: Treat inclusivity as a journey-quality problem, not a page-quality problem, and judge it by whether real users can complete the full sign-in path independently.

Related resources from NHI Mgmt Group

• How should IAM teams evaluate FedCM for customer sign-in?
• How do security and public-sector teams evaluate whether a digital identity ecosystem is inclusive enough?
• How should insurance teams evaluate whether digital underwriting and claims tools actually improve customer experience?
• How should teams evaluate CIAM capabilities when customer sign-in needs to be faster and easier?