AJAX Accesible (II): WAI-ARIA

• Ver artículo AJAX accesible I


• Ver artículo AJAX accesible III: HIJAX

Cuando abordé hace unos meses el tema de AJAX Accesible nombré de pasada WAI-ARIA, sin profundizar más en el tema, puesto que me parecía suficientemente importante para abordarlo en un futuro en otro artículo diferente.

A raíz de un correo en el que se me preguntaba sobre el tema, influenciada por el hecho de que en el último mes he estado dedicada en exclusiva a desarrollos AJAX, y consciente de que hay muy poca documentación o artículos sobre el tema (y menos aún en español), me ha parecido que era un buen momento para escribir algo al respecto. Espero que le sea de utilidad al lector que me preguntaba por este tema y a cualquiera que se dejé caer por aquí. Y ya de paso, me gustaría saber si alguien está aplicándolo en la práctica.

Cuál es el problema

Pongamos un ejemplo. Nos serviría cualquiera en el cual se modificara dinámicamente una página web. Imaginemos el siguiente:

Tenemos un enlace o botón ("Ver última noticia") en nuestra página. Al pulsarlo se escribe una noticia mediante la modificación del innerHTML del div que la contiene.

Me da igual que se utilice o no AJAX, puesto que el problema es el mismo en ambos casos, pero imaginemos que recuperamos el texto de la noticia mediante AJAX.

Es sólo un ejemplo, no entraremos en si es o no usable.

Con un navegador que admita javascript, que lo tenga activo y soporte AJAX, no tendremos ningún problema: el texto de la noticia se escribirá dinámicamente.

Además hemos hecho los deberes (ver AJAX Accesible) y si el usuario trabaja con un user-agent que no admita javascript, no lo tenga activo o no soporte AJAX, no tendrá problemas, puesto que la página se recargará para mostrarle de nuevo la página con la noticia (o cualquier otra alternativa que se decida).

Podríamos pensar que nuestra página ya no presenta problemas pues hemos tenido en cuenta su accesibilidad, hemos proporcionado una alternativa, de modo que todos los usuarios puedan leer la noticia.

Y sin embargo sigue existiendo un problema de accesibilidad, puesto que hay usuarios que no podrán leer esa noticia, ¿quiénes? Haz la prueba. Eres un usuario que tienes por ejemplo Explorer (o cualquier otro navegador que soporte javascript y lo tenga activo). Pero además eres invidente y usas, por ejemplo, JAWS como lector de pantalla. Cuando pulsas "Ver última noticia" esta aparece en la página gracias a AJAX sin ningún problema, pero tú no puedes verla, ¿te lee JAWS el texto de la noticia?

La respuesta es NO.

Cuál es la solución: WAI-ARIA

WAI-ARIA (Accessible Rich Internet Applications) Suite incluye los siguientes documentos:

• La hoja de ruta: Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap). Última versión hasta la fecha del 20 diciembre 2006.


• WAI-ARIA Roles (en español se ha traducido "roles" por "funciones"): Roles for Accessible Rich Internet Applications (WAI-ARIA Roles). Última versión hasta la fecha del 1 junio 2007.


• WAI- States (estados y propiedades): States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties). Última versión hasta la fecha del 1 junio 2007.

En qué consiste la solución

Cuando hable de AT me referiré a cualquier tecnología asistiva (Assistive Technology (AT)): lectores de pantalla, software de dictado o teclados de pantalla.

Tabindex

Lo primero que necesita saber la AT es qué objeto tiene el foco.
Necesitamos que aquellos objetos que vayan a cambiar dinámicamente puedan coger el foco, para ello utilizamos tabindex="-1".

Virtually all adaptive technology solutions, such as screen readers and onscreen keyboards, need to know what object currently has focus. […] HTML 4.01 and XHTML 1.x limit script authors to only being able to provide focus to form and anchor elements yet the Document Object Model Specification allows all elements to receive events including keyboard events. This means that HTML, by design prohibits script authors from making all HTML elements keyboard accessible. This single problem has impacted the usability of Web pages whereas gaining access to all elements means using the tab key on desktop browsers. This slow, unproductive, approach makes it difficult for portal navigation whereas all active elements must be tabbed through to get to an active element in the last portlet in a document. To solve this problem in XHTML 1.x we are incorporating a feature in Firefox and IE to define the tabindex for -1. This allows a script author to give an element focus without placing it in the tab order.

[En Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap)]

An important addition in the States and Properties Module for Accessible Rich Internet Applications is new extensions of tabindex. Now, with the tabindex change, the author is allowed to give any element keyboard focus (and not just form elements or anchors). In this paradigm shift, the user experience should be to use tabbing or keyboard mnemonics to move focus to widgets on the Web page and then use the arrow keys to navigate the object.

[En Roles for Accessible Rich Internet Applications (WAI-ARIA Roles)]

XHTML 2 permitirá ya que todos los elementos de la página reciban el foco, y por tanto ya no será necesario lo que en este apartado se ha dicho.

