Checklist EN 301 549: audita la accesibilidad de tu app

Instalas en tu app uno de esos widgets de accesibilidad que prometen cumplimiento en una línea de código, el panel del proveedor se pone verde y te quedas tranquilo. Dos problemas: ese widget no comprueba nada de lo que la EN 301 549 exige, y la norma acaba de cambiar de versión, aunque la nueva todavía no sea la que te aplica. Esto no es un resumen: es un checklist que puedes ejecutar esta semana sobre tu app, con el móvil que llevas encima.

En Docastix metemos la accesibilidad en el desarrollo de apps móviles desde el diseño, porque el orden decide el coste: arreglar contraste y etiquetas en un Figma son horas, y en producción es un ciclo de release en dos tiendas. La obligación legal, a quién alcanza y desde cuándo están en la guía sobre la normativa europea de accesibilidad; aquí vamos a la parte técnica.

Respuesta rápida: ¿qué es la EN 301 549 y qué te exige para tu app?

La EN 301 549 es la norma técnica europea de accesibilidad de productos y servicios TIC, y la parte que aplica a una app móvil nativa está en su cláusula 11. En la V3.2.1, la vigente, se titula «Software»; la V4.1.1 la rebautiza «Non-web software», que es como venían formulados sus requisitos desde el principio. No es la única que te puede aplicar —según lo que haga tu app entran también la 5, la 6, la 7, la 10 y la 12, y al final del artículo está el detalle—, pero es la que concentra el trabajo. Traslada al software no web los criterios de las WCAG en nivel AA y añade requisitos que la web no tenía: interoperar con las tecnologías de asistencia y respetar los ajustes de accesibilidad de la plataforma.

Quédate con tres ideas: con la que te van a medir hoy es con la V3.2.1, con WCAG 2.1 en nivel AA; la V4.1.1 ya existe y trae WCAG 2.2, así que ve preparando la app sin auditar todavía contra ella; y la mayoría de los fallos se descubren gratis, con los ajustes del propio teléfono.

Qué cambia con la V4.1.1, y por qué todavía no auditas contra ella

ETSI publicó la EN 301 549 V4.1.1 en septiembre de 2026, adoptada el 24 de agosto de 2026 según el propio documento. No es un retoque menor:

• Incorpora las WCAG 2.2 en lugar de las 2.1 y realinea con ellas las cláusulas 9, 10 y 11: la que rige tu app pasa a apoyarse en criterios distintos.
• Elimina el criterio 4.1.1 Parsing, que la V3.2.1 todavía exige. Si tu último informe tiene hallazgos ahí, hoy siguen contando; dejarán de contar cuando la nueva sea la referencia.
• Trae los seis criterios nuevos de las WCAG 2.2 en nivel A y AA. A una app le aplican cinco —foco no oculto, movimientos de arrastre, tamaño del objetivo, entrada redundante y autenticación accesible—; el sexto, ayuda consistente, la norma lo deja vacío para software no web porque está escrito sobre «conjuntos de páginas», que en una app no existen.
• Amplía la cláusula 11.7, la de preferencias del usuario. Conviene decirlo bien, porque suele contarse como novedad y no lo es: respetar los ajustes del sistema ya lo exige la V3.2.1. Lo que cambia es el alcance, que pasa de una lista cerrada de seis ajustes —unidades, color, contraste, tipo y tamaño de letra y cursor de foco— a cualquier función de accesibilidad documentada por la plataforma. La norma no nombra la reducción de movimiento en ninguna de sus dos versiones, así que entraría por esa vía y solo en la medida en que iOS y Android la documenten como función de accesibilidad.
• Suma tres anexos —ZA, ZB y ZC— y una cláusula A.2 con cinco tablas. El ZA corresponde a la Directiva 2016/2102; el ZB y la A.2, a la 2019/882; el ZC relaciona con esta última los requisitos que vienen de otras directivas.

Y ahora lo que decide qué haces esta semana: la referencia con la que te van a medir sigue siendo la V3.2.1, la que se apoya en WCAG 2.1 nivel AA, hasta que la Comisión cite la nueva en el Diario Oficial. Con un matiz que importa para lo que viene justo después: la cita que ampara a la V3.2.1 lo es para la directiva del sector público, así que para una app privada es la referencia de facto, la que usará quien te audite, no una versión bendecida bajo la Ley Europea de Accesibilidad. Quien audite ya contra la V4.1.1 trabaja de más; quien no sepa que existe se reserva un susto para dentro de unos meses.

