llámanos ahora
Barcelona: 931 88 05 70
Madrid: 910 05 21 75
Español | English

Un paseo por Wai-Aria

por

Post publicado en Usabilidad y Accesibilidad

Tiempo atrás, hacer un sitio web usable era sinónimo de simplificación. La eliminación de cualquier floritura que no tuviera la estricta semántica dictada por el estándar HTML del momento.

¿Cómo iba algún usuario de software de asistencia ser capaz de navegar por nuestra web sin ver correctamente, sin leer correctamente un lugar cargado de metáforas visuales y contenidos de carga asíncrona?

Pongamos un ejemplo: ¿a quién le gustaban esas casillas de verificación, sosas, aburridas, cuyo diseño se había mantenido casi inalterado desde el mismo inicio de las interfaces gráficas?
Eso no podía permitirse, había que hacer algo, como bien sabía el diseñador de turno, cuando incluía esos diseños imposibles. Nada de  sino más bien 

Botones con menús desplegables, selectores de rango, y un largo etcétera.
A partir de ese momento nuestra web dejaba de tener significado. En lugar de tener un control que el sistema entiende como una casilla de verificación o un selector de opción, por ejemplo, se acababa con un surtido de div anidados o peor, una imagen. La accesibilidad se había esfumado y había que hacer algo.

Y así surgió la especificación técnica del W3C, WAI-ARIA Web Accessibility Initiative – Accessible Rich Internet Applications, o lo que es lo mismo, Iniciativa de accesibilidad web – Aplicaciones de internet enriquecidas y accesibles. WAI-ARIA 1.0 se completó en marzo de 2014.

El propósito de ARIA es claro: dotar de significado explícito a un contenido que no lo tiene. En detalle:

- Establecer el rol de un elemento
- Establecer la relación entre elementos
- Informar del estado de un elemento
- Hacer accesibles los controles a través del teclado

Veamos a continuación algunas aplicaciones prácticas.

Cómo hacer un formulario accesible

Volviendo al ejemplo anterior de las casillas de verificación de diseño, vamos a ver cómo añadir la usabilidad que se pierde al abandonar el estándar.

Así sería una casilla en HTML básico:

<label> <input type=”checkbox” checked> Casilla </label>

Y así podría ser nuestro control personalizado

<div class=”checkbox-control”>
	<span class=”checkbox-image”></span>
	<span>Casilla</span>
</div>

Ahora reescribamos nuestro control para que, manteniendo el diseño deseado, siga manteniendo la semántica perdida del estándar inicial:

<div class=”checkbox-control”>
	<span class=”checkbox-image” tabindex=”0” role=”checkbox” aria-checked=”true”></span>
	<span>Casilla</span>
</div>

Con el atributo tabindex, indicamos cómo acceder al control con el teclado. En este caso, al ser 0, será el primer elemento seleccionable mendiante el teclado. Con role=”checkbox” indicamos claramente que la función del elemento es hacer las veces de casilla de verificación. Por último, con aria-checked=”true” indicamos que la casilla está inicialmente seleccionada.

Pongamos otro ejemplo.

A veces, por cuestiones estéticas, mostramos un campo de introducción de texto, seguido de un texto explicativo, por ejemplo:

<input type=”text” name=”search[title]” title=”Buscador” />
<div class=”text”>

Este buscador busca solamente en los titulares. Para una búsqueda más exacta, utiliza el

<a href=”...”>buscador avanzado</a>
</div>

Esto presenta un claro fallo de accesibilidad, pues un lector de pantallas informaría del buscador antes que del texto, produciendo quizás unos resultados negativos. Para evitarlo, recurrimos otra vez a ARIA, añadiendo una relación entre los dos elementos de la siguiente forma:

<input type=”text” name=”search[title]” title=”Buscador” aria-describedby= “search_info” />
<div class=”text” id=”search_info”>

Este buscador busca solamente en los titulares. Para una búsqueda más exacta, utiliza el

<a href=”...”>buscador avanzado</a>
</div>

De esta forma informamos correctamente del propósito de un control y él mismo, independientemente de la ubicación de los dos.

Otros ejemplos

ARIA no se limita a formularios, sino que su aplicación es muy extensa, cubriendo cualquier información que podamos representar en HTML. Por ejemplo, un típico menú de navegación, con submenús anidados:

<ul role=”menubar”>
	<li role=”menuitem” aria-haspopup=”true”>
		item 1
		<ul role=”menu” aria-hidden=”true”>
			<li role=”menuitem”>subitem 1-1</li>
			<li role=”menuitem”>subitem 1-2</li>
		</ul>
	</li>
	<li role=”menuitem”>item 2</li>
</ul>

El marcado adicional en ningún momento sustituye al CSS, que debe añadirse normalmente, simplemente indica su función independientemente de su diseño. Es decir, añadir el atributo aria-hidden=”true” no esconde el elemento, sino que indica que éste está ya oculto. Como vemos, es bastante sencillo de interpretar.

Otro caso práctico sería la típica “x” para cerrar un diálogo u ocultar un contenido concreto:

<button aria-label=”cerrar” onclick=”…”>x</button>

De esta manera asignamos el nombre “cerrar” al botón, dotándolo de un significado mucho mayor.

En definitiva, es mucha la información que podemos añadir con estos atributos en aras de aumentar la accesibilidad, y, en definitiva, tener un producto mejor que llegue a más visitantes.
Para una referencia completa, puedes consultar la página oficial y comenzar desde hoy a usar WAI-ARIA

¿Te ha gustado el post?
Compártelo en tu red social.

Leave a Reply

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

comparte este post
Un paseo por Wai-Aria