By Dheeraj

Imagine This…

A visually impaired customer wants to log in to their banking application.

The app sends a One-Time Password (OTP) to their registered email address. Unlike an SMS, there is no automatic OTP detection. The user switches to their email app, navigates through multiple messages using a screen reader, locates the latest email, listens to the content, memorizes the code, and returns to the banking app.

By the time they return, the session has expired.

The application was designed to be secure.

But was it designed to be usable for everyone?

Accessibility vs Security — A False Choice

When accessibility issues are raised during development, one common concern is:

“Won’t making this accessible reduce security?”
The answer is usually no.

In most cases, accessibility doesn’t weaken security. It exposes assumptions in the design.

Good accessibility doesn’t remove security controls. It ensures legitimate users can successfully complete secure tasks independently.

Example 1: Email OTP

For many users, retrieving an email OTP takes only a few seconds.

For someone using a screen reader, the journey is significantly longer:

Application

         ↓

Email application

         ↓

Navigate Inbox

         ↓

Open latest email

         ↓

Locate OTP

         ↓

Remember OTP

         ↓

Return to application

         ↓

Find OTP field

         ↓

Enter OTP

Every additional navigation step increases the time required.

If the authentication session expires before the OTP can be entered, the user is forced to restart the process or rely on another person to read the code.

This is not a failure of security. 

It is a workflow that assumes all users retrieve information at the same speed.

Better Design

Rather than weakening authentication:

• Allow reasonable OTP validity.
• Keep the session active while the OTP remains valid.
• Provide an easy “Resend OTP” option.
• Support passkeys or authenticator applications where appropriate.

The security objective remains unchanged.

The experience becomes inclusive.

Example 2: Password Privacy

Consider another common scenario.

A developer notices that blind users sometimes struggle to verify passwords during entry.
Their solution?
“Let’s automatically reveal the password whenever TalkBack is enabled.”

At first glance, this seems helpful.

In reality, it creates a security risk.

Imagine entering your banking password in:

• A crowded office
• Public transport
• An airport
• A café

If the screen reader announces the complete password aloud, nearby people can overhear sensitive credentials.

The application has unintentionally reduced the user’s privacy.

A Better Solution

Instead of automatically exposing the password:

• Keep passwords protected by default.
• Provide an accessible Show Password button.
• Allow users to decide whether they want to reveal the password.

Accessibility should provide choice, not remove security protections.

Accessibility Doesn’t Mean Lower Security

This is perhaps the biggest misconception.

Accessibility is not about making systems less secure.

It is about ensuring that security mechanisms are usable by everyone.

Examples include:

Shared Principles

Although accessibility and cybersecurity focus on different goals, they share common principles.

Accessibility asks:

Can every legitimate user complete this task independently?

Cybersecurity asks:

Can only legitimate users complete this task?

When both questions are answered together, the result is a secure and inclusive experience.

Designing for Trust

The strongest digital products don’t force teams to choose between accessibility and security.

They achieve both by designing thoughtfully.

A secure application that excludes some users has failed part of its purpose.

An accessible application that compromises user privacy has failed another.

True digital trust exists only when people can access services independently and confidently know that their information remains protected.