Requisitos de accesibilidad de la EN 301 549 aplicables a las apps móviles nativas, obligatorios por ley a partir de 2021

Última actualización: 22/12/2022

El objetivo de este artículo es clarificar qué requisitos tienen que cumplir las apps nativas para ser conformes con la norma de accesibilidad EN 301 549.

La norma EN 301 549 (V3.2.1 (2021-03) - PDF, 2.2MB) es la norma europea que recoge los requisitos de accesibilidad de todos los productos y servicios TIC, incluidas páginas web, documentos electrónicos o apps móviles.

El 20 de septiembre entró en vigor el "Real Decreto sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles del Sector Público" que traspone la Directiva europea 2016/2102 y que obliga a que las apps nativas, al menos del sector público, sean accesibles a partir del 23 de junio de 2021 de acuerdo con la norma EN 301 549.

Aunque el grueso de los requisitos que hay que cumplir es el nivel AA de las WCAG (de las WCAG 2.1 desde la actualización de la norma en agosto de 2018) también hay otros requisitos obligatorios, como los referentes a la documentación y servicios de soporte que se ofrecen, la interoperabilidad con los productos de apoyo o las preferencias del usuario; así como otros en función de si la app ofrece determinadas características como comunicación bidireccional por voz, reproducción de vídeos o si se trata de una herramienta de autor.

Si quieres primero tener un conocimiento general de la norma EN 301 549, te recomiendo que leas mi artículo: EN 301 549: norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC)

Si necesitas profundizar en cómo aplicar los requisitos a nivel de código, te recomiendo mi artículo: Apps nativas de Android accesibles

También puedes consultar cómo se aplica la norma EN 301 549 a las páginas web en el artículo anterior: Requisitos de accesibilidad de la EN 301 549 aplicables a las páginas web, puesto que ahora las páginas web deben ser accesibles también respecto a la EN 301 549.

Si quieres consultar de forma esquemática todos los requisitos que aplican a páginas web, apps nativas y documentos electrónicos, puedes consultar la tabla de equivalencia entre las WCAG y la EN 301 549, en el "Tabla de los requisitos de la EN 301 549 v3.2.1 (2021-03) aplicables a sitios web, documentos y apps nativas. Correspondencia con las WCAG 2.1" (Excel, 101 KB, actualizada en 2022)

Por último, si quieres conocer las obligaciones del nuevo Real Decreto 1112/2018, puedes consultar el artículo: Real Decreto 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público

Aguía Aplicaciones móviles accesibles

Olga Carreras, 2023

Un guía divulgativa sobre la accesibilidad en aplicaciones móviles. Está dirigida a cualquier personas que quiera comprender qué es una aplicación móvil accesible y qué requisitos debe cumplir sin necesidad de tener conocimientos técnicos específicos.

En la guía explico todos los requisitos de la EN 301 549. También incluye un anexo con una lista de verificación.

Leer reseña

Descarga gratuita del libro "Guía Aplicaciones móviles accesible" en PDF accesible (10MB)

Índice:

• Nivel AA de las WCAG 2.1
• Requisitos del capítulo "11. Software"
• Requisitos del capítulo "12. Documentación y servicio de soporte"
• Requisitos del capítulo "5. Requisitos generales"
• Requisitos del capítulo "6. Requisitos aplicables cuando hay comunicación bidireccional de voz"
• Requisitos del capítulo "7. Requisitos aplicables cuando hay capacidad de vídeo"
• Requisitos del capítulo "11.8. Requisitos aplicables cuando es una herramienta de autor"
• Recursos de interés

Nivel AA de las WCAG 2.1

En primer lugar las apps nativas deben cumplir con el nivel AA de las WCAG 2.1.

Sin embargo, hay 6 criterios de las WCAG 2.1 que no se aplican a las apps nativas y no sería necesario cumplir:

• 2.4.1 Evitar bloques A
• 2.4.2 Título de las páginas A
• 2.4.5 Múltiples vías AA
• 3.1.2 Idioma de las partes de la página AA
• 3.2.3 Navegación coherente AA
• 3.2.4 Identificación coherente AA
• 4.1.3 Mensajes de estado AA, desde la versión 3.1.1 de la norma EN 301 549, el criterio 4.1.3 sí aplica a las apps (en las versiones anteriores no aplicaba)

