Buscador

Mostrando entradas con la etiqueta WAI. Mostrar todas las entradas
Mostrando entradas con la etiqueta WAI. Mostrar todas las entradas

jueves, 9 de octubre de 2008

Guía breve para crear sitios web accesibles según WCAG 2.0

Con WCAG 1.0 se publicó la Guía breve para crear sitios web accesibles (Quick Tips to Make Accessible Web Sites), que era un resumen de los aspectos más importantes de las pautas.

Con WCAG 2.0 se ha publicado Web Accessibility Quicktips: WCAG 2.0 at a Glance que proporciona un resumen de la versión 2.0 de las pautas de accesibilidad:
Perceivable
  • Provide text alternatives for non-text content.
  • Provide captions and alternatives for audio and video content.
  • Make content adaptable; and make it available to assistive technologies.
  • Use sufficient contrast to make things easy to see and hear.
Operable
  • Make all functionality keyboard accessible.
  • Give users enough time to read and use content.
  • Do not use content that causes seizures.
  • Help users navigate and find content.
Understandable
  • Make text readable and understandable.
  • Make content appear and operate in predictable ways.
  • Help users avoid and correct mistakes.
Robust
  • Maximize compatibility with current and future technologies.
No conozco una traducción oficial del W3C al castellano, así que aquí ofrezco la mía:

Perceptible
  • Proporciona texto alternativo para el contenido no textual.
  • Proporciona subtítulos y otras alternativas para el contenido de audio y vídeo.
  • Crea contenido adaptable y que esté disponible a las ayudas técnicas.
  • Utiliza el suficiente contraste para lograr que el contenido sea fácil de ver y oír.
Operable
  • Haz que todas las funcionalidades sean accesibles a través del teclado.
  • Proporciona a los usuarios el tiempo suficiente para leer y utilizar el contenido.
  • No utilices contenido que cause convulsiones.
  • Ayuda a los usuarios a navegar y buscar el contenido.
Comprensible
  • Haz que el texto sea legible y comprensible.
  • Haz que el contenido aparezca y funcione de forma previsible.
  • Ayuda a los usuarios a evitar y corregir los errores.
Robusto
  • Maximizar la compatibilidad con las actuales y futuras tecnologías.

viernes, 3 de octubre de 2008

Lista de verificación de la accesibilidad de IBM

Acabo de encontrar la lista de verificación de la accesibilidad de IBM (IBM Web accessibility checklist - version 3.5). Esta lista contiene 16 puntos:

  1. Imágenes y animaciones. Utiliza el atributo alt="text" para proporcionar textos equivalentas para las imágenes. Utiliza alt="" para las imágnes que no transmiten información importante o que expresan información redundante.
  2. Mapas de imagen. Utiliza mapas de imagen del lado del cliente y proporciona un texto alternativo para cada zona sensible del mapa de de imagen. Si es imprescindible emplear un mapa de imagen del lado del servidor, proporciona enlaces textuales equivalentes.
  3. Gráficos y tablas. Resume el contenido de cada gráfico y cada tabla, o emplea el atributo longdesc para enlazar con una descripción de los datos.
  4. Multimedia. Proporciona subtítulos o transcripciones para el contenido sonoro que sea importante. Proporciona transcripciones o descripciones sonoras del contenido en vídeo que sea importante.
  5. Scripts. Asegura que la funcionalidad de los scripts es accesible mediante teclado. Si el contenido afectado por un script no es accesible, proporciona alternativas.
  6. Applets, plug-ins y contenido no basado en HTML. Cuando sea necesario que aparezca un applet, un plug-in u otra aplicación, proporciona un enlace que sea directamente accesible, o proporciona un contenido alternativo en aquellos casos que no sea directamente accesible.
  7. Formularios. Diseña formularios accesibles a las ayudas técnicas.
  8. Saltar al contenido principal. Proporciona métodos para saltarse los enlaces de navegación y llegar al contenido principal de la página.
  9. Marcos. Proporciona un título para cada marco. Emplea un contenido accesible en cada marco.
  10. Encabezados de tabla. Utiliza el elemento th para marcar los encabezados de tabla. Utiliza el atributo headers en las celdas de las tablas complejas.
  11. Hojas de estilo en cascada. Las páginas web se deben de poder leer sin necesitar las hojas de estilo.
  12. Color y contraste. Asegura que toda la información expresada mediante colores también es transmitida en ausencia de color.
  13. Parpadeos, movimientos y destellos del contenido. Evita que el contenido tenga parpadeos, destellos o se mueva.
  14. Respuestas dependientes del tiempo. Cuando sea necesario una respuesta dependiente del tiempo, avisa al usuario y proporciona el tiempo suficiente para indicar que se necesita más tiempo.
  15. Página de solo texto. Si la accesibilidad no se puede lograr de otra forma, proporciona una versión de solo texto con información y funcionalidad equivalente. Actualiza el contenido de la versión de solo texto cada vez que la página principal cambie.
  16. Verifica la accesibilidad. Comprueba la accesibilidad con las herramientas que existen.
