5 de Octubre

Introducción a WAI-ARIA

Este artículo es para quienes empiezan con ARIA. Es necesario entender el código HTML y las dificultades potenciales que las personas con discapacidad pueden sufrir al usar la web. También es útil estar familiarizado con alguna aplicación RIA desde una perspectiva de usuario.

Tras leer este artículo, entenderás para qué sirve ARIA, cómo integrarla en tus sitios, y cómo la puedes usar desde ya mismo para hacer más accesibles incluso los sitios más sencillos.

Introducción

HTML no fue diseñado originalmente para crear aplicaciones web. Tiene un grupo limitado de controles de interfaz, y está basado en un modelo de comunicación cliente-servidor secuencial. Los desarrolladores de aplicaciones web han sorteado las limitaciones creando sus propios componentes a la medida (widgets), usando Javascript para añadirles comportamiento.

Desafortunadamente, las técnicas usadas para sortear estas limitaciones no han sido accesibles. Aunque los widgets a la medida podrían parecer y comportarse como los widgets de las aplicaciones de escritorio, como los widgets de vista de tipo árbol, el rol (lo que hace el widget), estado (su configuracición, como checked), y otras importantes propiedades no están disponibles para las tecnologías asistivas, como los lectores de pantalla. Esto es similar a aplicar estilo a texto plano para que parezca un encabezado, en lugar de utilizar un elemento de encabezado: el texto plano parece un encabezado, pero no es presentado como tal a la tecnología asistiva.

Las actualizaciones a menudo no son percibidas por las personas que usan tecnologías asistivas. Estas personas normalmente esperan que el contenido web cambie en respuesta a un evento de navegación, como seguir un enlace o enviar un formulario. Las aplicaciones web usan técnicas como AJAX para actualizar el contenido en segundo plano, lo que a menudo no es percibido por la tecnología asistiva. Incluso si esta es consciente de las actualizaciones, el usuario todavía podría no ser consciente de que el contenido ha sido actualizado, o cómo localizar dicho contenido.

WAI-ARIA es una especificación que proporciona un método de describir roles, estados y propiedades para widgets a medida para que estos sean reconocibles y usables por los usuarios de tecnología asisitiva. WAI-ARIA también proporciona un mecanismo para asegurar que los usuarios de tecnología asisitiva sean conscientes de las actualizaciones en la aplicación.

Breve historia de HTML

HTML fue diseñado originalmente como un sistema de hipertexto para estructurar y compartir documentos enlazados. Las primeras versiones de HTML definían etiquetas, tales como encabezados, párrafos, listas o enlaces, para añadir estructura a documentos textuales. La primera propuesta para una especificación HTML, creada por la IETF, también incluía el elemento img para permitir la inclusión de gráficos. La primera especificación formal de HTML fue HTML 2, basada en las primeras versiones de HTML. Esta especificación introducía los formularios y definía un pequeño conjunto de componentes de interfaz para crear cajas de texto, botones, checkboxes, botones de radio y combos. El pequeño grupo de componentes de interfaz definido en HTML 2 ha cambiado mucho comparado con el grupo que usamos actualmente en HTML 4.01.

El modelo de comunicación de HTML está basado en el modelo cliente-servidor. En este modelo el cliente envía peticiones y puede recibir respuestas; el servidor escucha las peticiones, las procesa, y envía respuestas de vuelta al cliente. Como HTML no tenía capa de comportamiento, se pretendió que la comunicación fuera secuencial: el cliente pide una página al servidor, este la procesa, y la envía de vuelta al cliente.

Aplicaciones Web

Las aplicaciones web tratan de emular a las de escritorio excepto en que las aplicaciones web corren sobre una aplicación de escritorio: el navegador. Hay dos diferencias fundamentales entre HTML y su modelo de comunicación, y una aplicación de escritorio:

• Las aplicaciones de escritorio tienen una capa de comportamiento que no depende de peticiones a un servidor.
• Las aplicaciones de escritorio tienen un grupo de componentes de interfaz mucho más rico.

Emulando las aplicaciones de escritorio

Peticiones al servidor en segundo plano