Esto implica cumplir con 28 criterios de nivel A (2 menos respecto a las páginas web), 16 criterios de nivel AA (4 menos respecto a las páginas web), y los 5 requisitos de conformidad.

Requisitos del capítulo "11. Software"

En el capítulo 11 se listan todos los requisitos de accesibilidad que debe cumplir el software, donde se incluyen las apps nativas. En los subcapítulos 11.1-11.4 se referencian los criterios relativos a las WCAG 2.1, como hemos visto en el apartado anterior.

Pero además se incluyen 3 subcapítulos más (11.5-11.7) con otros requisitos adicionales.

11.5 Interoperabilidad con los productos de apoyo

Cuando el software proporciona una interfaz de usuario (11.5.2.3), como es el caso de una aplicación móvil, utilizará los servicios de accesibilidad documentados de la plataforma aplicables. Si estos no permiten que el software cumpla con los requisitos del 11.5.2.5 al 11.5.2.17, utilizará otros servicios documentados para interoperar con los productos de apoyo. Se indica que es una buena práctica desarrollar software con herramientas que implementen automáticamente los servicios de accesibilidad de la plataforma subyacente.

Los requisitos del 11.5.2.5 al 11.5.17 solo se aplican si el software no proporciona funcionalidades cerradas (funcionalidades limitadas por características que impiden a un usuario instalar, conectar o utilizar productos de apoyo), de lo contrario se aplicaría el capítulo 5.1.

Todos estos requisitos se aplican cuando el software proporciona una interfaz de usuario. En ellos se identifican características de la interfaz de usuario que se deben exponer mediante los servicios de accesibilidad, y que deben exponerse determinados por software para que puedan ser comprendidos por los productos de apoyo.

• 11.5.2.5 Información del objeto: el rol, el estado, los límites, el nombre y la descripción de los elementos de la interfaz.
• 11.5.2.6 Fila, columna y cabeceras: la fila y la columna de cada celda de una tabla de datos, y los encabezados de fila y columna, si están presentes.
• 11.5.2.7 Valores: el valor actual de un elemento de la interfaz de usuario y cualquier valor mínimo o máximo del rango, si el elemento de la interfaz de usuario transmite información sobre un rango de valores.
• 11.5.2.8 Relaciones de etiquetado: la relación entre los elemento de la interfaz de usuario y sus etiquetas.
• 11.5.2.9 Relaciones padre-hijo: la relación entre un elemento de la interfaz de usuario con otros elementos que sean padres o hijos del mismo.
• 11.5.2.10 Texto: el contenido, los atributos y el límite del texto renderizado en pantalla.
• 11.5.2.11 Lista de acciones disponibles: lista de las acciones disponibles que se pueden ejecutar con un elemento de la interfaz de usuario.
• 11.5.2.12 Ejecución de acciones disponibles: siempre que lo permitan los requisitos de seguridad, deberá permitir la ejecución de las acciones expuestas en la cláusula 11.2.5.11 por los productos de apoyo.
• 11.5.2.13 Seguimiento del foco y de los atributos de selección: la información sobre el foco, el punto de inserción de texto y los atributos de selección de los elementos de la interfaz de usuario.
• 11.5.2.14 Modificación del foco y de los atributos de selección: donde lo permitan los requisitos de seguridad, se debe permitir que los productos de apoyo modifiquen los atributos del foco, de inserción de texto y de selección de los elementos de la interfaz de usuario, cuando el usuario puede modificar estos elementos.
• 11.5.2.15 Notificación de cambios: también se debe exponer los cambios en los atributos de los elementos de la interfaz de usuario, determinables por software, a los que se hace referencia en los requisitos del 11.5.2.5 al 11.5.2.11 y 11.5.2.13.
• 11.5.2.16 Modificaciones de los estados y propiedades: cuando lo permitan los requisitos de seguridad, se debe permitir que los productos de apoyo modifiquen los estados y las propiedades de los elementos de la interfaz de usuario, cuando el usuario puede modificar estos elementos.
• 11.5.2.17 Modificación de valores y texto: cuando lo permitan los requisitos de seguridad, se debe permitir que los productos de apoyo modifiquen los valores y el texto de los elementos de la interfaz de usuario utilizando los métodos de entrada de la plataforma, cuando el usuario puede modificar estos elementos sin el uso de productos de apoyo.

