TL;DR: The European Accessibility Act now covers consumer-facing identification and security methods in digital banking, so authentication flows must meet WCAG principles for perception, operability, understandability, and robustness, according to OneSpan. That turns accessibility into an identity governance requirement, not just a UI concern.
NHIMG editorial — based on content published by OneSpan: Répondre à la loi européenne sur l'accessibilité avec le Digipass® Conformité
By the numbers:
- The European Accessibility Act became effective in April 2019, and compliance is required by 28 June 2025.
- The Digipass 750 Comfort Voice includes 10 accessibility-focused features, including voice output and adjustable speech speed.
Questions worth separating out
Q: How should security teams make authentication accessible without weakening assurance?
A: Design the control so users can complete it through multiple sensory and input paths while keeping the trust standard unchanged.
Q: What breaks when consumer authentication is not accessible?
A: Users cannot complete secure access reliably, so support teams create exceptions, workarounds multiply, and the organisation inherits hidden risk.
Q: How do banks know if accessible authentication is actually working?
A: Look for completion rates across user groups, support-assisted sign-in volume, exception requests, and the number of flows that fail under assistive technology testing.
Practitioner guidance
- Map accessibility requirements to identity journeys Review login, step-up authentication, transaction signing, and account recovery against WCAG POUR expectations.
- Test hardware and software authenticators together Validate whether your authenticator options work across screen readers, voice guidance, larger-button devices, and mobile browsers.
- Remove manual-entry traps from high-risk flows Where possible, reduce challenge typing and repeated numeric entry in connected authentication modes.
What's in the full article
OneSpan's full article covers the operational detail this post intentionally leaves for the source:
- Device-level feature breakdown for the Digipass 750 Comfort Voice, including screen, voice, and button behaviours
- Compatibility notes for OneSpan Authentication Suite Server SDK and OneSpan Authentication Cloud
- Product-specific accessibility settings such as speech speed, repetition, and language support
- Implementation context for financial institutions aligning authentication flows with EAA expectations
👉 Read OneSpan's accessibility guidance for Digipass and consumer authentication →
Accessibility in authentication: what EAA means for IAM teams?
Explore further
Accessible authentication is now an identity control requirement, not a design preference. The EAA pushes consumer authentication into the same compliance conversation as the services it protects. That matters because inaccessible identity flows create informal exceptions, support workarounds, and unusable recovery paths. The practitioner conclusion is straightforward: assurance that users cannot complete is not operationally real.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which leaves many identity programmes operating with partial control evidence.
A question worth separating out:
Q: Who is accountable when accessibility rules apply to authentication controls?
A: Accountability sits with the organisation operating the customer identity journey, not only with the product team that built the interface. Compliance, IAM, security, and digital experience owners all share responsibility for proving the control works for users who rely on accessibility support.
👉 Read our full editorial: European accessibility law is reshaping digital authentication