Accesibilidad en iOS y Android: mis aprendizajes recientes

Últimamente he estado profundizando en accesibilidad para interfaces móviles. Lo curioso es que, a pesar de la cantidad de información que existe en la web sobre diseño, cuando se trata de asegurar que las apps funcionen correctamente con lectores de pantalla en iOS y Android, el camino se vuelve menos claro. Ese vacío fue lo que me impulsó a sumergirme en el tema. Hoy quiero compartir lo que he aprendido, desde mi perspectiva de diseñador y con la convicción de que nuestra labor va más allá de lo visual.

Como diseñadores solemos pensar que la accesibilidad es responsabilidad del equipo de desarrollo. Pero en realidad, somos nosotros quienes definimos cómo se vive la experiencia: qué se entiende, qué se percibe y qué se siente al interactuar con una interfaz. Y eso también incluye a las personas que dependen de tecnologías de asistencia como TalkBack en Android o VoiceOver en iOS.

1. La importancia de la accesibilidad en el diseño

Lo primero que comprendí es que no basta con que una app “luzca bien”. Nuestro verdadero reto es que funcione para todos. Y cuando digo todos, incluyo a personas con discapacidad visual, auditiva o motriz. En mi día a día, he aprendido que no se trata de cumplir una norma, sino de abrir las puertas de la experiencia digital para cualquiera.

Este cambio de mentalidad me llevó a replantear cómo defino cada detalle en un flujo. Si un usuario no puede navegar correctamente con un lector de pantalla, significa que como diseñador no he terminado mi trabajo.

2. Entendiendo cómo funcionan TalkBack y VoiceOver

Para diseñar pensando en accesibilidad, primero tuve que ponerme en los zapatos de los usuarios que interactúan con estas tecnologías. Descubrí que los gestos —no el mouse ni el teclado— son el puente para navegar:

• Deslizar izquierda o derecha: mueve el foco entre elementos.
• Doble toque: actúa como clic.
• Deslizar arriba o abajo: alterna entre modos o acciones dentro de un elemento.

Reconocer estas dinámicas me ayudó a imaginar cómo se siente recorrer una pantalla con los ojos cerrados, solo confiando en la voz de un lector.

3. Toparme con la realidad: aprendiendo con los desarrolladores

Un punto esencial en mi aprendizaje fue acercarme directamente a los desarrolladores. Ahí entendí que lo que proponemos en diseño no siempre se aplica de la misma manera en Android e iOS. Esa diferencia me obligó a aterrizar mis ideas: distinguir entre lo que es posible implementar hoy y lo que todavía queda en el terreno de lo aspiracional.

Lo interesante es que cada sistema operativo tiene sus reglas y comportamientos propios. A veces lo que en uno ocurre de forma automática, en el otro requiere configurarse con más detalle. Esto me hizo ver que, como diseñadores, no basta con seguir guías generales de accesibilidad; necesitamos comprender cómo funcionan las plataformas para que nuestras entregas sean realmente útiles y aplicables.

4. Creando anotaciones de accesibilidad en Figma

Uno de los avances más concretos que logramos en el equipo fue incluir anotaciones de accesibilidad en nuestros entregables de Figma. Esto cambió la manera en la que colaboramos con desarrollo. En lugar de dejar que interpreten, les damos especificaciones claras para que la implementación sea accesible desde la raíz.

Algunos puntos clave que empezamos a documentar:

• Accessible name (Nombre accesible): por ejemplo, no basta con un botón que diga “Enviar”. El accessible name debe ser “Enviar formulario”.
• Accessibility hint/description (Pistas o descripciones): agregamos indicaciones como “Doble toque para enviar” para dar contexto adicional.
• Role (Rol de los elementos): diferenciamos correctamente entre botones, enlaces o encabezados para evitar confusión con los lectores.

5. Más allá de lo visual: diseñar para todos

