jueves, 7 de noviembre de 2019

EN 301 549: Norma Europea de Accesibilidad para Productos y Servicios de Tecnologías de la Información y Comunicación (TIC) V3.2.1 (2021-03). En español UNE-EN 301549:2022

EN 301 549 V3.2.1 (2021-03)

Última actualización: 15/06/2022.

Este artículo integra las novedades de la última actualización de la norma, la versión EN 301 549 V3.2.1 (2021-03) (PDF, 2.2MB), equivalente en español a la UNE-EN 301549:2022.

Recordemos que el Real Decreto 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público dicta que los portales y apps del sector público deben cumplir con la última versión de la EN 301 549.

La norma ha sufrido diversas actualizaciones. La actualización de 2018 supuso un cambio importante respecto a su predecesora, porque suponía la adaptación de la norma a las WCAG 2.1. Sin embargo, la mayoría de los cambios de la versión de 2019 fueron menos relevantes, salvo alguna excepción.

La actualización de 2021, la EN 301549-2021 v.3.2.1, solo añade un apéndice F con el histórico de cambios de la norma en sus sucesivas versiones.

Estas normas tienen su equivalencia publicada en español por AENOR: la UNE-EN 301549:2020 es equivalente a la EN 301549-2019 v.3.1.1; o la UNE-EN 301549:2022 es equivalente a la EN 301549-2021 V3.2.1. Se puede consultar la tabla resumen de normativas en el PAe

Índice

Historia de la norma EN 301 549

Por qué se creó la norma

Los organismos europeos de Normalización CEN (Comité Europeo de Normalización), CENELEC (Comité Europeo de Normalización Electrotécnica) y ETSI (Instituto Europeo de Normalización de las Telecomunicaciones) aprobaron en 2014 la primera norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC).

La EN 301 549 ‘Requisitos de accesibilidad de productos y servicios TIC aplicables a la contratación pública en Europa’, era el resultado del mandato M 376 "Standardisation Mandate to CEN, CENELEC and ETSI in support of European accessibility requirements for public procurement of products and services in the ICT domain" de la Comisión Europea para elaborar un estándar europeo de requisitos funcionales de accesibilidad, en la contratación pública de productos y servicios TIC, que asegurara que eran accesibles para todas las personas.

La norma se actualizó en 2015 sin grandes novedades, y ha sido adoptada en el catálogo español como UNE-EN 301 549 por parte de AENOR, la entidad legalmente responsable del desarrollo de las normas técnicas en España. Por tanto, es aquí donde podéis encontrarla en español.

La norma EN 301 549 es la norma a la que va a hacer referencia la legislación europea y española en materia de accesibilidad TIC. En 2016 se publicó la Directiva (UE) 2016/2102 del Parlamento Europeo y del Consejo, de 26 de octubre de 2016, sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público que obliga a los sitios web y las apps del sector público al cumplimiento de la norma EN 301 549.

Esta directiva ha sido transpuesta a la legislación española por el Real Decreto 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público, de manera que la nueva ley española de accesibilidad hace también referencia a la EN 301 549. De hecho, especifica que hay que cumplir con la última versión publicada de la misma. Por ello es necesario conocer cuáles son los requisitos de accesibilidad que recoge.

Versión 2.1.2

Desde la publicación de la norma, y debido a la propia estructura de la misma, se hizo evidente que su aplicación era algo confusa. Consciente de esta dificultad, la Comisión Europea publicó en 2017 el mandato M/554 (PDF) por el cual instaba a los organismos correspondientes a actualizar la norma EN 301 549 para apoyar la aplicación de la directiva.

La versión que iba a dar respuesta a este mandato era la v2.1.1, pero durante el proceso se produjo la publicación de la nueva versión de las WCAG, de modo que se aprovechó para adaptar la norma a las WCAG 2.1, de ahí que la versión finalmente publicada sea la EN 301 549 v2.1.2

Las tres grandes novedades de la versión EN 301 549 v2.1.2 de 2018 fueron:

  • Se equipara a las WCAG 2.1
  • Los requisitos se numeran de forma que se pueda relacionar cada criterio con el criterio de las WCAG 2.1 correspondiente de una manera más transparente. Por ejemplo, el criterio de la norma 9.1.1.1 (páginas web) o 10.1.1.1 (documentos electrónicos) o 11.1.1.1 (software) es en todos casos equivalente al 1.1.1 de las WCAG 2.1
  • Se añade un anexo A con todos los requisitos que deben cumplir las páginas web y las apps móviles para acatar la Directiva (UE) 2016/2102, la cual obliga a que los portales y apps del sector público sean accesibles. Los criterios que aplican provienen de diferentes capítulos de la norma, de ahí que sea tan útil este anexo.

Versión 3.1.1

En noviembre de 2019 se aprueba la nueva versión 3.1.1, que entra en vigor cuando se publica en el Diario Oficial de la Unión Europea el 23 de abril de 2020 (consultar Work Programme. Details of 'REN/HF-00301549v311' Work Item Schedule).

La publicación de esta nueva versión se enmarca en la aprobación de la Directiva 2019/882 sobre los requisitos de accesibilidad de los productos y servicios en junio de ese mismo año 2019. Esta directiva legisla los requisitos de accesibilidad de determinados productos y servicios en Europa y deberá ser transpuesta a nuestra legislación antes del 28 de junio de 2022 (consultar el artículo Directiva 2019/882 sobre los requisitos de accesibilidad de los productos y servicios. European Accessibility Act.)