Además, también existe una comparativa entre la lista de IBM, la lista del WAI y la lista de la Sección 508: IBM Web Accessibility Checklist, W3C Web Content Accessibility Guidelines (WCAG) and US Section 508.

lunes, 5 de mayo de 2008

WCAG 2.0 Candidata a Recomendación

Con fecha 30 de abril, el W3C ha anunciado que las Pautas de Accesibilidad al Contenido en la Web (WCAG) 2.0 tienen la consideración de "Candidata a Recomendación" (Candidate Recommendation) y están listas para que los desarrolladores y diseñadores las prueben sobre el contenido y las aplicaciones web.

Por fin parece que dentro de poco tendremos la versión definitiva. Parece que se han adelantado, ya que en una entrada anterior (¿Cómo va WCAG 2.0?) comentaba que se esperaba que estuviera disponible durante del último trimestre de 2008.

lunes, 17 de marzo de 2008

Abreviaturas y acrónimos

Antes que nada, ¿qué es una abreviatura y qué es un acrónimo? Consultemos el diccionario de la Real Academia Española:
abreviatura.

(Del lat. abbreviatūra).

1. f. Tipo de abreviación que consiste en la representación gráfica reducida de una palabra mediante la supresión de letras finales o centrales, y que suele cerrarse con punto; p. ej., afmo. por afectísimo; Dir.a por directora; íd. por ídem; SS. MM. por Sus Majestades; D. por don.

acrónimo.

(Del gr. ἄκρος, extremo, y -ónimo).

1. m. Tipo de sigla que se pronuncia como una palabra; p. ej., o(bjeto) v(olante) n(o) i(dentificado).

2. m. Vocablo formado por la unión de elementos de dos o más palabras, constituido por el principio de la primera y el final de la última, p. ej., ofi(cina infor)mática, o, frecuentemente, por otras combinaciones, p. ej., so(und) n(avigation) a(nd) r(anging), Ban(co) es(pañol) (de) (crédi)to.


¿Qué problema de accesibilidad tienen las abreviaturas y acrónimos? Recordemos la lectura de la condena contra RTVE en el 2003 por Alfredo Urdaci que leyó "Ce Ce O O" en vez de Comisiones Obreras y la mitad de los televidentes no entendieron nada. Pues eso mismo ocurre con las abreviaturas y acrónimos y los lectores de pantalla: si no se indica nada, lo leen de forma literal, letra a letra, lo que dificulta su entendimiento muchas veces. En Dive Into Accessibility: Day 17: Defining acronyms nos explican muy bien los problemas que existen.

¿Qué nos dice el W3C? En la Pauta 4, Identifique el idioma usado de las Pautas de Accesibilidad al Contenido en la Web 1.0 dice:
4.2 Especifique la expansión de cada abreviatura o acrónimo cuando aparezcan por primera vez en el documento. [Prioridad 3]
Por ejemplo, en HTML, use el atributo "title" de los elementos "ABBR" y "ACRONYM". Proporcionar la expansión en el cuerpo principal del documento también ayuda a la usabilidad del documento.
¿Y para qué sirven las etiquetas ABBR y ACRONYM? En Especificación HTML 4.01 del W3C, en el apartado 9.2.1 Elementos de frase: EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, y ACRONYM nos explican la utilidad de estas dos etiquetas:
ABBR:
Indica una forma abreviada (p.ej., WWW, HTTP, URI, Mass., etc.).
ACRONYM:
Indica un acrónimo (p.ej., WAC, radar, etc.).

Los elementos ABBR y ACRONYM permiten a los autores indicar claramente la aparición de abreviaturas y acrónimos. Los idiomas occidentales hacen uso extensivo de acrónimos tales como "GmbH", "NATO", y "F.B.I.", así como de abreviaturas como "M.", "Inc.", "et al.", "etc.". Tanto en chino como en japonés se utilizan mecanismos de abreviación análogos, por los cuales las referencias subsiguientes a un nombre largo se realizan con un subconjunto de los caracteres Han del nombre original. Al marcar estas estructuras se proporciona información útil a los agentes de usuario y a herramientas tales como correctores ortográficos, sintetizadores de voz, sistemas de traducción e indexadores de motores de búsqueda.

