Accesibilidad en aplicaciones móviles: cómo hacer tu app más accesible

No puedes demostrar que una app es accesible a partir de una vista previa o una puntuación de contraste. Sin embargo, sí puedes eliminar una cantidad sorprendente de barreras antes de que empiecen las pruebas formales.

La accesibilidad móvil va mucho más allá del contraste de color. La tipografía, los espacios, la navegación, las zonas táctiles, las etiquetas, el movimiento, los contenidos multimedia y el comportamiento con las tecnologías de asistencia también determinan si una persona puede completar una tarea.

Las WCAG se escribieron para contenido web. La guía WCAG2Mobile del W3C explica cómo aplicar los criterios de nivel A y AA de WCAG 2.2 a apps móviles nativas, web e híbridas. Es un documento informativo, no una norma móvil independiente, y por sí solo no basta para establecer que una app es accesible.

Esta checklist separa lo que se puede configurar de forma centralizada de lo que todavía debe verificarse en el producto publicado:

Nada parecía claramente roto en esta primera pantalla. Ahí residía el interés del ejercicio: los problemas de accesibilidad no siempre son llamativos; a menudo se esconden dentro de decisiones de diseño elegantes.

Aplicamos texto claro sobre un fondo claro, redujimos el cuerpo del texto a 10 px, eliminamos los márgenes globales y mantuvimos etiquetas de navegación genéricas como «Videos» y «Podcasts». El resultado seguía transmitiendo calma en una presentación. En un teléfono, la jerarquía se derrumbaba: el texto secundario se desvanecía, las tarjetas se acercaban demasiado a los bordes y la navegación inferior resultaba mucho más difícil de recorrer.

La lección no es «no uses nunca colores pastel» ni «haz que todo sea grande». Las decisiones de marca necesitan un sistema legible que las sostenga.

Empezamos en Mi App > Estilo de App > Colores y asignamos los colores según su función. Mantuvimos el fondo cálido. Lo que cambió fue la distancia entre cada primer plano y su fondo:

Las WCAG 2.2 establecen un ratio de contraste mínimo de 4,5:1 para texto normal y de 3:1 para texto grande en el nivel AA. Dejamos deliberadamente más margen en el texto principal: una combinación que supera el umbral sobre el papel puede seguir pareciendo débil con una fuente fina, un tamaño pequeño o una pantalla brillante en exteriores.

GoodBarber permite partir de un tema integrado, generar una paleta o crearla desde cero. Lo útil no es el número de muestras, sino su reutilización. El texto del header y del cuerpo, los separadores, los botones y los estados de navegación pueden recibir funciones coherentes en todas las secciones. La documentación de Estilo de App explica cómo se propagan estas decisiones globales.

Una paleta legible es un punto de partida sólido, no un certificado de accesibilidad. Comprueba cada combinación real de primer plano y fondo, incluidos los estados seleccionados, las superposiciones, las imágenes y las personalizaciones propias de cada sección.

El contraste hizo visibles las palabras. El tamaño y el espacio hicieron que resultaran cómodas.

Seleccionamos el tema tipográfico Formateca, que combina Work Sans para los títulos con Manrope para el cuerpo del texto. Después usamos el control global de tipografía para reconstruir la jerarquía: el cuerpo pasó de 10 px a 16 px, el título principal alcanzó 30 px y el contenido principal recuperó márgenes de 16 px.

La escala tipográfica global de GoodBarber ajusta proporcionalmente ocho niveles de texto. Facilita el mantenimiento de una jerarquía coherente entre pantallas, pero no garantiza un resultado accesible. Verifica los tamaños, los saltos de línea y el interlineado resultantes en la app generada.

WCAG no prescribe un tamaño mínimo universal para el cuerpo del texto. Los 16 px son el valor que elegimos para esta interfaz, no un umbral de conformidad. El texto más grande también necesita más espacio; de lo contrario, las tarjetas se comprimen y las etiquetas se cortan de forma incómoda.

Por último, prueba la app con el tamaño de texto preferido por el usuario. Apple recomienda admitir la ampliación del texto y Dynamic Type, mientras que el contenido web debe seguir siendo utilizable al cambiar el tamaño del texto. Una vista previa equilibrada en el editor es solo el primer estado que debes comprobar.

En esta comparación de antes y después, la TabBar original mostraba «Videos», «Podcasts» y «Navigation». Estas etiquetas describían formatos o mecanismos de la interfaz, no lo que una persona de la comunidad de yoga podía hacer a continuación.

Las renombramos Classes, Audio y More. La estructura no cambió, pero la decisión se volvió más sencilla: realizar una clase, elegir una sesión de audio o abrir las demás secciones.

La guía de accesibilidad de Android recomienda etiquetas útiles y descriptivas para los elementos interactivos, ya que servicios como TalkBack pueden anunciar sus nombres de accesibilidad. Cambiar el título visible mejora la navegación visual; aun así, debes verificar qué expone realmente el componente generado a VoiceOver y TalkBack.

Mantén las etiquetas breves, únicas y orientadas a tareas. Combina los iconos con texto cuando haya espacio. Una prueba sencilla: si desaparecieran los iconos, ¿las palabras seguirían indicando adónde conduce cada toque?

La accesibilidad falla cuando el contenido puede verse pero un control es difícil de pulsar, o cuando un medio esencial excluye un canal sensorial.

Empieza por las zonas táctiles. Android recomienda una zona enfocable de al menos 48 × 48 dp para los elementos interactivos. En la PWA, el criterio Tamaño del objetivo (mínimo) de WCAG 2.2 fija un mínimo de 24 × 24 píxeles CSS en el nivel AA, con las excepciones definidas. El icono visible puede ser más pequeño que su área operable, pero los objetivos próximos deben seguir estando claramente separados.