Para emular las aplicaciones de escritorio, las aplicaciones web usan Javascript para añadir comportamiento. Por ejemplo, Javascript puede ser usado para permitir a un elemento de menú expandirse o contraerse cuando el usuario interactúa con él. Ocasionalmente, se pueden requerir datos del servidor. Por ejemplo, la aplicación puede tener que traerse registros de una base de datos del servidor para actualizar información en la página. Cuando la aplicación tiene que interactuar con el servidor, las aplicaciones web usan técnicas como AJAX o iFrames ocultos para comunicarse con él en segundo plano.

Emulando componentes enriquecidos

Como HTML tiene muy pocos componentes de interfaz, las aplicaciones web a veces necesitan crear widgets mas complejos, como checkboxes de tres estados o un control deslizante (slider). El aspecto de estos widgets se crea normalmente con gráficos y añadiendo programación Javascript para hacer que se comporten como el componente nativo.

Figura 1 - Un cuadro de diálogo con un checkbox de tres estados

Figura 2 - Un slider que se podría usar para indicar la calidad de un servicio

Problemas de accesibilidad con la emulación del aspecto

Visualmente, emular componentes enriquecidos y hacer peticiones al servidor en segundo plano crea una experiencia más rica para los usuarios. Desafortunadamente, esto crea problemas de accesibilidad particularmente negativos para los usuarios de tecnologías asistivas, como los usuarios de lectores de pantalla.

• Los widgets creados de esta forma raramente son accesibles mediante el teclado.
• El rol del widget, lo que hace, no está disponible para la tecnología asistiva.
• Los estados y las propiedades del widget no están disponibles para la tecnología asistiva.
• Las actualizaciones no son notificadas a la tecnología asistiva.

WAI-ARIA al rescate

Por fortuna, todos los problemas esbozados anteriormente se resuelven con la especificación Aplicaciones enriquecidas de Internet accesibles de la Iniciativa para la Accesibilidad Web (WAI-ARIA, abreviado como ARIA en el resto de este artículo).

ARIA es una tecnología positiva: en vez de decirle a los desarrolladores lo que no pueden hacer, ARIA les permite crear aplicaciones web enriquecidas. Además, es muy fácil de implementar.

Navegación mediante el teclado

Junto con crear texto alternativo para los elementos no textuales, la capacidad de interactuar con los elementos de la interfaz sólo con el teclado es una de las precauciones más básicas de la accesibilidad web. Los desarrolladores que entienden la accesibilidad pueden construir widgets a la medida usando componentes que pueden recibir el foco, como el elemento input con un atributo type con valor image (input type=”image”). Desafortunadamente, la mayoría de widgets no se construyen con componentes accesibles mediante el teclado, sino que se usan elementos como img, o pueden constar de varios elementos que tienen que englobarse en un elemento contenedor, como un div, que es incapaz de recibir el foco mediante el teclado.

HTML 4 introdujo el atributo tabindex para los elementos a, area, button, input, object, select, y textarea. El atributo tabindex de HTML 4 acepta un valor positivo entre 0 y 32767. La navegación comienza en los elementos con el menor número y avanza hacia el elemento con el número mayor. Los elementos con un valor de 0 son visitados en el orden en el que aparecen en el código. Si el código tiene una estructura lógica, el atributo tabindex no es necesario para los elementos de interfaz que ya están en el orden de tabulación del teclado.

ARIA extiende el atributo tabindex para que pueda ser usado en todos los elementos visibles. ARIA también permite que se especifique un valor negativo para elementos que no deberían aparecer en el orden de tabulación del teclado, pero sí obtener el foco a través de programación (dar el foco a un elemento mediante Javascript). Como el valor actual del número negativo no es importante (el elemento nunca recibe el foco mediante el teclado), el valor -1 es usado normalmente en los elementos que no deben ser incluidos en el orden de tabulación pero podrían necesitar ser capaces de recibir el foco por programación. Por ejemplo, podrías construir un menú en el que el propio menú esté en el orden de tabulación y reciba el foco al tabular sobre él, pero los elementos del menú no estén en el orden de tabulación del teclado. En vez de eso, podrían ser programados para ser navegados usando las flechas. De esta manera, los usuarios no tienen que tabular a través de todos los elementos del menú, con lo que pueden navegar mejor el documento. Esto es válido para todos los widgets que tengan una serie de componentes que necesiten acceso a través del teclado, como un menú de tipo árbol.

Añadiendo un elemento al orden de tabulación natural

