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

Última actualización: 15/06/2022

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 española en materia de accesibilidad web.

Aunque el grueso de los requisitos que hay que cumplir en una página web es el nivel AA de las WCAG 2.1 (capítulo 9 de la EN 301 549), también hay otros requisitos adicionales, unos obligatorios, como los referentes a las preferencias del usuario, la documentación y los servicios de soporte que se ofrecen; y otros condicionales, en función del tipo de sitio (si es una herramienta de autor) o de si el sitio presenta determinadas características, como comunicación bidireccional por voz o reproducción de vídeos.

Si es un sitio público español, ten en cuenta que la plantilla para el "Informe de revisión de accesibilidad para sitios web" del Observatorio de Accesibilidad Web con la que se reportan los resultados de la evaluación en profundidad, ya incluye todos estos requisitos, y no solo los equivalentes a las WCAG 2.1. Además, la declaración de conformidad debería recoger también las no conformidades en estos requisitos.

Los requisitos adicionales más relevantes para la mayoría de las auditorías web son los referentes a las preferencias del usuario y las condiciones del reproductor de vídeo.

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

Índice

Requisitos obligatorios para todos los sitios web
Requisitos condicionales
Recursos de interés

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. Estos requisitos vienen recogidos en el capítulo 9 de la EN 301 549, de tal manera que, por ejemplo, el requisito 1.1.1 de las WCAG 2.1 equivale al requisito 9.1.1.1 de la EN 301 549.

Requisitos del capítulo "11.7 Preferencias del usuario" (no condicional)

El anexo A de la EN 301549 indica que el requisito 11.7 Preferencias de usuario del capítulo "11. Software" aplica a las páginas web y lo hace de forma no condicional.

Cuando el software que no está diseñado para aislarse de su plataforma proporcione una interfaz de usuario, esa interfaz de usuario debe seguir los valores de las preferencias del usuario con respecto a unidades de medida, color, contraste, tipo de letra, cuerpo de letra y cursor del foco de la plataforma, salvo que el usuario los anule.

Hay que tener en cuenta que un software (como una página web) que está aislado de su plataforma subyacente (en el caso de una página web, el navegador) no tiene acceso a la configuración establecida por el usuario en dicha plataforma y, por tanto, no puede atenerse a ella.

Para los contenidos web, el agente de usuario constituye la plataforma subyacente.

Por tanto, cualquier portal web que se visualiza en un navegador de manera estándar, como es lo habitual, debe respetar las preferencias que el usuario ha definido en la configuración del navegador.

Esto no excluye la posibilidad de que el software tenga valores de configuración adicionales, siempre que exista un modo que permita a la aplicación respetar la configuración del sistema en el caso de que esta sea más restrictiva.

Este requisito implica que, si el usuario ha definido un tamaño de letra muy grande en la configuración del navegador, para cumplir este requisito, tu página web debe visualizarse con un tamaño de letra muy grande.

Tenlo en cuenta porque, el requisito (9.)1.4.4 Tamaño de letra, admite varias técnicas. Una de ellas es definir el texto en medidas relativas para que crezca según las preferencias del usuario. Pero admite otras técnicas suficientes para cumplirlo, como es mediante la correcta visualizando de la página con zoom 200%. Esta última técnica permitiría cumplir el criterio 1.4.4 pero no te permitiría cumplir con el requisito 11.7.

Requisitos del capítulo "12. Documentación y servicio de soporte" (no condicional)

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 Características de accesibilidad y de compatibilidad

La documentación que se suministra del producto (en nuestro caso un sitio web) debe enumerar y explicar cómo utilizar las características de accesibilidad y compatibilidad. Debe hacerlo tanto si se suministra por separado como si forma parte integral del producto.

La declaración de accesibilidad y las páginas de ayuda son ejemplos del suministro de información sobre el producto.

Las características de accesibilidad y compatibilidad incluyen las características de accesibilidad integradas, así como las características que permiten la compatibilidad con las tecnología de apoyo.

