HTML provee de un conjunto de elementos estructurales para definir citas. Una cita, según su acepción como mención es:

Recuerdo o memoria que se hace de una persona o cosa, nombrándola, contándola o refiriéndola.

Estructuralmente podemos definir tres tipos de citas:

• Un bloque extenso de texto referido desde algún texto, publicación o cualquier otra fuente externa
• Una referencia breve de un contenido de una fuente externa
• Una referencia a otras fuentes, sin citar necesariamente contenidos específicos

Estos tres tipos de referencia tienen su representación en HTML en los elementos blockquote, q y cite respectivamente.

Uno de los aspectos interesantes de estos elementos es el hecho de que el contenido que definen gana un valor semántico importante: cualquier procesador automatizado o cualquier persona que lea el código reconoce que estas estructuras se refieren a un contenido que está siendo referenciado. Es decir, reconoce el sentido y relación de este contenido respecto al documento.

Más aún, podemos utilizar el atributo cite para blockquote y q para indicar la fuente de destino en la forma de una URI. Es importante no confundir el atributo cite, propio de los elementos blockquote y q, con el elemento cite.

El ejemplo de la definición de la palabra cita que aparece poco más arriba, utiliza blockquote junto con el atributo cite para indicar la definición en el sitio de la RAE.

Una distinción más sutil es la que marca la diferencia entre los elementos q y cite. q, así como blockquote definen un contenido extraído de una fuente externa, sólo que en el primero se trata de un texto breve, contenido dentro de un párrafo u otro elemento de bloque. cite, en tanto, tiene como objetivo el definir una referencia, o más bien la fuente de una referencia. Un ejemplo de esto es:

El elemento cite está definido en la sección de Texto Estructurado de la Especificación de HTML 4.01.

Estos elementos permiten enriquecer el valor semántico de los contenidos, en tanto que al identificarlos según su estructura podemos presentarlos apropiadamente usando CSS.

¿Cuál es el objetivo de validar un documento (X)HTML? ¿Es acaso el comprobar que cumplimos 100% con la sintaxis del tipo de decumento, independientemente de la estructura de contenidos que éste tenga? ¿Vale la pena tener un documento que pase las pruebas automatizadas de validación independientemente de la estructura interna?

Yo creo que no . No creo que el espíritu de un estándar sea el que los documentos cumplan sólo formalmente con su sintaxis. En un post anterior planteé algunos aspectos de mi forma de enfrentar los temas de estándares y validación. Lo importante no es cumplir formalmente, sino utilizar la estructura que HTML o XHTML nos proveen para organizar y dar cuerpo a los contenidos.

Progresivamente podemos observar una proliferación de sitios utilizando correctamente DOCTYPE para definir los tipos de documentos, e incluso muchos utilizando XHTML. Esto es en parte debido al soporte de las herramientas de desarrollo así como también porque el tema está en el aire. Pero muchos de esos documentos que se declaran como XHTML utilizan una diagramación basada en tablas. Técnicamente es posible y el (X)HTML puede validar pero la estructura de los documentos es pobre y no describe realmente la jerarquía y relaciones internas del contenido.

¿A qué me refiero? El validador de HTML del W3 genera un outline que utiliza los encabezados del documento (los elementos h1 al h6) para representar la estructura de contenidos. Este tipo de análisis se basa en el reconocimiento de la estructura de los contenidos, que es relativamente fácil de extraer de un documento bien organizado.

Los elementos h1, h2, h3, h4 , h5 y h6 deben representar la estructura de un documento mediante la jerarquización de los contenidos. h1 es el título principal, por lo tanto su contenido es relevante para determinar de qué trata un documento. Por lo mismo, h2 determinará un contenido secundario, pero de mayor relevancia o peso que el contenido de h3. Evidentemente ningún analizador automatizado podrá extraer la estructura real de un documento que no use apropiadamente los encabezados.

Otros beneficiados del uso de elementos estructurales de XHTML son los buscadores. Para un robot indexador tiene mucho sentido reconocer la estructura de un documento mediante sus encabezados y otorgará un mejor ranking a aquellos contenidos que declaren su estructura explícitamente.

Tampoco es muy razonable utilizar recursos como <div id="titulo"> porque no representan realmente a la estructura.