Roles

Lo segundo que necesita la AT es obtener información sobre la semántica de partes específicas del documento, de aquellas que van a cambiar dinámicamente, o que contienen elementos que lo van a hacer. El div que contiene la noticia no es una etiqueta con significado semántico, y tampoco existe una etiqueta "menú", "pestaña" o "árbol", así que en la etiqueta div añadiremos el rol, la función.

The incorporation of Roles for Accessible Rich Internet Applications is a way for an author to provide proper type semantics on custom widgets (elements with repurposed semantics) to make these widgets accessible, usable and interoperable with assistive technologies.

[En Roles for Accessible Rich Internet Applications (WAI-ARIA Roles)]

Por ejemplo, para definir un menú de tipo árbol, utilizaríamos el rol "tree" y "treeitem":


<div role="wairole:tree" tabindex="-1">

   <div role="wairole:treeitem" tabindex="-1">

     [...]


En este enlace puedes ver un listado de todos los roles.

Estados y propiedades

Lo tercero que necesita saber la AT es el estado y propiedades del objeto. Siguiendo con el ejemplo del menú de tipo árbol, necesitará saber si está plegado o no. Lo indicaríamos de la siguiente manera:


<div role="wairole:treeitem" tabindex="-1" aaa:expanded="true">


"aaa" significa: accessible adaptable applications

En este enlace puedes ver un listado de estados y propiedades.

Sin embargo, no basta con indicar su estado, sino que además, si este cambia, deberá modificarse para que la AT registre el cambio y pueda informar de ello al usuario. Es decir, cada vez que el árbol se pliegue o despliegue deberá cambiar su estado. Este cambio se realiza por javascript de la siguiente manera.

JavaScript can then manipulate the widget via the DOM. However, because States and Properties are mapped to the accessibility platforms, the assistive technology and user agents can understand the widget behavior and respond appropriately.

java script snippet :

   if ((event.type == "keyup" && event.button == 0){

      // Toggle checkbox

      var checkbox = event.target;

      if (checkbox.getAttributeNS("http://www.w3.org/2005/07/aaa", "checked") == "true") {

         checkbox.removeAttributeNS("http://www.w3.org/2005/07/aaa", "checked");

      }

      return false; // Don't continue propagating event

   }

   return true; // Browser can still use event

}




[Ejemplo tomado de: States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties) ]

Así como los estados y propiedades deben modificarse, los roles NO.

Roles are element types and should not change with time or user actions. […] If the old element type is be replaced by a new one, the corresponding element and its subtree should be removed from the document and a new one inserted containing the new role type.

[En Roles for Accessible Rich Internet Applications (WAI-ARIA Roles)]

En resumen:

An application becomes accessible when:

• Each element or widget has full and correct semantics that fully describes it's behavior (using element names or roles).


• The relationships between elements and groups are known


• States, properties, and relationships are valid for each elements behavior and are accessible via the Document Object Model [DOM].


• There is an element having the correct input focus.

Estos son los pasos que WAI-ARIA indica que hay que seguir:

• Step 1: Use your native mark up as well as you can


• Step 2: Find the right roles


• Step 3: Look for groups


• Step 4: Build relationships


• Step 5: Set properties


• Step 6: Associate style sheet selectors with accessibility states and properties

[En Roles for Accessible Rich Internet Applications (WAI-ARIA Roles)]

¿Puedo aplicar WAI-ARIA a cualquier página HTML o XHTML?

At this time, the primary effort in the W3C WAI Protocols and Formats working group is to focus on an extension to XHTML 1.1. It should be noted that XHTML 1.0 could also be enhance to support this extension through the use of a hybrid DTD which incorporates the extensions. The reason for focusing on XHTML 1.X is that XHTML is extensible through the use of namespaces and because it is renderable by today's browses.
[…]
This roadmap is designed to address the accessibility of dynamic, scripted, Web content that may be rendered in today's browser while bridging to future declarative standards, such as XHTML2, in the W3C. The extensions being created for XHTML 1.X are intended to be cross-cutting.

[En Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap)]

Como se ve, en espera del estándar XHTML 2, WAI-ARIA se enfoca a XHTML 1.X. Si te interesa su aplicación a HTML:

There is no normative way to apply roles in HTML, but it is recommended to use the HTML implementation technique.
[...]
HTML documents do not support namespaces, so the required accessibility role and state metadata can not be included directly in these documents. In HTML 4, you can define the accessible role and accessible states as keywords in the class attribute, then use an ECMAScript library to parse the class keywords and copy them into the appropriate role and state namespaces.

[En Embedding Accessibility Role and State Metadata in HTML Documents]

