EN 301 549 capítulo 11 y aplicación de las WCAG a apps nativas

Cuando un auditor evalúa una página web sabe contra qué medir: WCAG 2.2 nivel AA o, en el marco normativo europeo, la EN 301 549 (PDF, se abre en una ventana nueva) capítulo 9, que hoy equivale a WCAG 2.1 AA. Con una app móvil la referencia es el capítulo 11 de la EN 301 549 («Software»), que contiene los criterios WCAG adaptados más una serie de requisitos propios sobre la interoperabilidad con tecnologías de apoyo y las preferencias del usuario. Esta lección desgrana ese capítulo para que puedas construir la lista de comprobación de una auditoría de app.

Qué cubre el capítulo 11

La EN 301 549 v3.2.1 (2021) es la norma armonizada que la Directiva (UE) 2016/2102 (PDF, se abre en una ventana nueva) y el RD 1112/2018 (PDF, se abre en una ventana nueva) toman como referencia para sitios web y aplicaciones móviles del sector público, y también la referencia técnica habitual para la Ley 11/2023 (PDF, se abre en una ventana nueva) en el sector privado mientras no se cite en el DOUE una norma armonizada para la Directiva (UE) 2019/882 (PDF, se abre en una ventana nueva) (la EN 301 549 v4.1.1 (PDF, se abre en una ventana nueva), publicada en septiembre de 2026, está pendiente de esa cita). El capítulo 11 se aplica al software no web: aplicaciones de escritorio, apps móviles nativas e híbridas (la parte nativa), y también al software con «funcionalidad cerrada» (quioscos, terminales) mediante notas específicas. Su estructura:

Los criterios WCAG en software: lo que cambia

En 11.1-11.4 casi todo es reconocible, pero hay matices que un auditor debe conocer:

• Criterios vacíos: 11.2.4.1 Saltar bloques, 11.2.4.2 Página titulada, 11.2.4.5 Múltiples vías, 11.3.2.3 Navegación coherente y 11.3.2.4 Identificación coherente aparecen como «vacíos» (void) en la EN 301 549 v3.2.1 porque no se aplican a un programa aislado (se refieren a conjuntos de páginas o de programas). No se evalúan como requisito, aunque la coherencia entre pantallas sigue siendo buena práctica.
• 11.2.4.2 Página titulada: aunque WCAG2ICT aplica 2.4.2 al software, la v3.2.1 lo deja vacío (una nota indica que el nombre del producto puede servir de título si describe su propósito). Que cada pantalla identifique su función de forma perceptible y anunciada se registra como buena práctica o dentro del bloque WCAG 2.2 si el encargo lo incluye.
• 11.1.4.10 Reajuste de los elementos y 11.1.4.4 Cambio de tamaño del texto: se aplican con notas: la plataforma debe ofrecer el escalado y la app debe respetarlo sin pérdida de contenido o funcionalidad; en software con funcionalidad cerrada se sustituye por requisitos del capítulo 5.
• 11.4.1.1 Análisis sintáctico: en v3.2.1 se mantiene con una nota que lo da por cumplido en software que no usa lenguajes de marcado; WCAG 2.2 lo ha eliminado, y las próximas versiones de la EN seguirán ese camino. Hoy no aporta hallazgos en apps nativas.
• 11.4.1.2 Nombre, función, valor: es el criterio central para controles personalizados: lo que no expone nombre, rol, estado y valor a la API de accesibilidad falla aquí.
• 11.4.1.3 Mensajes de estado: anuncios sin cambio de foco (live regions, notificaciones de accesibilidad).
• 11.1.2.x Multimedia: igual que en web; además, para el vídeo distribuido con la app, se aplican los requisitos de reproducción del capítulo 7 (subtítulos y audiodescripción en el reproductor).

11.5: interoperabilidad con tecnologías de apoyo

Esta cláusula es la que diferencia una auditoría de software de una web. Exige que el software, o bien use los servicios de accesibilidad de la plataforma (11.5.2.1, 11.5.2.2), o bien exponga por sí mismo toda la información. Los requisitos 11.5.2.5 a 11.5.2.17 describen qué debe ser accesible para una tecnología de apoyo:

