Accesibilidad web: Cómo hacer una navegación más accesible

En esta entrada voy a comentaros varios requisitos y técnicas de accesibilidad que nos ayudarán a tener una navegación más sencilla y más accesible.

Accesibilidad web: Cómo hacer una navegación más accesible

Cómo hacer una navegación accesible

Los requisitos a tener en cuenta son los siguientes:

  • Ofrecer varias vías de navegación para localizar el contenido
  • Facilitar la ubicación al usuario para que en ningún momento se sienta perdido
  • Mantener la consistencia lo largo del sitio

 

1. Múltiples vías  de navegación

Lo primero vamos a explicar es cómo establecer diferentes vías para mejorar la navegación de forma que los usuarios lo encuentren fácil y puedan satisfacer sus necesidades.

Para ello, tendremos en cuenta el criterio 2.4.5. “Múltiples vías: Se proporciona más de un camino para localizar una página web dentro de un conjunto de páginas web, excepto cuando la página es el resultado, o un paso intermedio, de un proceso. (Nivel AA)

Hay quienes prefieren usar el buscador a recorrer un menú de navegación largo. Otros prefieren usar tablas de contenidos o un mapa del sitios para navegar por el sitio

Por eso, las WCAG 2.0 establece que tenemos que aplicar dos o más técnicas para mejorar la navegación.

  • Mapa del sitio
  • Función de búsqueda
  • Enlaces a páginas relacionadas
  • Tabla de contenidos

 

Mapa del sitio

Es muy importante tener en cuenta la creación de un mapa web, que ayude a facilitar la comprensión del sitio web. Para ello, tenemos la técnica G63: Proporcionar un mapa del sitio y que debe cumplir una serie de requisitos:

  • Debe estar enlazado a todas las páginas, o desde cada una de las páginas que se listan en el mapa web.
  • Desde el mapa web se tiene que poder acceder a todas las páginas del sitio, directa o indirectamente. Por lo tanto, sus elementos deben ser enlaces.
  • La presentación y la estructura deben reflejar la orgnización del sitio, con elementos HTML, como son los encabezados y las listas.
  • El orden de lectura y de tabulación debe ser el correcto.
  • Se debe actualizar cada vez que se actualiza el sitio.

Función de búsqueda

Otra técnica a tener en cuenta es proporcionar una función de búsqueda en el sittio web, patra que los usuarios puedan acceder a buscar el contenido sin necesidad de entender el sitio o navegar por él. Es muy útil en sitios de gran tamaño.

La función de búsqueda se realizará mediando un campo de búsqueda que esté presente en las páginas del sitio. La técnica que habla de esto es la G161: Proporcionar una función de búsqueda para ayudar a los usuarios a encontrar contenido.

 

Enlaces a páginas relacionadas

Otra técnica que se puede emplear es enlaces a páginas relacionadas. De esta manera los usuarios ppueden encontrar información adicional. Técnica G125: Proporcionar enlaces para navegar a páginas relacionadas.

 

Tabla de contenidos

Otra técnica es utilizar una tabla de contenidos, que consiste en un índice con las secciones y subsecciones de una página, y que proporciona un acceso directo a una sección específica. Para más información sobre ello, se puede consultar la técnica G64: Proporcionar una tabla de contenidos.

Otras técnicas para sitios pequeños

Si el sitio es pequeño se pueden aplicar otras técnicas:

  • el menú de navegación incluye el acceso a todas las páginas del sitio.
  • todas las páginas están enlazadas desde la página de inicio.

Técnicas relacionadas:

 

Ubicación del usuario

Un requisito muy importante que hará que el sitio web sea más accesible es facilitarle la ubicación a los usuarios, proporcionarle inforción sobre dónde se encuentran.

Para ello, esta el criterio 2.4.8 Ubicación: se proporciona información acerca de la ubicación del usuario dentro de un conjunto de páginas web.

Hay varias técnicas para conseguir esto:

Migas de pan.

Las migas de pan van a ayudar a:

  • Comprender cómo se estructura el contenido de un sitio web.
  • Navegar por las páginas visitadas
  • Identificar la ubicación actual de una página dentro del sitio web.

¿Qué requisitos deben cumplir las migas de pan?

  • Deben estar siempre situadas en el mismo lugar en todas las páginas.
  • Maquetarlas mediante listas, aunque visualmente se presenten en línea.
  • Usar separadores visuales entre las mismas.
  • Deben ser enlaces.
  • Deben indicar el camino usado para llegar a la página actual o bien indicar su situación en la jerarquía u organización del sitio.

 

Indicar la situación actual en la navegación

Otra técnica para facilitar la ubicación del usuario es indicar la situación actual en menús, barras de navegación, pestañas o pasos en un proceso. Todo cambio que se produzca se debe comunicar a los usuarios.

Por eso, el menú o paso en el que nos encontramos no solo se debe indicar visualmente, sino también estructural y semánticamente o mediante texto si fuera necesario como establece el criterio 1.3.1 Información y relaciones. Se puede obtener más información sobre este requisito en la técnica G128: Indica la ubicación actual dentro de las barras de navegación.

 

Elemento <link>

Otra técnica es incluir navegación semántica a través del elemento link

<head><title>Capítulo 2</title>
<link rel="index" href="index.html“ title="Índice" />

<link rel="start" href=“intro.html“ title="Introducción" />

<link rel="next" href=“cap3.html“ title="Capítulo 3" />

En este ejemplo estamos indicando, dentro de una colección de páginas: el índice, la primera página de la colección y la siguiente.

La ventaja de usar <link> para establecer las relaciones es que este elemento se puede interpretar mediante software. Se puede ampliar información en la técnica H59: Uso del elemento de enlace y las herramientas de navegación.

 

Consistencia

Otro aspecto que hace más accesible la navegación es la consistencia, tanto en la presentación y maquetación de los mecanismos de navegación, como en la identificación de los componentes que tienen la misma funcionalidad dentro de un conjunto de páginas

  • 3.2.3 – Navegación coherente
  • 3.2.4 – Identificación coherente

Navegación coherente

Si los mecanismos de navegación que se repiten en diferentes páginas de un conjunto (como el buscador, el menú de navegación, las migas de pan, etc), se presentan en el mismo orden en las diferentes páginas del conjunto, los usuarios pueden predecir dónde estarán en cada página y localizarlos con más facilidad. Para más información se puede consultar la técnica G61.

Identificación coherente

Tan importante es la navegación coherente, como la identificación coherente, porque si en un sitio web se usan diferentes etiquetas para una misma función se dificulta considerablemente la comprensión y la interacción con el sitio, y en definitiva su uso.

Identificación coherente quiere decir, en los enlaces, que aquellos que tienen un mismo destino tienen el mismo texto de enlace.

Por ejemplo, si el destino del enlace es la página de inicio del sitio, el texto del enlace no puede ser unas veces “Ir a la home”, en otras “Ir a la página de inicio” y en otras “Ir a la página principal”.

El texto del enlace además deberá ser consistente con el título de la página, el nombre con el que se identifica a la misma en las migas de pan o en el mapa del sitio.
En el caso de destinos similares, los textos de enlace deberán ser consistentes.

Por ejemplo, en un portal de noticias, el texto del enlace para ampliar información sobre cada noticia, no puede ser en un caso “Más información”, en otro “Leer más” y en otro “Más info”.

La identificación coherente también se aplica al texto alternativo de los elementos no textuales.
Por ejemplo, si se usa el mismo icono en diferentes páginas, se entiende que con la misma función, debe tener el mismo texto alternativo, si tenemos un icono para descargar un fichero, su texto alternativo no puede ser en unos casos “descargar”, en otros “guardar” y en otros “bajar”.

Y la identificación coherente se aplica también a las etiquetas de los campos de formulario: los mismos controles de formulario deben estar etiquetados igual.

Por ejemplo, no podemos etiquetar el campo contraseña en unos casos como “password”, en otros como “contraseña” y otros como “clave”.

 

Accesibilidad web: Requisitos de Accesibilidad de los Medios Audiovisuales

El objetivo de este artículo es explicar el documento del W3C: Requisitos de usuario para la Accesibilidad de los medios audiovisuales.

Introducción

Este documento explica los diferentes tipos de contenidos alternativos que se pueden ofrecer, a quiénes benefician y los requisitos que deben cumplir; recoge asimismo los que debería cumplir el sistema, abarcando el proceso de producción o los agentes de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia).

Requisitos de usuario para la accesibilidad de los medios audiovisuales

Estructura del documento

Se divide en cuatro grandes apartados:

  • Resumen de los requisitos de accesibilidad de los medios audiovisuales por tipo de diversidad funcional.

En este apartado se proporciona una introducción a las necesidades de los usuarios con diversidad funcional, (ceguera, baja visión, daltonismo, diversidad funcional auditiva, sordoceguera, diversidad funcional motriz y diversidad funcional intelectual) en relación con el contenido audiovisual.

  • Tecnologías para proporcionar contenido alternativo.

En esta sección se explican los diferentes tipos de contenidos alternativos que se pueden proporcionar para ayudar a los usuarios con una discapacidad sensorial a acceder al contenido audiovisual. Por cada uno de ellos se incluye un listado de los requisitos que deben satisfacer en el contexto de un desarrollo HTML5 (pero no se entra en aspectos técnicos o de desarrollo concretos).

  • Requisitos del sistema

En este apartado se explica cómo las tecnologías para proporcionar contenido alternativo al vídeo y audio encajan en el panorama más amplio de la accesibilidad, tanto técnicamente, desde de un punto de vista del agente de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia) como desde un punto de vista del proceso de producción. Por ello, los requisitos listados en este apartado están en su mayoría más relacionados con las UAAG que con las WCAG.

  • Checklist “Requisitos de Usuario para la Accesibilidad de los Medios Audiovisuales”

 

Resumen de los requisitos de accesibilidad de los medios audiovisuales por tipo de diversidad funcional

En este apartado se proporciona una introducción a las necesidades de los usuarios con discapacidad para poder percibir, interactuar y comprender los contenidos audiovisuales.

Ceguera

Las personas ciegas no pueden acceder a la información visual presente en los vídeos, los controles de los reproductores o los indicadores de estado. Por ello necesitan que la información se presente de forma alternativa mediante texto o audio.

Hay que tener en cuenta que las personas ciegas utilizan un lector de pantalla y/o una línea braille, por tanto necesitan que los medios audiovisuales sean operables cuando se utilizan estos productos de apoyo.

Baja visión

Las personas con baja visión, en función de su capacidad visual, puede ser que tengan problemas específicos, como dificultad para discriminar la información de primer plano de la información de fondo, para discriminar colores, o les pueden deslumbrar los contenidos muy brillantes.

Por otra parte, quizás no puedan reaccionar rápidamente a la información que se presenta en pantalla durante un tiempo limitado. Pueden tener un ángulo de visión estrecho que no les permita detectar la información clave presentada temporalmente si no están mirando en esa dirección, o si el texto se está moviendo o desplazando.

Estas personas utilizarán probablemente un magnificador de pantalla, así que solo estarán viendo una parte de la pantalla, por ello se debe poder gestionar el contenido audiovisual a través de su producto de apoyo.

Las personas con baja visión pueden tener dificultad para leer el texto demasiado pequeño, con poco contraste, con un determinado tipo de fuente o con efectos. Por otra parte, si el texto es una imagen, se verá pixelada al ampliarse.

Pueden estar utilizando un producto de apoyo que modifique los colores, por ejemplo que los invierta, de modo que los contenidos audiovisuales deben ser visibles también en este contexto.

Por último, los usuarios con baja visión a menudo se benefician también de los textos e instrucciones que algunas veces los autores ocultan visualmente (por ejemplo colocándolos fuera de pantalla) dirigidos a los usuarios de lector de pantalla o línea braille.

Percepción del color

Las personas con problemas en la percepción del color (daltonismo) pueden tener dificultades para discriminar entre diferentes colores, o pueden perderse información clave cuando la información se proporciona solo mediante el color, por ejemplo en los controles del audio/vídeo o en las superposiciones de texto

Sordera

Las personas sordas no podrán escuchar el audio, por tanto será necesaria una alternativa, normalmente a través de subtítulos sincronizados y/o traducción en lengua de signos.

Problemas de audición

Las personas con problemas de audición podrían no ser capaces de discriminar cierto tipo de sonidos, y por tanto pueden perderse información presente en el audio si tiene frecuencias que no pueden oír, o bien a causa del ruido de fondo o la distorsión.

También pueden perderse información si el audio es demasiado bajo o de mala calidad, o si las personas hablan demasiado rápido y no se puede reproducir el audio más lento.

La información que se presenta mediante audio multicanal puede no ser percibida por las personas sordas de un oído.

Por último, las personas con un implante coclear pueden no tener problemas con el volumen del audio, pero la comprensión puede ser difícil si la experiencia multimedia es abrumadora.

Sordoceguera

