Accesibilidad

Este proyecto pretende crear la base para la construcción de interfaces de usuario para aplicaciones que van a utilizar ciudadanos y funcionarios. Ponemos un foco especial en entender que los usuarios pueden tener muchas maneras diversas de utilizar nuestras aplicaciones, conforme a la diversidad funcional de cada usuario. Por eso el diseño de este sistema de diseño está muy condicionado por sus requisitos de accesibilidad.

Requerimientos de accesibilidad

Consulta aquí una descripción detallada de lo que se debe pedir a la entrega de un proyecto: https://paega2.atlassian.net/wiki/spaces/AreaUsuariosIntegradores/pages/3429302559

 

El Real Decreto 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público (PDF, 332 KB) rige actualmente los requerimientos de accesibilidad que deben cumplir los portales web (incluidas intranets y extranets) y aplicaciones móviles 1 de la Administración Pública.

También deben ser accesibles los documentos (PDF, hojas de cálculo, documentos de texto, etc.) y contenidos multimedia (vídeos, audios) que pudieran contener, así como los procesos de identificación, autenticación, firma y pago, con independencia de la plataforma tecnológica que se use para su puesta a disposición del público.

El Real Decreto 1112/2018 indica que los portales y apps de la Administración Pública deben cumplir con el nivel AA de la norma EN 301 549 que, en lo que a requisitos de accesibilidad de los portales web se refiere, es equivalente al estándar internacional Web Content Accessibility Guidelines (WCAG) 2.1

Las WCAG 2.1 están compuestas por 78 criterios de conformidad, que se dividen en tres niveles:

  • Nivel A: es el nivel más básico e implica el cumplimiento de 30 criterios de conformidad.

  • Nivel AA: es el nivel exigido por la legislación española y europea, e implica el cumplimiento de los 30 criterios de conformidad de nivel A, más los 20 criterios de conformidad de nivel AA, en total 50 criterios de conformidad.

  • Nivel AAA: es el nivel más completo, pues implica cumplir con los 78 criterios de conformidad.

Aunque el nivel exigido por ley es el nivel AA, se anima a cumplir, en la medida de lo posible, con el nivel AAA.

El Gobierno de Aragón aspira a cumplir con el nivel AAA. Por ejemplo, el portal aragon.es alcanza el nivel AAA en un determinado número de páginas relevantes (Home, Actualidad, Buscador, etc.) y utiliza una paleta de colores que cumple con el nivel AAA.

Declaración de accesibilidad

El Real Decreto 1112/2018 establece que todos los portales deben incluir un apartado llamado “Accesibilidad” con la declaración de conformidad del sitio. El enlace a este apartado se incluye en la cabecera o el pie de las páginas.

La declaración de conformidad:

El modelo establecido por la Comisión establece exactamente qué apartados y contenidos debe incluir. Se puede consultar la guía para elaborarla y diversos ejemplos en el Portal de la Administración Electrónica: “Declaraciones de accesibilidad”.

Uno de los requisitos de este apartado “Accesibilidad” es que, desde el 20 de septiembre de 2020, incluya el enlace a un trámite administrativo para que los ciudadanos puedan iniciar una reclamación relacionada con la accesibilidad del portal web.

Otro de los requisitos de la declaración de conformidad es indicar los contenidos no accesibles del portal, bien porque todavía no se han hecho accesibles; bien porque no están en el ámbito del Real Decreto 1112/2018; o bien porque suponen una carga desproporcionada.

A continuación, se enumeran los contenidos que son excepciones y no entran en el ámbito del Real Decreto 1112/2018, y se explica qué se entiende por carga desproporcionada.

Excepciones

