Usable y accesible

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>

Noticias... (16)

2009-03-04T16:23:00.016+01:00

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

WCAG 2.0

Esta semana me sorprendía conocer la web Codexexempla, que dispone de uno de los recursos más codiciados en la actualidad, la traducción (no oficial) de las WCAG 2.0.

Otras traducciones interesantes que ofrece son:
- "Comparativa entre los puntos de comprobación de las Pautas de Accesibilidad de Contenido Web 1.0 y las Pautas 2.0, agrupados por prioridades" de la versión en inglés del 15 de diciembre de 2008.
- "Fe de erratas de las Pautas de Accesibilidad de Contenido Web del WCAG Samurai", [traducción] V1.0 de 26 de febrero de 2008

"¿Qué pasa con las WCAG 2?", se pregunta Olga Revilla, y en consecuencia ha puesto en marcha la web One Guideline a Day en la que pretende ir analizando una por una las pautas, criterios de éxito, técnicas y errores comunes que vienen publicados en la WCAG 2, comparándolo con las anteriores y aportando un poquito de mi experiencia en este campo.

Relacionado: WCAG 2.0 en este blog.

Novedades W3C

Se han actualizado los siguientes borradores:

Authoring Tool Accessibility Guidelines 2.0 W3C Working Draft 17 February 2009.

HTML 5. W3C Working Draft 12 February 2009 y HTML 5 differences from HTML 4 W3C Working Draft 12 February 2009

Accessible Rich Internet Applications (WAI-ARIA) 1.0 W3C Working Draft 24 February 2009

Relacionados:

HTML 5 en este blog.

Ajax accesible II: WAI-ARIA en este blog.

Dominios .tel

"Llegan los dominios .tel" eWeek Europe

"Llega el dominio .tel" TIC Pymes

Móvil

"Banco Popular integra Iphone 3G en su banca móvil" (leído en Computing.es) como ya lo hizo antes Caixa Penedès (Iphone y accesibilidad en este blog)

"Instant Mobilizer de dot.mobi" el Libro de Apuntes: un servicio que moviliza tu página web, es decir, la transforma automáticamente para que se vea correctamente desde los teléfonos móviles.

Sectores

"Pensando la banca del futuro", Usolab: se ha creado el Center for Future Banking, un centro donde se "investigará cómo las nuevas tecnologías y los conocimientos sobre el comportamiento humano pueden transformar la experiencia de los clientes y elevar el papel del banco en su vida financiera", es decir, simplificar la vida de la gente y hacer la experiencia con la banca más satisfactoria.

"Las empresas aseguradoras impulsarán la accesibilidad de sus páginas web" en Acceso.com

Prototype 1.6.0.2 CheatSheet

2008-03-06T13:45:00.001+01:00

La última versión de Prototype, la 1.6.0.2, del 25 de Enero de 2008, ya tiene CheatSheet [vía anieto2k].

Esta versión es compatible con:

Mozilla Firefox ≥ 1.5
Microsoft Internet Explorer ≥ 6.0
Apple Safari ≥ 2.0
Opera ≥ 9.25

Para los amantes de las CheatSheet, encuentro también vía anieto2k una recopilación muy interesante: The Developer Cheat Sheet Compilation.

Otra recopilación de CheatSheet es Quick Reference Cards

Eduardo Sanchez publica también hoy otra recopilación: Top 100 Cheat Sheet para web developers.

Me apunto aquí las que más me interesan:

XHTML

JavaScript

Expresiones regulares

ASCII Character Codes Table

Photoshop y Atajos de teclado

HTML 5 Canvas

Imprescindibles... (6)

2008-02-28T09:05:00.000+01:00

Sobre Quirks Mode o modo "chapucero".

[Si no sabes lo que es, lo explicaba en: Plantilla Base XHTML]

Problemas con AJAX y Quirks Mode de anieto2k

Modo quirks vs. modo estándar en Mozilla Developer Center

Internet Explorer 8.0 modo super estándar de anieto2k

Noticias... (9)

2008-02-28T09:00:00.000+01:00

El portal público de la CAM obtiene la certificación Euracert.