El contenido de los elementos ABBR y ACRONYM especifica la expresión abreviada, tal y como aparece en el texto. Puede utilizarse el atributo title de estos elementos para proporcionar la forma completa o expandida de la expresión.

[...]

Obsérvese que las abreviaturas y los acrónimos tienen a menudo pronunciaciones idiosincráticas. Por ejemplo, mientras que "IRS" y "BBC" se suelen pronunciar letra por letra, "OTAN" y "UNESCO" se pronuncian fonéticamente. Y hay otras formas abreviadas (p.ej., "URI" y "SCSI") que algunas personas deletrean y que otras pronuncian como palabras. Cuando sea necesario, los autores deberían usar hojas de estilo para especificar la pronunciación de una forma abreviada.

Por tanto, tenemos que etiquetar las abreviaturas con la etiqueta <abbr> y los acrónimos con la etiqueta <acronym>. Con el atributo title indicamos la expansión de las abreviaturas y acrónimos, que será empleada por los agentes de usuario (navegadores, lectores de pantalla, etc.) para mostrarla al usuario

¿Todos los navegadores y lectores de pantalla interpretan correctamente estas dos etiquetas? Desgraciadamente, NO. En las páginas del SIDAR Abreviaturas versus acrónimos y Abreviaturas versus acrónimos: resultados de la comparativa podemos encontrar un amplio estudio donde se analiza la interpretación de estas dos etiquetas por parte de algunos navegadores (Opera, Internet Explorer, Netscape) y lectores de pantalla (JAWS, NVDA, IBM HomePageReader). Desgraciadamente, este análisis no está actualizado y es de hace unos años.

¿Cómo va WCAG 2.0?

El 11/12/2007 se publicó el último borrador de WCAG 2.0 y se abrió el plazo para el envío de comentarios.

Según nos cuenta Alan Chuter en Progreso de WCAG 2.0, se están resolviendo los más de 200 comentarios que se recibieron y se espera que "el último borrador de WCAG 2.0 (llamada “Propuesta de Recomendación”) podría estar disponible en el último trimestre del 2008".

Más información:

viernes, 7 de marzo de 2008

Internet Explorer 8 tendrá soporte de WAI-ARIA

Acabo de encontrar el artículo Soporte para WAI-ARIA en Internet Explorer 8.

Hace unos meses hablé sobre WAI-ARIA: una iniciativa del W3C para estudiar y solucionar los problemas que presentan las páginas web actuales que se basan en contenido dinámico, como por ejemplo las páginas web que emplean AJAX.

En WAI-ARIA se emplean los conceptos rol, estado y propiedad para indicar el funcionamiento de los elementos de una página web y comunicar esta información a las ayudas técnicas (lectores de pantalla, por ejemplo). Pero si un navegador no reconoce estos nuevos conceptos, de nada servirá que los incluya el diseñador en la página web.

Según el artículo que comento, el próximo Microsoft Internet Explorer 8 incluirá soporte para WAI-ARIA. Más información: Internet Explorer 8 Beta 1 Whitepapers, W3C’s ARIA Support

martes, 12 de febrero de 2008

La accesibilidad web y los dispositivos móviles

Normalmente la accesibilidad web se asocia con la idea de desarrollar páginas web que puedan ser utilizadas por las personas con discapacidad.

Sin embargo, hoy en día la accesibilidad web no está orientada exclusivamente a las personas con discapacidad. Con el aumento del uso de los dispositivos móviles que permiten el acceso a la Web con las mismas prestaciones que desde un ordenador, la accesibilidad web pasa a significar que la Web es única (no diferentes versiones según el dispositivo o el navegador que se utilice) y universal (utilizable independientemente de las características del usuario).

Debido a ello, el W3C está desarrollando actividades para fomentar que las páginas web sean totalmente accesibles, incluyendo en esta accesibilidad los dispositivos móviles.

Más información:

jueves, 20 de diciembre de 2007

Vídeos sobre accesibilidad web

Tres vídeos de un seminario sobre la accesibilidad web. El contenido está bien, pero el sonido es muy malo.



jueves, 13 de diciembre de 2007

Legibilidad de una página web

En ¿Tu Sitio es Entendible y Fácil de Leer? nos presentan la herramienta TxReadability (versión en español) que evalúa la facilidad de lectura de una página web, para textos en español, inglés y japonés.