Los cambios en esta versión 3.1.1 son muchos, pero a mi parecer, pequeños y no especialmente significativos, salvo alguna excepción:

  • En el capítulo 7 "TIC con capacidades de vídeo", se incluyen dos requisitos relevantes porque aplican a la revisión de páginas web. Son los puntos 7.1.4 y 7.1.5, que amplían los requisitos relativos a los subtítulos.
  • Dentro de los requisitos de Hardware (capítulo 8), los cambios en el apartado 8.3 Stationary ICT (Acceso físico a las TIC), que define las dimensiones para acceder a las TIC estacionarias que se pueden colocar en un entorno construido.

    Dimensiones para que una persona en silla de ruedas pueda acceder a un cajero automático.

  • Un añadido relevante es el anexo E, una guía del documento donde se explica cómo utilizarlo. De hecho, si no estás familiarizado con la norma, es recomendable leerlo en primer lugar.
  • El capítulo 9, el relativo a los requisitos de las páginas web y equivalente a las WCAG 2.1, presenta cambios, pero no son significativos: la introducción se redacta de manera más sencilla y se listan los requisitos AAA en el apartado 9.5 (en la versión anterior estaban en un anexo) animando a cumplirlos.
  • En el capítulo 10, relativo a los requisitos de los documentos (que no sean páginas web), es interesante que añaden una nota indicando que estos requisitos aplican también: a los documentos a disposición de los usuarios que tengan firma digital, estén encriptados, estén protegidos por contraseña o tengan marcas de agua. Por otra parte, en esta versión, el requisito "10.4.1.3 Mensajes de estado" sí aplica a los documentos (en la versión anterior no aplicaba)
  • En el capítulo 11, relativo a los requisitos de software, se especifica en la introducción que también aplican a las apps, por si había alguna duda al respecto. Por otra parte, en esta versión, el requisito "11.4.1.3 Mensajes de estado" sí aplica a los documentos (en la versión anterior no aplicaba)
  • En la tabla A.1 del anexo A, donde se indican los requisitos que aplican a las páginas web, se eliminan requisitos, como parte de los requisitos del capítulo 5 o el requisito 11.6.2. También hay algún cambio en la tabla A.2
  • En el anexo D, que antes listaba los requisitos AAA (ahora incluidos en el capítulo 9), se pasa a indicar que la WAI está actualmente trabajando en mejorar los requisitos para las personas con discapacidad cognitiva, del lenguaje o del aprendizaje.
  • Hay muchos más cambios en diferentes apartados, a veces se modifica la redacción, o más habitual, se añaden nuevas notas. Es interesante que se hace referencia varias veces a W3C WebSchemas/Accessibility 2.0

Versión 3.2.1

La actualización de marzo de 2021, la EN 301549 v.3.2.1, solo añade un apéndice F con el histórico de cambios de la norma en sus sucesivas versiones.

Descarga las diferentes versiones

Descarga de las diferentes versiones:

Por último, indicar que la norma se publicó originalmente complementada por tres informes técnicos:

También puedes consultar Human Factors and accessibility, ETSI.

Relación con las WCAG

La norma EN 301 549 recoge los requisitos de accesibilidad que debe cumplir cualquier producto y servicio: páginas web, software incluidas apps nativas, documentos, hardware, etc.

El capítulo 9 de la norma recoge los criterios y requisitos de accesibilidad que se aplican al contenido web. Los criterios que incluye son todos los de nivel A y AA de las WCAG, así como sus 5 requisitos de conformidad (apartado 9.6). Desde la versión de 2018, los criterios que encontramos son los de las WCAG 2.1.

Hay que decir que se alienta a cumplir con criterios de nivel AAA, los cuales se listan en el apartado 9.5.

El capítulo 10 está dedicado a los documentos electrónicos (PDF, documento de texto, hoja de cálculo, etc.), a los cuales se aplican también las WCAG 2.1, pero se excluyen ciertos criterios que no aplican.

El capítulo 11 hace referencia al software, y es el que se aplicaría a las apps móviles. De nuevo se aplican las WCAG 2.1 excluyendo ciertos criterios que no aplican, e incluyendo otros específicos relacionados con la interoperabilidad (11.5), el uso de las características de accesibilidad documentadas (11.6), las preferencias de usuario (11.7) y las herramientas de autor (11.8).

La aplicación de los requisitos se complica porque además hay otros capítulos generales ("5. Requisitos generales"; "6. Requisitos cuando hay comunicación direccional de voz"; "7. Requisitos cuando hay capacidad de vídeo"; "12. Documentación y servicios de atención al cliente"), que se pueden tener que aplicar también, tanto en el caso de las páginas web, los documentos electrónicos o las apps móviles.

