Accesibilidad en aplicaciones móviles: Requisitos de WCAG 2.2 para iOS y Android

Más del 72% de las personas adultas con discapacidad poseen un smartphone, y según una encuesta, aproximadamente el 86% de las personas usuarias de lectores de pantalla dependen de un dispositivo móvil, una proporción mayor que quienes usan computadoras de escritorio o portátiles. Sin embargo, las mismas organizaciones que auditan sus sitios web de forma rigurosa suelen tener apps móviles que nunca se han probado frente a un solo criterio de accesibilidad. Esa brecha se está cerrando rápidamente, impulsada por la evolución de la normativa, el aumento de litigios y —sobre todo— por la propia guía del W3C que mapea explícitamente WCAG 2.2 a aplicaciones nativas de iOS y Android.

Por qué WCAG 2.2 se aplica a tu app móvil

Existe un mito persistente de que WCAG es un estándar solo para la web. No lo es. El W3C no tiene pautas separadas para accesibilidad móvil; en su lugar, la accesibilidad móvil se aborda dentro del marco existente de WCAG, y el Mobile Accessibility Task Force (MATF) del W3C ha producido una guía específica titulada Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile) que mapea cada criterio de éxito de nivel A y AA a apps móviles nativas, apps web móviles y apps híbridas.

La implicación práctica es significativa. Cuando lees un criterio de éxito de WCAG que se refiere a una "página web", el documento WCAG2Mobile reemplaza ese lenguaje por "pantalla" o "vista". Cuando un criterio habla de un "agente de usuario", se refiere al sistema operativo móvil. Los cuatro principios POUR —Perceptible, Operable, Comprensible, Robusto— se traducen directamente a cómo una persona usuaria interactúa con una vista de SwiftUI en iOS o un layout de Jetpack Compose en Android.

Desde el punto de vista legal, la presión ya no es teórica. En virtud del Título II de la ADA, la normativa actualizada del DOJ publicada en abril de 2024 exige explícitamente que los gobiernos estatales y locales hagan accesibles sus aplicaciones móviles conforme a WCAG 2.1 AA. Las organizaciones sanitarias que aceptan Medicare o Medicaid afrontan requisitos similares bajo las normas de HHS finalizadas en mayo de 2024. Y aunque las demandas sobre apps móviles en el sector privado siguen siendo menos frecuentes que las relativas a sitios web, al menos una parte demandante de alto volumen ha apuntado específicamente a aplicaciones móviles por falta de acceso equitativo bajo la ADA, y se espera que esa tendencia se acelere a medida que lleguen los plazos de cumplimiento del Título II en 2026.

La European Accessibility Act (EAA), que entró en vigor el 28 de junio de 2025 y se basa en la EN 301 549 como estándar técnico presuntivo, también exige conformidad con WCAG 2.2 para productos y servicios digitales, incluidas las apps móviles vendidas u ofrecidas en mercados de la UE. Para cualquier organización con una base de personas usuarias global, WCAG 2.2 en móvil no es una aspiración futura: es una obligación presente.

Qué cambió en WCAG 2.2 que más importa para móvil

WCAG 2.2, publicada como Recomendación del W3C en octubre de 2023, añade nueve nuevos criterios de éxito y elimina el ahora obsoleto 4.1.1 Parsing. Es totalmente retrocompatible: conformar con 2.2 implica conformar con 2.1 y 2.0. Varios de los nuevos criterios se redactaron teniendo explícitamente en mente los patrones de interacción móvil, y aun aquellos formulados en torno al uso de teclado tienen análogos directos en la tecnología de asistencia para iOS y Android.