Según su nivel de ceguera y sordera, las personas sordociegas podrían necesitar: subtítulos y la posibilidad de ampliarlos; cambiar a colores de alto contraste (u otra combinación de colores); subtítulos y/o descripción del vídeo expuestos por su producto de apoyo; o una transcripción que cada usuario pueda leer a su ritmo, es decir, que no esté basada en el tiempo.

Diversidad funcional motriz

Algunas personas con diversidad funcional motriz como aquellas con un control muscular limitado (temblores, falta de coordinación, parálisis), con dolor que les impida el movimiento o con la falta de alguna extremidad, no podrán utilizar el teclado o el ratón para interactuar con el contenido y los controles.

El reproductor de los contenidos audiovisuales tiene que poder ser operable solo con el teclado (sin ratón), lo cual incluye el acceso a todos los controles y métodos de selección del contenido alternativo.

Diversidad funcional cognitiva

Autismo, dislexia, discalculia, trastorno de déficit de atención, problemas de memoria, … la extensa gama de condiciones que abarca hace que los requisitos de accesibilidad también varíen ampliamente.

Algunas personas podrán procesar la información auditiva mejor que la lectura del texto, por tanto, la información que se presenta como texto embebido en el vídeo también deberá estar disponible como descripciones de audio.

Otras personas pueden necesitar reducir las distracciones o flashes en las presentaciones de vídeo.

En general, la experiencia multimedia para las personas con trastornos del espectro autista debe ser personalizable y estar bien diseñada para no resultar abrumadora.

Se debe tener cuidado en presentar la experiencia multimedia focalizada en el propósito del contenido y proporcionar alternativas al contenido de una manera clara y concisa.

Tecnologías para proporcionar contenido alternativo

En esta sección se explican los diferentes tipos de contenidos alternativos que se pueden proporcionar para ayudar a los usuarios con una discapacidad sensorial a acceder al contenido audiovisual. Por cada uno de ellos se incluye un listado de los requisitos que deben satisfacer en el contexto de un desarrollo HTML5 (pero no se entra en aspectos técnicos o de desarrollo concretos).

Audiodescripción

Una audiodescripción contiene una narración descriptiva de los elementos visuales clave para hacerlos accesibles a las personas ciegas o con una discapacidad visual. Se incluyen acciones, vestuario, gestos, cambios de escena o cualquier otra información visual relevante que alguien que no puede ver la pantalla podría perderse.

Las audiodescripciones son grabaciones de audio que se insertan en las pausas naturales del mismo.

Pueden ser de dos tipos:

  • Abiertas, se fusionan con la pista de audio y no pueden ser desactivadas por el usuario.
  • Cerradas, el usuario puede activarlas o desactivarlas.

Las audiodescripciones no solo benefician a las personas ciegas o con problemas de visión. Por ejemplo, pueden beneficiar a los estudiantes que lidian con materiales o conceptos difíciles, puesto que la audiodescripción puede dar información complementaria acerca de lo que se está viendo en pantalla (la estructura de una ecuación, la complejidad de una pintura, etc.).

Audiodescripciones en formato texto

Cuando la audiodescripción se proporciona en formato texto, en vez de en formato voz grabada, se presentan unos requisitos específicos.

Las audiodescripciones en formato texto (TVDs) se entregan al cliente como texto y son renderizadas localmente por los productos de apoyo (lector de pantalla o línea braille). Los ficheros de texto se proporcionan como archivos de texto que contienen los tiempos de comienzo de cada descripción. Las ventajas son que el usuario de lector de pantalla puede tener un control total sobre la voz, la velocidad del habla u otras opciones.

Audiodescripciones ampliadas

Las audiodescripciones se suelen introducir en las pausas naturales del diálogo o la narración. Pero en algunos casos no hay tiempo suficiente. Las audiodescripciones ampliadas (EVD) trabajan pausando el vídeo y el audio en momentos clave para reproducir la audiodescripción extensa, y una vez que termina reanudan la reproducción.

Las audiodescripciones ampliadas benefician por ejemplo a las personas con el síndrome de Asperger u otras personas con trastornos del espectro autista, ya que en ellas se puede explicar conexiones entre la causa y el efecto, se puede señalar lo que es más importante, o explicar los estados de ánimo.

Clean audio

Un desarrollo relativamente reciente en la accesibilidad en televisión es el concepto de “audio limpio”, que aprovecha el audio multicanal.

Beneficia especialmente a las personas con problemas de audición. Consiste en aislar el canal de audio que contiene los diálogos o la información relevante que así puede amplificarse (o modificarse de otro modo), mientras que los canales que tienen la música o los sonidos ambientales pueden atenuarse. Esto permite usar filtros y adaptar el audio a las necesidades del usuario, ya que la pérdida de audición es típicamente dependiente de la frecuencia.

La mayoría de los usuarios están familiarizados con el avance rápido y el rebobinado en el contenido audiovisual. Sin embargo, esta manera de explorar el contenido, basada en el tiempo, es bastante ineficaz y perjudica especialmente a las personas con discapacidad.

Afortunadamente, la mayoría de los contenidos tienen una estructura (los audiolibros tienen capítulos, las películas actos y escenas, los programas de televisión secciones, etc.). Un marcado adecuado puede exponer su estructura en los controles para avanzar y rebobinar.

Sin embargo, una navegación efectiva por la jerarquía de su estructura requeriría un control adicional que no suele estar disponible en los reproductores multimedia actuales. Este mecanismo (que llaman “granularity-level control”) permitiría al usuario ajustar el nivel de granularidad aplicado a los controles “siguiente” y “anterior”. La personalización sería necesaria porque puede ser muy engorroso acceder a todos los nodos de la jerarquía o insatisfactorio acceder solo a los del nivel superior de la jerarquía.

Se ponen varios ejemplos. Uno de ellos es el de un telediario. Las grandes secciones serían noticias, tiempo o deportes. El segundo nivel serían las noticias individuales de cada sección. Si dispusieras de este “granularity-level control” podrías ajustar el nivel de granularidad de los controles “siguiente” y “anterior” para saltar de sección en sección, o de noticia en noticia.

A continuación se habla de la navegación a través de contenidos auxiliares, como anuncios, resúmenes de noticias, notas al pie de un libro, etc. que interrumpen el “programa” primario, y que el usuario puede querer saltarlos (o tal vez ir directamente a ellos).

Subtítulos

Para las personas sordas o con problemas de audición, los subtítulos son la principal alternativa al audio.

A diferencia de los subtítulos para personas cuyo idioma no es el del contenido, el subtitulado para sordos (captioning) no solo debe transcribir el diálogo o la narración, sino también la información importante como efectos de sonido, risas, etc., y debe estar en el mismo idioma que la pista de audio principal.

Los subtítulos pueden ser cerrados, es decir, pueden ser activados o desactivados por el usuario; o abiertos, que están siempre visibles, fusionados con la pista de vídeo y no pueden desactivarse.

Aunque lo ideal es que sea una transcripción literal del audio, a veces se editan por adecuarlos, por ejemplo, a la velocidad de lectura. Si se editan debería indicarse y debería proporcionarse una versión textual completa.

No es estrictamente necesario que el texto del subtítulo coincida con el movimiento de la boca, a veces pueden adelantarse o extender un poco.

Cuando hablan varias personas, en el texto de los subtítulos se debe distinguir a los oradores, por ejemplo indicando el nombre de la persona (“Ana:”) antes del texto que representa lo que dice en el audio.

Los subtítulos también son muy útiles para que los clientes de bares, gimnasios, etc. sigan el programa en la televisión (yo añadiría que también para las personas que por el contexto no pueden activar o escuchar el audio y/o no tienen auriculares) o para las personas que no dominan el idioma. Por otra parte, los subtítulos tienen capacidad de búsqueda, lo que permite localizar un vídeo o un punto exacto del mismo.

Subtítulos enriquecidos

Pueden tenerse varias pistas de subtítulos, por ejemplo uno adecuado para cada rango de edad.

Los subtítulos también pueden enriquecerse con más información, por ejemplo con un glosario (podría ser un enlace que pausa el contenido principal y permite acceso al material explicativo). Proporcionar información relevante adicional permite mejorar la comprensión de los elementos esenciales tanto para los usuarios de productos de apoyo como para las personas con dificultad en la lectura.

Interpretación en lengua de signos

La lengua de signos no es universal, por tanto debe adecuarse a la audiencia. Es importante que la cara, los brazos, manos y gestos corporales se vean claramente, con suficiente resolución para que sean legibles. Por otra parte es preferible una persona que un avatar animado, al menos por el momento.

Igual que los subtítulos, pueden ser abiertos (siempre visibles) o cerrados (se puede activar/desactivar su visualización).

No todos los dispositivos podrán manejar múltiples flujos de vídeo, así que este debería ser un requisito del navegador. En las situaciones en las que no se soporte, por ejemplo en dispositivos móviles, los autores podrían ofrecer dos versiones, una de ellas con la interpretación en lengua de signos insertada en el vídeo. La selección de diferentes pistas de lengua de signos se haría de la misma manera que se manejan diferentes subtítulos.

Transcripciones

Hay personas a las que no les es posible o les resulta difícil seguir los subtítulos sincronizados, como las personas sordociegas, las personas con problemas cognitivos o con dificultad en la lectura. Incluso las personas que sí pueden seguirlos podrían perderse información al dividir la atención entre lo que ocurre en pantalla y el texto de los subtítulos.

Por tanto, la transcripción completa ayuda a las personas con diferentes necesidades y no es un sustituto de los subtítulos. La transcripción se puede presentar simultáneamente con el contenido audiovisual, pero debería estar también disponible independientemente.

El contenido que se incluye en la transcripción es tanto el de los subtítulos como el de la audiodescripción (y las opciones interactivas si tiene), y es por tanto una representación completa del material.

Requisitos del sistema

En este apartado se explica cómo las tecnologías para proporcionar contenido alternativo al vídeo y audio encajan en el panorama más amplio de la accesibilidad, tanto técnicamente desde de un punto de vista del agente de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia) como desde un punto de vista del proceso de producción.

Acceso a los controles y menús interactivos

Todas las posibilidades de interacción deben estar disponibles para todos los usuarios. Por tanto deben ser independientes del dispositivo de entrada (teclado, ratón, habla, etc.) y ser expuestas a los productos de apoyo. Las posibilidades de interacción deben ser lo suficientemente ricas para un control detallado de la reproducción del contenido.

Control del nivel de granularidad para la navegación por la estructura del contenido

Los usuarios deben ser capaces de establecer el rango o alcance de los controles “siguiente” y “anterior” en tiempo real, ajustando en qué nivel de la estructura del contenido quieren navegar con dichos controles.

Modificación de la escala de tiempo

Por ejemplo en muchos reproductores de audiolibros, desde hace años, se puede acelerar o ralentizar la lectura del contenido sin alterar el tono del audio.

Requisitos de la producción y los resultados

En este apartado se habla del desafío que supone la falta de un sistema universal de acceso, la convivencia de sistemas incompatibles, o la falta de formatos comunes que permita el intercambio de datos. Trata también de los recursos que se aportan por separado, pues los contenidos alternativos son a menudo creados por entidades diferentes a las que crean el contenido audiovisual, así como de las posibilidades de edición.

Descubrimiento y activación/desactivación del contenido alternativo por parte del usuario

Se han descrito diferentes tipos de contenido alternativos que permitirán que las personas puedan percibir, interactuar y comprender el contenido audiovisual. Estas alternativas pueden ser parte del contenido, activarse o desactivarse o estar vinculadas al contenido original.

El usuario se enfrenta al reto de poder descubrir y reconocer que se proporcionan estos contenidos alternativos.

Requisitos relativos a hacer que las propiedades estén disponibles para la API de accesibilidad

Los usuarios necesitan acceder a los contenidos, controlar su reproducción y activar las opciones de accesibilidad. Para que los agentes de usuario apoyen la API de accesibilidad implementada para una plataforma, los controles del reproductor tienen que exponer la información, en caso contrario hay que proporcionar la información en formatos alternativos.

Por ello la existencia de pistas de contenido alternativo debe ser expuesta al agente de usuario y la API de accesibilidad debe tener acceso a las mismas.

Requisitos sobre el uso del visor de vídeo

El visor de vídeo juega un papel importante en lo que se refiere a los contenidos alternativos. Ofrece una caja delimitada para muchas de las alternativas que se ofrecen visualmente (subtítulos, lengua de signos, etc.), aunque no todas se basan en una ventana (como las transcripciones completas).

Hay que recordar que un tercio del vídeo será ocupado por el texto de los subtítulos. Los usuarios esperan encontrarlos en un lugar estándar y poder hacer movimientos oculares rápidos entre los mismos y el contenido del vídeo. Por tanto no se debe ocupar este espacio con otras cosas y se debe evitar la superposición con el contenido importante del vídeo.

Los requisitos de este apartado también hacen referencia a la relación entre el tamaño de la ventana de visualización, la posición de contenido audiovisual y la del contenido alternativo.

