headingsMap

Esta extensión genera un índice (o mapa) de cualquier documento web estructurado mediante el uso de encabezados, de tal manera que pulsando sobre cualquiera de los items de dicho mapa, se accede directamente al contenido correspondiente de la página.

Sí, ya lo se, esto mismo lo hace también otra extensión (documentmap). La diferencia estriba en que headingsMap, además de indicar los niveles de cada encabezado y los posibles errores que pudiera haber en su secuencia (por ejemplo, los saltos inadecuados), en el caso de haber marcos (FRAMESET e IFRAMES) también genera el mapa para cada uno de ellos. De esta manera, se convierte en una herramienta útil tanto para la navegación por el documento como para revisar y/o auditar sitios web (en cuanto a accesibilidad, estándares, etc).

Como no podia ser menos, también se le ha añadido una funcionalidad adicional. En el caso de que el documento web al que se esté accediendo sea una presentación en formato web hecha con acc_slide (o rumoslide) o con HTML Slidy, la extensión funciona como un índice, permitiendo acceder directamente a la diapositiva que se desee.

En la página de la extensión headingsMap se puede encontrar más información, así como en Firefox add-ons.

Al instalar la extensión, aparece un icono en la barra de estado que despliega el panel lateral en el que se muestra la estructura de encabezados. También se puede acceder mediante la combinación del teclado Alt + O.

WCAG Contrast checker

Mediante esta extensión se puede comprobar si la combinación de dos colores es adecuada para su percepción visual en base a los requerimientos de las WCAG 1 y WCAG 2, empleando para ello el algoritmo que estas proponen. Dado que el algoritmo incluido en las WCAG 2 parece ser más preciso, el resultado de este es el que se muestra por defecto.

En un panel lateral se ofrece la posibilidad de introducir el código de los dos colores que se quieren comparar, mostrándose los resultados tanto para el caso de una percepción normal de los colores, como para situaciones tales como la protanopia, deuteranopia y tritanopia.

El código de color se puede introducir tanto en formato hexadecimal (en forma abreviada o no, y tanto con almohadilla como sin ella), como en RGB (pudiendo usar diferentes separadores entre los valores, como por ejemplo la coma o los dos puntos). Ej:

• En hexadecimal se podría poner: #FC5 ó FC5 ó FFCC55
• En formato RGB se podría poner: 231,28,197 ó 231:28:197 ó rgb(231,28,197)

El uso de la extensión WCAG Contrast checker se puede combinar con la extensión ColorZilla, pues esta permite seleccionar directamente desde el documento web (y copiar al portapapeles) el color que se quiera comprobar. Si se tiene dicha extensión instalada, WCAG Contrast checker reconocerá su presencia. En este caso, pulsando Shift + Z ó Shift + X se activará el eyedropper del ColorZilla y se enviará de forma automática, bien el color de primer plano, bien el de fondo, al WCAG Contrast checker para su análisis.

La extensión hace aparecer un icono en la barra de estado que al pulsarlo despliega el panel lateral, pudiendo acceder también mediante la combinación del teclado Alt + C.

En la página de la extensión WCAG Contrast checker y en Firefox Add-ons hay más información, además del enlace para la descarga.

La pregunta no parece complicada a simple vista. Simplemente con utilizar el elemento <script> en dicho documento, donde el valor del atributo src nos indique donde se encuentra el fichero, sería suficiente.


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


Sin embargo, si por un "descuido" olvidásemos la etiqueta de cierre de este elemento (</script>) comenzarían los problemas. IE (6 y 7) devuelven un documento en blanco, sin contenido. Si vemos el código fuente de la página, esta todo. Qué raro, ¿no?

En todo caso, la solución no es difícil. Cerramos el elemento y arreglado.

Si se trata de un documento XHTML, al ser nosotros unos tíos finos que nos gusta el código limpio y ordenado reducimos el código de llamada al código JavaScript mediante el uso de un elemento vacío, al igual que haríamos con contenedor de metainformación (<meta />), una imagen (<img />) o incluso con un vínculo a un recurso externo (<link />).

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