El W3C, en la pauta 14 de sus Pautas de Accesibilidad al Contenido en la Web 1.0 nos dice:
Pauta 14. Asegúrese de que los documentos sean claros y simples.

Asegure que los documentos son claros y simples para que puedan ser más fácilmente comprendidos.

La maquetación coherente de páginas, los gráficos reconocibles y el lenguaje fácilmente comprensible benefician a todos los usuarios. En particular, ayudan a personas con discapacidades cognitivas o con dificultades en la lectura. (Por tanto, asegúrese de que las imágenes tienen textos equivalentes para los ciegos, los de baja visión o para cualquier usuario que no puede o ha elegido no ver los gráficos. Consulte también la pauta 1).

La utilización de un lenguaje claro y simple promueve una comunicación efectiva. El acceso a la información escrita puede ser difícil para personas con discapacidades cognitivas o de aprendizaje. La utilización de un lenguaje claro y simple también beneficia a las personas cuyo primer idioma es diferente al del autor, incluidos aquellos que se comunican principalmente mediante lengua de signos.

Puntos de verificación:

14.1 Utilice el lenguaje apropiado más claro y simple para el contenido de un sitio. [Prioridad 1]
Técnicas para el punto de verificación 14.1.

14.2 Complemente el texto con presentaciones gráficas o auditivas cuando ello facilite la comprensión de la página. [Prioridad 3]
Consultar también la pauta 1.
Técnicas para el punto de verificación 14.2.

14.3 Cree un estilo de presentación que sea coherente para todas las páginas. [Prioridad 3]
Técnicas para el punto de verificación 14.3.
Esta herramienta nos puede ayudar a cumplir esta pauta.

Nuevo borrador de WCAG 2.0

Con fecha 11/12/07 se ha publicado un nuevo borrador de las Web Content Accessibility Guidelines 2.0. La fecha límite para enviar comentarios es el 01/02/08. ¿Para cuándo la recomendación definitiva?

En la entrada ¿Qué pasa con WCAG 2.0? comenté los problemas que está teniendo esta nueva recomendación.

domingo, 11 de noviembre de 2007

Serie "Guía breve": Figuras y diagramas

Consejo 6: Figuras y diagramas: Describalos brevemente en la pagina o use el atributo longdesc.

Este consejo está relacionado con el consejo 1 Imágenes y animaciones. El uso del atributo longdesc lo comenté hace tiempo en otra entrada:
El atributo longdesc complementa al atributo alt y se emplea para ofrecer una descripción más larga del elemento que la proporcionada por el atributo alt. Las etiquetas de XHTML que admiten este atributo en la versión 1.0 son: img, iframe y frame. Su valor tiene que ser una Uniform Resource Identifier (URI), la dirección de un recurso en Internet.

Mientras que el atributo alt contiene el texto alternativo de la imagen, el atributo longdesc contiene una dirección de Internet a otra página web o a la misma página web donde se encuentra la descripción larga de la imagen. El atributo longdesc se emplea en situaciones donde la descripción es muy larga para ser incluida en el atributo alt, por ejemplo, cuando la imagen es un cuadro o un gráfico.
¿Los navegadores actuales utilizan el atributo longdesc? Ni Internet Explorer 7, ni Firefox 2, ni Opera 9 lo soportan. Incluso Amaya, el navegador oficial del W3C, lo utiliza.

Pero sí que existe un complemento para Firefox llamado Longdesc que añade al menú contextual (botón derecho del ratón) una nueva opción llamada View Image Longdesc que permite navegar a la URL que tenga asignada la imagen, como podemos ver en la siguiente imagen que es una captura de la página firefox longdesc extension - demo page del autor del complemento:

sábado, 10 de noviembre de 2007

WAI-ARIA

Acabo de encontrar la página Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap) del W3C. ¿Qué es esto? Es una iniciativa del W3C para estudiar y solucionar los problemas que presentan las páginas web actuales que se basan en contenido dinámico, como por ejemplo las páginas web que emplean AJAX. Otra página donde se puede leer una introducción a este tema es Accessible Rich Internet Applications Suite (WAI-ARIA) Overview.

Las páginas web, mejor dicho, los sitios web que contienen contenido dinámico que se actualiza en el cliente (navegador) sin tener que recargar la página se conocen como Rich Internet Applications. En español se puede traducir como Aplicaciones ricas de Internet.

viernes, 9 de noviembre de 2007

Serie "Guía breve": Organización de las páginas