Por último se tratan las opciones de personalización por parte del usuario: del brillo y el contraste; de las características del texto (por ejemplo de los subtítulos) tamaño, color, etc.; o el ajuste del tamaño de visualización pero preservando la relación y evitando recortes.

Requisitos sobre las pantallas secundarias y otros dispositivos

El término “second screen” hace referencia a que cuando vemos o consumimos contenido (por ejemplo en la televisión), la información contextual adicional o el propio contenido se puede visualizar en un dispositivo complementario (como una tablet o un móvil). Se llama “second screen” a pesar de que puede haber más de dos y a pesar de que no todos los dispositivos secundarios son pantallas de vídeo.

Hay que asumir que muchos usuarios tendrán un dispositivo de visualización adicional y/o un dispositivo de audio adicional (como unos auriculares) conectado al dispositivo de visualización principal. Por tanto debe ser posible configurar ciertos tipos de contenidos para su presentación en dispositivos específicos.

Checklist de los Requisitos de Usuario para la Accesibilidad de los Medios Audiovisuales

Este es un apartado muy útil porque recoge la checklist con todos los requisitos listados en el documento.

La checklist está en formato tabla, con una fila para cada requisito y diversas columnas para indicar:

  • su categorización respecto a la tecnología (si ya está en la especificación de HTML 5, si es un nuevo requisito de la especificación, etc.)
  • su relación con criterios de conformidad de las WCAG y las UAAG. Cuando se incluye el signo “+” se está indicando que el requisito de este documento se define con más precisión que en las WCAG o en las UAAG. De hecho, el grupo de trabajo de las UAAG (se está trabajando en las UAAG 2.0 actualmente) ha indicado que revisarán algunos de sus requisitos en base a esta checklist.
  • su prioridad (Must, Should o May)

 

Actualmente, está en borrador una versión actualizada de este documento.

 

Accesibilidad web: Problemas con el foco de teclado

En esta entrada voy a hablar de un problema bastante habitual en los sitios web. Hay personas que navegan por un sitio web a través de teclado, porque no ven. Al carecer de visión no pueden llevar a cabo el manejo del ratón y la visualización de la pantalla para poder dirigir el puntero.

 

Accesibilidad web: Problemas con el foco de teclado

Navegación por el sitio web a través de teclado

Para muchas personas este el único medio que tienen poder acceder a los sitios web:

  • Personas que usan un lector de pantallas o teclado braille.
  • Personas con diversidad funcional física o motriz, que pueden usar:
    • teclados alternativos.
    • Licornios, punteros de cabeza o apuntadores de boca para interactuar con el teclado.
    • Pulsadores de soplado que simulan la navegación por teclado.
  • Usuarios expertos que se manejan más rápido por teclado que con el ratón.
  • Personas que usan un portátil, que prefieren la navegación por teclado, o cuando existe un problema que impide usar el ratón.

Accesibilidad por teclado

Las WCAG 2.0 tienen varios criterios que hacen referencia a la operabilidad de los sitios web mediante el teclado.

teclado

2.1 Accesible por teclado

  • 2.1.1 Teclado Toda la funcionalidad del contenido es operable a través de una interfaz de teclado sin que se requiera una determinada velocidad para cada pulsación individual de las teclas, excepto cuando la función interna requiere de una entrada que depende del trayecto de los movimientos del usuario y no sólo de los puntos inicial y final. (Nivel A)
  • 2.1.3 Teclado (sin excepciones): Toda la funcionalidad del contenido se puede operar a través de una interfaz de teclado sin requerir una determinada velocidad en la pulsación de las teclas. (Nivel AAA)

 

Problemas con el foco de teclado

Hay varios problemas que impiden la navegación por los sitios web y que están relacionados con el foco de teclado. Estos problemas son:

  • El foco no está visible
  • El orden del foco no tiene sentido
  • Las páginas tienen trampas para el foco
  • Recibir el foco provoca automáticamente un cambio de contexto sin avisar al menos previamente al usuario.

1. El foco no está visible

Por defecto, cuando un enlace coge el foco aparece punteado alrededor.  O cuando un campo de formulario coge el foco también se aprecia visualmente, es decir, muestra un cursor parpadeando en su interior. El criterio de conformidad que recoge este problema es el 2.4.7 Foco visible.

El problema está en que hay sitios web en los que por razones estéticas, el foco no se encuentra visible, lo cual dificulta la navegación a muchos usuarios. Por lo tanto, el foco debe estar visible en todo momento.

El foco puede resaltarse con un borde más sólido y de color. Y usarse con la pseudoclase :hoveren la CSS y así resalta también con la interacción mediante ratón.

 

2. El orden del foco no tiene sentido

Otro de los problemas es que el orden del foco no tenga sentido. Por eso, es muy importante que el orden del foco sea el correcto, tal y como establece el criterio 2.4.3 de las WCAG 2.0.

Por ejemplo, si un enlace abre un menú desplegable, el siguiente elemento que debería coger el foco sería el primer elemento del menú.

No  sólo es necesario que el orden de lectura sea lineal y tenga sentido, sino también que el orden del foco por los elementos de interacción también lo tenga. De igual manera ocurre con el atributo global tabindex.

 

3. Trampas para el foco

El tercer problema que nos encontramos son las trampas para el foco. Son aquellas zonas a las que no podemos llegar mediante teclado, como son las ventanas modales o cuadros de diálogo, los controles de un reproducción de un vídeo o una animación en Flash. En estas interacciones sólo se puede volver atrás o ir a otra parte mediante el ratón.

Tal y como se puede leer en el criterio de conformidad 2.1.2 Sin trampas para el foco de teclado, vamos a seguir con el ejemplo del menú desplegable.

Si una vez que abrimos el menú, navegamos con la tecla TAB, y por cualquier razón no podemos volver a salir con el teclado, se consideraría una trampa para el foco.

 

4. Recibir el foco provoca un cambio de contexto

Otro de los problemas que se pueden dar es cuando se produce un cambio de contexto y reciben el foco sin advertir previamente al usuario.

Los cambios de contexto deberían producirse cuando el usuario realiza una acción, que normalmente se utilice para solicitar un cambio de contexto, como hacer clic en un enlace o un botón.

Los cambios inesperados en el contexto o que no puedan detectarlos pueden desorientar a los usuarios.

¿Qué es un cambio de contexto?

Es un cambio importante en el contenido de la página, que cuando se hace sin el consentimiento del usuario, puede desorientar a quienes no pueden ver la página o no pueden ver toda la página al mismo tiempo.

Esto incluye cambios en:

  • El agente de usuario. Como abrir un gestor de correo o un lector de PDF.
  • El foco: Mover automáticamente el foco a otro elemento. Una mala práctica muy habitual en los formularios es mover el foco de un control a otro automáticamente, por ejemplo al rellenar los campos de una cuenta bancaria. También es una mala práctica habitual utilizar  onfocus="blur()"para quitar el foco a un elemento cuando lo recibe.
  • El área de visualización del contenido: abrir otra ventana, otra pestaña o cambiar de marco.
  • El contenido. Cambios en el contenido que cambian el significado de la página: enviar un formulario, ir a otra página, o que lo parezca porque se cambia el orden del contenido de la misma.

Los criterios relacionados con este problema son:

3.2.1 Al recibir el foco

3.2.2 Al recibir entradas

3.2.5 Cambios a petición

 

Accesibilidad web: Las WCAG 2.1

El pasado 5 de junio, el W3C estableció como recomendación las WCAG 2.1, tras más de 10 de la publicación de las WCAG 2.0.

Accesibilidad web: WCAG 2.1

Introducción

Antes de empezar, me gustaría aclarar una cosa:

Un sitio web que aplique las WCAG 2.1 también cumple con las WCAG 2.0.

La novedad, es que los criterios ya no están ordenados por su nivel de conformidad. Para no cambiar el número de criterio a los criterios existentes, los nuevos siempre se han añadido al final de los actuales.

Para ello, hay una guía de referencia y ayuda, que permite filtrar los criterios por nivel, ya sea de las WCAG 2.0 o WCAG 2.1.

Filtro para los criterios en las WCAG 2.1

WCAG 2.1.

Como ya veníamos comentando desde hace unos meses, existen 17 nuevos criterios de conformidad, que son los siguientes:

 

Criterio 1.3.4: Orientación.

“El contenido no restringe su vista y funcionamiento a una única orientación de visualización, como vertical u horizontal, a menos que una orientación de visualización específica sea esencial.”

Este criterio hace referencia a que los sitios web deben admitir las dos orientaciones disponibles para que se pueda adaptar a todo tipo de usuarios, y asegurarse de que el contenido y la funcionalidad de la web estén disponibles. El contenido debe ser operable en todas las orientaciones de pantalla.

Criterio 1.3.5. Identificar el propósito de la entrada.

El propósito de cada campo que recoge información del usuario se puede determinar por software cuando:

  • el campo tiene un propósito identificado y concreto de los listados en el apartado 7. Input Purposes for User Interface Components (“name”, “country”, “postal-code”, etc.), cuya lista está basada en la de HTML 5.2 Autofill field section. Y
  • el contenido está implementado usando una tecnología con soporte para identificar el significado esperado del dato introducido en un campo de formulario.

Este criterio ayuda a que sea más fácil rellenar los campos de formularios, según las necesidades y las preferencias de los usuarios.

La técnica suficiente incluida es utilizar autocomplete con los atributos definidos en HTML 5.2 Autofill field section.

Criterio 1.3.6 Identificar el propósito.

“En el contenido implementado utilizando lenguaje de marcas, el propósito de los componentes de la interfaz de usuario, los iconos y las regiones se puede determinar mediante programación.”

Tiene el mismo objetivo que el criterio anterior en cuantro a las preferencias y necesidades de los usuarios. Por ejemplo, si se identifica que es un botón para enviar un email, este tipo de botón se podrá personalizar con un icono o un término comprensible para un usuario en particular; se podrá mostrar ayuda relacionada con esa función, renderizarlo más grande, etc.

Las técnicas suficientes que se incluyen son: agregar semántica a los elementos usando landmark roles ARIA.

Como técnicas recomendables se incluyen: el uso de los atributos ARIA aria-invalid y aria-required en los campos de formulario.

1.4.10 Reflow

“El contenido puede presentarse sin pérdida de información o funcionalidad y sin necesidad de hacer scroll en dos dimensiones*, para:

  • Contenido con desplazamiento vertical con un ancho equivalente a 320 píxeles CSS;
  • Contenido con desplazamiento horizontal con una altura equivalente a 256 píxeles CSS;

*excepto para partes del contenido que lo requieran para su uso o significado.

En las notas se indica que, 320 píxeles CSS es equivalente a un viewport width inicial de 1280 píxeles CSS con un zoom de 400%. Para el contenido diseñado para escrolar horizontalmente, 256 píxeles CSS es equivalente a un viewport height inicial de 1024px con un zoom de 400%.

Los contenidos que pueden requerir doble scroll son: imágenes, mapas, diagramas, vídeo, juegos, presentaciones, tablas de datos, o interfaces donde es necesario mantener las barras de herramientas a la vista mientras se manipula el contenido.

Este criterio asegura que se puede hacer zoom de 400% sin pérdida de contenido o funcionalidad y se evitan los dobles scroll (salvo en los casos citados), pues el impacto del desplazamiento horizontal aumenta el esfuerzo de lectura 40-100 veces.

Las técnicas suficientes que se incluyen son: usar media queries y CSS grids o CSS Flexbox para reajustar los contenidos. Y también, calcular por programación los tamaños y posiciones de los elementos de manera que escalen con el tamaño del texto.

Como técnicas recomendables se incluyen: ajustar el tamaño de las imágenes y las tablas al viewport; y dar un mecanismo que permita cambiar a la vista móvil en cualquier momento.

Como errores comunes se nombran: usar tamaños y posiciones fijas; impedir el zoom; y usar texto preformateado o tratarlo como una excepción.

1.4.11 Contraste no textual

“La presentación visual de los siguientes elementos tiene una ratio de contraste de al menos 3:1 respecto a los colores adyacentes:

  • Componentes de la interfaz de usuario: información visual utilizada para identificar los componentes de la interfaz de usuario y los estados, excepto para componentes inactivos o cuando la apariencia del componente es determinada por el agente de usuario y el autor no la modifica.
  • Objetos gráficos: partes de los gráficos necesarias para comprender el contenido, excepto cuando una presentación particular de los gráficos es esencial para la información que se transmite (esencial como por ejemplo en los logotipos o en las banderas, en una captura de un sitio que muestra cómo es su apariencia, en un mapa de calor, en un diagrama médico que usa los colores utilizados en biología, etc.)

 

El criterio 1.4.3 solo abarca “la presentación visual de texto e imágenes de texto” y por tanto el criterio 1.4.11 lo complementa, porque el contraste sería también necesario para:

  • los iconos (que no van con texto)
  • los gráficos, por ejemplo, cada una de sus líneas
  • el borde o límites visuales de un campo de formulario o botón, siempre que no estuviera disabled
  • el indicador visual del valor actual en un control deslizante
  • el indicador del foco
  • etc.