Nota: podría usarse W3C WebSchemas/Accessibility, que permite proporcionar los metadatos sobre la accesibilidad de las TIC.

12.1.2 Documentación accesible

La documentación que se suministra del producto debe proporcionarse al menos en uno de los siguientes formatos electrónicos:

formato web accesible (es decir, conforme con los requisitos del capítulo 9)
documento electrónico accesible (es decir, conforme con los requisitos del capítulo 10)

Esto no excluye la posibilidad de que se proporcione también la documentación del producto 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 usuario (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 proporcionará 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 las características de accesibilidad y 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.

Las características de accesibilidad y compatibilidad incluyen las características de accesibilidad integradas, así como las características de accesibilidad que permiten la compatibilidad con los productos de apoyo.

12.2.3 Comunicación efectiva

El servicio de soporte debe adaptarse a las necesidades de comunicación de las personas con discapacidad, bien directamente, bien a través de un punto de derivación.

12.2.4 Documentación accesible

La documentación proporcionada por los servicios de soporte debe proporcionarse al menos en uno de los siguientes formatos:

formato web accesible (es decir, conforme con los requisitos del capítulo 9)
documento electrónico accesible (es decir, conforme con requisitos del capítulo 10)

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

En el caso de que la documentación sea incorporada al producto, estará sujeta a los requisitos de accesibilidad.

Requisitos condicionales

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

Los requisitos del subcapítulo 11.8 aplican 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.1 Tecnología de gestión de contenidos: en la medida en que la información necesaria para la accesibilidad sea compatible con el formato que se utiliza para la salida de la herramienta de autor, las herramientas de autor deben cumplir los requisitos de los apartados 11.8.2 a 11.8.5
11.8.2 Creación de contenido accesible: las herramientas de autor deben permitir y guiar la producción de contenidos conforme a los capítulos 9 (páginas web) o 10 (para documento no web) (es decir, el nivel AA de las WCAG 2.1)
Por ejemplo, Blogger y Google Docs deberían permitir y guiar la producción de páginas web y documentos electrónicos accesibles, respectivamente. Para ello, tendrían 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 cumplir este criterio, puedes consultar las Authoring Tool Accessibility Guidelines (ATAG) 2.0 del W3C.
11.8.3 Preservación de la información de accesibilidad durante las transformaciones: si la herramienta de autor proporciona transformaciones de reestructuración o transformaciones de recodificació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 de una página web o documento electrónico no cumple con los requisitos del capítulo 9 o 10 respectivamente (es decir, el nivel AA 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 sea compatible con la creación de contenido accesible (es decir, los requisitos del capítulo 9 o 10, según corresponda, esto es, acorde con el nivel AA de las WCAG 2.1).
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: cuando el contenido web tenga características de accesibilidad documentadas, debe ser posible activar las características de accesibilidad documentadas para satisfacer una necesidad específica sin tener que recurrir para ello a un método que no sea compatible con esa necesidad.
5.3 Biométrica: cuando se utilizan características biológicas (huellas dactilares, patrones de retina, etc.) no se debe depender del uso de una característica biológica particular como único medio de identificación del usuario o de control de las TIC. Los medios alternativos de identificación del usuario o de control de las TIC 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 informaciones o comunicaciones, debe preservar toda la información que se proporciona a efectos de la accesibilidad (que no esté sujeta al derecho de propiedad intelectual) en la medida en que el formato de destino pueda contener o sea compatible con esa información.

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

En el caso de que se permita la comunicación bidireccional de voz (emisor y receptor intercambian mensajes de voz) en el sitio, 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 cuyo límite superior sea al menos de 7000 Hz (recomendación ITU-T G.722).
6.2 Funcionalidad de texto en tiempo real (RTT):
- 6.2.1.1 Comunicación mediante RTT: se debe proporcionar un modo de comunicación bidireccional mediante RTT, salvo que fuese necesario modificar el diseño para incorporar hardware de entrada o salida a las TIC. A efectos de interoperabilidad, se suele requerir el cumplimiento de la Recomendación ITU-T T.140
- 6.2.1.2 Voz y texto simultáneos: cuando se proporciona un medio de comunicación bidireccional por voz para permitir a los usuarios comunicarse mediante RTT, debe permitir la transmisión simultánea de voz y texto a través de una única conexión de usuario. Este requisito incluye diversas notas referentes en gran medida a la comunicación multiparte.
- 6.2.2.1 Presentación en pantalla diferenciable visualmente: cuando las TIC tienen capacidad de envío y recepción de RTT, el texto enviado que se muestra debe encontrarse visualmente diferenciado y separado del texto recibido.
  La capacidad del usuario para elegir entre la visualización de envío y recepción en la misma línea o de forma separada, así como la disponibilidad de opciones para su selección, permite a los usuarios visualizar el RTT de la forma más conveniente. Esto permitiría a los usuarios de braille utilizar un único campo con intervención por turnos, con lo que se consigue que el texto aparezca de la forma secuencial que puedan necesitar o preferir.
- 6.2.2.2 Dirección de envío y recepción determinable por software: cuando las TIC tienen capacidad de envío y recepción de RTT, la dirección de envío y recepción del texto transmitido debe poder determinarse por software, salvo que el RTT esté implementado como funcionalidad cerrada. De esta forma, se permite a los lectores de pantalla distinguir entre el texto entrante y el texto saliente cuando se utilizan con la funcionalidad RTT.
- 6.2.2.3 Identificación del hablante: cuando las TIC tienen capacidad de RTT y facilitan la identificación del hablante por voz, deben proporcionar la identificación del hablante por RTT.
- 6.2.2.4 Indicador visual de audio con texto en tiempo real: cuando las TIC tienen comunicación bidireccional y capacidad de RTT, deben proporcionar en pantalla un indicador visual de la actividad de audio en tiempo real.
- 6.2.3 Interoperabilidad: cuando las TIC proporcionan comunicación bidireccional por voz con funcionalidad RTT, e interoperan con otras TIC con funcionalidades RTT, deben ser compatibles con una serie de mecanismos de interoperabilidad RTT (incluye 4 subapartados)
- 6.2.4 Capacidad de respuesta de RTT: cuando las TIC proporcionen comunicación bidireccional por voz y utilicen una entrada RTT, dicha entrada debe transmitirse a la red TIC, o a la plataforma en la que se ejecuta la TIC, dentro de 500ms a partir del momento en el que la TIC tenga acceso a la unidad mínima de entrada de texto compuesta de forma fiable para su transmisión.
6.3 Identificación de llamadas: cuando las TIC proporcionen identificación de llamadas o funciones similares de telecomunicación, estas funciones de telecomunicación deben estar disponibles en forma textual, además de ser determinable por software, salvo que la funcionalidad esté cerrada.
6.4 Alternativas a los servicios basados en voz: cuando las TIC proporcionen un servicio de comunicación basada en voz en tiempo real e igualmente facilidades de buzón de voz, asistente automático o respuesta interactiva de voz, las TIC deben ofrecer a los usuarios un modo de acceder a la información, así como de realizar tareas facilitadas por las TIC sin que sea necesario el uso de la audición o de la voz.
6.5 Comunicación por vídeo:
- 6.5.2 Resolución: si se proporciona comunicación bidireccional por voz y se incluye una funcionalidad de vídeo en tiempo real, debe ser compatible con una resolución QVGA como mínimo.
- 6.5.3 Frecuencia de imagen: si se proporciona comunicación bidireccional por voz y se incluye una funcionalidad de vídeo en tiempo real, debe ser compatible con una frecuencia de imagen de 20 FPS como mínimo.
- 6.5.4 Sincronización entre audio y vídeo: si se proporciona comunicación bidireccional por voz y se incluye una funcionalidad de vídeo en tiempo real, se debe garantizar una diferencia temporal máxima de 100 ms entre la presentación de la voz y el vídeo al usuario.
- 6.5.5 Indicador visual de audio con video: esi se proporciona comunicación bidireccional por voz y se incluye una funcionalidad de vídeo en tiempo real, se debe proporcionar un indicador visual de la actividad de audio en tiempo real.
- 6.5.6 Identificación del hablante con comunicación por vídeo (lengua de signos): cuando las TIC proporcionen identificación del hablante para usuarios de voz, deben, una vez que se haya indicando el comienzo del uso de la lengua de signos, facilitar un modo para la identificación del hablante para los usuarios de lengua de signos en tiempo real.

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

Las WCAG 2.1 (capítulo 9 de la EN 301 549) obligan a incluir alternativas textuales a los vídeos, como los subtítulos y audiodescripciones, para alcanzar el nivel AA.

Este capítulo no trata por tanto de las alternativas que hay que dar a los vídeos, sino de ciertas condiciones que debe cumplir el reproductor de vídeo que incluyes en tus páginas web, en relación con la activación y personalización de los subtítulos y la audiodescripción.

7.1 Subtítulos

Los requisitos relacionados con 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 subtítulos ocultos como parte del contenido, hay que permitir que el usuario elija mostrar los subtítulos.
Este requisito se refiere a la capacidad del reproductor para mostrar los subtítulos; mientras que los requisitos de las WCAG hacen referencia a si se proporcionan subtítulos.

Los subtítulos pueden contener información sobre la velocidad, el color y la ubicación de los subtítulos. Los tres son necesarios: la velocidad para la sincronización; el color, por ejemplo, para identificar al que habla; y la posición para evitar que tapen información relevante.

Si se encuentra conectado un dispositivo braille, las TIC deberían proporcionar una opción para la reproducción de los subtítulos en el dispositivo braille.
7.1.2 Sincronización de los subtítulos: el mecanismo para mostrar los subtítulos deberá preservar la sincronización entre el audio y los subtítulos, que se establece dentro de 100 ms a partir de la marca temporal del subtítulo.
7.1.3 Preservación de los subtítulos: si el contenido web retransmite, convierte o graba vídeo con audio sincronizado, se debe preservar los datos de los subtítulos de manera que puedan visualizarse en consonancia con lo indicado en 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 las TIC visualicen subtítulos, deben proporcionar un modo en el que el usuario pueda adaptar las características visualizadas de los subtítulos a sus requisitos individuales, salvo en el caso de que los subtítulos se visualicen como caracteres no modificables (por ejemplo, subtítulos que son imágenes de mapa de bits).
La definición de los colores de fondo y de texto de los subtítulos, de su tipo y cuerpo de letra, de la opacidad de la caja de fondo de los subtítulos, y del contorno o borde de los tipos de letra, puede contribuir al cumplimiento de este requisito.
7.1.5 Subtítulos hablados: cuando las TIC visualicen vídeo con audio sincronizado, deben proporcionar un modo de operación que facilite una salida hablada de los subtítulos disponibles, salvo en el caso de que el contenido con los subtítulos visualizados no sea determinable por software (por ejemplo, subtítulos que son imágenes de mapa de bits).
La mayoría de los usuarios prefiere manejar el rango de salida de voz para los subtítulos hablados independientemente de la voz general de las TIC. Esto es posible cuando el fichero de audio con el subtítulo hablado se sirve en una pista de audio diferenciada y se mezcla en el dispositivo del usuario final.
La sincronización entre la presentación de la pista de audio separada con los subtítulos hablados y los subtítulos visualizados mejora la comprensibilidad de los subtítulos. El suministro de subtítulos como flujos de texto separados facilita la conversión de los textos respectivos a audio.

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 la audiodescripción disponible y reproducirla por 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 que el soporte para las audiodescripciones ampliadas es también muy útil.
7.2.2 Sincronizació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 contenido web 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.1 (capítulo 9 de las EN 301 549) 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, que necesites el mismo número de pasos para completar la tarea de pausar el vídeo que de activar los subtítulos, por ejemplo.

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.