miércoles, 29 de agosto de 2018

EN 301 549: norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC)

Última actualización: 29/08/2018.

En esta nueva versión del artículo recojo todas las novedades de la actualización de la norma EN 301 549 v2.1.2 (2018-08) publicada el 28 de agosto de 2018.

La nueva versión de la norma tiene dos objetivos principalmente:

Índice

Historia de la norma EN 301 549

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 siempre la legislación europea 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, de manera que la nueva ley española de accesibilidad hace también referencia a la EN 301 549. Por ello es necesario conocer cuáles son los requisitos de accesibilidad que recoge.

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 son:

  • 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.

Descarga de 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. 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, pero para no confundir se listan en el ANEXO D.

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.3), el uso de las características de accesibilidad documentadas (11.4) y las preferencias de usuario (11.5).

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 nuevo 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) 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. Software)
  • 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 y 7. Requisitos cuando hay capacidad de vídeo)

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

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. Se definen los requisitos cuando haya funcionalidades cerradas a los lectores de pantalla; a la ampliación del texto; al teclado o a una interfaz de teclado; o que necesiten información sonora. Se deberá proporcionar al menos un modo de funcionamiento que utilice el acceso no visual a esas funciones (audio, táctil); y si se necesita información auditiva pregrabada para el uso de las funciones se proporcionará información visual equivalente (como subtítulos o transcripciones).

    Se define también la siguiente fórmula:

    Where any functionality of ICT is closed to the text enlargement features of platform or assistive technology, the ICT shall provide a mode of operation where the text and images of text necessary for all functionality is displayed in such a way that a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the supplier.

    The subtended angle, in degrees, may be calculated from:

    Ψ = (180 x H) / (π x D)

    Where:

    • ψ is the subtended angle in degrees
    • H is the height of the text
    • D is the viewing distance
    • D and H are expressed in the same units

    NOTE: The intent is to provide a mode of operation where text is large enough to be used by most users with low vision.

  • 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 caracter 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, bien sea en una web, en una app....

Los apartados son:

  • 6.1 Ancho de banda para voz
  • 6.2 Funcionalidad de texto en tiempo real
  • 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 están agrupados en:

  • Reproducción del subtitulado y la audiodescripción (7.1.1 y 7.2.1)
  • Sincronización del subtitulado y la audiodescripción(7.1.2 y 7.2.2 )
  • Preservación del subtitulado y la audiodescripción (7.1.3 y 7.2.3 )
  • Controles de usuario para los subtítulos y la audiodescripción (7.3)

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.
  • 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.5 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 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.

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)
  • 10.4.1.3 Mensajes de estado (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

Estos son los requisitos que aplicarían a las apps móviles nativas .

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:

  • 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)
  • 11.2.4.2 Titulado de páginas (A)
  • 10.2.4.5 Múltiples vías (AA)
  • 11.3.1.2 Idioma de las partes (A)
  • 10.3.2.3 Navegación coherente (AA)
  • 10.3.2.4 Identificación coherente (AA)
  • 10.4.1.3 Mensajes de estado (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.

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) 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 y 7. Requisitos cuando hay capacidad de vídeo)
  • 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 y 7. Requisitos cuando hay capacidad de vídeo)

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.

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

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:

Esquema de los requisitos de la EN 301 549 aplicables a sitios web, documentos y software. Correspondencia con las WCAG 2.1 (.xlsx, 101 KB)

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 de interés:

    • Accessibility Requirements Generator. Ayuda a elaborar listas a medida de los requisitos aplicables, en función de los requisitos funcionales que se precisen, aglutinando la información más relevante de los cuatro documentos.
    • Managing accessibility in the public procurement of ICT. Proporciona orientación sobre la forma de considerar la accesibilidad en las diferentes etapas del proceso de adquisición. Proporciona muestras de texto que se puede cortar y pegar en la convocatoria de ofertas (solo en inglés).
    • Proyecto TFG (ICT-AccE). Trabajo fin de grado Herramienta EN 301 549: cliente web (PDF) de Juan Antonio Montero, tutorizada por Loïc Martínez Normand. Permite a grupos de trabajo anotar los resultados de la evaluación de accesibilidad de un producto o servicio TIC siguiendo la norma EN 301 549.

    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:

    6 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

    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

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

    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.

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

    priyanka jadhav dijo...

    Gracias.!
    Las mejores aplicaciones móviles para eventos

    Publicar un comentario