De ahí la utilidad del anexo A de la norma sobre la relación entre los requisitos que lista y el cumplimiento de la Directiva 2016/2102. El anexo "Annex A (informative): Relationship between the present document and the essential requirements of Directive 2016/2102" tiene dos tablas:

  • Tabla A.1: recoge los requisitos que deben cumplir las páginas web para acatar la directiva. Son requisitos de los capítulos: 9 (equivalente a las WCAG 2.1), 11.7 "Preferencias del usuario" y 12 "Documentación y servicios de atención al cliente", y otros capítulos condicionalmente ("5. Requisitos generales"; "6. Requisitos cuando hay comunicación direccional de voz", "7. Requisitos cuando hay capacidad de vídeo" y "11.8 Requisitos si es una herramienta de autor"). Artículos relacionado Requisitos de accesibilidad de la EN 301 549 aplicables a las páginas web
  • Tabla A.2: recoge los requisitos que deben cumplir las apps móviles para acatar la directiva. Son requisitos de los capítulos: 11 "Software" (WCAG 2.1 con excepciones y criterios adicionales) y 12 "Documentación y servicios de atención al cliente", y otros capítulos condicionalmente ("5. Requisitos generales"; "6. Requisitos cuando hay comunicación direccional de voz", "7. Requisitos cuando hay capacidad de vídeo" y "11.8 Requisitos si es una herramienta de autor") Artículos relacionado Requisitos de accesibilidad de la EN 301 549 aplicables a las apps móviles nativas, obligatorios por ley a partir de 2021

Para ayudar a aplicar la EN 301 549 a páginas web y apps móviles he preparado los siguientes recursos:

También sigue siendo útil el árbol de decisión de Loïc Martínez Normand para ayudar a aplicar los requisitos, aunque ahora habrá que tener en cuenta la nueva numeración y los nuevos requisitos de las WCAG 2.1

La norma EN 301 549 en detalle

Descripción de la norma

La norma especifica, de forma adecuada para su uso en la contratación pública europea, los requisitos funcionales de accesibilidad aplicables a los productos y servicios que incorporan TIC, junto con una descripción de los procedimientos de prueba y la metodología de evaluación para cada requisito de accesibilidad.

Constituye una fuente de consulta que hará posible que los resultados de las pruebas sean similares y la interpretación de estos sea clara, aun cuando los procedimientos sean seguidos por diferentes actores.

Se definen más de 200 requisitos y recomendaciones (capítulos 5 al 13).

Cada requisito y recomendación tiene los siguientes datos:

  • Número
  • Título
  • Definición
  • Notas (opcional)
  • Cumplimiento (anexo c):
    • Pre-condiciones: en qué condiciones se aplica.
    • Procedimiento: las acciones que debes realizar para verificar si cumple este requisito.
    • Resultado: indica en qué caso pasa o no pasa la validación.

Las descripciones de las pruebas y la metodología de evaluación que se incluyen en la norma han sido elaboradas a un nivel de detalle acorde con la norma ISO/IEC 17007:2009, de forma que las pruebas de conformidad puedan producir resultados concluyentes.

Todas las cláusulas, excepto las del capítulo 12 relacionadas con la documentación y los servicios de soporte, tienen un alcance propio. Esto significa que se introducen con la frase 'Where ICT <pre-condición>'. El cumplimiento se logra cuando la condición previa es verdadera y se pasa la prueba correspondiente (en el Anexo C), o cuando la condición previa es falsa (es decir, la condición previa no se cumple o no es válida).

La naturaleza inherente de ciertas situaciones hace que sea imposible hacer declaraciones confiables y definitivas de que el requisito de accesibilidad se ha cumplido. En esas situaciones, por lo tanto, los requisitos no son aplicables: cuando el producto está en un estado de fallo, reparación o mantenimiento donde el conjunto ordinario de funciones de entrada o salida no están disponibles; o durante las fases de inicio, apagado y otras transiciones de estado que se pueden completar sin la interacción del usuario.

Se indica que, incluso en las situaciones anteriores, es una buena práctica aplicar los requisitos del presente documento donde sea es factible y seguro hacerlo.

El esquema de la norma es el siguiente (donde indica WCAG 2.0, entiéndase WCAG 2.1 desde la versión de 2018):

Estructura EN 301549: 1. Scope; 2. References; 3.Definitions and abbreviations; Necesidad de los usuarios en el capítulo 4; Del capítulo 5 al 13 requisitos; al final 3 anexos

Estructura de la EN 301 549 (ver más grande). Imagen de Loïc Martínez Normand

Me voy a centrar en los capítulos 5-13 (que contienen los requisitos de accesibilidad) y en los anexos.

La relación entre el la norma y los requisitos de la "Directiva 2016/2102 sobre la accesibilidad de los sitios web y las aplicaciones móviles de los organismos del sector público" figura en el Anexo A, que es nuevo en la versión de 2018.

También puede ser de utilidad la Excel: "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).

Capítulo 5. Requisitos genéricos

Son aquellos que se aplican a cualquier hardware o software.

El capítulo se divide en los siguientes apartados:

  • 5.1 Funcionalidad cerrada: hace referencia a las funcionalidades limitadas por características que impiden a un usuario instalar, conectar o utilizar productos de apoyo. Cuando las TIC tengan una funcionalidad cerrada, deberán cumplir los requisitos establecidos en las cláusulas 5.2 a 13, según corresponda.
  • 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).
  • 5.4 Preservación de la información de accesibilidad durante la conversión, 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.

Capítulo 6. Comunicación bidireccional por voz

Recoge los requisitos que se deben cumplir si hay comunicación bidireccional por voz (en una web, en una app, etc.)