Podéis ver ejemplos concretos de código para cumplirlo en el caso de las apps nativas de Android en mi artículo: Apps nativas de Android accesibles

11.6.2 No alteración de las características de accesibilidad

El desarrollador no debe alterar o inteferir en aquellas características de accesibilidad que se definen en la documentación de la plataforma, salvo cuando así lo solicite el usuario al operar con la aplicación. Es decir, si el usuario tiene activa la lupa o el lector de pantalla, la aplicación no debe anular o interrumpir estas funciones, a menos que incluyas una opción específica en la aplicación para que el usuario lo haga.

11.7 Preferencias de usuario

Cuando el software proporciona una interfaz de usuario, debe proporcionar suficientes modos de operación que usen las preferencias de usuario definidas en los ajustes de la plataforma respecto al color, contraste, tipo de fuente, tamaño de fuente y cursor de foco, excepto para el software diseñado para aislarse de sus plataformas subyacentes. El software que está aislado de su plataforma subyacente no tiene acceso a la configuración del usuario en la plataforma y, por lo tanto, no puede adherirse a ella.

Es decir, que si a nivel de preferencias de la plataforma tienes configurado, por ejemplo, un cursor o tamaño de fuente grande o un modo de alto contraste, la app debe respetarlo y permitir al usuario operar con las preferencias definidas en la plataforma.

Requisitos del capítulo "12. Documentación y servicio de soporte"

12.1 Documentación del producto

Son los requisitos que debe cumplir la documentación de la app.

• 12.1.1 Accesibilidad y características de compatibilidad: la documentación, tanto si se proporciona por separado o integrada, debe enumerar y explicar cómo usar las características de accesibilidad y compatibilidad (como las funciones de accesibilidad incorporadas y las funciones de accesibilidad que brindan compatibilidad con los productos de apoyo).
• 12.1.2 Documentación accesible: la documentación estará disponible al menos en uno de los siguientes formatos electrónicos
  • formato web accesible
  • documento electrónico accesible

  Esto no excluye la posibilidad de que se proporcione también en otros formatos electrónicos o impresos no accesibles.

  Tampoco excluye la posibilidad de proporcionar formatos alternativos que satisfagan las necesidades de un tipo específico de usuarios (por ejemplo, documentos en braille para personas ciegas, o información en Lectura fácil para personas con discapacidad cognitiva).

  Si la documentación es parte integral del producto, se proporciona a través de una interfaz de usuario accesible.

12.2 Servicios de soporte

En el apartado 12.2.1 se clarifica que un servicio de soporte puede ser: help desk, call center, soporte técnico, TRS o servicio de capacitación. Por tanto, si la app no ofrece estos servicios no se aplicarán estos requisitos.

• 12.2.2 Información sobre accesibilidad y características de compatibilidad: los servicios de soporte deben proporcionar información sobre las características de accesibilidad y compatibilidad que se incluyen en la documentación del producto (como funciones de accesibilidad incorporadas y funciones de accesibilidad que brindan compatibilidad con los productos de apoyo).
• 12.2.3 Comunicación efectiva: el servicio de soporte deberá satisfacer las necesidades de las personas con discapacidad, bien directamente, bien a través de un punto de referencia.
• 12.2.4 Documentación accesible: la documentación proporcionada por los servicios de soporte estará disponible en al menos uno de los siguientes formatos:
  • formato web accesible
  • documento electrónico accesible

  Esto no excluye la posibilidad de que se proporcione también en otros formatos electrónicos o impresos no accesibles.

  Tampoco excluye la posibilidad de proporcionar formatos alternativos que satisfagan las necesidades de un tipo específico de usuarios (por ejemplo, documentos en braille para personas ciegas, o información en Lectura fácil para personas con discapacidad cognitiva).

