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.

Serie "Guía breve": Marcos: use el elemento noframes y títulos con sentido

Consejo 8: Marcos: Use el elemento noframes y títulos con sentido.

Los marcos (frames) son un elemento del HTML que siempre han causado problemas. Tanto es así que en XHTML 1.0 Strict y Transitional no se pueden emplear y tenemos que utilizar XHTML 1.0 Frameset si queremos tener marcos.

En XHTML 1.1 Modularization, si se quieren emplear los marcos se tiene que implementar el módulo Frames que define los elementos frameset, frame y noframes.

¿Qué problemas tienen los marcos? Un par de páginas sobre el tema:

• Los problemas de los marcos
• Problemas con marcos
  
• 9 razones para no utilizar frames (marcos)

¿Y si aún así quiero utilizar los marcos? Pues tendremos algunos problemas de accesibilidad:

1.1 Proporcione un texto equivalente para todo elemento no textual (Por ejemplo, a través de "alt", "longdesc" o en el contenido del elemento). Esto incluye: imágenes, representaciones gráficas del texto, mapas de imagen, animaciones (Por ejemplo, GIFs animados), "applets" y objetos programados, "ascii art", marcos, scripts, imágenes usadas como viñetas en las listas, espaciadores, botones gráficos, sonidos (ejecutados con o sin interacción del usuario), archivos exclusivamente auditivos, banda sonora del vídeo y vídeos. [Prioridad 1]

12.1 Titule cada marco para facilitar su identificación y navegación. [Prioridad 1]

12.2 Describa el propósito de los marcos y como éstos se relacionan entre sí, si no resulta obvio solamente con el título del marco. [Prioridad 2]

Fuente: Pautas de Accesibilidad al Contenido en la Web 1.0, Recomendación W3C de 5 de mayo de 1999

Cada marco debe tener un título y una descripción. Para ello, se tienen que emplear los atributos title y longdesc en la etiqueta <frame>.

Además, se tiene que proporcionar una versión alternativa sin marcos para aquellos agentes de usuario (navegadores) que no sean capaces de interpretar los marcos. Para ello se tiene que emplear la etiqueta <noframes>.

El atributo target

Siempre se aconseja que para mejorar la accesibilidad de las páginas web se deben emplear los estándares. Respecto al HTML, en la actualidad se debe emplear XHTML 1.0 Strict, pero esta elección puede implicar algunos problemas a los desarrolladores, ya que descubrirán que algunos elementos y atributos de HTML no están. Uno de ellos es el atributo target.

El atributo target de HTML se emplea para abrir un enlace en un destino distinto a la ventana actual. Este atributo se puede aplicar a las etiquetas A, AREA, BASE, FORM y LINK. Según HTML 4.01 Specification de W3C:

This attribute specifies the name of a frame where a document is to be opened.

The following target names are reserved and have special meanings.

_blank
The user agent should load the designated document in a new, unnamed window.
_self
The user agent should load the document in the same frame as the element that refers to this target.
_parent
The user agent should load the document into the immediate FRAMESET parent of the current frame. This value is equivalent to _self if the current frame has no parent.
_top
The user agent should load the document into the full, original window (thus canceling all other frames). This value is equivalent to _self if the current frame has no parent.

¿Presenta algún problema de accesibilidad este atributo? Sí, porque la apertura de ventanas nuevas o el uso de marcos puede dificultar la navegación de algunos grupos de usuarios:

10.1 Hasta que las aplicaciones de usuario permitan desconectar la apertura de nuevas ventanas, no provoque apariciones repentinas de nuevas ventanas y no cambie la ventana actual sin informar al usuario. [Prioridad 2]

Fuente: Pautas de Accesibilidad al Contenido en la Web 1.0, Recomendación W3C de 5 de mayo de 1999, Pauta 10. Utilice soluciones provisionales

Por tanto, se debe reducir su uso todo lo posible. Además, XHTML 1.0 Strict no permite su uso. Si queremos utilizarlo, tenemos que emplear XHTML 1.0 Transitional o Frameset.

¿Y cómo está la situación con las nuevas versiones de XHTML?

