Accessibility | NastyaG

Making Mobile Accessibility Work (When You Never Planned to Deal With It)

Oct 6th , 2025

The Wake-Up Call

“Nobody is disabled until he tries to do something and can’t.”
Alison Ennis, National Australia Bank / Digital Accessibility Specialist

This quote hit me hard the first time I read it.
It crystallized something I’d been struggling to articulate: accessibility isn’t about accommodating a small minority — it’s about removing barriers we’ve unknowingly built.

About a year ago, I was asked to lead an accessibility project at work.
To be honest, I wasn’t excited about it.
After five years in product design, I’d never gone deeper into accessibility than ensuring high color contrast. Suddenly, I was expected to “make the app accessible” — whatever that meant.

I started where everyone does: Online.
But every article I found spoke about why accessibility is important, not how to actually do it.
No one was explaining how to test an app with a screen reader, what “focus order” means, or how to write alt text that’s actually useful.

So, I did what I least wanted to do: I opened the WCAG standard, read all of it, translated it into plain Hebrew, and built a presentation just to understand what applies to us and what doesn’t.

That process changed everything.

What Accessibility Really Means

In digital products, accessibility means designing and developing applications so that people with disabilities can use them effectively and comfortably.
That includes people with visual, hearing, motor, and cognitive impairments.

But accessibility isn’t binary.

Disability is a spectrum. Accessibility is a spectrum.

It’s not just about people who are blind or deaf.
It’s about the person using your app one-handed while holding a baby, or someone trying to read in bright sunlight, or someone recovering from eye surgery.
Inclusive design benefits everyone.

Understanding Visual Impairments

When I started researching accessibility, visual impairments were the biggest eye-opener (no pun intended).
We often think of “blind” and “sighted” as two extremes — but the reality is much more nuanced.
Most people with visual impairments see something — just not in the way you and I do.

Here are six common examples of how people might experience your app differently:

These are not rare edge cases — they represent millions of people globally who use digital products every day.
In the “Unblind Your Apps” study, researchers found that ~1.3 billion people worldwide live with some form of vision impairment, and 36 million are blind.
(Source: arxiv.org)

And closer to home:
In Israel, 18% of the population lives with some form of disability, and for 10%, accessibility features are absolutely critical for digital interaction — that’s about 1.4 million people who may struggle to use the products we design every day.
(Source: Israel Accessibility Association, 2024)

How Users with Visual Impairments Use Their Phones

If you’ve never thought about it, the question seems obvious:
How do people who can’t see well use a smartphone?

The answer: they listen.

Most visually impaired users rely on built-in assistive technologies called screen readers, which read aloud what’s on the screen and let users navigate through gestures instead of visuals.

The two main screen readers are:

VoiceOver (on iOS)
TalkBack (on Android)

With a screen reader turned on, every interaction changes meaning:

Single tap → Selects an item and announces it (e.g., “Next button”).
Double tap → Activates the selected item.
Swipe right or left → Moves through elements in reading order.

Typing on a touchscreen without visual feedback is incredibly challenging — there’s no tactile reference point, no physical keyboard.
That’s why many users prefer voice commands over typing, except when privacy is a concern (like entering banking details).
These small realities completely change how we should think about designing for mobile.

What Is a Screen Reader (and Why It Matters to Designers)

A screen reader isn’t just a robotic voice that reads text aloud — it’s an entire interaction layer between your app and your user.
It interprets what your interface means rather than how it looks.

One of the biggest lessons I learned is that we don’t fully control the final experience.
How a screen reader behaves depends on the user’s phone, system language, settings, and personal preferences.
A button might be read as “Button, Send Money” on one device and “Send Money, Button” on another.
Even pronunciation and reading order can vary dramatically — which is why real-device testing is non-negotiable.

Screen readers rely on semantic structure — every button, field, and label must be coded correctly.

VoiceOver and TalkBack behave differently, so both must be tested.
Language settings, pronunciation, and gestures all impact comprehension.
Focus order defines the entire flow of the experience.

For sighted users, these details seem minor.
For screen reader users, they define whether an app is usable or not.

Why It Matters

Accessibility isn’t just a compliance box. It’s a moral and business imperative.

