4 de Febrero de 2009

WAI-ARIA, una aproximación

Fernández Rivera, Javier

Resumen: Introducción a ARIA (Accessible Rich Internet Applications), iniciativa del W3C que define cómo hacer accesibles contenidos y aplicaciones web, específicamente el contenido dinámico y los controles avanzados de interfaz desarrollados con Ajax y sus tecnologías relacionadas.

1. Introducción

Contexto

Para comprender ARIA es necesario recordar el contexto donde se desarrolla esta iniciativa: el W3C, cuyo eslogan actual refleja acertadamente el compromiso de esta organización:

Guiar la web hacia su máximo potencial.

Esto incluye una web accesible para las personas, tengan o no cualquier tipo de discapacidad (Fernández Rivera; 2008).

De este modo, nace y se desarrolla en el W3C la Iniciativa de Accesibilidad Web WAI , dentro de la cual podemos ubicar el PFWG, grupo de trabajo de protocolos y formatos, que a su vez son los autores de:

  • Directrices de Accesibilidad para el Contenido Web 2.0 - WCAG 2.0
  • Directrices de Accesibilidad para XML - XAG
  • Aplicaciones de Internet enriquecidas accesibles - ARIA
  • etc.

Definición

El W3C define ARIA como:

La forma para crear contenido Web y aplicaciones Web que sean accesibles para las personas con discapacidades.

Origen

Una de las problemáticas más recientes de accesibilidad en la Web surgió con la llegada de Ajax, momento en el que los desarrolladores se "animaron" a usar esta tecnología motivados por sus posibilidades para la actualización dinámica del contenido y la creación de diferentes controles a medida (widgets). Todo esto con el fin de simular una GUI más parecida a las de las aplicaciones de escritorio, obteniendo como resultado aplicaciones web más ricas e interactivas, pero menos accesibles.

Imaginemos por ejemplo el caso de un control avanzando como el slider. Un lector de pantalla no será capaz de dar respuesta a las siguientes preguntas:

  • Identificar el rol del elemento: ¿qué es?
  • Conocer su estado y propiedades: ¿cómo se encuentra?
  • Capturar su comportamiento: ¿qué hace?

Las soluciones que aporta ARIA

ARIA viene a responder a las anteriores preguntas y otras cuestiones proporcionando un marco de trabajo complementario.

  1. Estructuras más semánticas para las zonas funcionales.
  2. Mejora de la navegación mediante el teclado.
  3. Controles complejos (widgets) más accesibles.
  4. Accesibilidad para el contenido actualizado de forma dinámica.

Para ello ARIA cuenta con:

  • Roles: su misión es definir el papel que juegan los elemento dentro del documento web.
    <div id="slider" role="slider">
  • Estados y propiedades: determinan las características y los valores de cada elementos.
    <div id="slider" role="slider" aria-valuenow="27">

Por tanto, podemos intuir que ARIA no funciona como una tecnología restrictiva o exclusiva, sino que se trata de un complemento con el que podemos hacer accesibles las aplicaciones web enriquecidas.

Problemas

ARIA es soportado por los principales navegadores y tecnologías asistivas, pero sin embargo hay que señalar que en la actualidad los documentos web que contengan ARIA no pueden ser validados, debido a la especificación HTML 4.01 y a los actuales DTD Strict, Transitional y Frameset.

2. Estructura semántica de un documento

Con ARIA podemos especificar los roles de las diferentes zonas funcionales de un documento web, haciendo que sea más semántico y accesible.

Por ejemplo, actualmente estamos acostumbrados a usar un enlace para saltar al contenido principal (skip to content), mientras que ARIA nos permite, a través de los Document Landmarks, crear una estructura más semántica y accesible para que, entre otras cosas, las tecnologías asistivas puedan discernir donde se encuentra el contenido principal sin falta de recurrir a un enlace.

Para crear una estructura semántica accesible con ARIA únicamente tenemos que especificar los roles de cada zona funcional por medio de la propiedad role.

Document Landmarks

Ejemplo para la indicar la zona de navegación

<div id="navigation" role="navigation">
	<ul>
		<li id="active"><a id="current" href="home">Inicio</a></li>
		<li><a href="blog">Blog</a></li>
		<li><a href="contacto">Contacto</a></li>
	</ul>
</div>

Incluso podemos aprovechar el atributo role para personalizar el estilo del elemento mediante CSS.

div[role="navigation"] { color: blue; background-color: inherit; }

Nota: Los selectores de atributos sólo son reconocidos por las versiones actuales de los principales navegadores.

