4 de Febrero de 2009
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.
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:
El W3C define ARIA como:
La forma para crear contenido Web y aplicaciones Web que sean accesibles para las personas con discapacidades.
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:
ARIA viene a responder a las anteriores preguntas y otras cuestiones proporcionando un marco de trabajo complementario.
Para ello ARIA cuenta con:
<div id="slider" role="slider">
<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.
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.
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
.
<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.
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:
tabindex="-1"
únicamente podrá recibir el foco por medio de JavaScript (con el método focus()
).HTML fue concebido para compartir documentos en la web y no para crear aplicaciones, razón por la cual no ofrece controles (widgets) avanzados.
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>
DIV
, una imagen de fondo (con CSS) y otra imagen para el deslizador.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:
DIV
que ni si quiera puede ser accedido por teclado.<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>
slider-description
con una ayuda descriptiva para que pueda ser comunicada por las tecnologías asistivas.slider-label
contiene la etiqueta del slider.slider-rail
.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
.
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>
aria-live="polite"
en el elemento SPAN
.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.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">©2009 aurea webdesign</p>
</div>
$(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');
});
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
.
<h1 id="logo" role="banner">
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
No Solo Usabilidad - ISSN 1886-8592. Todos los derechos reservados, 2003-2023
email: info (arroba) nosolousabilidad.com