Revisa después cómo se comunica el significado. Los errores, el progreso y la disponibilidad necesitan señales que los usuarios puedan percibir. Las imágenes informativas requieren alternativas textuales útiles; los vídeos con información relevante, subtítulos; y el contenido solo de audio, una transcripción o equivalente. Son decisiones editoriales que un diseño de app coherente no puede automatizar por ti.

GoodBarber centraliza la jerarquía, los colores y la forma de los botones mediante Estilo de App. Utiliza estos controles para reducir inconsistencias y después verifica el tamaño de los objetivos, el foco, las etiquetas y los estados en las versiones iOS, Android y PWA generadas.

Lotus Yoga utilizaba respuesta háptica y una animación de apertura. En Mi App > Estilo de App, desactivamos el efecto decorativo de apertura y mantuvimos la respuesta háptica en las apps nativas. GoodBarber también ofrece efectos de desplazamiento en la misma zona; las opciones de diseño adicionales de Estilo de App explican dónde se encuentran estos controles.

Esta decisión no es una receta universal de accesibilidad. El movimiento puede explicar un cambio de estado y la respuesta háptica puede confirmar una acción sin añadir ruido visual. La pregunta es si el efecto transmite información útil. Si no lo hace, resulta más fácil justificar un ajuste más tranquilo.

No des por hecho que cambiar un ajuste del editor demuestra que se respetan las preferencias de reducción de movimiento. Comprueba la app publicada con dichas preferencias activadas y confirma que las tareas completas siguen teniendo sentido sin el efecto.

Esta versión final es más fácil de leer y recorrer sin perder el carácter tranquilo de la marca. Y, sobre todo, las mejoras son sistémicas: una sola paleta, escala tipográfica y sistema de espaciado pueden mejorar muchas pantallas a la vez.

La vista previa muestra el color, la jerarquía, el espaciado, las etiquetas y los estados visibles. No puede decirte si cada anuncio del lector de pantalla es útil, si el foco avanza de forma lógica o si un recorrido completo sigue siendo operable con un método de entrada alternativo.

Antes de publicar:

• Recorre los flujos esenciales de iOS con VoiceOver y los de Android con TalkBack sin mirar la pantalla.
• Aumenta el tamaño de texto del sistema y comprueba si hay recortes, superposiciones, controles ocultos o contenido perdido.
• Comprueba que botones, enlaces, formularios y menús tengan nombres, roles, estados y un orden de foco claros.
• Prueba la PWA con navegación por teclado, zoom del navegador y varios tamaños de ventana.

Las herramientas automáticas detectan problemas útiles. No entienden si una etiqueta tiene sentido, si una instrucción es cognitivamente clara o si completar una tarea resulta frustrante. Las pruebas manuales —idealmente con personas con discapacidad— siguen siendo esenciales.

La ventaja de un design system es su efecto multiplicador. GoodBarber construye las pantallas a partir de fundamentos compartidos y componentes reutilizables. El color, la tipografía, el espacio, las formas y la navegación son reglas que se repiten en toda la app, no decoraciones aisladas. Puedes explorar el Design System de GoodBarber para ver cómo encajan estas capas.

Este efecto multiplicador también establece un reparto claro de responsabilidades:

El Design System de GoodBarber elimina parte del trabajo repetitivo de accesibilidad al aplicar reglas compartidas de tipografía, color, espaciado y componentes en toda la app. Aun así, debes validar la interfaz y el contenido resultantes en cada plataforma.

¿WCAG se aplica a las aplicaciones móviles nativas?

WCAG se escribió para contenido web, pero sus principios y criterios de éxito se utilizan ampliamente en accesibilidad móvil. El borrador WCAG2Mobile del W3C explica cómo aplicar los criterios de nivel A y AA de WCAG 2.2 a apps móviles nativas, web e híbridas. La guía es informativa: no constituye una norma móvil separada ni garantiza el cumplimiento legal.

¿Puede un app builder crear automáticamente una app accesible?

No. Los componentes reutilizables, los valores predeterminados legibles y las reglas globales de diseño pueden ofrecer una base más sólida, pero la accesibilidad también depende de la configuración, el contenido, las funciones de terceros y los recorridos completos. La app generada todavía debe probarse.

¿Qué debo probar primero en una aplicación móvil existente?

Empieza por los recorridos que los usuarios no pueden evitar: abrir la app, navegar, iniciar sesión, encontrar contenido y completar la acción principal. Pruébalos con un lector de pantalla, texto ampliado y movimiento reducido; después revisa las zonas táctiles, los errores de formulario y las alternativas multimedia.

¿Cuál es el contraste de texto mínimo para una aplicación móvil?

WCAG 2.2 de nivel AA establece un ratio de contraste mínimo de 4,5:1 para texto normal y de 3:1 para texto grande. Estos umbrales también se utilizan habitualmente al evaluar interfaces móviles mediante la guía WCAG2Mobile. Trátalos como un mínimo, no como un objetivo de diseño.

¿Dónde cambio estos ajustes en GoodBarber?

Abre Mi App > Estilo de App para gestionar los colores globales, las fuentes, los márgenes, los botones, las animaciones y la respuesta háptica. Las etiquetas y los diseños de navegación se configuran en la estructura de la app. Previsualiza el resultado mientras trabajas y prueba las versiones iOS, Android y PWA generadas antes de publicar.

Una app accesible no es un estilo visual concreto. Es una serie de decisiones que permiten a más personas percibir el contenido, comprender la interfaz y completar la tarea. Crea tu app con GoodBarber, construye esta base una sola vez y mejórala con información de usuarios reales.