Consejo 5: Organización de las páginas: Use encabezados, listas y estructura consistente. Use CSS para la maquetación donde sea posible.

Las páginas web tienen que estar correctamente estructuradas. Para ello, se tienen que explear las etiquetas de HTML que definen la estructura de una página, como son:

<title>, <h1>, <h2>, ..., <ul>, <ol>, <p>, <blockquote>

Toda página web debe tener un título definido con la etiqueta title que resuma el contenido o la función de la página.

El contenido de las páginas se tiene que estructurar con las etiquetas de encabezado h1, h2, ... La mayoría de los lectores de pantalla y algunos navegadores como Opera permiten al usuario desplazarse dentro de una página web "saltando" de un encabezado a otro encabezado. Eso permite llegar de una forma más rápida a la información que se busca. Por ejemplo, la siguiente página web está estructurada en diversos apartados: Presentación, Formación académica, Investigación, Docencia, Libros, etc.





En la siguiente imagen de Fangs, que simula el comportamiento de un lector de pantallas, podemos observar la lista de encabezados (Heading list) de la página anterior. Cada encabezado lleva asociado un número que indica en nivel de encabezado (del 1 al 6).




Para maquetar una página web nunca se deben utilizar las tablas, ya que suponen un grave problema de accesibilidad. Una página web se puede y debe maquetar con CSS y obtener el mismo resultado que se obtendría con tablas. Un par de enlaces sobre cómo maquetar sin tablas:

miércoles, 7 de noviembre de 2007

Serie "Guía breve": Enlaces de hipertexto

Consejo 4: Enlaces de hipertexto: Use texto que tenga sentido leído fuera de contexto. Por ejemplo, evite "pincha aquí".

Algunos navegadores y algunos los programas de ayuda que emplean las personas con discapacidad (por ejemplo, los lectores de pantalla) ofrecen al usuario la posibilidad de mostrar, normalmente una ventana aparte, la lista de enlaces que contiene una página web. Esta lista de enlaces normalmente permite activar un enlace y navegar a la página de destino. Si el texto de un enlace no tiene sentido fuera de su contexto, el enlace no tendrá sentido en esta lista de enlaces.

Por otro lado, si los enlaces poseen un estilo especial para resaltarlos, los usuarios suelen fijar su atención en ellos, por lo que es importante que el texto de los enlaces sea lo más claro y significativo.

Por ejemplo, elPeriódico.com tiene una sección llamada Encuestas en la que se muestran todas las encuestas que existen. Cada encuesta tiene un enlace asociado con el texto Ver Resultados para visualizar los resultados de la encuesta seleccionada, como podemos ver en la siguiente imagen:



El complemento Fangs para Firefox que simula el comportamiento de un lector de pantalla posee una ventana para visualizar los enlaces que contiene una página web. En la siguiente imagen podemos ver la lista con los primeros enlaces (Portada, Opinión, Internacional, etc.) de la página web mostrada anteriormente:



Como todas las encuestas tienen un enlace con el texto Ver Resultados, cuando se consulta la lista de enlaces no se sabe a qué encuesta se refiere cada enlace, como podemos observar en la siguiente imagen:


Por tanto, esta página presenta un grave problema de accesibilidad, ya que no se puede seleccionar un enlace en la lista de enlaces.

Para finalizar, unos breves consejos para escribir enlaces correctos:

  • Tiene que ser claro y corto, pero no tan corto que sea casi inapreciable para el usuario cuando lo escuche.
  • Tiene que tener sentido fuera de contexto, por ejemplo, cuando se lea él sólo o como parte de una lista de enlaces de una página.
  • Tiene que tener sentido en el contexto, por ejemplo, cuando se lea como parte del resto de la página.

Para ampliar estos consejos, recomiendo la lectura de los siguientes artículos:

(Actualización 22/11/2007) También hay gente que defiende lo contrario: si le dices a la gente "pulsa aquí" (click here) aumentará el porcentaje de usuarios que lo hagan. Además, ayuda a los usuarios poco familiarizados con la navegación web. Lo explican en el artículo Does Telling Someone to “Click Here” Actually Matter?.

(Actualización 30/11/2008) El artículo Enlaces para “leer más” que sean simples y accesibles explica cómo emplear CSS para solucionar el problema de los enlaces poco descriptivos.

domingo, 4 de noviembre de 2007

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:

(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:
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.

viernes, 2 de noviembre de 2007

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:

miércoles, 31 de octubre de 2007

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).

viernes, 25 de mayo de 2007

¿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.

viernes, 18 de mayo de 2007

¿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.