La postura sensata tiene dos tiempos: audita hoy contra la V3.2.1, que es lo que usará un tercero, y lee la V4.1.1 antes de rehacer la navegación o el sistema de diseño. Sale barato si la accesibilidad tiene sitio fijo en el proceso de desarrollo; caro si es una revisión suelta cada dos años.

Lo que casi nadie dice: bajo la Ley Europea de Accesibilidad no hay presunción de conformidad

El mecanismo europeo habitual: una directiva fija objetivos, la Comisión encarga una norma armonizada y la cita en el Diario Oficial, y desde ahí cumplirla da presunción de conformidad. Se presume que cumples y quien diga lo contrario debe demostrarlo.

El artículo 15 de la Directiva 2019/882, la Ley Europea de Accesibilidad, recoge ese mecanismo: la presunción la dan las normas armonizadas publicadas en el Diario Oficial. El detalle está en el índice de normas armonizadas de la Comisión, consultado el 14 de septiembre de 2026: la única entrada de accesibilidad es «Websites and mobile applications of public sector bodies», que corresponde a la Directiva 2016/2102, la del sector público. No hay entrada para la Directiva 2019/882.

Y no hace falta deducirlo: lo dice la propia norma en su prólogo, supeditado a un hecho que aún no ha ocurrido. Una vez que el documento se cite en el Diario Oficial bajo esa Directiva, cumplir las cláusulas normativas recogidas en las tablas de la A.2 conferirá presunción de conformidad. Está escrito así porque esa cita todavía no existe.

La consecuencia práctica, sin dramatismo: cumplir la EN 301 549 no te da hoy un salvoconducto automático bajo la Ley Europea de Accesibilidad, porque ese salvoconducto no existe todavía para nadie. No es un problema tuyo: es el estado del mecanismo.

Eso no significa —porque el malentendido contrario también circula— que la norma dé igual. Sigue siendo el único marco técnico reconocido en Europa, el que usará quien te inspeccione y la prueba de tu diligencia. Lo que cambia es el argumento: «cumplo la norma, estoy cubierto» no se sostiene; «he auditado contra el marco de referencia, tengo el informe, el plan y las fechas» sí. El alcance legal está en la guía de normativa europea de accesibilidad.

El checklist, principio por principio

Cada punto lleva tres cosas: qué exige, cómo se comprueba en un móvil de verdad y qué se ve cuando está mal. Prepara el terreno: VoiceOver o TalkBack, el tamaño de texto al máximo, contraste alto, reducción de movimiento y un teclado Bluetooth barato. Y recorre la app de punta a punta —alta, acceso, acción principal, pago y baja—, no por pantallas sueltas.

Que la app siga el color, el contraste, el tipo y el tamaño de letra del sistema no es cortesía ni algo que llegue con la versión nueva: es la cláusula 11.7, y la V3.2.1 —la que te aplica hoy— ya obliga a seguir los valores que el usuario tiene puestos en unidades de medida, color, contraste, tipo y tamaño de letra y cursor de foco. Una app que ignora el tamaño de texto del sistema no está siendo poco amable: está incumpliendo la versión vigente. La reducción de movimiento no está en esa lista: es buena práctica hoy y entra en la norma con la V4.1.1.

Perceptible

Alternativas textuales en todo elemento no textual

• Qué exige. Toda imagen o icono sin texto visible expone una descripción equivalente; lo decorativo, marcado como tal.
• Cómo se comprueba. Recorre la pantalla con VoiceOver o TalkBack, parada a parada, sin mirar.
• Qué se ve cuando falla. El lector dice «botón», «imagen» o el nombre del fichero.

Contraste suficiente entre texto y fondo

• Qué exige. Texto normal a 4,5:1 como mínimo; texto grande —18 puntos, o 14 en negrita— a 3:1; y los componentes de interfaz y los objetos gráficos, también a 3:1 contra el color de al lado, estados incluidos. Con una excepción que conviene saberse antes de discutir con un auditor: los componentes inactivos están excluidos, tanto del 4,5:1 como del 3:1.
• Cómo se comprueba. El ojo no sirve y no hace falta pagar nada: cualquier medidor de contraste gratuito sobre los códigos de color de tu sistema de diseño da el número exacto en un minuto.
• Qué se ve cuando falla. Gris claro sobre blanco en avisos y textos legales, o texto blanco sobre el color de marca.