Las técnicas suficientes para las gráficas son: que el contraste entre los colores de las gráficas sea suficiente así como el contraste de las líneas entre colores adyacentes.

Las técnicas suficientes para los textos de las gráficas son: que se incluyan en las gráficas etiquetas y valores; que las imágenes que transmiten información y los textos de las gráficas tengan suficiente contraste; o que haya un control con suficiente contraste que permita a los usuarios cambiar a una presentación que utilice suficiente contraste.

Como técnica recomendable, en el caso de los enlaces y controles que solo se identifican por el color, sería un ratio de contraste de 4,5:1 con el texto de alrededor y pistas visuales adicionales.

1.4.12 Espaciado de texto

El contenido implementado con lenguaje de marcas que soporte las siguientes propiedades, no se pierde contenido o funcionalidad ni por configurarlas, ni por no cambiar ninguna otra propiedad de estilo:

  • altura de línea (espaciado entre líneas): al menos 1.5 veces el tamaño de fuente
  • espaciado debajo de los párrafos: al menos 2 veces el tamaño de fuente
  • espaciado de letras (tracking): al menos 0.12 veces el tamaño de fuente
  • espaciado de palabras: al menos 0.16 veces el tamaño de fuente

 

La técnica suficiente que se incluye es: el espaciado del texto se pueda cambiar, siendo un error habitual usar medidas fijas.

Como técnicas recomendables se indican: usar las propiedades CSS letter-spacing, line-height y definir el tamaño de los contenedores en em

1.4.13 Contenido en Hover o Foco

Cuando el contenido se hace visible/oculto porque un componente de la interfaz coge/pierde el foco, lo siguiente es verdad:

  • Dismissable. Hay un mecanismo disponible para descartar el contenido adicional sin mover el puntero o el foco del teclado, a menos que el contenido adicional comunique un error en la entrada de datos, o no tape o reemplace otro contenido.
  • Hoverable. Si el puntero del cursor puede activar el contenido adicional, entonces el puntero se puede mover sobre el contenido adicional sin que desaparezca el contenido adicional.
  • Persistent. El contenido adicional permanece visible hasta que la activación del hover/focus se elimine, el usuario lo descarte o su información ya no sea válida.

 

Algunos ejemplos de contenidos a los que SÍ se aplica este criterio son: tooltips personalizados, submenús, pop-ups no modales que se muestran en el hover o en el focus, etc.

Las técnicas suficientes que se incluyen son: el uso de las pseudo-clases hover y focus.

Como técnicas recomendables: no escondas los elementos que desencadenan los cambios; y no escondas los nuevos mensajes cuando se haga hover sobre ellos, o hasta que el usuario los descarte o sean incorrectos.

2.1.4 Atajos de teclado de caracteres

si se implementa un atajo de teclado en el contenido usando una letra (incluidas mayúsculas y minúsculas), signo de puntuación, número o símbolo, entonces al menos una de las siguientes afirmaciones es cierta:

  • Desactivar: hay un mecanismo para desactivar el atajo.
  • Reasignar: hay un mecanismo para reasignar ese atajo de teclado, usando uno o más caracteres de teclado no imprimibles (Alt, Ctrl,…)
  • Activo solo en el foco: el atajo de teclado de un componente de la interfaz solo está activo cuando ese componente tiene el foco.

 

Este criterio tiene relación con los atajos de teclado personalizado.

Beneficia a los usuarios que utilizan programas de reconocimiento de voz que pueden activar varios atajos accidentalmente cuando estos están asociados a una sola tecla.

También puede evitar errores. El usuario de teclado puede pulsarla sin querer, especialmente aquellos que tienen problemas de movilidad.

Las técnicas suficientes se incluyen son: que los usuarios tengan una forma de desactivar los atajos de teclado de un solo carácter, o que exista un mecanismo que permite a los usuarios modificar los atajos de teclado y reasignarlos a caracteres no imprimibles.

2.2.6 Tiempos de espera

Se debe advertir a los usuarios de la duración de cualquier inactividad del usuario que pueda causar la pérdida de datos, a menos que los datos se conserven durante más de 20 horas cuando el usuario no realiza ninguna acción.”

2.3.3 Animación de interacciones

“Las animaciones de movimiento desencadenadas por una interacción pueden ser deshabilitadas, a menos que la animación sea esencial para la funcionalidad o la información que se transmite.”

Este criterio se aplica cuando una interacción del usuario inicia una animación inesperadamente.

Esto puede provocar no solo distracción, sino incluso en algunos usuarios con desorden vestibular, nauseas y dolores de cabeza.

Las técnicas suficientes que se incluyen son: que los usuarios puedan definir en sus preferencias que no haya animaciones.

2.5.1 Gestos del puntero

“Toda funcionalidad que usa gestos multipunto o basados en una trayectoria, puede ser operada con un solo gesto de puntero (single pointer) sin depender de un gesto basado en una trayectoria, a no ser que sea esencial un gesto multipunto o basado en una trayectoria.”

iconos-del-gesto-fijados-para-los-dispositivos-móviles-del-tacto

Este criterio se aplica al contenido web que interpreta las acciones del puntero, es decir, no se aplica a las acciones que se requieren para operar el agente de usuario o el producto de apoyo.

Las técnicas suficientes que se incluyen son: no basar la interacción solo en recorridos gestuales o en varios toques, ofrecer controles alternativos que permitan realizar la misma función pero que no requieran gestos complejos.

2.5.2 Cancelación del puntero

“Para la funcionalidad que se puede operar con un puntero único, al menos una de las siguientes afirmaciones es verdad:

  • No Down-Event: el down-event del puntero no se usa para ejecutar ninguna parte de la función
  • Abort or Undo: la finalización de la función está en el up-event, y hay un mecanismo disponible para abortar la función antes de completarse o deshacer la función una vez completada
  • Up Reversal: el up-event invierte cualquier resultado del down-event anterior.
  • Essential: completar la función en el down-event es esencial

 

“Down-event”, es cuando se presiona el dedo contra la pantalla.

Este criterio se aplica al contenido web que interpreta las acciones del puntero, es decir, no se aplica a las acciones que se requieren para operar el agente de usuario o el producto de apoyo.

Las técnicas suficientes se incluyen son: la activación de los controles en el up-event en HTML, iOS y Android; y que los eventos táctiles solo son activados cuando el toque se retira del control.

Como error a evitar, no actives un control en un down-event si el evento up-event no coincide con la misma localización del puntero.

2.5.3 Etiqueta en Nombre

“Para los componentes de la interfaz de usuario con etiquetas que incluyen texto o imágenes de texto, el nombre accesible contiene el texto que se presenta visualmente. Y añade en una nota que una buena práctica es poner el texto de la etiqueta al comienzo del nombre.”

Si la etiqueta visible no es igual que la etiqueta no visible (el nombre accesible) los usuarios que acceden con programas de reconocimiento de voz pueden tener problemas. Hay que tener en cuenta que estos usuarios pueden decir el menú, el vínculo o la etiqueta del botón para activarlos.

Para los usuarios que utilizan un lector de pantalla pero visualizan la pantalla, también es mucho más claro que el nombre accesible que se les anuncia coincida con la etiqueta visual.

La técnica suficiente que se incluye es que las etiquetas visibles concuerden con los nombres accesibles.

Como técnica recomendable, si un icono no va acompañado de un texto, usa su texto “hover” como nombre accesible.

Los errores habituales que se listan:

  • El nombre accesible no contiene el texto visible de la etiqueta.
  • El nombre accesible contiene el texto de la etiqueta visible, pero las palabras de la etiqueta visible no están en el mismo orden.
  • El nombre accesible contiene el texto de la etiqueta visible, pero una o más palabras se entremezclan en la etiqueta.
  • El nombre accesible contiene el texto de la etiqueta visible, pero hay una o más palabras adicionales antes del texto de la etiqueta visible.

2.5.4 Actuación de movimiento

Toda funcionalidad que puede ser operada por el movimiento del dispositivo o por el movimiento del usuario, también puede ser operada mediante los componentes de la interfaz de usuario, y la respuesta al movimiento se puede desactivar para evitar el accionamiento accidental.

Incluye dos excepciones:

  • Supported Interface: el movimiento se utiliza para operar la funcionalidad a través de una interfaz compatible con la accesibilidad.
  • Essential: el movimiento es esencial para la función o si no se invalidaría la actividad.

Este criterio hace referencia a los sensores del dispositivo que detectan y responden a algún tipo de entrada del entorno físico. Por ejemplo, un movimiento como agitar el móvil, inclinar la tablet, etc.

Este criterio no se aplica a los sensores de geolocalización, ni a los movimientos que no sean movimientos intencionales del usuario, ni a los asociados al uso del teclado, el puntero o productos de apoyo.

Las técnicas suficientes que se incluyen son: proporcionar formas alternativas de introducir información cuando se usan los sensores de movimiento para activar funcionalidades y contenidos; y que el usuario pueda desactivar la actuación por movimiento.

2.5.5 Tamaño de la región de pantalla

Define que el tamaño mínimo del “target” (región de la pantalla que acepta la acción del puntero) debe ser 44×44 píxeles CSS.

Incluye ciertas excepciones:

  • Equivalent. Si el target está disponible a través de un enlace o un control equivalente, en la misma página, que tiene al menos 44×44 píxeles CSS.
  • Inline. Si el target está en una frase o en un bloque de texto.
  • User agent control. Si la apariencia del target es determinada por el agente de usuario y no es modificada por el autor.
  • Essential. Si una presentación particular del target es esencial para la información que se transmite.

 

El tamaño 44×44 que se define es el mínimo, pero se recomienda utilizar tamaños mayores, esto es especialmente importante en los siguientes casos:

  • El control se usa con frecuencia.
  • El resultado de la interacción no se puede deshacer fácilmente.
  • El control está situado en un lugar que será difícil de alcanzar o está cerca del borde de la pantalla.
  • El control es parte de una tarea esencial.

 

Las técnicas suficientes que se incluyen son: que las áreas interactivas tengan al menos 44*44px; y ofrecer un mecanismo que permita cambiar el tamaño de las áreas.

Como técnica recomendable, el área interactiva de un párrafo que es un enlace también tiene al menos 44*44px.

2.5.6 Mecanismos de entrada concurrentes

“El contenido web no restringe el uso de las modalidades de entrada (teclado, interfaz de teclado, ratón, pantalla táctil, habla, etc.) disponibles en una plataforma, excepto cuando la restricción es esencial, necesaria para garantizar la seguridad del contenido o respetar la configuración del usuario.”

En la mayoría de los dispositivos, es posible que los usuarios cambien entre diferentes medios de entrada de datos en la misma sesión (por ejemplo, entre pantalla táctil y teclado).

La aplicación o sitio web no debe asumir que el usuario siempre utilizará exclusivamente un mecanismo de entrada particular, y deberá permitir a los usuarios operar con cualquier mecanismo de entrada a su disposición.

Las técnicas suficientes que se incluyen son: usar solo manejadores de evento JS de alto nivel, independientes de la modalidad de entrada (focus, blur, click); o incluir manejadores de evento redundantes para las diferentes modalidades de entrada.

4.1.3 Mensajes de estado

“en el contenido implementado mediante lenguaje de marcas, los mensajes de estado pueden ser determinado por software a través de roles y propiedades, de modo que puedan ser presentados a los productos de apoyo sin recibir el foco.”

Se debe proporcionar una notificación para cada cambio del contenido de la página. No se trata tanto de que se vean esos mensajes, sino de que sean anunciados por el lector de pantalla. Esto se hace con el atributo aria-live de ARIA y sus roles específicos.

Los mensajes serán del tipo: “El formulario se ha enviado correctamente”

Las técnicas suficientes que se incluyen son:

  • Si el mensaje de estado advierte del éxito o el resultado de una acción o el estado de una aplicación: se usa role="status", informando de que el datos se ha enviado correctamente.
  • Si el mensaje de estado transmite una sugerencia o una advertencia ante la existencia de un error: se usa role=alert, en combinación con alguna de otras técnicas ya existentes como dar una descripción textual para identificar los campos requeridos no completados, así como los campos con valores o formatos no permitidos; permitir saltar a los errores; dar sugerencias de corrección o proporcionar una revisión ortográfica y sugerencias para la entrada de datos.
  • Si el mensaje de estado transmite información sobre el progreso de un proceso: se usa el role="log", role="progressbar" o role="status"

 

Nota adicional: 5.2.2 Páginas completas.

Este requisito de conformidad trata de que una página es conforme si es conforme en su totalidad, lo cual incluye las alternativas a las que enlaza (como por ejemplo una página con descripciones extensas de imágenes o con presentaciones alternativas de un vídeo).

Esta nota añade que las distintas variaciones de la página, como las generadas automáticamente para diferentes resoluciones de pantalla, también forman parte de esa página y deben ser conformes todas ellas.

