La validación de sus documentos HTML es quizá lo más sencillo e importante que el autor puede hacer para ayudar a la accesibilidad. Un validador compara el HTML de un documento contra un documento modelo definido para asegurar que la sintaxis del HTML es correcta.
Olvidar unas comillas o poner valores de atributo erróneos es algo muy común de hacer cuando se escribe HTML. Si bien muchos navegadores se recuperan de estos errores de autoría, la manera en que lo hacen tiende a diferir y hasta las nuevas versiones de un mismo navegador pueden cambiar sus métodos de recuperación. Un buen ejemplo es el cambio de comportamiento entre Netscape 1.22 y Netscape 2.0; al Netscape 1.22 no le importa si el autor olvida las comillas de cierre en códigos como <A HREF="oops.html>Oops</A>, pero el Netscape 2.0 sí necesita las comillas de cierre. Un documento que ha sido validado lucirá perfecto bajo cualquier navegador, pero un documento cuyo autor sólo lo ha checado visualmente con el Netscape 1.22 seguramente perderá la mitad de su contenido en el Netscape 2.0.
Debería utilizar el WDG HTML Validator para checar sus páginas Web. Sea cauteloso con programas que falsamente dicen ser validadores; aunque los verificadores de ortografía o sintaxis son herramientas valiosas, ellas no sustituyen la validación del HTML.
En todo lo posible, las páginas Web deberán ser independientes de cualquier plataforma, lo que significa que ellas serán accesibles sin tomar en cuenta la plataforma del usuario ni su configuración. Aunque la validación sea un paso clave para asegurar la independencia de la plataforma, ella sola no es suficiente. Los autores también deberán tomar precauciones para que sus páginas Web no dependan de cierta resolución, intensidad de color, tamaño de la fuente o de la ventana.
A los autores preocupados por la accesibilidad de sus documentos se les invita a que vean sus páginas en diferentes resoluciones, intensidades de colores, tamaños de fuentes o ventanas. Las páginas bien elaboradas se ajustarán y permanecerán accesibles para cualquier ambiente de navegadores. Los autores también pueden comparar sus páginas Web en diferentes navegadores (sin dejar de incluir algún navegador de sólo texto como el Lynx) y pedir a un amigo que las lea en voz alta, para simular lo que escucharía un ciego o quien tenga un sistema de navegación en movimiento. Dos herramientas de utilidad para los autores, durante la evaluación de la independencia de plataforma de un sitio, son Web Page Purifier y Web Page Backward Compatibility Viewer (Purificador de Páginas Web y Visualizador de Compatibilidad de Páginas Web).
Dado que mucha gente accede a la Web por diferentes medios, deberán evitarse frases que crean dependencia de la plataforma. Por ejemplo "haz click aquí" es inapropiada para alguien sin un ratón, también es inútil cuando el ancla de un enlace se lee en voz alta o se imprime al final del documento como resumen. Los autores también deben evitar frases como "ver abajo" ya que "abajo" carece de sentido cuando un documento se lee en voz alta.
Cuando escriban HTML, los autores deben concentrarse en la estructura del documento más que en su presentación. Un documento marcado estructuralmente puede adaptarse con toda facilidad a los diferentes navegadores del ambiente. Cuando compongan para HTML, los autores deben concentrase en el significado del contenido en vez de en como lucirá. Si quiere que el texto esté en negritas, medite en el porqué quiere ese estilo; si lo que pretende realmente es expresar énfasis o fuerte énfasis, use los elementos de HTML EM o STRONG.
Frecuentemente se abusa del elemento FONT cuando se trata de expresar un énfasis fuerte o poner un encabezado. En lugar de <FONT COLOR=red>¡Cuidado!</FONT>, use <STRONG CLASS=warning>¡Cuidado!</STRONG> con .warning { color: red; background: transparent } estipulado en una hoja de estilo.
Algunos atributos de presentación de HTML, como ALIGN, pueden usarse sin riesgos en las sugerencias de presentación. En general, las hojas de estilo ofrecen una solución más flexible que favorecen tanto a los autores como a los usuarios. Para conservar la accesibilidad, los documentos nunca deben ser dependientes de una presentación en particular, incluyendo las realizadas con las hojas de estilo.
Cuando usen los elementos IMG o AREA, los autores siempre deberán incluir el atributo ALT para ofrecer un texto alterno. El atributo ALT es obsequiado a aquellos usuarios de la Web que no cargan imágenes --se estima que son un 30%.
El atributo ALT debe usarse mejor para comunicar la función de la imagen que para hacer la descripción de ella. Por ejemplo, ALT="Bienvenido al Web Design Group" es más útil para los que no cargan imágenes que ALT="logo del Web Design Group". De esta forma, para la mayoría de los usuarios de navegadores de sólo texto como el Lynx las imágenes pasarán inadvertidas, a no ser que la imagen tenga contenido que no pueda ser reemplazado completamente con texto, como en el caso de un álbum fotográfico o galería de arte. En estos casos función y descripción de la imagen son en esencia lo mismo, por lo tanto una descripción de la imagen será apropiada para el texto de ALT.
Las imágenes que solamente son decorativas deberán usar ALT="" para indicar explícitamente que la imagen carece de contenido. Las balitas decorativas deben reemplazarse con ALT="*" o algo similar --no con ALT="Balita redonda amarilla". Cuando las imágenes se encuentran a lo largo del texto o de otras imágenes, puede ser necesaria alguna forma de separación, como ALT=" [Mi fotografía] " o ALT="Web Design Group ~".
Para una discusión más completa del atributo ALT, vea el artículo Uso de textos ALT en IMGs.
Las imágenes de texto son muy comunes en la Web, pero pueden ser dificultosas para quienes tienen una vista débil o monitores pequeños con altas resoluciones. En HTML, el texto es dimensionado de acuerdo al tamaño de la fuente preferida por el usuario, pero cuando se usan imágenes de texto es el autor quien elige en pixeles el tamaño absoluto de la fuente no el usuario. Como cada usuario tiene sus propios gustos, tratar de adivinar un tamaño de fuente adecuado no resulta buena idea. Por estas razones, se deben evitar las imágenes de texto cuanto sea posible.
A menudo pueden usarse las Hojas de Estilo en Cascada para ofrecer textos atractivos sin necesidad de hacerlo con imágenes. Con las CSS, el autor puede sugerir numerosas propiedades físicas del texto, como son fuente, color, fondo, espaciado entre letras y otras.
Los mapas de imagen son problemáticos por su pobre soporte para quienes no carguen imágenes. En tanto sea posible, cuando use mapas de imágenes, use un mapa de imagen del lado del cliente en combinación con un mapa de imagen del lado del servidor. Con mapas de imagen del lado del cliente, siempre deberá usarse el atributo ALT del elemento AREA.
Los mapas de imagen deben evitarse cuando su uso no sea "natural". Por ejemplo, la mayoría de las barras gráficas de herramientas podrían ser creadas más fácil y eficientemente utilizando un número de imágenes separadas o simplemente con texto. En cambio, un mapa de imagen para hacer enlaces a los órganos del cuerpo o las regiones de un país, será más natural y menos forzado que la barra gráfica de herramientas común en la Web. Si es factible, un texto alterno sería de mucha ayuda para estos casos.
Si establece colores con los atributos HTML de BODY, el autor deberá especificar todos los atributos de color. Si especifica sólo uno o algunos atributos de entre BGCOLOR, TEXT, LINK, VLINK y ALINK, se arriesga a crear un documento inaccesible, ya que si el usuario cambia colores seguramente algunos serán ilegibles contra los escasos colores que especificó. En este caso el autor no fuerza a que el usuario tenga la misma configuración que su navegador.
Los colores de BODY siempre deben especificarse con una tríada hexadecimal de la forma #rrggbb o #RRGGBB, porque los navegadores viejos no soportan nombres de colores (tampoco nombres de caracteres especiales). Netscape 1.22 interpreta todos los nombres de colores como azul.
Los autores que especifiquen una imagen como fondo, usando el atributo BACKGROUND en BODY, también deben especificar todos los atributos de color. Asegúrese de elegir un BGCOLOR que haga legible los colores de texto, ya que quienes no carguen imágenes verán el color de fondo en vez de la imagen de fondo.
Generalmente, el elemento FONT de HTML (y su socio BASEFONT) deben evitarse para crear sitios Web accesibles. A la par que especificaciones de atributo como SIZE="+1" o SIZE="-1" son relativamente inútiles, los tamaños absolutos como SIZE=1 pueden originar textos de letras muy pequeñas para poder leerse. En cambio, las hojas de estilo permiten a los autores sugerir cambios relativos en el tamaño de una fuente con mucha mayor flexibilidad que si se engloban bajo FONT.
El atributo COLOR del elemento FONT deberá evitarse siempre, ya que muchos navegadores que lo soportan respetan todavía el color de la fuente cuando el usuario intenta de anular los colores especificados por el autor. Como resultado se puede obtener un documento ilegible si el color de la fuente no contrasta bien contra el fondo seleccionado por el usuario.
Puede ser que el atributo FACE del elemento FONT tampoco sea anulado por el usuario en algunos navegadores que lo soporten. Pero puede ocasionar que el navegador elija una fuente muy difícil de leer, dependiendo de la plataforma y de la configuración. Recuerde que la misma fuente va a verse muy diferente en plataformas distintas a la suya.
El atributo FACE tampoco debe usarse para tratar de mostrar letras griegas, símbolos matemáticos o figurillas. El elemento FONT solamente sugiere una presentación, de manera que el contenido debe permanecer intacto aún en ausencia de esta presentación. Los navegadores, por ejemplo, no deberían visualizar <FONT FACE=Symbol>a</FONT> como la letra griega alfa; este es un defecto que debe corregirse en el futuro.
Para una discusión más a fondo sobre el atributo FACE, vea <FONT FACE> considerada dañina. Otra excelente discusión sobre el elemento FONT se encuentra en ¿Qué es incorrecto con FONT? de Warren Steel.
Los autores deben evitar en todo lo posible el uso de tablas sólo para formatear la página. Desafortunadamente, evitarlo en su totalidad limita la flexibilidad del autor; los métodos de formateo de las CSS no están lo suficientemente bien soportados como para reemplazar definitivamente a las tablas. Se recomienda a los autores que, cuando usen tablas para formatear, tomen en cuenta las siguientes sugerencias:
JavaScript (JScript o VBScript) no es soportado por todos los navegadores, además de que algunos usuarios pueden decidir desactivarlo. Por eso, cuando se use JavaScript no debe confiársele todo.
Por ejemplo, cuando usen JavaScript para que la ventana de un enlace emerja y se abra, los autores no deben utilizar:
<A HREF="javascript:window.open('foo.html', 'popup', 'scrollbars,resizable,width=300,height=120')">
ya que el enlace fallará para quienes no tengan habilitado JavaScript. En cambio lo siguiente sí funcionará en todos los navegadores:
<A HREF="foo.html" ONCLICK="if (window.open) { window.open('foo.html', 'popup', 'scrollbars,resizable,width=300,height=120'); return false; }">
Índice de Accesibilidad ~ ¿Por Qué Escribir Páginas Accesibles? ~ Mitos de Accesibilidad
Copyright © 1997-2002 Liam Quinn. Derechos reservados.