Del mismo modo otros elementos determinan estructura dentro de un documento, un p es un párrafo, es decir, un conjunto ordenado de ideas relacionadas que termina en un punto aparte. Los contenidos de una tabla utilizada para contenidos tabulares reflejan una relación basada en los cruces de filas y columnas: una celda pertenece a una fila y una columna, esta relación le confiere un sentido especial.

Así, formalmente un documento puede pasar una validación automatizada, pero eso no significa que la sintaxis esté utilizada de modo apropiado para reflejar la estructura de los contenidos.

Desde hace ya varios años que me dedico a promover el uso de buenas prácticas en el Web y a incentivar el uso de estándares como XHTML y CSS. Los beneficios de utilizar los estándares son muchos y seguramente escribiré más adelante acerca de ellos. No obstante, mencionaré algunas ideas al rspecto. Estándares como CSS y XHTML además establecer un lenguaje común en el que todos nos podemos comunicar, en el que podemos confiar (poco más o menos) que los navegadores modernos respetarán de un modo razonable y que de paso facilita el trabajo a agentes de indexación (los robots) y otros procedimientos automatizados, nos permiten separar eficientemente el contenido y la presentación, el diseño visual.

Pero estas herramientas, que nos deberían simplificar la vida están implementadas y adoptadas de modo direferente y no somos nosotros (normalmente) los que controlamos el amplio universo en el que publicamos nuestros productos, léase contenidos, sitios, documentos, etc.

Es por esto que en momentos, en la vida real, aunque tengamos un compromiso grande con el respeto a los estándares, tenemos que tomar decisones que bajo cierta óptica pueden ser cuestionables. En efh yo puedo darme el lujo de ser estricto y controlar muchos aspectos, tomar desiciones autónomas y determinar qué técnicas utilizo, pero la vida no simepre es así. La idea es tener en el horizonte y como objetivo que el estándar es tal y las cosas deben ser así, y lo haremos en la medida que esto sea factible.

Cito un ejemplo: en una de las CSS de la Guía Web hay una propiedad, white-space a la que agregamos el valor pre-wrap, que es una definición propia de Microsoft para Explorer, por lo tanto no valida, para asegurar que este navegador desplegara correctamente lo que nosotros necesitábamos. El valor real, estándar es pre y lo agregamos mediante un hack sólo para los browsers estándar.

p.code {
white-space: pre-wrap;
}

h t m l >body p.code {
white-space: pre;
}

Todo el mundo recibe lo que quiere, sin que eso signifique un perjuicio muy grande. Ese es el único error de validación, es conciente y por razones concretas. Los browsers estándar reciben una versión estándar, Explorer recibe lo que necesita.

Podría citar otros ejemplos, pero creo que esto ilustra mi punto: lo importante es hacer el mejor esfuerzo de lograr la conformidad con los estándares, pero hasta que los navegadores sean 100% compatibles, tendremos que recurrir a trucos como esos. La idea es que sean los menos.

No quiero ser malinterpretado, yo soy tremendamente exigente respecto a estos temas, este sitio valida 100% sin errores y además es WAI-AAA (tengo algunos ajustes que hacer a este respecto, pero están en la lista de to-dos). Quienes me conocen lo saben, pero no soy integrista.

Moraleja: construye tus sitios considerando y respetando los estándares, pero no creas que el objetivo final es el estándar. Éste es sólo un medio, y en tanto el soporte real de los navegadores no sea el apropiado, habrá que procurar soluciones que se ajusten a la realidad.

Desde hace ya algún tiempo está al aire la Guía para el Desarrollo de Sitios Web de Gobierno. La iniciativa del Gobierno de Chile fue un esfuerzo que se basó en las conclusiones y experiencias de la primera versión del Premio Web. Su objetivo es el reunir una serie de buenas prácticas y recomendaciones que los sitios del Estado deben cumplir para asegurar un óptimo servicio a los ciudadanos.

Pese a que aún no ha sido presentada oficialmente, la Guía está disponibla para consulta y su recepción ha sido importante.

El Coordinador del proyecto fue Paulo Saavedra y el responsable de la edición Juan Carlos Camus. Mi papel en este proyecto fue construir el sitio de la Guía, que por su naturaleza debía cumplir con todas las recomendaciones del documento y ser muy respetuoso de los estándares, considerando entre otras cosas, accesibilidad. En este aspecto el sitio cumple con todas las guías de verificación automáticas y con una serie de los puntos de chequeo manual.

