Usable y accesible

Noticias... (19)

2009-06-11T00:00:00.003+02:00

Estas son las noticias que han llamado últimamente mi atención:

[01-06-09] "JCCM.ES, un nuevo portal en Internet a la altura de la Ley de Acceso Electrónico" en computing.es

La Junta de Comunidades de Castilla-La Mancha ha lanzado su nuevo portal con la plataforma FatWire Content Server 7.5. La noticia dice que "cuenta con la certificación de accesibilidad AA". En realidad no tiene una certificación sino simplemente el sello "AA" del W3C. Si bien es cierto que ha mejorado mucho su accesibilidad y que muchas páginas pasan el TAW, la realidad es que no cumple con las WCAG 1.0 en su nivel de adecuación AA. Deberían seguir trabajando en ello...

[08-06-09] "La primera experiencia española de Open Government" en seraccesible

Aragón Participa es la primera web española nacida con la mentalidad Open Government, construida íntegramente con Software Libre, pretende ser un canal de participación de los ciudadanos en las políticas públicas del Gobierno de Aragón.

El portal incorpora, como novedad tecnológica, un asistente virtual al que los cuidadanos se puede dirigir para hacer llegar sus preguntas o reflexiones.

[04-06-09] "Estándar del PDF accesible - Standard for accessible PDF" en La hoguera de las brujas

Por fin se ha aprovado PDF/UA (Universal Accesibility) como ISO/AWI (approved work item) 14289. Es el primer paso hacia un estándar abierto de PDF accesible. Aunque todavía no es público, el desarrollo se puede consultar en PDF edtime

[22-05-09] "Google Chrome 2.0, 30% más rápido" en anieto2k

Hoy se ha publicado una nueva versión de Google Chrome, la 2.0 estable, que se está presentando a la red como una versión 30% más rápida que su versión anterior. Hay que decir que ese incremento de velocidad es en el motor javascript llamado V8. Lo que hace que este incremento en páginas muy cargadas de Javascript sea muy significativo.

Artículo relacionado: Chrome (IV): accesibilidad

[09-06-09] "Safari 4 ya está aquí" de Programar a ciegas

En cuanto a su accesibilidad indicar que en MacOS X resulta más accesible incluso que la versión 3 aunque siguen apareciendo algunos problemas al encontrar webs que no cumplen las pautas de accesibilidad para la Web.

VoiceOver accede mejor a la barra de pestañas y a la zona de favoritos. Ahora resulta más cómodo navegar entre la lista de favoritos y elegir entre las distintas pestañas abiertas.

Sigue sin poder acceder a la capa de accesibilidad de los objetos Flash aunque ahora si notifica que hay un objeto incrustado dentro.

Lo más importante es que Safari implementa HTML5 y WAI ARIA y voiceOver es compatible con las páginas que incorporen estas tecnologías.

Con Safari 4 el acceso a la nueva Web resultará posible para aquellos que utilicen ordenadores con el sistema operativo de Apple. La versión para Ms Windows de Safari resulta incompatible con los lectores de pantallas más conocidos, como NVDA, JAWS y Window eyes.

[08-06-09] "Safari 4 [NO] más rápido que Google Chrome en el V8 Benchmark Suite" de anieto2k

... podemos decir con el 100% del convencimiento que Google Chrome es hoy por hoy, el navegador más rápido (ejecutando javascript) del lejano oeste.

AJAX accesible IV: Técnicas ARIA de las WCAG 2.0

2009-03-27T21:55:00.019+01:00

Artículos relacionados
[26-05-07] AJAX accesible I
[07-09-07] AJAX accesible II: WAI-ARIA
[22-10-07] AJAX accesible III: HIJAX
[12-02-08] WCAG 2.0
[5-05-09] Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad

Las WCAG 2.0 (Web Content Accessibility Guidelines 2.0) incluyen cuatro técnicas (Techniques for WCAG 2.0: Techniques and Failures for Web Content Accessibility Guidelines 2.0) específicas relacionadas con WAI- ARIA.

Estas técnicas son de momento "advisory technique", pero serán "sufficient technique" en cuanto la especificación alcance el estado de recomendación, tal y como se advierte en las mismas.

ARIA1: Using Accessible Rich Internet Application describedby property to provide a descriptive, programmatically determined label

The purpose of this technique is to demonstrate how to use the Accessible Rich Internet Application (ARIA) descibedby property to provide descriptive information about a user interface control that can be programmatically determined by user agents.

ARIA techniques provide the ability to add programmatically determined information to an element which can provide additional information about the element. The user agent can provide this additional information to assistive technology for presentation to the user.

Ejemplo:


<p>The link in the next paragraph has been updated with the Accessible Rich Internet Applications describedby property to provide more information about the link</p>

<p><span id="icebergInfo">Alaskan storm cracks iceberg in Antarctica. </span>

A bad storm in Alaska last October generated an ocean swell that broke apart a giant iceberg near Antarctica six days later, U.S. researchers reported on Monday.

<a href="http://www.sciencemag.com/iceberg.html" id="iceberg" waistate:describedby="icebergInfo">More Info...</a>.
</p>

ARIA2: Identifying required fields with the "required" property

The objective of this technique is to indicate that the completion of a user input field is mandatory in a programmatically determinable way. The WAI-ARIA required state indicates that user input is required before submission. The "required" state can have values of "true" or "false". For example, if a user must fill in an address field, then "required" is set to true.

