.png&w=3840&q=75)
Security is supposed to protect customers.
For one banking client, it was also becoming a barrier.
The bank had been receiving complaints from customers struggling to complete security verification during login, password recovery, account unlock, and high-risk transactions.
The core banking experience worked reasonably well. The problems appeared when customers were pushed into additional security checks.
An incorrect password, a new device, or a suspicious transaction could trigger OTPs, timers, identity checks, confirmation screens, and recovery steps.
For customers using assistive technologies, those extra layers could make it difficult to regain access independently. The bank needed to keep its security controls in place. The challenge was making sure those controls did not block the people they were meant to protect.
The Challenge
When we tested the verification and recovery flows, no single issue explained the complaints.
The problem was the way several small barriers accumulated.
OTP fields were split across multiple inputs, with focus sometimes moving automatically from one field to another. Screen reader and keyboard users could lose track of where they were.
Timers were visible but were not always communicated clearly through assistive technology. Customers sometimes knew a code had expired only after attempting to submit it.
Error messages told users that verification had failed, but not always why it failed or what they needed to do next.
Some failures also forced users to restart the entire process.
The same pattern appeared throughout the journey: customers were being asked to complete security-sensitive actions without always being given enough information about what had happened, what was expected next, or whether their action had succeeded.
For a banking customer already dealing with a blocked login or suspicious transaction, that uncertainty mattered.
Why It Mattered
Customers who could not complete verification independently often turned to support.
Others repeated actions because they were unsure whether a code had been accepted or whether another step was required. In some cases, repeated attempts triggered additional restrictions and made account recovery even harder.
What was designed as a self-service security journey was creating more support work and more frustration.
It was also affecting trust.
When someone is trying to regain access to a bank account, clarity is part of the security experience. Customers need to know what is happening and what they need to do next.
Accessibility was not separate from that experience.
It was part of whether the security process worked at all.
How We Approached It
We stopped looking at OTP fields, error messages, and dialogs as separate accessibility issues.
Instead, we tested complete security journeys:
Login → Verification → OTP → Confirmation
Password reset → OTP → New password → Account access
Suspicious transaction → Identity check → Recovery
At every stage, we asked three questions:
Can the customer understand what is happening?
Can they complete the step independently?
Can they recover if something goes wrong?
This helped separate genuine security requirements from interaction patterns that had accumulated over time.
What Changed
The bank kept its security requirements, but simplified the experience around them.
OTP entry became more predictable. Instructions were shortened and placed closer to the actions they explained. Customers received clearer warnings before codes expired and could request another code without restarting the entire journey.
Error messages explained both what had happened and what to do next.
Focus behavior was improved so important errors and confirmations were easier to find with a keyboard or screen reader.
Visual instructions were supplemented with text, and successful verification was confirmed clearly.
Most importantly, one failed step no longer had to mean starting over.
The Outcome
The goal was not to remove security checks.
It was to help more legitimate customers complete them successfully.
After the changes, the bank saw fewer failed OTP attempts, fewer accessibility-related complaints, and fewer support contacts connected to password recovery and account unlock.
- 22% fewer failed OTP verification attempts
- 24% fewer accessibility-related complaints around login and verification
- 17% fewer support contacts related to password reset and account unlock
The security controls remained. Customers were simply better able to complete them.
What We Learned
Security and accessibility do not have to compete.
The bank did not need to weaken fraud controls to improve the experience. The most effective changes came from making security steps easier to understand, navigate, and recover from.
For this client, accessibility helped create a security journey that continued to protect the account without becoming another barrier to accessing it.