Serie "Guía breve": Multimedia

Consejo 3: Multimedia: Proporcione subtítulos y transcripción del sonido, y descripción del vídeo.

Los elementos multimedia que tanto se utilizan en las páginas web hoy en día pueden ocasionar graves problemas de accesibilidad, ya no sólo a las personas con algún tipo de discapacidad, sino a todo el mundo en general. ¿Por qué?

Porque al ser elementos que no son HTML requieren, en la mayoría de los casos, la instalación de un visor específico (plug-in, add-in o extensión) que sea capaz de interpretar el elemento multimedia. Y no todo el mundo tiene su ordenador actualizado con los últimos visores.

Por tanto, como regla general, no se debe abusar de los elementos multimedia y el diseñador de una página web se tiene que preguntar, antes de incluirlo en una página web, si es un elemento esencial que no se puede eliminar o sustituir por otro más accesible.

Si nos centramos en los problemas de accesibilidad que pueden tener las personas con discapacidad, los elementos multimedia más problemáticos son los vídeos, las grabaciones sonoras y las animaciones.

Respecto a los vídeos y las grabaciones sonoras, en ambos casos se tiene que proporcionar una transcripción de los dialógos y una descripción de los sonidos. En el caso de los vídeos también se tiene que proporcionar una descripción del vídeo en sí (de la imagen). Un par de artículos sobre subtítulos y descripciones: Captioning y Audio description.

Hoy en día existen tecnologías que permiten sincronizar los subtítulos o una transcripción con un vídeo o una grabación sonora. Las dos tecnologías que más se emplean son Synchronized Multimedia Integration Language (SMIL), una tecnología promovida por el W3C, y por otro lado Microsoft Synchronized Accessible Media Interchange (SAMI). Hace unos días publiqué una entrada llamada SMIL y la accesibilidad web donde comento brevemente estas dos tecnologías.

En el caso de las animaciones, lo más normal hoy en día es que se realicen con Adobe (Macromedia) Flash. Para conocer los problemas de accesibilidad que presentan los elementos multimedia creados con Flash y cómo hacer que sean accesibles, recomiendo la lectura de las siguientes páginas:

• Flash y Accesibilidad Web: una relación complicada: en este artículo podemos leer que la accesibiliad de Flash sólo esta disponible en el sistema operativo Microsoft Windows y con el navegador Microsoft Internet Explorer, ya que Flash utiliza la tecnología tecnología Microsoft Active Accesibility (MSAA) para ofrecer las carecterísticas de accesibilidad.
• Creating Accessible Macromedia Flash Content
• Flash 8 Accessibility Design Guidelines: de Adobe.
• Flash 8 Accessibility Design Guidelines: similar al anterior.
• Best Practices for Accessible Flash Design: de Adobe.

(Actualización 22/11/2007) Otro tipo de elemento problemático, que no es del todo multimedia, pero que se puede incluir dentro de este consejo son los documentos PDF (Portable Document Format). Algunos páginas donde nos explican cómo hacer que un PDF sea accesible:

• Técnicas para el desarrollo de documentos PDFs accesibles
• PDF accesibles
• Creating accessible Adobe PDF Files
• Guía Accesibilidad en Documentos PDF

Adobe ofrece un servicio llamado Online conversion tools for Adobe PDF documents que convierte un documento PDF a HTML o texto plano para aquellos usuarios que no dispongan de un visor de PDF o que su lector de pantalla no sea compatible con Adobe Acrobat Reader.

Serie "Guía breve": Mapas de imagen

Consejo 2: Mapas de imagen: Use el elemento map y texto para las zonas activas.

¿Qué son los mapas de imagen? Veamos lo que dice el W3C en el apartado 13.6 Mapas de imagen de la especificación HTML 4.01:

Los mapas de imágenes permiten a los autores especificar regiones en una imagen u objeto y asignar una acción específica a cada región (p.ej., abrir un documento, ejecutar un programa, etc.). Cuando la región es activada por el usuario, se ejecuta la acción.

Un mapa de imágenes se crea asociando un objeto con una especificación de las áreas geométricas sensibles del objeto.

Hay dos tipos de mapas de imágenes:

• En el lado del cliente. Cuando un usuario activa una región de un mapa de imágenes en el lado del cliente con un ratón, las coordenadas en píxeles son interpretadas por el agente de usuario. El agente de usuario selecciona el vínculo especificado por la región activada y lo sigue.
• En el lado del servidor. Cuando un usuario activa una región de un mapa de imágenes en el lado del servidor, las coordenadas en píxeles son enviadas al agente del lado del servidor especificado por el atributo href del elemento A. El agente del servidor interpreta las coordenadas y realiza alguna acción.

Se prefieren los mapas de imágenes en el cliente que los mapas de imágenes en el servidor por dos razones: son accesibles a las personas que utilizan agentes de usuario no gráficos y permiten saber en todo momento si el apuntador está sobre una región activa o no.

Por tanto, se tienen que emplear los mapas de imagen en el lado del cliente para evitar problemas de accesibilidad.

¿Cómo se crea un mapa de imagen en el lado del cliente? Un mapa de imagen en el cliente se define con la etiqueta map y cada una de las zonas activas se define con la etiqueta area. La etiqueta area posee los atributos shape coords (su valor depende del valor de shape), que se emplean para definir la forma geométrica de la zona activa, y el atributo href, que se emplea para indicar la acción asociada:

• shape="default": define la acción por defecto para toda la imagen.
• shape="rect": define una región rectangular; el atributo coords contiene las coordenadas de la esquina superior izquierda y de la esquina inferior derecha del rectángulo.
• shape="circle": define una región circular; el atributo coords contiene las coordenadas del centro del círculo y del radio.
• shape="poly": define una región poligonal; el atributo coords contiene las coordenadas de cada uno de los puntos que forman el polígono; el último punto tiene que coincidir con el primero para que el polígono se cierre.

Para que el mapa de imagen sea accesible, se tiene queproporcionar un texto alternativo con el atributo alt para cada etiqueta area. Como cada zona activa realiza la misma función que un enlace, el texto alternativo tiene que ser eficaz, en especial, el texto alternativo tiene que tener sentido cuando se lea fuera de contexto. Desgraciadamente, la etiqueta area no posee el atributo longdesc para proporcionar una descripción más larga que con el atributo alt.

El siguiente código define un mapa de imagen que contiene tres enlaces:
<img alt="" src="logopp.gif" usemap="#map1" /><map name="map1" id="map1"><area href="http://www.ua.es/en/index.html" shape="rect" coords="342,104,490,134" alt="University of Alicante"><area href="http://www.ua.es/es/index.html" shape="rect" coords="160,104,325,134" alt="Universidad de Alicante"><area href="http://www.ua.es/va/index.html" shape="rect" coords="0,104,145,134" alt="Universitat d'Alacant"></map>Un lector de pantalla que esté preparado para interpretar los mapas de imagen comunicará al usuario el texto alternativo de cada una de las zonas sensibles definidas en el mapa de imagen. Por ejemplo, en la siguiente imagen podemos observar como lo interpreta la herramienta aDesigner de IBM:



Sin embargo, Fangs no lo interpreta correctamente y no muestra nada. El W3C propone el uso de la etiqueta object en vez de la etiqueta img, ya que la etiqueta object permite incluir contenido alternativo que se muestra en el caso de que el agente de usuario (navegador) no pueda mostrar la etiqueta object. El ejemplo anterior con la etiqueta object se escribe:

<object data="logopp.gif" type="image/jpg" usemap="#map1"><map name="map1" id="map1"><p>Navegar por este sitio: <a href="http://www.ua.es/en/index.html" shape="rect" coords="342,104,490,134">University of Alicante</a><a href="http://www.ua.es/es/index.html" shape="rect" coords="160,104,325,134">Universidad de Alicante</a><a href="http://www.ua.es/va/index.html" shape="rect" coords="0,104,145,134">Universitat d'Alacant</a></p></map></object>Con este código Fangs muestra de forma correcta el contenido alternativo como sustituo de la imagen, como podemos ver en la siguiente imagen:


aDesigner también muestra correctamente el contenido alternativo, como podemos ver en la parte derecha de la siguiente imagen, pero desgraciadamente Internet Explorer no es capaz de interpretar correctamente la etiqueta object (muestra unas barras de desplazamiento y el mapa de imagen no funciona), como podemos ver en la parte izquierda:

¿Qué pasa con la etiqueta object en Internet Explorer? Su soporte es muy malo, como podemos leer y ver en las siguientes páginas:

• Object test suite
• Object and Internet Explorer
• Robin's HTML 4.0 Conformance Test: Objects

Términos relacionados con la accesibilidad

Acabo de encontrar la página Accesibilidad al alcance de todos. En esta página podemos encontrar definiciones de los siguientes términos:

