Emmanuelle Gutiérrez y Restrepo

1.- No crees textos alternativos verbosos

El autor dice:

A menudo los desarrolladores de contenidos web accesibles insertan demasiado texto en los atributos alt de las imágenes, con la esperanza de que esto ayudará a los usuarios de lectores de pantalla. El texto en los atributos alt de las imágenes que transmiten información debería ser corto y sucinto, y contener ni más ni menos información que la que hay en la imagen.

Las imágenes decorativas deberían contener siempre un atributo alt nulo, ó alt="", de manera que sean ignoradas por los lectores de pantalla. Asignando un texto al atributo alt que no aporte ningún valor real se le dificultará el manejar la página a los usuarios de lectores de pantalla al enviársele un montón de contenido innecesario.

Lo que no dice es que:

• La principal razón para que se pida que los textos alternativos sean cortos y sucintos estriba en la comodidad de los usuarios de líneas braille (Ver el excelente artículo de Carmen Bonet sobre «El Braille y el placer de la lectura»), porque la línea braille más extensa comprende 80 caracteres, por eso algunas herramientas de revisión de la accesibilidad se toman el trabajo de revisar la extensión y avisan cuando ésta excede de los 80 caracteres (Ver, por ejemplo, CynthiaSays).
• Evidentemente los usuarios de lectores de pantalla son objetivo de los textos alternativos y, evidentemente, no debemos marearles con textos muy extensos, pero es que, además, el texto alternativo no tiene como función describir las imágenes, para eso existe el atributo longdesc.
• Que los textos alternativos no tienen como misión facilitar la vida sólo a los usuarios de lectores de pantalla, también son importantes para quienes navegan sin descargarse las imágenes, como los usuarios de banda estrecha y los de dispositivos móviles que no quieren pagar un dineral a su compañía de teléfonos.
• No siempre es posible limitarse a ochenta caracteres, especialmente cuando utilizas determinados idiomas. Pero esta es desde luego una recomendación a seguir, en la medida de las posibilidades.

2.- No uses caracteres aleatorios para separar enlaces

El autor dice:

Una de las directrices menores de la accesibilidad dice que los enlaces adyacentes deben separarse con un caracter no enlazado. La razón para que esta directriz exista es que algún navegador muy antigüo presenta problemas con los enlaces adyacentes, por lo que terminaba haciendo que todos los enlaces adyacentes apuntaran a la misma página.

Esta pauta no es ya relevante pero a menudo puede provocar que los desarrolladores de webs accesibles inserten caracteres invisibles (generalmente barras verticales) entre los enlaces. Desafortunadamente, cada barra vertical es anunciada a los usuarios de lectores de pantalla como "barra vertical", lo que por supuesto no tiene sentido y hace difícil para esos usuarios el manejar la página.

Lo que no dice es que:

• El problema persiste para los usuraios de lectores de pantalla. No porque modifiquen los enlaces y acaben apuntando todos a la misma página (cosa de la que no había oído hablar jamás) sino porque la aplicación no encuentra ningún indicador para hacer una pausa entre un enlace y otro, con lo que acaba leyéndolos como si se tratara de una frase completa y entonces el usuario no pude determinar el punto en el que tiene que activar un determinado enlace. Recientemente se ha comentado un caso en una de las listas de tiflotecnología en español. Lamentablemente no recuerdo en cuál de ellas y ni el caso exacto, pero lo que sí recuerdo, y por eso me llamó la atención, es que se trataba de un usuario de una versión actual del lector de pantalla más usado.
• Tampoco indica cuál es el modo correcto de marcar los enlaces adyacentes y a la vez evitar el usar caracteres imprimibles para separarlos. Porque, efectivamente, el escuchar la existencia del caracter separador puede llegar a ser molesto. Pero la solución no es dejar de incluir esos caracteres sin más, la solución pasa por marcar esos enlaces adyacentes, que por serlo están relacionados, como elementos de lista y utilizar la hoja de estilos para disponerlos uno al lado del otro. Así, los lectores de pantalla contarán con elementos para diferenciar cada enlace y podrán hacer las pausas correspondientes tras cada uno.