Directiva europea 2016/2012 sobre la accesibilidad de los sitios web y aplicaciones móviles

Tras un proceso de 4 años, el 26 de octubre de 2016 se aprobó 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.

directiva europea 2016_2012

Objetivo de la directiva

El objetivo de la directiva es armonizar los requisitos de accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público:

La presente Directiva establece las normas por las que se exige a los Estados miembros que garanticen que los sitios web, independientemente del dispositivo empleado para acceder a ellos, y las aplicaciones para dispositivos móviles de los organismos del sector público cumplan los requisitos de accesibilidad.

Lo primero que deberíamos aclarar es qué es una directiva en el marco jurídico de la Unión Europea.

¿Qué es una directiva?

Las directivas son actos legislativos en los cuales se establecen objetivos que todos los países de la UE deben cumplir. Sin embargo, corresponde a cada país elaborar sus propias leyes sobre cómo alcanzar estos objetivos.

La directiva obliga a los Estados miembros destinatarios (uno, varios o todos ellos) en cuanto al resultado que debe conseguirse, dejándoles, sin embargo, la elección de la forma y de los medios.

El legislador nacional debe adoptar un acto de transposición en el Derecho interno mediante el que se adapte la legislación nacional a tenor de los objetivos definidos en la directiva.

Este acto de transposición es el que en esencia confiere derechos e impone obligaciones al ciudadano. Los Estados miembros disponen de facultades discrecionales en la transposición al Derecho nacional, lo que les permite tener en cuenta las particularidades nacionales.

La transposición debe efectuarse en el plazo establecido por la directiva. Al transponer las directivas, los Estados miembros deben garantizar la eficacia del Derecho de la Unión, de conformidad con el principio de cooperación leal consagrado en el artículo 4, apartado 3, del TUE.

En principio, las directivas no son directamente aplicables. Sin embargo, el Tribunal de Justicia de la Unión Europea ha considerado que, de forma excepcional, determinadas disposiciones de una directiva pueden tener efectos directos en un Estado miembro sin que sea necesario que este último haya adoptado un acto de transposición previo, siempre que: a) la directiva no haya sido transpuesta o lo haya sido de forma incorrecta; b) las disposiciones de la directiva sean incondicionales y suficientemente claras y precisas; y c) las disposiciones de la directiva confieran derechos a los individuos. Si se reúnen estas condiciones, un particular puede hacer valer las disposiciones de la directiva ante cualquier autoridad pública.

Por tanto, la directiva es de obligado cumplimiento pero no es directamente aplicable, sino que ahora España (y de igual forma cada país) debe elaborar una ley que respete, como mínimo, el alcance y los requisitos de accesibilidad estipulados en esta directiva.

La ley española deberá respetar “como mínimo” el alcance y los requisitos de accesibilidad de la directiva porque el artículo 2 lo establece así:

Artículo 2. Armonización mínima

Los Estados miembros podrán 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 aplicaciones para dispositivos móviles dispuestos en la presente Directiva.

Es decir, que la ley de un país podrá ser luego más exigente que lo estipulado en la directiva. De hecho, la propia directiva anima a ampliar su alcance.

También puede darse el caso de que en algunos casos la propia legislación del país puede ser ya más exigente que la directiva europea.

 

¿Cuánto tiempo tiene España para elaborar la ley que adapte la directiva a su legislación?

Los Estados miembros tienen un plazo estipulado para llevar a cabo la adaptación de la directiva, en caso contrario, la Comisión abrirá un procedimiento de infracción:

Cuando un país no transpone una Directiva, la Comisión puede incoar un procedimiento de infracción e instruir un procedimiento contra el país ante el Tribunal de Justicia de la UE (el incumplimiento de la sentencia dictada con este motivo puede derivar en una nueva condena que puede concluir en la imposición de multas).

En Directivas de la Unión Europea, Eur-lex

En consecuencia, podemos estar bastante seguros de que la directiva será transpuesta a nuestra legislación para evitar sanciones. El plazo que estipula la directiva para ello es el 23 de septiembre de 2018:

Artículo 12. Transposición

Los Estados miembros pondrán en vigor a más tardar el 23 de septiembre de 2018 las disposiciones legales, reglamentarias y administrativas necesarias para dar cumplimiento a lo establecido en la presente Directiva. Informarán inmediatamente de ello a la Comisión.

¿Cuándo deben empezar los sitios web y apps del sector público español a cumplir con la directiva?

En primer lugar, como hemos visto, deberemos esperar a que España apruebe una ley propia en la que transponga la directiva europea.

Pero la directiva ya estipula los plazos en los que entraría en vigor la obligación de cumplir con los requisitos de accesibilidad:

  • Sitios web nuevos (publicados después del 23 de septiembre de 2018): deberán ser accesibles a partir del 23 de septiembre de 2019.
  • Resto de sitios web (publicados antes del 23 de septiembre de 2018): deberán ser accesibles a partir del 23 de septiembre de 2020.
  • Aplicaciones para dispositivos móviles: deberán ser accesibles a partir del 23 de junio de 2021.

 

El 23 de septiembre de 2018, los estados deben haber transpuesto la directiva a sus legislaciones o de lo contrario serían sancionados.

Norma EN 301 549

La norma EN 301 549 es el estándar europeo que dicta los requisitos de accesibilidad de cualquier producto y servicio: páginas web, software incluidas apps nativas, documentos, hardware, etc.

La Directiva (UE) 2016/2102 “sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público”, establece como norma a seguir la EN 301 549.

En estos momentos, ya tenemos el borrador de la que será la próxima versión EN 301 549  (PDF). En ella se incluye un anexo A. “Relationship between the present document and the essential requirements of Directive 2016/2102”, con dos tablas:

  • Tabla A: requisitos que se aplican a las páginas web: capítulo 9 (WCAG 2.0) y capítulo 12 “Documentación y servicios de atención al cliente”, y otros capítulos condicionalmente
  • Tabla B: requisitos que se aplican a las aplicaciones móviles: capítulo 11 “Software” (WCAG 2.0 con excepciones y criterios adicionales) y 12 “Documentación y servicios de atención al cliente”, y otros capítulos condicionalmente.

 

¿Quiénes están obligados a cumplir con los requisitos de accesibilidad de la directiva?

La Directiva establece los requisitos de accesibilidad que deben cumplir los sitios web y aplicaciones móviles del sector público. NO incluye a las empresas privadas.

¿Qué se entiende por “sector público”?

Artículo 3. Definiciones

1) «organismo del sector público»: el Estado, las entidades territoriales, los organismos de Derecho público según se definen en el artículo 2, apartado 1, punto 4, de la Directiva 2014/24/UE, o las asociaciones constituidas por una o más de dichas entidades o uno o más de dichos organismos de Derecho público, si esas asociaciones se han establecido con el propósito específico de atender necesidades de interés general, sin tener carácter industrial ni comercial;

Los organismos de Derecho público se definen así en la Directiva 2014/24/UE:

4) «Organismo de Derecho público»: cualquier organismo que reúna todas las características siguientes:

a) que se haya creado específicamente para satisfacer necesidades de interés general que no tengan carácter industrial o mercantil;

b) que esté dotado de personalidad jurídica propia, y

c) que esté financiado mayoritariamente por el Estado, las autoridades regionales o locales, u otros organismos de Derecho público, o cuya gestión esté sujeta a la supervisión de dichas autoridades u organismos, o que tenga un órgano de administración, de dirección o de supervisión, en el que más de la mitad de los miembros sean nombrados por el Estado, las autoridades regionales o locales, u otros organismos de Derecho público.

Sin embargo, se establecen algunas excepciones.

NO se aplica a los siguientes sitios web y aplicaciones móviles

3. La presente Directiva no se aplica a los siguientes sitios web y aplicaciones para dispositivos móviles:

a) sitios web y aplicaciones para dispositivos móviles de prestadores del servicio público de radiodifusión y sus filiales, así como los de otros organismos o sus filiales que cumplan un mandato de servicio público de radiodifusión;

b) sitios web y aplicaciones para dispositivos móviles de ONG que no presten servicios esenciales a los ciudadanos ni servicios que traten específicamente las necesidades de las personas con discapacidad o estén diseñados para ello.

5. Los Estados miembros podrán excluir del ámbito de aplicación de la presente Directiva los sitios web y las aplicaciones para dispositivos móviles de escuelas, jardines de infancia o guarderías, excepto en lo relativo a las funciones administrativas esenciales en línea.

(33) Las funciones administrativas esenciales en línea de escuelas, jardines de infancia y guarderías deben ser accesibles. Cuando ese contenido esencial se proporcione de manera accesible en otro sitio web, no debe ser necesario que también sea accesible en la página web del centro de que se trate.

A pesar de ello, la directiva anima a los estados a ampliar el ámbito de aplicación de la Directiva:

(34) […] debe animarse a los Estados miembros a que amplíen la aplicación de la presente Directiva a las entidades privadas que ofrezcan instalaciones y servicios abiertos al público o de uso público, entre otros en los ámbitos de la asistencia sanitaria, la asistencia infantil, la inclusión social y la seguridad social, así como en el sector del transporte y la electricidad, el gas, la calefacción, el agua, las comunicaciones electrónicas y los servicios postales

(35) Si bien la presente Directiva no se aplica a los sitios web ni a las aplicaciones para dispositivos móviles de las instituciones de la Unión, se anima a estas a cumplir los requisitos de accesibilidad de la presente Directiva.

La legislación española ya obliga a las empresas privadas de más de 100 trabajadores o que facturen más de 6 millones de euros a tener sitios web accesibles, especialmente a las empresas “de los sectores de mayor incidencia en la actividad económica, entre otras, compañías dedicadas al suministro de electricidad, agua y gas, telecomunicaciones, entidades financieras, aseguradoras, grandes superficies, transportes, agencias de viaje” (Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información).

Habrá que esperar a la transposición de la directiva para ver si se mantienen estas exigencias extras de la actual legislación española. Esperemos que sí.

¿A qué tipo de contenidos afecta?

Se aplica al contenido de sitios web y a las aplicaciones para dispositivos móviles, cuyo alcance se concreta detalladamente en la directiva:

2) «aplicaciones para dispositivos móviles»: las aplicaciones informáticas diseñadas y desarrolladas por organismos del sector público o por su cuenta, para ser usadas por el público en general en dispositivos móviles, como teléfonos inteligentes y tabletas. No incluyen el software que controla dichos dispositivos (sistemas operativos para dispositivos móviles) ni el equipo informático;

(19) El contenido de los sitios web y de las aplicaciones para dispositivos móviles incluye la información tanto textual como no textual, los documentos y formularios que se pueden descargar, así como las formas de interacción bidireccional, como el tratamiento de formularios digitales y la cumplimentación de los procesos de autenticación, identificación y pago.

Por tanto, por si quedaba alguna duda, los PDF u otros archivos que se pueden descargar de una web deben ser también accesibles.

La directiva establece una serie de exclusiones, algunas temporales y otras permanentes, e indica que “esas exclusiones deben volver a valorarse en el contexto del examen de la presente Directiva a la luz de los futuros avances de la tecnología”.

Otras medidas para fomentar la accesibilidad

En la directiva se tratan también otras medidas:

  • fomentar y facilitar programas de formación sobre cómo crear, gestionar y actualizar contenidos de sitios web y aplicaciones para dispositivos móviles accesibles,
  • medidas de concienciación,
  • consultas periódicas por parte de los Estados miembros a las organizaciones que representan los intereses de las personas con discapacidad y personas de edad avanzada,
  • la promoción por parte de los Estados miembros del uso de determinadas herramientas de autor que permitan una mejor aplicación de los requisitos de accesibilidad,
  • la cooperación entre los Estados miembros para intercambiar buenas prácticas, o revisar el mercado o la evolución de la tecnología en materia de accesibilidad web.

 

Antes de finalizar, os dejo un resumen de las fechas importantes a tener en cuenta.

Esquema de la directiva

Año 2016 – Se aprueba y entra en vigor la directiva

  • 26 de octubre: Se aprueba la directiva
  • 2 de diciembre: Se publica en el Diario Oficial de la Unión Europea. (DOUE)
  • 22 de diciembre: entra en vigor.

 

Año 2018 – Fecha límite para la transposición nacional de la directiva

  • 23 de septiembre: transposición nacional
  • 23 de diciembre: La Comisión proporcionará modelo de declaración de conformidad, la metodología para el seguimiento y las disposiciones paera la presentación de informes.
  • Ese mismo día, los estados comunicarán el organismo de la aplicación de la directiva y del seguimiento y la presentación de informes.

Año 2019 – Obligación para los sitios web nuevos

  • 23 de septiembre: Deberán ser accesibles los sitios publicados después del 23 de septiembre de 2018

Año 2020 – Obligación para todos los sitios web

  • 23 de septiembre: Deberán ser accesibles todos los sitios web.

Año 2021 – Obligación para las apps

  • 23 de junio: deberán ser accesibles las app
  • 23 de diciembre: los estados presentarán su primer informe

 