Vale la pena entender la genealogía aquí. Después de 2018, el Mobile Accessibility Task Force se aseguró de que las consideraciones móviles dieran forma tanto a WCAG 2.1 como a 2.2. Criterios como 1.3.4 Orientation (AA), 1.4.10 Reflow (AA), 2.5.1 Pointer Gestures (A), 2.5.4 Motion Actuation (A), y los nuevos 2.5.7 Dragging Movements (AA), 2.5.8 Target Size Minimum (AA) y 3.3.7 Redundant Entry (A) reflejan todos patrones específicos de usabilidad móvil identificados mediante pruebas en el mundo real con personas con discapacidad que usan smartphones y tablets.

Los nueve nuevos criterios de éxito introducidos en WCAG 2.2 se dirigen a barreras específicas que encuentran las personas usuarias reales: flujos de inicio de sesión que castigan a cualquiera con problemas de memoria, interfaces que exigen manos firmes para toques precisos, funciones de ayuda enterradas en lugares distintos de cada pantalla e indicadores de foco que desaparecen detrás de barras de navegación fijas. Cada criterio tapa un agujero concreto, y casi todos tienen una aplicación directa en móvil.

Los nuevos criterios de WCAG 2.2 y cómo se aplican a iOS y Android

2.5.8 Target Size Minimum (Nivel AA)

Este es posiblemente el nuevo criterio de mayor impacto para los equipos móviles. Exige que los objetivos interactivos —botones, enlaces, campos de formulario, casillas de verificación, interruptores— tengan un tamaño mínimo de 24 × 24 píxeles CSS, o que exista un margen de separación de 24 píxeles entre objetivos adyacentes si el objetivo en sí es más pequeño. La razón es sencilla: las personas con temblores en las manos, enfermedad de Parkinson o destreza limitada encuentran realmente imposible pulsar de forma fiable un botón de icono de 16 píxeles, y hasta las personas sin discapacidad cometen muchos más errores en objetivos pequeños.

Para el desarrollo móvil nativo, el mínimo de 24 × 24 de WCAG 2.2 es en realidad un suelo, no un techo. Las Human Interface Guidelines de Apple recomiendan un objetivo táctil mínimo de 44 × 44 puntos en iOS y iPadOS. Material Design de Google recomienda 48 × 48 píxeles independientes de densidad (dp) en Android. Si tu app cumple las recomendaciones de plataforma de Apple o Google, ya superas el mínimo de WCAG 2.2, pero muchas apps no lo hacen. Esos diminutos botones de cierre en hojas modales, las casillas de verificación finísimas en pantallas de ajustes y las acciones de barra de herramientas solo con iconos que miden 20 × 20 dp son todos incumplimientos de conformidad esperando a ser detectados en una auditoría.

Una nota práctica: el requisito de WCAG se refiere al área interactiva de toque, no al tamaño visual del icono. Un icono de 16 puntos envuelto en 14 puntos de relleno a cada lado tiene un objetivo de toque efectivo de 44 × 44 puntos. Esto significa que las personas desarrolladoras pueden satisfacer el criterio sin agrandar visualmente los elementos, pero deben establecer deliberadamente ese relleno, no confiar en que el sistema lo haga automáticamente.

2.5.7 Dragging Movements (Nivel AA)

Este criterio exige que cualquier funcionalidad implementada mediante un gesto de arrastre —deslizadores, reordenación por arrastrar y soltar, pull-to-refresh, desplazamiento de carruseles— también pueda lograrse mediante una acción de un solo puntero que no requiera arrastrar. En iOS y Android, las propias tecnologías de asistencia de la plataforma gestionan ciertos gestos de forma diferente, pero la app en sí debe exponer alternativas sin arrastre para cualquier comportamiento de arrastre personalizado que implemente.

En la práctica, esto significa que una lista que se reordena arrastrando debe ofrecer una alternativa como un botón de incremento/decremento "arriba/abajo". Un deslizador de rango personalizado que solo responde a un gesto de arrastre también debe responder a toques en puntos específicos o proporcionar botones de incremento/decremento. El criterio no se aplica si el sistema operativo subyacente o la tecnología de asistencia proporcionan la alternativa automáticamente, pero las personas desarrolladoras deberían probar esto explícitamente en lugar de asumir que siempre se gestionará por ellas.

