Usar textos alternativos lógicos y coherentes

• Si la imagen contiene texto, por ejemplo un número de teléfono, debemos transmitirlo completamente, alt="Teléfono: 000 000 000".
• Si la imagen es un icono de error, el texto debe transmitir esa misma idea, podemos usar simplemente alt="error".
• Si se trata de un icono “ZIP”, podemos usar algo como alt="fichero comprimido en ZIP".
• En el caso de una fotografía podemos describir lo que vemos, alt="Asturias, tierra de altas montañas".
• Si la imagen transmite acción, por ejemplo un enlace que tenga un icono de una impresora, debemos indicar dicha acción y no la descripción del icono, alt="imprimir".
• Si una imagen transmite lo mismo que un texto contiguo, debemos dejar el texto alternativo vació para no caer en redundancias, alt="".

Las votaciones

Supongamos que tenemos el clásico sistema de votaciones con estrellas:

Siguiendo las directrices de WCAG2 lo que podemos hacer es usar el atributo alt de la primera imagen para describir a todo el grupo e indicar la puntuación global. El resto de las imágenes que deberían estar situadas de forma contigua, tienen que tener alt="" vacio y no llevar ningún title, de esta forma son obviadas. Con ello se consigue que las ayudas técnicas (como por ejemplo lectores de pantalla) únicamente “lean” el texto alternativo de la primera imagen donde se da toda la información necesaria al usuario.

Ejemplo

<img src="star1.png" alt="puntuación 4 de 5" />
<img src="star2.png" alt="" />
<img src="star3.png" alt="" />
<img src="star4.png" alt="" />
<img src="star5.png" alt="" />

Los emoticonos

Se tiene que transmitir de forma textual el mismo sentimiento que el representado. Por ejemplo: alt="Feliz".

<img src="http://aurea.es/wp-includes/images/smilies/icon_smile.gif" alt="Feliz" />

Supongamos que en vez de una imagen usamos texto (ASCII). En este caso podemos marcar los emoticonos como abreviaturas (semánticamente podrían ser considerados así) y con el atributo title="sentimiento"
Por ejemplo:

<abbr title="Feliz">:-)</abbr>

La etiqueta caption proporciona información sobre el contenido de la tabla al igual que el atributo <table title="">.

La única diferencia es que title no se muestra en los navegadores de pantalla (a excepción de mostrarse como tooltip o mensaje emergente). Por contra caption aparece como un texto centrado en la parte superior de la tabla.

Resulta innecesario usar ambos puesto que con uno de ellos ya aportamos la información sobre el contenido de la tabla.

SUMMARY

Podemos optar libremente por usar caption o title pero si es necesario (sobre todo por razones de accesibilidad) complementar la información con un resumen a través del atributo <table summary="">

Como resumen se debería de indicar la función informativa de la tabla, de una forma más ampliada que el caso de caption. También se puede indicar de forma muy resumida las relaciones entre las celdas.

TH

La etiqueta th sirve para identificar los grupos de encabezamiento. Las cabeceras que sirven de referencia, tanto si se trata de una disposición en columna como en filas.

SCOPE y HEADERS

Su función consiste en relacionar las celdas de los encabezados con las celdas que contienen los datos.

• El atributo scope podemos usarlo especialmente en tablas sencillas y en los encabezamientos th.
• El atributo headers cumple la misma misión pero de una forma más especifica, por ello es mejor reservarlo para tablas complejas.

Más información detallada de estos atributos en scope y headers en tablas para mejorar la accesibilidad.

En conclusión, con el uso de caption, th, thead, tbody, tfoot, colgroup, col, scope, headers, axis mejoramos sustancialmente la accesibilidad de nuestras tablas.

En la tabla vemos que hay unos campos de formulario para introducir el número de unidades de cada producto y que no tienen un texto que pueda usarse como LABEL. Ante esta situación he pensado que podría asociar explícitamente el INPUT con un LABEL de cada campo en la columna producto (reproductor mp3, impresora, caja 25 dvd).

<tr>
	<th id="pro1">
		<label for="a_uds">
			Reproductor <dfn title="Es un formato de audio digital"><abbr lang="en" xml:lang="en" title="MPEG-1 Audio Layer 3">MP3</abbr></dfn>
		</label>
	</th>
	<td headers="pro1 tpvp">
		40 &euro;
	</td>
	<td headers="pro1 tuds">
		<input type="text" id="a_uds" name="a_uds" value="1" size="4" />
	</td>
</tr>

Vemos que LABEL e INPUT se encuentran asociados por el identificador “a_uds”.

Aunque esta forma de proceder no sea “mala”, quizás la etiqueta textual queda “lejos” del control de formulario, lo que puede provocar cierta confusión a los usuarios de lectores de pantalla.

La solución más directa en estos casos es usar el atributo TITLE de los controles de formulario.