Una de mis mayores lecciones fue desapegarme de lo visual como único eje. Descubrí que confiar solo en el color para transmitir un estado —como error o éxito— deja a muchos usuarios fuera. Desde entonces, empecé a pensar en redundancias: texto, iconos, jerarquía.

Otro aprendizaje invaluable vino de la retroalimentación de un colega con discapacidad. Sus observaciones me hicieron ajustar decisiones que yo creía “resueltas”. Esa experiencia me recordó que no hay mejor guía que escuchar a quienes realmente viven la accesibilidad día a día.

6. Aprendizajes a lo largo del camino

En este proceso también me encontré con situaciones que no salieron como esperaba, pero que se convirtieron en aprendizajes valiosos.

Uno de ellos fue entender que, para la mayoría de los desarrolladores, la accesibilidad también es un terreno nuevo. Requiere paciencia, espacio para investigar y tiempo para experimentar con las propiedades de cada sistema. Como diseñador, aprendí que no se trata solo de pedir entregables, sino de acompañar y construir juntos un entendimiento compartido.

Otro aprendizaje importante fue entender que la accesibilidad no puede dejarse “para después”. Cuando se piensa como algo secundario, al final se convierte en un parche difícil de aplicar y muchas veces se descarta. En cambio, si la colocamos como prioridad desde el inicio, se integra de manera natural en el diseño y en la implementación.

Y finalmente, comprendí que uno de mis mayores aciertos habría sido acercarme antes a los desarrolladores. Ese diálogo temprano me habría permitido entender mejor las limitantes técnicas y entregar anotaciones más claras y aplicables. Hoy sé que esa cercanía no es opcional: es esencial para que la accesibilidad pase de la teoría a la práctica.

7. Herramientas útiles en Figma

En este camino también encontré aliados que hicieron más práctico llevar la accesibilidad a los entregables:

• Color Contrast Checker integrado en Figma: al seleccionar colores con el color picker, puedes ver automáticamente el ratio de contraste entre texto y fondo, comprobar el cumplimiento con WCAG y simular cómo lo perciben personas con daltonismo.
• Plugins de etiquetado accesible: para documentar qué debe anunciar un lector de pantalla.
• Include — Accessibility Annotations (eBay): un plugin de eBay que ayuda a añadir anotaciones de accesibilidad directamente en Figma y guiar al equipo en aspectos como texto alternativo, orden de lectura o contraste. Ver en GitHub.
• Accessibility Annotation Kits (CVS Health): una librería de CVS Health que ofrece plantillas de anotaciones accesibles para iOS, web y más, con el objetivo de capturar detalles de accesibilidad que no se transmiten solo con lo visual.

Con estas herramientas, logramos que lo que diseñamos en equipo tenga un sustento técnico más fuerte, medible y compartible entre diseño y desarrollo.

Conclusión

Hoy puedo decir que la accesibilidad dejó de ser un apéndice en mi proceso de diseño. Ahora es un pilar. Como equipo, hemos aprendido a documentar mejor, a escuchar más y a diseñar pensando en todas las realidades. Y aunque todavía enfrentamos retos, cada mejora que hacemos significa que alguien más puede usar una app con dignidad y sin barreras.

Al final, diseñar accesible no es solo cuestión de buenas prácticas: es reconocer que detrás de cada pantalla hay una persona, y que la tecnología solo cumple su propósito cuando está al alcance de todos.

---

Gracias por leer hasta aquí.
Quiero agradecer al equipo de Coppel, en especial a los desarrolladores de iOS y Android, por la paciencia, el tiempo y la apertura para explorar juntos estos temas de accesibilidad. También a todo el equipo de Diseño, y de manera muy especial a Manuel Valdez, por su apoyo, retroalimentación y por impulsar que la accesibilidad se convierta en una prioridad dentro de nuestro trabajo. Nada de lo que aprendí en este camino hubiera sido posible sin su colaboración y compromiso.