Su navegador no admite frames. <a href='http://www.blogger.com/home'>Acceder a la página pricipal de Blogger</a>

Usable y accesible. Olga Carreras

Ir al contenido | Cambiar el color y tamaño del texto

Menú

Ir al comienzo del artículo

Catálogo de servicios

Portada Catálogo de servicios (Word en formato ZIP 2.20 MB) Versión accesible en HTML

Archivos

Usable y accesible. Olga carreras

domingo 26 de agosto de 2007

Plantilla base XHTML


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:






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:



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:



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 de tu página muestre por ejemplo Google en su resultado, y deberías colocarla en primer lugar.


La descripción no debe superar las 200 palabras.


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: Icono de uso de metas Dublin Core


Otros enlaces de interés:





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:





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:



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:



Barra de navegación semántica en Opera

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



Barra de navegación semántica en Explorer

En Lynx, por ejemplo,



Barra de navegación semántica en Lynx

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:



Barra de navegación semántica en Explorer: enlaces alternate

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:



Barra de navegación semántica en Explorer: enlaces propios

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.

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:





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:




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


Contrato Coloriuris









Publicado por Olga Carreras

Compártelo en:
Añadir a Facebook Añadir a Twitter Añadir a Fresqui Añadir a Delicious Añadir a Digg Añadir a Technorati Añadir a Yahoo Añadir a Meneame Añadir a Bitacoras.com Añadir a BarraPunto Añadir a Google

Etiquetas: , ,


26 comentarios en el artículo "Plantilla base XHTML"