Los apartados son:

  • 6.1 Ancho de banda para voz
  • 6.2 Funcionalidad de texto en tiempo real (RTT)
  • 6.3 Identificación de llamadas
  • 6.4 Alternativas a los servicios basados en voz
  • 6.5 Comunicación mediante vídeo
  • 6.6 Alternativas a los servicios basados en vídeo

Por ejemplo, se establece que, cuando el producto o servicio TIC proporciona la identificación del llamador o funciones similares, la identificación de este (y las funciones similares) estarán disponibles en formato texto y por lo menos en otra modalidad.

Capítulo 7. TIC con capacidades de vídeo

Recoge los requisitos que se deben cumplir si hay capacidad de vídeo, bien sea en una web, en una app, en un documento, etc. y hace referencia específicamente a los subtítulos y la audiodescripción.

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.

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

Por su parte, el criterio "7.3 Controles de usuario" indica que 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.

Capítulo 8. Hardware

Tiene los siguientes apartados:

  • 8.1 Generalidades: requisitos genéricos, conexiones normalizadas y color.
  • 8.2 Productos de hardware con salida de voz: incremento del volumen de voz, gama de volumen de voz, control fino de volumen, acoplamiento magnético, dispositivos de telefonía fija y de comunicación inalámbrica.
  • 8.3 Acceso físico a las TIC: generalidades, superficie libre, cambio de nivel, aproximación frontal y paralela, anchura libre para pies y rodillas, alcance para la TIC frontal (superior no obstaculizado, inferior no obstaculizado y obstaculizado) y lateral (superior no obstaculizado, inferior no obstaculizado y obstaculizado), visibilidad e instrucciones de instalación. En la versión de 2019 se ha sufrido muchas modificaciones.
  • 8.4 Elementos accionables de forma mecánica: teclas numéricas; accionamiento (modo, fuerza) de elementos mecánicos; llaves, billetes y abonos.
  • 8.5 Indicación táctil del modo de voz

Capítulo 9. Web

Se indica que los requisitos de este capítulo se aplican a las páginas web, entendiendo como tales:

Web page: non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent

Incluyendo:

  • documentos que son páginas web;
  • documentos embebidos en páginas web y que se utilicen en la renderización, o que estén destinados a ser renderizados junto con la página web en la que están embebidos;
  • software que es una página web;
  • software embebido en páginas web y que se utilice en la renderización, o que esté destinado a ser renderizado junto con la página web en la que está embebido.

Los requisitos para otros documentos o software (como una app nativa) están en los capítulos 10 y 11 respectivamente.

En una nota se indica que, al evaluar sitios web, estos se evalúan como páginas web individuales. Las aplicaciones web, aplicaciones web para móviles, etc. están cubiertas bajo la definición de página web, que es bastante amplia y cubre todos los tipos de contenido web.

Los criterios que incluye son todos los criterios de conformidad A y AA (50 en total) de las WCAG 2.1, haciendo referencia directamente a los mismos.

Por ejemplo, el 9.1 es Perceptible, siendo el 9.1.1 Text alternative, y el 9.1.1.1 el criterio "Non-text content":

9.1.1.1 Non-text content: where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.1.1 Non-text content [enlace al mismo].

Por tanto, quitando el "9" de delante, tenemos la equivalencia exacta con el criterio de las WCAG 2.1 (9.1.1.1 de la UNE 301 549 = 1.1.1 WCAG 2.1)

En el capítulo "9.6 Requisitos de conformidad" incluye los 5 requisitos de conformidad de las WCAG 2.1: Nivel de conformidad; Páginas completas; Procesos completos; Uso de tecnologías exclusivamente según métodos que sean compatibles con la accesibilidad; Sin interferencia.

Solo las páginas web que cumplan con todos los requisitos para el contenido web (9.1-9.4) y los requisitos de conformidad de la cláusula 9.5 se ajustarán a WCAG 2.1 Nivel AA.

Además, se señala que, si una página no tiene una característica específica, la página satisface ese criterio de conformidad. Por ejemplo, si una página no tiene audio pregrabado cumplirá con el criterio 1.2.2

Por último, se alienta a cumplir con criterios del nivel AAA que se incluyen en el apartado 9.5 (en la versión de 2018 estaban en el Anexo D).

Capítulo 10. Documentos no-web

Los requisitos de este capítulo se aplican a los documentos que:

  • no sean páginas web;
  • no estén embebidos en páginas web;
  • estén embebidos en páginas web y no se utilicen en la renderización y no estén destinados a ser renderizados junto con la página web en la que están embebidos.

Algunos ejemplos de documentos son cartas, hojas de cálculo, correos electrónicos, libros, imágenes, presentaciones y películas que tienen un agente de usuario asociado (cuyos requisitos están en el capítulo 11), como un lector de documentos, un editor o un reproductor multimedia.

En la versión de 2019 se añaden la nota de que estos requisitos aplican también a los documentos a disposición de los usuarios que tengan firma digital, estén encriptados, estén protegidos por contraseña o tengan marcas de agua.

Un documento puede estar compuesto de varios archivos, como: el contenido del vídeo, el texto de los subtítulos, etc. Este hecho no suele ser evidente para el usuario final que consume el documento o el contenido.