El Real Decreto indica que los contenidos que están excluidos de cumplir con los requisitos de accesibilidad son:

  • los documentos de ofimática (PDF, hoja de cálculo, documento de texto, etc.) publicados antes de septiembre de 2018, salvo que se hayan modificado después o sean necesarios para tareas administrativas activas.

  • contenido multimedia grabado (audios, vídeos) publicados antes de septiembre de 2018.

  • archivos o herramientas de archivo que no hayan sido publicados ni editados después de septiembre de 2018 ni sean necesarios para el desarrollo de tareas administrativas activas.

  • contenido multimedia en directo.

  • servicios de mapas y cartografía en línea, siempre y cuando la información esencial se proporcione de manera accesible digitalmente.

  • contenidos de terceros que no estén financiados ni desarrollados por el organismo obligado ni estén bajo su control.

  • extranets e intranets publicadas antes del 23 de septiembre de 2019 hasta que sean objeto de una revisión sustancial.

  • reproducciones de bienes de colecciones del patrimonio que no pueden hacerse plenamente accesibles por:

    • incompatibilidad de los requisitos de accesibilidad con la conservación del bien de que se trate o con la autenticidad de la reproducción;

    • indisponibilidad de soluciones automatizadas y rentables que permitan extraer el texto de manuscritos u otros bienes de colecciones del patrimonio y transformarlos en contenidos compatibles con los requisitos de accesibilidad.

Carga desproporcionada

El RD 1112/2018 también establece que, si cumplir los requisitos de accesibilidad es una carga desproporcionada para la entidad, podrá exceptuar el cumplimiento de los requisitos de accesibilidad.

NO se considera carga desproporcionada la falta de prioridad, de tiempo o de conocimientos; y no es justificable la adquisición o desarrollo de gestores de contenido que no sean accesibles.

Se considera carga desproporcionada:

Aquella que impone a la entidad obligada una carga financiera y organizativa excesiva, o que compromete su capacidad para cumplir su cometido o para publicar la información necesaria y pertinente para sus tareas y servicios, teniendo en cuenta al mismo tiempo el posible beneficio o perjuicio para los ciudadanos, en particular para las personas con discapacidad y personas mayores.

La alegación de "carga desproporcionada" debe ser excepcional, y se limitará al contenido concreto y a lo estrictamente necesario para reducir la carga. No debe impedir hacer estos contenidos lo más accesibles posible, ni exime de cumplir todos los requisitos en el resto de contenidos.

Si la entidad se acoge a la excepción, deberá realizar un informe que lo justifique y revisar anualmente los posibles cambios organizacionales o técnicos que ya no den lugar a la excepción.

Criterios de conformidad

A continuación, se enumeran los 78 criterios de conformidad de las WCAG 2.1 / EN 301 549 organizados por niveles (A, AA, AAA).

Cada uno de los criterios tiene un enlace a la documentación de la normativa donde se explica el criterio y las diferentes técnicas que pueden aplicarse para su cumplimiento. La normativa todavía no está traducida al castellano.

Se indica con un * los criterios nuevos de la última versión de las WCAG (las WCAG 2.1) publicadas en 2018.

Nivel A

1.1.1 Contenido no textual: https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.htmlhttps://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html

1.2.1 Sonido solo o vídeo solo (grabado) :

1.2.2 Subtítulos (grabados):

1.2.3 Audiodescripción o medio alternativo (grabado) :

1.3.1 Información y relaciones:

1.3.2 Secuencia significativa:

1.3.3 Características sensoriales:

1.4.1 Uso de color:

1.4.2 Control del sonido:

2.1.1 Teclado:

2.1.2 Sin trampas para el foco del teclado:

2.1.4* Atajos de teclado:

2.2.1 Tiempo ajustable: https://www.w3.org/WAI/WCAG21/Understanding/timing-adjustable

2.2.2 Poner en pausa, detener, ocultar:

2.3.1 Umbral de tres destellos o menos:

2.4.1 Evitar bloques:

2.4.2 Titulado de páginas:

2.4.3 Orden del foco:

2.4.4 Propósito de los enlaces (en contexto):

