James Brothercake Edwards abrió el debate con su reciente post en Dev.Opera, donde asegura que los desarrolladores están más inclinados a seguir las tendencias de las últimas y mejores tecnologÃas que a comprometerse con la accesibilidad. Entre otras cosas, dice que las metodologÃas de Ajax son realmente ofensivas.
Usar tecnologÃas no muy accesibles sólo porque son cool va en contra de la idea humanista que engloba los estándards de la web: acceso universal. Y este es sólo un ejemplo de su bandera a favor de la accesibilidad y en contra de una herramienta como Ajax y otros lenguajes.
La voz de James Brothercake Edwards se está difundiendo en la web. Esto es más o menos lo que dijo:
Introducción
Hace un tiempo atrás entré en un foro de discusión sobre la accesibilidad en los sistemas CAPTCHA. Este artÃculo no trata sobre eso, pero lo menciono porque un comentario en particular me pareció un claro ejemplo de una actitud muy frecuente que veo una y otra vez:
“Estoy muy a favor de hacer la web más accesible para todos, pero…”
Como agregué en ese foro, estar “muy a favor” es un decir cuando no estás preparado para hacer lo que se requiere a favor de eso; es simplemente un acto arrogante y falso decir que se está muy a favor de algo pero no hacer nada (o no hacer todo) para lograrlo. Estuve unos dÃas pensando en esto y hasta escribà unas reflexiones sobre el tema en mi sitio: Technology is the last, best hope for accessibility. En ese post hablé sobre los desarrolladores a los que el tema no les interesa:
“Los programadores que están en la parte de servidores, que se esconden detrás del servidor niegan el hecho de que los clientes son los importantes… Los programadores que trabajan directamente con clientes están tan obsesionados con lo último, lo más cool, que dejan detrás grupos de personas en nombre de la novedad y lo que se ve más lindo.”
La web ya era accesible para todos. La visión original de Tim Berners-Lee sobre la web fue un espacio de acceso universal; y las tecnologÃas involucradas en el proceso –HTTP y HTML– fueron diseñadas para ser plataformas y dispositivos “agnósticos”; no deberÃa importar qué tecnologÃa utilices para acceder a la web.
Pero en esto se entrometen los intereses comerciales, superando la necesidad de soluciones abiertas y estandarizadas; en efecto, queremos correr antes de aprender a caminar porque el gran auge comercial de Internet es mayor que sus capacidad tempranas, las actuales (internet es joven). Y entonces tenemos cosas como la guerra de navegadores, el DHTML especÃfico de los navegadores y el diseño basado en tablas. Estas son cosas que fueron en el mismo sentido de la visión original, porque la gente querÃa contenido rico cuando la tecnologÃa no estaba lista. Y ahora está sucediendo de nuevo.
Por supuesto, para la mayorÃa de la gente esto es irrelevante: si funciona y luce bien ¿dónde está el problema?. Bueno, desafortunadamente el problema es que hay una vÃctima, y la vÃctima es la accesibilidad. Lo que estoy sugiriendo en este artÃculo es que no es aceptable que haya una vÃctima –especialmente cuando hay un grupo de gente que ya está sufriendo desproporcionadamente– y si lo que estamos haciendo genera eso, entonces lo que estamos haciendo está mal. Repasaré los argumentos en detalle, llegaré a una conclusión y en el camino sugeriré cómo podemos encontrar soluciones sin usar Ajax a muchos problemas de funcionalidad donde actualmente se usa Ajax.
“MayorÃa” no es suficiente
Ajax es una idea útil y sólida. Pero todas las ideas deben pasar por una implementación práctica –una tecnologÃa que haga que las cosas sucedan– y en este caso la tecnologÃa es inmadura porque deja a varios grupos de usuarios atrás. Los más afectados son los que utilizan tecnologÃas asistidas, pero también a los que usan navegadores menos capaces que no soportan scripting.
PodrÃa ser razonable decir que el soporte de JavaScript no condiciona la accesibilidad, si es que es una elección del usuario. Pero si un usuario deshabilita el JavaScript deliberadamente ¿No deberÃas ser responsables de esa elección? Bueno, sÃ, deberÃan, pero ese no es el verdadero problema aquÃ; el verdadero problema es más complicado y no es una elección de un usuario.
Los lectores de pantalla como JAWS, Window-Eyes y Hal son dispositivos que soportan scripting (son de los navegadores más capaces), sin embargo su habilidad para manejar aplicaciones de JavaScript no tiene equivalente. No podemos confiar en alternativas sin script o en una interface scriptada. Estos dispositivos hacen que las mejoras progresivas que se estuvieron logrando en la red finalmente fracasen.
Ahora se sabe, por ejemplo, que las tecnologÃas asistidas tienen problemas con actualizaciones asincrónicas del DOM.
También podrÃas decir –y con bastante razón– que es un problema de los lectores de pantalla, que la tecnologÃa está rota y necesita ser reparada. PodrÃa ser, pero ese razonamiento no ayuda. El hecho es que hay gente que está utilizando la web ahora misma, usando tecnologÃa que cada vez genera más dificultades que soluciones, y no tienen la opción de usar algo mejor porque no existe algo mejor.
(Tomemos esto del uso con una analogÃa: supone que hablas inglés y español y le estás hablando a alguien que sólo habla español. ¿SeguirÃas hablando en inglés sólo porque piensas que suena mejor? ¿Te quejarÃas de que es culpa suya que no te entienda?)
Ahora podemos llegar a una conclusión intermedia: este problema no ha sido solucionado y, en mi opinión, hasta que llegue la solución, Ajax no deberÃa ser considerada una herramienta oportuna para webs de uso extendido.
No está bien dejar atrás a miles de usuarios sólo porque no se adaptan a tu modelo de lo que es un usuario. De todos modos, aprecio que se hayan conseguido útiles progresos y desarrollos si otra gente puede beneficiarse con ellos.
Pero creo que no hay porqué elegir entre buenos desarrollos y desarrollos accesibles, se pueden lograr ambos. Recordemos esta simple observación:
Las nuevas innovaciones generalmente nos inspiran a hacer cosas para las que realmente no necesitamos la nueva tecnologÃa, es una realidad que el cambio de enfoque y herramientas más sencillas nos inspiren nuevas ideas.
En otras palabras, el surgimiento de las técnicas de Ajax han inspirado toda una nueva gama de aplicaciones, pero en muchos (sino en la mayorÃa) de los casos, estas aplicaciones ni siquiera necesitan Ajax para funcionar pero son pocos los que se pusieron a pensar en eso. Es fácil asumir que la evolución de las ideas sigue a una cadena de causa y efecto, pero este no es el caso. La evolución es tan aleatoria como determinada, y podemos escoger las mejores ideas… Podemos construir aplicaciones Web 2.0 sin usar Ajax.
Web 2.0 != Ajax
Una de las joyas de la Web 2.0 es el sitio de intercambio de fotos Flickr. Realmente amo Flickr y ciertamente no estoy sugiriendo que es un sitio web terrible. Pero la verdad es que Flickr usa Ajax gratuita e innecesariamente. La funcionalidad de Flickr no requiere actualizaciones asincrónicas de la página; todo podrÃa haberse hecho a la vieja usanza de la Web 1.0. Si hubieran tomado el modelo “viejo” hubieran logrado mayor accesibilidad y mayor usabilidad.
Para ilustrar esto, haz clic y verás un boceto de página. Pensando en cómo se podrÃa haber hecho Flickr sin usar nada de Ajax, me topé con la idea de una página editable similar a una wiki, en donde todo lo que sea editable por un usuario se pueda modificar de una sola vez. Entonces tienes por un lado una página regular de sólo lectura y por otro una editable. Haz clic aquà para descargar los archivos completos de ejemplo.
Esta distinción genera una mejora en la accesibilidad porque baja los requerimientos tecnológicos que necesita para funcionar correctamente. Además creo que ayuda a la usabilidad porque evita las dudas que genera la interface en Ajax: si todo se edita en el lugar no hay cosas para cliquear por doquier.
Por este tipo de cosas es que digo que no necesitamos Ajax para generar una interface editable. La página se construye como un formulario y los parámetros editables actúan como campos en ese formulario (los parámetros editables se indican en el ejemplo con cajas amarillas). Todo esto genera una solicitud de POST cuando se envÃa (se evita el uso de GET data, que es inapropiado con algunos tipos de acciones); y por supuesto, todo sin JavaScript.
¡Es un XHTML semántico, sin tablas en la composición!
Para mi es más usable que la interface original, porque se ve obvio lo que es cada cosa: no hay acciones de formulario disfrazadas de links, o links disfrazados de botones. Hace lo que dice que hace. Pero sé que el tema de la usabilidad es debatible. Puedes mirar mi formulario y pensar que es menos usable que el formato actual del sitio. La usabilidad es, después de todo, uno de los principales beneficios de Ajax, y si podemos diseñar interfaces que sean más auto-contenidas y versátiles ¿No serÃa eso algo bueno? (¿PodrÃa acaso Flickr ser lo que es hoy en dÃa –podrÃa haber alcanzado el éxito que tiene– sin esa experiencia “progresista” del usuario?)
Pero los formularios de posteo y las actualizaciones de las páginas son normas del comportamiento actual de la web. Son parte de un conjunto de expectativas que comparten actualmente todos los usuarios de Internet. ¿Es realmente una buena acción dar de baja todas esas expectativas sólo porque pensamos que de otra forma la web podrÃa ser mejor?
Esforzarse por lograr cosas mejores no es suficiente si en el proceso perdemos por completo a algunos de nuestros usuarios. Pienso que una mejora progresiva es como una jerarquÃa de objetivos: donde la accesibilidad es el más importante, seguido de la usabilidad y por último de la estética. Idealmente queremos los tres, pero si alcanzar uno de los niveles más bajos significa resignar uno de los objetivos más altos, realmente no creo que se justifique.
Con mejor o peor usabilidad, creo que el tema de la accesibilidad es innegable. Todos los navegadores y las tecnologÃas asistidas saben como manejarse con formularios. ¡No necesitas JavaScript, o un mouse, o CSS y ni siquiera color para que funcione!
“Y el hombe y la mujer… bueno, el hombre… que fue a la luna, lo hizo sin mouse, con una pantalla en blanco y negro y 32 kilobytes de RAM”
Pero Ajax permite crear aplicaciones que no se podrÃan hacer de otra forma…
¿Cómo podrÃa funcionar Google maps sin actualizaciones asincrónicas? ¿Y Meebo, el servicio de mensajerÃa online, que tampoco podrÃa haberse hecho sin Ajax?
Meebo y Google maps necesitan Ajax para funcionar, y por eso es que no los critico y acepto que los temas principales de accesibilidad no tienen solución hasta ahora. No soy un puritano y si tengo que decidir entre “haz X para la mayorÃa” y “no hagas X para nadie”, me quedo la primer opción.
Creo que Twitter podrÃa haberse hecho sin Ajax, porque sus actualizaciones periódicas son relativamente poco frecuentes. Twitter podrÃa haber funcionado haciendo un refresh completo de la página, o un inframe conteniendo sólo la lista de mensajes, refrescándola cada uno o dos minutos. Pero las páginas que se recargan automáticamente tienen sus propios problemas de accesibilidad (esto se debe principalmente a que la recarga de la página sin el consentimiento del usuario se considera un acto rudo e intrusivo). Por eso, si Ajax es tal como viene y es eso o nada, entonces no tendrÃa casi nada de qué quejarme…
De hecho, tengo un cliente que tiene una empresa donde la división de desarrollo web ha realizado trabajos que sólo podrÃan haberse logrado con Ajax. Fueron consultados para hacer mejoras de usabilidad en un sistema de legajos. Aparentemente no habÃa solución, pero Ajax permitió las mejoras agregando nuevos componentes UI directamente en la interface, sin necesidad de tocar el back-end. ¡Y eso es genial y el cliente quedó muy satisfecho!
Pero todos estos ejemplos son casos contados, cosas que rara vez suceden. La mayorÃa de nosotros, la mayorÃa del tiempo, trabajamos en aplicaciones que realmente no necesitan Ajax y que no se benefician significativamente con su uso. Por eso digo que generalmente Ajax se usa sólo por cuestiones estéticas…
Recientemente fui a una empresa que estaba desarrollando una aplicaciones compleja completamente en Ajax. Para mi Ajax no era necesario para lo que querÃan hacer. QuerÃa dar el visto bueno, pero estaba seguro de que en materia de accesibilidad el proyecto no iba bien. Asi que les comenté el problema de Ajax con la accesibilidad. Sin embargo, su excusa para el uso de Ajax me sorprendió. Sus argumentos eran razonables en términos financieros: “Si llegamos al 90% de penetración usando esta tecnologÃa, ¿Por qué deberÃa importarnos el otro 10%?”
¿Pero qué pasarÃa si todos pensáramos asÃ? ¿Qué pasarÃa con ese 10% que de pronto encontrarÃa que la web es un espacio donde ya no son bienvenidos? Entonces la misma tecnologÃa que habÃa borrado las fronteras, se convertirÃa en otra barrera.
Eso está sucediendo ahora y no está bueno. Este apuro por crear Aplicaciones Ricas de Internet (RIA) está pasando sin poner cuidado y atención en temas tan fundamentales como la accesibilidad.
Quedarse con valentÃa
En 2293, durante su discurso de apertura en la conferencia de paz en Camp Khitomer, el presidente de la Federación dijo estas grandes palabras:
“Déjennos redefinir el progreso: el hecho de que podamos hacer algo, no significa que debamos hacerlo.”
Jesse James-Garrett pudo haber iniciado una revolución, pero estoy seguro que no fue su intención. TenÃa la libertad de usar una técnica donde la accesibilidad no importe, y universalmente no fue un problema. Pero la mayorÃa del tiempo, en la mayorÃa de las cosas que hacemos, no tenemos ese lujo; entonces no abandonemos las cosas que funcionan.
Dejemos de ser tan caprichosos y tomémonos un tiempo para hacer las cosas bien.
De todas maneras… las buenas ideas en esta evolución de la web son conceptuales, no tecnológicas, de redes sociales, tagging, contenido generado por el usuario… y no necesitamos Ajax para que todo esto funcione.
Para resumir
Como conclusión, estos son mis puntos:
- No digo que Ajax es malo, sino que es inmaduro
- No digo que no uses más Ajax, sino que no lo uses sólo por usarlo, sino que trates de evitarlo y reemplazarlo por alternativas que brinden mayor accesibilidad
Cuando Ajax crezca seré uno de los usuarios más entusiastas. Estaré trabajando para encontrar una solución a este problema. Pero hasta que ese dÃa llegue, itentaré apegarme a herramientas más accesibles basadas en estándares ya probados, evitando a hacer uso de juguetes superficiales e inaccesibles.
Haz clic aquà para ver el post original: Stop using Ajax!
Miércoles, 30 de Abril de 2008 a las 15.01
No se muy bien que productos has desarrollado; pero creo que andas muy equivocado en tu directriz de desarrollo.
Ajax es cien por cien recomendable; y para temas de accesibilidad los métodos Hijax es obligatorio; pero además se suele brindar una alternativa a todo el javascript y enviarle a una página sin nada de javascript ni estilo para que pueda tener toda la información que el usuario necesita.
creo que deberÃas ampliar tus horizontes y tener en cuenta el tamaño del trafico de datos de los servidores; lo digo por la critica que le haces a Twiter
Miércoles, 30 de Abril de 2008 a las 15.41
No estoy nada de acuerdo.
Por el contrario, tecnologÃas como AJAX bien aplicadas mejoran la accesibilidad y la usabilidad de la web, pero no sólo al hacer parecer los sitios más sofisticados sino al efectivamente permitir un mejor diseño.
El HTML o DHTML son muy rústicos en ese aspecto. Para cada acción, un submit o un refresh de página. ¿Qué usabilidad es eso? Pésimo. En cambio AJAX o equivalente significan otra dimensión de posibilidades.
Por lo demás, el autor se contradice. Por más que cierre el artÃculo diciendo “No digo que no usen AJAX, pero evitenlo si pueden”, el sentido general es no aún usen AJAX. Es decir, hoy, no usen AJAX.
También se puede evitar FLASH, se puede evitar hacer streaming de video (se podrÃa poner el link como antes, no?). Es más, se podrÃa evitar RSS también… ¿para qué usarlo si se puede visitar todas esas páginas de noticias manualmente? También se podrÃa evitar los servicios web, y si uno quiere combinar información, ir sitio por sitio y listo. No creo que por el hecho que no sea vital para algo entonces sea necesario obviarlo.
Los problemas que plantea de accesibilidad no son propios de AJAX sino de un mal diseño o poco cuidado. Si al programador o diseñador o equipo de desarrollo (término más apropiado, creo yo) no le importa la accesibilidad, tampoco le va a importar con ninguna otra tecnologÃa. AJAX no lo dificulta particularmente.
Si AJAX es nuevo y no se aplica nunca va a madurar, y si no se vuelve un estándar las tecnologÃas que facilitan el acceso (lectores de pantalla, etc) nunca van a evolucionar en ese dirección.
Es como pedir no usar celulares hasta que las baterÃas se desarrollen lo suficiente como para soportan las nuevas funciones. Es un rÃo constante de cambio, no se va haciendo de a “bloques” estipulados.
Todo esto tomando a AJAX como algo meramente estético (ventanitas desplegables) y no considerando las posibilidades que brinda para combinar información de distintas fuentas, actualización de detos en tiempo real, etc larguÃsimo.
Viernes, 2 de Mayo de 2008 a las 17.11
¡Hola, acido69!
Jeje, yo opino igual que tú, pero por la manera en que hablas parece como si te dirigieras a James “Brothercake” Edwards.
Te dejo el link de su post original para que puedas descargar tu indignación ^_^ (haz clic aquÃ).
¡Saludos!
Lunes, 5 de Mayo de 2008 a las 12.20
Estoy de acuerdo que ajax solo deba usarse cuando realmente se necesite, pero no estoy de acuerdo en simplemente decir no usemos ajax, y que es hay cosas que de no hacerlas con ajax serÃan mayor problema que no haberlas hecho con ajax, he desarrollado multitud de aplicaciones web, y comento algunos casos puntuales:
Hay una lista de departamentos (provincias) seleccionas uno y te carga la lista de ciudades de ese departamento, si se hace SIN AJAX, resulta que habria que hacer un carga completa de la página para solo enviar la id del departamento, eso serÃa absurdo enviar todo un formulario cuando solo necesito un campo.
Tengo una lista de empresas en un select al cambiar la selección (onchange) cargo la lista de productos, y asu vez cuando cambio el producto cargo una lista de opciones check de productos adicionales, eso hacerlo sin ajax, serÃa enviar 2 veces el formulario y realizar dos cargas completas de la página, estoy seguro que eso hay que hacerlo con ajax.
Mis conclusiones son:
Usar dhtml, javascript, xajax, flash, solo cuando es necesario.
Entre enviar todo un formulario, cargar toda una página para modificar un pequeño campo, 100% usar ajax.
La única forma que una tecnologÃa madure es usandola, no hay otra forma.