Requisitos del capítulo "5. Requisitos generales"

Se aplican salvo en el caso de funcionalidad cerrada. La funcionalidad cerrada hace referencia a las funcionalidades limitadas por características que impiden a un usuario instalar, conectar o utilizar productos de apoyo.

• 5.2 Activación de características de accesibilidad: para activar las características de accesibilidad documentadas para satisfacer una necesidad específica no se puede depender de un método que esa necesidad no soporte.
• 5.3 Biométrica: cuando se utilizan características biológicas (huellas dactilares, patrones de retina, etc.) para el control del producto o para la identificación del usuario, no pueden basarse, como único medio, en una característica biológica particular, sino que debe haber medios alternativos (que pueden ser biométricos o no). Los métodos biométricos basados ​​en características biológicas diferentes aumentan la probabilidad de que las personas con discapacidad posean al menos una de las características biológicas especificadas. Ejemplos de características biológicas diferentes son las huellas dactilares, los patrones de la retina del ojo, de voz y de cara.
• 5.4 Preservación de la información de accesibilidad durante la conversión: si el producto convierte información o una comunicación, debe preservar la información de accesibilidad, en la medida en que dicha información pueda estar contenida o soportada por el formato de destino.
• 5.5 Elementos accionables: cuando haya partes operables que requieran apretar, pellizcar o torcer la muñeca para operar, se proporcionará un medio alternativo accesible que no requiera estas acciones. Además se proporcionará un medio para discernir cada parte operable, sin requerir la visión y sin realizar la acción asociada con la parte operable. Una forma de cumplir este requisito es haciendo que las partes operables sean discernibles táctilmente.
• 5.6 Controles de bloqueo o conmutación (por ejemplo la tecla "Bloq Mayús", el botón de volumen de un teléfono, etc.) Si se presenta visualmente, se deberá determinar su estado por el tacto o el sonido sin operar el control; en caso contrario, si no se presenta visualmente, al menos se proporcionará un modo de funcionamiento en el que el estado del control pueda determinarse visualmente cuando se presente el control.
• 5.7 Repetición de caracteres de teclado: si no se puede desactivar, el retardo antes de la repetición debería poderse ajustar al menos a 2 segundos, y el ratio de repetición de la tecla ser ajustable hasta un carácter cada 2 segundos.
• 5.8 Aceptación de pulsación de doble tecla: el retardo después de cualquier pulsación de tecla, durante el cual no se aceptará una pulsación de tecla adicional si es idéntica a la pulsación de tecla anterior, será ajustable al menos a 0,5 segundos.
• 5.9 Acciones simultáneas del usuario (por ejemplo tener que usar ambas manos para abrir la tapa de un ordenador portátil, tener que presionar dos o más teclas al mismo tiempo o tener que tocar una superficie con más de un dedo). Se proporcionará al menos un modo de funcionamiento que no requiera acciones simultáneas de los usuarios al operar. Está muy relacionado con el nuevo criterio "2.5.1 Pointer gestures (A)" de las WCAG 2.1

Requisitos del capítulo "6. Requisitos aplicables cuando hay comunicación bidireccional de voz"

En el caso de que en la app se permita la comunicación bidireccional de voz (emisor y receptor intercambian mensajes de voz) se deben cumplir los siguientes requisitos:

• 6.1 Ancho de banda para voz: a fin de proporcionar una buena calidad de audio, se podrá codificar y decodificar la comunicación de voz bidireccional con un rango de frecuencia con un límite superior de al menos 7000 Hz (recommendation ITU-T G.722).
• 6.2 Funcionalidad de texto en tiempo real (RTT):
  • 6.2.1 Proveer RTT: cuando se admita comunicación bidireccional de voz en un contexto de uso específico, se permitirá que un usuario se comunique con otro mediante RTT. Se deberá proporcionar un mecanismo para seleccionar un modo de operación que permita la voz y el texto simultáneos.
  • 6.2.2 Visualización de RTT: el texto enviado y el texto recibido estarán separados y se diferenciarán visualmente. Además, la dirección de envío / recepción del texto transmitido se podrá determinar mediante programación (a menos que el RTT tenga funcionalidad cerrada) para permitir que los lectores de pantalla puedan distinguir entre el texto entrante y el texto saliente cuando se utilizan con la funcionalidad RTT. Por otra parte, se tendrá que identificar al hablante y haber un indicador visual de la actividad de audio en pantalla.
  • 6.2.3 Interoperabilidad: cuando soportas RTT y interactúas con otro producto con funcionalidad RTT, se deben soportar al menos uno de los cuatro mecanismos de interoperabilidad que se describen.
  • 6.2.4 Respuesta de RTT: que se establece en 500 milisegundos.
