Hola, soy Ester Serna Berná, trabajo como desarrolladora web y consultora en accesibilidad en el Taller Digital de la Universidad de Alicante. En este vídeo sobre accesibilidad, que forma parte del curso “Introducción al desarrollo web”, voy a detallar los 4 elementos más problemáticos que encuentran las personas que acceden a los contenidos web con un lector de pantalla y te voy a proponer algunas soluciones para que tú como desarrollador web puedas evitarlos.

Antes de dar paso a la presentación, puedes contactar conmigo a través de mi correo electrónico esterser@gmail.com
, a través de mi cuenta en Twitter @estersernaberna o a través de mi perfil en Linkedin. Además, puedes visitar el sitio web donde trabajo actualmente, www.eltallerdigital.com
, del que soy responsable del mantenimiento de la marca AENOR N en accesibilidad TIC, que asegura el cumplimiento de la Norma UNE 139803 Requisitos de accesibilidad para contenidos Web.

En mayo de 2012, el WebAIM, un centro dependiente de la Utah State University dedicado a la accesibilidad web, realizó por cuarta vez una encuesta sobre el uso de los lectores de pantalla. En ella se realizó la siguiente pregunta a los participantes: ¿Qué elemento es el más problemático en una página web? El resultado fue el que muestra el siguiente gráfico de barras. Voy a destacar los 4 principales problemas de acceso, que son los que os voy a presentar en detalle.

El primer problema que presenta mayor dificultad de acceso a los contenidos a los usuarios con lectores de pantalla es la presencia de contenido Flash inaccesible. El segundo, y muy de cerca, los captcha. El tercero, los enlaces o botones que no tienen sentido fuera del contexto en el que se encuentran. El cuarto, las imágenes sin un texto alternativo que las describa o un texto alternativo inapropiado.

El primer problema que presenta mayor dificultad de acceso es el uso de la tecnología Flash de forma inaccesible. Una de las preguntas más comunes entre los desarrolladores web es si se puede usar Flash en nuestros sitios web de forma que sigan siendo accesibles. La respuesta es sí, pero con prudencia; a mí me gusta ser cautelosa en el uso del Flash. Mi consejo es que no hagas tu sitio web 100% en Flash y no desarrolles elementos importantes como los menús de navegación en Flash.

¿Cómo usamos Flash de forma accesible? Tenemos dos opciones: aplicar las directrices de accesibilidad de forma nativa, y por tanto no necesitaría alternativa en HTML, o, por el contrario, si nuestro objeto Flash no es accesible, hemos de proporcionar una alternativa en HTML que sí lo sea. En la dirección que se muestra en la diapositiva podéis encontrar 36 técnicas específicas para el contenido Flash donde se explica cómo implementar Flash accesible de forma nativa.

En esta página, antes de detallar las 36 técnicas, hace tres consideraciones especiales que me gustaría comentar:
La primera es referente al titulado de páginas; con el fin de cumplir con el criterio 2.4.2, el contenido Flash debe estar integrado en una página HTML que posea un título de página a través del elemento <title>.
La siguiente consideración es en referencia al idioma de la página, criterio de conformidad 3.1.1. El lenguaje del contenido del Flash hay que especificarlo mediante el atributo lang. En el ejemplo que se muestra en la diapositiva, el idioma del documento es español y el objeto Flash está en el mismo idioma, por lo que no hemos de volver a especificarlo a través de la etiqueta object. En este ejemplo se ha especificado el idioma en el Flash embebido. De esta forma podemos incluir varios objetos Flash con diferentes idiomas en una misma página.
La tercera consideración es en referencia al idioma de las partes, criterio de conformidad 3.1.2. Actualmente no es posible definir dentro del archivo SWF los cambios de idioma que puedan ocurrir en el contenido del mismo.

El detalle de las 36 técnicas en esta presentación es inviable, por lo que aquellos de vosotros que queráis insertar un objeto Flash os animo a que visitéis esta URL para que podáis profundizar en ellas.

El segundo problema que presenta dificultad de acceso a los usuarios de lectores de pantalla es el uso de captcha. En la diapositiva se muestra el test más habitual, que consiste en incluir en una imagen letras o palabras distorsionadas para que el usuario las reconozca y las introduzca por teclado. Esto se hace para evitar que accedan robots de spam u otro tipo de software automático a zonas restringidas de nuestro sitio web. El problema es que esta forma de incluir los captcha crea una barrera de acceso a los usuarios que no puedan ver la imagen.

Modalidades de captcha: los captcha pueden ser visuales, en ellos se muestra una imagen con las letras o palabras distorsionadas que hemos de introducir. También pueden ser auditivos, donde se pronuncia la palabra que hay que reconocer sobre un ruido de fondo. O pueden ser lógicos, en los que se realiza una pregunta lógica, como por ejemplo "¿cuántas son dos más dos?" o "¿cuál es la tercera palabra de: Hoy está lloviendo?"

¿Cómo programamos un CAPTCHA de forma accesible? En primer lugar, hemos de proporcionar una alternativa textual que describa su propósito. Si observamos el ejemplo, en el texto alternativo se ha incluido la acción que debemos realizar, es decir, “introduzca las letras de la imagen”. Además de la alternativa textual que lo identifique, tenemos que proporcionar otro captcha con el mismo propósito, pero en una modalidad sensorial diferente; en la captura del captcha que aparece en la diapositiva se ha incluido como alternativa la modalidad auditiva.

