lunes, 10 de septiembre de 2018

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

EN 301549 - Apps nativas. Deben cumplir el nivel AA de las WCAG 2.1 (excepto los criterios 2.4.1, 2.4.2, 2.4.5, 3.1.2, 3.2.3, 3.2.4, 4.1.3) más, de manera condicional, los requisitos de los capítulos 5. Requisitos generales, 6. Requisitos  si hay comunicación bidireccional, 7.Requisitos si hay capacidad de vídeo y 11.8 Requisitos si es una herramienta de autor. De manera no condicional hay que cumplir con los requisitos de los capítulos 11.1-11.7 Software y  12. Documentación y servicio de apoyo.

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 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 condicionales, 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 "Esquema de los requisitos de la EN 301 549 aplicables a sitios web, documentos y software. Correspondencia con las WCAG 2.1" (Excel, 101 KB, actualizada 2018)

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

Índice:

Requisitos obligatorios para todas las apps

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 7 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
  • 2.4.2 Título de las páginas
  • 2.4.5 Múltiples vías
  • 3.1.2 Idioma de las partes de la página
  • 3.2.3 Navegación coherente
  • 3.2.4 Identificación coherente
  • 4.1.3 Mensajes de estado

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

La diferencia entre las WCAG 2.0 y las WCAG 2.1 es que estas últimas incluyen 17 criterios nuevos: 5 de nivel A y 7 de nivel AA.

Si necesitas conocer los nuevos criterios de las WCAG 2.1 puedes consultar el artículo: WCAG 2.1, recomendación hasta las WCAG 3.0

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 no condicionales.

11.5 Interoperabilidad con los productos de apoyo

Cuando el software es una plataforma:

  • 11.5.2.1: debe proporcionar un conjunto de servicios documentados que permitan que el software con una interfaz de usuario que se ejecuta sobre esta plataforma interactúe con los productos de apoyo. En este caso se deben cumplir los requisitos del 11.5.2.5 al 11.5.2.17, excepto cuando el concepto que se trata no esté soportado (por ejemplo, si no se permite la selección, no se aplicarán los requisitos relacionados con la selección)
  • 11.5.2.2: debe proporcionar un conjunto de servicios documentados de accesibilidad de la plataforma que permitan a los productos de apoyo interoperar con el software que tiene una interfaz de usuario y se ejecuta sobre la plataforma.

Cuando el software proporciona una interfaz de usuario (11.5.2.3): 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.

Cuando el software sea un producto de apoyo (11.5.2.4): utilizará los servicios documentados de accesibilidad de la plataforma. También puede utilizar otros servicios documentados de accesibilidad.

Los requisitos que se listan a continuación (11.5.2.5-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 Uso de las características de accesibilidad documentadas

Tiene dos requisitos:

  • 11.6.1 Control del usuario de las funciones de accesibilidad: cuando el software es una plataforma, debe proporcionar suficientes modos de operación para el control del usuario sobre las funciones de accesibilidad documentadas de la plataforma destinadas a los usuarios.
  • 11.6.2 No interrumpir las funciones de accesibilidad: cuando el software proporciona una interfaz de usuario, no se debe interrumpir las funciones de accesibilidad documentadas de la plataforma, excepto cuando así lo solicite el usuario durante el funcionamiento del software. Por ejemplo, si el sistema operativo ofrece la función de lupa, de reconocimiento de voz, de lector de pantalla, etc. la app no debe anular o interrumpir la funcionalidad, a menos que sea a través de una opción incorporada a la app que el usuario pueda seleccionar.

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 para 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 un cursor o tamaño de fuente grande, un modo de alto contraste, etc. 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"

Los requisitos del capítulo 12 de la EN 301 549 también son obligatorios de manera no condicional para las apps nativas.

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 condicionales

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.1.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.1.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.
    • 6.1.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.1.4 Respuesta de RRT: que se establece en 1 segundo.
  • 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 (no se aplica a las apps nativas*)
  • 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. Cuando la comunicación bidireccional de voz incluye vídeo en tiempo real, debe soportar al menos la resolución QCIF y debería soportar preferiblemente al menos la resolución CIF. Debería soportar al menos una velocidad de 12 frames por segundo, y preferiblemente 20 frames por segundo. Además se debería garantizar una diferencia máxima de tiempo de 100 ms entre la voz y la imagen de vídeo presentada al usuario.
  • 6.6 Alternativas a los servicios basados en vídeo (no se aplica a las apps nativas*)

* Según el anexo A de la EN 301549 los requisitos 6.4 y 6.6 no aplican a las apps nativas

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. Cuando se proporcionan como parte del contenido hay que permitir que el usuario elija mostrar los subtítulos. Los subtítulos tendrán información sobre el tiempo, el color y la posición. Los tres son importantes: el tiempo para la sincronización, el color por ejemplo para identificar al que habla, y la posición para evitar que tapen información relevante.
  • 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.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.0 / WCAG 2.1 (en este aspecto son equivalentes) puedes consultar el artículo: Tabla resumen de los requisitos de accesibilidad para los medios tempodependientes según las WCAG 2.0

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)"

Vimos que se aplicaban criterios del capítulo 11 de forma no condicional. También aplican a las apps nativas los criterios del subcapítulo 11.8 de forma condicional, pues solo aplican 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

Artículos relacionados:

0 comentarios :
Publicar un comentario