2.4.11 Focus Not Obscured — Minimum (Nivel AA) y 2.4.12 (Enhanced, Nivel AAA)

Estos criterios abordan un patrón extremadamente común tanto en apps web como móviles nativas: el elemento enfocado queda parcial o totalmente oculto por una interfaz fija —una barra de navegación inferior persistente, un botón flotante de acción, una barra superior que se superpone al área de scroll. El criterio mínimo (Nivel AA) exige que cuando un componente recibe el foco, al menos una parte de él siga siendo visible. La versión mejorada (Nivel AAA) exige que todo el componente enfocado sea visible.

Para móvil nativo, el "foco de teclado" se interpreta de forma amplia para incluir el anillo de foco usado por Switch Control o Switch Access, Full Keyboard Access (iOS 15+) y Voice Control/Access. Una app en la que el elemento enfocado se desliza por debajo de una barra de navegación inferior durante un barrido de Switch Control incumple este criterio, aunque no haya un teclado físico implicado. La interfaz de la app debe evitar ocultar controles enfocados con superposiciones creadas por la autora o el autor, barras fijas o superficies transitorias.

2.4.13 Focus Appearance (Nivel AA)

Este criterio establece requisitos mínimos para las características visuales del indicador de foco: debe tener un área mínima equivalente al perímetro del componente × 2 píxeles CSS, y una relación de contraste de al menos 3:1 frente a los colores adyacentes. En plataformas móviles nativas, el anillo de foco para VoiceOver y TalkBack está controlado por el sistema operativo, y las personas desarrolladoras no pueden cambiar su aspecto, lo que significa que generalmente se les concede una excepción para este criterio específico. Sin embargo, el estilo de la app no debe reducir activamente la visibilidad del foco, por ejemplo, superponiendo un velo translúcido sobre los controles enfocados.

3.3.8 Accessible Authentication — Minimum (Nivel A)

Este criterio representa un gran avance para la accesibilidad cognitiva. Exige que los procesos de autenticación no se basen únicamente en una prueba de función cognitiva, es decir, que no se exija a la persona usuaria memorizar una contraseña, resolver un rompecabezas o transcribir un CAPTCHA, a menos que la app proporcione una alternativa accesible. En iOS, esto significa admitir el llavero de Apple y Sign in with Apple para permitir que las personas se autentiquen sin memorizar credenciales. En Android, significa admitir el framework de Autofill de Google, la autenticación biométrica y no bloquear el uso de gestores de contraseñas de terceros.

Más concretamente: si tu app bloquea la acción de pegar en los campos de contraseña, probablemente no cumple con 3.3.8. Si tu flujo de autenticación de dos factores exige que la persona usuaria escriba manualmente un código OTP desde una notificación sin proporcionar un mecanismo de copiar y pegar, introduce una carga cognitiva innecesaria. La app Mensajes de Android ya proporciona un botón de "copiar código" en las notificaciones de OTP precisamente por esta razón, alineando el comportamiento de la plataforma con la intención del criterio.

Idea clave: Admitir la autenticación biométrica (Face ID, Touch ID, Android Biometric API) no es solo una mejora de UX: es un mecanismo de conformidad con WCAG 2.2 para personas con discapacidades cognitivas que no pueden recordar contraseñas de forma fiable.

3.3.7 Redundant Entry (Nivel A)

Si un flujo de varias pantallas en tu app —checkout, onboarding, un formulario de admisión sanitaria— pide a la persona usuaria introducir la misma información más de una vez, debes o bien autocompletar el valor introducido previamente o bien ofrecer una forma de seleccionarlo a partir de entradas anteriores. Este criterio es directamente aplicable a apps móviles nativas. El modo clásico de fallo es un formulario de dirección de envío que más tarde pide una dirección de facturación sin opción de "igual que la de envío", obligando a las personas con discapacidades motoras o cognitivas a volver a escribir el mismo texto varias veces.