• Tiflotecnología.
• Lector de pantalla.
• Sintetizador de voz.
• Magnificador de pantalla.
• ¿Cuándo es una aplicación accesible?
• ¿Que se necesita para desarrollar una aplicación accesible?

Noticia en formato mp3

Acabo de encontrar la noticia Cuatro de cada diez webs municipales suspenden en accesibilidad. La noticia comenta un estudio realizado por una compañía española que ha analizado los portales municipales de todas las capitales de provincia. Según este estudio, "44 por ciento de las páginas web municipales españolas no cumplen los niveles mínimos de accesibilidad".

Este estudio confirma que no se cumplen las leyes ni los anuncios "a bombo y platillo" que realizan los políticos de vez en cuando. Recordemos algunas noticias pasadas que he comentado desde aquí:

• El acceso electrónico a la Administración, garantizado por ley a los discapacitados
• Garantizada la accesibilidad de los discapactiados en sus relaciones con la Administración
• La accesibilidad web: una asignatura pendiente

Además del contenido de la noticia, me ha llamado mucho la atención que en la página exista una opción para escuchar la noticia o descargarla en formato mp3. ¿Cuál es la finalidad? ¿A qué tipos de discapacitados y en qué condiciones ayuda esta opción? Una persona ciega suele utilizar un lector de pantallas y no necesita de esta ayuda, a no ser que no se encuentre en su ordenador, pero en ese caso, ¿cómo llega hasta el enlace para activar la audición? Se admiten comentarios.

Serie "Guía breve": Imágenes y animaciones

Consejo 1: Imágenes y animaciones: Use el atributo alt para describir la función de cada elemento visual.

En comentarios anteriores he explicado el uso del atributo alt (El atributo alt) y del atributo longdesc (El atributo longdesc). Además, he explicado cómo los agentes de usuario (navegadores) emplean el atributo alt (¿Qué hace el atributo alt?).

¿Para qué sirve el atributo alt? En el apartado 13.8 Cómo especificar texto alternativo de la Especificación HTML 4.01 (HTML 4.01 Specification) encontramos la siguiente definición:

Definiciones de atributos
alt = texto [CS]
Este atributo especifica texto alternativo para agentes de usuario que no puedan mostrar imágenes, formularios o aplicaciones. El idioma de este texto alternativo está especificado por el atributo lang.

Varios elementos no textuales (IMG, AREA, APPLET e INPUT) permiten a los autores especificar texto alternativo que sirva como contenido cuando el elemento no pueda ser representado normalmente. El especificar texto alternativo ayuda a los usuarios que no tengan terminales gráficas, a los usuarios cuyos navegadores no soporten formularios, a los usuarios con discapacidades visuales, a aquellos que utilicen sintetizadores de voz, a aquellos que hayan configurado sus agentes de usuario para no mostrar imágenes, etc.

El atributo alt debe especificarse para los elementos IMG y AREA. Es opcional para los elementos INPUT y APPLET.

Si bien el texto alternativo puede ser muy útil, hay que tratarlo con cuidado. Los autores deberían seguir las siguientes pautas:

• No especificar texto alternativo irrelevante cuando las imágenes incluidas sólo sirven para dar formato a una página, por ejemplo, alt="bola roja" sería inapropiado para una imagen que añade una bola roja para decorar un título o un párrafo. En tales casos, el texto alternativo debería ser la cadena vacía (""). En cualquier caso se aconseja a los autores que eviten usar imágenes para dar formato a las páginas, y que utilicen hojas de estilo en su lugar.
• No especificar texto alternativo sin significado (p.ej., "relleno"). Esto no solamente frustrará a los usuarios, sino que ralentizará a los agentes de usuario que deban convertir texto a salida por voz o Braille.

Los implementadores deberían consultar la sección sobre accessibilidad para información sobre cómo tratar los casos en que se omite el texto alternativo.

¿Cómo utiliza un lector de pantalla el atributo alt? Normalmente, los lectores de pantalla tienen opciones para configurar como tratar el atributo alt y qué hace caso de que no esté. Si no está el atributo alt, normalmente leen el valor del atributo src de la imagen, lo cual no suele ser muy útil.

Para que se entienda lo que hacen los lectores de pantalla, que suelen ser difíciles de utilizar para una persona que no está acostumbrada a ellos, vamos a utilizar el programa aDesigner y la extensión Fangs para Mozilla Firefox. Estos dos programas ofrecen una representación textual de lo que un lector de pantalla lee.

La siguiente imagen muestra una página web con varias imágenes que se corresponde con el siguiente código HTML:

<h1><a href="anterior.html"><img alt="Flecha roja que apunta a la izquierda" src="flecha-izq.gif" /></a><a href="indice.html">Índice</a><a href="siguiente.html"><img alt="Flecha roja que apunta a la derecha" src="flecha-der.gif" /></a></h1><p>Lista de senderos de pequeño recorrido en la provincia de Alicante:<br /><a href="marinabaja.html"><img alt="Senderos en la Marina Baja" src="bullet.gif" />Senderos en la Marina Baja</a><br /><a href="marinaalta.html"><img alt="Senderos en la Marina Alta" src="bullet.gif" />Senderos en la Marina Alta</a><br /><a href="vegabaja.html"><img alt="Senderos en la Vega Baja" src="bullet.gif" />Senderos en la Vega Baja</a></p><p>Teléfono de contacto: <img alt="Teléfono de contacto del servicio técnico" src="telefono.gif" /></p>

Cuando la página anterior se visualiza en aDesigner se obtiene el siguiente resultado:

Con el programa Fangs obtenemos la siguiente representación textual de la página:

Fangs ofrece más información que aDesigner, ya que indica la aparición de algunos elementos de la página, como los enlaces (Link) o las imágenes (Graphic).

En esta página existen varios problemas:

• El texto alternativo que tienen las flechas describe las imágenes, pero no indica su función que es moverse hacia la anterior o la siguiente página.
• Las imágenes que se han empleado en las listas tienen como texto alternativo el mismo texto que las acompañan, por lo que aparece repetido dos veces.
• La imagen que contiene un número de teléfono tiene un texto alternativo que no es nada útil ("Teléfono de contacto del servicio técnico").

Para que está página sea accesible, podemos modificar el texto alternativo de la siguiente forma:

• El texto alternativo de las flechas pasa a ser "Anterior" y "Siguiente". También se podría poner una descripción más larga como "Pasar a la página anterior" si "Anterior" puede ser ambiguo dentro del contexto de la página.
• El texto de las imágenes de las listas lo dejamos vacío, ya que es simplemente decorativo y no aporta ningún contenido útil.
• En el texto alternativo de la imagen con un número de teléfono ponemos el número de teléfono.

Una vez corregido el texto alternativo de las imágenes de la página web de ejemplo se obtiene lo siguiente con aDesigner y Fangs:

Podemos ver que en Fangs aparece un problema nuevo que no aparecía en aDesigner: cuando una imagen no tiene texto alternativo o el texto alternativo es nulo (alt=""), Fangs muestra el valor del atributo src como representación alternativa. En la mayoría de los casos, este valor no es muy útil, ya que suele incluir nombres de directorios y el nombre del fichero que contiene la imagen puede no tener sentido. Para resolver este problema lo mejor es no incluir las imágenes decorativas directamente en el HTML, sino emplear CSS para su inclusión. Pero eso ya lo explicaré otro día.

Serie "Guía breve para crear sitios web accesibles"

A partir de hoy voy a dedicar un comentario cada día a la Guía breve para crear sitios web accesibles del W3C. A principios de 2007 ya dediqué un comentario a esta guía. Los 10 consejos que proporcionan son:

• Imágenes y animaciones: Use el atributo alt para describir la función de cada elemento visual.
• Mapas de imagen: Use el elemento map y texto para las zonas activas.
• Multimedia: Proporcione subtítulos y transcripción del sonido, y descripción del vídeo.
• Enlaces de hipertexto: Use texto que tenga sentido leído fuera de contexto. Por ejemplo, evite "pincha aquí".
• Organización de las páginas: Use encabezados, listas y estructura consistente. Use CSS para la maquetación donde sea posible.
• Figuras y diagramas: Describalos brevemente en la pagina o use el atributo longdesc.
• Scripts, applets y plug-ins: Ofrezca contenido alternativo si las funciones nuevas no son accesibles.
• Marcos: Use el elemento noframes y títulos con sentido.
• Tablas: Facilite la lectura línea a línea. Resuma.
• Revise su trabajo: Verifique. Use las herramientas, puntos de comprobación y pautas de http://www.w3.org/TR/WCAG.

Esta guía son únicamente consejos que ayudan cuando se tiene un "primer contacto" con la accesibilidad web, pero en ningún caso implican que su cumplimiento garantice que se alcance algún nivel de accesibilidad (A, AA o AAA).