El siguiente ejemplo utiliza un valor del atributo tabindex igual a 0 para añadir un div al orden de tabulación para que así alguien que navegue con el teclado pueda acceder al elemento.

<div tabindex="0">
...
</div>

Tabindex negativo

El siguiente ejemplo usa un valor negativo para el atributo tabindex, para que el elemento pueda recibir el foco mediante programación.

<div id="progaccess" tabindex="-1">
...
</div>

En este ejemplo, el div no está situado en el orden de tabulación, pero al tener un atributo tabindex con valor de -1 puede recibir el foco mediante programación. El siguiente trocito de código Javascript selecciona el elemento definido anteriormente y usa el método focus para poner el foco en él.

var objDiv = document.getElementById('progaccess');
// Focus on the element
objDiv.focus();

¿Qué soy?

ARIA introduce el atributo role para ayudar a crear widgets, como un slider, y definir la estructura de la págna, como una sección de navegación. Uno de los principales problemas con las aplicaciones web es que se puede usar cualquier elemento para crear un widget. Los elementos HTML ya tienen roles predefinidos. El rol de un elemento es lo que hace, el papel que juega en la estructura. Por ejemplo, el rol de un encabezado es bien entendido por la tecnología asistiva. Cuando los widgets son construídos con elementos existentes, el rol del elemento es lo que se muestra a la tecnología asistiva, en lugar de lo que representa visualmente en el widget. Por ejemplo, si el tirador de un control deslizante (slider) se crea usando una imagen con un texto alternativo apropiado, un lector de pantalla probablemente anunciará el control como “Gráfico, tirador”, en contraposición a algo más significativo como “Tirador, valor 16 por ciento”.

Figura 3 - El tirador de un típico control deslizante

El rol dado por el atributo role sustituye al rol del elemento nativo. En el siguiente ejemplo, un elemento input tiene un atributo role de slider (echaremos una ojeada a algunas del resto de propiedades de ARIA más tarde en este artículo), por lo que el rol expuesto a la tecnología asistiva es slider, en lugar de input.

<input type="image"
       src="thumb.gif"
       alt="Effectiveness"
       role="slider"
       aria-valuemin="0"
       aria-valuemax="100"
       aria-valuenow="42"
       aria-valuetext="42 percent"
       aria-labelledby="leffective">

Cuando este elemento recibe el foco, un usuario de lector de pantalla entiende el rol que juega este widget. La especificación ARIA mantiene una lista de roles.

Document Landmark Roles (Roles de zonas del documento)

Así como hay roles que ayudan a definir widgets, hay roles que pueden ayudar a definir la estructura del documento. Los Document Landmarks son un subgrupo de roles que ayudan a los usuarios de lectores de pantalla a entender el rol de una sección y a orientarse dentro de un documento.

Figura 4 - Una página típica con un encabezado, barra lateral y área de contenido principal

ARIA define los siguientes roles de zonas del documento.

article

Contenido que tiene sentido en sí mismo, como una entrada completa de un blog, un comentario en un blog, un post en un foro, etc.

banner

Contenido orientado al sitio, como el título de la página y el logo.

complementary

Contenido de apoyo al contenido principal, pero con sentido en sí mismo cuando es separado del contenido principal. Por ejemplo, la información del tiempo en un portal web.

contentinfo

Información sobre el contenido, como notas al pie, copyrights, enlaces a la política de privacidad, enlaces a preferencias, etc.

main

Contenido directamente relacionado o que amplía el contenido principal del documento.

navigation

Contenido que contiene los enlaces para navegar el documento y/o documentos relacionados.

search

Esta sección contiene el formulario de búsqueda del sitio.

El siguiente ejemplo especifica los roles de zonas del documento banner, navigation y main para crear la estructura de página mostrada en la figura 4.

<div role="banner">
...
</div>
<div role="navigation">
...
</div>
<div role="main">
...
</div>

Estados y propiedades de ARIA

Los estados y propiedades de ARIA permiten proporcionar a la tecnología asistiva más información acerca del widget para ayudar al usuario a entender cómo interactuar con él. El estado identifica una única configuración de la información para un objeto. Por ejemplo, la propiedad aria-checked tiene 3 valores de estado: true, false, y mixed.