3.2.6 Consistent Help (Nivel A)

Si tu app proporciona un mecanismo de ayuda —un botón de chat de soporte, un icono de ayuda, un enlace de "contacto"— debe aparecer en una ubicación consistente en todas las pantallas de la app. Las personas con discapacidades cognitivas dependen de la colocación predecible de los mecanismos de navegación y soporte. Colocar el botón de ayuda en el encabezado en algunas pantallas y en la barra de pestañas en otras, o enterrarlo dentro de un menú de ajustes en ciertos flujos, incumple este criterio.

Criterios de WCAG 2.1 que siguen siendo críticos para móvil

Los nuevos criterios de WCAG 2.2 acaparan la mayor parte de la atención, pero varios requisitos de WCAG 2.1 que se introdujeron específicamente pensando en móvil siguen incumpliéndose habitualmente en apps nativas, y las personas responsables de cumplimiento no deberían pasarlos por alto durante las auditorías.

1.3.4 Orientation (AA) prohíbe bloquear una app en orientación vertical u horizontal salvo que esa orientación sea esencial para la función del contenido. Muchas apps se bloquean en vertical durante flujos de onboarding o en reproductores de vídeo integrados sin justificación. Esto afecta de forma desproporcionada a personas con dispositivos montados en sillas de ruedas que no pueden rotarse. 1.4.10 Reflow (AA) exige que el contenido pueda presentarse sin desplazamiento horizontal cuando se muestra a 320 píxeles CSS de ancho (equivalente a un zoom del 400%), lo que en términos móviles significa admitir Dynamic Type y la escala de tamaño de texto del sistema sin romper el layout ni truncar contenido.

2.5.1 Pointer Gestures (A) exige que cualquier funcionalidad que use gestos multipunto o basados en trayectoria —un pellizco para hacer zoom, un deslizamiento con dos dedos— tenga también una alternativa de un solo puntero. 2.5.4 Motion Actuation (A) exige que la funcionalidad activada al agitar o inclinar el dispositivo también pueda operarse mediante controles estándar de la interfaz, y que las personas usuarias puedan desactivar los disparadores basados en movimiento para evitar activaciones accidentales.

En cuanto a la presentación visual, 1.4.3 Contrast Minimum (AA) exige una relación de al menos 4.5:1 para texto normal y 3:1 para texto grande. Muchas apps siguen fallando aquí porque el texto de marcador de posición en campos de entrada, las etiquetas de botones deshabilitados y el texto sobre fondos fotográficos quedan por debajo del mínimo. Las personas desarrolladoras deben asegurarse de que todo el texto, controles y contenido funcionen con Dynamic Type, Bold Text, modo oscuro y opciones de contraste a nivel de sistema tanto en iOS como en Android.

Guía de implementación específica por plataforma

iOS y SwiftUI / UIKit

Apple proporciona un amplio soporte nativo de accesibilidad a través de la API UIAccessibility y, en SwiftUI, mediante modificadores de accesibilidad. Para el soporte de VoiceOver, cada elemento interactivo debe tener una etiqueta de accesibilidad, una pista y un valor significativos. Los controles personalizados que no heredan de componentes estándar de UIKit deben adoptar explícitamente un rasgo de accesibilidad apropiado —.isButton, .isHeader, .isLink— para que VoiceOver los anuncie correctamente. El Accessibility Inspector de Xcode puede ayudar a detectar etiquetas faltantes y desajustes de rasgos durante el desarrollo.

