TL;DR: Accessible sign-in journeys reduce drop-off and legal exposure, while poor login UX still blocks users who rely on assistive technology, according to Strivacity and the World Health Organization. CIAM is now a customer-facing control point where accessibility, compliance, and trust have to be designed together, not traded off.
NHIMG editorial — based on content published by Strivacity: accessible CIAM, accessibility, and sign-in UX
By the numbers:
- More than 60 percent of users abandon accounts when the sign-in experience is frustrating, according to multiple studies cited by Strivacity.
Questions worth separating out
Q: How should security teams make customer sign-in more accessible without weakening security?
A: Start by testing the full login flow with assistive technologies, then tune authentication so challenges appear only when risk justifies them.
Q: Why does inaccessible login design create an identity governance problem?
A: Because the login screen is the first control point for customer access.
Q: What do teams get wrong about friction in customer authentication?
A: They often treat friction as a user experience issue only.
Practitioner guidance
- Audit sign-in journeys for assistive technology compatibility Test keyboard-only navigation, screen reader labelling, error messaging, focus order, and mobile behaviour across the full customer login flow.
- Treat abandonment as a CIAM governance metric Track login drop-off, password reset failure, and challenge completion alongside authentication success so friction problems are visible in programme reporting.
- Tune adaptive policies to reduce unnecessary challenge steps Review behavioural and contextual rules so step-up prompts are reserved for genuinely elevated risk rather than used as a default gate.
What's in the full article
Strivacity's full article covers the implementation detail this post intentionally leaves for the source:
- Specific sign-up and sign-in options including social login, passkeys, and passwordless flows
- Prebuilt WCAG-compliant UI template guidance for teams that need a practical starting point
- Adaptive access policy examples showing how behavioural and contextual signals reduce friction
- Cross-channel consent and preference management patterns for web, mobile, and partner journeys
👉 Read Strivacity's article on accessible CIAM and sign-in UX →
Accessible sign-in journeys: what IAM teams need to fix now?
Explore further
Accessible CIAM is an identity governance control, not a branding exercise. When the login journey excludes users who depend on assistive technology, the organisation has failed at access as a service, not just at user experience. That failure affects authentication completion, regulated access obligations, and customer trust in the identity layer. Practitioners should treat accessible sign-in as part of the control plane for customer identity, not as a front-end enhancement.
A few things that frame the scale:
- Over 1 billion people globally live with a disability, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how weak identity observability often is across programmes.
A question worth separating out:
Q: How do accessibility standards change CIAM delivery priorities?
A: They turn accessibility into a release requirement rather than an afterthought. Teams should validate customer sign-in journeys against WCAG 2.1 AA and related obligations before launch, then keep testing as flows change across web, mobile, and partner channels.
👉 Read our full editorial: Accessible CIAM is now a governance issue, not just UX