En XHTML 1.1 Modularization, XHTML 1.0 Strict se divide en una serie de módulos abstractos que agrupan los elementos y atributos relacionados entre ellos. El objetivo es proporcionar la máxima flexibilidad y que un dispositivo (navegador) implemente únicamente aquellos módulos que necesite o que pueda implementar. Con el fin de asegurar cierta consistencia, existen cuatro módulos básicos (core) que son necesarios siempre:

• Structure: define body, head, html y title.
  
• Text: define, entre otras, br, cite, div, h1...h6, p, span, etc.
  
• Hypertext: define a.
  
• List: define dl, dt, dd, ol, ul y li.
  

Existen otros módulos que definen el resto de elementos y atributos de HTML: Applet, Basic Forms, Forms, Basic Tables, Tables, Image, etc.

Si se quiere emplear el atributo target es necesario incluir el módulo Target, que incluye la definición de este atributo para las etiquetas a, area, base, link y form.

Más información: Standards-Compliant New Windows

HTML 5

He encontrado el comentario El HTML 5: el futuro del contenido web. Copio el comentario:

Hoy ha publicado el W3C un borrador del HTML 5, lo que ellos mismos llaman el futuro del contenido web, pero aunque todavía pasará mucho tiempo hasta que este estándar vea la luz (ya sabemos la velocidad que llevan las cosas del W3C), es conveniente empezar a saber que va a suponer el HTML 5, por lo que vamos a responder una serie de preguntas básicas para comenzar a conocer este nuevo estándar.

¿Este nuevo estándar supone cambios para las nuevas guías de accesibilidad?
Por supuesto que no, las guías de accesibilidad son totalmente independientes del estándar (X)HTML que se utilice, por lo tanto lo único que supondrá es añadir un nuevo enlace al nuevo estándar.

¿Se necesitan unos nuevos estándares de HTML?
Personalmente pienso que lo que se necesita es que se cumplan, pero si es verdad que los anteriores son ya muy antiguos y todos sabemos la velocidad a la que se mueve la tecnología en el mundo de la informática.

¿Qué pasará con nuestras páginas realizadas en HTML 4.0 o XHTML 1.0?
Pues es de suponer que si tus páginas cumplen con los estándares correctamente no debe pasar nada, se deben seguir viendo correctamente en los navegadores futuros. Otra cosa es que páginas que no cumplan con los estándares y que ahora se ven bien en un determinado navegador, se sigan viendo bien en un futuro; ésto me parece que va a ser más difícil.

¿Nos aseguraremos que si nuestra página cumple con los estándares HTML 5 se verá por fin correctamente en todos los navegadores?
Pues aunque en la redacción de estos nuevos estándares está trabajando un grupo formado por personas de los principales navegadores, sería muy optimista pensar que nuestra página por cumplir con los estándares HTML 5 se va a ver correctamente en todos los navegadores. Me temo que este problema no será tan fácil de solucionar.

¿Qué características nuevas nos aporta el HTML 5?
Pues según el W3C, algunas de las características más interesantes para los autores son APIs para dibujar gráficos en dos dimensiones, incorporar y controlar contenido de audio y vídeo, mantener persistente en la parte del cliente el almacenamiento de datos y para ofrecer a los usuarios la edición de documentos, o partes de éstos, de forma interactiva. Otras características facilitan la representación de elementos familiares de las páginas, incluyendo (sección) (pie); (para navegación) y (para asignación de un título a una foto u otro contenido incluido en la página).

¿Tendremos que aprender un nuevo lenguaje de etiquetado web?
Pues seguro que no, sólo habrá que ver que etiquetas han cambiado su uso y cuales se han añadido nuevas.

¿Tenemos que empezar a usar HTML 5 en nuestras páginas web?
Ahora mismo ni pensarlo, recordar que en estos momentos es sólo un borrador y con total seguridad sufrirá muchos cambios, por lo que nos queda esperar hasta que se apruebe definitivamente.

JavaScript no molesto (5): validación de formularios

En la entrada JavaScript no molesto (4): separación del JavaScript se explicó cómo aprovechar el atributo class para separar el código JavaScript del código XHTML. En esta entrada se va a explicar cómo utilizar la misma técnica para validar formularios.