Para Dynamic Type, las fuentes de sistema UIFont.preferredFont(forTextStyle:) en UIKit y .font(.body) en SwiftUI se escalan automáticamente con el tamaño de texto preferido de la persona usuaria. Los tamaños de fuente codificados en puntos que no usan scaledValue(for:) incumplirán 1.4.4 Resize Text. Para los tamaños de objetivo, puedes ampliar el área táctil de un icono pequeño usando contentEdgeInsets en UIKit o el modificador .contentShape() en SwiftUI sin cambiar la presentación visual del elemento.

// SwiftUI: ampliar el área de toque sin cambiar el tamaño visual
Image(systemName: 'xmark')
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel('Close')
    .accessibilityAddTraits(.isButton)

Android y Jetpack Compose / Views

La accesibilidad en Android se expone a través de la API AccessibilityNodeInfo, que consumen TalkBack y Switch Access. En Jetpack Compose, el bloque Modifier.semantics permite establecer descripciones de contenido, roles, descripciones de estado y combinar semánticas descendientes. Para interfaces basadas en Views, ViewCompat.setAccessibilityDelegate() permite la manipulación programática de propiedades de accesibilidad en cualquier vista.

Para el tamaño de los objetivos táctiles, la guía de Material Design recomienda un mínimo de 48 × 48 dp. Si un composable o vista es visualmente más pequeño, puedes usar Modifier.minimumInteractiveComponentSize() en Compose (introducido en Material3) para aplicar automáticamente un mínimo de 48 dp, o envolver una vista pequeña en un TouchDelegate para ampliar su área de toque en el sistema de Views heredado. Para la escala de texto, asegúrate de que todos los tamaños de texto se especifiquen en sp (píxeles independientes de escala), no en dp, de modo que respeten las preferencias de tamaño de fuente configuradas por la persona usuaria en los ajustes de Pantalla de Android.

// Jetpack Compose: botón de icono accesible con tamaño mínimo
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // aplica mínimo de 48dp
        .semantics { contentDescription = 'Close dialog' }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // descrito por el elemento padre
    )
}

Probar tu app frente a WCAG 2.2

Probar la accesibilidad móvil requiere una combinación de herramientas automatizadas y pruebas manuales con tecnologías de asistencia reales. Las herramientas automatizadas —incluidas axe DevTools Mobile de Deque, Accessibility Scanner de Google para Android y Accessibility Inspector de Apple en Xcode— pueden detectar etiquetas faltantes, contraste insuficiente y objetivos táctiles que están por debajo de los mínimos de la plataforma. Sin embargo, las herramientas automatizadas solo detectan una fracción de los problemas reales de accesibilidad. Las pruebas manuales con VoiceOver en iOS y TalkBack en Android son esenciales para verificar el orden de lectura correcto, etiquetas significativas y una gestión lógica del foco en flujos complejos.

Para los criterios específicos de WCAG 2.2, las pruebas manuales son especialmente importantes. Para probar 2.5.8 (Target Size), usa tu propio dedo —no un cursor de ratón en el iOS Simulator— para intentar interactuar con controles pequeños. Para probar 3.3.8 (Accessible Authentication), verifica que tu flujo de inicio de sesión permite pegar en los campos de contraseña, admite gestores de contraseñas (1Password, Bitwarden, llavero del sistema) y admite autenticación biométrica. Para probar 2.4.11 (Focus Not Obscured), navega por tu app únicamente mediante Switch Control en iOS o Switch Access en Android y confirma que ningún elemento enfocado desaparece detrás de una barra de navegación, una superposición modal o un botón flotante.

Un plan de pruebas de accesibilidad completo debe incluir pruebas en al menos dos dispositivos físicos —un iPhone y un dispositivo Android— con el tamaño de fuente predeterminado de la persona usuaria y con el tamaño máximo de fuente del sistema, con VoiceOver y TalkBack activados respectivamente. Las pruebas solo en simulador pasarán por alto diferencias reales de renderizado y comportamiento de las tecnologías de asistencia.

