Usable y accesible

Descripción extensa de una imagen: accesible con lector de pantalla y visible sin imágenes activas

2012-03-28T00:21:00.008+02:00

El objetivo de este artículo es explicar cómo podemos tener una descripción extensa de una imagen en la propia página, de tal manera que:

sea accesible para los lectores de pantalla
se visualice cuando la imagen no esté cargada (bien porque tenemos las imágenes desactivadas, bien porque ya no se encuentra disponible, etc.)

Todo ello sin depender del atributo longdesc, que no siempre es soportado, ni de los típicos enlaces [D] junto a la imagen (conocidos como D-Link); y asegurando que no dé problemas cuando se deshabilita el javascript o las CSS.

Este artículo se me ocurrió después de leer el artículo de Steve Faulkner Detecting if images are disabled in browsers, en el cual explicaba cómo podemos detectar por javascript si las imágenes están deshabilitadas o no se han cargado.

Ver la página de ejemplo

Descargar el ejemplo (RAR, 13Kb)

La descarga y uso del ejemplo es completamente libre, pero os agradecería mucho que compartierais mejoras que se os ocurran o problemas que detectéis.

He probado su funcionamiento con NVDA, Explorer 7, Explorer 8, Explorer 9, Firefox 1.5, Firefox 2, Firefox 3, Firefox 11, Chrome 17, Opera 11, Safari 5 (para Windows) y desde una BlackBerry y una iPad. En Explorer 6 no hay problema para visualizar la descripción, pero se ve siempre presente como si el javascript estuviera deshabilitado.

HTML

El código HTML es XHTML 1.0 Strict válido y es el siguiente. En primer lugar tenemos la cabecera:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"  >
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
<head>
<title>Ejemplo descripción extensa accesible de imágenes< /title >
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
<meta name="author" content="Olga Carreras" />
<meta name="description" content="Descripciones extensas de imágenes accesibles con lectores de pantalla y sin imágenes activas" />

<link href="estilos.css" type="text/css" rel="stylesheet" media="all" />
<script type="text/javascript" src="utils.js"></script>
</head>

Como se ve, estoy llamando a una CSS y a un JS que explico más adelante.

A continuación tenemos el cuerpo de la página:


<body>
<h1>Ejemplo de descripción extensa de una imagen: accesible con lector de pantalla y sin imágenes activas</h1>
<p>Olga Carreras. Ejemplo del artículo <a href="http://olgacarreras.blogspot.com">"Descripción extensa de una imagen: accesible con lector de pantalla y sin imágenes activas"</a></p>

Después de lo que es el título de la página y el enlace al artículo tenemos ya la imagen:


<div>
<img src="razones_uso_tecnologia_accesible.gif" alt="Razones de uso de la tecnología accesible" id="image1" class="images" />
<p><a href="#descripcion" title="Mostrar la descripción de la imagen Razones de uso de la tecnología accesible" id="linkDescripcion" class="oculto">Ver descripción de la imagen</a></p>
</div>

La imagen es un gráfico, por tanto el atributo ALT no es suficiente, necesitamos una descripción detallada la imagen.

Os preguntaréis la razón por la cuál he incluido a continuación de la imagen un enlace "Ver descripción de la imagen".

Ese enlace no es necesario puesto que si la imagen no está cargada se verá la descripción detallada y los lectores de pantalla no van a tener problemas para acceder a dicha descripción.

Sin embargo, puede darse el caso de usuarios con vista cansada o que accedan desde un dispositivo móvil y el tamaño de letra de la imagen les resulte pequeño (y no sepan o no puedan hacer zoom de la imagen)

En ese caso les puede ser de utilidad pulsar el enlace para ver la descripción.

El enlace es un ancla al comienzo de la descripción, después veremos que mediante javascript no intrusivo se le ha asignado una función que permite mostrar/ocultar la descripción detallada y personalizar el texto y el TITLE del enlace en función de si se visualiza o no la descripción.


<div id="descripcion" class="visible">
<h2>< < Descripción de la imagen: Razones de uso de la tecnología accesible</h2>
<h3>Por entorno laboral</h3>
<ul>
<li>Con discapacidad severa: 4%</li>
<li<Con discapacidad moderada: 3%</li>
<li<Sin discapacidad: 6%</li>
</ul>
[el resto de la descripción larga, no la pongo aquí toda]
</div>

Como vemos, a continuación se incluye la descripción detallada correctamente maquetada. Esta descripción se oculta una vez cargada la página mediante javascript no intrusivo, por tanto estará disponible tanto sin javascript activo como sin CSS activas, debajo de la imagen.

Con CSS activas, tanto si pulsas el enlace como si no se carga la imagen, la descripción se posiciona a la derecha de la imagen.

Por otro lado veremos que la descripción extensa se está ocultando de forma accesible, así que los usuarios que usan un lector de pantalla (podéis probarlo con NVDA) escuchan la descripción a continuación de la imagen y el enlace.


<div class="pie">
<p>Probad a deshabilitar javascript, css o imágenes. Para ver sin imágenes cargadas o sin javascript activo acordaros de recargar la página una vez que los desactivéis.</p>
<p>Para facilitaros verla sin la imagen cargada os dejo una copia de la misma página pero donde se ha escrito mal el nombre de la imagen y por tanto no la encuentra: <a href="descripcion_imagenes_accesibles_sinimg.html">Probar esta página cuando no se encuentra la imagen.</a></p>
</div>
</body>
</html>

En el pie de la página os recuerdo que si deshabilitáis el javascript, las CSS o las imágenes mientras visualizáis la página deberéis recargarla. Para facilitaros comprobar que, efectivamente, cuando no se carga la imagen se muestra por defecto la descripción a su lado, os pongo un enlace a una copia de la página donde he escrito mal el nombre de la imagen para comprobar cómo se ve la página sin la imagen cargada.

Como se observa, cuando la imagen no se ha podido mostrar, se ve en el hueco que ocuparía la imagen su ALT, y junto a la imagen aparece por defecto la descripción detallada. Ya no se muestra el enlace "Ver descripción de la imagen" porque no es necesario.

Me parece importante destacar que se ha separado:

el contenido: eso es únicamente lo que vemos en la página HTML
la presentación: no se especifica ningún estilo en la página, todos están recogidos en la CSS
el código javascript: no hay ningún evento, ninguna función, nada que haga sospechar que esta página incluye javascript (salvo la llamada al JS en el HEAD). Todo el javascript, incluso las funciones que se llaman en el onLoad de la página, están definidas de forma no intrusiva.

CSS

La CSS es CSS 2.1 válida. No pongo toda la CSS, sólo aquello que es relevante para el ejemplo.


.oculto{
position:absolute;
left:-999em;
}

Con esta clase general "oculto" oculto aquellos elementos que me interesa:

al cargarse la página compruebo si la imagen se ha cargado, en cuyo caso oculto por javascript la descripción. Sin javascript activo, por tanto, la descripción se verá.
el enlace "Ver descripción de la imagen" tiene esta clase "oculto" por defecto y una vez cargada la página lo hago visible. De esta manera, sin javascript activo, el enlace no se muestra puesto que ya no es necesario.

La forma de ocultar (mediante posicionamiento fuera de pantalla) permite que los lectores de pantalla sí puedan acceder al contenido oculto, algo que no ocurre con display:none. Más detalles en "Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página"

Otros estilos que me interesa comentar son los de la imagen:


.images{
width:auto;
height:auto;
}
.widthImage1{
width:393px;
height:363px;
}

Por defecto indico que el ancho de las imágenes sea "auto". No puedo poner por defecto el tamaño real de la imagen porque el script se basa en comprobar si el ancho de la imagen es diferente del ancho que debería tener, en cuyo caso es que la imagen no está cargada.

Sin embargo tengo una clase con el tamaño real de la imagen porque en Safari y Chrome, si la imagen no tiene especificado su ancho y alto real, no se muestra su atributo ALT. Así que veremos que en el script, tras comprobar el ancho de la imagen para saber si la imagen está cargada, le aplico la clase "widthImage1", y de este modo en Safari y Chrome vemos su ALT.

JS


function addLoadEvent(func) {
var oldonload = window.onload;
if (typeof window.onload != 'function') {
window.onload = func;
} else {
window.onload = function() {
if (oldonload) {
oldonload();
}
func();
}
}
}

La función "addLoadEvent" es la que nos permite llamar a funciones en el onLoad de la página de forma no intrusiva.

¿Qué funciones estamos llamando? Primero a addLoadEvent(noimage)


var Image1Width=393;
function noimage(){
var objImagen = document.getElementById('image1');
var objDescripcion = document.getElementById('descripcion');
var linkDescripcion = document.getElementById( 'linkDescripcion' );
objDescripcion.className = 'oculto';
linkDescripcion.className = 'visible';
if (objImagen.offsetWidth != Image1Width)
{
objDescripcion.className = 'visible';
objImagen.className = 'widthImage1';
linkDescripcion.className = 'oculto';
}
}

Lo primero que hago, como ya he comentado, es ocultar la descripción larga de la imagen y mostrar el enlace "Ver descripción de la imagen".

A continuación compruebo si el ancho de la imagen es diferente del ancho que debería tener, en cuyo caso es que la imagen no se ha cargado.

En la propuesta de S.Faulkner se comparaba si era igual a 1, pero esto no me funcionaba en todos los navegadores. Por eso lo comparo con el ancho real "393". Es más "sucio" porque no me sirve para todas las imágenes como el compararlo con 1, sino que he de personalizarlo para cada una, pero funciona en todos los navegadores.

Nota: Faulkner lo comparaba con 1 porque no le ponía ALT a las imágenes. Entonces el hueco de la imagen no se adaptaba al ALT y por eso su ancho era 1 cuando no estaba cargada. Como se debe poner ALT tenemos que hacerlo comparándolo con su ancho real. Por otro lado, indicar el ancho y alto de la imagen ayuda a las personas que ven la página sin la imagen cargada a hacerse una idea del tamaño que esta tenía.

En el caso de que la imagen no se haya cargado muestro la descripción, cambio la clase de la CSS aplicada a la imagen (ya he explicado en la CSS que es para que en Chrome y Safari se vea el atributo ALT dentro de la zona de la imagen) y oculto el enlace "Ver descripción de la imagen" porque el enlace ya no es necesario.

La otra función que llamo en el onLoad de la página es la siguiente:


addLoadEvent (function(){
var linkDescripcion = document.getElementById( 'linkDescripcion' );
var objDescripcion = document.getElementById('descripcion');
linkDescripcion.onclick = function(){
if (objDescripcion.className == 'oculto')
{
objDescripcion.className = 'visible';
linkDescripcion.innerHTML="Ocultar descripción de la imagen";
linkDescripcion.title="Ocultar la descripción de la imagen Razones de uso de la tecnología accesible"
}else{
objDescripcion.className = 'oculto';
linkDescripcion.innerHTML="Ver descripción de la imagen";
linkDescripcion.title="Mostrar la descripción de la imagen Razones de uso de la tecnología accesible"
}
}
}
)

Esta función añade al evento "onClick" del enlace "Ver descripción de la imagen" una función que:

Si la descripción de la imagen está oculta, al pulsar el enlace la mostraremos. Y a continuación cambiaremos el texto del enlace por su nueva acción "Ocultar descripción de la imagen" y cambiaremos también el TITLE de la imagen para que esté acorde con su nueva función de ocultar la descripción.
Si la descripción de la imagen está visible, al pulsar el enlace la ocultaremos. Y a continuación cambiaremos en texto del enlace por su nueva acción "Ver descripción de la imagen" y cambiaremos también el TITLE de la imagen para que esté acorde con su nueva función de mostrar la descripción.

Algo que no he hecho para que se viera más claro lo que hacían las funciones y que se debería hacer para separar el código javascript del texto concreto que queremos personalizar, sería definir esos literales en un fichero diferente de variables para que nos sean más sencillos de modificar. Así en el código sólo incluiriamos variables y no texto concreto.

Os animo ha que dejéis en los comentarios cualquier sugerencia de mejora o problema que detectéis.

Artículos relacionados:

Cheat Sheet HTML 4.01, HTML 5, XHTML Elements

2011-01-21T22:00:00.002+01:00

Descripción: Tabla en formato excel con todas los elementos HTML (incluido HTML 5) y XHTML con información relevante sobre ellos: navegadores que los soportan, anotaciones de accesibilidad, etc. (ver descripción detallada de la tabla)

Versión: [20.01.2011] versión 1.0 en castellano

Autor: Olga Carreras

Descarga: Cheat Sheet HTML 4.01, HTML 5, XHTML Elements (Excel, 189 KB)

Descripción detallada de la tabla

La tabla consta de 14 columnas. Los encabezados de las columnas se han bloqueados para que estén siempre disponibles aunque se escrole la tabla verticalmente.

Columna A: Elemento

Incluye todas los elementos (X)HTML (incluidos los de HTML 5) en orden alfabético con enlace a su descripción en la especificación correspondiente. También se incluyen elementos que no están en ninguna especificación del W3C como marquee, spacer, etc. en cuyo caso enlazan con una web de referencia. Es en estos enlaces donde se puede consultar información sobre los atributos de cada elemento.

No se han incluido los elementos que sólo están presentes en XHTML 2. Como excepción se incluye el elemento h de XHTML 2 para documentar los encabezados en esta especificación. Se pueden consultar todas las etiquetas de XHTML 2 en: XHTMl 2.0. List of elements del W3C.

Está primera columna está bloqueada para tener siempre presente el elemento aunque se escrole la tabla horizontalmente.

Columna B: Descripción

Breve descripción del elemento.

Columna C: Desaprobado/No estándar/Obsoleto

En esta columna se indica si los elementos son:

Desaprobado (deprecated): son elementos que están en la especificación HTML 4.01 o XHTML pero que el W3C los ha marcado como "deprecated", desaprobando su uso. No están permitidos en documentos STRICT. Se indica el elemento alternativo que debe usarse.

No estándar: son elementos no estándar, que fueron implementados por algunos navegadores (y que aún las soportan en muchos casos) pero que no pertenecen a ninguna especificación (X)HTML. En cada caso se indica el navegador que las implementó y las alternativas a su uso.

Obsoleto: son elementos de especificaciones anteriores (se indica de cual).

HTML 5: elementos que sólo pertenecen a HTML 5.

En cualquier otro caso la celda correspondiente aparece vacía.

Columna D: Web Browser Support

He documentado el soporte de cada elemento (incluidos los de HTML 5) en las diferentes versiones de navegadores.

Referencias sobre soporte en navegadores:

HTML 4.01 / XHTML 1.0 Reference, about.com