La CAM es la segunda entidad financiera en obtener esta certificación. La primera fue Bankinter en marzo del 2007.

ORDEN PRE/446/2008, de 20 de febrero, por la que se determinan las especificaciones y características técnicas de las condiciones y criterios de accesibilidad y no discriminación establecidos en el Real Decreto 366/2007, de 16 de marzo.

XMLHttpRequest Level 2. W3C Working Draft 25 February 2008

Prototype y Explorer 5

2007-10-31T11:21:00.000+01:00

El objeto XMLHTTPRequest, base de lo que es AJAX, existe desde Explorer 5. Esto quiere decir que un desarrollo AJAX funcionará en Explorer 5.

Podríamos pensar que Prototype, una de las librerías más populares y utilizadas en desarrollos AJAX, sería compatible con Explorer 5. No hay documentación que lo afirme o lo niegue, pero parece lo razonable.

Bien, la triste conclusión de hoy es que la implementación de Prototype no es compatible con Explorer 5. La única confirmación a mi conclusión la he encontrado en Listado de librerías Ajax/DHTML. Portabilidad y compatibilidad con los navegadores.

No se acaba el mundo, mis cinco mil usuarios de Explorer 5 serán derivados a la versión accesible, la de toda la vida, con recarga de páginas, pero es una lástima que a pesar de que Ajax funciona en Explorer 5, no se haya tenido en cuenta este navegador en la implementación de Prototype.

¿Alguien me alegra el día y me dice que usa Prototype en Explorer 5 sin problemas?

HIJAX

2007-10-22T14:20:00.001+02:00

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

El otro día me preguntaban qué era Hijax, si era la evolución de AJAX, o algo nuevo, o ¡qué era!, muy preocupado por si se estaba perdiendo algo referente a AJAX. No me voy a extender mucho, ya habló de Hijax Fran Tarifa el otro día en Hijax: ¿Ajax accesible? (aunque no estoy de acuerdo con sus conclusiones)

Hijax es una metodología a seguir a la hora de realizar aplicaciones AJAX, que consiste en aplicar a estos desarrollos la estrategia que se conoce como "mejora progresiva", propia del diseño web, para que dichos desarrollos AJAX sean accesibles.

Jeremy Keith ya hablaba de aplicar la "mejora progresiva" a AJAX en marzo de 2005, antes de que se le ocurriera bautizar a esta metodología como Hijax, en su artículo Progressive enhancement with Ajax.

Parece que esto de Hijax es nuevo, pero Jeremy no se inventó el término ayer, sino el 1 de enero de 2006 a las 7:40, en el artículo Hijax. Supongo que esa Nochevieja fue sonada para sentarse a primera hora a hablar de Hijax [bromilla].

El caso es que últimamente se oye hablar mucho de Hijax, como algo nuevo, lo cual se debe en parte a sus ponencias como "Bulletproof AJAX (Ajax a pruebas de balas)" y en parte a ese curioso boca a boca exponencial (buzz) propio de Internet.

Esto de bautizar a todo con un nombre gancho es muy habitual (AJAX, Web 2.0, etc.) y muy eficaz para estar en boca de todos (o en blog de todos, como tendríamos que decir hoy en día), pero bueno, no está mal si eso ayuda a difundir buenas prácticas. Hay que reconocerle a Jeremy Keith que lleva ya años abogando por hacer las cosas bien, es simplemente que me hace gracia como de repente todo el mundo habla de algo cotidiano y habitual como si fuera muy novedoso por tener un nombre vistoso. Él mismo ironizaba:

I’ve even got a nice shiny buzzword for this technique: Hijax. (Hijax, Jeremy Keith) [1]

Pero dime, ¿en qué consiste eso de Hijax? Pues me temo que te va a decepcionar un poco, porque no es más que aplicar aquello que venimos recomendando una y otra vez: JavaScript no intrusivo a la hora de plantear alternativas accesibles.

El resumen es el siguiente:

1. Haz que la aplicación funcione sin AJAX mediante peticiones normales al servidor que recarguen la página.