Se listan todos los criterios de conformidad de nivel A y AA de las WCAG 2.1 salvo aquellos que no aplican. Los apartados en los que deberían incluirse los criterios que no aplican (10.1.4.6, 10.1.4.7, etc.) están, pero vacíos. De esta manera se mantiene la coherencia de la numeración con las WCAG 2.1 y entre los diferentes capítulos. Así, el requisito 9.1.4.5 (páginas web) es equivalente al 10.1.4.5 (documentos) y al 1.4.5 de las WCAG 2.1, independientemente de que se eliminen criterios en sus respectivos listados.

Los criterios excluidos que no aplican a los documentos son:

  • 10.1.4.6 Contraste mejorado (AAA)
  • 10.1.4.7 Sonido de fondo bajo o ausente (AAA)
  • 10.1.4.8 Presentación visual (AAA)
  • 10.1.4.9 Imágenes de texto (sin excepciones) (AAA)
  • 10.2.1.3 Teclado (sin excepciones) (AAA)
  • 10.2.4.1 Evitar bloques (A)
  • 10.2.4.5 Múltiples vías (AA)
  • 10.3.2.3 Navegación coherente (AA)
  • 10.3.2.4 Identificación coherente (AA)

Algunos de estos criterios son de nivel AAA. Se han incluido para mantener la coherencia de la numeración de los criterios WCAG 2.1 que se han añadido a la numeración tras los criterios de nivel AAA (saber más en WCAG 2.1, recomendación hasta las WCAG 3.0 )

Se añaden dos criterios extra:

  • 10.5 Colocación de los subtítulos. Cuando el documento no web contiene medios sincronizados con subtítulos, estos no deben ocultar información relevante en el medio sincronizado.
  • 10.6 Sincronización de la audiodescripción. Cuando el documento no web contiene medios sincronizados con audiodescripción, esta no debe interferir con la información de audio relevante en el medio sincronizado.

Capítulo 11. Software

Establece los requisitos del software, lo cual incluye:

  • platform software, se entiende por "plataforma" el software que proporciona servicios a otro software, por ejemplo, los sistemas operativos, navegadores web o máquinas virtuales.
  • software que proporciona una interfaz de usuario (como los agentes de usuario)
  • herramientas de autor
  • software que opera como producto de apoyo
  • aplicaciones móviles

Al igual que en los capítulos precedentes, la numeración es equivalente a la de los criterios de las WCAG 2.1, es decir, el criterio 11.1.1.1 es el equivalente al 1.1.1 de las WCAG 2.1.

Al igual que en el capítulo 10, los criterios que en este caso no aplican al software se dejan vacíos para mantener la coherencia de la enumeración.

Los criterios que no aplican al software son:

  • 11.1.4.6 Contraste mejorado (AAA)
  • 11.1.4.7 Sonido de fondo bajo o ausente (AAA)
  • 11.1.4.8 Presentación visual (AAA)
  • 11.1.4.9 Imágenes de texto (sin excepciones) (AAA)
  • 11.2.1.3 Teclado (sin excepciones) (AAA)
  • 11.2.4.1 Evitar bloques (A)
  • 11.2.4.2 Titulado de páginas (A)
  • 11.2.4.5 Múltiples vías (AA)
  • 11.3.1.2 Idioma de las partes (A)
  • 11.3.2.3 Navegación coherente (AA)
  • 11.3.2.4 Identificación coherente (AA)

Algunos de estos criterios son de nivel AAA. Se han incluido para mantener la coherencia de la numeración de los criterios WCAG 2.1 que se han añadido a la numeración tras los criterios de nivel AAA (saber más en WCAG 2.1, recomendación hasta las WCAG 3.0 )

El capítulo 11 tiene otros subcapítulos adicionales.

11.5 Interoperabilidad con los productos de apoyo

Cuando el software es una plataforma:

  • 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)
  • 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, 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, utilizará los servicios documentados de accesibilidad de la plataforma. También puede utilizar otros servicios documentados de accesibilidad.

Los requisitos son los siguientes y solo se aplican si el software no proporciona funcionalidades cerradas, de lo contrario se aplicaría el capítulo 5.1:

  • 11.5.2.5 Información del objeto
  • 11.5.2.6 Fila, columna y cabeceras
  • 11.5.2.7 Valores
  • 11.5.2.8 Relaciones de etiquetado
  • 11.5.2.9 Relaciones padre-hijo
  • 11.5.2.10 Texto
  • 11.5.2.11 Lista de acciones disponibles
  • 11.5.2.12 Ejecución de acciones disponibles
  • 11.5.2.13 Seguimiento del foco y de los atributos de selección
  • 11.5.2.14 Modificación del foco y de los atributos de selección
  • 11.5.2.15 Notificación de cambios
  • 11.5.2.16 Modificaciones de los estados y propiedades
  • 11.5.2.17 Modificación de valores y texto

11.6 Uso de las características de accesibilidad documentadas

Cuando el software es una plataforma, el usuario debe tener control sobre las características de accesibilidad documentadas destinadas a los usuarios.

Cuando el software tiene una interfaz de usuario, este no debe interferir o alterar las características de accesibilidad documentadas de la plataforma, excepto cuando el usuario lo solicite durante el uso del software.

11.7 Preferencias de usuario

Se aplica cuando el software proporciona una interfaz de usuario. Las preferencias de usuario en la configuración de la plataforma abarcan el color, el contraste, el tipo de fuente, el tamaño de fuente y el cursor del foco. Se exceptúa el software que se diseña para aislarse de la plataforma subyacente y que por tanto no tiene acceso a la configuración de las preferencias de usuario en la plataforma.

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.