Tamaño de texto y reflujo

• Qué exige. El texto se puede ampliar hasta el 200% sin que se pierda contenido ni funcionalidad, y el contenido refluye sin obligar a desplazarse en dos direcciones a la vez.
• Cómo se comprueba. Sube el tamaño al máximo, tamaños de accesibilidad incluidos, y repite el recorrido girando el móvil.
• Qué se ve cuando falla. Frases cortadas, etiquetas que desaparecen y pantallas bloqueadas en vertical sin motivo.

Subtítulos y audiodescripción en el vídeo

• Qué exige. Todo vídeo pregrabado con audio lleva subtítulos, y el que transmite información visual que el audio no cuenta necesita audiodescripción o una alternativa equivalente. Si hay vídeo en directo, subtítulos también.
• Cómo se comprueba. Quita el sonido y mira si te enteras; después cierra los ojos y escucha si te pierdes algo que solo se ve.
• Qué se ve cuando falla. El vídeo de onboarding sin subtítulos, y los tutoriales que enseñan dónde tocar sin decirlo en voz alta.

No depender solo del color

• Qué exige. Ninguna información se transmite solo con el color: estados, errores o series necesitan además texto, icono o forma.
• Cómo se comprueba. Activa el filtro en escala de grises del sistema. Si tienes que adivinar algo, falla.
• Qué se ve cuando falla. Puntos verdes y rojos sin etiqueta, y leyendas que son una fila de cuadraditos.

Operable

Foco visible y orden lógico

• Qué exige. Todo lo accionable se alcanza sin tocar la pantalla, muestra dónde está el foco y sigue el orden de lectura.
• Cómo se comprueba. Recorre cada pantalla con el tabulador del teclado, sin usar el dedo, y repítelo con el lector.
• Qué se ve cuando falla. El foco no se ve sobre fondos oscuros, el recorrido salta al pie, o hay iconos inalcanzables.

Objetivos táctiles con tamaño y separación suficientes

• Qué exige. Los elementos accionables tienen área de toque y separación suficientes para no activarse por error.
• Cómo se comprueba. Usa la app con el pulgar, de pie y con una mano. El área táctil real suele ser menor que el icono que ves. Hoy la norma no fija umbral —el criterio de tamaño de objetivo de las WCAG 2.1 es de nivel AAA y solo se exige AA—, así que la referencia práctica son las guías de Apple y Google. El umbral explícito de 24 × 24 píxeles CSS llega con las WCAG 2.2, y por tanto con la versión nueva, no con la que te aplica ahora.
• Qué se ve cuando falla. Una equis de cerrar diminuta y listas cuyo botón de borrar cae junto al de abrir.

Toda acción por gesto tiene alternativa

• Qué exige. Lo que exige hoy el criterio son los gestos multipunto o de trayectoria —pellizcar, rotar, dibujar un recorrido—: todos tienen que poder hacerse con un puntero simple, salvo que el gesto sea esencial. Mantener pulsado no entra ahí, y el arrastre solo tiene criterio propio desde la V4.1.1.
• Cómo se comprueba. Busca para cada gesto un botón equivalente. Con el lector activado, sus gestos se comen a los de la app.
• Qué se ve cuando falla. Un mapa que solo se amplía pellizcando con dos dedos, o una firma que solo se traza a mano alzada. Borrar deslizando y reordenar arrastrando son el caso de al lado: hoy es buena práctica darles alternativa y con la V4.1.1 pasa a ser requisito.

Sin límites de tiempo rígidos

• Qué exige. Si hay un plazo para completar algo, el usuario puede apagarlo, ajustarlo o ampliarlo, salvo que sea esencial.
• Cómo se comprueba. Localiza cada contador —códigos, cierre de sesión, avisos que se van solos— y haz esos flujos con el lector.
• Qué se ve cuando falla. Un código que caduca antes de que el lector termine de dictarlo, o una sesión cerrada a mitad de formulario.

Sin destellos ni movimiento impuesto