2. Ahora añade JavaScript no intrusivo para incluir el código AJAX, de este modo, si el user-agent no admite JavaScript o está desactivado, la aplicación seguirá funcionando correctamente, puesto que el código es invisible y no afecta al funcionamiento de la página.

Según dice Jeremy, la clave es: Plan for Ajax from the start. Implement Ajax at the end.

Nada nuevo, pero si llamarle Hijax ayuda a difundir las buenas prácticas de la programación AJAX, pues nada: viva Hijax! todos a aplicar Hijax! es decir, a seguir haciendo las cosas bien.

[1]

There seems to be an inherent paradox in saying that you need to think about your server-side architecture but you should just be building old-fashioned page by page submissions before hijacking them with Ajax (Hijax, Jeremy Keith)

Hijax, vendría del término "hijack", secuestrar.

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

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

Imprescindibles... (1)

2007-06-26T09:43:00.000+02:00

80+ AJAX-Solutions For Professional Coding

40+ Tooltips Scripts With AJAX, JavaScript & CSS

Al día en AJAX mediante webéame

Ajax Examples in Action

AJAX accesible

2007-05-26T23:24:00.006+02:00

El objetivo de este artículo es reflexionar sobre los retos de accesibilidad que supone un desarrollo con AJAX. Me voy a centrar en la accesibilidad, sin entrar en los problemas de usabilidad que plantea (seguro que a todos os suenan los diez famosos problemas), tema que abordaré otro día.

Entiendo que si sigues leyendo es porque sabes lo que es AJAX como técnica de enriquecimiento de aplicaciones web, si no es así te recomiendo que antes de continuar le eches un vistazo a “AJAX: un nuevo acercamiento a Aplicaciones Web“ con la traducción del famoso artículo “Ajax: A New Approach to Web Applications” de Jesse James Garret.

AJAX no es un fin, es un medio

Mucha gente dará por sentado que si alguien preocupado por temas de usabilidad y accesibilidad hace un artículo sobre AJAX es para concluir: “no uséis AJAX, es el demonio, AJAX no es accesible”.

Nada más lejos de mis intenciones. Me gusta AJAX, he trabajado con AJAX y recomiendo a menudo AJAX. Y aquí entran las matizaciones.

Recomiendo AJAX para problema concretos y siempre con sentido común.
No recomiendo AJAX a toda costa, para todo, sólo porque los demás lo están usando o con el único afán de hacer alarde del dominio de la tecnología de moda. Usar AJAX con cualquier otro objetivo que no sea el de hacer más fácil, satisfactoria y productiva la experiencia del usuario, es simplemente una estupidez, y lo que es peor, un error que se descubre demasiado tarde.

En definitiva: AJAX no es un fin, es un medio para mejorar la experiencia del usuario. Parece evidente, pero un inquietante número de arquitectos y diseñadores software pierden la perspectiva.

AJAX con sentido común

Creo que Alex Bosworth, en su famoso artículo “10 Places You Must Use Ajax” recomienda muy acertadamente para qué usar o no usar AJAX:

Recomienda usar AJAX para:

Form driven interaction.
Deep hierarchical tree navigation.
Rapid user-to-user communication.
Voting, Yes/No boxes, Ratings submissions.
Filtering and involved data manipulation.
Commonly entered text hints/autocompletion.

NO recomienda usar AJAX para:

Simple forms.
Search.
Basic navigation.
Replacing a large amount of text.
Display manipulation.
Useless widgets.

Dicho esto, es cierto que un desarrollo con técnicas AJAX plantea interesantes retos de accesibilidad, y para afrontarlos deberemos partir de dos premisas básicas:

La inmensa mayoría de los problemas tienen solución, unas veces será más fácil que otras, unas veces será más costosa que otras, pero siempre hay una solución. Al fin y al cabo en eso consiste nuestro trabajo ¿no? en encontrar soluciones a los problemas.
Nada es de por si accesible o no accesible, ni una página, ni un script; los que los hacen inaccesibles son siempre los desarrolladores, por falta de conocimientos o por falta de interés.

AJAX y navegadores