¿RDFa mejorará la accesibilidad web?

Acabo de encontrar un nuevo término que desconocía: RDFa. Según la Wikipedia en español:

RDFa es un conjunto de extensiones de XHTML propuestas por W3C para introducir semántica en los documentos. RDFa aprovecha atributos de los elementos meta y link de XHTML y los generaliza de forma que puedan ser utilizados en otros elementos. Además se ha definido una correspondencia simple que permite extraer tripletes RDF.

Una explicación más sencilla: RDFa es un paso más hacia la web semántica, que pretende incorporar descripciones a la información contenida en una página web para que su utilización posterior sea más eficiente (por ejemplo, para facilitar las búsquedas). Con la web semántica una página web no sólo contendrá información, sino información sobre la información (los metadatos), que permitirán saber, por ejemplo, si un número representa un precio o una fecha, o si un nombre es el nombre de una persona o de un lugar.

¿Qué tiene que ver todo esto con la accesibilidad web? En el artículo RDFa - Implications for Accessibility se propone la idea de que RDFa puede ser empleado por el software que emplean las personas discapacitadas (por ejemplo, lectores de pantalla) para facilitar la navegación al aportar más información sobre el contenido de las páginas.

Por ejemplo, el siguiente fragmento de código HTML incluye información personal de contacto. El W3C tiene una propuesta (no es una recomendación aprobada) llamada Representing vCard Objects in RDF/XML para etiquetar este tipo de información. En el primer párrafo se muestra la información sin etiquetar y en el segundo ya aparece etiquetada.

Párrafo sin etiquetar:
<p class="contactinfo">Mi nombre es Sergio Luján Mora. Soy profesor titular en la <a href="http://www.ua.es/">Universidad de Alicante</a>. Puedes contactar conmigo a través del <a href="mailto:sergio.lujan@[arroba]@ua.es">correo electrónico</a>.</p>

Párrafo etiquetado:
<p class="contactinfo">Mi nombre es <span property="contact:fn">Sergio Luján Mora</span>. Soy <span property="contact:title">profesor titular</span> en la <a rel="contact:org" href="http://www.ua.es/">Universidad de Alicante</a>. Puedes contactar conmigo a través del <a rel="contact:email" href="mailto:sergio.lujan@[arroba]@ua.es"> correo electrónico</a>.</p>

Más ejemplos de diseño no accesible

He encontrado la página web Too much accessibility: Good intentions, badly implemented donde podemos encontrar una presentación sobre el mal uso de la accesibilidad en un sitio web. En esta presentación podemos encontrar ejemplos reales de un mal uso del texto alternativo (demasiado explícito o con información irrelevante), del atributo title en los enlaces, de los elementos de los formularios (texto por defecto, legend y fieldset), el enlace de "salta navegación" o "saltar al contenido" (skip to content) y otros errores muy comunes.

Ejemplos de diseño web no accesible

He encontrado la página web Examples of Accessible (and Inaccessible) Web Design. Aunque es del año 1996 y por tanto un poco antigua, ofrece ejemplos muy interesantes de diseño web que no es accesible y consejos para que sí lo sea.

Los temas que trata son:

• Every image should have good ALT text Separate block of ALT text
• Use simple ALT text for simple images
• Proper use of image maps
• Make link text descriptive but brief
• Use link text that can stand alone
• Provide good keyboard navigation
• Provide alternatives to controls and applets
• Provide alternatives to tables and frames
• Don't assume your formatting will be seen
• Don't require the use of style sheets

¿Qué navegadores usa la gente?

En la página web W3C Counter - Global Stats y W3Schools Browser Statistics se ofrecen estadísticas de uso de los navegadores, resoluciones de pantalla, sistemas operativos y otras categorías.

Respecto a los navegadores, los datos que ofrecen estos dos sitios sobre el uso de los navegadores es:

W3Counter
1 Internet Explorer 6.0 43.76%
2 Firefox 2.0 19.98%
3 Internet Explorer 7.0 18.76%
4 Firefox 1.5 6.43%
5 Safari 2.0 1.99%
6 Firefox 1.0 1.09%
7 Opera 9.2 0.81%
8 Mozilla 1.8 0.62%
9 Opera 9.0 0.52%
10 AOL 6.0 0.48%

W3Schools
1 Firefox 35.4%
2 IE6 34.9%
3 IE7 20.8%
4 Safari 1.6%
5 IE5 1.5%
6 Opera 1.5%
7 Mozilla 1.2%

Hay importantes diferencias entre las dos fuentes.

50 herramientas de accesibilidad y usabilidad

He encontrado la página 50 Online Accessibility and Usability Tools que ofrece una lista de 50 herramientas disponibles en la Web para mejorar la accesibilidad y usabilidad de las páginas web.

Las herramientas están agrupadas en las siguientes categorías:

• Color Tools
• Content Tools
• Browsers
• Other

Vídeos

He encontrado la página AssistiveWare videos on computer accessibility. Es una página que debería ver todo el mundo porque te abre los ojos y te permite descubrir cómo personas con algunas discapacidades muy severas son capaces de manejar un ordenador y utilizarlo con la misma fluidez que cualquier otra persona. El espíritu de estos vídeos se puede resumir en la frase de una de sus protagonistas: "We can because we think we can".

Libro electrónico: Accesibilidad e Internet

Gracias a Gabriel Porras y su página Libros Gratis he encontrado el libro Accesibilidad e Internet en formato PDF.

El contenido de este libro es:

• Índice
• Agradecimientos
• Prefacio
• Génesis del trabajo
• Acerca del archivo del trabajo
• Capítulo 1 - Introducción
• Capítulo 2- ¿Cuáles usuarios pueden tener problemas de accesibilidad en la Web?
• Capítulo 3 - Problemas de accesibilidad en la Web
• Capítulo 4 – Pautas, iniciativas y leyes
• Capítulo 5 - ¿Cómo se sabe si una página web es accesible?
• Capítulo 6 - Ayudas técnicas
• Capítulo 7 – Variantes accesibles en el uso de Internet
• Capítulo 8 – Preguntas más frecuentes
• Capítulo 9 – Conclusiones
• Anexo A - WAI y la Sección 508
• Anexo B - Códigos de lenguas
• Anexo C – Bibliografía y recursos en Internet
• Anexo D – Licencia de Creative Commons
• Acerca del autor

Libro electrónico: Comprendiendo la Accesibilidad

Gracias a Gabriel Porras y su página Libros Gratis he encontrado el libro Comprendiendo la Accesibilidad Una Guía para Lograr la Conformidad en Sitios Web e Intranets, que es la traducción al español del libro Understanding Accessibility. A Guide to Achieving Compliance on Web Sites and Intranets.

En la introducción del libro se describe el contenido del mismo:

INTRODUCCIÓN

Entendiendo la Accesibilidad: Una Guía para Lograr Conformidad en Sitios Web e Intranets, está diseñada para ser una completa guía para crear sitios Web, que consigan la conformidad con las normas federales de Estados Unidos para la accesibilidad del contenido Web, delineadas en el Rehabilitation Act Amendments
de 1998, Sección 508, Subsección B, §1194.22. Adicionalmente, esta guía puede ayudarte a asegurarte de que tus documentos con base en la Web, cumplen con los estándares de accesibilidad del World Wide Web, o W3C®. En este libro encontrarás:

• Exhaustiva información, sobre directrices de accesibilidad
• Consejo y guía, sobre cómo conseguir su conformidad
• Instrucciones fáciles de seguir, que te ayudarán a construir contenido Web
  accesible
• Una exhaustiva referencia en código HTML, para crear sitios accesibles
• Ejemplos de sitios Web, Dinámicos y Estáticos
• Comparaciones entre estándares del W3C y la legislación Federal de Estados
  Unidos
• Información útil, para ayudarte a seleccionar software para auditar la
  accesibilidad
• Información sobre el manejo de test de accesibilidad
• Guía para la adquisición de software, basado en requerimientos para software
  accesible.

Este libro es para Autores Web, Gerentes de Proyectos y básicamente cualquier individuo o equipo que se enfrente con el desafío de crear un sitio Web accesible, o modificar un sitio Web, para hacerlo accesible. Si la accesibilidad es algo nuevo para ti te sugerimos que comiences por el principio y leas el libro entero. Si estás atareado reparando sitios que no son accesibles, este libro te servirá como referencia y guía. Si revisas sitios para ver si son accesibles, este libro te ayudará a seleccionar herramientas y a entender los requerimientos de accesibilidad.

¿QUÉ HAY EN ESTE LIBRO?

Este libro te introduce en los preliminares de la accesibilidad y sus desafíos. Proporciona una completa referencia sobre reparación de la accesibilidad. A continuación, se detalla cada una de las secciones:

Capítulo Uno: Familiarizándose con el problema de la Accesibilidad y sus desafíos En esta sección, aprenderás sobre las principales organizaciones que desarrollan estándares de accesibilidad y sobre las leyes del gobierno de Estados Unidos, y también, aprenderás sobre los tipos de discapacidad tenidos en cuenta por los requerimientos. El capítulo Uno, también te guía hacia diversos recursos que pueden proporcionarle ayuda a tu organización y pueden proporcionarte la justificación de, por qué debe construir su sitio Web de forma accesible.

Capítulo dos: Los puntos de control y su significadoEn esta sección, aprenderás qué es cada uno de los puntos de control, cuál es el objetivo de los puntos de control, e información sobre cómo observar su cumplimiento satisfactoriamente.

Capítulo Tres: Introducción a la revisión de la AccesibilidadEsta sección, te introducirá en la tarea de revisar la accesibilidad de páginas Web y de sitios
Web enteros. Además, te introducirá en el conocimiento de herramientas de revisión, reparación y seguimiento. Discutiremos brevemente sobre los sistemas de gestión de contenido y arquitecturas de revisión existentes.

Capítulo Cuatro: Desarrollando una estrategia para la conformidad con la Accesibilidad En esta sección, aprenderás cómo definir requisitos de formación, como parte de una valoración inicial de la accesibilidad de un sitio.

Capítulo Cinco: Accesibilidad y Contenido DinámicoEsta sección, te introducirá en la relación entre el contenido dinámico y el trabajo para hacerlo accesible. Esta sección incluirá, también, dos ejemplos para demostrar problemas de accesibilidad con el contenido dinámico.

Capítulo Seis: El significado inadvertidoEste capítulo, cubre tres métodos distintos para proveer un sitio más útil, para aquellos que tienen una limitación tecnológica, o una discapacidad que les impide ver el componente visual de su sitio Web.

• Metadatos para la accesibilidad: En esta sección, aprenderás cómo usar metadatos para incrementar la accesibilidad de tu sitio Web.
• Escribiendo textos alternativos: En esta sección, aprenderás las mejores y peores prácticas, para crear textos alternativos para los objetos gráficos en tu página Web.
• Imágenes y accesibilidad: En esta sección, aprenderás cómo asignar con propiedad textos alternativos a las imágenes y por qué. Además, expondremos algunas prácticas comunes, pero defectuosas, para asignar texto alternativo a las imágenes.

Capítulo Siete: Tutorial: Corrigiendo Errores de AccesibilidadEsta sección, consiste en una extensa guía y tutorial. Este capítulo, contiene completos ejemplos y una serie de archivos de demostración, que serán inestimables ayudándote a comprender el marcado de la accesibilidad.

Capítulo Ocho: Uso de soluciones accesiblesEn esta sección, aprenderás sobre los requerimientos de accesibilidad para el software, de acuerdo con las normas de accesibilidad de Estados Unidos. También, te introducirá en el uso de la “Voluntary Product Accessibility Template, (“VPAT”)”.

Capítulo Nueve: Recursos de Accesibilidad y otras lecturas Esta sección, te proporciona información adicional y recursos.

Libro electrónico: Just Ask

Gracias a Gabriel Porras y su entrada Libros gratis he localizado un libro gratuito en versión electrónica llamado Just Ask: Integrating Accessibility Throughout Design.

Este libro describre como integrar la accesibilidad en un proceso de diseño centrado en el usuario. El libro posee un apartado muy práctico sobre cómo realizar pruebas con usuarios para evaluar la accesibilidad y usabilidad de un sitio web.

Libro electrónico: Buiding Accesible Websites

Acabo de encontrar la versión web del libro Building Accesible Websites de Joe Clark. Aunque sea del año 2002, es un libro de lectura imprescindible.

Siete errores de accesibilidad que no se deben cometer

Acabo de encontrar el artículo Seven accessibility mistakes you don’t want to make. Son consejos muy generales, más bien destinados a un jefe de proyectos que a un programador que se tenga que pelear con el HTML para que una página sea accesible, pero puede venir bien leerlo.

Los siete errores que se citan son:

1. Believing in products without putting them to the test (creer en los productos sin probarlos).
2. Taking too much responsibility (asumir demasiada responsabilidad).
3. Planning only for the worst-case scenario (planificar únicamente para el peor caso).
4. Sharing problems with the visitor (compartir los problemas con el visitante).
5. Trying to solve problems outside our area of experience (intentar resolver los problemas que están fuera del área de experiencia).
6. Hiding or overriding accessibility/usability enhancements (esconder o pasar por alto las mejoras de accesibilidad/usabilidad).
7. Catering to your client–not their clients (abastecer a tu cliente, no a sus clientes).

Mejores blogs sobre accesibilidad y usabilidad web en español

He encontrado una entrada en el blog Accesibilidad, Usabilidad y Estandares Web titulada Mejores blogs sobre accesibilidad y usabilidad web en español. El propósito del autor era recopilar una lista con los 100 mejores blogs sobre accesibilidad en español. Inicialmente tenía 60 direcciones, pero ya va por 105.

Desde aquí le agradezco al autor de este blog que me haya incluido en su lista :-)

Accesibilidad de los productos de IBM

He encontrado la página web Accessibility and ergonomic comfort features of IBM personal computers and accessories donde se explican las características para mejorar la accesibilidad que incorporan algunos de los productos de IBM.

SMIL y la accesibilidad web

He recibido un correo electrónico en el que me preguntan si conozco algún editor de SMIL que permita realizar subtitulado y utilizar el lenguaje de signos. He tenido que contestar que lo desconozco. Pero... ¿qué es SMIL?

SMIL es el acrónimo de Synchronized Multimedia Integration Language, una recomendación del W3C que se emplea para describir presentaciones multimedia, es decir, presentaciones donde podemos combinar texto (con formato), imágenes, audio y vídeo. SMIL es un lenguaje de marcado basado en XML.

Como de costumbre, Microsoft tiene una tecnología con un propósito similar llamada SAMI (Synchronized Accessible Media Interchange).

Para trabajar con cualquiera de las dos tecnologías necesitamos una herramienta de autor para crear el contenido y un reproductor compatible para poderlo visualizar.

En el caso de SMIL, algunos reproductores compatibles son Apple QuickTime, RealPlayer o Microsoft Windows Media Player. En el caso de SAMI, Microsoft Windows Media Player es compatible con esta tecnología.

Ambas tecnologías se pueden emplear para proporcionar subtítulos y transcripciones de la pista sonora de algún elemento multimedia de nuestras páginas web como los vídeos. Con esta tecnología podemos sincronizar los subtítulos y cualquier otro elemento con el vídeo.

En la página Webcasting Samples se pueden encontrar varios ejemplos para diferentes reproductores multimedia. A continuación incluyo dos ejemplos con dos estilos diferentes, uno integrado en la propia página web y otro que hace uso de forma externa del reproductos Microsoft Windows Media Player:

Otra certificación de la accesibilidad web

He encontrado otra certificación de la accesibilidad web: Etiqueta Europea (Accesibilidad Web): Euracert. Según dice en la propia web, "La etiqueta Euracert no es otra etiqueta sobre Accesibilidad Web. De hecho, un sitio web obtiene la etiqueta Euracert como añadido a una etiqueta local otorgada en un país europeo por una de las organizaciones existentes [...]". Esta certificación permite un reconocimiento mutuo entre organizaciones de distintos países que trabajan sobre las pautas y recomendaciones internacionales de accesibilidad.

Hace unos meses comenté en la entrada Certificación Accesibilidad Web otro tipo de certificación que existe y que está respaldada por el European Software Institute (ESI) y la Fundación CTIC.

¿Tiene un sentido tantas certificaciones? ¿Habra una certificación para las certificaciones?

El lenguaje de signos reconocido como lengua natural de las personas sordas

He encontrado esta noticia en el periódico El País: El orgullo sordo. Según cuenta la noticia, el Senado español acaba de reconocer el lenguaje de signos como lengua natural de las personas sordas.

Esta noticia me ha recordado una entrada titulada Simplificar los textos que escribí hace unos meses. En esta entrada explicaba que la redacción de los textos de una página web se tiene que simplificar para facilitar su lectura a las personas sordas ya que para ellas su lengua natural es el lenguaje de signos.

Como medio para mejorar la accesibilidad de un sitio web para las personas sordas se pueden incorporar vídeos con explicaciones en el lenguaje de signos. En aquella entrada ponía como ejemplo la web del banco Bankinter.

He encontrado un ejemplo más de uso del lenguaje de signos en una página web: Movistar. En este sitio web podemos encontrar varios vídeos que explican los servicios que ofrece Movistar mediante el lenguaje de signos.