Accesibilidad web: Cómo trabajar los textos alternativos en las imágenes

En esta entrada voy a hablar de uno de los principales problemas de accesibilidad web que hay. Aún habrá muchas personas que no lo sepan, así que no viene mal recordarlo: Los textos alternativos en las imágenes.

Accesibilidad web: Cómo trabajar los textos alternativos para las imágenes

Textos alternativos en las imágenes

Uno de los errores más habituales es que se encuentran textos alternativos que no son los adecuados. Porque a veces no se tiene en cuenta el contexto o la función de la imagen.

Para identificar más fácilmente cuál es la función de las imágenes, hay que pararse a pensar en las características del criterio 1.1.1 de las WCAG 2.0.

Por lo tanto, vamos a definir las diferentes opciones o posibilidades que se pueden dar a la hora de analizar una imagen.

¿La imagen es o forma parte de un enlace o botón?

Sí, la imagen es el único elemento dentro del enlace o es un mapa de imagen o un botón de tipo imagen:

  • Si la imagen es un logo, o es un icono, imagen o botón de tipo imagen en el que la imagen no tiene texto (por ejemplo un icono de una lupa) se debe añadir a la imagen o al botón de imagen el atributo alt, en el cual se indique la función de la imagen. Por ejemplo: alt="Buscar" (para el icono de una lupa) o alt="Página principal de la web de Mª Carmen de Alba (para el logotipo)
  • Si es un icono, imagen o botón de tipo imagen en el que la imagen tiene texto (como por ejemplo una imagen, o un botón de tipo imagen, con un sobre y el texto “Enviar”), se debe añadir a la imagen (o al botón de tipo imagen) el atributo alt, en el cual se indique la función de la imagen que normalmente será su texto (por ejemplo: alt="Enviar")
  • Si es un mapa de imagen (por ejemplo un mapa de España), a la imagen se debe añadir un atributo alt que identifique el contenido y su función (por ejemplo alt="Mapa de España. Seleccione una Comunidad Autónoma para acceder a su información turística") y a las áreas del mapa se les debe añadir el atributo alt identificando cada área (por ejemplo, alt="Galicia"). Con la técnica H24 puedes ampliar información sobre esta característica.

O por el contrario:

No, la imagen no es el único elemento dentro del enlace, ni es un mapa de imagen ni un botón de tipo imagen:

  • Si la imagen aporta información adicional al texto del enlace, y por tanto complementa la información del texto del enlace (por ejemplo un enlace que incluye el texto “Ponencia WordCamp Chiclana 2017” seguido de un icono de fichero PDF), se debe incluir a la imagen un atributo alt con la información adicional que transmite la imagen (por ejemplo alt="en formato PDF").
  • Si la imagen no aporta información adicional, es solo decorativa (por ejemplo el icono de una casa delante del enlace “Home”) tendrá el atributo alt vacío (y no debe incluirse el atributo title, a menos que también esté vacío), o bien la imagen se definirá en la CSS, por ejemplo con background-image.

 

¿La imagen es decorativa, invisible o no proporciona información adicional? (y no es un enlace)

  • Si, la imagen es decorativa, invisible y no aporta información adicional.

Por ejemplo un icono de advertencia que va seguido de un texto que ya comienza por “¡Advertencia!”. La imagen deberá tener el atributo alt vacío (y no debe incluirse el atributo title, a menos que también esté vacío) o bien se deberá definir la imagen en la CSS, por ejemplo mediante background-image.

  • No, la imagen aporta información y apoya al contenido.

En este caso hay que comprobar si se trata es un cuadro o crea una experiencia sensorial.

Si se trata de un cuadro, se incluirá el atributo alt indicando el nombre de la obra comúnmente aceptado (si lo tiene, por ejemplo alt="Las meninas de Velázquez") o una breve descripción que identifique el contenido.

Las meninas de Velázquez
No, no es un cuadro. Aquí debes incluir el atributo alt a la imagen.
El texto alternativo proporcionado por este atributo debe ser una breve descripción que identifique el contenido. (por ejemplo, en el caso de una escultura de arena, alt="Gran escultura de arena en una playa. Representa un rostro furioso de hombre hundido en la arena por una mano.")

Gran escultura de arena en una playa. Representa un rostro furioso de hombre hundido en la arena por una mano

Si es posible o útil se puede incluir un texto descriptivo adicional, por ejemplo si existe alguna razón especial por la cual se ha incluido dicha imagen en la página.

¿La imagen es parte de una prueba o test que queda invalidado si se describe la imagen? (y no es un enlace)

  • Si es una prueba o test visual (por ejemplo un test lógico de formas o un test de daltonimo) se incluirá a la imagen el atributo alt con una breve descripción que identifique el contenido (por ejemplo alt="Test visual de daltonismo")

 

test visual de daltonismo

  • Si se trata de un CAPTCHA, una prueba para comprobar si el usuario es una persona o una máquina, se incluirá a la imagen un atributo alt que indique el propósito del CAPTCHA (por ejemplo alt="Introduce este texto en el campo 'Captcha'. Si no puedes ver la imagen pulsa el botón 'Audio' disponible tras la imagen.") y también es necesario ofrecer otro CAPTCHA alternativo en una modalidad sensorial diferente, por ejemplo auditiva.

Captcha

¿La imagen forma parte de una serie de imágenes contiguas que transmiten una información de forma conjunta?

  • , la imagen forma parte de una serie de imágenes contiguas que transmiten una información de forma conjunta

Por ejemplo, en una puntuación de 5 estrellas, formada con cinco imágenes de estrellas contiguas, tres en amarillo y dos en blanco, el alt de la primera imagen será: alt="Puntuación: tres estrellas de cinco", y el resto de las imágenes tendrán texto alternativo nulo, alt="".

No, la imagen no forma parte de una serie de imágenes contiguas que transmiten una información de forma conjunta.

  • Si la imagen solo tiene texto se incluirá el atributo alt con el texto de la imagen (por ejemplo, para una imagen con el texto “5 años de garantía” se incluirá alt="5 años de garantía") Es preferible usar texto con el estilo deseado definido en la CSS en vez de una imagen de texto.
  • Si la imagen incluye texto no decorativo (por ejemplo la imagen de un gráfico con el texto de la leyenda y el título incluidos como parte de la imagen, se incluirá el atributo alt con la información que transmite la imagen y que debe incluir el texto. Por ejemplo, alt="Venta de comida. Gráfico circular: Sandwich=20%, Ensaladas=15% Sopas=25% Bebidas=22% y Postres=18%"

Como recomendación, usa texto y no imágenes de texto siempre que sea posible.

Gráfico

 

  • Si la imagen no contiene texto, incluye un atributo alt con la información que transmite la imagen. Por ejemplo, un icono de advertencia, seguido de un párrafo de texto “Tu sesión está a punto de expirar” tendrá como texto alternativo alt="¡Advertencia!". O por ejemplo, una imagen de los jugadores del Real Madrid levantando la Copa de Europa tendrá como texto alternativo alt="Sergio Ramos, capitán del Real Madrid levantando la Copa de Europa acompañado de sus compañeros"

 

Sergio Ramos, capitán del Real Madrid levantando la Copa de Europa acompañado de sus compañeros

 

Texto alternativo en imágenes complejas

Si la imagen es compleja tendrá un atributo alt que identifique el contenido o que proporcione una breve descripción del mismo. Además deberá tener una descripción larga que puede proporcionarse por medio de diferentes técnicas:

  • En otra página: se debe incluir el enlace a esta página adyacente a la imagen, inmediatamente antes o después de la misma.
  • En la misma página, a continuación de la imagen: incluir en el alt una referencia a la ubicación de la descripción larga.
  • En la misma página, lejos de la imagen: se debe incluir un enlace (un ancla) a la zona de la descripción. Este enlace debe estar inmediatamente antes o después de la imagen.
  • Mediante el atributo LONGDESC, siempre que no sobrepase los 150 caracteres.

 

¿A quién beneficia?

  • A las personas con dificultades para percibir el contenido visual (personas con ceguera, baja visión, sordo-ciegas) o con dificultades de comprensión del contenido visual. La información contenida en el texto se puede presentar al usuario de la manera que mejor se adapte a sus necesidades: en braille, leída en voz alta o presentarla visualmente.
  • A las personas que por limitaciones técnicas no pueden acceder al contenido visual: navegan con las imágenes deshabilitadas por tener una conexión lenta o para ahorrar costes en la tarifa por datos, hay un problema en el servidor y no se están sirviendo las imágenes o alguna de estas ya no está disponible. También pueden estar usando un navegador solo-texto.
  • A los buscadores web, pues se basan en el contenido textual para indexar los contenidos.

 

Norma Europea EN 301 549: Estructura (Parte 2)

Debido a lo extensa que es la Norma EN 301 549, en la entrada anterior realicé un resumen de la primera parte de esta norma. Y ahora toca continuar explicando todos y cada uno de los capítulos.

Norma Europea EN 301549 (2ª parte)

Norma EN 301 549: Segunda parte

Capítulo 6: Requisitos sobre la comunicación bidireccional por voz

Se aplica a productos TIC en la que es posible la comunicación entre personas, como por ejemplo, los teléfonos móviles.

Para comprender mejor este capítulo, vamos a tomar como ejemplo una aplicación de videoconferencia. Estas aplicaciones pueden permitir la comunicación por vídeo o sólo por voz.

Este capítulo tiene varios apartados, que son:

6.1 Ancho de banda para voz.

6.2 Funcionalidad de texto en tiempo real

6.3 Identificador 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ídeos

En el caso de que se produzca una comunicación en tiempo real (RTT), el estándar define requisitos sobre la simultaneidad de texto y voz.

Establece también la diferenciación entre el texto de entrada y el de salida, así como la interoperabilidad y el tiempo de respuesta.

Capítulo 7: Requisitos sobre sistemas de vídeo

Este capítulo se aplica a productos TIC que tienen la capacidad de grabar o transmitir vídeos, como un aparato reproductor de discos o una aplicación para reproducir multimedia.

7.1.1 Se debe gestionar adecuadamente los subtítulos para personas sordas.

7.1.2 y 7.1.3 Se debe sincronizar los subtítulos con la pista de audio y preservando el subtítulado existente al transmitir el vídeo.

 7.2.1, 7.2.2 y 7.2.3 Se debe gestionar la audiodescripción para aquellas personas que no ven reproduciendo y sincronizando dicho canal de información.

7.3 Se debe permitir el control a los usuarios para el subtítulo y la audiodescripción.

Capítulo 8: Hardware

Este capítulo de la norma se enfoca a los productos TIC personales que tengan componentes hardware, como los ordenadores, las tabletas y los móviles. Por lo que, quedan excluidos las páginas web y las aplicaciones móviles

Tiene los siguientes apartados, que son:

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: Contenidos Web

Este capítulo se aplica a todo lo relacionado con los contenidos web: sitios web e intranets.

La Norma 301 549 es totalmente compatible con las Pautas de Accesibilidad al Contenido Web 2.0

En la nota 1 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.

Tiene dos apartados:

9.2 Requisitos para el contenido web: incluye todos los criterios de conformidad A y AA (38 en total) de las WCAG 2.0, haciendo referencia directamente a los mismos. Por tanto, el apartado 9.2 tiene 38 subapartados, del 9.2.1 al 9.2.38, uno por cada criterio de conformidad de las WCAG 2.0

9.3 Requisitos de conformidad de las WCAG 2.0: incluye los 5 requisitos de conformidad de las WCAG 2.0 (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)

Capítulo 10: Documentos electrónicos no web

En este capítulo se recogen requisitos que se aplican a documentos electrónicos que no sean páginas web o que no estén incrustados en páginas web.

Algunos ejemplos de documentos son cartas, hojas de cálculo, correos electrónicos, libros, imágenes, presentaciones, EPUB o PDF.

En el apartado 10.2 se establece que deben cumplir con todos los criterios de conformidad hasta el nivel AA de las WCAG 2.0 (38 en total), excepto cuatro criterios:

10.2.20 “Evitar bloques” (2.4.1)

10.2.24 “Múltiples vías” (2.4.5)

10.2.31: “Navegación coherente” (3.2.3)

10.2.32: “Identificación coherente” (3.2.4)

Los apartados en los que deberían incluirse (10.2.20, 10.2.24, 10.2.31, 10.2.32) se mantienen, pero vacíos. De esta manera se mantiene la coherencia de la numeración de los requisitos en los diferentes capítulos. Así, el requisito 9.2.15 (Teclado, equivalente al 2.1.1 de las WCAG 2.0) es igual al 10.2.15 o al 11.2.2.15, independientemente de que se eliminen criterios en sus respectivos listados.

Por otro lado, se añaden dos criterios:

10.2.39 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.2.40 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

En este capítulo se recogen todos los requisitos que se refiere a software que no es web.

En el subapartado 11.2.1 se incluyen los requisitos cuando no se están proporcionando funcionalidades “cerradas”. Se listan todos los criterios de conformidad, y estos son los 38 de nivel A y AA de las WCAG 2.0, pero con varias peculiaridades:

No se referencia directamente al criterio de las WCAG como en el capítulo 9. Esto es así porque incluye las notas “Additional Guidance When Applying Success Criterion xxxx to Non-Web Documents and Software” del documento del W3C Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)