AJAX se basa en el uso del objeto XMLHTTPRequest mediante Javascript ejecutado en el navegador para realizar peticiones asíncronas al servidor, y en la manipulación, también por Javascript, del Document Object Model (DOM) para visualizar e interactuar dinámicamente con la información presentada.

Por tanto, aunque AJAX no necesita ningún tipo de plugin para el navegador, requiere que el navegador soporte y tenga activo el Javascript, y que además soporte el objeto XMLHTTPRequest. En Internet Explorer 5 y 6, además, es necesario tener la secuencia de comandos ActiveX activada, ya que, en estas versiones, la implementación de Microsoft (denominada XMLHTTP) es un componente ActiveX (mientras que en versiones más recientes de los navegadores está implementado como un objeto nativo).

En resumen, los navegadores que soportan AJAX, siempre y cuando tengan Javascript activado, y en su caso la secuencia de comandos ActiveX, son:

Microsoft Internet Explorer para Windows versión 5.0 y superiores, y los navegadores basados en él (por ejemplo Maxthon)
Navegadores basados en Gecko como Mozilla, Mozilla Firefox, SeaMonkey, Camino, Flock, Epiphany, Galeon y Netscape versión 7.1 y superiores
Navegadores con el API KHTML versión 3.2 y superiores implementado, incluyendo Konqueror versión 3.2 y superiores, Apple Safari versión 1.2 y superiores.
Opera versión 8.0 y superiores
Dispositivos móviles: Opera Mobile Browser 8.0 basado en Safari y API KHTML, que soporta aplicaciones desarrolladas en AJAX gracias a su motor de Javascript y su seguimiento del DOM. El mes pasado Mozilla lanzaba Minimo Mobile Browser 0.2 compatible con Windows Mobile 5.0, y que soporta Javascript y AJAX.

[Si os interesa el uso de AJAX en entornos móviles, es interesante echar un vistazo a MOJAX (Mobile AJAX Application Frameworks)]

Los navegadores que NO soportan AJAX son:

Opera 7 y anteriores
Microsoft Internet Explorer para Windows versión 4.0 y anteriores
IE para Macintosh, todas las versiones
Dillo
Navegadores basados en texto como Lynx y Links
Navegadores para incapacitados visuales (braille)
Dispositivos móviles: Deepfish de Microsoft, presentado también hace un par de meses no soporta controles ActiveX, AJAX, cookies, ni JavaScript.

AJAX accesible

El punto de verificación 6.3 de las Pautas de Accesibilidad de la WAI dice así:

Asegúrese de que las páginas sigan siendo utilizables cuando se desconecten o no se soporten los scripts, applets u otros objetos programados. Si esto no es posible, proporcione información equivalente en una página alternativa accesible.

Dicho punto es de Prioridad 1, es decir, es necesario para alcanzar un nivel de adecuación Simple A. Por tanto, para asegurar la accesibilidad de nuestra aplicación, se debe ofrecer una alternativa para el contenido mostrado dinámicamente por Javascript.

Si se utiliza un framework para implementar técnicas AJAX, bien sea open source, comercial o propio de nuestra organización, habrá que asegurarse de que éste ofrece una alternativa accesible adecuada para cada componente AJAX y de que tienen en cuenta las incompatibilidades entre navegadores. [1]

Y por supuesto, todos aquellos contenidos que se inserten dinámicamente en la página deben cumplir las normas de accesibilidad de ese elemento, tal y como las cumplen los demás elementos de la página. Y por tanto, si se utiliza un framework, asegurarse de que cumpla este requisito. [2]

Y después de todo lo dicho, llegamos a lo realmente importante, al "meollo" del asunto.

Cuando indico que es necesario ofrecer una alternativa accesible NO me refiero a crear dos aplicaciones diferentes, una con AJAX y otra sin AJAX. La WAI desaconseja explícitamente los sitios alternativos por no ser una solución integradora, eso sin contar con el elevado coste de realizar dos versiones, las dificultades y el coste de su mantenimiento (como leí en el blog de Torres Burriel, Jesús García lo definió muy acertadamente como “casa de dos puertas es difícil de guardar” ).

El objetivo, por lo tanto, es conseguir hacer accesible una única aplicación.