3.- No insertes texto en campos de formulario vacíos para simplificarlos

El autor dice:

Otra antigüa y obsoleta pauta establece que todos los campos de formulario vacíos deberían tener texto por omisión en ellos. Esta pauta existe debido a que los lectores ee pantalla muy antigüos no siempre eran capaces de interactuar con los campos vacíos.

Los principales lectores de pantalla ahora son capaces de interactuar con campos vacíos (y lo hacen desde hace algún tiempo) de manera que podemos ignorar esta pauta con tranquilidad y no insertar texto inutil en los campos vacíos. De hecho, a menudo los lectores de pantalla no anuncian estos textos por omisión de manera que el usuario puede introducir texto junto al texto por omisión sin darse cuenta.

Lo que no dice es que:

• El objetivo de este punto no es sólo atender a los usuarios de algunos lectores de pantalla, sino también a las personas con algunas deficiencias cognitivas para las que ese texto por omisión les clarifica qué es lo que tienen que escribir en el campo. Es verdad que puede ocurrir que algunos usurios añadan al texto por omisión el que ellos quieren enviar, pero para eso hay técnicas de scripting que permiten eliminar ese texto por omisión en cuanto el usuario pone el cursor en el campo.
• Si bien es verdad que las últimas versiones de los lectores de pantalla manejan bien los campos vacíos, aún existen usuarios de versiones anteriores de esos lectores de pantalla y de líneas braille que dan problema.
• Cierto es que probablemente este requisito no se mantenga en la nueva versión de las WCAG (Directrices de Accesibilidad para el Contenido Web), pero puesto que el hacerlo no supone un fallo de accesibilidad, si nos preocupan los usuarios de tecnologías antiguas (que deben preocuparnos) seguiremos incluyendo caracteres por omisión en los campos vacíos utilizando las técnicas precisas para evitar problemas de usabilidad, al menos hasta que estemos seguros de que los lectores de pantalla antiguos han dejado de existir.

4.- No utilices atajos de teclado

El autor dice:

Podemos asignar teclas de acceso a cualquier enlace o control de formulario para proporcionarles un atajo mediante el teclado. En teoría esto parece una gran idea ya que los usuarios de lectores de pantalla y los usuarios de teclado podrán activar fácilmente enlaces clave desde cualquier lugar de la página.

Sin embargo no deberíamos usar atajos de teclado pues pueden invalidar los atajos definidos para del lector de pantalla, e inutilizar su funcionalidad. El otro problema con los atajos de teclado es que no existe una convención de manera que los pcoso sitios que los usan lo hacen de cualquier manera. Es bastante poco probable que los visitantes gasten tiempo en acostumbrarse a los atajos particulares de cada sitio web.

Lo que no dice es que:

• No hay lector de pantalla que no permita al usuario decidir en qué momento quiere utilizar los atajos del lector y en cuál los de la aplicación o web que está utilizando. Es decir, en ningún caso se inituliza la funcionalidad del lector. (Quizás aquí el autor ha confundido "agente de usuario" con este tipo concreto de agentes, pero el término en realidad se refiere tanto a lectores de pantalla como a navegadores y otros tipos de aplicación).
• Es verdad que puede generarse un conflicto con los atajos predefinidos para algunos navedores. Pero también es verdad que existen técnicas para evitar dicho conflicto y que los navegadores que aplican las directrices de accesibilidad para agentes de usuario (UAAG), cosa que deberían hacer todos, permiten al usuario decidir en qué momento quieren aplicar los atajos de la página y en cuál los del navegador e incluso definir atajos de teclado propios para cualquier sitio web.
• Si bien en la futura versión de las WCAG los atajos de teclado no serán un requisito, es decir, no serán obligatorios, sí serán una técnica aconsejable.
• En cuanto al supuesto problema de que los usuarios no vayan a gastar tiempo en acostumbrarse a los atajos definidos en nuestro sitio web, es que no hace falta. Existen técnicas para mostrar a los usuarios de atajos de teclado cuáles puede usar en nuestra página (mediante la hoja de estilos), para que no tenga que aprenderlos, y por otra parte los navegadores como Opera, por ejemplo, también facilitan la posibilidad de obtener el listado de atajos de manera tan sencilla como pulsando las teclas "Mayúsculas"+"Escape" y a partir de ahí bastará con pulsar las teclas definidas como atajo en la página.