Por otro lado, existe el documento Directrices para el uso del Lenguaje de Signos en la Red donde se explica cómo incorporar el lenguaje de signos a la web. En esta página se proporcionan consejos para grabar un vídeo e incluirlo en una página web.

aDesigner

Los creadores de IBM Home Page Reader han creado una nueva herramienta para evaluar la accesibilidad de un sitio web: aDesigner. Y es gratuita.

Además de evaluar la accesibilidad según las pautas del W3C o Section 508, esta herramienta realiza dos análisis y simulaciones muy interesantes: cómo ve la página web una persona completamente ciega que utilice un lector de pantallas o cómo ve una página web con una visión reducida (por la edad o por alguna enfermedad).

En el caso de las personas ciegas, esta herramienta muestra el tiempo necesario (en segundos y con un código de colores) para llegar a distintos puntos de la página cuando se accede a ella con un lector de pantalla. Cuando una página contiene muchas zonas oscuras significa que se tarda mucho tiempo en llegar a ellas; este problema se puede resolver con enlaces intradocumentales del tipo salta contenido (skip content).

En el caso de las personas con una visión reducida, esta herramienta permite simular distintas situaciones, como falta de agudeza visual o problemas de ceguera a algunos colores (daltonismo).

aDesigner también permite evaluar la accesibilidad de documentos ODF, de contenido Flash y de entornos gráficos de usuario.

Por último, esta herramienta se integra con Internet Explorer, ya que al instalarse añade al menú Herramientas la opción "Open with aDesigner".

Más sobre compatibilidad con distintos navegadores

Lograr que una misma página web sea compatible (funcione correctamente) con múltiples navegadores es una cuestión bastante compleja hoy en día. La mejor forma de lograrlo es:

1. Emplear los estándares.
2. Visualizar la página web en distintos navegadores para comprobar que es compatible.

Para visualizar una página web en distintos navegadores se podría pensar que haría falta tener un ordenador para cada navegador. Pero esa no es la única solución y, evidentemente, la mejor solución.

Hace ya unos meses escribí la entrada Como se ve mi página en distintos navegadores y Cómo instalar varias versiones de Internet Explorer en un mismo ordenador.

Ahora he encontrado el artículo Browser Tests, Services and Compatibility Test Suites que explica con detalle tres escenarios: como instalar varias versiones de Internet Explorer, como instalar varias versiones de Safari (el navegador más utilizado en Mac OS) y como instalar o utilizar varios navegadores en Linux.

Además, el artículo incluye una lista de herramientas disponibles a través de Internet que se pueden emplear para ver una página web en distintos navegadores.

En la página How to Check Your Website with Multiple Browsers on a Single Machine (Cross-Browser Compatibility Checking) se puede leer otra explicación de este problema.

(Actualización 07/10/2007) Me han informado de la existencia de la página Prueba tu página con diferentes navegadores donde también se comenta la necesidad de verificar la correcta visualización de una página web con diferentes navegadores. En esta página se incide en la necesidad de emplear navegadores alternativos y se ofrecen enlaces a algunos de ellos.

Un mini navegador muy potente

Acabo de encontrar una página web donde se puede probar Opera Mini, el navegador de Opera que se incluye en algunos móviles.

El simulador es muy bueno y el navegador es bastante asombroso, ya que muestra las páginas no con su aspecto original, sino modificadas, pero parece que es bastante "inteligente", ya que las modificaciones que introduce son muy acertadas (por ejemplo, adaptación de una página cuando se emplean tablas para maquetar el contenido).

Esta herramienta puede ser muy últil para evaluar la accesibilidad de una página web desde distintos dispositivos.

A continuación he incluido algunas capturas de visualización de la página web de la Universidad de Alicante con este navegador:

Hijax: Ajax accesible

Acabo de encontrar un nuevo término: Hijax. Bajo este término se esconde una estrategia de uso de Ajax que tiene el objetivo de lograr páginas web accesibles: que las páginas sean totalmente funcionales para aquellos usuarios que no puedan hacer uso de Ajax (por ejemplo, porque quieren o no pueden hacer uso de JavaScript).

Esta técnica se basa en lo que se conoce en inglés como progressive enhancement y graceful degradation, dos estrategias que permiten que un sistema informático (en este caso, una página web) funcione correctamente aun en el caso de que falte algún tipo de componente.

Mientras que con progressive enhancement se parte de una versión básica completamente operativa (se parte de una página web compatible con la mayoría de los navegadores y con el menor uso posible de tecnologías complementarias como CSS o JavaScript), con graceful degradation se parte del extremo contrario: se crea una página web para los últimos navegadores, con la posibilidad de que funcione en navegadors antiguos.

En el caso de Hijax, la estrategia que se emplea para lograr el progressive enhancement es la siguiente:

1. Primero, diseñar un sitio web al "estilo antiguo", con enlaces y acciones de formularios que envían información al servidor y este devuelve una página completa con cada petición.
2. A continuación, emplear JavaScript para capturar todos los enlaces y las acciones de los formularios para enviar la infomación mediante XMLHttpRequest. De este modo se puede seleccionar que parte de la página se pueden actualizar de forma individual en vez de tener que recargar toda la página.

Se puede encontrar más de información sobre este tema en esta página: Hijax.


Actualización (12/11/2007) Unas páginas con información interesante sobre Ajax y accesibilidad:

• Quiz: AJAX - automatically move focus?
• Improving accessibility for today’s AJAX - To hack or not?
• HIJAX

Actualización (21/11/2007) Un nuevo término sobre Ajax y la accesibilidad web: AxsJax. Más información en este comentario y en este otro.

Otra noticia sobre IBM

Desde hace años, IBM está muy comprometida con el tema de la accesibilidad en la Web. En esta entrevista a Chieko Asakawa, Q&A: IBM seeks to make streaming media accessible to visually impaired, se describe un nuevo sistema que permite a los usuarios con problemas visuales acceder al contenido multimedia de las páginas web.

IBM Makes Software, Web, Accessibility Push

He encontrado esta página IBM Makes Software, Web, Accessibility Push que anuncia que IBM juntos con unas universidades norteamericanas está preparando material educativo sobre la accesibilidad web:

You might take using a computer for granted, but for millions of people, it's a challenge. One in five individuals, or over 54 million Americans, has a disability that makes it difficult to see a computer screen or navigate the Web, according to IBM.

Specialized, usually expensive, software and hardware solutions have long existed. And in recent years, certain helpful facilities have been built into mainstream software, like magnification for the visually impaired.

But IBM wants to broaden development for the needs of the disabled at a fundamental teaching level. A recent survey of 200 two and four-year U.S. universities commissioned by the computer giant found that the majority of
faculty do not teach accessibility in the classroom.

Today IBM announced an initiative to give teachers wider access to learning material about assistive technologies. Six university partners have signed on to start and the U.S. Department of Education is also supporting the initiative. IBM is building a worldwide repository of materials it said will enable student developers to make software more accessible to those with disabilities and the aging population.

"To create a truly inclusive society, all forms of information technology need to be more accessible," said Dr. Bonnie Jones of the U.S. Department of Education. "If we can't do this, people with disabilities land on the wrong side of the 'digital divide.' We have to capture the intelligence and imagination of our next generation of IT developers now."

The University of Illinois, California State University at Long Beach, Georgia Tech, University of Toronto and the Rochester Institute of Technology are some of the universities who are already working with IBM to build a repository of repeatable learning materials to incorporate into everyday computer programming classes.

In one example, the University of Illinois recently added an online course out universal Web site design that includes accessibility for people with disabilities.

"What's so exciting to me, and so important, is trying to get ahead of the curve and influence colleges around the world to change the way they teach," said Benjamin Kempner, program director, marketing and strategy for the IBM human ability and accessibility center.

"The result is going to be that IBM, or let's say AT&T, Verizon and other companies, will be able to employ people who understand accessibility, it's not an afterthought. Once you build accessibility into your products, that means giving millions of people, productive, fulfilling work," Kempner told internetnews.com. "It can also mean more Web sites will be created that consumers can access."

Kempner spoke during his attendance at the 2007 Technology & Persons with Disabilities Conference at the California State University at Northridge. IBM awarded prizes to three students who won a contest related to the Open Document Format for interoperability.

Daniel Millington (Capitol College), Chase Pritchett (University of Oklahoma), and Yang Liu (Tsinghua University in China), wrote computer code that checks word processing documents that adhere to the ODF to determine whether they are accessible. The students contributed their code to the open source community via sourceforge.org.

Separately, Kempner mentioned other accessibility projects in which IBM is involved. For example, one software/hardware product IBM co-developed with another firm is designed to help people with tremors better control a computer mouse. Another, ViaScribe, is being used by 15 universities worldwide. Used in conjunction with a microphone, ViaScribe is speech recognition software that course instructors can use to get their spoken words on a computer screen so the deaf and hard of hearing can follow along.