11.8 Herramientas de autor

Los requisitos para las herramientas de autor son:

  • Las herramientas de autor deben permitir crear contenido que se ajuste a los requisitos de accesibilidad del capítulo 9, si genera páginas web, y del capítulo 10, si genera documentos. Para ello se puede apoyar en herramientas adicionales, por ejemplo, una herramienta de edición de vídeo para la creación de los archivos de subtítulos puede proporcionarse por una herramienta diferente.
  • Si la herramienta proporciona transformaciones de reestructuración (por ejemplo, dividir un documento en páginas o linealizar tabla) o recodificación, la información de accesibilidad se debe preservar si existen mecanismos equivalentes en la tecnología de salida.
  • Si la herramienta de validación de la accesibilidad puede detectar que el contenido no cumple con algún requisito del capítulo 9 (web) o del capítulo 10 (documentos), la herramienta debe proporcionar sugerencias de corrección de los problemas de accesibilidad. Esto no impide que además se puedan hacer reparaciones automáticas o semiautomáticas de los problemas que se puedan corregir.
  • Si la herramienta proporciona plantillas, al menos tiene que haber una plantilla que cumpla los requisitos del capítulo 9 (si es una plantilla de página web) o del capítulo 10 (si es una plantilla de un documento) y debe identificarse como tal.

Capítulo 12. Documentación y servicios de atención al cliente

Se aborda la documentación de apoyo y los servicios de apoyo (help desks, call centres, technical support, relay services, training services, etc.).

  • Deben proporcionar información sobre las características de accesibilidad y compatibilidad;
  • Para que la comunicación sea efectiva debe acomodarse a las necesidades de las personas con discapacidad;
  • La documentación debe ser accesible. Se puede proporcionar en formato web (que cumpla con los requisitos del capítulo 9) o en formato no web (que cumpla con los requisitos del capítulo 10). Esto no excluye que se pueda proporcionar también en otros formatos electrónicos o impresos no accesibles, o en formatos que satisfagan las necesidades de algún tipo específico de usuarios (por ejemplo, en braille o en fácil lectura). Se facilitará a través de una interfaz de usuario accesible.

Capítulo 13. Servicios de intermediación y emergencia

Trata los servicios de intermediación de texto, de signos, de lectura de labios, de voz a voz; y los servicios de telefonía con subtítulos. También se aborda propiamente el acceso a los servicios de intermediación y emergencia.

Anexo A. Relación entre el presente documento y los requisitos esenciales de la Directiva 2016/2102

Una de las novedades de la versión de la norma 2018 es la inclusión del ANEXO A para ayudar a cumplir con la Directiva (UE) 2016/2102, que obliga a que las páginas web y apps móviles del sector público sean accesibles según la norma EN 301 549.

El anexo "Annex A (informative): Relationship between the present document and the essential requirements of Directive 2016/2102" tiene dos tablas:

  • Tabla A.1: recoge los requisitos que deben cumplir las páginas web para acatar la directiva. Son requisitos de los capítulos: 9 (equivalente a las WCAG 2.1), 11.7 "Preferencias del usuario" y 12 "Documentación y servicios de atención al cliente", y otros capítulos condicionalmente ("5. Requisitos generales"; "6. Requisitos cuando hay comunicación direccional de voz", "7. Requisitos cuando hay capacidad de vídeo" y "11.8 Requisitos si es una herramienta de autor"). Artículos relacionado Requisitos de accesibilidad de la EN 301 549 aplicables a las páginas web
  • Tabla A.2: recoge los requisitos que deben cumplir las apps móviles para acatar la directiva. Son requisitos de los capítulos: 11 "Software" (WCAG 2.1 con excepciones y criterios adicionales) y 12 "Documentación y servicios de atención al cliente", y otros capítulos condicionalmente ("5. Requisitos generales"; "6. Requisitos cuando hay comunicación direccional de voz", "7. Requisitos cuando hay capacidad de vídeo" y "11.8 Requisitos si es una herramienta de autor") Artículos relacionado Requisitos de accesibilidad de la EN 301 549 aplicables a las apps móviles nativas, obligatorios por ley a partir de 2021

Anexo B. Relación entre los requisitos y las declaraciones de desempeño funcional

Este anexo me parece muy interesante porque incluye una tabla con todos los requisitos de accesibilidad de la norma expresados en términos de rendimiento funcional (distinguiendo relaciones primarias y secundarias): uso sin visión, uso con visión limitada, uso sin percepción del color, uso sin audición, uso con audición limitada, minimiza los factores desencadenantes de convulsiones fotosensibles, etc.

En la versión de 2019 se ha añadido un apartado B.2 donde se explica cómo usar la tabla.

Anexo C. Determinación de la conformidad

Este anexo normativo establece los medios necesarios para determinar el cumplimiento de los requisitos individuales establecidos a lo largo del presente documento.

Se especifica que:

El cumplimiento debe ser reportado en una forma que:

  • deje claro si se cumple con todos los requisitos aplicables o si solo se cumple alguno de los requisitos;
  • notifique las técnicas de muestreo y evaluación utilizadas para evaluar las TIC;
  • notifique si existe una funcionalidad accesible equivalente en donde se detectó incumplimiento; y
  • notifique si se utilizaron medios equivalentes para alcanzar el resultado previsto, en los casos en que se detectó incumplimiento técnico.