5.- No utilices el atributo summary en una tabla (a menos que realmente agregue información)

El autor dice:

El atributo summary puede insertarse en cualquier tabla en HTML y esencialmente vale para resumir en qué consiste la tabla. Los lectores de pantalla leen en voz alta el valor de summary antes de leer la tabla, proporcionando de esta manera un resumen del contenido de la tabla antes de que se escuche la tabla completa.

El resumen de la tabla debe omitirse en las tablas usadas para disponer el contenido (maquetar). Los sitios web que utilizan la disposición mediante tablas tienen a veces un atributo summary con el valor "tabla para maquetar", lo que por supuesto no añade ningún valor en absoluto.

Incluso con las tablas que presentan datos tabulares, el resumen de la tabla es necesario sólo si la información que hay en la página sobre la tabla es insuficiente (lo que no suele ser el caso).

Lo que no dice es que:

• El objetivo del atributo summary es proporcionar a los usuarios que no ven la tabla información sobre cómo están dispuestos sus contenidos, especialmente cuando las tablas son complejas y tienen varios niveles de encabezado o hay tablas anidadas.
• Por principio no deben usarse tablas para disponer el contenido. Pero si se usan, el atributo summary no es preceptivo pero puede ser útil en algunos casos. Evidentemente no limitando su contenido a indicar que se trata de una tabla usada para maquetar, sino indicando la disposición de los elementos en ella. Pero por regla general se recomienda que el atributo summary permanezca nulo si se trata de una tabla usada para maquetar. En la nueva versión de las WCAG se explica que el atributo summary nulo facilita la transparencia de la tabla y se califica de "aceptable", pero no es un requisito.
• El que en el resto de la página se proporcione información sobre la disposición de los contenidos de una tabla, no garantiza que el usuario obtenga esa información, porque es posible que el usuario haya llegado directamente al punto de inicio de la tabla y si es un usuario de lector de pantalla y existe el resumen de la tabla podrá escucharlo. Generalmente, en los documentos se incluye información, explicaciones, sobre el contenido de las tablas después de la tabla, porque la mayoría de los lectores del documento ven y, por tanto, leerán la tabla, no necesitan una interpretación de la disposición de los elementos porque ésta les es dada visualmente. Pero si el usuario es ciego o sordo-ciego, necesita esa información que los demás percibimos con los ojos.

6.- No te olvides del contenido

El autor dice:

La manera en que se estructura el contenido en cualquier sitio web es una parte enormemente importante de la accesibilidad. Un sitio web puede estar perfectamente codificado y conformar los más altos estándares, pero si su contenido está pobremente estructurado, entonces el sitio puede, desde dificultar hasta imposibilitar el acceso a algunos usuarios con necesidades especiales.

Existen una serie de consideraciones importantes en cuanto a la accesibilidad del contenido, entre las que se encuentran:

• Carga frontal del contenido de manera que cada párrafo comience con su conclusión.
• Asegurarse de que el contenido ha sido dividido en bloques de información manejables con subtítulos descriptivos.
• Utilizar listas siempre que sea apropiado
• Asegurarse de utilizar un lenguaje claro y sencillo

En este punto estamos completamente de acuerdo

7.- No te preocupes demasiado por las declaraciones de accesibilidad

El autor dice:

Muchos sitios web intentan ofrecer una gran accesibilidad creando larguísimas declaraciones de accesibilidad que ellos creen que serán útiles. Generalmente estas páginas contienen información sobre las características de accesibilidad del sitio, cómo ampliar el texto, etc.

En realidad, las usuarios con discapacidad raramente miran estas declaraciones de accesibilidad. Como los usuarios de la web, nosotros no intentamos consultar la "ayuda" en ningún sitio. En vez de ello, tropezamos en nuestros intentos de conseguir nuestro objetivo. Aunque no hay nada incorrecto en crear una página de declaración de accesibilidad, no hay necesidad de dedicarle mucho tiempo pues no será usada realmente.