Sin embargo, a pesar de ser un documento válido, Volvemos a lo mismo, IE nos vuelve a sorprender con un documento en blanco. De nuevo, la solución es sencilla: utilizar la correspondiente etiqueta de cierre del elemento (</script>).

¿Eso es todo?. No, que va. Si todo el trabajo lo realizaramos de forma manual no sería mayor inconveniente que recordar en todos los documentos que tenemos que utilizar esta etiqueta de cierre. Lamentablemente, hoy en día las cosas son un poco más complicadas y es habitual que el contenido sea generado y procesado a partir de otros documentos XML, por lo que el tratamiento de ciertos elementos se realiza en cadena. Por ejemplo, a los elementos vacíos se les proporciona de forma automática su correspondiente etiqueta de cierre (<img></img>, <input></input>, <script></script>), lo que a fin de cuentas devuelve un código no muy limpio. Si por el contrario sucede que a todos los elementos vacíos se les aplica la barra de cierre (/) tendremos los problemas anteriormente descritos con nuestro navegador más querido.

La recomendación HTML 4.01 indica que la etiqueta de cierre del elemento <script> es requerida, pero de ahí a que IE se altere y deje de respirar va mucho. ¡Qué menos que pasarse a modo quirks!, ¿no creéis?

Un caso práctico

Para ponernos en situación, lo mejor será utilizar un caso real de uso, a partir del cuál interpretar el problema. Tenemos el siguiente marcado:

<blockquote>
  <p>
    An equal opportunity disease afflicts nearly every site now on the
    web, from the humblest personal pages to multimilliondollar sites
    of corporate giants. Cunning and insidious, the disease goes largely
    unrecognized because it is based on industry norms. Although their
    owners and managers might not know it yet, 99.9% of all websites
    are obsolete.
  </p>
  <p>Jeffrey Zeldman</p>
</blockquote>

Por un lado, parece bastante claro que se trata de una cita textual extraída de algún recurso (documento impreso, artículo, sitio web, etc). En este caso no parece que se esté utilizando con fines de presentación, sino que se está realizando un marcado adecuado.

Por otro lado tenemos al autor de dicha cita, Jeffrey Zeldman. ¿Debería marcarse con el elemento <cite>?

Bien, yo diría que, a primera vista, no. Al menos la ausencia de marcado de este tipo no debería considerarse un error.

¿Por qué?

Vamos a tirar de estándar. El elemento <blockquote> (también <q>) tiene un atributo (cite) que nos permite, a través de una URI, indicar el documento fuente del que se ha extraído dicha cita. En caso de tratarse de un documento impreso, asignarle una URI nos complica un poco el tema. Nada imposible, por supuesto.

Por otra parte, tenemos el elemento <cite> que, según la especificación HTML 4.01, contiene una cita o referencia a otras fuentes. (Contains a citation or a reference to other sources). Vamos, que viene a tener la misma función que el atributo con el mismo nombre, pero con la ventaja de que podemos citar cualquier tipo de recurso. En ningún momento indica que este elemento se tenga que utilizar para indicar el autor de una cita, aunque es cierto que los ejemplos de la especificación lo hacen.

¿De que sirve marcar como <cite> al autor de una cita textual?. Si el contenido de este elemento no es capaz de proporcionarnos la información suficiente como para localizar el documento original del que se ha extraído, de poco. Autores como Zeldman no se caracterizan precisamente por haber escrito una única obra (artículo, libro, entrada en su diario personal, etc), por lo tanto, ¿de qué obra estamos hablando?

El contenido de este tipo de elementos debería servir como punto de acceso a una información más completa del recurso que se está citando, es decir, una asociación inequívoca a la lista de referencias bibliográficas utilizadas en nuestro documento.

Utilizar de forma adecuada este elemento, así como citar correctamente, proporciona una serie de ventajas (Eaves; Hurst, 1998):

• credibilidad al que escribe el documento, ya que es una forma de demostrar que se ha leído sobre el tema;
• reconocimiento al autor del recurso citado, conocido como visibilidad en entornos de investigación;
• información al lector, de forma que este pueda ampliar sus conocimientos, así como corroborar la autenticidad de la información.

Marcar correctamente las citas