¿Cómo podemos pues ofrecer alternativas accesibles para los desarrollos AJAX sin crear dos aplicaciones diferentes?

Antes de entrar en el tema me gustaría hacer un inciso sobre la etiqueta "noscript", de la que a menudo se echa mano. Por ejemplo, imaginemos un menú dinámico implementado por AJAX, de tal manera que al pulsar en una de las opciones principales del menú, se consulta al servidor su árbol de submenús para pintarse en la página.

Puede pensarse que una buena alternativa accesible sería en la etiqueta "noscript" incluir todo el árbol del menú (o si este es muy extenso, un enlace a un página con todas las opciones de menú). Pero hay que advertir que la etiqueta "noscript" no estará en el estándar XHTML2.0

De todas formas, como voy a explicar ahora, hay una manera más robusta de hacer las cosas.

Para empezar, tu aplicación debe utilizar un patrón MVC (Modelo-Vista-Controlador) que separe los datos de la aplicación, la interfaz de usuario y la lógica de negocio en tres componentes distintos… y si no… vamos “apañaos”.

Por otra parte, es graciosa tanta preocupación por separar el contenido, la presentación y el comportamiento, para luego encontramos las páginas llenas de Javascript. No me refiero a que el código no esté en ficheros JS (faltaría más), sino a tener el código Javascript mezclado con el código HTML, empozoñándolo al estilo de <input onClick=”mifuncion()”>.

Todo el código javascript debe ser no intrusivo, invisible, de tal manera que no afecte su desactivación al funcionamiento de la página, y por supuesto tener cuidado con el tipo de eventos que se manejan (el evento onClick será inservible, por ejemplo, a un usuario que no disponga de ratón).

[Si lo de javascript “no intrusivo” te suena a chino, ya te estás yendo a Unobtrusive Javascript y a Behaviour].

Bien, tenemos pues una aplicación como dios manda en la que además, desde la primera petición al servidor de nuestras páginas, éste identifica el User-Agent en una cabecera del protocolo http, pudiendo guardar esta información en una variable. Dicha variable será recuperable en toda la aplicación y servirá a los componentes AJAX de nuestro framework para que decidan cómo deben presentarse (en combinación con la identificación en su código generado de si está activado el Javascript en el navegador).

Cuando hablo de componentes AJAX, en realidad pienso siempre en un framework personal o corporativo de mi organización o de mi cliente. Desconfío de los grandes frameworks de AJAX por varias razones: tienen bugs al estar todavía poco maduros y no siempre hacen todo lo que el cliente/usuario/guía de estilo te exige que hagan. Prefiero un framework personal, al que le puedes echar mano con facilidad, sólo con los componentes que necesitas, a la medida de tus necesidades, y por supuesto basado en prototype. [3]

En este contexto, un componente AJAX sería, por ejemplo, una tabla con ordenamiento de columnas y paginación mediante AJAX, o un menú dinámico que consulte por AJAX las subopciones que ha de desplegar antes de repintarse.

Nuestro componente “tabla” define internamente dos comportamientos en función del User-Agent: cómo pintarse para el caso de que sí admita javascript y en el de que no lo admita.

Por otro lado, hay que decir que la variante accesible dependerá mucho del tipo de componente; por ejemplo:

Si se trata de un autocompletar en una caja de texto, puede decidirse que no es necesario disponer de una alternativa accesible, puesto que no tenerla no merma en nada la interacción con el formulario.
En el caso de una validación campo a campo de un formulario asíncronamente mediante AJAX, siempre que el formulario tenga un botón submit que valide los campos en servidor, no necesitará mayor alternativa.
En el caso de las capas de detalle (o balones) que aparecen sobre una celda de una tabla a modo de resumen (para no tener que navegar al detalle completo si no se desea), mi punto de vista es que si existe el enlace de detalle en cada fila, tampoco es necesaria otra alternativa accesible.

Por lo tanto, si cada componente de nuestro framework tiene correctamente implementado internamente su comportamiento en función de las capacidades del navegador y del contexto de ejecución, este framework conseguirá el objetivo de cualquier diseño técnico orientado a componentes: independizar a la aplicación que los utiliza acerca de sus particularidades de implementación, lo que en este caso significa, en un caso ideal, que el desarrollador de la aplicación no deberá preocuparse acerca de las alternativas accesibles para los elementos enriquecimiento utilizados.

