Criterios WCAG que cambian en el móvil: cómo evaluarlos en una app

El protocolo de la lección anterior te dice qué configuraciones recorrer en cada pantalla. Esta lección baja al detalle de los criterios cuya evaluación más cambia en una app táctil: cómo se provoca el fallo, qué se considera incumplimiento y qué es solo una recomendación de plataforma. Antes, una precisión normativa que conviene tener clara al redactar cualquier hallazgo.

WCAG 2.1 en la norma, WCAG 2.2 en la práctica

La EN 301 549 v3.2.1 (PDF, se abre en una ventana nueva) incorpora los criterios de WCAG 2.1 de nivel A y AA. Los criterios que añadió WCAG 2.2 en el nivel AA o inferior (2.4.11 Foco no oculto (mínimo), 2.5.7 Movimientos de arrastre, 2.5.8 Tamaño del objetivo (mínimo), 3.2.6 Ayuda coherente, 3.3.7 Entrada redundante y 3.3.8 Autenticación accesible (mínimo)) no forman parte hoy del capítulo 11. Eso no significa que debas ignorarlos: muchas organizaciones del sector privado piden WCAG 2.2 AA como referencia, el W3C ha publicado la guía WCAG2ICT actualizada a 2.2 y es previsible que futuras versiones de la EN los incorporen.

Lo recomendable es evaluarlos y presentarlos en un bloque separado del informe, etiquetado como «WCAG 2.2 AA, no exigible por la EN 301 549 v3.2.1»: el cliente distingue así la obligación legal de hoy de lo que conviene corregir ya.

Orientación, texto grande y reflujo

1.3.4 Orientación (11.1.3.4)

Desactiva el bloqueo de orientación del sistema y gira el dispositivo en cada pantalla de la muestra. Falla la pantalla que no rota o que, al rotar, pierde contenido o funcionalidad, salvo que una orientación concreta sea esencial: los documentos de comprensión de WCAG citan como ejemplos un cheque bancario, una aplicación de piano o contenido de realidad virtual. «Queda mejor en vertical» no es una razón esencial. La causa suele estar en la configuración del proyecto, así que la recomendación es fácil de dar:

<!-- Android (AndroidManifest.xml). Incorrecto: bloquea la actividad en vertical -->
<activity android:name=".CitaActivity"
          android:screenOrientation="portrait" />

<!-- Correcto: sin restricción; la disposición se adapta -->
<activity android:name=".CitaActivity" />

En iOS, el equivalente es la lista de orientaciones admitidas del proyecto (UISupportedInterfaceOrientations en el fichero Info.plist) o el bloqueo programático en un controlador concreto. Revisa también los casos parciales, como una app que fuerza la vertical solo en el pago.

1.4.4 Cambio de tamaño del texto (11.1.4.4)

Según WCAG2ICT, en software este criterio se apoya en el escalado de la plataforma: la app debe respetar el tamaño de texto del sistema hasta el 200 % sin pérdida de contenido ni funcionalidad. En Android, el ajuste Tamaño de fuente llega al 200 % desde Android 14. En iOS, Texto más grande con los tamaños de accesibilidad activados va más allá: el 200 % del texto de cuerpo queda en torno a los primeros tamaños de accesibilidad. Evalúa en dos puntos:

• Al 200 %, para decidir cumple o no cumple: el texto crece, nada se corta con puntos suspensivos sin forma de leerlo completo, nada se solapa y todo es alcanzable desplazándose.
• Al máximo, como prueba de robustez: lo que se rompe solo por encima del 200 % se registra como recomendación, señalando que afecta a quien usa esos tamaños.

Causas habituales: tamaños fijos (en iOS, fuentes con tamaño en puntos sin escalado de Dynamic Type; en Android, textSize en dp en lugar de sp), contenedores de altura fija y barras de pestañas que no crecen. Para barras que no pueden crecer, Apple propone el visor de contenido grande (al mantener pulsado un elemento, aparece ampliado en el centro de la pantalla): documenta si está implementado y tenlo en cuenta en la valoración.

1.4.10 Reajuste de los elementos (11.1.4.10)

En una app se evalúa sobre todo combinado con el texto grande: los bloques de texto no deben exigir desplazamiento en dos direcciones para leerse. Quedan fuera, igual que en web, los contenidos que necesitan disposición bidimensional (tablas de datos, mapas, diagramas).

Gestos, puntero y movimiento

Empieza por un inventario de todos los gestos que ofrece la app en uso normal (sin lector de pantalla): deslizar para borrar o archivar, pellizcar para ampliar, deslizar con dos dedos, arrastrar para reordenar, mantener pulsado, agitar. Después evalúa cada uno con el criterio que le corresponde:

• 2.5.1 Gestos del puntero (11.2.5.1): todo gesto multipunto o basado en una trayectoria necesita una alternativa con un solo puntero sin trayectoria. El mapa que solo se amplía con el pellizco falla si no tiene botones «+» y «−»; la fila que solo se borra deslizando falla si no hay botón o menú. Ojo: una acción que solo está en el menú de acciones del lector de pantalla no basta, porque no ayuda a quien usa el dedo, un puntero bucal o un lápiz sin lector. Mantener pulsado sí es un gesto de un solo puntero sin trayectoria.
• 2.5.2 Cancelación del puntero (11.2.5.2): pon el dedo sobre un botón, deslízalo fuera y levántalo. Si la acción se ejecutó al tocar, la pantalla falla, salvo que la acción pueda deshacerse o que sea esencial (las teclas de un piano). Es típico de vistas personalizadas que reaccionan al evento de pulsación inicial.
• 2.5.3 Etiqueta en el nombre (11.2.5.3): con Control por voz (iOS) o Acceso por voz (Android), muestra los nombres de los elementos y di «pulsar» seguido del texto visible. Si el botón dice «Pedir cita» y su nombre accesible es «Botón de solicitud», la orden no funciona.
• 2.5.4 Activación mediante movimiento (11.2.5.4): agita e inclina el dispositivo en las pantallas principales. Una función que se activa al agitar (por ejemplo, «agitar para informar de un error») necesita una alternativa en la interfaz y una forma de desactivar la respuesta al movimiento.
• 2.5.7 Movimientos de arrastre (WCAG 2.2): reordenar una lista arrastrando, mover un deslizador personalizado o desplazar el mapa necesitan una alternativa con toques simples (flechas, botones, campo numérico).