To IBM's surprise, ViaScribe proved valuable to more than those with hearing loss. "We've created a mine-able resource that students can use look up lectures on the Web," said Kempner. "As we develop more of these technologies, there will be a larger societal benefit."

En esta página de IBM se puede encontrar toda la información.

Metodología revisión accesibilidad

Acabo de encontrar esta interesante página web: Metodología práctica de revisión de la accesibilidad de sitios Web. En esta página se comentan las ventajas y desventajas de la revisión manual y la revisión automática de la accesibilidad y se propone una metodología práctica de revisión de la accesibilidad de los sitios web que combina ambos métodos.

La metodología de revisión de la accesibilidad consta de cuatro pasos:

1. Análisis con navegador sólo-texto
   Se recomienda usar BrailleSurf o alternativamente usar el simulador Lynx-me disponible mediante un formulario Internet para intenta navegar por el sitio usando este tipo de interfaz sólo texto. Es importante probar así antes de ver la página con el navegador gráfico, para ver si se entiende correctamente la estructura del sitio web.
2. Análisis con navegador gráfico habitual
   Comprobar en Netscape o Explorer el lugar donde se producen fallos con la versión
3. Análisis con navegador Opera
   Opera es un navegador gráfico gratuito con muchas funciones de accesibilidad y alta capacidad de configuración lo que permite comprobar fácilmente distintas situaciones que ayuden a detectar problemas de accesibilidad.
4. Análisis final con Bobby o Taw (opcional)
   Es importante realizar este análisis final que confirmará si hemos olvidado verificar alguno de los aspectos fundamentales de accesibilidad recogidos en las pautas WAI.

Artículo sobre la accesibilidad de algunos sitios web de las administraciones públicas españolas

El artículo La accesibilidad en los sitios web de instituciones públicas españolas fue publicado en el IV Congreso Iberoamericano de informática en la Educación Especial. Aplicaciones para la calidad de vida,  Madrid (2003).

I Plan Nacional de Accesibilidad 2004-2012

El I Plan Nacional de Accesibilidad 2004-2012, publicado por el Ministerio de Trabajo y Asuntos Sociales.

Los captcha y la accesibilidad web

¿Qué es un captcha? Según la Wikipedia:

Captcha es el acrónimo de Completely Automated Public Turing test to tell Computers and Humans Apart (Prueba de Turing pública y automática para diferenciar a máquinas y humanos).

Se trata de una prueba desafío-respuesta utilizada en computación para determinar cuándo el usuario es o no humano. El término se empezó a utilizar en el año 2000 por Luis von Ahn, Manuel Blum y Nicholas J. Hopper de la Carnegie Mellon University, y John Langford de IBM.

La típica prueba consiste en que el usuario introduzca un conjunto de caracteres que se muestran en una imagen distorsionada que aparece en pantalla. Se supone que una máquina no es capaz de comprender e introducir la secuencia de forma correcta por lo que solamente el humano podría hacerlo (salvo error).

Como el test es controlado por una máquina en lugar de un humano como en la Prueba de Turing, también se denomina Prueba de Turing Inversa.

A continuación, un vídeo que he preparado donde explico qué es un captcha con más detalle:



Los captcha actuales suponen un problema de accesibilidad para algunas personas discapacitadas, ya que impiden a personas con deficiencias visuales o auditivas acceder a los recursos protegidos por los captcha. El vídeo CAPTCHAs on Social Networking Sites Shut Out Blind Users explica muy bien el problema de los captcha.



El W3C trabaja en resolver este problema y ha publicado el documento Inaccessibility of CAPTCHA donde explica posibles soluciones.

¿Cuanto sabes de accesibilidad?

He encontrado esta página, Niveles de conocimiento de la Accesibilidad web, en la que se definen 6 + 1 (nivel 0) niveles de conocimiento sobre la accesibilidad en la Web. A continuación incluyo las definiciones:

Conoce tu nivel de conocimiento de la accesibilidad web, una palabra desconocida por muchos pero que cada vez adquiere mayor importancia en Internet. Realice la clasificación de niveles según los conocimientos de accesibilidad web, esa palabra desconocida por muchos pero cada vez adquiere más importancia en Internet.

Esta es mi opinión personal (por lo tanto discutible), y muchas de ellas se desprenden de mis experiencias en el foro de accesibilidad de Foros del Web.

Nivel 0
No me funciona Internet ¿qué hago?:
Estas personas nunca se detienen a pensar sobre la importancia de la accesibilidad web; muchas veces confunden accesibilidad web con accesibilidad a un nivel más general. Por ejemplo, cuando no pueden utilizar Internet por un desperfecto de hardware.

Nivel 1
Optimizado para Internet Explorer y una resolución de 1024 x 768:
Estas personas tienen conocimientos muy básicos de HTML, como para pensar sobre accesibilidad web. No conocen más allá del Internet Explorer, y no conciben que haya diferentes navegadores. Piensan que si una página se ve bien en su computadora, se ve bien en todas.

Nivel 2
Usaré javascript, y el que no lo tenga habilitado que lo habilite:
En este nivel ya se empiezan a escuchar opiniones sobre la accesibilidad web, pero la mayoría piensa que es un capricho de algún loco desquiciado, y que no vale la pena tanto esfuerzo "para eso". La actitud general es "si el usuario no puede visualizar el website, que se arregle como pueda". Los sitios con menús solo en javascript o solo en flash son realizados generalmente por personas en este nivel.

Nivel 3
A mí la accesibilidad no me importa, lo que a mí me interesa es aparecer bien en Google:
En este nivel se produce un primer encuentro obligado con la accesibilidad web, cuando las personas se dan cuenta que la falta de accesibilidad repercute en un perjuicio directo hacia sus sitios.
En este nivel son comunes, a pie de página, los menús solo texto alternativos al menú principal (que sigue estando en flash o javascript). Un acercamiento a la accesibilidad es visto como un "mal menor" necesario para aparecer en los buscadores. La mayoría de los desarrolladores se estanca en este nivel.

Nivel 4
Para ver la versión accesible haz clic aquí:
Las personas en este nivel, ya comienzan a preocuparse un poco, voluntariamente por la accesibilidad, pero aún la siguen viendo como un concepto separado del resto,
sobretodo separado del diseño.
Los sitios desarrollados en este nivel, generalmente no son accesibles pero tienen una versión secundaria desprovista de elementos de diseño, que intenta serlo, aunque muchas veces solo queda en el intento.
Después de todo, recién se están enterando del real significado de "accesibilidad web", muchos han sentido nombrar a las WAI pero pocos saben su significado, mucho menos han leído las directrices de accesibilidad.

Nivel 5
Valido WAI-AAA (Triple A):
Después de leer y ensayar mucho, las personas en este nivel ya tienen un gran dominio sobre la accesibilidad web, y hacen sus webs accesibles porque están convencidas de que es la única forma de avanzar hacia una red más igualitaria.
Sus sitios tienen un marcado HTML semántico, conocen la gran mayoría de los puntos de las WCAG y entre sus lecturas habituales se encuentran temas sobre estándares web, usabilidad y CSS.

Nivel 6
Recientes investigaciones indican que:
Este es el nivel de los "gurus" de la accesibilidad. Son personas proactivas, que no solo aplican la accesibilidad a sus propios sitios, son verdaderos evangelizadores, expandiendo la idea de una web para todos.
Generalmente son miembros de fundaciones como SIDAR, y tienen en su haber libros y artículos publicados sobre lo necesario de realizar webs accesibles y fáciles de usar.

Inspirado por los artículos Niveles de conocimiento de CSS (por Emil Strenstrom) y Niveles de Conocimiento de HTML (por Roger Johansson).

¿Cuál es tu nivel de accesibilidad web?

Guía para crear sitios web accesibles

How to Commission and Design Web Accessible Websites es una guía gratuita elaborada por AbilityNet, el principal fabricante de ayudas técnicas para discapacitados en el Reino Unido, para ICT Hub.

Esta guía contiene los siguientes apartados:

Introduction

Part one: An overview of web accessibility for the VCS
What is web accessibility?
What are the benefits?
Facts and figures
An introduction to accessibility guidelines
Who does it affect?
Future trends in web accessibility

Part two: For commissioners
Introduction
What the law says about web accessibility
Planning for an accessible website
Web Accessibility Policy
Working with designers and developers
Post launch – how to keep your site accessible

Part three: For editors: Writing for the web
Language
Pictures and symbols to help understanding
Writing alternative text
Hypertext links
Headings
Editors checklist

Part four: For developers and designers
Web accessibility in context
Web accessibility level 1 issues
Key Level 2 accessibility issues
Word, PowerPoint and PDFs

Part five: Testing the accessibility of your website
Testing overview
Disabled user testing
Testing for specific accessibility issues
Testing checklist