Cada modalidad sensorial usada por separado crea problemas de acceso: los captcha visuales crean una barrera de acceso a las personas que no ven, los auditivos son inaccesibles para aquellas personas que no puedan oír, y los lógicos pueden presentar problemas para usuarios con problemas cognitivos, ya que por ejemplo pueden no entender el idioma. Por tanto, se considera suficiente usar dos de estas modalidades. Aquellos que queráis profundizar más sobre este tema, podéis ver en este enlace varios vídeos realizados por el profesor Sergio Luján Mora sobre los captcha.

El tercer problema de acceso que encuentran los usuarios con lectores de pantalla son los enlaces o botones que no tienen sentido fuera del contexto. Tal y como vimos en el vídeo sobre tipos de discapacidad, una de las estrategias de interacción de las personas que usan lectores de pantalla es el uso del tabulador para recorrer los enlaces del sitio web.

Si realizamos enlaces como el del ejemplo y navegamos con el tabulador, el lector de pantalla nos leerá “pinche aquí”. Con esta información no podemos saber que en el destino del enlace hay más información sobre accesibilidad web.

¿Cómo se define el propósito de los enlaces? El propósito de cada enlace puede ser determinado con solo el texto del enlace o a través del texto del enlace sumado al contexto del enlace determinado por software, excepto cuando el propósito del enlace resultara ambiguo para los usuarios en general. Debéis tener en cuenta que enlaces con el mismo destino tienen que tener la misma descripción, es decir, el mismo texto del enlace, y enlaces a diferentes destinos deben tener diferentes descripciones.

A continuación, se detallan algunos de los criterios de éxito que deberemos cumplir para que nuestros enlaces cumplan con su propósito y sean contenidos accesibles. Tenemos que usar el propio texto del enlace para describir su propósito; por ejemplo, en la frase que se muestra en el ejemplo, el texto del enlace es “periodo de la Edad Media”, que describe su propósito.

En el caso de una web que contiene una colección de nuevos artículos y los enlaces de acceso al contenido informativo son todos iguales del tipo “leer más”, hemos de proporcionar una descripción adicional al texto del enlace. Para ello podemos usar el atributo title para complementar la información, poniendo por ejemplo el título del artículo al que hace referencia el destino del enlace. Otra opción es usar las hojas de estilo para ocultar parte del texto del enlace. De esta forma enviamos parte del contenido del enlace fuera de la pantalla, por lo que visualmente no lo vemos, pero sí lo leerán los lectores de pantalla.

Si el texto del enlace no es suficientemente descriptivo, pero sí lo es la frase en la que se encuentra, hemos de proporcionar el enlace al final de la misma, ya que mediante una combinación de teclas con el lector de pantalla, los usuarios son capaces de leer el párrafo actual, como por ejemplo la frase que se muestra en la diapositiva.

El cuarto problema de acceso es la inclusión de imágenes sin un texto alternativo que las describa o un texto alternativo inapropiado. Podemos clasificar las imágenes en dos grandes grupos: las imágenes decorativas, que las incluimos en nuestros textos pero que no transmiten información, y las imágenes que transmiten información relevante.

Para las imágenes decorativas que no transmiten información hemos de incluir un texto alternativo, pero éste ha de estar vacío. En las imágenes no decorativas que transmiten información relevante, podemos encontrarnos con imágenes que no posean información textual, como la que aparece en la diapositiva, que transmite la idea de advertencia o importancia; por lo que hemos de proporcionarle un texto alternativo: "¡Importante!"

En las imágenes que poseen información textual, hemos de proporcionar como alternativa textual el texto que aparece en ellas, como se realiza en el ejemplo. En aquellas imágenes que funcionan como enlace, pondremos como alternativa textual la función que desempeña. Si os fijáis en el ejemplo, no he puesto como alternativa textual “impresora”, sino la función de imprimir.

Por otro lado, no hemos de ser redundantes. Es decir, si tenemos como se muestra en el ejemplo el icono de la impresora y además en texto hemos incluido la acción, ahora el texto alternativo lo pondremos vacío, sino el lector de pantalla leerá dos veces "Imprimir". Fijaros que el enlace abarca todo: la imagen y el texto; separarlo como se muestra en el siguiente código sería incorrecto, ya que podría generar confusión.

Los fallos más comunes son: usar alternativas inapropiadas que no proporcionan la misma información o función, como por ejemplo usar nombres de archivos, textos de relleno o genéricos como “Foto” o “Imagen”, etc. Otro fallo muy común es no actualizar las alternativas textuales cuando cambia el contenido no textual; por ejemplo, si tenemos una imagen con información meteorológica, la alternativa textual debe variar a la vez que la imagen.

La inclusión de alternativas textuales se aprende en buena medida con la teoría y otra con la práctica, ya que hay multitud de casos que se os presentarán. Por ello os voy a dejar como referencia un par de páginas para aquellos que estéis interesados y podáis ampliar sobre este problema en concreto. Los casos que os he presentado son los más básicos, pero hay muchos más, como cuando insertamos un gráfico complejo, un objeto o applet, etc.

Recuerda que este vídeo forma parte del curso “Introducción al desarrollo web”, que está disponible en la dirección idesweb.es.

Muchas gracias por vuestra atención.