Una buena cita se compone de dos elementos: la cita en el texto y la referencia bibliográfica a la que apunta y donde encontraremos la información completa que nos lleve a localizar un documento.

Para expresar la primera parte se utilizan gran variedad de estilos (University of Wisconsin-Madison, 2006), (Merlo; Sorli, 2000) donde generalmente se indica entre paréntesis el apellido del autor y el año de publicación.

<cite>(Zeldman, 2003)</cite>

Esta información nos permitirá encontrar en la lista de referencias bibliográficas utilizadas en el documento, localizar el documento concreto del que se ha extraído la información.

<li>
  Zeldman, Jeffrey (2003). Designing with Web Standards. 1st. ed.
  New Riders Publishing, [New York]. 0735712018.
</li>
<li>
  Zeldman, Jeffrey (2001). Taking your talent to the web: Making the
  transition. 1st. ed. Que Pub. 0789724898.
</li>

En caso de normas, estándares, recomendaciones, etc. cuyo responsable principal suele ser una organización (OASIS, W3C, ISO, AENOR, etc.), resulta más útil hacer referencia al título abreviado de la norma o estándar.

<cite>(WCAG10)</cite>

<li>
  W3C. Web Content Accesibility Guidelines 1.0 (WCAG10). [En línea].
  Wendy Chisholm; Gregg Vanderheiden; Ian Jacobs; 5 mayo 1999. W3C
  Recommendation. <a href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/">
  <http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/></a>
</li>

La creación de las referencias bibliográficas tiene sus propios estándares, tanto nacionales (UNE-50104) como internacionales (ISO 690 e ISO 690-2).

Otras buenas prácticas

Hemos visto que marcar de forma adecuada una cita proporciona al lector información útil que le permitirá acceder a un nuevo recurso si lo considera interesante. En el caso del atributo cite de los elementos <blockquote> y <q>, al tener como valor la URI del documento fuente, no va a proporcionar la misma información que una referencia bibliográfica completa. Tendremos que acceder al recurso y comprobarlo por nosotros mismos. Para aportar un poco más de información útil podemos utilizar este atributo para introducir una URI que apunte directamente a nuestra referencia bibliográfica.

<blockquote cite="http://uri_a_referencia/referencia.html#dwws">
  <p xml:lang="en" lang="en">
    An equal opportunity disease afflicts nearly every site now on the
    web, from the humblest personal pages to multimilliondollar sites
    of corporate giants. Cunning and insidious, the disease goes largely
    unrecognized because it is based on industry norms. Although their
    owners and managers might not know it yet, 99.9% of all websites
    are obsolete.
  </p>
  <p>Jeffrey Zeldman</p>
</blockquote>

Una buena idea es convertir el elemento <cite> en un ancla que apunte directamente a la referencia bibliográfica, evitando de este modo que el lector tenga que desplazarse mediante el scroll para localizarla.

<cite><a href="#dwws" title="Enlace a
referencia bibliografica">(Zeldman, 2003)</a>
</cite>

Esta información nos permitirá encontrar en la lista de referencias bibliográficas utilizadas en el documento, localizar el documento concreto del que se ha extraído la información.

<li id="dwws">
  Zeldman, Jeffrey. Designing with Web Standards. 1st. ed. 2003
  New Riders Publishing, [New York]. 0735712018.
</li>

Por último, y utilizando algo de javascript, podríamos cargar dinámicamente la información que aparecen en la referencia bibliográfica al pasar el ratón sobre la cita, a modo de tooltip. De este modo se evita que el usuario se mueva por el documento para obtener la información.

Conclusiones

De lo expuesto a lo largo de este artículo, salido de lo más profundo de las fuentes de Maroto, queremos dar a entender que no marcar al autor con el elemento <cite> no se debería considerar un error de accesibilidad, ni siquiera de semántica. Por supuesto, en caso de marcarlo, sería conveniente aplicar las recomendaciones aquí expuestas.

Probablemente la confusión al respecto de este elemento y el problema de accesibilidad que refleja el punto de verificación 3.7 surja de la traducción del mismo. Mark up quotations. Do not use quotation markup for formatting effects such as indentation. Si bien el castellano se caracteriza por su gran riqueza, en este caso el uso de la palabra cita genera demasiada ambigüedad. Por el contrario, en inglés hay una importante diferencia entre lo que se entiende por quotation (transcripción literal de las palabras de otra persona) y citation (dar credibilidad a dicha transcripción).