<tr>
	<th id="pro1">
		Reproductor <dfn title="Es un formato de audio digital"><abbr lang="en" xml:lang="en" title="MPEG-1 Audio Layer 3">MP3</abbr></dfn>
	</th>
	<td headers="pro1 tpvp">
		40 &euro;
	</td>
	<td headers="pro1 tuds">
		<input type="text" title="Número de unidades para: Reproductor mp3" name="a_uds" value="1" size="4" />
	</td>
</tr>

Usando title="Número de unidades para: Reproductor mp3" podemos ayudar a que el usuario sepa como actuar con ese control.

Imagen ilustrativa de enlace que recibe el foco

Cuando hacemos clic en un enlace los navegadores te muestran una línea discontinua para indicar el elemento que ha recibido el foco.
Parece una tontería pero fijaros que los navegadores usan inteligentemente contornos dinámicos (propiedad outline de CSS) para no afectar a la maqueta del diseño web.

¿Como evitar el foco?

Esta línea discontinua podemos eliminarla con una simple regla de CSS donde hacemos uso de la pseudo-classe :focus.

	*:focus { outline: none; }

Este ejemplo es el más global, afectando a todos los elementos. Podemos usar algo más concreto y afectar únicamente a nuestro menú de navegación principal. Por ejemplo:

	#menu a:focus { outline: none; }

¿Y el por que no me gusta eliminar el foco?

Resulta evidente… Pero algunas simples razones:

• Accesibilidad, por ejemplo las persona con poca visión pueden así reconocer adecuadamente en que elemento esta operando.
• Usabilidad, no se enfatiza y refuerza el elemento sobre el que se hace clic.
• Otro ejemplo, ¿qué sucede si quieres navegar con el tabulador…?

Desde entonces han mejorado un poquito la accesibilidad, aunque siguen sin usar la etiqueta label para el campo de Email de inicio de sesión. En su lugar han puesto los atributos title y value. El problema es que algunas ayudas asistivas pueden no interpretar el atributo title, por lo que esta solución no sería suficiente.

Respecto a la usabilidad puede ser debatida, pero el hecho de perder (lo que tienes que rellenar en ese campo) cuando haces clic en el, me parece un error. Eso si, visualmente y a nivel de interacción queda chulisimo.

Hoy, Kus (de uninstallme.com) me comenta:

Acabo de encontrar esto http://www.csskarma.com/lab/slidinglabels/ y me he acordado de este post. No lo he analizado a fondo, pero me ha parecido una buena idea.

Y tanto que es buena idea, la accesibilidad es impecable. Se usa JavaScript como un complemento no intrusivo que se encarga de realizar el efecto y la transición del label. Solo le veo una pega, que puede resultar cansino, yo lo usaría para formularios muy pequeños, con 2 o 3 inputs.

Un lujo contar con tus aportaciones María

Recientemente se ha publicado la nueva versión de MOSAIC, una destacada publicación dedicada a las tecnologías y comunicación multimedia, donde tuve la oportunidad de colaborar en el desarrollo (ver ficha del proyecto).

Voy aprovechar este post para compartir como he implementado ARIA en las solapas que aparecen en la home de MOSAIC. De esta forma el contenido de las solapas es más accesible y semántico.

Marcado para un elemento de tipo tabs (solapas)

<div id="tabs">
	<ul>
		<li><a href="#tabs-1" id="tab1">en este número</a></li>
		<li><a href="#tabs-2" id="tab2">lo más leído</a></li>
	</ul>
	<div id="tabs-1" class="tabpanel">
		contenido de la solapa 1 (en este número)
	</div>
	<div id="tabs-2" class="tabpanel">
		contenido de la solapa 2 (lo más leído)
	</div>
</div>

Podemos destacar los siguientes elementos con IDentificadores:

• id="tabs": contenedor general
• id="tab1", id="tab2": cada solapa
• id="tabs-1", id="tabs-2": contenedores de cada solapa

Inyectando ARIA con jQuery en un elemento de tipo tabs

$('#tabs ul').attr('role', 'tablist');
$('#tabs ul li a').attr('role', 'tab');
$('#tabs .tabpanel').attr('role', 'tabpanel');

1. En la primera línea añadimos el landmark tablist a la lista que contiene las solapas.
2. En la segunda línea marcamos cada enlace (solapa) de la lista con el landmark tab.
3. Finalmente en la tercera línea indicamos el contenedor de cada solapa con el landmark tabpanel.

Una de las nuevas características de WordPress es la incorporación de los conocidos landmarks de WAI-ARIA, añadidos a través del atributo role al theme por defecto de WordPress. De esta forma se especifican los roles de las diferentes zonas funcionales del blog haciendo que sea más semántico y accesible.

Los landmarks que WordPress ha incluido en su theme por defecto son: main, contentinfo, banner, complementary y navigation.

Sin duda se trata de una gran apuesta de WordPress volcada a mejorar la accesibilidad de sus blogs.