Considera integrar comprobaciones de accesibilidad en tu pipeline de CI/CD. Tanto Espresso (Android) como XCUITest (iOS) permiten escribir pruebas automatizadas de interfaz que verifican propiedades de accesibilidad —descripciones de contenido, rasgos y estados habilitados— de modo que las regresiones se detecten antes de fusionar código en lugar de descubrirse en una auditoría en producción.

El caso legal y de negocio para actuar ahora

Más allá del imperativo moral de la inclusión, el caso de negocio para la accesibilidad móvil es concreto. Las empresas líderes en inclusión de la discapacidad generan 1.6 veces más ingresos y 2.6 veces más beneficio neto que sus homólogas del sector. Las personas con discapacidad en EE. UU. poseen casi medio billón de dólares en ingresos disponibles. Y dado que el 69% de las personas consumidoras con discapacidad abandonan apps y sitios web que encuentran difíciles de usar, cada barrera de accesibilidad es una conversión que nunca ocurre.

El riesgo legal va en aumento. Las demandas dirigidas a empresas con fallos de accesibilidad digital siguen creciendo año tras año. La adopción de WCAG por parte del DOJ como estándar técnico para el cumplimiento de la ADA, los plazos de aplicación del Título II en 2026 y la entrada en vigor de la EAA en junio de 2025 crean colectivamente un requisito de cumplimiento multijurisdiccional que ahora abarca explícitamente las aplicaciones móviles nativas. Una auditoría previa de WCAG 2.1 no demuestra automáticamente la conformidad con WCAG 2.2: los flujos de autenticación, campos de formulario, componentes interactivos y la gestión del foco necesitan una reevaluación frente a los nueve nuevos criterios de éxito.

De forma crítica, la accesibilidad en móvil no es una característica que pueda añadirse de forma económica después del lanzamiento. Abordar fallos de WCAG en una app ya publicada implica actualizar recursos, reconstruir componentes, revisar layouts, volver a probar flujos y, potencialmente, refactorizar sistemas de autenticación. Los equipos que incorporan la conformidad con WCAG 2.2 en sus sistemas de diseño y librerías de componentes desde el principio —aplicando tamaños mínimos de objetivo táctil, tokens de contraste, roles semánticos y patrones de autenticación a nivel de componente— pagan una fracción del coste en comparación con remediar una app inaccesible tras su lanzamiento.

Conclusiones clave

• WCAG 2.2 se aplica a apps nativas de iOS y Android. La guía WCAG2Mobile del W3C mapea cada criterio de éxito de nivel A y AA a pantallas y vistas móviles, lo que significa que tu app nativa está dentro del alcance, no solo tu sitio web móvil.
• El tamaño del objetivo táctil es el nuevo fallo más común en auditorías móviles. El mínimo de 24 × 24 de WCAG 2.2 es el suelo; Apple recomienda 44 × 44 pt y Google recomienda 48 × 48 dp. Amplía las áreas de toque con relleno y APIs nativas de la plataforma, no agrandando visualmente los iconos.
• Bloquear pegar en campos de contraseña probablemente incumple 3.3.8 Accessible Authentication. Admite llaveros del sistema, gestores de contraseñas, biometría y autocompletado de OTP para cumplir los requisitos de accesibilidad cognitiva en los flujos de inicio de sesión en ambas plataformas.
• Las pruebas manuales con VoiceOver y TalkBack son innegociables. Las herramientas automatizadas solo detectan una fracción de los problemas de accesibilidad. Prueba en dispositivos físicos con el tamaño máximo de fuente, con tecnologías de asistencia activadas, en cada recorrido de usuario crítico.
• Incorpora la accesibilidad en tu sistema de diseño ahora, no después del lanzamiento. Remediar apps inaccesibles tras el lanzamiento es mucho más caro que aplicar estándares de componentes accesibles desde el primer día. Con los plazos de aplicación del DOJ, HHS y la EAA llegando en 2025–2026, la ventana para un trabajo de cumplimiento de bajo coste se está cerrando.