Los formularios se deben validar en el navegador por varias razones, las más importantes son:

• Disminuye el tiempo de respuesta de la aplicación: el usuario no tiene que esperar a que se envíen los datos al servidor, se validen en el servidor y se reciba una respuesta para saber si los datos están bien o están mal.
• Se reduce la carga de trabajo del servidor (no del todo, como ahora se explicará): en el servidor no se tienen que validar los formularios de todos los usuarios, en el navegador de cada usuario se validan los datos que ha introducido.

La segunda razón no es verdad en parte, porque SIEMPRE hay que validar los datos que se reciben en el servidor, ya que un usuario malicioso los puede enviar directamente, sin pasar antes por la validación de nuestro formulario. Por tanto, la solución que vamos a ver para separar el JavaScript del XHTML no supone un problema cuando no se dispone de JavaScript, ya que los datos serán validados en el servidor.

Sí que puede haber problemas cuando se emplea JavaScript para actualizar un control del formulario o una página web en función de las acciones del usuario. Por ejemplo, el típico caso de las listas desplegables en cascada (una lista que muestra sus valores en función de lo que se ha elegido en otra lista) realizado con JavaScript no funcionaría si está desactivado. Este problema es distinto al que se explica en esta entrada y merece una para él solo.

Consejo 1: no se debe usar botones de tipo button con el evento onclick para enviar un formulario

El código siguiente presenta un grave problema de accesibilidad: cuando JavaScript no está disponible, el formulario no se puede enviar.

function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}

<input type="button" value="Enviar" onclick="validar()">Para solucionar este problema, se deben emplear los botones de tipo submit y utilizar el evento onsubmit para llamar al código de validación:

function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}

<form action="unapagina.php" onsubmit="return validar()"></form>Consejo 2: utiliza múltiples clases para indicar el tipo de validación que requiere cada control de un formulario

En el artículo A Guide to Unobtrusive JavaScript Validation se presentan técnicas para separar el código JavaScript que realiza la validación de un formulario:

• Utilizar campos ocultos (hidden) para indicar las validaciones que se tienen que realizar (valor requerido, correo electrónico, código postal).
• Utilizar el atributo class para indicar el tipo de validación.
• Crear un DTD propio para añadir atributos que indican el tipo de validación.

La primera opción es poco práctica, ya que no es adecuada para formularios complejos con muchos campos. La tercera opción tampoco es práctica, ya que una página web basada en un DTD propio no es una página válida respecto a XHTML. Por tanto, la opción más recomendable es la segunda.

En el class se pueden añadir valores para indicar el tipo de validación que requiere el control:

• required
• notrequired
• email
• integer
• date

Por ejemplo:

<input type="text" name="correo" class="required email">
Para más información sobre cómo lograr un manejo de formularios correcto con JavaScript:

• A Guide to Unobtrusive JavaScript Validation
• Unobtrusive Javascript
• Javascript no obstructivo, Manual de buenas maneras (traducción al español del anterior)

JavaScript no molesto (4): separación del JavaScript

La entrada de ayer terminaba con la pregunta ¿No se puede separar el código JavaScript del código HTML como se hace con CSS?

Sí, sí que se puede. Una página web se puede construir mediante capas:

• Capa de contenido: la estructura y el contenido con etiquetas de XHTML.
• Capa de presentación: la presentación del contenido definida con CSS.
• Capa de comportamiento: el comportamiento del contenido (por ejemplo, la respuesta ante una acción del usuario) definido con JavaScript.

Con un diseño basado en capas logramos reducir el acomplamiento entre los distintos componentes (contenido, presentación y comportamiento), lo que se traduce en importantes beneficios: disminución de los errores, reducción en los costes de mantenimiento, etc. Pero además, una página web construida de esta forma (que se conoce como progressive enhancement) casi siempre es graceful degradation, y por tanto la página web funcionará correctamente aun en el caso de que falte algún tipo de componente (CSS o JavaScript).