NOTA 1: En algunas circunstancias, por ejemplo, cuando las TIC están diseñadas para ser utilizadas por un individuo específico, o en un escenario de uso bien definido, las necesidades de accesibilidad del usuario pueden ser satisfechas por un subconjunto de los requisitos.

[...]

NOTA 4: A menudo es necesario el uso de muestras para testear, cuando el producto es complejo y hay demasiados casos a probar. El presente documento no puede recomendar técnicas específicas de muestreo de la evaluación de las TIC, ya que son específicas del contexto.

El anexo tiene tanto apartados como el documento. El C5 repasa la determinación de conformidad de los requisitos del capítulo 5; el C6 los del capítulo 6, etc.

Cada determinación de conformidad tiene los campos:

  • tipo de evaluación,
  • precondiciones,
  • procedimiento,
  • resultados.

Por ejemplo, en el caso del capítulo 9, sobre los requisitos web, un ejemplo de determinación de conformidad es:

C.9.1.1.1 Non-text content: (referencia al 9.1.1.1 = 1.1.1 de las WCAG 2.1)

  • Type of assessment: Inspection
  • Pre-conditions: 1. The ICT is a web page.
  • Procedure: 1. Check that the web page does not fail WCAG 2.1 Success Criterion 1.1.1 Non-text content [enlace al mismo].
  • Result
    • Pass: Check 1 is true
    • Fail: Check 1 is false

Anexo D. Recursos adicionales sobre accesibilidad cognitiva

En la versión de 2008 incluía el listado de criterios AAA (ahora en el capítulo 9).

En la versión de 2019 se indica que el WAI está actualmente trabajando en mejorar los requisitos para las personas con discapacidad cognitiva, del lenguaje o del aprendizaje

Anexo E. Guía de usuarios para el presente documento

Este Anexo se añade en la versión de 2019. Es una guía del documento donde se explica cómo utilizarlo. De hecho, si no estás familiarizado con él, es recomendable leerlo en primer lugar

Anexo F. Histórico de cambios

Este Anexo se añade en la versión de 2021. Es un cuadro resumen del histórico de cambios del documento a lo largo de sus sucesivas versiones.

Aplicabilidad, herramientas y recursos

Para tener un esquema de todos los requisitos y su relación con las WCAG 2.1, os comparto la Excel:

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

Para saber cómo aplicar la norma en página web, y por tanto cómo cumplir con la legislación que la referencia, podéis consultar mi artículo: Requisitos de accesibilidad de la EN 301 549 aplicables a las páginas web, 2018

Para saber cómo se aplica a las apps nativas: Requisitos de accesibilidad de la EN 301 549 aplicables a las apps móviles nativas, obligatorios por ley a partir de 2021

Herramientas y recursos de interés:

Recursos de interés anteriores a la actualización de EN 301 549 (2018):

En ellos habrá que tener en cuenta el cambio de numeración de los requisitos en la versión de 2018, y los requisitos extras de las WCAG 2.1 que se han incluido.

Artículos relacionados:

* Como todos los artículos de este blog, este es un artículo NO promocionado.

Autor: Olga Carreras Montoto

Etiquetas: , , , ,

Compártelo en:

Histórico de artículos:

< < Página de inicio

Subir al comienzo de la página



11 comentarios :
isabel rc dijo...

¿Me podría informar alguien sobre la norma que recoge especificaciones técnicas o requisitos para introducir vídeo en Lengua de Signos que haga accesibles programas de TV o cualquier otro tipo de vídeo? Muchas gracias

Fecha: 5 de mayo de 2017, 21:01


Eliminar comentario de ' isabel rc ' con fecha de 5 de mayo de 2017, 21:01
Olga Carreras dijo...

Norma UNE 139804:2007 Requisitos para el uso de la Lengua de Signos Española en redes informáticas http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo=N&codigo=N0040404

Fecha: 5 de mayo de 2017, 21:39


Eliminar comentario de ' Olga Carreras ' con fecha de 5 de mayo de 2017, 21:39
interas dijo...

Enhorabuena y muchas gracias por toda la serie de artículos que estas publicando sobre esta norma (a algunos nos ayudan mucho en nuestro día a día).
Me gustaría hacer una pregunta sobre su aplicación: Esta directiva aplica a las app de organismos públicos pero, ¿aplica también a app´s de empresas públicas que sólo vayan a ser utilizadas por sus empleados?, es decir, app´s que al fin y al cabo sólo van a gestionar "contenidos de intranet."

Muchas gracias :)

Fecha: 20 de febrero de 2018, 9:06


Eliminar comentario de ' interas ' con fecha de 20 de febrero de 2018, 9:06
Olga Carreras dijo...

Como indiqué en https://olgacarreras.blogspot.com.es/2016/12/directiva-europea-sobre-la.HTML, la Directiva dice que quedan excluidas las extranets e intranets, o sea, sitios web accesibles únicamente para un grupo restringido de personas y no para el público en general como tal, publicados antes del 23 de septiembre de 2019, hasta que dichos sitios web sean objeto de una revisión sustancial.