• 6.3 Identificación de llamadas: si se proporciona identificación de llamadas o funciones de telecomunicaciones similares, la identificación de la persona que llama y las funciones de telecomunicaciones similares estarán disponibles en formato texto y en al menos otra modalidad.
• 6.4 Alternativas a los servicios basados en voz: cuando se proporciona un servicio de comunicación basado en voz en tiempo real y opciones de buzón de voz, asistente automático o respuesta interactiva de voz, se debe ofrecer a los usuarios un modo de acceder a la información, así como de realizar las tareas facilitadas, sin que sea necesario el uso de la audición o de la voz.
• 6.5 Comunicación mediante vídeo: proporciona requisitos de rendimiento que respaldan a los usuarios que se comunican mediante el lengua de signos y la lectura de labios, como una resolución de vídeo QVGA como mínimo, al menos una frecuencia de imagen de 20 frames por segundo o una diferencia máxima de tiempo de 100 ms entre la voz y la imagen de vídeo presentada al usuario. Incluye también otros requisitos como proporcionar un indicador visual de audio con vídeo o la indicación del hablante en la comunicación por vídeo en lenguaje de signos.

Requisitos del capítulo "7. Requisitos aplicables cuando hay capacidad de vídeo"

Si tu app incluye vídeo, deberá cumplir estos requisitos que hacen referencia a los subtítulos, la audiodescripción y los controles de usuario para controlarlos.

Recordemos que las WCAG 2.0/2.1 obligan a incluir subtítulos y audiodescripciones a los vídeos para alcanzar el nivel AA.

7.1 Subtítulos

Los requisitos para los subtítulos son:

• 7.1.1 Reproducción de los subtítulos: debe haber un mecanismo para mostrar los subtítulos disponibles.
• 7.1.2 Sincronicación de los subtítulos: el mecanismo para mostrar los subtítulos deberá preservar la sincronización entre el audio y los subtítulos.
• 7.1.3 Preservación de los subtítulos: si el producto retransmite, convierte o graba vídeo con audio sincronizado, se deberán preservar los subtítulos de manera que puedan presentarse de forma consistente con los puntos anteriores (7.1.1 y 7.1.2). Los aspectos de presentación adicionales de los subtítulos, como la posición de la pantalla, los colores, estilo o tipografía del texto, pueden transmitir significado, de modo que alterar estos aspectos de presentación podría cambiar el significado y debería evitarse siempre que sea posible.
• 7.1.4 Características de los subtítulos: cuando se proporcionen subtítulos, el usuario tiene que poder adaptarlos a sus necesidades, por ejemplo, personalizando el tamaño y color de los mismos.
• 7.1.5 Subtítulos hablados: se tiene que facilitar una salida hablada de los subtítulos disponibles.

7.2 Audiodescripción

Si no tienes muy claro qué es una audiodescripción, puedes consultar un ejemplo en: Ejemplo de audiodescripción en YouTube

Los requisitos para las audiodescripciones son:

• 7.2.1 Reproducción de la audiodescripción: cuando se muestre video con audio sincronizado, se proporcionará un mecanismo para seleccionar y reproducir la audiodescripción disponible en el canal de audio predeterminado. Cuando la tecnología de video utilizada no tenga mecanismos explícitos y separados para la audiodescripción, se considerará que satisface este requisito si se permite al usuario seleccionar y reproducir varias pistas de audio. En tales casos, el contenido del video puede incluir la audiodescripción como una de las pistas de audio disponibles. Se indica además que el soporte para las audiodescripciones ampliadas es también muy útil.
• 7.2.2 Sincronicación de la audiodescripción: cuando hay un mecanismo para reproducir la audiodescripción se debe preservar la sincronización entre el contenido del audio/video y la audiodescripción.
• 7.2.3 Preservación de la audiodescripción: si el producto retransmite, convierte o graba vídeo con audio sincronizado se deberán preservar los datos de la audiodescripción de modo que se pueda reproducir de forma consistente con los puntos anteriores (7.2.1 y 7.2.2).