Lo que no dice es que:

• Siempre he dicho que parte de la responsabilidad sobre la accesibilidad de un sitio web radica en el usuario. Los usuarios, incluso los usuarios con discapacidad suelen desconocer las opciones de configuración, de personalización, de su sistema operativo, del navegador que usan y hasta de la ayuda técnica que usan. Por tanto, es conveniente que exista un espacio en el que se le ofrezca la información necesaria para que pueda sacar el mayor partido posible al uso de la web. Por eso se creó la sección de personalización en el sitio del SIDAR, para que los sitios web puedan apuntar a las páginas en las que se informa al usuario sobre estas cuestiones y no tengan que repetir su contenido, que por otra parte, debe ir cambiando con el tiempo según evolucionan las tecnologías. Los desarrolladores pueden evitar el tener que redactar páginas extensas sobre características de accesibilidad, contribuyendo a que esa sección sea lo más completa y actualizada posible. Así sólo tienen que enlazar con sus apartados.
• En este momento las declaraciones de accesibilidad, la indicación de conformidad con un nivel de accesibilidad u otro, en la mayoría de los sitios, sirven de bien poco, pero esperamos que en un futuro muy próximo resulten realmente útiles. Y lo serán si se hacen siguiendo las técnicas semánticas. La Fundación Sidar espera lanzar dentro de este año un par de proyectos que permitirán sacar partido de las técnicas de la web semántica para mejorar la localización de contenidos accesibles y para mejorar el modo en que se hacen las declaraciones de conformidad y su calidad.
• Es cierto que los usuarios no suelen mirar la ayuda o las páginas sobre la accesibilidad de los sitios. Y realmente no debería ser necesario que existieran esas páginas de ayuda o de explicación sobre las características de accesibilidad. Existen métodos para facilitar información puntual al usuario, pero éstos no son suficientes, al menos no para todos los tipos de usuario.

8.- No te agobies por los acrónimos y las abreviaturas

El autor dice:

Declarar si algo es un acrónimo o una abreviatura es fácil de hacer en HTML, sólo hay que usar los elementos <acronym> o <abbr>. La expansión completa del acrónimo o abreviatura puede entonces ampliarse en el seno del marcado.

Los lectores de pantalla no soportan estas etiquetas de manera que no proporcionan ningún beneficio a esos usuarios. Los usuarios que se benefician son los que ven, usuarios de ratón, pues cuando ponen el puntero del ratón sobre esos elementos la expansión completa del acrónimo o de la abreviatura aparece como una "tooltip". Esto puede, ciertamente, verse como una mejora de usabilidad pero realmente no cuenta como un beneficio para la accesibilidad.

Lo que no dice es que:

• No es cierto que los lectores de pantalla no soporten estas etiquetas, al menos no desde hace algunos años. Ocurre en muchos casos, nuevamente, que no todos los usuarios conocen su ayuda técnica suficientemente bien y no saben cómo configurarla para que les lea el valor del atributo title en vez del texto en pantalla del acrónimo o abreviatura. Existe una página de prueba y una de resultados, que sirve de base al artículo «Abreviaturas vs. Acrónimos»
• La presentación de la "tooltip" hoy en día, a partir de la versión 7 de Internet Explorer, la encontramos en todos los navegadores, porque así debe ser, los navegadores siempre deben presentar en una "tooltip" el valor del atributo title. Hace algunos años esto no ocurría de manera generalizada, como puede verse en el artículo previamente mencionado. Pero los navegadores como Opera, Flock o Firefox; además de eso destacan gráficamente las abreviaturas y acrónimos añadiéndoles un subrayado de puntos. Esto beneficia, efectivamente, a los usuarios que ven, pero no se trata de una simple cuestión de usabilidad, se trata de un incremento de la accesibilidad. si por ella entendemos que el objetivo es facilitar al usuario la comprensión e interacción con los contenidos del sitio de manera eficiente, eficaz y satisfactoria. Y es que entre los usuarios puede haber personas que no dominen el idioma en el que está escrito el contenido o que tengan dificultades de lectura o aprendizaje, y para ellos es especialmente útil el poder "recordar" el significado de las abreviaturas y acrónimos que haya en la página.
• Así que conviene que nos preocupemos por marcar apropiadamente las abreviaturas y los acrónimos, incluso conviene que nos preocupemos por la posibilidad de que nuestro visitante sea usuario de Internet Explorer y nos aseguremos, mediante la hoja de estilos, de proporcionar un modo de destacarlas visualmente y de que pueda ver fácilmente el valor del atributo title.