HTML reference, sitepoint.com

HTML, XHTML, and WML support in Opera Presto 2.2, soporte en Opera 10

Web specifications support in Opera Presto 2.7, soporte en Opera 11

When can I use..., compatibility tables for support of HTML5, CSS3, SVG and more in desktop and mobile browsers

HTML5 Tutorial, w3school.

Comparison of layout engines (Non-standard HTML), wikipedia

En algunos casos se indica el test concreto que se ha realizado para validar un elemento concreto.

Columna E-L: Especificación

Las columnas son:

HTML 4.01

XHTML 1.0 Strict

XHTML 1.0 Transitional

XHTML 1.0 Frameset

XHTML 1.1

XHTML 1.1 Basic

HTML 5

XHTML 2

Cuando la celda correspondiente está verde con el texto "SI" indica que el elemento pertenece a esa especificación.

Cuando la celda correspondiente está roja con el texto "NO" indica que el elemento no pertenece a esa especificación.

Algunas celdas pueden aparecer naranjas con una advertencia dentro. Por ejemplo, en el caso de que el elemento pertenezca a HTML 4.01 pero esté desaprobado y no pueda usarse con HTML 4.01 Strict, la celda correspondiente a la columna E (HTML 4.01) estará coloreada en naraja con la advertencia en su interior.

Columna M: Notas de accesibilidad

En este apartado se incluyen notas relevantes como el soporte en lectores de pantalla, ejemplos cuando se trata de elementos poco habituales, mención a puntos de verificación de las WCAG relacionadas con el elemento en cuestión, etc.

Columna N: ¿Semántico?

En esta columna se indica si es una elemento semántico o si por el contrario es un elemento de presentación. En algunos casos, como se indica, puede depender del uso que se haga de ella.

Referencias:

Semantic (X)HTML, microformats.org

Presentational (X)HTML, microformats.org

Otros enlaces de interés:

Keryx (X)HTML Elements Best Practice Sheet

Podeis dejar en los comentarios cualquier propuesta o anotación para incluir en versiones posteriores.

Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad

2009-10-30T21:49:00.025+01:00

El contenido de este artículo se ha movido a la recopilación Respuesta a 25 dudas habituales sobre accesibilidad web

Noticias (13)

2008-10-07T09:00:00.000+02:00

Estas son las noticias que han llamado mi atención durante el mes de septiembre:

Premios TAW (Test de Accesibilidad Web) 2008

Los Premios TAW a la Accesibilidad Web se internacionalizan al abrirse a América Latina
La Fundación CTIC, con la colaboración del Gobierno del Principado de Asturias, convoca la cuarta edición de los Premios TAW a la Accesibilidad Web, dirigidos a todas aquellas personas y entidades, públicas o privadas, que promueven la accesibilidad de los sitios web. El plazo para concursar se extiende hasta el 9 de octubre de 2008 inclusive y, como novedad, este año la convocatoria adquiere carácter internacional al abrirse, en todas sus categorías, a América Latina.

Se pueden proponer candidaturas hasta el 9 de octubre mediante un formulario online.

World Wide Web Foundation

Tim Berners-Lee anuncia la creación de la nueva Fundación para acercar la Web a todo el mundo

Puedes ampliar más información en la web de la fundación.

XHTML(eXtensible Hypertext Markup Language) Basic 1.1 y Mobile Web Best Practices 1.0, recomendaciones del W3C (Consorcio World Wide Web)

Webposible nos informa del cambio de estado de los hasta ahora borradores.

Resultados de la consulta pública para mejorar la accesibilidad de Internet de la Comisión Europea

La Comisión Europea realizó una consulta pública para mejorar la eAccesibilidad como puedes consultar en La Comisión quiere una Internet mejor adaptada a las personas discapacitadas.

El 15% de los europeos sufre alguna forma de discapacidad y muchos sufren dificultades para leer los textos en letra pequeña de los sitios de Internet o hasta para saber cómo acceder a los sitios de Internet y los servicios en línea.

A pesar de los repetidos llamamientos de los jefes de Estado y de Gobierno de la UE para atajar esta situación, los progresos son limitados: con gran diferencia, la mayoría de los sitios de Internet no recurre a soluciones de fácil uso aceptadas universalmente.

La Comisión Europea ha puesto en marcha hoy una consulta pública sobre otras medidas para hacer accesibles los sitios de Internet en Europa, empezando por los de las administraciones públicas, e invita a los interesados a dar su opinión. También aborda otras tecnologías como la televisión digital.

La consulta se cerró el 7 de septiembre. En Public consultation on Web accessibility se pueden leer las propuestas recibidas.

Evolución de la demanda por inaccesibilidad a la web de los almacenes Target

La cadena de almacenes estadounidense Target hará accesible su página web para internautas ciegos, noticia publicada en Discapnet.

La cadena de almacenes estadounidense Target hará accesible su página web para internautas ciegos, en virtud de una sentencia que resuelve la demanda presentada por un grupo de personas con esta discapacidad por la incompatibilidad del portal con los programas lectores de pantalla que utilizan para convertir el texto en audio, según informa la prensa estadounidense.

Target tendrá que introducir explicaciones en audio de las imágenes que utilice en su sitio web, así como garantizar que pueden manejarse todas sus funciones valiéndose sólo del teclado, sin utilizar el ratón.

Más información en:

Welcome to the NFB Target lawsuit site

Target Will Ensure That Web Site Remains Accessible to Guests Who Use Assistive Technologies

El iPhone acusado de inaccesibilidad

Apple y Telefónica (de nuevo) acusadas de publicidad engañosa

El organismo regulador ha entendido que la expresión utilizada en el anuncio del nuevo dispositivo móvil de Apple, el Iphone 3G, referente a las capacidades de acceso a Internet conducía a engaño en tanto que en el anuncio se mencionaba expresamente "Todos los rincones de Internet están en el iPhone" sin indicarse ninguna limitación cuando en realidad hay determinadas partes de las páginas web (programadas en java y flash) que no son accesibles a través de los dispositivos comercializados por O2.

También se puede leer la noticia en expansion.com

Google Phone

Es el turno de 'Google Phone'

HTC ha presentado en Nueva York el primer móvil basado en Android, el sistema operativo de código abierto diseñado por Google. El nuevo terminal, llamado HTC Dream se empezará a comercializar junto con el operador T-Mobile el 22 de octubre en Estados Unidos por 179 dólares (123 euros). A principios de noviembre, saldrá al mercado británico, y se irá introduciendo por el resto de Europa a lo largo del próximo año, según ha explicado la compañía.

Web 3.0

El ordenador ya puede comprenderte: reconoce el significado de las palabras

También se puede seguir la noticia en Web 3.0, computadoras ya entienden el significado de las palabras

Web móvil: el 30% de los españoles con teléfono 3G navega en la Red

Localización y servicios contextuales, pilares de la Web móvil/

El móvil, por fin, comienza a desbancar lentamente al ordenador y a la Internet fija para convertirse en la herramienta de socialización del futuro. Lo que toda una industria esperaba, audiencia, masa crítica, se va acercando. En España, el 37% del total de suscriptores móviles mayores de 13 años poseen un terminal 3G, según M:Metrics. Y el 30% lo utiliza para navegar por la Red, descargar juegos y vídeos o chatear con los amigos. La oportunidad aguarda a la vuelta de la esquina y una nube de start-ups en todo el mundo no quiere perdérsela.