Referencia

• AENOR. Referencias bibliográficas. Contenido, forma y estructura (UNE-50104:1994). 1994-01-19.
• Eaves, Dan; Hurst, John (1998). Standards for the Presentation of Written Assignments. [En línea]. 18 p. <http://www.csse.monash.edu.au/~ajh/teaching/resources/studentguide.pdf>
• ISO. Information and documentation — Bibliographic references – Content, form and structure (ISO 690:1987). [En línea]. 2005-08-30. <http://www.iso.org/[...]>
• ISO. Information and documentation — Bibliographic references — Part 2: Electronic documents or parts thereof. (ISO 690-2:1997). [En línea]. 2004-06-30. <http://www.iso.org/[...]>
• Merlo Vega, José Antonio; Sorli Rojo, Ángela (2000). Estilos de citas y referencias de documentos electrónicos. [En línea]. Revista Española de Documentación Científica. vol. 23, no. 4, pp. 483-496. <http://exlibris.usal.es/merlo/escritos/citas.htm>
• University of Wisconsin-Madison (2006). Citing references in your paper. [En línea]. <http://www.wisc.edu/writing/Handbook/Documentation.html>
• W3C. Web Content Accesibility Guidelines 1.0 (WCAG10). [En línea]. Wendy Chisholm; Gregg Vanderheiden; Ian Jacobs; 5 mayo 1999. W3C Recommendation. <http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/>

Supongo que alguno ya conocerá más de un sistema de los que habitualmente se utilizan, como por ejemplo el HTML Slidy del W3C o el S5 de Eric Meyer. Tras utilizarlos llegué a la conclusión de que, aunque buenos, había algo que quizás podría ser mejorable (según mi criterio, claro).

Como he dicho, ambos sistemas son buenos y válidos, pero en ambos se hace necesario utilizar marcado cuya única finalidad es la de servir para que el script lo utilice y aplique estilos sobre él. Si realmente se quiere tener algo eficaz, ¿por qué no hacer que el propio script genere el marcado que necesita de forma inteligente?

El desarrollo

Me puse manos a la obra con la siguiente premisa: Si tenemos un documento correctamente estructurado y marcado (con sus encabezados, párrafos, listas…), el script debe ser lo suficientemente inteligente como para organizar y generar la presentación, todo ello sin incluir ningún contenedor adicional, ni clases, ni id. Únicamente ha de ser la propia estructura del documento la que permita diferenciar lo que se tiene que incluir en cada diapositiva.

Tras pegarme con ello, aquí está el resultado. El acc_slide, o como Andrés y Maroto lo llaman, rumo_slide o slide_oso. En lugar de seguir escribiendo más acerca de ello, lo mejor es demostrar de lo que estoy hablando. He preparado dos presentaciones, ambas con la descripción del sistema y de su utilización. La diferencia entre ambas es el grado de resumen. No dudéis en echar un vistazo al marcado que he empleado para ver de lo que estoy hablando:

nota: aunque la forma de navegación por la presentación se trata en la misma, la forma básica de moverse por los contenidos se realiza con las flechas (arriba y abajo) del teclado.

• Versión reducida y Versión reducida descargable
• Versión extendida (si, muy extendida) y Versión extendida descargable

Características básicas

acc_slide ha sido creado teniendo como objetivo la separación absoluta entre el contenido y el comportamiento, evitando cualquier consideración acerca de este al crear y marcar la información que se quiera mostrar.

Entre las características que el sistema de presentaciones acc_slide posee se pueden destacar:

• Únicamente requiere de una correcta y lógica estructuración del contenido mediante el uso de encabezados. No necesita de elementos adicionales más allá de los necesarios para el marcado semántico del contenido. El sistema reconstruye y adapta el árbol DOM, con lo que no impone la necesidad de un marcado concreto. Esto lo hace compatible con cualquier documento (X)HTML bien estructurado (incluso con los que incluyen el marcado empleado por otros sistemas de presentaciones). Esto lo hace totalmente versatil. Se podría utilizar sobre un documento web, sobre el marcado empleado en los otros sistemas de presentaciones, etc.
• Respetuoso con los estándares y la accesibilidad.
• Separación absoluta de contenido, presentación y comportamiento.
• Fácil integración y fácil utilización. No requiere conocimientos específicos, y si se utiliza uno de los temas propuestos, no es necesario conocer CSS.
• Permite crear secciones con grupos de diapositivas.
• El aspecto gráfico ofrece gran versatilidad y se controla totalmente con CSS. Además se pueden crear varios estilos y jugar con la especificidad de selector para aplicarlos (y combinarlos) en caliente (mientras se ejecuta la presentación).
• Sistema autoplay de reproducción automática.
• Incorpora un sistema para abrir enlaces de forma integrada a la presentación. Si se incluye el atributo title en el enlace, el contenido de este se mostrará al pié de la ventana. Además, el destino del enlace puede ser una URL o una imagen.
• Cada diapositiva se asocia con un ancla de tal manera que se puede ir directamente a la que se desee. El ancla coincide con la posición de la diapositiva en la presentación.

Llegados a este punto, espero vuestro feedback. También estaba pensando crear un repositorio público de estilos para el sistema. Si os parece una buena idea y queréis participar con los vuestros, no lo dudéis. Podéis enviar vuestros temas a rumoroso@niquelao.net

¿Qué? ¿Estoy o no estoy a la última?. Esto no se consigue ni con un master.

Por todos es conocido que Internet Explorer (6 y anteriores) no soporta XHTML en absoluto y que en el momento en que encuentra algo diferente a la declaración de tipo de documento (DOCTYPE) entra en modo quirks, es decir, cuando encuentra la declaración <?xml?> en la primera línea del documento suceden cosas raras.

Haciendo uso de los famosos comentarios condicionales de Internet Explorer (IE) vamos permitir que aparezca la declaración <?xml?> en nuestros documentos XHTML en aquellos navegadores que soportan este tipo de ficheros.

Problemas conocidos

Por ejemplo, queremos tener todas las páginas de nuestro sitio centradas, con cierto espacio por los lados. Ya sabemos que con Firefox (FF) bastaría con aplicar al bloque contenedor la siguiente declaración en la hoja de estilo CSS:

	#contenedor {
	   margin: 0 auto;
	   width: 65%;
	}

Sin embargo en nuestro amigo IE6 deberíamos añadirle algo como esto:

	body {
	   text-align: center;
	}

Todo esto se debe a lo que comentabamos anteriormente, IE entra en modo quirks y empieza a dar problemas. Sin embargo, si a IE le proporcionamos una declaración de tipo de documento correcta actuará igual que otros navegadores estándar (al menos en su mayor parte). Hay que tener en cuenta que para IE la declaración de tipo de documento correcta incluye: el identificador público y de sistema adecuados además de no tener nada antes que esta declaración.

¡Aquí es donde la matan!. La declaración <?xml?> siempre debe aparecer en la primera línea.

Buscando soluciones

¿Que podemos hacer?. Está claro que hay otros navegadores que aceptan este tipo de declaración y no todo el mundo tiene acceso a lenguajes del lado del servidor para identificar cuando se trata de uno u otro navegador para enviarle un tipo u otro de cabecera.

La solución nos la ofrece el mismo IE, los famosos comentarios condicionales (muy bien explicados en Diseñorama).

La cosa es sencilla, cuando se trate de IE le indicamos que no lea la línea de comentarios y cuando sea otro los tratará como comentarios. Ahí va el código del delito:

<!--[if !IE]><-->
	<?xml version="1.0" encoding="UTF-8"?>
<!--><![endif]-->

Por cierto, antes de que nadie venga pidiendo la silla eléctrica para el autor del artículo, se recomienda tomar todas las precauciones posibles. La primera de ellas, y casi la única, es fácil: leer.

• Recomendación XHTML 1.0 del W3C
• Apéndice C de la Recomendación XHTML 1.0
• XHTML no es para principiantes (versión española).
• Tipos de medio para servir XHTML

Por último, recordar que los comentarios condicionales no funcionarán en la versión de IE para Mac.