9.- No cambies el orden de tabulación (A menos que tengas una buena razón para hacerlo)

El autor dice:

El atributo tabindex puede usarse para cambiar el orden de tabulación en la página, pero raramente es necesario. El orden de tabulación por defecto usualmente es perfectamente lógico de manera que no necesita ser cambiado.

Los usuarios de lectores de pantalla y de teclado tabulan a través de los enlaces y controles de formulario en el orden en que están localizados en el código fuente HTML. Dado que los usuarios tabulan dentro de cada sección aproximadamente desde la parte superior izquierda a la parte inferior derecha (que es lo que quieren) entonces el orden de tabulación es perfectamente adecuado.

Aquí también concuerdo plenamente :-). Si el orden de los contenidos en el código fuente es el mismo de la presentación, es innecesario indicar un orden de tabulación. ¡Pero es que las Directrices de accesibilidad nunca han pedido que se indique el orden de tabulación si no es imprescindible!

10.- No olvides escuchar con un lector de pantalla

El autor dice:

Mientras estas creando tu sitio web accesible, no olvides probar las páginas según las vas creando. En particular, querrás escucharlas con un lector de pantalla para revisar las características de accesibilidad que vas implementando según lo planeado.

Por ejemplo, si insertas texto invisible, para ayudar a los usuarios de lectores de pantalla, utilizando display:none; te darás cuenta de que no será leído en voz alta. Los lectores de pantalla ignoran los textos que tienen asignado este comando de CSS, de manera que, en vez de ello, posiciona los textos fuera de la pantalla.

Lo que no dice es que:

• Por supuesto que conviene ir comprobando la accesibilidad según se van creando las páginas, y por supuesto que es importante escucharlas utilizando no uno, sino varios lectores de pantalla y navegadores parlantes. Porque no todos los agentes de usuario funcionan igual. Lamentablemente, como hemos comentado, no todos aplican los estándares, las directrices de accesibilidad para agentes de usuario, por lo que no todos reaccionan de la misma manera ante los mismos elementos.
• Por otra parte, también cabe decir que, no basta con la revisión que pueda hacer el desarrollador utilizando un lector de pantalla, a menos que él mismo sea usuario habitual de esas aplicaciones. Porque ni la velocidad, ni las estrategias de adaptación que tienen las personas con discapacidad en el uso de la web pueden ser bien emuladas por un usuario ocasional de ellas.
• Y en cuanto a las técnicas para ocultar textos, lo que no dice y no suelen decir quienes proponen "novedosas técnicas" es que éstas resultan perfectamente inútiles para algunos usuarios. Por ejemplo, la técnica de ocultar el texto desplazándolo fuera de la pantalla, vale para los usuarios ciegos o sordociegos, pero no vale de nada si ese texto no aparece visualmente en pantalla en el momento de recibir el foco, cuando se trata de usuarios de lectores de pantalla o de teclado que sí ven. Es más, producirá confusión en ellos.
• Y no olvidemos usar también al menos dos herramientas de revisión de la accesibilidad, combinadas con revisión hecha por usuarios finales. Porque tanto las herramientas como los usuarios pueden ver cosas que a nosotros, como diseñadores o desarrolladores, se nos escapan por estar directamente implicados.

Si al leer esto te surge alguna duda sobre cualquier técnica o punto tratado, por favor, revisa el histórico de la lista ACCESOWEB o plantea tu duda allí.

Blogged with Flock

Tags: accesibilidad, ayudas técnicas, navegadores, usabilidad, web semántica