NO se incluyen 6 criterios de conformidad que presumiblemente no aplican al software, como son:

11.2.1.20 “Evitar bloques” (2.4.1)

11.2.1.21 “Titulado de las páginas” (2.4.2)

11.2.1.24 “Múltiples vías” (2.4.5)

11.2.1.28 “Idioma de las partes” (3.1.2)

11.2.1.31 “Navegación coherente” (3.2.3)

11.2.1.32 “Identificación coherente” (3.2.4)

11.2.2 Criterios de conformidad (con funcionalidades cerradas)

En el subapartado 11.2.2 se incluyen los requisitos cuando sí se están proporcionando funcionalidades “cerradas”. En este caso solo se mantienen 12 de los 38 requisitos A y AA de las WCAG 2.0, y se van poniendo en relación con los requisitos definidos en el capítulo 5.

11.3 Interoperabilidad con los productos de apoyo

Cuando el software es una plataforma,

  • la aplicación tiene que usar los servicios de accesibilidad de la plataforma (11.3.2.3)
  • ofrecer información sobre objetos, tablas, valores, etiquetas, jerarquía visual, texto, acciones, etc
  • permitir que los productos de apoyo realicen acciones en nombre del usuario (11.3.2.5 al 11.3.2.17).

 

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.3.2.5 Información del objeto

11.3.2.6 Fila, columna y cabeceras

11.3.2.7 Valores

11.3.2.8 Relaciones de etiquetado

11.3.2.9 Relaciones padre-hijo

11.3.2.10 Texto

11.3.2.11 Lista de acciones disponibles

11.3.2.12 Ejecución de acciones disponibles

11.3.2.13 Seguimiento del foco y de los atributos de selección

11.3.2.14 Modificación del foco y de los atributos de selección

11.3.2.15 Notificación de cambios

11.3.2.16 Modificaciones de los estados y propiedades

11.3.2.17 Modificación de valores y texto

11.4 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.5 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.6 Herramientas de autor

Los requisitos para las herramientas de autor son:

  • deben permitir crear contenido que se ajuste a los requisitos de accesibilidad
  • se debe preservar la información de accesibilidad de los contenidos
  • la herramienta debe proporcionar sugerencias para corregir los problemas de accesibilidad
  • tiene que haber plantillas accesibles (11.6.5)

 

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

Se aborda la documentación de apoyo y los servicios de apoyo.

  • deberá proporcionar información sobre las características de accesibilidad y compatibilidad (12.1.1)
  • deberá ser un documento accesible (12.1.2)
  • deberán informar sobre características de accesibilidad (12.2.2)
  • deberán adaptarse a las necesidades de comunicación de las personas con diversidad funcional (12.2.3)
  • deberán ofrecer documentación accesible (12.2.4)

 

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.

Actualización 2018: v 2.1.2

La norma se actualizó en agosto de 2018 con un nuevo anexo, el anexo D, para el cumplimiento de los requisitos del nivel AAA de las WCAG 2.1.

 

 

Norma Europea EN 301 549: Estructura (Parte 1)

Después de hacer un repaso general sobre la normativa en España, toca hacer un repaso sobre la Normativa Europea sobre accesibilidad web.

  • La anterior versión versión de la norma se pubicó en 2015.
  • Se actualizó en agosto de 2018. Es la v2.1.2. Se actualizó con un nuevo anexo, el anexo D, que abarca los criterios de la triple A. Estos requisitos no son de obligado cumplimiento.

Normativa europea: EN 301 549

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

Sin más dilación, os voy a hablar de la estructura de la Norma Europea de accesibilidad EN 301 549Requisitos de accesibilidad de productos y servicios TIC aplicables a la contratación pública en Europa”.

Estructura de la Norma EN 301 549

En la norma se definen 213 requisitos y 26 recomendaciones.

estructura_EN301549

El estándar comienza con el alcance de la norma y algunas referencias y definiciones y abreviaturas en los tres primeros capítulos.

En el capítulo cuatro se encuentran las declaraciones de prestación funcional, donde se establecen diferentes diversidades funcionales y cómo llevar a cabo con las soluciones adecuadas.

¿Qué son las declaraciones de prestación funcional?

En el contexto de la Norma EN 301 549, hace referencia a la funcionalidad que se requiere para satisfacer las diferentes necesidades de los usuarios.

Este capítulo está dividido por dos apartados:

Apartado 4.1: Cómo cumplir las declaraciones de prestación funcional.

Apartado 4.2: Descripción de las diferentes necesidades de los usuarios y por qué es necesario tenerlas en consideración.

4.2.1 Sin visión. Algunos usuarios son ciegos, por tanto la TIC debe ser posible usarla sin visión. Los audios y los vídeos deben ser de utilidad.

4.2.2 Visión limitada o baja visión. Deben existir posibilidades para los usuarios puedan usar la interfaz y regular los costrastes de color. El audio es otro ejemplo para las personas con baja visión.

4.2.3 Percepción del color. Algunos usuarios son daltónicos, por lo qe se debe tener en cuenta esta dificultad visual. Si los colores constituyen la información fundamental, se debe sustituir por texto.

4.2.4. Sin audición. Hay usuarios que no pueden oír, por los interfaces deben ayudar a las personas sordas.

4.2.5. Deficiencia auditiva. Para estos usuarios es importante tener un audio claro y sin ruido de fondo, y la posibilidad de controlar el volumen.

4.2.6 Capacidad vocal. Algunos usuarios no pueden hablar, por lo tanto las TIC se deben usar sin necesidad de voz. Un ejemplo de ello, sería el uso de teclados.

4.2.7 Manipulación o fuerza limitada. Para los usuarios con problemas motores, con la TIC debe ser posible facilitar su uso con una sola mano. También la manipulación y el habla pueden ayudar a estos usuarios.

4.2.8 Alcance limitado. Los usuarios en silla de ruedas.

4.2.9. Sensibilidad a los destellos. Se deben reducir el número de destellos y de luz.

4.2.10. Problemas cognitivos. Se debe proporcionar características que permitan su uso por usuarios que no puedan entender interfaces complejas. Hacerlo intiutiva y fácil para ese grupo.

4.2.11 Privacidad. El uso de auriculares es un ejemplo de ello.

La norma contiene tres anexos:

 

Una vez explicado el capítulo 4, hablaremos sobre el anexo B, donde se establece la relación entre las declaraciones de prestacion funcional y las necesidades de los usuarios. Es un anexo muy interesante porque te hace comprender el impacto que los problemas de accesibilidad pueden tener en los usuarios finales.

Tenemos en cuenta la tabla siguiente:

Tabla de relaciones de la EN 301 549

Para comprender la tabla, primero hay que saber qué significan las abreviaturas. Estas abreviaturas tratan sobre las necesidades de los usuarios de este capítulo que estamos viendo.

Así es que la 4.2.1 “WV” significa “With vision” (Sin visión) y así sucesivamente cada uno de ellos.

¿Qué grupo de usuarios queda afectado por cada requisito?

Tenemos que tener en cuenta que hay dos relaciones:

P: Relacion primaria

Esto significa que el requisito es compatible con la declaración de prestación funcional de ese grupo de usuarios en particular.

S: Relación secundaria

Esto significa apoyo parcial para la declaración de prestación funcional porque algunos usuarios pueden usar la función en algunas situaciones específicas.

Vamos a analizar la tabla con un ejemplo:

Los requisitos tecnicos se enumeran de manera vertical y las declaraciones de prestación funcional de manera horizontal.

Si vemos este ejemplo, tenemos el requisito que hace referencia al uso del volumen de un auricular privado, la tabla se lee así:

La tabla tiene una P para el soporte primario para el requisito 4.2.1 “WV” (Sin visión). Esto significa que el requisito soporta la declaración funcional para los usuarios que no pueden ver. En otras palabras, si proporcionan la posibilidad de controlar el volumen cumplirá una de las necesidades de los usuarios ciegos.

En el requisito 4.2.5, se marca con S, porque si los usuarios tienen problemas de audición, el volumen de los auriculares es muy importante, por lo tanto, satisface parcialmente esas necesidades. No todos los usuarios usan auriculares, pero si lo hacen el volumen es muy importante.

Continuando con los diferentes capítulos que contiene la norma, se describen los siguientes:

  • Capítulo 5: Requisitos genéricos, que sirven para todas las TIC.
  • Capítulo 6: Requisitos TIC con comunicación bidireccional por voz.
  • Capítulo 7: Requisitos TIC con capacidades de vídeo
  • Capítulo 8: Hardware
  • Capítulo 9: Requisitos sobre contenido web
  • Capítulo 10: Requisitos sobre documentos
  • Capítulo 11: Software no web
  • Capítulo 12: Documentación y servicios de apoyo
  • Capítulo 13: Acceso de servicios de retransmisión o emergencia.

 

A partir de aquí, paso a desarrollar cada uno de los capítulos. Empiezo por el 5 y los demás los dejo para otra entrada para que no se haga demasiado extenso  el post.

Capítulo 5: Requisitos genéricos. Funcionalidad cerrada.

¿Qué es la funcionalidad cerrada?

La funcionalidad cerrada consiste en los que los usuarios no pueden utilizar tecnologías de apoyo propias, (lector de pantallas). Esta situación podría darse por ejemplo, en máquinas de venta de entradas. (tickets).

Para que los dispositivos con sistema de funcionalidad cerrada funcione para todos los usuarios, el sistema debe proporcionar alguna manera para que los usuarios interactúen y perciban la información. Esto significa que el propio sistema debe funcionar con tecnología de apoyo.

Un ejemplo de producto con funcionalidad cerrada sería un cajero automático. Esto implica que debe ser accesible por sí mismo, sin ayudas externas.

Para ello, tendrá que cumplir los siguientes requisitos:

  • Debe permitir su uso sin visión, con la que tendrá salida por voz
  • La salida por voz tiene que tiene que tener relación con la salida visual, para ayudar a los que tengan dificultades visuales
  • También tiene que poder pararse y repetirse cada vez que los usuarios lo necesiten
  • Deberá incluir descripción de elementos no visuales y la narración de vídeos.
  • Se deberá tener especial cuidado con la información personal y con no reproducir contraseñas
  • La salida por voz deberá tener un volumen suficientemente alto para personas con problemas de audición, con posibilidad de reajuste rápido al cambiar de usuario.
  • Es importante que la información esté en el mismo idioma que el contenido mostrado.
  • Debe incluir la información necesaria para que los usuarios sepan que se han realizado las transacciones.
  • Debe incluir un tamaño del texto adecuado, que sirva a las personas con baja visión.
  • Deberá ofrecer alternativas al uso del teclado.

 

Para seguir leyendo sobre la Norma EN 301 549, aquí tienes la segunda parte.

 

 

 

 

 

 

 

 

 

 

Accesibilidad y usabilidad web: Diferencias

Introducción

Me apetecía escribir esta entrada porque me encuentro a gente que me ha preguntado que no sabe muy bien cuál es la diferencia entre la accesibilidad web y la usabilidad web. O que no les queda del todo claro. Hay gente que puede pensar que las dos palabras significan lo mismo, pero no es así.

Estos dos conceptos están muy relacionados pero NO son lo mismo.

Para comprender esto mejor, vamos a establecer una definición sencilla:

  • accesible: que se puede acceder a él
  • usable: que sea fácil de usar

 

Accesibilidad web y usabilidad web: Diferencias

A partir de ahí, hay que plantearse el dilema de ¿accesible/usable para quién?

En realidad no hay una respuesta exacta para resolver esta pregunta porque puede haber casos en los que habrá a quien le resulte “cómodo” acceder y usarlo y otras personas a las que no, y pueda darse el caso de que no se pueda usar.

Por ejemplo, un vídeo con mala calidad y sin subtítulos puede ser díficil de entender, pero si lo reproduces varias veces, al final te enteras de la película. Pero una persona con dificultades auditivas o sorda, por mucho que lo ponga no se entera y no lo entenderá.

Diferencias entre la accesibilidad web y la usabilidad web

La accesibilidad web consiste en hacer accesible todo lo que engloba un sitio web y todas las opciones y funcionalidades que posee. Todas las funcionalidades que posee para todas las personas usuarias.

En el caso de WordPress, aparte de tener nuestro sitio web, también hay que hacerlo con las opciones del escritorio, los widgets y los plugins. Y si hablamos del futuro editor de WordPress, Gutenberg, que se pretende implantar en las próximas versiones, todavía está muy verde y deja mucho que desear y mejorar en cuanto a accesibilidad y usabilidad web.

¿Cómo se pone en práctica la accesibilidad en la web?