Nota: actualmente el sitio presenta un problema de validación en la portada producto del código de certificación de Certifica, que es un elemento ajeno al sitio. Esto se solucionaría próximamante.

Uno de los aspectos más interesantes de la construcción del sitio, al menos para mí que soy un maniático declarado de los estándares, es el uso meditado y cuidadoso de cada elemento o tag de XHTML. Los invito a anlaizar la estructura de los documentos que, naturalmente, confían la presentación a CSS. Una página en particular que me dió mucha satisfacción es el Glosario. Observen el cuidadoso uso de las listas de definición DL y de la lista de navegación alfabética al principio de la página.

Quedan otras cosas por revisar del sitio, pero la verdad es que necesitaré otro post completo para eso. Por ahora los dejo con la presentación, prometo una visita más detallada de los detalles de la construcción y las decisiones que fue necesario tomar respecto a estructura, presentación, estándares, etc.

Una de las funcionalidades que me resultan más cómodas en Mozilla es la llamada Find As You Type. Consiste básicamente en que el usuario puede escribir aquéllo que desea encontrar en una página, con el foco en el documento, sin necesidad de abrir una ventana de buscador y Mozilla buscará y destacará en el contenido del documento lo que uno está ingresando.

Por otro lado todos hemos observado el comportamiento de la barra de ubicación en los browsers que tratan de hacer cincidir la URL que uno ingresa con aquéllas registradas en el historial. Incluso en los entornos de desarrollo IDE las funciones de autocompletación de código proveen una utiidad similar.

OK, pero todo eso en aplicaciones de escritorio no es algo demasiado impresionante, sin menospreciar su utilidad. Lo destacable es implementarlo en entorno Web. Es por esto que me detengo nuevamente en el caso de Livesearch que mencionara en un post anterior.

La búsqueda dinámica implica que se están realizando una serie de conexiones y queries en el servidor, y me pregunto cuánto afectará esto al rendimiento y cuántos recursos adicionales utilizará. Aparentemente esto está resuelto de modo bastante apropiado en Livesearch, observando su comportamiento aparentemente las búsquedas se realizan sobre los títulos de los posts en el sitio y no sobre los contenidos completos y es posible que una vez realizada una conexión para obtener los datos de, por ejemplo, Li si ingreso luego Livesearch se puedan filtrar los contenidos localmente vía JavaScript sin necesidad de realizar nuevas comunicaciones con el servidor.

Estoy especulando, habrá que ver con más detalle su implementación, pero el punto destacable es el hecho de ser una aplicación inteligente de tecnologías combinadas al servicio del mejoramiento de la experiencia de uso.

El weblog de Chregu Stocker tiene una característica que no había visto en ningún otro sitio y que me parece un aporte de usabilidad tremendo: el buscador realiza búsquedas dinamicas mientras el usuario ingresa los términos deseados.

El mecanismo, denominado Livesearch opera del siguiente modo: en la medida que existan coincidencias, luego del tercer o cuarto caracter ingresado, y sin haber hecho un submit del formulario se despliegan resultados parciales que se van filtrando en la medida que se completa el texto de búsqueda.

El formulario de búsqueda de todos modos funciona también como un buscador convencional y presionando Enter procesa la búsqueda en el servidor y se retornan los resultados coincidentes con los criterios.

La tecnología que hace posible esto es una combinación de JavaScript, DOM, y XML. El objeto XMLHttpRequest permite realizar una conexión HTTP con el servidor para solicitar los datos requeridos. Todo esto sin recargar la página en el browser.

El resultado es un mecanismo que no afecta al funcionamiento estándar del buscador, pero que incrementa su efectividad y su usabilidad.

Las siguientes son dos presentaciones sobre accesibilidad que he preparado para diversos propósitos. Si les son de utilidad les invito a usarlas libremente.

Las presentaciones están en formato PDF y se encuentran licenciadas bajo Creative Commons.

• Presentación en formato PDF (62.7 KB) con una introducción a la validación de accesibilidad en el Web.
• Presentación en formato PDF (124 KB) sobre accesibilidad y Iniciativa de Accesibilidad para el Web del W3C.