When I first tested an app using VoiceOver, I couldn’t complete a simple action.

Labels were missing, focus was random, and the experience was confusing.
It wasn’t just frustrating — it was exclusion.

Accessibility means inclusion.
It’s making sure people can participate in digital life without barriers we never intended to build.

The Regulatory Side (In Simple Words)

Here’s what guides most accessibility work:

WCAG (Web Content Accessibility Guidelines) — the global standard for web and app accessibility.
It’s built on four main principles:
1. Perceivable – Users must be able to see or hear the content.
2. Operable – They must be able to navigate and interact with it.
3. Understandable – The information must be clear and predictable.
4. Robust – It must work with assistive technologies now and in the future.

There are three levels of compliance: A, AA, and AAA — most companies aim for AA.
And although WCAG was originally written for websites, it’s still the most relevant reference for mobile apps until a mobile-specific Israeli standard is defined

Choosing the Right Accessibility Approach

Because accessibility is a spectrum, there’s no single “correct” way to do it.
A company has to define for itself how much, where, and how to invest — and what will make the most real-world impact for its users.

It’s easy to fall into the trap of trying to make everything perfect.
But accessibility, like any product effort, needs to be guided by priorities and measurable value.
We called it the Effort & Impact balance — investing enough to make a real difference, but not endlessly chasing compliance for its own sake.

From my research, I’ve seen five main approaches companies can take:

Minimal Screen Reader Adaptation
Fix labels, contrast, focus order.
- Low effort, medium impact.
A solid foundation every app should achieve.
Deep Accessibility Integration
Build accessibility into every design and development cycle.
- High effort, high impact.
Great for mature products with accessibility culture already in place.
Assistive AI Tools
Add voice assistants or AI-based help for complex flows.
- Innovative, targeted impact.
External Accessibility Providers
Plug-ins or SDKs that add accessibility layers.
- Fast to implement, limited flexibility.
Human Support Channels

Offer accessible human touchpoints (chat, phone, etc.) as backup.

- Low effort, high empathy.

Source: Migdal Or Association

The key is to choose deliberately — not to do everything, but to do what matters most.
Each company should ask:

What’s blocking users the most right now?
Which improvements deliver the most immediate value?
How can we make accessibility part of our product routine, not an afterthought?

A Practical Process for Making Your App Accessible

If you’re starting from zero, here’s a simple process to guide you:

1. Test with a Screen Reader

Experience your app as a blind user would.

Turn on VoiceOver or TalkBack.
Try completing one key flow with your eyes closed.
Write down everything that breaks the experience.

2. Prioritize by Impact

Fix critical blockers first — missing labels, broken navigation, low contrast.
Then move to usability enhancers like better hints or improved focus order.
Finally, tackle advanced features like gestures or AI assistants.

3. Work Cross-Functionally

Accessibility is everyone’s responsibility.

Designers: define hierarchy, structure, and color contrast.
Developers: implement semantic roles and ARIA attributes.
QA: test with assistive tech, not just visual review.

4. Build a Checklist

Create reusable accessibility guidelines.

Document patterns for buttons, forms, and modals.
Add accessibility checks to every design and QA process.
Make it part of your definition of done.

5. Test, Iterate, Educate

Accessibility isn’t one-and-done.

Re-test after every release.
Collect user feedback.
Share learnings internally — make accessibility part of your company’s DNA.

Practical Tips for Getting Started

Start small, but start.
Pick one flow and test it with a screen reader — you’ll learn more in an hour than from any article.
Label everything.
Every button, icon, and input field should describe its purpose.
Check contrast and text size.
Aim for a 4.5:1 contrast ratio, and ensure text scales up to 200% without breaking layout.
Define reading order.
The order elements are read must match their visual order.
Test on real devices.
TalkBack and VoiceOver behave differently — test both.
Educate your team.
Accessibility is a culture shift, not a task.

Final Thoughts

When this project landed on my desk, it wasn’t marked as urgent.
Now I believe it’s one of the most important things we’ve ever done.

Accessibility isn’t about disability.
It’s about possibility — about ensuring every person can use what we create.