Si quieres recordar las alternativas que debes ofrecer en los vídeos y audios para cumplir con las WCAG 2.1 puedes consultar el artículo: Tabla resumen de los requisitos de accesibilidad para los medios tempodependientes según las WCAG 2.1

7.3 Controles de usuario

Los controles para activar los subtítulos y la audiodescripción deben estar al mismo nivel de interacción que el resto de controles habituales (reproducir, pausa...), es decir, en el mismo número de pasos.

Además, se indica que es una buena práctica que se incluyan controles adicionales que permitan al usuario seleccionar si los subtítulos y la audiodescripción se activan o desactivan de manera predeterminada.

Requisitos del capítulo "11.8. Software (Herramientas de autor)"

También aplican a las apps nativas los criterios del subcapítulo 11.8 si la app es una herramienta de autor, es decir, una app que genera páginas web o documentos electrónicos:

• 11.8.2 Creación de contenido accesible: las herramientas de autor deben permitir y guiar la producción de contenido que cumpla con los requisitos de accesibilidad para las páginas web y los documentos electrónicos (nivel AA de las WCAG 2.1)
• 11.8.3 Preservación de información de accesibilidad en transformaciones: si la herramienta de autor proporciona transformaciones de reestructuración o transformaciones de codificación, la información de accesibilidad se conservará en la salida, siempre y cuando existan mecanismos equivalentes en la tecnología de salida. Una transformación de reestructuración es aquella en la que el contenido permanece igual, pero las características estructurales del contenido se modifican, por ejemplo, tablas linealizadas o la división de un documento en páginas. Una transformación de codificación es aquella en la que se modifica la tecnología utilizada para codificar el contenido. Por ejemplo, si una app transformar un documento de texto o una página web en un PDF, el PDF debe preservar las características de accesibilidad (título del documento, texto alternativo de las imágenes, información semántica de los elementos, etc.)
• 11.8.4 Asistencia para la reparación: si la funcionalidad de verificación de accesibilidad de una herramienta de autor puede detectar que el contenido (tanto en páginas web como en documentos electrónicos) no cumple con los requisitos de las WCAG 2.1, la herramienta de autor deberá proporcionar sugerencias de reparación. Esto no excluye la reparación automática y semi-automatizada, que es posible (y recomendada) para muchos tipos de problemas de accesibilidad del contenido.
• 11.8.5 Plantillas: cuando una herramienta de autor proporciona plantillas, debe estar disponible al menos una plantilla (de página web o de documento electrónico, según corresponda) que admita la creación de contenido que cumpla con los requisitos de las WCAG 2.1, y debe estar identificada como plantilla accesible.

Recursos de interés

• "Tabla de los requisitos de la EN 301 549 v3.2.1 (2021-03) aplicables a sitios web, documentos y apps nativas. Correspondencia con las WCAG 2.1" (Excel, 101 KB, actualizada en 2022)
• Anexo A de la EN 301549 con todos los requisitos que deben cumplir las páginas web (tabla A.1) y las aplicaciones móviles (tabla A.2) para acatar la Directiva (UE) 2016/2102
• el árbol de decisión de Loïc Martínez Normand para ayudar a aplicar los requisitos. Hace referencia a la versión de la norma de 2015, así que ahora habrá que tener en cuenta la nueva numeración y los nuevos requisitos de las WCAG 2.1

Artículos relacionados:

• EN 301 549: norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC), 2018
• Requisitos de accesibilidad de la EN 301 549 aplicables a las páginas web, 2018
• Apps nativas de Android accesibles , 2018
• Real Decreto 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público
• Modelo de declaración de accesibilidad y de presentación de informes definido por la Comisión Europea