En el ejemplo anterior del slider, incluimos varias propiedades ARIA, mostradas a continuación, que ayudaban a describir el widget a la tecnología asistiva.

aria-valuemin

almacena el valor más bajo que puede tener un rango.

aria-valuemax

almacena el valor más alto que puede tener un rango.

aria-valuenow

almacena el valor actual en un rango.

aria-valuetext

almacena texto legible para ayudar al usuario a entender el contexto. Por ejemplo, “30 dólares”.

aria-labelledby

almacena el atributo id de un label que contiene un apropiado texto (prompt) para el widget.

Algunas propiedades podrían ser actualizadas por programación. Por ejemplo, las propiedades aria-valuenow y aria-valuetext de nuestro slider serían actualizadas cuando se moviera el tirador.

// Set the ARIA property values when the thumb is
// moved on the slider
objThumb.setAttribute('aria-valuenow', iValue);
objThumb.setAttribute('aria-valuetext', iValue + ' %');

La adición de propiedades y roles de ARIA no validará con HTML 4.01 o XHTML, pero es lo correcto, ya que ARIA está añadiendo información importante a especificaciones que fueron escritas hace mucho tiempo. Se está trabajando en la definición de una DTD que pueda ser usada con XML modular, como XHTML 1.1. Hay una lista completa de estados y propiedades para ayudar a definir widgets accesibles en la especificación ARIA.

Live Regions (Regiones activas)

Las regiones activas permiten a los elementos en el documento anunciar si han sufrido cambios, sin que el usuario pierda el foco de su actividad actual. Esto significa que los usuarios pueden ser informados de actualizaciones sin que pierdan el sitio dentro del contenido. Por ejemplo, un chat podría anunciar la respuesta de la persona con la que se está chateando sin que se pierda el foco de la caja de entrada de texto en la que se añade una línea de chat.

aria-live

La capacidad del contenido actualizado de ser detectado es uno de los mayores obstáculos para los usuarios de lectores de pantalla. ARIA proporciona una propiedad aria-live cuyo valor indica el nivel de verbosidad (el nivel de información transmitida) de la región. Los siguientes son los valores de verbosidad que pueden ser usados con la propiedad aria-live:

off

Este es el valor por defecto, e indica que la región no es activa.
<ul aria-live="off">

polite

Este es el funcionamiento normal y el comportamiento esperado para las regiones activas. Un valor de polite indica que no es necesario responder hasta que el usuario complete su actividad actual.
<ul aria-live="polite">

assertive

Este valor tiene una prioridad mayor de lo normal pero no necesariamente interrumpe al usuario inmediatamente.
<ul aria-live="assertive">

rude

Este valor tiene la prioridad más alta y normalmente hará que el usuario sea interrumpido. Esto les puede desorientar y resultar en que no sean capaces de continuar con su tarea actual, y sólo debería ser usado en escenarios en los que sea absolutamente necesario, como mucho.
<ul aria-live="rude">

Hay algunas otras importantes propiedades que pueden ser usadas al definir regiones activas, resumidas a continuación.

La propiedad aria-atomic

La propiedad aria-atomic es una propiedad opcional de las regiones activas que puede tener los valores true o false (el valor por defecto si no está especificada esta propiedad). Cuando la región es actualizada, la propiedad aria-atomic se usa para indicar si la tecnología asistiva debe presentar al usuario toda la región o parte de ella. Si la propiedad es establecida a true, la tecnología asistiva debe presentar la región al completo; si no, debe ser anunciada la parte de la región que ha cambiado.

En el siguiente ejemplo, todos los elementos dentro de la lista no ordenada serán anunciados por completo cuando la región sea verbalizada, a no ser que otro más profundo en el código sobreescriba la propiedad aria-atomic.

<ul aria-atomic="true"
    aria-live="polite">

La propiedad aria-busy

La propiedad aria-busy es una propiedad opcional de las regiones activas que puede tener los valores true o false (el valor por defecto si no está especificada esta propiedad). Si múltiples partes de una región activa necesitan ser cargadas antes de que los cambios sean anunciados al usuario, la propiedad aria-busy puede ser establecida a true hasta que la parte final sea cargada y entonces establecerla a false cuando las actualizaciones estén completas. Esta propiedad previene de que las tecnologías asistivas anuncien los cambios antes de que estén completados.