Note: The fact that the element is required is often visually presented (such as a sign or symbol after the control). Using the "required" property makes it much easier for user agents to pass on this important information to the user in a user agent-specific manner.

Ejemplo:


<label for="test">Test (required)</label>
<input name="test" id="test" aaa:required="true" />

ARIA3: Identifying valid range information with the "valuemin" and "valuemax" properties

The objective of this technique is to provide information about the allowable range of an entry field in a programmatically determinable way. The WAI-ARIA valuemin and valuemax states provide the minimum and maximum (respectively) values that may be provided by the user. User agents will not permit users to enter values outside that range, or will generate a validation error if users do so.

Ejemplo:


<form action="http://example.com/submit">
  
<p><label for="test">Enter a date in 2007:</label>
<input name="test" id="test" aaa:valuemin="2007-01-01" aaa:valuemax="2007-12-31" aaa:datatype="xsd:date" />
</p>

<p><input type="submit" value="Submit" /></p>

</form>

ARIA4: Using Accessible Rich Internet Applications to programmatically identify form fields as required

La manera de implementar la técnica ARIA2 de forma dinámica se ejemplifica así:

Ejemplo:


<head>
 <script type="text/javascript">
 //<![CDATA[
 
 // array or ids on the required fields on this page
 var requiredIds = new Array( "firstName", "lastName");
 
// function that is run after the page has loaded 
to set the required role on each of the 
 //elements in requiredIds array of id values
 function setRequired(){
  if (requiredIds){
   var field;
   for (var i = 0; i< requiredIds.length; i++){
    field = document.getElementById(requiredIds[i]);
    setAttrNS(field, "required", "true");
   }
  }
 }
 
 // method to set the attribute values based on the capability 
of the browser.  
 // Use setAttributeNS if it is available,
 // otherwise append a namespace indicator string to the 
attribute and set its value.
 function setAttrNS(elemObj, theAttr, theValue){
  if (typeof document.documentElement.setAttributeNS
      != 'undefined') {
   elemObj.setAttributeNS
   ("http://www.w3.org/2005/07/aaa", theAttr, theValue);
  }else{
   elemObj.setAttribute("aaa:" + theAttr, theValue);
  }
 }
 window.onload=setRequired;
//]]>
 </script>
 </head>
 <body>
 <p>Please enter the following data.  
 Required fields have been programmatically identified 
 as required and  marked with an asterisk (*) following 
 the field label.</p>
 <form action="submit.php">
 <p>
 <label for="firstName">First Name *: </label>
 <input type="text" name="firstName" 
    id="firstName" value="" />
 <label for="lastName">Last Name *: </label>
 <input type="text" name="lastName"
    id="lastName"  value="" />
 </p>
 </form>
 </body>

AJAX Accesible (II): WAI-ARIA

2007-09-07T13:07:00.017+02:00

Artículos relacionados
[26-05-07] AJAX accesible I
[22-10-07] AJAX accesible III: HIJAX
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0

Nota 2012: cuando en el artículo se ponen ejemplos como x2:role="role:checkbox" aaa:checked="true" actualmente se marcan como role=”checkbox” aria-checked="true". Sobre la simplificación actual en la especificación de roles y atributos: Knowing when to break the rules

Por otra parte, en el artículo HTML5 y accesibilidad hablo sobre el soporte de Aria Roles por los diferentes lectores de pantalla y sobre cómo usarlos con las nuevas etiquetas semánticas de HTML5.

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).
WAI-ARIA Roles (en español se ha traducido "roles" por "funciones"): Roles for Accessible Rich Internet Applications (WAI-ARIA Roles).
WAI- States (estados y propiedades): States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties).

[nota 2009: se han actualizado estos documentos]

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

NOTA 2009: Soporte para WAI-ARIA en Internet Explorer 8, "Internet Explorer 8 emplea información de rol, estado y propiedades a través de ARIA para communicar con las ayudas técnicas."

NOTA 2009:

[09-06-09] "Safari 4 ya está aquí" de Programar a ciegas
Lo más importante es que Safari implementa HTML5 y WAI ARIA y voiceOver es compatible con las páginas que incorporen estas tecnologías.

Con Safari 4 el acceso a la nueva Web resultará posible para aquellos que utilicen ordenadores con el sistema operativo de Apple. La versión para Ms Windows de Safari resulta incompatible con los lectores de pantallas más conocidos, como NVDA, JAWS y Window eyes.

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

Ejemplos

Simple AJAX Application

Utilidades

La extensión de accesibilidad de JuicyStudio soporta ARIA, por lo que será de ayuda a la hora de avaluar las webs que se vayan aplicando la especificación.

Generales

Accessible Rich Internet Applications (WAI-ARIA) Suite Overview en WAI
WAI-ARIA Best Practices
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
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)
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

Artículos

"Introduction to WAI ARIA", de Dev.Opera
Introducción a WAI-ARIA (octubre 2008)
WAI-ARIA, una aproximación (febrero 2009)
How Can I Validate (X)HTML + ARIA?, de Paciello Group
Using WAI ARIA Landmark Roles, de Paciello Group
Accessible Web 2.0 Applications with WAI-ARIA de Martin Kliehm (9 de abril de 2007)
Redesigning with HTML 5 and WAI-ARIA
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)

Artículos relacionados
[26-05-07] AJAX accesible I
[22-10-07] AJAX accesible III: HIJAX
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0