¿Cómo se puede lograr esto? En el código HTML no vamos a escribir ni una sola línea de código JavaScript. Más aun, tampoco se van a emplear los manejadores de eventos como onclick, onblur, etc.

Desde JavaScript, se puede asignar código de JavaScript a un manejador de eventos con el siguiente código:

elemento.evento = acccion;

Para seleccionar un elemento de la página web (una celda en una tabla, un botón en un formulario, un enlace, etc.) se puede emplear:

• getElementById(id): selecciona el emento indicado por el id.
• Usar una combinación de getElementsByTagName(etiqueta) y getAttribute(atributo) para seleccionar elementos con un atributo específico.

En la entrada JavaScript no molesto (3): las ventanas emergentes se puso como ejemplo los enlaces que se abren en ventanas emergentes. Para indicar que un enlace es de este tipo, vamos a añadir al atributo class un valor que no se emplea en el CSS, pero que desde CSS nos va a permitir saber que se trata de una ventana emergente:

<a href="http://www.ua.es/" class="estilo popup">Universidad de Alicante</a>
En el atributo class, el valor estilo se emplea en el CSS para asignar una presentación concreta, mientas que el atributo popup se emplea en JavaScript para identificar los enlaces que se tienen que abrir en ventanas emergentes:

window.onload = prepareLinks;
function prepareLinks() {
  var links = document.getElementsByTagName("a");
  for (var i=0; i= 0) {
      links[i].onclick = function() {
        popUp(this.getAttribute("href"));
        return false;
      }
    }
  }

}

function popUp(winURL) {
  window.open(winURL,"popup","width=320,height=480");
}

En el código anterior se realizan los siguientes pasos:

1. Se asigna al evento onload la función prepareLinks: esta función será llamada automáticamente cuando la página termine de cargarse.
2. La función prepareLinks obtiene un array con todos los enlaces de la página web.
3. Para cada enlace, se comprueba si el atributo class contiene el valor popup.
4. Si el enlace está marcado como popup, le asigna una función de JavaScript al evento onclick.

Para más información sobre cómo lograr la separación del código JavaScript:

• DHTML no intrusivo
• Nociones básicas de JavaScript no intrusivo
• Behavioral Separation
• Unobtrusive Javascript
• Javascript no obstructivo, Manual de buenas maneras (traducción al español del anterior)
• 7 reglas de oro para hacer un javascript no obstructivo

JavaScript no molesto (3): las ventanas emergentes

Una ventana emergente (popup window) es una ventana independiente del navegador que se abre de forma automática (por ejemplo, las molestas ventanas emergentes de publicidad que se abren al cargar una página) o de forma manual como respuesta a una acción del usuario de una página (por ejemplo, al pulsar sobre un enlace).

En el caso de estas últimas, lo normal es que se abran tras pulsar el usuario sobre un enlace o un botón. El uso de botones con el evento onclick se debería evitar, ya que supone una barrera de accesibilidad en el caso de que JavaScript no esté disponible. Por tanto, nos vamos a centrar en las ventanas emergentes activadas al pulsar sobre un enlace.

En el href de un enlace se puede utilizar directamente JavaScript. Por ejemplo, suponiendo que tenemos la función popUp que abre una ventana emergente:

function popUp(winURL) {
window.open(winURL,"popup","width=320,height=480");
}

simplemente tenemos que escribir javascript:popUp('http://www.ua.es/') en la dirección del enlace. También se puede emplear el evento onclick y dejar la dirección en blanco o poner el símbolo "#":

<a href="" onclick="popUp('http://www.ua.es/');">UA</a>Cualquiera de las dos posibilidades impide que los usuarios sin JavaScript puedan acceder al contenido indicado.

La solución es muy sencilla:

• Añadir en el enlace una URL al contenido que se desea visualizar.
• En el código JavaScript, añadir return false; al final para evitar que se ejecute el enlace cuando se ejecute el código JavaScript. La URL del enlace indicada con href sólo será empleada cuando JavaScript no esté disponible.

Con esta solución, la funcionalidad se ve reducida para los usuarios sin JavaScript porque no se abre en una nueva ventana, pero no falla completamente.

La solución anterior se puede mejorar para evitar el tener que repetir la URL tanto en el enlace como en el evento onclick:

<a href="http://www.ua.es/" onclick="popUp(this.getAttribute('href')); return false;">UA</a>o también:

<a href="http://www.ua.es/" onclick="popUp(this.href); return false;">UA</a>Pero esta solución aún se puede mejorar más, ya que el código JavaScript está escrito directamente en las etiquetas HTML, lo cual ocasiona algunos problemas:

• Dificulta la escritura.
• Dificulta la lectura.
• Dificulta el mantenimiento.

¿No se puede separar el código JavaScript del código HTML como se hace con CSS?

Página con muchos recursos

Acabo de encontrar la página web Web Design References: Accessibility. Es una página web muy buena, ya que contiene multitud de enlaces a páginas web donde explican temas relacionados con la accesibilidad. Los temas que contiene son:

• Abbreviations & Acronyms
• Accessibility Statements
• Accesskeys
• Alt Attributes , Alt Text, Long Descriptions
• Assistive Technology
• Baseline
• Benefits (Why accessibility?)
• Captcha (Completely Automated Public Turing test to tell Computers and Humans Apart)
• Checklists
• Cognitive Disabilities
• Definitions and Overviews
• Device Independence and Graceful Degradation
• Deprecated Features
• Flicker
• Forms
• Language
• Law, Lawsuits, Policies
• Lists
• Mailto
• Multimedia
• Open Source
• Plugins, PDF, PowerPoint, etc.
• Relative sizing
• Scripts
• Structure & Semantics
• Style Sheets (Accessibility)
• Tables
• Testing, Checking, Validating
• Text Links
• Text Only Versions
• Usability and Accessibility
• Zoom Layouts
• Articles & Related Links

JavaScript no molesto (1): Definición

El término JavaScript no molesto es la traducción del inglés unobtrusive JavaScript. En muchas páginas (por ejemplo, en la Wikipedia) aparece mal traducido como JavaScript no obstructivo o no intrusivo. Ni obstructivo ni intrusivo existen en el Diccionario de la lengua española de la Real Academia Española, por lo que no se deben usar. Unobtrusive se traduce al español como discreto o no molesto.

La Wikipedia contiene la definición de JavaScript no obstructivo:

JavaScript no obstructivo es un paradigma floreciente en el uso del lenguaje de programación JavaScript, utilizado en la Web. Aunque el término no se define formalmente, sus principios generalmente incluyen:

• Separación de la funcionalidad JavaScript (la "capa del comportamiento") de las capas de estructura/contenido y de presentación de un página.
• Uso de buenas prácticas a fin de evitar los problemas de incompatibilidad de la programación tradicional en JavaScript (tales como inconsistencias entre navegadores y falta de escalabilidad).

El objetivo final es que las páginas web sean totalmente funcionales para aquellos usuarios que no puedan o no quieran hacer uso de JavaScript.

Cuando escribí sobre Hijax: Ajax accesible ya comenté que 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 navegadores antiguos.

¿Hay gente que navega por Internet y su navegador no admite JavaScript? En la página Browser Statistics podemos ver que en enero de 2007 había un 6% de usuarios sin JavaScript.

Pero los beneficios no son sólo para los posibles visitantes de nuestro sitio web: nosotros mismos nos beneficiaremos al tener separados la estructura de la página (HTML), la presentación (CSS) y la lógica (JavaScript). Los costes de mantenimiento de una página web son menores si lo tenemos todo bien separado y en su sitio.

¿Qué se tiene que hacer para tener JavaScript no molesto? En próximas entradas comentaré algunas de las técnicas más comunes. Recomiendo la lectura de la página Javascript no obstructivo, Manual de buenas maneras, que ofrece una extensa explicación del tema.

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:

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:

• Porqué el diseñar con tablas es estúpido: problemas definidos, soluciones ofrecidas
• CSS Layout Techniques: for Fun and Profit

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:

• Evitando el “click aquí”: el arte de enlazar, traducción al castellano del artículo Don't Click Here: The Art of Hyperlinking.
• Enlazar es importante.
• Affordance: un botón es un botón

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

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

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

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.

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.

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