<ul aria-atomic="true"
    aria-busy="true"
    aria-live="polite">

La propiedad aria-channel

La propiedad aria-channel es una propiedad opcional de las regiones activas que puede tener los valores main (el valor por defecto si esta propiedad no es especificada) o notify. Los canales se refieren a canales hardware físicos, como sintetizadores de voz o Braille. Si sólo hay disponible un canal hardware, main y notify usan ambos el canal principal. El canal notify tiene una prioridad mayor que el canal main.

<ul aria-atomic="true"
    aria-channel="notify"
    aria-live="polite">

La propiedad aria-relevant

La propiedad aria-relevant es una propiedad opcional de las regiones activas que indica qué cambios son considerados relevantes dentro de una región. La propiedad aria-relevant acepta una lista separada por espacios de los siguientes valores:

additions

los nodos son añadidos al DOM dentro de la región.

removals

los nodos son eliminados del DOM dentro de la región.

text

el texto es añadido o eliminado del DOM.

all

todo lo anterior (adiciones, eliminaciones, texto) aplican a esta región.

Ante la ausencia de una propiedad aria-relevant añadida explícitamente, el comportamiento por defecto es asumir que hay cambios de texto y adiciones (aria-relevant = “text additions”). El siguiente ejemplo sólo anunciaría cambios si se añaden nodos al DOM dentro de la región. Si hay cambios de texto, o se eliminan nodos dentro de la región, el usuario no será notificado.

<ul aria-relevant="additions"
    aria-atomic="true"
    aria-live="polite">

¿Cuándo puede ser usado ARIA?

No hay efectos colaterales negativos por usar ARIA, así que puedes empezar a usarlo desde ya mismo. Los 4 principales navegadores han implementado soporte para ARIA, o tienen planes para implementarlo. Opera 9.5 y Firefox 1.5+ ya incluyen soporte para ARIA. IE8 Beta tiene soporte para ARIA, y Webkit, el framework de aplicaciones de código abierto que está detras de Safari, ha anunciado que ha comenzado a añadir soporte para ARIA.

ARIA también se está volviendo ampliamente soportado por las tecnologías asistivas. JAWS 7.1+, Windows-eyes, NVDA. Zoomtext 9+, y otros, tienen soporte básico para ARIA, y la situación irá mejorando.

Sé uno de los primeros en implementar ARIA

Como no hay efectos colaterales negativos por usar ARIA, y ya hay soporte, no hay nada que perder por implementar ya ARIA, pero mucho que ganar. Incluso si tienes la más sencilla de las webs, puedes incluir roles de zonas del documento para ayudar a los usuarios a navegar mejor, y a orientarse mejor dentro del contenido.

Usa roles de zonas del documento

En mi web personal, he incluido roles de zonas del documento para main, navigation, search y secondary. Considera la siguiente estructura de documento.

<div id="ads">
...
</div>
<div id="nav">
    <form id="searchform" ...>
    ...
    </form>
...
</div>
<div id="content">
...
</div>

Podríamos escribir el atributo role para nuestras zonas del documento directamente en el código.

<div id="ads" role="banner">
...
</div>
<div id="nav" role="navigation">
    <form id="searchform" role="search" ...>
    ...
    </form>
...
</div>
<div id="content" role="main">
...
</div>

De forma alternativa, como la mayoría de páginas están estructuradas para que se les pueda aplicar estilo con CSS, es probable que estén estructuradas con atributos id que podrían ser pasados a una función Javascript. El siguiente es un ejemplo de una sencilla función de Javascript que acepta el atributo id de un elemento, y un valor de role, y asigna éste al atributo role del elemento correspondiente.

function addARIARole(strID, strRole)
{
    // Find the element to add a role property to
    var objElement = document.getElementById(strID);
    if (objElement)
    {
        // Add the role property to the element
        objElement.setAttribute('role', strRole);
    }
}

La función puede entonces ser llamada con el id de la sección y el rol de zona de documento de la sección. Así que considerando la estructura del documento superior, podríamos usar esta función de Javascript para insertar el atributo role, en lugar de escribirlo en el código.

function setupARIA()
{
    // Add ARIA roles to the document
    addARIARole('content', 'main');
    addARIARole('nav', 'navigation');
    addARIARole('searchform', 'search');
    addARIARole('ads', 'banner');
}
window.onload = setupARIA;