• Qué exige. Nada parpadea más de tres veces en un segundo, y el contenido en movimiento se puede pausar, parar u ocultar.
• Cómo se comprueba. Activa la reducción de movimiento y vuelve a entrar: transiciones, paralaje y animaciones deberían atenuarse.
• Qué se ve cuando falla. El carrusel de portada pasa de tarjeta sin botón de pausa: eso sí incumple hoy. Que la app anime igual con la reducción activada todavía no, pero es el primer sitio donde mirará quien audite contra la V4.1.1.

Comprensible

Idioma declarado

• Qué exige. La app declara su idioma al sistema. Marcar además los fragmentos en otro idioma sí se le pide a la web, pero la norma lo declara vacío para software no web: obligaría a etiquetar todo el texto de la app, y lo da por imposible.
• Cómo se comprueba. Con el lector activado, escucha la pronunciación. Es lo más rápido del checklist.
• Qué se ve cuando falla. Una voz en inglés leyendo español letra a letra, con las cifras y las fechas dichas al revés.

Etiquetas y mensajes de error útiles

• Qué exige. Cada campo tiene etiqueta persistente asociada y, ante un error, se identifica el campo y se dice qué corregir.
• Cómo se comprueba. Rellena mal un formulario real, con el lector activado y sin mirar: ¿podrías arreglarlo con lo que has oído?
• Qué se ve cuando falla. El campo se pone rojo y nadie lo anuncia, o el mensaje es «datos incorrectos» sin decir cuál.

Comportamiento previsible

• Qué exige. Recibir el foco o cambiar un valor no puede provocar por sí solo un cambio de contexto: navegar, enviar o reordenar.
• Cómo se comprueba. Recorre los formularios con el teclado, cambia cada desplegable y mira si la pantalla se mueve sola.
• Qué se ve cuando falla. Un selector de país que recarga y devuelve el foco al principio, o un botón de volver que cambia de lado.

Robusto

Nombre, función, valor y estado expuestos

• Qué exige. Es el requisito central de la cláusula 11: todo componente expone a las tecnologías de asistencia qué es, cómo se llama, en qué estado está y qué valor tiene, mediante las APIs de la plataforma.
• Cómo se comprueba. Para en cada control y escucha la frase entera: un interruptor debe anunciarse como interruptor y decir si está activado; un acordeón, si está desplegado.
• Qué se ve cuando falla. Controles dibujados a mano en vez del componente nativo: el lector anuncia «activado» sin decir qué, y los modales no se anuncian.

Un apunte honesto: ningún punto de este checklist necesita software de pago. Lo que cuesta dinero es escalarlo —veinte modelos de teléfono, automatización en integración continua, un informe firmado—, y hay algo que no automatiza ninguna herramienta: si una alternativa textual describe lo que la imagen aporta, solo lo juzga una persona.

El stack decide dónde aparecen los fallos: en nativo hablas directamente con las APIs de accesibilidad de cada plataforma, y en multiplataforma dependes de cómo la capa intermedia traduce tus componentes. Es un criterio que pesa al elegir entre desarrollo nativo y multiplataforma y que casi nunca entra a tiempo en esa decisión.

Los cinco fallos que más se repiten

Aparecen en apps de todos los tamaños, y los dos primeros se arreglan en un sitio y se propagan a toda la app.

• El contraste de los estados deshabilitados. Aquí la norma no obliga —los componentes inactivos están excluidos— y por eso no lo mide nadie. Aun así: «Continuar» en gris suele ser el elemento con peor contraste de la app, y es justo el que hay que leer para saber por qué no se puede seguir. No saldrá en el informe; arreglarlo cuesta un token de color.
• Iconos sin etiqueta. Papelera, corazón, tres puntos, filtro: el lector los anuncia como «botón» y la pantalla se vuelve una fila de botones idénticos. El más frecuente y el más rápido de arreglar.
• El foco que se pierde al abrir un modal. Se abre el diálogo y el foco se queda detrás: el usuario recorre contenido invisible y no encuentra el botón de confirmar. Al cerrarlo tampoco vuelve.
• Formularios que anuncian el error solo con color. El borde se pone rojo, el lector calla y el formulario se reenvía dos veces a ciegas.
• Vídeos con reproducción automática sin control de parada. Una portada que arranca sola, a veces con sonido y sin pausa visible. Para quien usa un lector, la pantalla se vuelve ruido.

Lo que un widget de accesibilidad no arregla