Accessibility isn’t a destination — it’s an ongoing commitment to inclusive design.
Every product decision is an opportunity to either build barriers or remove them.
The question isn’t whether you can afford to make your product accessible.
The real question is — can you afford not to?

“Nobody is disabled until he tries to do something and can’t.” Alison Ennis, National Australia Bank / Digital Accessibility Specialist

​

This quote hit me hard the first time I read it. It crystallized something I’d been struggling to articulate: accessibility isn’t about accommodating a small minority — it’s about removing barriers we’ve unknowingly built.

​

I started where everyone does: Online. But every article I found spoke about why accessibility is important, not how to actually do it. No one was explaining how to test an app with a screen reader, what “focus order” means, or how to write alt text that’s actually useful.

So, I did what I least wanted to do: I opened the WCAG standard, read all of it, translated it into plain Hebrew, and built a presentation just to understand what applies to us and what doesn’t.

That process changed everything.​

In digital products, accessibility means designing and developing applications so that people with disabilities can use them effectively and comfortably. That includes people with visual, hearing, motor, and cognitive impairments.

But accessibility isn’t binary.

​​​

Disability is a spectrum. Accessibility is a spectrum.​

​

It’s not just about people who are blind or deaf. It’s about the person using your app one-handed while holding a baby, or someone trying to read in bright sunlight, or someone recovering from eye surgery. Inclusive design benefits everyone.​

​​

​

Here are six common examples of how people might experience your app differently:​

If you’ve never thought about it, the question seems obvious: How do people who can’t see well use a smartphone?

The answer: they listen.

Most visually impaired users rely on built-in assistive technologies called screen readers, which read aloud what’s on the screen and let users navigate through gestures instead of visuals.

The two main screen readers are:

VoiceOver (on iOS)

TalkBack (on Android)

With a screen reader turned on, every interaction changes meaning:

Single tap → Selects an item and announces it (e.g., “Next button”).

Double tap → Activates the selected item.

Swipe right or left → Moves through elements in reading order.

​

A screen reader isn’t just a robotic voice that reads text aloud — it’s an entire interaction layer between your app and your user. It interprets what your interface means rather than how it looks.

Screen readers rely on semantic structure — every button, field, and label must be coded correctly.

VoiceOver and TalkBack behave differently, so both must be tested.

Language settings, pronunciation, and gestures all impact comprehension.

Focus order defines the entire flow of the experience.

​​

For sighted users, these details seem minor. For screen reader users, they define whether an app is usable or not.

​​

​

Accessibility isn’t just a compliance box. It’s a moral and business imperative.

When I first tested an app using VoiceOver, I couldn’t complete a simple action.

Labels were missing, focus was random, and the experience was confusing. It wasn’t just frustrating — it was exclusion.

Accessibility means inclusion. It’s making sure people can participate in digital life without barriers we never intended to build.

​

​

Here’s what guides most accessibility work:

WCAG (Web Content Accessibility Guidelines) — the global standard for web and app accessibility.

It’s built on four main principles:

Perceivable – Users must be able to see or hear the content.

Operable – They must be able to navigate and interact with it.

Understandable – The information must be clear and predictable.

Robust – It must work with assistive technologies now and in the future.

​​

There are three levels of compliance: A, AA, and AAA — most companies aim for AA. And although WCAG was originally written for websites, it’s still the most relevant reference for mobile apps until a mobile-specific Israeli standard is defined

​

​

Because accessibility is a spectrum, there’s no single “correct” way to do it. A company has to define for itself how much, where, and how to invest — and what will make the most real-world impact for its users.

From my research, I’ve seen five main approaches companies can take:

​

Minimal Screen Reader Adaptation Fix labels, contrast, focus order. - Low effort, medium impact. A solid foundation every app should achieve.

Deep Accessibility Integration Build accessibility into every design and development cycle. - High effort, high impact. Great for mature products with accessibility culture already in place.

Assistive AI Tools Add voice assistants or AI-based help for complex flows. - Innovative, targeted impact.

External Accessibility Providers Plug-ins or SDKs that add accessibility layers. - Fast to implement, limited flexibility.

Human Support Channels

Offer accessible human touchpoints (chat, phone, etc.) as backup.