Indicar campos obligatorios

Si tienes formularios con campos obligatorios, puedes utilizar la propiedad aria-required. La propiedad aria-required indica que es obligatoria una entrada del usuario en el control antes de que el formulario pueda ser enviado.El siguiente ejemplo añade la propiedad aria-required a un elemento input.

<label for="contactname">Name</label>
<input type="text"
       id="contactname"
       name="contactname"
       size="30"
       aria-required="true">

Wordpress ha empezado a usar el atributo aria-required para los campos obligatorios en la sección de comentarios de las entradas de los blogs.

Añade otras propiedades relevantes

Hay muchas propiedades de ARIA que pueden ser usadas hasta en las webs mas sencillas, como aria-labelledby y aria-describedby. La propiedad aria-labelledby apunta a uno o más elementos considerados el label para un elemento, y la propiedad aria-describedby apunta a uno o más elementos que son considerados la descripción para un elemento.

<h2 id="limg">Paragliding</h2>
<p id="dimg">
A long description of our paragliding trip ...
</p>
<div>
<img src="takeoff.png"
       alt="Getting ready to take off"
       aria-labelledby="limg"
       aria-describedby="dimg">
</div>

Precedencia del código

El código ARIA tiene precedencia sobre el código nativo. Esto significa que si aria-labelledby es usado junto con label for=”", aria-labelledby tendrá precedencia. Todavía se anima a usar el elemento label para los navegadores antiguos que no entienden ARIA. Una sencilla técnica para evitar conflictos consiste en usar el atributo aria-labelledby para referenciar a un label: esto garantiza que el label estará disponible sin importar el soporte de ARIA.

<label id="lblef" for="effectiveness">Effectiveness</label>
<input type="image"
       role="slider"
       id="effectiveness"
       aria-labelledby="lblef"
       ...>

Echa una ojeada a la lista completa de estados y propiedades para ver cómo ARIA te puede ayudar a asegurarte de que tu contenido es más accesible.

Resumen

HTML no fue diseñado originalmente para crear aplicaciones web, pero los desarrolladores las han creado haciendo sus propios widgets a medida, y añadiendo comportamiento con Javascript. El problema es que los roles, estados y propiedades de los widgets y el contenido actualizado en estas páginas no es correctamente transmitido a las tecnologías asistivas. La especificación ARIA resuelve estos problemas al permitir a los desarrolladores describir los widgets en detalle, definir la estructura del documento, y definir zonas de la página que cambiarán.

Ya estés desarrollando verdaderas aplicaciones web con complejos widgets y zonas activas o tengas la más sencilla de las webs, puedes empezar ya a usar ARIA para beneficiar a los usuarios con discapacidades.

Para mas información

• Mejores prácticas de WAI-ARIA
• Uso de aria-required
• Uso de aria-labelledby y aria-describedby
• Uso de aria-invalid y role alert
• Ejemplo de checkbox de tres estados
• Ejemplo de slider ARIA

Comentarios #18

Escribe un comentario

(*) Campos obligatorios

Nombre *

Web

E-mail

Comentario *

Categorías

• accesibilidad (16)
• arte (2)
• diseño (5)
• Diseño de información (8)
• Diseño de interacción (15)
• experiencia de usuario (16)
• front-end (8)
• general (11)
• producto (4)
• Redes sociales (4)
• SEO (4)
• WAI-ARIA (6)
• Web móvil (6)
• Web semántica (4)

Archivo

• Abril 2009 (2)
• Marzo 2009 (1)
• Febrero 2009 (2)
• Enero 2009 (1)
• Diciembre 2008 (3)
• Noviembre 2008 (4)
• Octubre 2008 (4)
• Septiembre 2008 (2)
• Agosto 2008 (1)
• Julio 2008 (1)
• Junio 2008 (3)
• Mayo 2008 (10)
• Abril 2008 (16)

Me gusta...

• Adaptive path
• Grancomo
• Índica
• Information aesthetics
• Juicystudio
• Lady on the Bus
• MakeMeMinimal
• Nitroglicerine
• Outsider
• Putting people first
• Signal vs. Noise
• Small surfaces
• Tentándote
• The Paciello Group Blog
• Visual complexity
• WebAIM