3. Navegación mediante el teclado

Por medio del teclado y a través del atributo tabindex podemos navegar entre los diferentes elementos de una web, pero sólo algunos elementos soportan este atributo y son capaces de recibir el foco: A, AREA, BUTTON, INPUT, OBJECT, SELECT, y TEXTAREA. Por tanto, un simple elemento DIV no puede ser accedido a través del teclado.

Es justo aquí donde hace acto de presencia ARIA:

  1. Haciendo que el atributo tabindex sea soportado por todos los elementos visibles de una web.
  2. Permitiendo el valor “-1″ en el atributo tabindex, lo que posibilita sacar un elemento del orden natural de navegación y del orden expresado por el índice de tabulación. Un elemento con el atributo tabindex="-1" únicamente podrá recibir el foco por medio de JavaScript (con el método focus()).

4. Accesibilidad en los controles (widgets)

HTML fue concebido para compartir documentos en la web y no para crear aplicaciones, razón por la cual no ofrece controles (widgets) avanzados.

Un ejemplo: slider widget (todo un clásico)

slider

El diseño y desarrollo de un control de este tipo puede tener el siguiente aspecto:

<div id="slider-bg" title="level">
	<div id="slider-handler">
		<img src="handler.gif" />
	</div>
</div>
  • Diseño: se hace uso del elemento DIV, una imagen de fondo (con CSS) y otra imagen para el deslizador.
  • Desarrollo: podemos simular el comportamiento usando JavaScript y manejadores de eventos lógicos más o menos accesibles. (Fernández Rivera; 2008b)

El problema de la accesibilidad en el slider

Una persona sin ningún tipo de discapacidad puede mover el deslizador (handler.gif) a lo largo de la imagen de fondo (class=”slider-bg”) y ubicarlo sobre el valor que desee, sin embargo una persona con discapacidad visual tendrá problemas con la accesibilidad de la imagen, no podrá mover el deslizador desde el teclado y, además, su lector de pantalla no será capaz de discernir:

  1. El rol del elemento (¿qué es?). Para el lector será un simple DIV que ni si quiera puede ser accedido por teclado.
  2. El estado y que atributos tiene (¿cómo se encuentra?).
  3. El comportamiento (¿qué hace?). El lector no sabrá que hay tres valores escritos en la imagen de fondo (1. fácil, 2. normal, 3. difícil), que además ha sido implementada con CSS, por el que se sitúa en la capa de presentación (no contenido, no comportamiento).

Slider accesible con ARIA

<p id="slider-description">Puede usar las teclas derecha/izquierda para cambiar el nivel.</p> 
<span id="slider-label">Nivel:</span> 
<div id="slider-rail">
	<button id="slider-handler" role="slider" aria-labelledby="slider-label" aria-describedby="slider-description" aria-valuemin="1" aria-valuemax="3" aria-valuenow="2"></button>
</div>
  • Se incorpora un elemento slider-description con una ayuda descriptiva para que pueda ser comunicada por las tecnologías asistivas.
  • El elemento slider-label contiene la etiqueta del slider.
  • La imagen de fondo que sirve como rail para el deslizador es proporcionada por slider-rail.
  • En vez de usar una imagen se utiliza un elemento BUTTON slider-handler que será el deslizador y el que realmente cumpla la función de slider con todos los atributos ARIA incorporados.

Podemos dar vida a este slider con JavaScript y reflejar los cambios que sufre modificando el valor del atributo aria-valuenow.

5. Accesibilidad en actualizaciones dinámicas de contenido

Otro de los grandes problemas de la accesibilidad en las aplicaciones web enriquecidas, recae sobre la actualización dinámica del contenido (o parte del contenido) que se realiza por medio de Ajax y en “segundo plano”.

ARIA denomina “regiones activas” a los elementos/zonas que pueden presentar estos cambios, y cuenta con la propiedad aria-live con la que indicar el valor de “intrusismo” (off, polite, assertive o rude) sobre la actividad actual del usuario.

Por ejemplo, supongamos que tenemos un elemento TEXT INPUT con un límite máximo de 20 caracteres, asociado a este elemento situamos un SPAN que sirve de contenedor para mostrar al usuario el número restante de caracteres que le quedan por escribir, finalmente con JavaScript podemos ir restando y actualizando el contenido de este elemento, que hace de contador.

<label for="user-name">
	Nombre (requerido)
	<input name="user-name" id="user-name" type="text" size="20" maxlength="20" />
	<span id="count"></span> 
