Accessibility in iOS and Android: My Recent Learnings

Lately, I’ve been diving deeper into accessibility for mobile interfaces. What struck me is that, despite the amount of information available about design, when it comes to making sure apps actually work with screen readers on iOS and Android, the path becomes less clear. That gap pushed me to immerse myself in the subject. Today I want to share what I’ve learned—from my perspective as a designer, with the conviction that our role goes far beyond the visual.

As designers, we often assume accessibility is the developers’ responsibility. But the truth is: we define how the experience is lived—what’s understood, what’s perceived, and what’s felt when interacting with an interface. And that includes people who rely on assistive technologies like TalkBack on Android or VoiceOver on iOS.

1. Why Accessibility Matters in Design

The first thing I realized is that “looking good” is never enough. The real challenge is making sure it works for everyone. And when I say everyone, I mean people with visual, auditory, or motor disabilities. In my daily work, I’ve learned that it’s not about compliance—it’s about opening the digital experience to anyone.

This mindset shift made me rethink how I define every detail in a flow. If a user cannot properly navigate with a screen reader, then my job as a designer isn’t finished.

2. Understanding How TalkBack and VoiceOver Work

To design with accessibility in mind, I first had to put myself in the shoes of those who interact with these technologies. I discovered that gestures—not the mouse or keyboard—are the bridge for navigation:

• Swipe left or right: moves the focus between elements.
• Double tap: acts as a click.
• Swipe up or down: switches between modes or actions within an element.

Recognizing these dynamics helped me imagine what it feels like to move through a screen with eyes closed, relying only on the voice of a screen reader.

3. Facing Reality: Learning with Developers

An essential part of my learning was working closely with developers. That’s when I realized that what we propose in design doesn’t always apply the same way in Android and iOS. This forced me to ground my ideas—distinguishing between what can be implemented today and what remains aspirational.

The key lesson was that each platform has its own rules and behaviors. Sometimes what happens automatically in one system requires more manual configuration in the other. This made me see that, as designers, it’s not enough to follow general accessibility guidelines; we need to understand how each platform actually works so our deliverables are not just theoretical, but truly applicable.

4. Creating Accessibility Annotations in Figma

One of the most concrete advances we achieved as a team was adding accessibility annotations in our Figma deliverables. This transformed how we collaborate with development. Instead of leaving room for interpretation, we provide clear specifications so accessibility is built in from the start.

Some key details we started documenting:

• Accessible name: For example, it’s not enough for a button to just say “Send.” The accessible name should be “Send form.”
• Accessibility hint/description: Adding cues like “Double tap to send” provides extra context.
• Role: Defining whether something is a button, link, or heading prevents confusion for screen readers.

5. Beyond the Visual: Designing for Everyone

One of my biggest lessons was letting go of visuals as the sole focus. Relying only on color to communicate a state—like error or success—excludes many users. Since then, I’ve started thinking in redundancies: text, icons, hierarchy.

Another invaluable moment came from feedback I received from a colleague with a disability. Their observations pushed me to adjust decisions I thought were “done.” That experience reminded me that there’s no better guide than listening to those who live accessibility every day.

6. Learnings Along the Way

Along this journey, I also encountered situations that didn’t go as expected—but each one turned into a valuable lesson.

One was realizing that for most developers, accessibility is also new territory. It requires patience, space to research, and time to experiment with each system’s properties. As a designer, I learned it’s not just about making requests—it’s about supporting and building a shared understanding together.

Another key learning was that accessibility cannot be treated as an afterthought. When it’s left “for later,” it usually becomes a patch that’s difficult to apply—and often gets left out. Instead, when it’s placed on the table from the very beginning, it integrates naturally into both design and development.

Finally, I realized that one of my biggest missed opportunities was not approaching developers earlier in the process. That early dialogue would have helped me understand technical limitations better and deliver clearer, more applicable annotations. Today I know that collaboration is not optional—it’s essential for turning accessibility from theory into practice.

7. Useful Tools in Figma

Along the way, I also found helpful allies that made accessibility easier to integrate into our deliverables:

• Figma’s built-in Color Contrast Checker: when selecting colors with the color picker, you can instantly see contrast ratios between text and background, check WCAG compliance, and even preview color blindness simulations.
• Accessible labeling plugins: to document what a screen reader should announce.
• Include — Accessibility Annotations (eBay): a plugin from eBay that helps add accessibility annotations directly in Figma and guides teams on aspects like alt text, reading order, or contrast. See on GitHub.
• Accessibility Annotation Kits (CVS Health): a library from CVS Health offering annotation templates for iOS, web, and more, designed to capture accessibility details that visuals alone can't convey.

With these tools, our design work gained stronger technical grounding, became more measurable, and was easier to share across design and development teams.

Conclusion

Today, I can confidently say accessibility is no longer a side note in my design process—it’s a pillar. As a team, we’ve learned to document better, listen more, and design for all realities. And while challenges remain, every improvement we make means someone else can use an app with dignity and without barriers.

In the end, designing for accessibility isn’t just about best practices—it’s about recognizing that behind every screen there’s a person, and technology only fulfills its purpose when it’s within everyone’s reach.

---

Thanks for reading this far.. I want to thank the Coppel team, especially the iOS and Android developers, for their patience, time, and openness in exploring accessibility with me. Also, the entire Design team, and most especially Manuel Valdez, for his support, feedback, and for helping make accessibility a true priority in our work. None of what I've learned along the way would have been possible without their collaboration and commitment.