El uso de "namespaces" para incorporar información de roles e información de estados y propiedades en XHTML 1.1 sería así (los ejemplos que incluyo son tomados literalmente de Roles for Accessible Rich Internet Applications (WAI-ARIA Roles):

<?xml version="1.1" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 
    http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"
     xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
     xmlns:waistate="http://www.w3.org/2005/07/aaa">
     
        <body>
        <div role="wairole:menu" waistate:haspopup="true">
                File
        </div>    
    </body>
</html>

El uso de namespaces para incorporar información de roles e información de estados y propiedades en XHTML 1.0 sería así:

<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"
    xmlns:xhtml10="http://www.w3.org/1999/xhtml"
    xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#">

    <body>
        <table id="table1" xhtml10:role="wairole:grid">
        ...
        </table>
    </body>
</html>

For developers using Firefox 1.5, the role attribute was used from the XHTML 2 namespace. Creation of an XHTML role module for XHTML 1.X only occurred recently. For those doing development on Firefox 1.5, the role attribute from XHTML 2 must be used. This being corrected in Firefox 2.0 although Firefox 2.0 will support role in both the old XHTML 2 and 1.1 namespaces. For Firefox 1.5 supporters, this is the
equivalent markup.

Example: Use of namespaces to incorporate role information information into XHTML 1.x for Firefox 1.5

<?xml version="1.1" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 
    http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
    xmlns:x2="http://www.w3.org/2002/06/xhtml2">
    <body>
        <div x2:role="wairole:menu">
            File
        </div>
    </body>
</html>

¿Los navegadores y AT ya soportan WAI-ARIA?

Avelino Herrera comentaba que había hecho pruebas con FireVox (lector de pantalla para Firefox) y que era compatible con WAI-ARIA, siendo capaz de dictar perfectamente todo el contenido que se añadía dinámicamente a la página mediante Javascript.

Yo también lo he comprobado y es cierto. En el último apartado citaré varios ejemplos para que podáis comprobarlo vosotros mismos.

Firefox Accessibility Extension Beta version 1.1 es otra extensión de Firefox que añade una nueva barra de herramientas al navegador. Uno de sus menús se llama "Scripting" y contiene todo lo relacionado con WAI-ARIA como puedes ver en esta imagen:

Por ejemplo, la "List of DHTML Widgets" mostraría el siguiente aspecto

Como ves, se muestra un listado de los roles, su tabindex, si ha cambiado su estado, etc.

A continuación incluyo la lista de implementaciones de WAI-ARIA en navegadores y tecnologías asitivas que se recoge en su Hoja de ruta:

• Firefox 1.5 (including MSAA support)


• GW Micro Window-Eyes 5.5 - with Firefox support


• JAWS 7.0 with Firefox support(partial)


• Windows Magnifier (with IE or Firefox 1.5)


• Internet Explorer from DOM API


• Mozilla Firefox Test samples


• Dojo JavaScript Toolkit


• Mozilla Firefox Accessibility Extensions Test Tool and test suite


• Mozilla Firefox ARIA to Accessibility API mapping


• Bindows Object Oriented Platform for AJAX Development


• WAI Role Taxonomy Extension Tool

Como se ve, el único framework de AJAX que lo implementa en Dojo... algo a tener en cuenta.

Muy interesante también la lista de roles que soporta Firefox en combinación con distintas AT.

Ejemplos

Incluyo a continuación una lista de ejemplos de aplicación de WAI-ARIA para que podáis probar vosostros mismos instalándoos alguna extensión/aplicación del apartado anterior:

• Diversos ejemplos clasificados en simples y complejos.
  Por ejemplo esta "Grid" compleja.



• Cantidad y variedad de ejemplos del iCITA (Illinois Center for Information Technology Accessibility)
  



• Si os interesan ejemplos sobre "AJAX live regions", es recomendable el artículo del 30 de enero de 2007 WAI-ARIA Live Regions de Juicy Studio, que puedes verlo aplicado en los ejemplos de Accessible AJAX.

Enlaces de interés

• Nota de prensa del 26 de septiembre de 2006: El W3C publica una 'Hoja de ruta' para las aplicaciones de Internet enriquecidas accesibles (WAI-ARIA)


• Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap). 20 diciembre 2006


• Roles for Accessible Rich Internet Applications (WAI-ARIA Roles). 1 junio 2007


• States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties). 1 junio 2007


• Accessible Rich Internet Applications (WAI-ARIA) Suite Overview en WAI


• Accessible Web 2.0 Applications with WAI-ARIA de Martin Kliehm (9 de abril de 2007)


• WAI-ARIA: Contenido Web Enriquecido Accesible de Accesibilidad, Usabilidad y Estándares Web (4 junio 2007)


• AJAX Accesible de Olga Carreras (febrero de 2007)


• Accessible AJAX
  
• WAI-ARIA Live Regions de Juicy Studio (30 enero 2007)


• WAI-ARIA: Aplicaciones web AJAX accesibles de Avelino Herrera (27 de abril de 2007)


• XHTML Role Attribute Module del W3C (13 noviembre de 2006)


• XML Events 2 del W3C (16 febrero 2007)


• Firefox Accessibility Extension Beta version 1.1