- Low effort, high empathy.​​​

Source: Migdal Or Association

The key is to choose deliberately — not to do everything, but to do what matters most. Each company should ask:

What’s blocking users the most right now?

Which improvements deliver the most immediate value?

How can we make accessibility part of our product routine, not an afterthought?

​

​

If you’re starting from zero, here’s a simple process to guide you:

1. Test with a Screen Reader

Experience your app as a blind user would.

Turn on VoiceOver or TalkBack.

Try completing one key flow with your eyes closed.

Write down everything that breaks the experience.

2. Prioritize by Impact

Fix critical blockers first — missing labels, broken navigation, low contrast.

Then move to usability enhancers like better hints or improved focus order.

Finally, tackle advanced features like gestures or AI assistants.

“Nobody is disabled until he tries to do something and can’t.”
Alison Ennis, National Australia Bank / Digital Accessibility Specialist

This quote hit me hard the first time I read it.
It crystallized something I’d been struggling to articulate: accessibility isn’t about accommodating a small minority — it’s about removing barriers we’ve unknowingly built.

I started where everyone does: Online.
But every article I found spoke about why accessibility is important, not how to actually do it.
No one was explaining how to test an app with a screen reader, what “focus order” means, or how to write alt text that’s actually useful.

That process changed everything.

In digital products, accessibility means designing and developing applications so that people with disabilities can use them effectively and comfortably.
That includes people with visual, hearing, motor, and cognitive impairments.

Disability is a spectrum. Accessibility is a spectrum.

It’s not just about people who are blind or deaf.
It’s about the person using your app one-handed while holding a baby, or someone trying to read in bright sunlight, or someone recovering from eye surgery.
Inclusive design benefits everyone.

Here are six common examples of how people might experience your app differently:

If you’ve never thought about it, the question seems obvious:
How do people who can’t see well use a smartphone?

A screen reader isn’t just a robotic voice that reads text aloud — it’s an entire interaction layer between your app and your user.
It interprets what your interface means rather than how it looks.

For sighted users, these details seem minor.
For screen reader users, they define whether an app is usable or not.

Labels were missing, focus was random, and the experience was confusing.
It wasn’t just frustrating — it was exclusion.

Accessibility means inclusion.
It’s making sure people can participate in digital life without barriers we never intended to build.

There are three levels of compliance: A, AA, and AAA — most companies aim for AA.
And although WCAG was originally written for websites, it’s still the most relevant reference for mobile apps until a mobile-specific Israeli standard is defined

Because accessibility is a spectrum, there’s no single “correct” way to do it.
A company has to define for itself how much, where, and how to invest — and what will make the most real-world impact for its users.

Minimal Screen Reader Adaptation
Fix labels, contrast, focus order.
- Low effort, medium impact.
A solid foundation every app should achieve.

Deep Accessibility Integration
Build accessibility into every design and development cycle.
- High effort, high impact.
Great for mature products with accessibility culture already in place.

Assistive AI Tools
Add voice assistants or AI-based help for complex flows.
- Innovative, targeted impact.

External Accessibility Providers
Plug-ins or SDKs that add accessibility layers.
- Fast to implement, limited flexibility.

- Low effort, high empathy.

The key is to choose deliberately — not to do everything, but to do what matters most.
Each company should ask:

Start small, but start.
Pick one flow and test it with a screen reader — you’ll learn more in an hour than from any article.

Label everything.
Every button, icon, and input field should describe its purpose.

Check contrast and text size.
Aim for a 4.5:1 contrast ratio, and ensure text scales up to 200% without breaking layout.

Define reading order.
The order elements are read must match their visual order.

Test on real devices.
TalkBack and VoiceOver behave differently — test both.

Educate your team.
Accessibility is a culture shift, not a task.

When this project landed on my desk, it wasn’t marked as urgent.
Now I believe it’s one of the most important things we’ve ever done.

Accessibility isn’t about disability.
It’s about possibility — about ensuring every person can use what we create.

Accessibility isn’t a destination — it’s an ongoing commitment to inclusive design.
Every product decision is an opportunity to either build barriers or remove them.
The question isn’t whether you can afford to make your product accessible.
The real question is — can you afford not to?