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

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

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.