Why I Took on This Challenge
As a mobile software engineer, accessibility has always been important to me, especially when one of my friends is blind, and I wanted to understand how he uses his phone daily more deeply. To do this, I decided to use VoiceOver exclusively for one week: not only to test apps, but to navigate my phone like someone who has recently become blind.
I have to confess that I work daily with VoiceOver and TalkBack, doing accessible apps and solutions at my current job
At first, it was irritating because using my phone became so slow and inefficient. For a person to whom the phone is such a big part of my work and personal life, it was huge.
To not break the challenge, I decided to create some rules just to stay on track with the challenge:
The rules
1 - I would not turn off VoiceOver to expedite things unless completely stuck, unless using an app that will never be adapted for visual blindness, like Waze for driving.
2 - I'd use whatever was already installed on my phone. Of course, I can install new apps, but I'll prefer not to install any visually impaired related apps, but rather expect the accessibility solutions to be in mainstream applications.
3 - I could see my phone screen, but I would only navigate using VoiceOver or with Siri. This rule may be a bit controversial because a visually impaired person wouldn't have this option, but I needed to make sure I can understand the situations to report what went great or bad with this experiement.
Without further ado, let's see what happened...
The Good News: I Made It!
I had made it through the week without quitting. The learning curve wasn't too steep, since I had already known and used many times VoiceOver, but I never used it for an extended period continuously. Within minutes, I realized that unlocking my phone with VoiceOver turned on was a different story, since I always enabled it after I was inside an app for testing purposes.
Overall, I never met the case where an app was simply NOT accessible at all.
The Challenges I Faced
1. Inaccessibility of Apps
One of the biggest challenges was inaccessible apps. Many apps would have modal popups or bottom sheets, but VoiceOver would read content behind them instead of the actual popup content. This happened frequently and made simple tasks frustrating. This often happens when developers don't properly mark modal views as "focused" for screen readers, making VoiceOver continue reading whatever was beneath them.
2. Social Media & Incomplete Information
This was a horrible experience while scrolling through social media feeds. At times, VoiceOver would cut off the caption, and sometimes it was very hard to know what was being said in that post. Multiple-image posts were even worse - the screen reader would jump from image to image without clarifying which caption belongs to which.
3. Typing with VoiceOver
At first, it was painfully slow: VoiceOver reads out each letter as you're navigating the keyboard, so it gets rather frustrating to type out long messages. It wasn't until after two days and a call with my blind friend that I learned about the "one-shot" keyboard mode, in which you'd type normally but rely on VoiceOver afterward for error checking. This greatly improved my typing speed but at the cost of memorizing the keyboard layout.
4. Gesture Conflicts & Navigation Issues
Many apps use custom gestures, such as swipe-to-delete or pinch-to-zoom, which conflict with VoiceOver gestures. This led to confusion—sometimes, I didn't know if the app was unresponsive or if I was simply using the wrong gesture. Navigation became unpredictable, requiring constant workarounds.
5. Maps & Navigation Difficulties
Navigation apps worked fine for turn-by-turn directions, but exploring a map was nearly impossible. VoiceOver could read street names and points of interest, but understanding spatial relationships without visual context was extremely difficult. Planning a route manually was out of the question.
Key Takeaways
Accessibility isn't about making things "readable"; it's about making them usable. Most apps technically "work" with VoiceOver, but if the user can't efficiently complete tasks, then the experience is still bad.
Most accessibility issues can be fixed with minor tweaks. Simply having popups correctly labeled, having images with alt text that makes sense, disabling VoiceOver on icons and other style elements and not allowing custom gestures to interfere with VoiceOver can greatly help in making things more usable.
VoiceOver requires a lot of patience and adaptability. The experience required constant workarounds, learning hidden settings, and adjusting expectations. It made me appreciate how much effort visually impaired users put into using their phones daily.
Moving On
This experience changed how I think about accessibility as a developer. I already tested my apps with VoiceOver & TalkBack from the first design phase, ensuring core interactions are accessible from the start, but now I'm convinced that this is something every developer should advocate for, and force companies/manager to take action for.
I highly recommend any developer, product owner to try VoiceOver for a few hours or a day, it will entirely change how you look at accessibility.
Learn accessibility.
Presently, we are developing a ruleset in my company, helping manager, developers, clients and curious people to learn about accessibility with a detailed book on how to make a digital product accessible.
As it's not ready yet, I cannot share it, but you can follow me on X / Bluesky / LinkedIn where I will share it once it's ready.
Meanwhile, I still want to share documentation that might help you get into accessibility more deeply:
General Apple Documentation on A11Y
Recommendation on each types of disabilities
Android Accessibility
A11ycasts with Rob Dodson
Android Accessibility Codelab
Top comments (0)