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.

Para evitar las frustrantes esperas que hemos de sufrir cuando, tras realizar la consulta, la fecha elegida no está disponible, en algunos sitios el calendario las filtra ofreciendo sólo las que si lo estan. Esto me hizo pensar que al acc_calendar le hacía falta esa posibilidad para quedar (al menos un poco) “niquelao”.

Dicho y (tras un buen rato) hecho. Mediante un toque de ajax, podemos aplicar un filtro sobre el calendario para que únicamente permita la selección de determinadas fechas. Para ello, de forma opcional añadiremos la clase disp en el campo de texto para la fecha. En el script hay disponible una variable (fichero_consulta) en la que indicar la dirección que resolverá la consulta de días disponibles en el servidor.

El envío se hace mediante el método POST y las variables son el mes y el año (month, en formato numérico, y year). El servidor ha de devolver los días disponibles en forma de texto y separados por comas. Por ejemplo, con php podría devolver la cadena 12,13,14,17,21,28,29 mediante un simple echo.

Ya he retocado el artículo original dedicado al calendario para detallar (otra vez) esta funcionalidad e incluir un ejemplo.

Si alguno de vosotros piensa que es mejorable, que lo diga. Yo por mi parte haré lo que pueda (teniendo en cuenta que estoy de vacaciones).

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

Tras observar la posible versatilidad de otros calendarios que se cargan con javascript, me he decidido a implementar un nuevo cambio y retocar/actualizar el artículo original.

El cambio consiste en la posibilidad de utilizar el calendario para cargar cada uno de los datos de la fecha en un campo de texto independiente. Asímismo, he decidido eliminar ciertos estilos que se aplicaban desde el propio script para que todo lo referente a la presentación sea una tarea de CSS.

Espero vuestro feed-back.

El nuevo script tiene una pequeña modificación tal que si en cualquier momento se introducen nuevos campos de texto bastará con llamar posteriormente a la función cargaLinks() para que todo funcione como se desea.

Se puede acceder al artículo completo del calendario (con la revisión incluida) desde acc_calendar v1.1 o desde el enlace permanente del área de Recursos de la página principal.

nota: Lo que no podemos olvidar es que para que los nuevos input asocien el enlace para la apertura del calendario tendrán que poseer las clases ya indicadas en el anterior artículo.

Objetivos

En principio he establecido dos objetivos principales, que más que objetivos han sido pautas de trabajo a la hora de construirlo:

• Que sea accesible y no intrusivo. Evidentemente, en ausencia de soporte para javascript no se ofrece la opción de desplegar el calendario, pero, si hay soporte… ¿por qué no hacer que el contenido generado sea accesible y utilizable?
• Que sea fácil de implementar y utilizar. He buscado una forma tal los programadores que deseen implementarlo en sus páginas web no requieran de introducir código adicional. Al igual que en CSS se utilizan diversos tipos de selectores (de elementos, id, clases,…) para asociar estilos a las diferentes partes de nuestros documentos, ¿por qué no utilizar lo mismo para asociar comportamientos?

Además, como objetivos secundarios están: optimizar, generalizar, internacionalizar,… (siendo realista, tuve que eliminar los objetivos de ligar y el de ganar dinero.)

El ejemplo

Para comprobar su funcionamiento, podéis acceder a un ejemplo y descargarlo.

Incluyéndolo en nuestros documentos

La inclusión del calendario en nuestro documento es tan sencillo como incluir el elemento script correspondiente en el head:

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

El calendario se cargará para cualquier campo de texto que lleve incluida la clase “fecha“. El formato de la fecha se introduce en la primera línea del script. Así, si por ejemplo se desea que la fecha siga el orden día/mes/año, no incluyendo un 0 delante del día cuando esté formada por un dígito, e incluyéndolo en el mes cuando sea necesario:

var formato = 'd/mm/y';

Para conseguir mostrar el calendario junto a un campo de texto, este deberá llevar la clase “fecha”. Además, todos los posibles parámetros se introducen como clases. La lista completa es la siguiente:

• Cargar calendario (requerido): fecha
• Fechas previas a hoy: prev
• Fechas posteriores a hoy: post
• Rango de años: rangX (siendo X el número de años)
• No se incluye el día actual: todnact

Ventajas

Entre las ventajas que se le pueden atribuir tenemos:

