Accessible authentication and WCAG 2.2 AA: are your controls ready?

TL;DR: WCAG 2.2 AA now makes cognitive function tests incompatible with accessible authentication flows, and the source article argues that biometric approaches can help organisations serve a broader user base while meeting accessibility requirements, according to iProov. Accessibility is no longer a UX layer added later; it is a design constraint that changes how identity teams evaluate assurance, onboarding, and user exclusion risk.

NHIMG editorial — based on content published by iProov: accessibility and inclusivity in biometric authentication under WCAG 2.2

By the numbers:

• The article says 1 billion people, approximately 15% of the world’s population, live with some form of disability.
• The article says the UK Government Digital Service began monitoring the extra WCAG 2.2 criteria in October 2024.

Questions worth separating out

Q: How should security teams make authentication more accessible without weakening assurance?

A: Treat accessibility as part of the control design, not a post-launch enhancement.

Q: Why do traditional password-based login flows create accessibility risk?

A: Password-based and recall-heavy login flows depend on memory, typing, and repeated user effort, which can exclude people with cognitive, visual, or motor constraints.

Q: How do organisations know if an authentication flow is truly inclusive?

A: Look for completion rates, error rates, and abandonment across user groups and device types, then test whether the flow still works when users have limited dexterity, low vision, or cognitive load.

Practitioner guidance

• Audit authentication journeys for excluded steps Map every login, recovery, and step-up path for memory tests, puzzles, time pressure, and device manipulation that can block users with accessibility needs.
• Require accessibility evidence in procurement Ask vendors for WCAG 2.2 AA and Section 508 test results that cover the exact SDKs, browsers, and mobile platforms you use in production.
• Design for assisted and alternative channels Make sure kiosks, shared devices, and in-person assistance can complete the same identity assurance objective without creating a separate, weaker workflow.

What's in the full article

iProov's full article covers the operational detail this post intentionally leaves for the source:

• The specific WCAG 2.2 AA and Section 508 testing claims made about its SDKs across Web, iOS, and Android.
• The article's explanation of passive versus active biometric authentication and how the user journey differs.
• The regulatory discussion around UK public-sector monitoring, EU accessibility obligations, and US legal defensibility.
• The vendor's own checklist framing for buyers evaluating accessibility and inclusivity in biometric authentication.

👉 Read iProov's analysis of WCAG 2.2 accessibility and biometric authentication →

Accessible authentication and WCAG 2.2 AA: are your controls ready?

Explore further

View Full Forum →  |  NHI Foundation Course →