De esta manera, la alternativa accesible es sólo a nivel de capa de presentación y sólo a nivel de componentes, no de aplicación. [4]

Es necesario conocer...

Si os interesa este tema, son imprescindibles los 40 tutoriales y artículos de AJAX y accesibilidad.

También por supuesto es imprescindible conocer la hoja de ruta WAI-ARIA (Roadmap for Accessible Rich Internet Applications (WAI-ARIA)), presentada por la W3C en septiembre de 2006.

[...] ofrece una propuesta global que permita asegurar la interoperabilidad entre las aplicaciones de internet enriquecidas y las tecnologías asistivas utilizadas por personas con discapacidad. La propuesta se apoya en tecnologías ya desarrolladas o que están en desarrollo por el W3C, tales como el Modulo del Atributo Role de XHTML.

[En W3C España]

[WAI-ARIA Roadmap] [WAI-ARIA Roles] [WAI-ARIA States and Properties]

[Ver artículo AJAX accesible II: WAI-ARIA]

Por último comentar el artículo "Making Ajax Work with Screen Readers" de Gez Lemon and Steve Faulkner, que proponen manejar el búfer virtual del lector de pantalla JAWS como vía para hacer accesible una aplicación web.

Como complemento de nuestra aplicación puede ser buena idea, pero no es un estándar, ni JAWS es el único software para usuarios con deficiencias visuales, ni por supuesto la accesibilidad está pensanda sólo para este colectivo, como a veces parece que mucha gente piensa.

En resumen, buenas prácticas

Respetar las pautas de accesibilidad en todos los elementos de las páginas aunque estén insertados dinámicamente.
Utilizar un patrón MVC que facilite la separación entre las lógicas de control y flujo de navegación (Controlador), de negocio y acceso a datos (Modelo), y de presentación en los distintos clientes, dispositivos y contextos (Vista).
Utilizar Javascript no intrusivo.
Conocer los navegadores para discapacitados visuales y comprobar que pueden interactuar con la aplicación: eventos adecuados, foco accesible, etc.
Detectar el User-Agent del usuario desde la primera petición guardando esta información para que sea recuperable por todas las páginas de la aplicación.
Crear una serie de módulos, de componentes AJAX, que en función del User-Agent y de si está habilitada la ejecución de Javascript sepan como “pintarse”, dando por tanto una opción alternativa accesible dependiendo del componente en cuestión.
Acatar la hoja de ruta de la WAI que permitirá por ejemplo informar mediante roles al usuario del funcionamiento exacto de la aplicación cuando los navegadores las implementen.

Notas

[1] Por ejemplo, Rails incluye alternativas accesibles para formularios que se envían por Javascript, incluyendo un argumento que indica a qué URL enviarlo si no está habilitado el Javascript.

[2] Por ejemplo, Dojo 0.4 empieza a ofrecer funcionalidad completa desde teclado e integración con modos de alto contraste así como con lectores de pantalla para las personas discapacitadas. dojo.a11y: la fundación para la accesibilidad (a11y), ha implementado algunos de los widgets de esta versión e implementará algunos más para la siguiente (0.5).

[3] Esta afirmación la considero válida en la actualidad, pero la evolución tecnológica que puede haber en un plazo de 2-3 años en los frameworks y productos disponibles, su integración con los IDEs, etc, seguramente desaconsejará a corto plazo el uso de frameworks propios, cuya principal debilidad es el coste y dificultad del futuro mantenimiento evolutivo/correctivo/adaptativo/perfectivo).

[4] A nivel de lógica de negocio, no sería óptimo trabajar sólo con macropeticiones (peticiones globales de la página como en una aplicación sin AJAX) ni siquiera componer las macropeticiones a través de las micropeticiones (pequeñas peticiones sólo de aquellos contenidos de la página que vamos actualizar con AJAX), por ello, sí que será necesario que junto a las micropeticiones haya macropeticiones para las variantes accesibles.

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