• Fácil de usar e implementar.
• No es intrusivo.
• El código y el contenido que se genera es accesible (marcado, organización, contenido,…) y es utilizable mediante el uso de ayudas técnicas (lector de pantalla,…). En este punto se ha tenido en cuenta en qué lugar recae el foco tanto al mostrarse como durante el funcionamiento y al desaparecer. Así, cuando se muestra, el foco recae directamente sobre el selector de años, siguiendo un orden lógico al tabular desde él, y cuando se cierra el calendario (mediante el enlace de cierre o tras haber seleccionado una fecha) el foco recae sobre el campo de texto al que se le había asociado.
• Se facilita la navegación por el mismo independientemente del dispositivo. Se puede navegar utilizando cualquiera de los dispositivos con los que podamos navegar por la web.
• Sus parámetros son fácilmente configurables y su llamada muy simple (mediante el uso de nombres de clase).
• El idioma lo toma directamente del documento padre, pudiendo añadir traducciones nuevas al código. En el caso de no estar declarado el idimoa en el documento (cosa que no debe ocurrir), el español será el que se utilice por defecto. Actualmente, además del español incluye el inglés. Adicionalmente se ha hecho que reconozca si es inglés americano, no porque vaya a cambiar el contenido, sino para cambiar la disposición de los días de la semana (el domingo se coloca primero).
• Los estilos aplicados al calendario se incluyen mediante una CSS enlazada por medio del script, con lo que en ausencia de soporte para este, se optimiza la descarga del documento al no llamarse a dicha hoja de estilos.
• Se han incluido clases de tal manera que se puedan aplicar estilos sobre cualquiera de las celdas de la tabla (días activos, días no activos, día actual), así como estilos específicos para los sábados o domingos.

Código generado

A continuación incluyo parte del código generado por el script. Como se puede observar (y como ya he dicho) se incluyen nombres de clase e id para poder controlar la maquetación mediante la hoja de estilos.

<a title="Desplegar el calendario para seleccionar una fecha" href="#" class="enl_cal">
	<img alt="" src="acc_calendar/acc_calendar.gif" />
</a>
<div id="calendar">
	<label id="label_year" for="nav_year_select">Año
		<select id="nav_year_select">
			...
			<option>1987</option>
			<option selected="selected">1988</option>
			...
		</select>
	</label>
	<label id="label_Meses" for="nav_mes_select">Mes
		<select id="nav_mes_select">
			<option selected="selected">Enero</option>
			<option>Febrero</option>
			<option>Marzo</option>
			...
		</select>
	</label>
	<table summary="Calendario con los días disponibles de Enero de 2007" id="calendario">
		<caption id="caption">Enero 2007</caption>
		<colgroup span="5"></colgroup>
		<colgroup span="2"></colgroup>
		<thead>
			<tr>
				<th scope="col"><abbr title="Lunes">Lun</abbr></th>
				<th scope="col"><abbr title="Martes">Mar</abbr></th>
				...
			</tr>
		</thead>
		<tbody id="tbody">
			<tr>
				<td class="act">
					<a title="Seleccione esta fecha" href="#">1</a>
				</td>
				<td class="act">
					<a title="Seleccione esta fecha" href="#">2</a>
				</td>
				...
			</tr>
			<tr>
				...
				<td class="inact">24</td>
				<td class="inact">25</td>
				...
			</tr>
		</tbody>
	</table>
	<ul id="nav_mes">
		<li>
			<a href="#">Diciembre</a>
		</li>
		<li class="post">
			<a href="#">Febrero</a>
		</li>
	</ul>
	<ul id="nav_year">
		<li>
			<a href="#" title="Ir al año">2004</a>
		</li>
		<li class="post">
			<a href="#" title="Ir al año">2006</a>
		</li>
	</ul>
	<div id="close_it">
		<a href="#">Cerrar calendario</a>
	</div>
</div>

Conclusión

A modo de cierre… ¿qué se podría decir de este calendario?… pues que “es innecesario… pero útil” y que “no tiene implicaciones negativas en términos de accesibilidad“.

…por cierto ¿qué día es hoy?

A las funcionalidades que introducían los anteriores scripts le he añadido la capacidad de reconocer la agrupación de campos mediante el elemento fieldset, y todo con la finalidad de mejorar la experiencia de usuario y la accesibilidad. Este elemento tiene como finalidad el agrupar campos en base al tipo de datos a introducir (ej. datos personales, datos bancarios, datos académicos, etc), mejorando la estructura y la accesibilidad del conjunto. Al fieldset se le añade el elemento legend que funciona a modo de encabezado de los datos agrupados.

…y ¿para qué?

La idea me surgió tras ver horrorizado un inmenso formulario con multitud de campos obligatorios (y no voy a decir donde…). Cuando no se rellenan estos, la lista con los errores se vuelve larguíííííííííísima, con lo que resulta muy incomodo de leer, difícil de comprender e incluso estéticamente horrible.

Si los campos de formulario van agrupados para facilitar su comprensión, ¿por qué no agrupar los errores siguiendo el mismo patrón?

Para el funcionamiento del script no hace falta la agrupación, pero bueno… siempre es positivo tenerla presente y utilizarla.

La prueba

Como siempre, podéis acceder al ejemplo de uso o incluso descargarlo directamente.

Como se puede observar, los errores siguen mostrándose mediante una lista. No obstante, en este caso se crea una lista anidada para tratar de agruparlos y conseguir esa mejora en estructura antes mencionada.

…y todo esto se relaciona con

• Retocando Formularios, Episodio III (”El Retorno”)
• Retocando Formularios (Episodio II)
• Retocando Formularios (episodio I)

Importante: Quiero recordar que el uso de javascript no debe tener implicaciones negativas en la accesibilidad. Bien utilizado, y con todas las consideraciones hacia el usuario, mejora su experiencia.