</label>

Un usuario con discapacidad visual no tendrá acceso a la información de ese contador puesto que las tecnologías asistivas no reflejarán la actualización del elemento SPAN.

La solución con ARIA:

<label for="user-name">
	Nombre (requerido)
	<input name="user-name" id="user-name" type="text" size="20" maxlength="20" aria-required="true" />
	<span id="count" aria-live="polite"></span> 
</label>
  • Como se observa únicamente nos basta con especificar la propiedad aria-live="polite" en el elemento SPAN.
  • Por otro lado se ha incluido aria-required="true" para que la ayuda asistiva pueda informar al usuario de que se trata de una entrada de texto que no puede quedar vacía.

6. Implementando ARIA

La dificultad de implementar ARIA puede ser considerada proporcional al grado de complejidad de la aplicación web, aunque al final se trata siempre de gestionar roles, estados y propiedades por medio de JavaScript.

Independientemente de la complejidad se nos plantea otro problema al no poder hacer algo tan esencial como validar los documentos web con ARIA.

El problema viene de HTML 4.01 y las DTD, puesto que no tienen en cuenta las especificaciones de ARIA. No obstante esta tecnología cuenta con un buen soporte por parte de la industria, las principales organizaciones, navegadores y ayudas asistivas. Su implementación tampoco presenta efectos negativos y sí bastantes beneficios en pro de la accesibilidad.

Pero el problema con el validador sigue estando ahí… ¿y qué podemos hacer?. Personalmente me inclino por inyectar los estados y propiedades ARIA por medio de JavaScript en tiempo de ejecución.

Consideremos la siguiente estructura:

<div id="head">
	<h1 id="logo">
		<img src="aurea.gif" alt="title" />
		<span id="tagline">description</span>
	</h1>
	<ul id="nav">
		<li><a href="/">home</a></li>
		<li><a href="/blog">blog</a></li>
		<li id="active"><a id="current" href="/contact">contact</a></li>
	</ul>
	<form id="searchform" method="get">
		<fieldset>
			<legend>Search</legend>
			<label for="s">
				<input type="text" name="s" id="s" value="Search" />
			</label>
			<label for="srhsub">
				<input type="image" name="srhsub" id="srhsub" src="search.gif" value="seek" alt="seek" />
			</label>	
		</fieldset>
	</form>	
</div>
 
<div id="main">
	<h2>title</h2>
	<p>post</p>
</div>
 
<div id="footer">
	<p id="copy">&copy;2009 aurea webdesign</p>
</div>

Inyectando ARIA con jQuery

$(document).ready(function() {
	$('#logo').attr('role', 'banner');
        $('#nav').attr('role', 'navigation');
	$('#searchform').attr('role', 'search');
	$('#main').attr('role', 'content');
	$('#footer').attr('role', 'contentinfo');
	$('.required').attr('aria-required', 'true');	
});

Inyectando ARIA con mootools

window.addEvent('domready', function() {
	$('logo').setProperty('role', 'banner');
	$('nav').setProperty('role', 'navigation');
        $('searchform').setProperty('role', 'search');
	$('main').setProperty('role', 'content');
	$('footer').setProperty('role', 'contentinfo');
	$('.required').setProperty('aria-required', 'true');
});

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 inyecta la propiedad aria-required="true" si un elemento contiene la clase required.

Herramientas que pueden ayudarnos con la implementación de ARIA

  • Firebug para Firefox, con la que podemos observar como se han incorporado los atributos a cada elemento.
    <h1 id="logo" role="banner">
  • Accessibility toolbar para Firefox, con ella podemos verificar el ARIA de nuestro sitio web y un sin fin de parametros relacionados con la accesibilidad.
  • Jaws, lector de pantalla.

7. Bibliografía

Acerca del autor/a:

Javier Fernández Rivera es un desarrollador web especializado en el entorno front-end.

Desde el 2006 trabaja de forma independiente bajo la iniciativa aurea webdesign: Front-end, Estándares web y Accesibilidad.

Blog: http://aurea.es/blog

Citación recomendada:

Fernández Rivera, Javier (2009). WAI-ARIA, una aproximación. En: No Solo Usabilidad, nš 8, 2009. <nosolousabilidad.com>. ISSN 1886-8592

Compártelo:

 
mini-logo nsu
No Solo Usabilidad journal - ISSN 1886-8592. Todos los derechos reservados, 2003-2014
email: info (arroba) nosolousabilidad.com
Powered by Calmly Writer