lunes, 3 de septiembre de 2018

Requisitos de accesibilidad de la EN 301 549 aplicables a las páginas web

EN 301549 - Páginas web. Deben cumplir el nivel AA de las WCAG 2.1 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 del capítulo 11.6.2/11.7 de Software y 12. Documentación y servicio de apoyo.

El objetivo de este artículo es clarificar qué requisitos hay que cumplir para que las páginas web sean conformes con la norma de accesibilidad EN 301 549.

La norma EN 301 549 es la norma europea que recoge los requisitos de accesibilidad que deben cumplir todos los productos y servicios TIC, incluidas páginas web, documentos electrónicos o apps nativas, y es a la que hace referencia la legislación europea y en breve la española.

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

Si quieres profundizar primero en el 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 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 todos los sitios web

Nivel AA de las WCAG 2.1

En primer lugar las páginas web deben cumplir con el nivel AA de las WCAG 2.1.

Esto implica cumplir con los 30 criterios de nivel A, los 20 criterios de nivel AA, 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"

El anexo A de la norma indica que a las páginas web también aplican dos requisitos del capítulo "11. Software" de forma no condicional:

  • 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. el sitio no debe anular o interrumpir la funcionalidad, a menos que sea a través de una opción incorporada al sitio 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. el sitio 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 son obligatorios de manera no condicional para las páginas web.

12.1 Documentación del producto

Son los requisitos que debe cumplir la documentación del sitio o producto.

  • 12.1.1 Accesibilidad y características de compatibilidad: la documentación del sitio o producto, 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 del sitio 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 el sitio 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 "11.8. Software (Herramientas de autor)"

Vimos que se aplicaban criterios del capítulo 11 de forma no condicional. También aplican a las páginas web los criterios del subcapítulo 11.8 de forma condicional, pues solo aplican si el sitio es una herramienta de autor. Este sería, por ejemplo, el caso de Blogger, un sitio web que permite generar páginas web; o Google Docs, una aplicación web que permite generar 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) Es decir, Blogger y Google Docs deben permitir y guiar la producción de páginas web y documentos electrónicos accesibles, respectivamente. Para ello tienen que permitir que el autor incluya el título y el idioma del documento, defina los encabezados, añada el texto alternativo a las imágenes, identifique las celdas de encabezado en las tablas, etc. El criterio permite que alguna de estas necesidades pueda llevarse a cabo mediante herramientas adicionales. Por ejemplo, para la inclusión de los subtítulos de los vídeos puede proporcionarse una herramienta diferente. Si necesitas ampliar información sobre cómo llevar a cabo este criterio, puedes consultar las Authoring Tool Accessibility Guidelines (ATAG) 2.0 del W3C.
  • 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 aplicación web permite 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.

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 el sitio 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 páginas web*)
  • 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 páginas web*)

* Según el anexo A de la EN 301549 los requisitos 6.4 y 6.6 no aplican a las páginas web

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

Si tu sitio 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. 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 puedan 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.

Recursos de interés

Artículos relacionados:

0 comentarios :
Publicar un comentario