El problema de la validación XHTML W3C

Esta importante actualización que viene integrada en el theme por defecto de Wrodpress plantea un problema de validación. Las especificaciones HTML 4.01 y las DTD no contemplan aún los landmarks de ARIA y esto hace que nuestro blog no pase positivamente el test de validación W3C.

Para solventar este problema podemos eliminar los atributos role del theme e inyectarlos por medio de JavaScript en tiempo de ejecución.

Inyectando landmarks de ARIA con jQuery

$(document).ready(function() {
	$('#content').attr('role', 'main');	
	$('#footer').attr('role', 'contentinfo');
	$('#header').attr('role', 'banner');
	$('#sidebar').attr('role', 'complementary');
        $('#sidebar ul').attr('role', 'navigation');
	$('#searchform').attr('role', 'search');
});

Sencillamente tomamos los elemento a partir de sus IDs (identificadores) e inyectamos la propiedad role con el valor que representa a cada una de las zonas funcionales role="navigation".
La última línea es un añadido que se encarga de inyectar el landmark del clasico buscador de WordPress.

En el artículo intentaba explicar la forma de crear un control de tipo “Slider” que fuese accesible gracias a la ayuda de las técnicas ARIA.

Hoy he descubierto una herramienta experimental “ARIA Slider Generator” que crea el control en base a unos parámetros dados y a las indicaciones aportadas por The paciello Group en el post ARIA Slider.

Ahora la Fundación CTIC ha desarrollado una nueva versión del analizador de accesibilidad TAW (www.tawdis.net) que permite revisar la accesibilidad de páginas web sobre la nueva normativa WCAG 2.0.

Por cierto, entre tantas versiones (pantalla, e-mail, impresión) cabe recordar eso de “una web única” tan promulgado por la W3C. Bueno, lo que si es cierto es que las ventajas de los estándares web permiten una mejor adaptación al dispositivo o medio final y esto conlleva un ahorro de trabajo enorme.

Vamos al ataque con el CSS optimizado para la impresión.

Media

Evidentemente lo primero que tenemos que hacer es indicar el medio al que van destinadas las hojas de estilo.

<link rel="stylesheet" type="text/css" href="screen.css" media="screen" />
<link rel="stylesheet" type="text/css" href="print.css" media="print" />

Estilo

• Para la impresión viene bien dejar elásticos los contenedores, no fijar tamaños y menos aún bajo unidades en pixeles.
• Evitar el uso de float y position absolute.
• Aplicar bordes a los elementos que lo requieran, por ejemplo contenedores (div) o tablas.
• Eliminar todos los elementos de: navegación, menús, tags, opciones (compartir, enviar por e-mail, saltar al contenido, subir, etc.) Lógicamente todo aquello que no podamos usar en papel. Para esto podemos hacer uso de display: none;
• También podemos ahórranos los comentarios.

Al igual que en otras muchas situaciones menos es más, así que evitar estilos innecesarios todo lo posible.
Y en cuanto al contenido, cuanto menos se imprima mejor!, tengamos presente la naturaleza

Textos

Hace mucho mucho tiempo (en mi época de estudiante) recuerdo haber leído acerca de la legibilidad de fuentes para pantalla o impresión.

• Sans-serif: más legibles en pantalla.
• Serif: más legibles en papel.

Había mucho escrito sobre este asunto, pero me quede especialmente con una cosa; Los trazos acabados en remates ayudan a la legibilidad y son más apreciables en papel, en cambio se produce el efecto inverso en pantalla. Por esta razón los remates de Sans-serif son recomendables para papel y no tan legibles en pantalla (a muy grandes rasgos y teniendo en cuenta el tamaño de letra).

Por cierto, recomiendo el libro “Manual de tipografía, del plomo a la era digital”. Yo tengo la edición 2001 supongo que saldrían nuevas ediciones, es buenísimo!

Imágenes

Una regla que puede servirte es pensar que las imágenes que no aporten información y sean meramente decorativas deben ir como estilo (background-image).

Dos enlaces interesantes al respecto:

• Un test, web sin imágenes, sin CSS, sin JavaScript, plugins, etc.
• Accesibilidad en imágenes

En versiones antiguas de Opera, creo recordar que también imprimía el background-image, en cualquier caso aquello era modificable mediante una opción.
Hoy en día y contemplando la mayoría de navegadores no tendremos problemas.

Enlaces

En papel vemos un enlace de color azul y subrayado, pero desconocemos donde obtener esa información y no podemos ver el recurso al que apunta.

Para evitar esto podemos tomar con ayuda los pseudo-selectores de CSS y hacer que los enlaces sean acompañados de la URL.

a { text-decoration: none; }
	a[href]:after { content: " (" attr(href) ")"; }

Con ello mostraríamos un enlace así: aurea webdesign (http://aurea.es).