AJAX accesible

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 (“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 es imprescindible conocer WAI-ARIA, para ello podéis leer mi artículo WAI-ARIA. Introducción, referencias, ejemplos, herramientas

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.