• 11.5.2.5 Información de objeto: rol, estado(s), límites, nombre y descripción de cada elemento de la interfaz.
• 11.5.2.6 Fila, columna y cabeceras en tablas de datos.
• 11.5.2.7 Valores: valor actual, mínimo y máximo de controles ajustables.
• 11.5.2.8 Relaciones de etiqueta: la asociación entre un control y su etiqueta.
• 11.5.2.9 Relaciones padre-hijo en la jerarquía de elementos.
• 11.5.2.10 Texto: contenido, atributos y límites del texto.
• 11.5.2.11 y 11.5.2.12 Acciones disponibles y su ejecución por parte de la tecnología de apoyo (equivale a exponer acciones personalizadas).
• 11.5.2.13 y 11.5.2.14 Seguimiento y modificación del foco y la selección.
• 11.5.2.15 a 11.5.2.17 Notificación de cambios de estado, propiedades, valores y texto.

En una app que usa componentes estándar de UIKit/SwiftUI o Material estos requisitos se cumplen por herencia. Los hallazgos aparecen en controles personalizados, en vistas dibujadas (gráficos, calendarios, mapas) y en motores que pintan sus propios píxeles (Flutter, juegos). Un auditor documenta 11.5 inspeccionando el árbol de accesibilidad con las herramientas de la plataforma (siguiente lección).

11.6 y 11.7: documentación, no interferencia y preferencias

11.6.2 exige que la app no interfiera con las funciones de accesibilidad de la plataforma: bloquear TalkBack o interceptar los gestos de VoiceOver son incumplimientos directos, e impedir el escalado de texto puede serlo también (además de fallar los criterios WCAG correspondientes). 11.7 exige respetar las preferencias de la plataforma (color, contraste, tipo y tamaño de fuente y cursor de foco): una app con «tema propio» que ignora los ajustes de color y el tamaño de fuente del sistema puede fallar 11.7 aunque su contraste interno sea correcto. El capítulo 12 añade que la documentación describa las funciones de accesibilidad (12.1.1) y que el soporte las atienda (12.2): ficha de la tienda, ayuda y canal de contacto.

Cómo encaja con WCAG2ICT

WCAG2ICT es la fuente de las notas interpretativas de la EN: «página web» pasa a «software», «conjunto de páginas» a «conjunto de programas», y «determinado por software» significa expuesto por la API de accesibilidad de la plataforma. Esto permite reutilizar WCAG-EM (se abre en una ventana nueva) con ajustes: la muestra es de pantallas y flujos, y las tecnologías con soporte son las versiones de iOS/Android y las tecnologías de apoyo del sistema declaradas en el alcance.

Alcance: lo que hay que fijar antes de evaluar

Antes de evaluar, el alcance debe fijar plataformas y versiones (al menos las dos últimas versiones mayores de iOS y Android que soporte la app), dispositivos, tecnologías de apoyo (VoiceOver, TalkBack, zoom, control por voz, control por pulsadores, teclado externo, escalado máximo de texto), versión de la app y entorno, y la muestra: pantallas de entrada, pantallas con cada tipo de componente, procesos completos principales y una muestra aleatoria. La lección siguiente convierte este alcance en un plan con inventario, muestra y matriz de cobertura, y la de protocolo manual detalla cómo ejecutarlo.

Resumen

• El capítulo 11 de la EN 301 549 es la referencia para apps nativas: criterios WCAG adaptados (11.1-11.4), interoperabilidad con tecnologías de apoyo (11.5), no interferencia y documentación (11.6), preferencias del usuario (11.7).
• Saltar bloques, Página titulada, Múltiples vías, Navegación coherente e Identificación coherente son vacíos en software; 11.4.1.2 Nombre, función, valor es el criterio central para controles personalizados.
• 11.5.2.x detalla qué debe exponer cada elemento: rol, estado, nombre, valor, relaciones, acciones y notificaciones.
• WCAG2ICT aporta las sustituciones terminológicas y permite adaptar WCAG-EM: muestra de pantallas y flujos, versiones y tecnologías de apoyo declaradas.
• El alcance fija plataformas, versiones, dispositivos, tecnologías de apoyo y muestra antes de empezar.