Part six: Resources
Glossary
Useful websites
W3C Web Content Accessibility Guidelines Checklist levels 1 and 2
Helpful organisations

Metodologías para evaluar la accesibilidad

En la página Metodología, certificaciones y entidades certificadoras de la accesibilidad web en España se recopila una lista de metodologías que se aplican para evaluar la accesibilidad de las páginas web y qué certificaciones y etiquetas (label, sello o marca) hay.

Software para discapacitados

He encontrado esta página sobre el Projecte Fressa donde hay disponible gran cantidad de software para personas con diferentes tipos de discapacidad.

El Gobierno aumentará en un 67% el presupuesto para proyectos de accesibilidad

He encontrado esta noticia en el periódico El Mundo: El Gobierno aumentará en un 67% el presupueto para proyectos de accesibilidad. La noticia dice:

El ministro de Industria, Comercio y Turismo, Joan Clos, ha anunciado que en 2007 el presupuesto para subvencionar proyectos destinados a facilitar el acceso de las personas con discapacidad a la sociedad de la información se incrementará en un 67%.

Clos aseguró que el Ejecutivo está realizando un "especial esfuerzo para acercar las nuevas tecnologías a todos los ciudadanos y, por supuesto, a todas aquellas personas que padecen alguna discapacidad".

Puso como ejemplo el denominado 'Plan Avanza', en el que las nuevas tecnologías son un "mecanismo idóneo para evitar la exclusión social y mejorar la calidad de vida" de los ciudadanos.

En 2006 se realizó la primera convocatoria para subvencionar proyectos que fueran en la línea del 'Plan Avanza'. Se concedieron más de de 2.694.000 euros en subvenciones para los 26 proyectos aprobados.

El responsable de Industria agregó que otra de estas iniciativas es la de 'Internet en las aulas', con medidas específicas para la compensación de desigualdades y actuaciones dirigidas a las personas con discapacidad.

Mencionó también otros proyectos, como los destinados a la mejora de la accesibilidad de la Red y la inclusión de los ciudadanos en la sociedad de la
información, con la fijación de 'estándares web', así como la instalación del Centro Demostrador de Tecnologías para la Accesibilidad.
Por último, Clos anunció un Real Decreto con el objetivo de "arreglar las condiciones de accesibilidad para el acceso a la sociedad de la información de todas las personas, independiente de sus capacidades".

Tablas accesibles

Una tabla de datos definida con la etiqueta table es muy fácil de entender si se
puede ver toda ella en su conjunto, pero es muy difícil de entender si sólo se puede ver un
dato aislado cada vez. Este problema lo sufren los usuarios que emplean navegadores no visuales, ya que ellos tienen que recorrer las tablas de formal lineal y pierden la visión global de la tabla que permite identificar el significado de cada dato de una celda.

Para evitar este problema, tenemos que etiquetar correctamente las tablas para definir su título, los encabezamientos de las columnas y las filas y tenemos que incluir un resumen que describa brevemente el contenido de la tabla.

El título
Una tabla debe de tener un título que proporcione una descripción breve de la tabla. Para evitar que existan dudas, el título se tiene que definir dentro de la tabla. Para definir correctamente el título de una tabla, se tiene que emplear la etiqueta caption. De acuerdo con la especificación de HTML, la etiqueta caption es opcional y tiene que ser el primer elemento que contenga una tabla.

Encabezamientos
Al recorrer una tabla de forma lineal, se pierde la visión global y es muy difícil identificar el significado de un dato. Para evitar esta situación, podemos usar los encabezamientos, que permiten asociar un dato con su encabezado.

Un encabezado de una tabla se define con la etiqueta th. Esta etiqueta es similar a la etiqueta td (se puede usar una en el lugar de la otra) y por tanto ambas definen una celda de una tabla, pero th indica que la celda contiene un encabezado.

Encabezamientos más complejos
Para tablas con encabezamientos más complejos, donde pueden existir varios niveles de encabezamiento, podemos emplear los atributos scope y headers para definir la relación que existe entre las celdas de encabezamiento y las celdas de datos. En tablas sencillas ambos atributos se pueden emplear de forma equivalente, pero para tablas más complejas se tiene que emplear el atributo headers. El uso del atributo scope y headers no afecta a la presentación visual de la tabla.

El atributo scope define el conjunto de celdas para las cuales la celda sobre la que se aplica proporciona información de encabezamiento. Puede tomar cuatro posibles valores:

• row: La celda proporciona información de encabezamiento para el resto de celdas
  de la fila que la contiene.
• col: La celda proporciona información de encabezamiento para el resto de celdas
  de la columna que la contiene.
• rowgroup: La celda proporciona información de encabezamiento para el resto del
  grupo de filas que la contiene.
• colgroup: La celda proporciona información de encabezamiento para el resto del
  grupo de columnas que la contiene.

El atributo headers permite definir una lista de celdas de la tabla que proporcionan información de encabezamiento para la celda actual. El valor de este atributo es una lista separada por espacios en blanco de los identificadores de las celdas de encabezamiento; las celdas se identifican con el atributo id. Por tanto, el atributo headers permite definir encabezamientos más complejos que con el atributo scope.

Resúmenes
El resumen permite definir una descripción larga de la tabla que complemente al título de la tabla. La descripción tiene que incluir una explicación sobre el contenido y sobre la estructura de la tabla (número de filas y de columnas, descripción de los encabezamientos). Además, también puede explicar la relación que guarda la tabla con el resto de la página. En HTML, el resumen de una tabla se define con el atributo summary de la etiqueta table.

Para obtener más información, consulta las siguientes páginas:

• Tablas accesibles, en español.
• Accesible Data Tables, en inglés.

Lector de pantalla para Firefox

Existen dos add-ons para Mozilla Firefox que proporcionan una funcionalidad similar, pero limitada, a un lector de pantalla: FoxyVoice y Speak It. Ambos emplean Microsoft Speech API (SAPI), por lo que sólo funcionan en Microsoft Windows. Desgraciadamente, por ahora Microsoft SAPI no incluye la fonética del español.

De los dos, Speak It es una versión más moderna del primero, por lo que se supone que funcionará mejor. Una vez que se ha instalado, añade el submenú Speak It en el menú Ver y las opciones Say It y Read All en el menú contextual que aparece al pulsar el botón derecho del ratón. Con ambas opciones se puede leer una parte seleccionada de la página web o la página completa.

Torquemada

Torquemada es una herramienta de evaluación de la accesibilidad desarrollada en Italia. Existe una versión en inglés, pero alguna vez me ha dado algún problema y no funciona.

Esta herramienta es muy interesante, ya que el informe de resultados está dividido en tres áreas que interactúan entre sí. Por un lado, se muestra el típico informe con la lista de puntos de verificación que han fallado (errores automáticos) o pueden fallar (errores manuales). Por otro lado se muestra la propia página web y, por último, se muestra el código HTML de la página.

En el informe con la lista de puntos de verificación, se puede acceder a la documentación del W3C que describe ese punto de verificación. Además, se indica mediante un enlace el número de línea donde está el (posible) error; al pulsar sobre este enlace, se destaca en las otras dos partes del informe el elemento de la página web y el código HTML correspondiente.

El acceso electrónico a la Administración, garantizado por ley a los discapacitados

He encontrado esta noticia en el periódico El Mundo: El acceso electrónico a la Administración, garantizado por ley a los discapacitados. La noticia dice:

El senador de la Entesa Joan Josep Nuet ha defendido en la Comisión de Administraciones Públicas de la Cámara Alta las enmiendas del grupo a la Ley de acceso electrónico a la administración, que se aprobará la próxima semana por el Pleno del Senado.

Así, la Entesa ha introducido en el texto una de sus enmiendas, después de pactar con los demás grupos que han dado su apoyo. Dicha enmienda se refiere a que el Gobierno desarrollará garantías para que todos los ciudadanos, con especial atención a las personas con algún tipo de discapacidad y mayores, puedan acceder a los servicios electrónicos en igualdad de condiciones.

Además, la Entesa ha logarado introducir un grupo de enmiendas encaminadas a reducir las posibles discriminaciones que pueda plantear el acceso electrónico y abrir a sistemas diversos, asegurar el software gratuito y la libre gestión de los programas informáticos.

La Ley de acceso electrónico a la administración garantiza el derecho de los ciudadanos a ser atendidos por las distintas administraciones públicas de forma telemática, garantizando la seguridad de las comunicaciones, la neutralidad tecnológica, y la accesibilidad a la información pública.

Así la ley crea derechos que hasta ahora no existían, según ha explicado el ponente socialista de esta futura ley, Juan Carlos Corcuera, resaltando que se obliga a las administraciones públicas a asegurar estos derechos.

Cómo se ve mi página en distintos navegadores