Plantilla base XHTML

2007-08-26T10:50:00.007+02:00

Artículo relacionado: Cheat Sheet HTML 4.01, HTML 5, XHTML Elements, tabla en formato excel con todas los elementos HTML (incluido HTML 5) y XHTML con información relevante sobre ellos: navegadores que los soportan, anotaciones de accesibilidad, etc.

El objetivo de este artículo era tan simple como crear una correcta plantilla XHTML base, lo más completa posible para que en función del desarrollo se pudiera eliminar aquello que fuera prescindible.

Pronto comprendí que para justificar la inclusión de cada línea sería necesaria una explicación, y al final me he liado a escribir y me ha salido de nuevo un artículo demasiado amplio. De modo que si te interesa tan sólo la plantilla puedes ir directamente al final del artículo. Serán bienvenidas todas las aportaciones acerca de qué añadirías o quitarías, pero entonces te agradecería que leyeras el artículo completo y argumentarás tu posición.

Si te interesa seguir la construcción de la plantilla aquí tienes el índice del artículo:

DOCTYPE
HTML
HEAD
Metas
CSS
Navegación semántica
JS
BODY
- Estructura de contenidos
- Microformatos
Fin de documento
Plantilla XHTML base

Declaración de tipo de documento DOCTYPE

     
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"       
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Lo primero que debe contener nuestra página es la declaración del tipo de documento (Document Type Definition (DTD), también conocida como Doctype para abreviar) no sólo para cumplir con los estándares sino para garantizar la correcta renderización de nuestra página.

Mediante esta declaración indicamos la versión de (X)HTML que usa la página y la DTD con la cual se realiza la validación, de forma que los navegadores puedan saber qué sintaxis y gramática se usa, y los validadores puedan comprobar su validez.

Los navegadores entran en modo de visualización Quirks Mode cuando una página no tiene definido un Doctype o pese a tenerlo no cumple el estándar referente a ese Doctype (por ello es tan importante validar la sintaxis de nuestras páginas con el validador del W3C). Las consecuencias de que el navegador entre en Quirks Mode son que:

procesa las páginas de forma más lenta
renderiza las páginas de forma completamente diferente a lo que teníamos previsto (ver consecuencias en ¿Qué pasa en el modo chapuzas (Quirks Mode)?

Con Firefox, por ejemplo, puedes consultar el modo de visualización de la página desde el menú "Herramientas/Información de la página".

La declaración de tipo de documento que he puesto es la de XHTML 1.0 Strict. Existen muchos otros que puedes consultar en el W3C.

El HTML se ha jubilado hace tiempo (bueno, habrá que ver como evoluciona el tema del HTML5), hoy en día yo creo que la elección debe ser entre los distintos tipos de XHTML, concretamente ente XHTML 1.0 Strict o XHTML 1.1, que nos aseguran una página bien estructurada, con una clara separación entre el contenido y la presentación.

Pero para no llevarnos desagradables sorpresas después, hay que tener en cuenta varias cosas antes de tomar una decisión:

Con XHTML 1.0 Strict y XHTML 1.1 no puedes utilizar el parámetro "target", y evidentemente tampoco vas a usar un window.open, así que si quieres abrir una ventana nueva hay que echar mano de soluciones ingeniosas como la de Kevin Yank. Lo cierto es que lo ideal es no abrir nunca nuevas ventanas, puesto que muchos user-agent no las permiten (dispositivos móviles, TDT, etc.)
Una página XHTML 1.1 NO puede ser servida como "text/html" (permitido en XHMTL 1.0 Strict siempre que se cumpla con las Directrices de Compatibilidad con HTML) lo cual no podrá ser interpretado por muchos navegadores (ver lista en el W3C)
Una página XHTML 1.1 debe incluir antes del DOCTYPE la línea: <?xml version="1.0" encoding="ISO-8859-1"?> (el encoding dependerá del idioma de la página, claro) lo cual provoca que Explorer 6 entre siempre en modo Quirks Mode (ver artículo "HTML Doctype" de webdiseny.es y el artículo "Duda con XHTML 1.1" de Anieto2K )
En XHTML 1.0 Strict y XHTML 1.1 no se admiten los elementos "applet", ni "frame" o "iframe", ni permite escribir código con javascript mediante "document.write"

En resumen, es muy importante la elección del DOCTYPE, y esta no se puede hacer a la ligera, sino que es necesario conocer las especificaciones de los distintos tipos de documento. Si tu desarrollo es incompatible (normalmente por las exigencias del que paga) con cualquiera de las prohibiciones/restricciones que hay en XHTML 1.0 Strict o XHTML 1.1, tus páginas deberán ser XHTML 1.0 Transitional o XHTML 1.0 Frameset.

Enlaces de interés:

XHTML 1.0
XHTML 1.1
Traducciones SIDAR sobre XHTML
HTML 4.01 / XHTML 1.0 Reference
"Recommended DTDs to use in your Web document" del W3C
"Preguntas frecuentes sobre HTML y XHTML" del W3C
"HTML Doctype" de webdiseny.es
"Pasando de HTML a XHTML" de mononeurona.org
"XHTML" de Patricio Galdames

HTML

     
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">

A continuación se incluye la etiqueta HTML indicando el idioma utilizado en la página. Como nuestra página es XHTML 1.0 debemos indicar el idioma tanto con "xml:lang" como con "lang", así como el espacio nominal a través del atributo "xmlns", siendo este: "http://www.w3.org/1999/xhtml"
(ver especificación de XHMTL 1.0)

HEAD

     
<head profile="http://miservidor.org/xmdp/htmlprofile.html http://dublincore.org/documents/dcq-html/ http://geotags.com/geo/">       


<title>Titulo de la pagina</title>       

<link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />       

<base href="http://miservidororg.com/" />

Comenzamos la cabecera de la página con <head>, que como se ve tiene definidos varios profile (documentos que contienen un perfil de metadata), separados por espacios. Es necesario utilizar un profile siempre que usemos metas que no estén definidos en la especificación XHTML. En este caso incluimos dos formalmente definidos como son el de Dublin Core y el de Geotags.

Del mismo modo, si en las etiquetas <link> o <a> usamos valores para “rel" y “rev" diferentes de los definidos en la especificación XHTML, también habremos de utilizar un profile propio en el cual sean definidos. En nuestro caso he creado mi propio profile (miprofile.html) con XMDP.

Estos profile deben estar ordenados de mayor a menor importancia, teniendo en cuenta que si un mismo elemento es definido en varios de esos profile tendrá prioridad el del primer profile en el que se defina. Si estás un poco perdido puedes leer esta breve introducción al tema.

Esta es la teoría, en la práctica, como se puede leer en el W3C , los user-agent, hoy en día, sólo admiten el primero de la lista. Incluimos los tres en espera de que sean capaces de reconocer varios profile, y más delante, delante de los metas, incluiré un link con el schema . Que yo sepa, el profile y el schema no son excluyente o sustitutivos, me corregís si me equivoco, así que se pueden incluir ambos en la plantilla.

A continuación añadimos el título de la página con <title> que debe identificar de la forma más clara y breve posible el contenido del documento que lo contiene (y por tanto no debe ser el mismo para todas las páginas del portal). El contenido del <title> será lo que se muestre en la ventana de título del navegador, el nombre del enlace al guardar la página en Favoritos, al descargarla o al hacer un acceso directo, será el título de nuestra página en los buscadores, etc.

En “Como optimizar los títulos en sus páginas web" encontrarás todas las reglas que debe seguir el <title> de tus páginas. Deberías tener en cuenta que los buscadores dan gran importancia al contenido del title (más que a las keywords) para indexar tu web y que Google interpreta que se hace spam si aparece más de una vez una palabra determinada en el título.

[..] el título debe ser una frase bien redactada y llamativa, y a su vez con una alta densidad de palabras clave, que describa con precisión los contenidos de la página. Una práctica muy común es poner como etiqueta de título el nombre de la empresa o página web. En primer lugar, esta práctica explica bien poco al visitante de lo que se trata la página y, en segundo lugar, no muestra al robot del buscador el tema principal […]
[En "La optimización de etiquetas y meta-tags HTML"]

Podemos indicar opcionalmente el favicon (icono asociado a la web), pero antes de usarlo deberías estar al corriente de los problemas de seguridad asociados a él: 'Favicon': la 'cara' de las direcciones url o favicon.net

Verás que hay un espacio en blanco antes del “/>" de la etiqueta link, espacio que he incluido en todas la etiquetas simples de la plantilla, puesto que así lo indican las Directrices de Compatibilidad con HTML del XHTML.

Por último, he incluido la etiqueta <base> para indicar la ruta base de referencia para enlaces relativos, esto es muy útil en sitios dinámicos y para que los enlaces sigan funcionando fuera de contexto (por ejemplo si se han guardado tu página en local)

METAS

Metas http-equiv

     
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />       


<meta http-equiv="content-language" content="es" />

Existen dos tipos de metas, los meta http-equiv, que tienen control sobre los exploradores, y son utilizados para refinar la información y dar instrucciones al explorador que las está leyendo (aunque hay que advertir que muchos navegadores las ignoran) y los meta name, que contienen información referida al documento (meta información) que no se presenta en la pantalla del navegador.

Las metaetiquetas [en referencia a los meta "http-equiv"] generan información extra a las cabeceras HTTP, de manera que cuando se hace una petición al servidor de una página en concreto, este genera una respuesta HTTP que incluye como información las metaetiquetas que nosotros hayamos insertado en nuestra página [...]
Debemos tener en cuenta que la inserción de las metaetiquetas no produce ningún cambio en el resultado de nuestra página a "nivel visible", es decir, que no alterará en nada el diseño de nuestra página, ya que su efecto sólo influye en las cabeceras HTTP, y por tanto sólo son utilizadas y vistas a nivel de servidor, motores de búsqueda, navegadores web, etc.

[En "Metaetiquetas"]

Hay diferentes metas http-equiv: para la caché, la expiración, el refresco (que se ha de evitar a toda costa) o las cookies de las páginas.

Yo he añadido a la plantilla los dos que me parecen fundamentales:

content-type: lo colocamos en primer lugar, indica el tipo de documento y su codificación de caracteres (XHMTL 1.0 Strict permite que la página sea servida como text/html siempre que se cumpla con las Directrices de Compatibilidad con HTML)
content-lenguage: el idioma del documento

Hay otros para especificar el tipo de script o de hojas de estilo utilizadas:

     
<meta http-equiv="content-style-type" content="text/css" />       


<meta http-equiv="content-script-type" content="text/javascript" />

Hay otros metas propietarios, sólo para determinados navegadores, no estandarizados por el W3C, por ejemplo imagetoolbar, que permite no mostrar en Explorer la barra de herramientas asociada a las imágenes. Yo no soy partidaria de incluirlo por las mismas razones por las cuales no deshabilitaría el menú del botón derecho del navegador, pero la experiencia me dice que el que paga a menudo no atiende a razones.

Otro meta interesante es window-target que especifica el nombre de la ventana en la cual se debe visualizar la página web. Es muy útil para evitar que nuestra página sea vista en el marco de otra página web ajena a la nuestra, puesto que con el parámetro _top elimina todos los marcos existentes en el explorador.

     
<meta http-equiv="window-target" content="_top" />

Si la página incluye contenido para adultos habría que añadir PICS-Label (existe un generador automático: PICS Rating Generator).

Metas name

     
<meta name="description" content="incluir descripcion" />       

<!--// Incluir descripción //-->

Las metaetiquetas tienen una utilidad fundamental, principalmente en la promoción e indexación de la página Web en motores de búsqueda, directorios, etc.
También tienen otros usos, pero el principal es el ofrecer información sobre el documento a estos buscadores y directorios (y más concretamente a los programas que estos usan, llamados robots, que utilizan para indexar páginas Web en sus bases de datos)

[En "Metaetiquetas"]

Hay un meta que no puede faltar, es “description", que será la descripción que muestre Google habitualmente en su resultado, y que debería ser atrayente para animar a los usuarios a hacer clic sobre el título.

La descripción debe ser de 20-35 palabras, siendo buena idea ajustar el texto para que quepa en dos líneas. Debe ser única para cada pagina pues a un buscador le parecerá extraño que distintas páginas tengan la misma descripción, por lo que las marcará como poco relevantes y, en consecuencia, o no las posicionará bien o, peor todavía, no las mostrará entre sus resultados.

La etiqueta de Description bien redactada debe ser corta, precisa y con una alta densidad de palabras clave. Deberíamos evitar la tentación de utilizar la misma frase para las etiquetas de título, palabras clave y descripción.

[En "La optimización de etiquetas y meta-tags HTML"]

Existen robots que no hacen uso de las metaetiquetas para indexar las páginas web, así que algunos recomiendan incluir una descripción de la página que pueda ser útil para estos robots en el head, como si se tratase de un comentario.

     
<meta name="keywords" content="palabra1, palabra2" />

keywords ha perdido mucha importancia porque los principales buscadores ya no la utilizan para buscar las palabras clave de un sitio, puesto que ahora buscan las palabras clave en el title y en el body. Muchos optan por eliminarlas, pero aunque sólo sea por Inktomi, uno de los cinco principales buscadores, puede merecer la pena incluirlas.

Se recomienda que no sean muchas palabras, escribirlas en minúsculas, sin acentos, ni caracteres no internacionales, separadas por coma y un espacio o sólo por espacios formando frases, y personalizarlas para cada página del sitio. No deben ponerse palabras repetidas pues los buscadores lo consideran spam.

En cualquier caso debe evitarse todo uso ilegal de los metas porque los buscadores son capaces de detectarlos y eliminar la web de sus índices.

Si incluimos las palabras clave o la descripción en un idioma diferente habrá que añadir el parámetro del lenguaje mediante "lang" y "xml:lang".

A partir de este punto se pueden incluir muchos metas más, algunos muy extendidos como "autor", "copyright" y "robots" (este último sólo cuando queremos cambiar los valores por defecto, sino no es necesario. En cualquier caso sería más apropiado hacerlo con un fichero “robots.txt" que permite mucha más versatilidad)

¿Pero por qué incluir más metas?

Esos metadatos, son uno de los pilares de la web semántica, cuyo objetivo principal es lograr una "web inteligente" en la que los agentes de usuarios (como los buscadores, y otros mucho más avanzados) son capaces de intercambiar información de forma automática, con una mínima intervención humana.

[En Webposible]

Los metas que incluyas ya depende de ti y de tu web. Deberías añadir, eso sí, sólo los necesarios, no añadir metas porque sí, puesto que algunos de los buscadores premian a las páginas por tener más contenidos comparado con la cantidad de código y hasta se dice que Google penaliza a las páginas con un exceso de etiquetas. De todas maneras, como veremos, siempre se pueden incluir en ficheros RDF.

Puedes ver referencias completas de metas en estas direcciones:

Como curiosidad, este meta que se ve en ciertas páginas: <meta name="MSSmartTagsPreventParsing" content="true">, no tiene sentido incluirlo, puesto que Microsoft nunca llego a implementar "smart tags" en Explorer.

Metas Dublin Core

Dublin Core es un estándar de metadatos que define un conjunto de propiedades recomendadas para descripciones bibliográficas electrónicas, y su objetivo es promover la interoperabilidad entre modelos descriptivos dispares.

[En conclase.com]

Dentro de la gran variedad de estándares que utilizan las diferentes comunidades en Internet, el Dublin Core ha resultado el más citado, aceptado y usado, desarrollándose a un ritmo acelerado; muchos son los aportes que se han hecho al formato en los últimos años, lo que ha posibilitado que pueda ser utilizado en una amplia y creciente variedad de proyectos pertenecientes a las más diversas comunidades dentro de Internet.

El formato Dublin Core tiene dos niveles de codificación: simple y calificado. El DC simple emplea solamente los 15 elementos originales que forman parte del formato (Creador, Title, Subject, Description, Publisher, Type, Format, Coverage, Contributor, Date, Relation, Source, Language, Identifier y Rights); el calificado, además de los 15 elementos del DC simple, incluye: nuevos elementos DC, términos de refinamiento y esquemas de codificación de los elementos.

[En "Dublin Core (DC) en XHTML" de Isabel Daudinot]

Una vez que hemos incluido su profile en el head como ya vimos, podríamos por ejemplo añadir los siguientes metas (precedidos de su schema, tema sobre el que puedes ampliar información en En "Dublin Core (DC) en XHTML"):

     
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />       

<meta name="DC.title" content="ejemplo" />       

<meta name="DC.creator" content="ejemplo" />       

<meta name="DC.subject" content="ejemplo" />       

<meta name="DC.description" content="ejemplo" />       

<meta name="DC.language" scheme="ISO639-1" content="es" />       

<meta name="DC.rights" content="(c) 2007 propiedad del copyright" />

Muchas páginas que utilizan metas Dublin Core incluyen este label en sus páginas:

Otros enlaces de interés:

"Expressing Dublin Core in HTML/XHTML meta and link elements" en Dublin Core Metadata Iniciative
Generador de metas de Dublin Core en Webposible
"Encoding Dublin Core Metadata in HTML" de J. Kunze
es.dublincore.org
Guía de uso en es.dublincore.org
Dublin Core en la Wikipedia
Dublin Core en Webposible

Metas Geotags

Permiten incluir metainformación geográfica. Una vez que hemos incluido su profile en el head, como ya vimos, podríamos por ejemplo añadir los siguientes metas (precedidos de su schema)

     
<link rel="schema.geo" href="http://geotags.com/geo" />       

<meta name="geo.position" content="36.1254;-5.4429" />       

<meta name="geo.region" content="ES-AN" />       

<meta name="geo.placename" content="Algeciras" />

Existe un generador automático de etiquetas: Geo Tag Generador. GeoURL Header Generator las genera a partir de una dirección, pero sólo está disponible para EEUU. Earth Google y Google Maps también son de utilidad porque te dan la localización exacta de un lugar.

Enlaces de interés:

"Cómo indicar con exactitud un lugar geográfico en metadatos" de Gonzalo M.B.
"Metadatos geográficos" en Web Semántica Hoy
"Pon tus fotos en el mapa" de Ramso Net Blog
"Geotagging Flickr photos with Google Earth"

Metadatos en RDF

     
<link rel="meta" href="miservidor/dublincore.xml" type="application/rdf+xml" title="Dublin Core Metadata" />

Otra manera de incluir metadatos es mediante un fichero RDF (Resource Description Framework), un framework para metadatos en la Web desarrollado por el W3C.

El fichero contendrá información optimizada para los agentes semánticos (buscadores semánticos u otras aplicaciones) y su potencial es inmenso: interoperabilidad entre aplicaciones, procesamiento automatizado de recursos, etc.

Como siempre, todo tiene sus ventajas y sus inconvenientes y su uso depende de las características de nuestro desarrollo. Imprescindible el artículo de Web Semántica Hoy "Etiquetas meta, ficheros RDF, microformatos: 3 sabores de la Web Semántica"

Existen herramientas automáticas para crear RDF como vimos para Dublin Core o RDF-Gen, el generador de ficheros RDF para describir imágenes; y por supuesto se pueden escribir a mano en un simple bloc de notas. Puedes ver un ejemplo en "Cómo indicar con exactitud un lugar geográfico en metadatos" de Gonzalo M.B.

Otros enlaces de interés:

DOAC, RDF metadata para información curricular
FOAF, para la descripción de relaciones personales. Existe un generador automático: Foaf-a-matic. Existen muchas aplicaciones relacionadas: FOAF People Map, foafnaut!, FoaF Explorer o FOAF Web View que explotan estos datos.

CSS

     
<link href="estilosGeneral.css" type="text/css" rel="stylesheet" media="all" />       


<link href="estilosPantalla.css" type="text/css" rel="stylesheet" media="screen,projection" />       


<link href="estilosPrint.css" type="text/css" rel="stylesheet" media="print,tty" />       


<link href="estilosTelevision.css" type="text/css" rel="stylesheet" media="tv" />       


<link href="estilosSintetizador.css" type="text/css" rel="stylesheet" media="aural" />       


<link href="estilosMovil.css" type="text/css" rel="stylesheet" media="handheld" />       



<!--[if IE]>       

<link href="estilosIE.css" rel="stylesheet" type="text/css" media="screen" />       

<![endif]-->

Nuestros estilos deberían estar siempre recogidos en CSS. Podemos y debemos especificar diferentes CSS según el dispositivo de salida.

La CSS de pantalla debería tener explícito el media="screen" porque, si no se especifica, el resto de las CSS heredarán sus atributos y esto complica mucho el mantenimiento de las mismas. Es mejor tener una CSS media="all" con los elementos comunes y una específica para redefinir la visualización de los elementos que consideremos necesarios para los distintos dispositivos de salida.

Es imprescindible siempre una CSS para impresión media="print" que nos permita controlar la impresión de las páginas. También recomiendo leer mi artículo “Tu web en la televisión" para crear una CSS especifica para televisión (media="tv"). Hoy en día también es imprescindible una CSS para dispositivos móviles (media="handheld"). Si tienes posibilidad de revisar tu web con otros dispositivos de salida: un proyector, en dispositivos táctiles braille, etc. también deberías comprobar la necesidad de una CSS específica.

Para los sintetizadores de voz puedes crear una "CSS auditiva" mediante el media="aural", en la cual puedes indicar una pausa, el volumen o incluso el sexo de la voz que lee determinado texto.

Son pocos los navegadores (Opera 9, FireVox, Emacspeak) que admiten estas CSS y no todos interpretan la totalidad de sus propiedades. Puedes ampliar información en: “Aural CSS: Support for CSS 2 Aural Style Sheets / CSS 3 Speech Module". También puedes consultar “Aural style sheets" del W3C.

Nuestras CSS deberían ser multinavegador, pero a veces Explorer nos pone las cosas difíciles, sólo cuando nos sea imposible que se visualice correctamente en Explorer algún elemento, deberemos recurrir a una CSS correctiva, que sólo redefina las etiquetas que nos dan problemas, lo cual hará el mantenimiento del portal mucho más sencillo. Esta CSS correctiva la podemos llamar mediante los condicionales de Explorer, como se ve en el código, condicionales que pasan la validación XHTML 1.0 Strict.

Ya he comentado porque hay un espacio en blanco antes de cerrar la etiqueta link.

Navegación semántica

     
<link rel="home" href="default.htm" title="Pagina inicial. " />       


<link rel="index" href="mapa_web.htm" title="Mapa web. " />       


<link rel="contents" href="#menu" title="Tabla de contenidos. " />       


<link rel="search" href="buscador.asp" title="Buscador. " />       


<link rel="glossary" href="glosario.htm" title="Glosario. " />       


<link rel="help" href="ayuda.htm" title="Ayuda. " />       


<link rel="first" href="articulo1.htm" title="Primer articulo. " />       


<link rel="previous" href="articulo3.htm" title="Articulo anterior. " />       


<link rel="next" href="articulo5.htm" title="Articulo siguiente. " />       


<link rel="last" href="articulo10.htm" title="Ultimo articulo. " />       


<link rel="up" href="#inicio" title="Arriba. " />       


<link rel="copyright" href="#copyright" title="Copyright. " />       


<link rel="author" href="mailto:carreras.olga@gmail.com" title="Contactar. " />

Si no sabes qué es la navegación semántica deberías comenzar leyendo

"Navegación Semántica o Meta Navegación" de Emmanuelle Gutiérrez y Restrepo.

No todos los navegadores incluyen por defecto la barra de navegación semántica, la tienen Seamonkey, Opera, Lynx o iCab, pero existen extensiones para otros, por ejemplo la Link Toolbar de Firefox o la <link> Navigation Bar para Explorer.

La forma de mostrar los vínculos varía de uno a otro, de tal manera que en algunos, como en Opera, sólo se muestran los definidos por el navegador pero no los definidos por la página:

Como ves, en Opera, los 13 enlaces aparecen activos porque se han definido todos ellos con el código anterior. Para que sean reconocidos, el parámetro “rel" debe ser exactamente el que he indicado (si pusieras otro, o lo pusieras en español, deberías definirlo en un profile para que fuera reconocido). El href puede ser a otra página, a una zona de la página actual o a un email.

Por ejemplo, en Explorer, vemos las mismas 13 opciones pero en forma de iconos y en distinto orden. Explorer presenta además un desplegable para los rel="alternate" y otro para los definidos por el autor (lo vemos más adelante):

En Lynx, por ejemplo,

se insertan estos enlaces al comienzo de la página. Aquí se ve claramente por qué conviene poner “." más un espacio en blanco al final del title: para que los enlaces sean legibles en los navegadores modo-texto (de otro modo, los enlaces hubieran estado todos juntos y seguidos). Por otro lado, el punto forzará una pausa en su lectura.

Además de esos 13 enlaces estándar, existen los alternate, que permiten ofrecer acceso a una presentación alternativa del documento.

     
<link rel="alternate" href="/en" hreflang="en" title="English version. " xml:lang="en" lang="en" />       


<link rel="alternate" href="/fr" hreflang="fr" title="Français version. " xml:lang="fr" lang="fr" />       


<link rel="alternate" href="/es" hreflang="es" title="Versión en Español. " xml:lang="es" lang="es" />

En estos enlaces estamos indicando versiones de la web en otros idiomas, también podemos indicar otro tipo de versiones:

     
<link rel="alternate" type="application/rss+xml" title="Titulares RSS Feed. " href="titulares.rss" />       


<link rel="alternate" type="application/atom+xml" title="Titulares Atom. " href="titulares.atom" />

En este caso dos versiones: RSS y ATOM para la distribución (o sindicación, con su nueva acepción tomada del “syndication" en inglés) del contenido de nuestra web. Si siglas y palabras como RSS, RDF, Atom, feed te suenan a chino o no terminas de aclararte con ellas, sólo necesitas leer el fabuloso artículo de microsiervos “¿Qué es RSS –y XML, RDF, Atom,...?". También puedes consultar la “Guía fácil del RSS".

Se podrían incluir en este tipo de link rel="alternate" otras versiones alternativas como versión zoom, versión alto contraste, etc.

En Explorer, por ejemplo, todos los rel="alternate" se muestran en un desplegable:

La W3C especifica otros valores de "rel", aparte de los vistos: chapter, section, subsection, appendix, bookmark

Por último, podemos ofrecer otros links definidos por el autor y no descritos en la especificación, en cuyo caso se debe usar un profile definido en el head, como ya he indicado.

Sería conveniente añadir estos dos links: rel=“accesibility" y rel=“personalizar" para los enlaces de accesibilidad, como se propone en "Navegación Semántica o Meta Navegación" de Emmanuelle Gutiérrez y Restrepo.

     

<link rel="accesibility" href="accesibilidad.rdf" type="application/rdf+xml" title="Accesibilidad. " />       


<link rel="personalizar" href="personalizar.htm" title="Opciones de personalización para la navegación por el sitio web. " />

El primero de ellos, “accesibility", enlazaría con el informe de evaluación de la accesibilidad de la página en formato RDF, que puede generarse fácilmente utilizando HERA u otra herramienta de revisión que permita la generación de informes utilizando el vocabulario EARL. Esto permite comprobar hasta que punto se han revisado las páginas, quién lo ha hecho y qué nivel de accesibilidad declara.

Este informe no está dirigido al usuario, aunque existan herramientas para que los informes generados en formato RDF se presenten de forma legible para los humanos en formato XHTML. Por ello tendríamos el link “personalizar" que enlazaría con la página habitual de accesibilidad, en donde se explicarían cuestiones básicas sobre las opciones de configuración y adaptación (por tanto de personalización) del sistema operativo y agente de usuario: teclas de acceso rápido, ampliación de fuente, etc.

Otros enlaces podrían ser propios de la aplicación, por ejemplo:

     
<link rel="archive" href="" title="Mayo 2007. " />       


<link rel="archive" href="" title="Junio 2007. " />

Estos enlaces personales, en Lynx, por ejemplo, no se visualizan, en Explorer sin embargo aparecen en un desplegable:

JS

     
<script type="text/javascript" src="js/utils.js"></script>

En XHMLT 1.0 Strict no se permite el parámetro “language" en la etiqueta script, por eso no lo incluyo.

Todo el código javascript debería estar en ficheros JS, aunque es cierto que la especificación permite incluir código en la página así:

   
<script>     
<![CDATA[     
... contenido no procesado del script ...     
]]>     
</script>

Nuestra página debe tener claramente separado el contenido, la presentación y el comportamiento, por ello el javascript utilizado debe ser no intrusito, invisible, de tal manera que no afecte su desactivación al funcionamiento de la página, y por supuesto tener cuidado con el tipo de eventos que se manejan (el evento "onclick" será inservible, por ejemplo, a un usuario que no disponga de ratón).

BODY

     
</head>       

<body>

Cerramos la cabecera del documento y comenzamos el cuerpo de la página. El body no debe llevar ningún parámetro de estilo (topmargin, etc.) ni tampoco debería incluir llamadas a eventos javascript (por ejemplo onLoad, perdón onload, en XHTML los atributos van en minúsculas) pues como digo todo el javascript debe ser no intrusito.

BODY: Estructura de contenidos

     
<div id="pagina"><a id="inicio" name="inicio">Inicio de la pagina</a>       


<div id="irContenido"><a rel="contents" href="#content" accesskey="S">[S] Ir al contenido</a></div>       


<div id="irNavegacion"><a rel="index" href="#menu">Ir al menú de navegación</a></div>

Al comienzo de las páginas deberíamos incluir un enlace que permita saltar directamente al contenido y otro que permita saltar directamente al menú, de manera que aquellos usuarios que, por ejemplo, utilicen un lector de pantalla, no tengan que escuchar en cada página toda la cabecera, todo el menú, etc., o que los usuarios que por ejemplo usen un navegador tipo texto como Lynx, no deban tabular por todas las opciones previas hasta llegar a un enlace en el contenido (lo mismo se aplica a otros dispositivos como MSN TV o dispositivos móviles en los que no se usa ratón)

Todo lo que hay que saber acerca de este tema está resumido en Enlaces de "saltar navegación" de jlvelazqueznet, y a él te remito.

En resumen, lo habitual es esconder estos enlaces mediante display:none, visibility:hidden, text-indent negativo o con una imagen invisible, anulando además el indentado del enlace. Usaremos por tanto las CSS de los dispositivos que nos convenga para mostrarlo o no.

Jlvelazquez reivindica, y estoy con él, que no deberíamos ocultarlos sino ofrecerlos como una herramienta más.

En cualquier caso, si se desea ocultar, hay que tener en cuenta que en función de la forma seleccionada se leerá/mostrará o no. En su artículo incluye una tabla aclaratoria que puede ser completada con esta otra.

Como vemos, es mejor evitar el display:none y el visibility:hidden.

Por otro lado, el acceso de teclado (acceskey) que le ha asignado al enlace de saltar al contenido es la "S". Si te preguntas qué es un acceso de teclado o por qué la "S", lo mejor es que leas “Atajos de teclado en documentos Web" de Accesibilidad Web y Alan.

Tal y como indica, los atajos propuestos por el gobierno del Reino Unido son:

S - Saltar navegación
1 - Página de inicio
2 - Novedades
3 - Mapa del sitio
4 - Búsqueda
5 - Preguntas frecuentes (FAQ)
6 - Ayuda
7 - Reclamaciones
8 - Términos y condiciones
9 - Contactar
0 - Definición de teclas rápidas

En Suecia, en las Swedish National Guidelines for Public Sector Websites, las teclas de acceso rápido que se indican para los portales de la Administración Pública son, según ellos mismos indican, basadas en las del Reino Unido:

S - Skip navigation, go directly to text content
0 - “About the website”, accessibility information. Provided details on access keys
1 - “Home” page
2 - News. Collection of news
3 - Content outline. A site map, or perhaps A-Z
4 - Search. Should be connected to the search field that searches the entire website
5 - Frequently Asked Questions (FAQ)
6 - Help. For example, about a specific service.
7 - Contact us. Page with contact details to important functions within the government agency.
8 - Legal information. Page that describe the website’s privacy policy and how legal information such as cookies are handled.

Ya he comentado en el apartado de navegación semántica el atributo "rel", es interesante el artículo sobre rev y rel "Hypertext links in HTML" de Murray Maloney y Liam Quin

     
<div id="cabeceraDiv">       
[…]       
</div>       


<div id="migasDiv">       
[…]       
</div>       


<div id="contenidoDiv"><a id="content" name="content">Inicio del contenido</a>       
[…]       
</div>       


<div id="menuDiv"><a id="menu" name="menu">Menu</a>       
<ul>       
   <li><a href="" accesskey="" rel="" rev=""></a>       
      <ul>       
        <li><a href="" accesskey="" rel="" rev=""></a></li>       
      </ul>       
  </li>       
</ul>       
</div>       


<div id="pieDiv"><a id="copyright" name="copyright">Copyright</a>       
[…]       
</div>       

</div>

Supongo que lo primero que llama la atención es que el código del menú esté al final de la página, por supuesto esto no tiene nada que ver con la situación visual del mismo que se define en la CSS. Prefiero colocarlo al final, porque ya tenemos al comienzo la navegación semántica y los dos enlaces de saltar al contenido y al menú, así que coloquemos lo primero el contenido, que es lo realmente importante de nuestra página.

Otro dato importante es que la estructura de nuestra página siempre ha de estar armada mediante DIV y nunca mediante tablas... no creo que hoy en día haya nadie capaz de rebatir esto.

También es importante que el menú esté estructurado mediante listas anidadas (si has leído el artículo completo ya no es necesario que explique los atributos "rel" y "rev").

El punto 9.5 de las pautas WCAG recomienda incluir atajos de teclado para los enlaces importantes. La Administración Pública del Reino Unido tiene definido un estándar de teclas rápidas en la guía para desarrolladores (Web handbook), como defiende Accesibilidad Web y Alan en "Atajos de teclado en documentos Web ". apliquemos las mismas:

S - Saltar navegación
1 - Página de inicio
2 - Novedades
3 - Mapa del sitio
4 - Búsqueda
5 - Preguntas frecuentes (FAQ)
6 - Ayuda
7 - Reclamaciones
8 - Términos y condiciones
9 - Contactar
0 - Definición de teclas rápidas

Por último, y en referencia a las anclas, indicar que el atributo id para marcar anclas se puede utilizar en cualquier etiqueta, sin embargo puede que algunos navegadores no lo reconozcan como un ancla, por eso se suele "anclar" sobre elementos a; se incluye el name también porque algunos viejos navegadores es posible que no reconozcan el atributo id.

No he dejado las anclas vacías, sino que he incluido dentro un texto; posteriormente se puede mover el ancla o sustituir este texto según el contenido y la estructura final de la página.

Puedes ampliar información en el W3C.

Otros enlaces de interés:

"Ocho pasos para servir buen XHTML" de Torres Burriel
Dive Into Accessibility.30 days to a more accessible web site
"Tags HTML no recomendados y sus alternativas" de Anieto2k

BODY: Microformatos

Ya hemos visto cómo añadir información semántica a la página mediante metas, mediante ficheros RDF, etc. Otra manera son los microformatos, una forma de representar información semántica cuyo objetivo principal es ser útil a las personas y no a las máquinas. Esta información aparece entre las etiquetas <body> y </body> de un documento HTML.

Los microformatos se salen ya del objetivo del artículo, si necesitas ampliar información te recomiendo:

el brillante artículo de Web semántica hoy “Etiquetas meta, ficheros RDF, microformatos: 3 sabores de la Web Semántica"
"Dublin Core Metadata Gen: Generador de metadatos Dublin Core" de Webposible
"hCard" de microformats.org

Fin del documento

     
</body>       

</html>

Plantilla XHTML base

Por supuesto habrá que adaptarla al desarrollo concreto, modificando lo que sea necesario (por ejemplo el title, la descripción de la página, etc.) y eliminado lo que no lo sea (por ejemplo, aquellos metas que no consideremos necesarios). Para ello te será de utilidad la información recopilada en el artículo.

La plantilla se distribuye bajo un contrato ColorIURIS. Deberás aceptar el contrato antes de descargarla:

Descargar Plantilla XHTML base