La directiva establece los mínimos, pero anima a ampliar el alcance. En este sentido, alienta a que en la transposición se amplíe la obligación para las extranets e intranets:


(34) Los Estados miembros deben poder ampliar la aplicación de la presente Directiva a otros tipos de sitios web y de aplicaciones para dispositivos móviles, en particular a la intranet y la extranet de los sitios web y aplicaciones para dispositivos móviles no incluidos en el ámbito de aplicación de la presente Directiva que estén diseñados para un número limitado de personas y utilizados en el puesto de trabajo o en la enseñanza, y deben poder mantener o introducir medidas conformes al Derecho de la Unión, que vayan más allá de los requisitos mínimos de accesibilidad de los sitios web y las aplicaciones para dispositivos móviles. […]

Así que hay que esperar a ver como queda traspuesta la Directiva este año a la legislación española.

Fecha: 20 de febrero de 2018, 9:58


Eliminar comentario de ' Olga Carreras ' con fecha de 20 de febrero de 2018, 9:58
interas dijo...

Muchas gracias por contestar tan rápido, claro mi duda era que como App debiera ser accesible pero como contenido de intranet no necesariamente, la pena es que nos hagamos estas preguntas en lugar de hacer las aplicaciones directamente accesibles, sin esperar a la futura ley.

Un saludo :)

Fecha: 20 de febrero de 2018, 11:02


Eliminar comentario de ' interas ' con fecha de 20 de febrero de 2018, 11:02
webposible dijo...

Enlace a UNE-EN 301549:2019 en AENOR (se puede comprar la versión impresa o de pago) https://www.une.org/encuentra-tu-norma/busca-tu-norma/norma?c=N0061677

Enlace al pdf en administracionelectronica.gob.es (descarga gratuita): http://administracionelectronica.gob.es/PAe/accesibilidad/une-en-301549-2019.pdf

Por lo demás, y como siempre, inmenso el trabajo que hay tras el blog. Felicidades.

Fecha: 16 de mayo de 2019, 17:56


Eliminar comentario de ' webposible ' con fecha de 16 de mayo de 2019, 17:56
Juan Sevillano dijo...

Hola Olga,

Lo primero, gracias por la información, muy aclaratoria de verdad.

Lo segundo, me gustaría saber si esta nueva norma es aplicable a cualquier aplicación Windows (Ojo, no al sistema operativo, sino a una aplicación que corra bajo Windows).

Entiendo que el apartado que debería de aplicar sería el 11 y no el resto. Estoy hablando de una aplicación orientada a un perfil específico de funcionario, no de público en general tal y como dice el Real Decreto.

Si pudieras aportarme un poco de luz sobre el tema, te lo agradecería.
Muchas gracias por tu tiempo.

Fecha: 29 de noviembre de 2019, 10:46


Eliminar comentario de ' Juan Sevillano ' con fecha de 29 de noviembre de 2019, 10:46
Alfonso dijo...

¡ bestial ¡
Muchísimas gracias por compartir tu visión sobre la norma, su actualización y por tanta información tan completa y didacticamente expuesta.
Eres muy generosa.

Fecha: 27 de abril de 2020, 20:40


Eliminar comentario de ' Alfonso ' con fecha de 27 de abril de 2020, 20:40
Olga Carreras dijo...

Hola,

para una aplicación que corra bajo Windows, aplicaría el capítulo 11, pero también el de requisitos generales (capítulo 5), y puede que otros, por ejemplo, si tuviera Comunicación bidireccional por voz aplicaría el capítulo 6.

No hay que confundir la norma con el Real Decreto 1112/2018, que no obliga a que sean accesibles las aplicaciones de escritorio.

Saludos,

Fecha: 8 de mayo de 2020, 16:23


Eliminar comentario de ' Olga Carreras ' con fecha de 8 de mayo de 2020, 16:23
Frank dijo...

De las pocas web en Español que hable con claridad sobre un tema tan amplio y complejo a veces de aplicar en el desarrollo web. ¿Entiendo entonces que la norma EN 301 549 V2.1.2 es equivalente a la WCAG 2.1 AA o la norma UNE añade algo mas que la WCAG 2.1 ?

Un saludo y gracias

Fecha: 26 de octubre de 2020, 10:44


Eliminar comentario de ' Frank ' con fecha de 26 de octubre de 2020, 10:44
Olga Carreras dijo...

Hola, básicamente y en la práctica, en lo que se refiere a páginas web, se podría decir que son equivalentes.

Pero realmente también aplican los requisitos generales (capítulo 5), los relacionados con la comunicación bidireccional y las capacidades de vídeo (capítulo 6 y 7) , las preferencias del usuario (11.7), sobre la documentación y servicio de soporte (capítulo 12) y el 11.8 si es una herramienta de autor.

Te recomiendo que consultes la equivalencia en la excel: https://www.usableyaccesible.com/archivos/relacion_equivalencia_301549_v3_2_1_WCAG21_v2022.xlsx

Y el artículo "Requisitos de accesibilidad de la EN 301 549 aplicables a las páginas web": https://olgacarreras.blogspot.com/2018/09/requisitos-de-accesibilidad-de-la-en.html

Saludos,

Fecha: 15 de junio de 2022, 12:08


Eliminar comentario de ' Olga Carreras ' con fecha de 15 de junio de 2022, 12:08

Publicar un comentario