2.5.1* Gestos del puntero:

2.5.2* Cancelación del puntero:

2.5.3* Etiqueta en el nombre:

2.5.4* Actuación por movimiento:

3.1.1 Idioma de la página:

3.2.1 Al recibir el foco:

3.2.2 Al recibir entradas:

3.3.1 Identificación de errores:

3.3.2 Etiquetas o instrucciones:

4.1.1 Procesamiento:

4.1.2 Nombre, función, valor:

Nivel AA

1.2.4 Subtítulos (en directo):

1.2.5 Audiodescripción (grabado):

1.3.4* Orientación de la pantalla:

1.3.5* Identificación del propósito del campo:

1.4.3 Contraste (mínimo): https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum

1.4.4 Cambio de tamaño del texto:

1.4.5 Imágenes de texto:

1.4.10* Reajuste de elementos:

1.4.11* Contraste no textual:

1.4.12* Espaciado del texto:

1.4.13* Contenido en hover o focus:

2.4.5 Múltiples vías:

2.4.6 Encabezados y etiquetas:

2.4.7 Foco visible:

3.1.2 Idioma de las partes:

3.2.3 Navegación coherente:

3.2.4 Identificación consistente:

3.3.3 Sugerencias ante errores:

3.3.4 Prevención de errores (legales, financieros, datos):

4.1.3* Mensajes de estado:

Nivel AAA

1.2.6 Lengua de signos (grabado):

1.2.7 Audiodescripción ampliada (grabada) :

1.2.8 Medio alternativo (grabado):

1.2.9 Sólo sonido (en directo):

1.3.6* Identificación del propósito:

1.4.6 Contraste (mejorado) :

1.4.7 Sonido de fondo bajo o ausente:

1.4.8 Presentación visual:

1.4.9 Imágenes de texto (sin excepciones):

2.1.3 Teclado (sin excepciones):

2.2.3 Sin tiempo: https://www.w3.org/WAI/WCAG21/Understanding/no-timing

2.2.4 Interrupciones:

2.2.5 Re-autentificación:

2.2.6* Límites de tiempo:

2.3.2 Tres destellos:

2.3.3* Animaciones desde interacciones:

2.4.8 Ubicación:

2.4.9 Propósito de los enlaces (sólo enlaces):

2.4.10 Encabezados de sección:

2.5.5* Tamaño del área de interacción:

2.5.6* Mecanismos de entrada concurrentes:

3.1.3 Palabras inusuales:

3.1.4 Abreviaturas:

3.1.5 Nivel de lectura:

3.1.6 Pronunciación:

3.2.5 Cambios a petición:

3.3.5 Ayuda:

3.3.6 Prevención de errores (todos):

WAI-ARIA

Actualmente, los portales incluyen numerosos elementos dinámicos como acordeones, menús desplegables, árboles, alertas, etc. que no tienen una etiqueta propia en HTML, sino que se implementan mediante código JavaScript y elementos HTML que no reflejan exactamente su función, su nombre o su valor o estado.

El estándar Accessible Rich Internet Applications (WAI-ARIA) 1.1, soportado por todos los navegadores y productos de apoyo actuales, permite que estos componentes sean correctamente anunciados por los lectores de pantalla como NVDA (gratuito), JAWS, VoiceOver (disponible por defecto en dispositivos Apple) y TalkBack (disponible por defecto en dispositivos Android).

WAI-ARIA define una ontología de roles y propiedades que permite marcar la función, el nombre y el estado de los componentes de la página mediante la inclusión de atributos en las etiquetas HTML.

Aplicar el estándar WAI-ARIA es imprescindible para que un portal con elementos dinámicos sea accesible para los usuarios que utilizan un lector de pantalla o línea braille, como las personas ciegas, sordociegas o con baja visión.



Recursos de interés:

 

1 El requerimiento de que las apps de la Administración Pública sean accesibles entra en vigor en junio de 2021.