Para poner en práctica la accesibilidad web hay que tener presente las Pautas de Accesibilidad al Contenido Web, así como aplicar los Roles ARIA que se usan para hacer contenido accesible para las personas con diversidad funcional.

Pongamos por ejemplo, una empresa de nombre ficticio ACUS, que se encuentra analizando un formulario.

Desde siempre hemos pensado que los formularios se podían realizar de la manera que en la siempre lo hemos hecho, poner los campos con la aplicación de sus atributos correspondientes. Y con el foco de teclado visible, claro.

Pero resulta que en la empresa tenemos un usuario ciego (al cual llamaremos Pepe), que nos comenta que él no puede acceder a los formularios de la web.

Tras conocer la noticia, los desarrolladores (que se llaman Andrés y Antonio), se vuelven locos intentando averiguar a ver de qué manera pueden solucionarle el problema a Pepe.

Pero ahí está la profesional experta en usabilidad, (de nombre Isabel), que les comenta a los desarrolladores que tienen ese problema porque no usan el etiquetado correcto en los formularios.

Si consiste en un problema grave que imposibilita llegar al objetivo a los usuarios, estamos hablando de un problema de accesibilidad. El objetivo de la accesibilidad es que se pueda usar por todas las personas.

Si quieres más información sobre este tema, la explico detalladamente en otras entradas de este blog:

Consejos para llevar a cabo la accesibilidad web

Cómo hacer formularios accesibles

 

¿Cómo llevamos a cabo la usabilidad?

La usabilidad consiste en conocer la experiencia que tiene el usuario cuando navega por el sitio, que nos cuenten las dificultades que se encuentran en el proceso, cuando están realizando una tarea determinada (realizar una compra, una venta, rellenar un formulario de registro…).

Entrando en materia os pongo una frase de uno de los mayores expertos en usabilidad, Steve Krug, del cual ha escrito un libro sobre el tema que es muy interesante y os lo recomiendo como lectura: “No me hagas pensar”.

¿Cuál es el objetivo de todo esto? ¿Qué quiero decir con esto?

Muy sencillo, que no hay que hacer pensar a los usuarios, que hay que ponérselo fácil y cómodo. Que, entre otras cosas, los usuarios que navegan por tu web son lo más importante que hay que en tener en cuenta. ¿Por qué? Porque si no lo tienes accesible ni usable, tu web no sirve para nada. Por muy bonita que esté y tenga un buen diseño, si no es usable, los usuarios no podrán interactuar con ella. Pueden ser posibles clientes potenciales y al no poder interactuar y no tenerlo accesible, no obtienes beneficios. Así de simple.

Por eso es importante saber que la usabilidad va enfocada desde el punto de vista del usuario, así como conocer sus inquietudes, qué puede y no puede hacer, qué piensa, cómo interactúa al realizar determinadas tareas y principalmente, conocer sus problemas. Y con todo esto, intentar buscar las soluciones más adecuadas a sus necesidades.

Siguiendo el ejemplo de la empresa: Andrés y Antonio, después de un intenso día de trabajo,  llegan muy ilusionados a su casa, sabiendo que han aprendido algo nuevo. Y con la ilusión, van y se lo enseñan a su madre. Y la señora al ver el formulario, se encuentra con unos campos con un asterisco en algunas de ellas, en las cuales no sabe qué tiene que hacer. No entiende qué tiene que hacer. Y les pregunta que cómo lo tiene que rellenar. Tras hacer los ajustes pertinentes, comprueban que ya ha entendido cómo hacerlo y procede a rellenarlo sin problemas.

Es decir, en este ejemplo que hemos explicado, hemos mejorado la usabilidad de los formularios.

Para finalizar, el objetivo de la usabilidad es que pueda ser usado fácilmente por un grupo de usuarios concreto. En este caso caso, las personas mayores.

Para que algo sea fácil de usar, es necesario que se pueda usar. Por eso, para un mismo perfil de usuario, usable implica accesible (pero no al revés). O dicho de otra manera, la accesibilidad es condición necesaria (pero no suficiente) para la usabilidad.

Conclusión

Hay que recordar varias cosas importantes.

  • Si algo no es accesible, no es usable.
  • Si algo no es usable, no es accesible.
  • Algo puede ser accesible pero puede no ser usable.

 

Si se da alguna de estas cirscuntancias, tenemos problemas de usabilidad web.

 

Entradas relacionadas:

Usabilidad web: ¿Qué es UI y UX? Diferencias

 

Accesibilidad web: Diversidad funcional motriz

Diversidad funcional motriz

Cuando hablamos de diversidad funcional motriz nos estamos refiriendo a personas que tienen dificultades a nivel físico y que puede afectar a todo: a nivel físico, vista, oído, al movimiento del cuerpo, al habla o a la deglución.

Accesibilidad web: Diversidad funcional motriz

En mi caso, hablamos de una patología llamada Parálisis Cerebral Infantil. Es una patología que afecta a 2 de cada 1000 personas. Esta patología se caracteriza por un trastorno psicomotor. Los problemas psicomotrices están acompañados de alteraciones cognitivas, de comunicación y percepción. Dependiendo de la zona del cerebro afectada se pueden observar desde movimientos involuntarios, espasmos y rigidez en los músculos, así como disfunciones visuales y auditivas.

Clasificación de la Parálisis Cerebral Infantil

Para entender mejor la parálisis cerebral vamos a establecer los diferentes tipos que hay:

Espástica: Es el grupo más numeroso, que se caracteriza por la rigidez en los músculos. Se puede dar hipertonía hiperreflexia e hiperflexión.

Atetósica: Se caracteriza por tener movimientos involuntarios, muecas por dificultades en la cara y torpeza al hablar. Se puede dar afectación de pérdida auditiva.

Atáxico: Son personas que tienen mal equilibrio corporal, muestran inseguridad en la marcha y dficultades en la coordinación y el control de las manos y los ojos.

Mixta: En este caso, es más raro de encontrar casos puros de espasticidad, atetosis o ataxia, lo normal es que se dé una mezcla de todas ellas.

¿Cómo acceden a la web las personas con dificultades motrices?

En el caso de las patologías motrices, como por ejemplo, la parálisis cerebral, hay muchos tipos y diferentes grados dependiendo de la zona afectada. Debido a esto, la persona tendrá más o menos autonomía, pero en la gran mayoría de los casos, las personas con esta patología suelen utilizar dispositivos de apoyo, como por ejemplo:

Licornio: dispostivo que se coloca en la cabeza que ayuda a escribir a las personas que tienen dificultades en las manos. Para usar el licornio debe tener un buen control del cuello para llevar la varilla hasta donde necesite.

Persona utilizando un licornio para el ordenador

Varilla de boca/joystick de boca/barbilla: estas personas usan una varilla para ir pulsando sobre el teclado tecla a tecla para escribir el texto. También lo pueden usar adaptado para las manos.

Varilla de boca, adaptada también para las manos

Tableros de pictogramas: Un tablero de pictogramas sirve para que todas aquellas personas que tienen dificultades del habla, puedan comunicarse a través de los movimientos de los ojos o señalando al icono que representa un sentimiento o la necesidad de la persona en ese momento.

Diversidad funcional motriz:Tablero de pictogramas

¿Qué son los sistemas de comunicación aumentativa y alternativa?

Los sistemas aumentativos complementan el lenguaje oral, cuando por sí solo no es suficiente para mantener una conversación.

Los sistemas alternativos sustituyen al lenguaje oral cuando éste no es comprensible o está ausente.

Los sistemas de comunicación aumentativa y alternativa varían en función de las características e intereses de la persona y su entorno.

Aquí os dejo algunos ejemplos de este tipo de ayudas técnicas para estos usuarios.

  • Plaphoons: Es un sistema de comunicación por pictogramas, donde pueden expresar su mensaje o lo que les dé la gana de forma totalmente independiente. También contiene opciones para usar un conmutador de barrido automático. También se puede usar para la lecto-escritura o con teclado alfabético.
  • Irisbond: Sistema de tecnología eyetracking avanzado (sistema de comunicación con la mirada), que no sólo usan personas con parálisis cerebral, sino también personas con otras patologías motrices como la Esclerosis Lateral Amiotrófica, la Esclerosis Múltiple, etc.
  • GoTalk 9+ Es otro sistema de comunicación.

 

Conmutadores y pulsadores de presión y soplo: El conmutador simple de soplido o aspiración consiste en un sensor que permite detectar presiones positivas (soplido) o negativas (aspiración) ejercidas mediante la boca.

También existen otros conmutadores que se activan por el tacto, por la mano o por el pie.

Teclado de una sola mano: Estos teclados son teclados adaptados para personas que sólo pueden usar una sola mano.

Teclado de una sola mano

Teclado en pantalla: El teclado en pantalla es necesario para todas aquellas personas que por problemas de movilidad en las manos y tengan que acceder a él desde teclado.

Acceso por pulsador: Normalmente, funcionan por barrido con un pulsador para acceder a la casilla del pictograma deseado. O también si se seleccionan las teclas directamente.

 

Uso de audios y vídeos

Si la afectación se produce a nivel auditivo tenemos que hablar de diversidad funcional auditiva.

Si las personas están escuchando un audio y ese audio no dispone de transcripción: Para llevar a cabo la accesibilidad hay que escribir la transcripción del audio para que las personas con dificultades auditivas puedan disfrutar de su contenido.

Con los audios con contenido multimedia, es decir, los vídeos, también hay que tener en cuenta la accesibilidad web añadiendo subtítulos al contenido que está visualizando. También es necesario que tenga un botón para dar la opción a los usuarios de abrir o cerrar los subtítulos. En WordPressTV si vas a visualizar un vídeo no aparece esa opción, lo cual es un problema de usabilidad. Los subtítulos han de contener dos líneas como máximo y tener entre 35 o 40 caracteres.

En algunos casos, debido al grado de afectación de las personas sobre todo, al escribir por un teclado y la espasticidad que genera, estas personas se pueden cansar. Por lo que es recomendable un sistema de reconocimiento de voz para facilitarles las cosas.

Sistema de reconocimiento de voz

Uso del teclado

Debido a la gran complejidad de esta patología y sus diferentes grados de afectación, hay personas que por sus movimientos involuntarios y el control de los movimientos tienen dificultades para usar el ratón. Por esto, es necesario, que tengamos siempre la opción de acceso por el sitio web a través de teclado, y que tenga el foco visible, tal y como indica el criterio 2.4.7 de las WCAG 2.0

Muchas personas con esta patología están afectados intelectualmente y hacen uso de los iconos para orientarse por la web.

Uso de ratones

Ratones virtuales: Son programas informáticos cuyas opciones de movimiento y funciones de clic aparecen en pantalla. Suelen utilizar un pulsador y un sistema de barrido para facilitar el uso del programa de comunicación.

Ratones de cabeza: Los movimientos de la cabeza realizados por el usuario se transforman en movimientos del puntero. De esta forma seleccionan directamente en la pantalla: la letra, la palabra, el pictograma, etc., según qué sistema se esté utilizando. Algunos ratones de cabeza necesitan una cámara web para su uso.

Control del ratón por el iris: Este sistema permite a personas con grandes dificultades de movimiento, controlar el puntero del ratón con la mirada.

Ratón controlado por pulsadores: Cada conmutador realiza un tipo de click, izquierdo y derecho. El ratón sigue conservando toda su funcionalidad habitual

Diveridad funcional motriz: Ratón por pulsador

Cómo comunicarse con personas con parálisis cerebral

  • Si hablas en su presencia, no le des la espalda y ten en cuenta que puede entender todo lo que dices.
  •  Permanece atento/a a sus gestos, ya que quizás quiera comunicarte algo o usar sistemas alternativos de comunicación.
  •  Cuando no sepas qué hacer o cómo hacerlo, pregúntale directamente. Te dirá como quiere ser ayudada. Pídele opinión acerca de las cosas.
  •  Si no entiendes lo que te dice, pídele que lo repita las veces que haga falta. Como todas las personas, lo que desea es ser comprendida.
  • En una conversación, dale tiempo para acabar sus frases y razonar sin interrumpirle.
  • Háblale mirándola a la cara cuando quieras decirle algo, no se lo digas a través de terceros. Sabrá cómo responderte, incluso instará a su acompañante para que te conteste si es necesario, pero con su consentimiento.
  • Deja que pueda adoptar sus propias decisiones, esto facilitará que pueda escoger y tomar iniciativas. Ofrécele solo la ayuda necesaria y complementaria.
  • Piensa que estás ante una PERSONA y, a partir de ahí, actúa como te gustaría que lo hicieran contigo. Procura no hacer etiquetaciones y evita que no te incluyan a ti en ninguna.
  • Ten en cuenta que su escala de valores puede ser distinta. A veces lo que para ti es una tarea rutinaria para ella es todo un logro. Háblale, por ello, de sus capacidades, no de sus limitaciones.
  • Comunícate con esa persona según su edad cronológica y mental. No la trates como a un niño pequeño.