Acabo de descubrir una herramienta muy interesante llamada Browsershots. Esta herramienta muestra mediante capturas de pantalla cómo se ve una página web con diversos navegadores (Firefox, Internet Explorer, Safari) en diferentes sistemas operativos (Linux, Windows y Mac). Con esta herramienta, podemos comprobar que nuestra página web es accesible con diferentes navegadores.

La descripción de esta herramienta según su propio autor es:

Browsershots makes screenshots of your web design in different browsers. It is a free open-source online service created by Johann C. Rocholl. When you submit your web address, it will be added to the job queue. A number of distributed computers will open your website in their browser. Then they will make screenshots and upload them to the central server here.

JAWS compatible con Firefox

He encontrado el proyecto JAWS Screen Reader Adaptation for Mozilla Firefox de la Universidad de Texas. Este proyecto prende que el lector de pantalla JAWS funcione correctamente con el navegador Mozilla Firefox.

El objetivo de este proyecto es, según sus propios autores:

The goal of the Sharkware Development team is to create compatibility between Freedom Scientific's JAWS Screen Reader and the Mozilla Firefox next generation browser. Freedom Scientific has not created scripts that would allow JAWS to function properly in Mozilla Firefox or any other browser other than Internet Explorer. The purpose of our project is to create a bridge between these two software components so that everyone can have a choice of what browser they wish to use.

Cómo hacer un blog accesible

He encontrado una página web donde explican cómo hacer un blog accesible: Haciendo una bitácora accesible. En estas páginas, Carlos Egea nos explica cómo hacer que un blog sea accesible con una serie de transformaciones. Como herramienta de publicación de blogs se emplea Blogger, así que debería de leerme estas páginas para mejorar la accesibilidad de este blog.

El proceso de mejora de la accesibilidad de un blog se ha dividido en 21 pasos:

Introducción.
Primeras instrucciones.
Paso 1.- ¿Para quién es la accesibilidad Web?.
Paso 2.- Elegir un DOCTYPE.
Paso 3.- Identificar el idioma.
Paso 4.- Elegir un título significativo.
Paso 5.- Ayudas adicionales a la navegación.
Paso 6.- Colocar primero el contenido principal.
Paso 7.- El uso de los colores.
Paso 8.- Vínculos reales.
Paso 9.- Vínculos correctos y con títulos.
Paso 10.- Atajos de teclado.
Paso 11.- No abrir nuevas ventanas.
Paso 12.- Acrónimos.
Paso 13.- Tablas accesibles.
Paso 14.- Usar listas reales.
Paso 15.- Equivalente textual para imágenes.
Paso 16.- Atributo "alt" vacio.
Paso 17.- Mapas de imagen accesibles.
Paso 18.- Líneas horizontales.
Paso 19.- Tamaños de fuente relativos.
Paso 20.- Encabezados correctos.
Paso 21.- Verificar la accesibilidad.

¿Manejadores de evento lógicos en vez de manejadores de evento dependientes de dispositivos?

La pauta 9 de las Pautas de Accesibilidad al Contenido en la Web 1.0 lleva por título Diseñe para la independencia del dispositivo. Dentro de esta pauta tenemos el punto de verificación 9.3

9.3 Para los "scripts", especifique manejadores de evento lógicos en vez de manejadores de evento dependientes de dispositivos. [Prioridad 2]

¿Cuál es la razón de este punto de verificación? Básicamente existen dos tipos de eventos, los dependientes del dispositivo y los independientes.

Los eventos dependientes del dispositivo dependen del uso concreto de un dispositivo, como puede ser el ratón y el teclado. Algunos eventos de este tipo son onmouseover, onmouseout y ondblclick.

Los eventos independientes del dispositivo son producidos por cualquier dispositivo, ya sea el ratón o el teclado, por ejemplo. Algunos eventos de este tipo son onfocus, onblur y onselect.

Si en una página web se emplean eventos asociados al uso del ratón, aquellos usuarios que empleen el teclado tendrán problemas para acceder a algunos contenidos. Para evitar este problema, hay que asegurarse de que se puede interactuar con una página mediante cualquier dispositivo. Básicamente, se tienen que emplear los eventos de la siguiente forma:

• onmousedown con onkeydown
• onmouseup con onkeyup
• onmouseover con onfocus
• onmouseout con onblur
• onclick con onkeypress

No obstante, hay que llevar un cuidado especial con el evento onclick, ya que en algunas situaciones (cuando se emplea en un enlace o en un control de un formulario) se comporta como un evento independiente del dispositivo, ya que la mayoría de los navegadores asocian la pulsación de la tecla Enter con este evento.

Por tanto, si especificásemos también el evento onkeypress, se podrían ejecutar al mismo tiempo los dos eventos, lo cual ocasionaría problemas.

Para más información, se puede consultar la página Scripts using event handlers de IBM.

¿Qué etiqueta utilizar: B o STRONG?

Algunas herramientas de evaluación de la accesibilidad, como WAVE, consideran como un error el empleo de las etiquetas B o I. ¿Por qué?

El punto de verificación 3.3 de las Pautas de Accesibilidad al Contenido en la Web 1.0 nos dice:

3.3 Utilice hojas de estilo para controlar la maquetación y la presentación. [Prioridad 2]

Si consultamos sus técnicas HTML, en el punto 3.1 Enfásis nos dice:

Para remarcar el énfasis, utilice los elementos HTML apropiados: EM y STRONG. No deberían usarse los elementos B e I, ya que se usan para crear un efecto visual de presentación. Los elementos EM y STRONG fueron diseñados para indicar un énfasis estructural, que puede ser plasmado en varios modos (cambios de estilo de fuente, cambios de inflexión del discurso, etc.).

La etiqueta B significa "bold", negrita, por lo que se trata de un elemento que modifica la presentación, pero no añade ningún contenido semántico.

Sin embargo, en Strong versus Bold podemos encontrar una discusión sobre en qué situaciones podemos emplear B o I simplemente para proporcionar una apariencia visual diferente (por ejemplo, para aumentar la legibilidad del texto) pero sin querer proporcionar un contenido semántico diferente.

Día de Internet y la accesibilidad en la Web

Hoy, 17 de mayo, se celebra el Día Mundial de Internet. Según los resultados de un estudio del Centro de Investigaciones Sociológicas (CIS) que leo en la noticia Día de Internet: más de la mitad de los españoles todavía no usa la Red de El Mundo, un 54% de los españoles no usa Internet. La situación parece un poco preocupante.

Por otro lado, también he encontrado en El Mundo la noticia MÁS DE 66.000 CIEGOS ESPAÑOLES NO PUEDEN NAVEGAR POR INTERNET. Cito a continuación lo más interesante que se dice en este artículo sobre la accesibilidad en la Web:

[...]

Según afirma la organización, existen más de 66.000 personas afiliadas que sufren "importantes problemas" a la hora de realizar determinadas actividades a través de Internet, como comprar o trabajar 'on-line', reservar billetes de viajes o realizar gestiones con la Administración.

Asimismo, la ONCE quiere poner de manifiesto que, además de los ciegos, existen 3.5 millones de personas en España, tanto discapacitadas como de la tercera edad, "que encuentran graves problemas de acceso y comprensión de las páginas web no adaptadas".

[...]

Para conseguir la accesibilidad de los discapacitados, la ONCE afirma que es necesaria la formación y concienciación de los diseñadores de de páginas web para la búsqueda de mejores sistemas de navegación y diseño accesible.

WAVE

La herramienta WAVE (Web Accessibility Tool) permite evaluar la accesibilidad de una página web, ya sea indicando la URL de la página a analizar o subiendo directamente la página. Al igual que otras herramientas similares, permite elegir el nivel de análisis. Lo más interesante de esta herramienta son las opciones de configuración que posee y la información que proporciona en los informes de análisis.

Respecto a las opciones de configuración, están agrupadas en dos conjuntos:

• Document mode: permite seleccionar qué elementos de la página original se tienen que mostrar en el informe, como por ejemplo, tablas, imágenes u objetos multimedia.
• WAVE features to include: permite indicar que características de análisis se tienen que incluir en el informe, como por ejemplo, los errores, las alertas o información estructural sobre el documento.

Esta herramienta va un poco más allá de los típicos análisis que realizan el resto de herramientas. Por ejemplo, WAVE detecta si se está empleando alguna de las siguientes características para mejorar la accesibilidad de una página y desaconseja su uso:

• Enlaces invisibles en la misma página: aconseja hacerlos visibles para los usuarios con discapacidad motora.
• Atajos de teclado: desaconseja su uso debido a posibles conflictos con los atajos de otros programas (por ejemplo, los atajos del propio navegador).
• Orden de tabulación indicado: desaconseja su uso debido a irregularidades en su implementación.

La explicación de los distintos iconos que se muestran en los informes de análisis se puede consultar en la página Index of WAVE icons.