Tamaño del objetivo: criterio frente a guía de plataforma

Aquí se cometen muchos errores de informe. Conviene separar tres umbrales:

Umbral	Origen	Cómo se registra
24 × 24 (o espaciado suficiente)	2.5.8 Tamaño del objetivo (mínimo), WCAG 2.2 AA. En apps se equipara en la práctica con pt (iOS) y dp (Android).	Por debajo, y sin excepción aplicable, fallo de 2.5.8 en el bloque WCAG 2.2.
44 × 44 pt	Guía de interfaz humana de Apple; es lo que avisa la auditoría del Accessibility Inspector.	Recomendación de plataforma.
48 × 48 dp	Directrices de Material Design y Android; es lo que avisa Accessibility Scanner.	Recomendación de plataforma.

El criterio AAA 2.5.5 Tamaño del objetivo (mejorado), con 44 × 44, solo se evalúa si el alcance lo incluye. Mide con el marco del elemento en el Accessibility Inspector o en el Layout Inspector, o activando en Android Opciones de desarrollador > Mostrar límites de diseño. Recuerda que lo que cuenta es el área táctil, que puede ser mayor que el icono visible.

Infografía · Conceptos clave

Ocho criterios que cambian en una interfaz táctil

Qué comprobar en cada uno al evaluar una app; los marcados 2.2 van en un bloque aparte

• 1.3.4 OrientaciónRota cada pantalla; solo una orientación esencial justifica el bloqueo
• 1.4.4 Tamaño del textoAl 200 %, nada cortado ni solapado; el máximo, como prueba de robustez
• 2.5.1 Gestos del punteroPellizcos y deslizamientos con alternativa de un solo toque
• 2.5.2 CancelaciónDeslizar fuera del botón antes de soltar no debe activarlo
• 2.5.3 Etiqueta visibleEl control por voz funciona diciendo el texto visible del control
• 2.5.4 MovimientoAgitar o inclinar con alternativa en pantalla y opción de desactivarlo
• 2.5.7 Arrastre (WCAG 2.2)Reordenar o mover deslizadores también con toques simples
• 2.5.8 Objetivo (WCAG 2.2)24 × 24 es el umbral; 44 pt y 48 dp son guías de plataforma

Leer la infografía como texto

Ocho tarjetas, una por criterio. 1.3.4 Orientación: rotar cada pantalla; solo una orientación esencial justifica bloquearla. 1.4.4 Tamaño del texto: al 200 % nada se corta ni se solapa; el máximo del sistema sirve como prueba de robustez. 2.5.1 Gestos del puntero: pellizcos y deslizamientos necesitan una alternativa con un solo toque. 2.5.2 Cancelación del puntero: deslizar el dedo fuera del botón antes de soltar no debe activarlo. 2.5.3 Etiqueta en el nombre: el control por voz debe funcionar diciendo el texto visible. 2.5.4 Activación mediante movimiento: agitar o inclinar necesita alternativa en pantalla y opción de desactivarlo. 2.5.7 Movimientos de arrastre, de WCAG 2.2: reordenar o mover deslizadores también con toques simples. 2.5.8 Tamaño del objetivo, de WCAG 2.2: el umbral es 24 por 24; 44 pt y 48 dp son guías de plataforma.

Teclado externo y foco

Con Acceso total con teclado en iOS (Ajustes > Accesibilidad > Teclados) o un teclado físico conectado a Android, recorre los flujos críticos con Tab, flechas, espacio e Intro. Se evalúan 2.1.1 Teclado, 2.1.2 Sin trampas para el foco del teclado, 2.4.3 Orden del foco y 2.4.7 Foco visible, como vimos en el protocolo. Añade una comprobación propia de WCAG 2.2: 2.4.11 Foco no oculto (mínimo). En apps es frecuente que el elemento con foco quede completamente tapado por una barra inferior fija, un botón flotante o el teclado en pantalla al saltar entre campos. Si queda oculto por completo, es un fallo del bloque WCAG 2.2.

Resumen

• La EN 301 549 v3.2.1 exige WCAG 2.1 A y AA; los criterios nuevos de WCAG 2.2 se evalúan y se presentan en un bloque aparte, claramente etiquetado.
• 1.3.4: rota cada pantalla con el bloqueo desactivado; solo una orientación esencial justifica bloquearla.
• 1.4.4: decide el cumplimiento al 200 % y usa el tamaño máximo como prueba de robustez.
• Gestos: inventaría los de la app y exige alternativa de un solo puntero (2.5.1), cancelación (2.5.2), etiqueta en el nombre (2.5.3), alternativa al movimiento (2.5.4) y al arrastre (2.5.7).
• Tamaño del objetivo: 24 es el umbral de WCAG 2.2; 44 pt y 48 dp son guías de plataforma y se registran como recomendaciones.