Ir directamente al contenido de esta página

Ajax, Ajax, Ajax…

Desde que en 2005 Jesse James Garrett bautizara con un nombre que suena tan bien a su aproximación a la programación de aplicaciones web —que por cierto, a pesar de lo que diga la Wikipedia sobre este enfoque, no es un acrónimo—, las discusiones sobre su bondad o maldad no han cesado.

En este contexto, resulta reconfortante leer un artículo razonable como es Stop using Ajax! de James Edwards, más conocido como Brothercake, publicado el pasado abril en la página de Opera Developer Community. No voy a hacer una traducción del artículo, pero sí voy a anotar los puntos más importantes, con los que estoy de acuerdo.

Ajax y la accesibilidad

Una pregunta que se oye a menudo es: «¿el Ajax es accesible?». Cuando se me hace suelo contestar «¿es el HTML accesible?», porque con él pueden lograrse perfectamente páginas que no lo son. A lo que apunto es que, como siempre, la accesibilidad no tiene tanto que ver con la tecnología que se emplea sino con la manera de emplearla. Como muestra Jeremy Keith en su libro Bulletproof Ajax, que algunas de las aplicaciones de Ajax sean accesibles puede lograrse aplicando los principios del JavaScript no obstrusivo. Sólo que, como bien apunta Edwards en su artículo, hay que tener en cuenta que en muchas ocasiones estos principios no son suficientes para que los contenidos sean accesibles para los lectores de pantalla.

La base del JavaScript no obstrusivo es que una página debe proporcionar su funcionalidad básica sin depender de aquel, y que lo que debe hacer es sólo ofrecer mejoras de la experiencia del usuario. La página, por tanto, estaría preparada para funcionar en dos extremos: con JavaScript soportado y activado, y en su ausencia. ¿Pero qué pasa con los lectores de pantalla? Pues que JAWS, Window-Eyes o Hal soportan JavaScript, pero de una manera bastante imperfecta. En el sistema bipolar de sí o no a JavaScript, quedan en un difuso lugar intermedio.

El principal problema que se plantea es que al actualizar los contenidos del DOM de un documento, los lectores de pantalla pueden ser o no capaces de reconocer que ha habido cambios en la página, y si no son capaces la información proporcionada por este medio no llegará al usuario. En este sentido es esclarecedor leer Making Ajax Work with Screen Readers de Gez Lemon y Steve Faulkner.

Afortunadamente en el W3C ya están desarrollando una solución, el ARIA, una recomendación que extienda el marcado de un documento y permita definir propiedades relevantas para la capa de comportamiento. Por medio de la definición de roles y estados, se puede informar a los lectores de pantalla de, por ejemplo, si una zona del documento puede estar sujeta a cambios dependientes de la interacción del usuario, y de si se ha producido en ella tales cambios. Como todos los documentos del W3C, la especificación de ARIA es un tanto densa, pero el mismo Gez Lemon ha escrito una introducción muy buena.

Por supuesto, con el estándar no será suficiente: por un lado será responsabilidad nuestra como desarrolladores implementar las mejoras que permite ARIA, y por parte de los fabricantes de lectores de pantalla de soportarla en sus productos.

Ajax y la usabilidad

Sobre este punto el artículo comentado no entra en detalles, pero quiero incluirlo para complementar la visión general de las dificultades que supone este modelo de desarrollo.

Con respecto a la usabilidad, Ajax es un arma de doble filo. Es innegable que la actualización de partes de un documento sin necesidad de una nueva llamada al servidor es una mejora de la experiencia del usuario, pero la contrapartida es que se bloquean dos de las funcionalidades básicas del navegador más empleadas por éste:

No hay que sorprenderse de estas limitaciones; al fin y al cabo, son las mismas que existían en las páginas creadas con marcos.

Usar Ajax por usar Ajax

La segunda mitad del artículo de Edwards es una crítica a la decisión de emplear Ajax simplemente por el hecho de que es nuevo, algo muy similar a lo que ocurrió en su momento con Flash, otra tecnología que hemos visto aplicada a páginas que no lo necesitaban.

De la misma manera, igual que Flash puede ser la tecnología propiada para ciertos contenidos —sobre todo multimedia—, el autor reconoce que aplicaciones web como Google maps o Meebo serían imposibles sin Ajax. Pero no son estas aplicaciones las que critica, sino las páginas en las que se ha empleado de manera innecesaria, limitando gratuitamente los usuarios que pueden emplearlas sin restricciones. Y para reforzar su punto de vista, ha creado una versión de la interfaz de Flickr que no necesita de Ajax para ofrecer la misma funcionalidad que la original.

Por desgracia, personalmente creo que esta aplicación gratuita de Ajax va a ser cada vez más común: hoy día es bastante frecuente oir a un cliente —que por otra parte no comprende muy bien lo que es Internet— pedir una interfaz en Flash; el año que viene puede pedirla en Ajax.

En conclusión

Para terminar, las conclusiones del artículo, con las que estoy plenamente de acuerdo, son:

Esta entrada se publicó el 20 de agosto de 2008, se archivó en , y fue etiquetada como . Autor: Saúl González Fernández. Aún no hay comentarios ›.

Comentarios

Aún no hay comentarios

¿Algún comentario?

* Los campos con un asterisco son necesarios

Últimos proyectos

© Digital Icon, S.L., 2007 – 2017