Los widgets —esa capa aparte que añade un botón flotante con contraste, tamaño de fuente y lectura en voz alta— se venden como atajo. Lo que hacen es superponer ajustes visuales sobre lo que ya hay. Lo que no hacen es casi todo lo de este artículo: no inventan la alternativa textual que falta, porque no saben qué muestra la imagen; no asocian una etiqueta a un campo del que nadie declaró la relación; no exponen nombre, función, valor y estado de un control dibujado a mano; no arreglan un orden de foco roto. Y a menudo estorban: duplican controles para el lector y compiten con los ajustes nativos.

Hay una razón de fondo. Quien necesita accesibilidad en un móvil no llega a tu app a configurarse nada: llega con VoiceOver o TalkBack activados, su tamaño de texto puesto y sus gestos aprendidos. Tu trabajo no es darle ajustes paralelos, es no romper los que ya usa. Un widget es una capa que no toca el código que causa los fallos.

Qué hacer si tu app no cumple y ya está publicada

Que la primera pasada saque una lista larga es lo normal, y el error caro es querer arreglarlos todos a la vez. El orden por impacto y coste:

Primero, lo que impide terminar un flujo. Si con el lector activado no se puede completar el registro, el acceso o el pago, eso no es un hallazgo de accesibilidad: es un fallo funcional. Va en el siguiente release.

Segundo, lo barato y masivo. Etiquetas de iconos, idioma declarado, contraste del sistema de diseño y áreas de toque: cambios de pocas líneas que se aplican en un sitio y se propagan a toda la app. La mejor relación entre esfuerzo y hallazgos cerrados.

Tercero, lo estructural. Componentes hechos a mano que sustituir por nativos, orden de foco, modales, formularios rehechos. Ya es refactor: se planifica por pantallas, empezando por las más usadas, y encaja en el mantenimiento de la app mejor que como proyecto aparte.

Cuarto, que no vuelva. Un criterio de aceptación de accesibilidad en cada tarea nueva, comprobaciones automáticas en integración continua y una pasada manual con lector antes de cada release grande. Sin esto, lo anterior se degrada en dos o tres versiones.

Y documenta sobre la marcha: informe con fecha y versión de la norma, hallazgos, decisiones y plan. Visto lo de la presunción de conformidad, ese expediente es hoy tu mejor argumento.

Lo que este checklist no cubre

Conviene decirlo, porque un checklist que se lee como completo es peor que no tenerlo. Lo de arriba es la primera pasada sobre la cláusula 11, que es donde está el grueso. Queda fuera:

• La cláusula 7, si tu app reproduce vídeo. Ahí viven los requisitos de subtítulos y audiodescripción del reproductor, más allá del contenido.
• La cláusula 6, si hay llamadas o videollamadas. Texto en tiempo real, identificación de quién llama, calidad de audio.
• La cláusula 10, si tu app genera o muestra documentos. Un PDF dentro de la app es un documento no web y tiene sus propios requisitos.
• La cláusula 5, con los requisitos genéricos —funcionalidad cerrada, biometría, conservar la información de accesibilidad—, y la 12, que es la documentación y el soporte: ayuda, tutoriales y canal de atención también entran.
• Dentro de la propia cláusula 11, criterios que no se comprueban con el recorrido de arriba: orden de lectura programático, propósito de los campos, encabezados y etiquetas descriptivos.

Ninguno se descubre con el móvil en la mano en una tarde, y por eso no están en el checklist. Si tu app hace alguna de esas cosas, la pasada manual te deja a medio camino y el resto es trabajo de auditoría.

Conclusión

La accesibilidad de una app no se demuestra con un sello ni con un botón flotante, sino con un recorrido hecho a mano —lector encendido, texto al máximo, teclado conectado— y con un informe que diga qué se ha mirado, contra qué versión de la norma y qué queda por arreglar. La EN 301 549 te da la lista; el móvil que tienes en la mesa, casi todo lo necesario para recorrerla.

Ten la foto completa: con la que te van a medir hoy es con la V3.2.1 y sus WCAG 2.1 en nivel AA, la V4.1.1 ya trae WCAG 2.2 y será la referencia cuando la Comisión la cite y bajo la Ley Europea de Accesibilidad todavía no hay presunción de conformidad para nadie. Eso no resta valor a auditar. Si quieres que pasemos este checklist sobre tu app, cuéntanos qué app tienes y con qué está construida: te decimos sin coste por dónde empezar. La auditoría formal, con informe y evidencias, es trabajo aparte y se cobra como tal.