Módulo 6: Accesibilidad, usabilidad y estética
JavaScript Asíncrono y XML: aportación práctica para la mejora de la Accesibilidad.
- Juan Fuertes
- Consultor DNX group
- Datos de contacto:
e-mail: juan.fuertes@dnxgroup.com
HTTP: la base de la transferencia de información
- Protocolo.- El conjunto de reglas que permite intercambiar datos entre dos máquinas.
- Modelo fundamental del web
- Protocolo HTTP: Protocolo de transferencia de hipertexto. Modelo petición - respuesta.
- Funcionamiento simple con un ejemplo
- Diferentes métodos
- Múltiples elementos interactúan pero la comunicación es bidireccional.
- HTTP es un simple protocolo stateless.
- Un cliente envía petición especificando el método HTTP que indica al servidor la acción a realizar, la dirección de un documento y la versión HTTP usada (1ª línea, p.ej "GET /intro.html HTTP/1.0").Tras lo anterior se puede incluir información adicional que no se refiere específicamente a la petición pero si puede ser usada por el servidor para generar una respuesta adecuada, algo del tipo: "User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 95) Accept: image/gif, image/jpeg, text/*, */*"
La primera línea de la respuesta incluye la versión de protocolo usada por el servidor, un código de estado y la descripción del mismo:
HTTP/1.0 200 OK
Tras ello se adjunta info adicional del tipo:
Date: Saturday, 23-May-98 03:25:12 GMT
Server: JavaWebServer/1.1.1
MIME-version: 1.0
Content-type: text/html
Content-length: 1029
Last-modified: Thursday, 7-May-98 12:15:35 GMT
Los métodos de la petición generalmente serán: - GET:obtención de información, querystring, limitado en algunos servidores a 240 cars.
POST: envío de información, los datos se pasan íntegramente sobre la conexión socket (dirección IP + protocolo + número de puerto) como parte del cuerpo de la petición, la URL se mantiene igual por lo que normalmente ni se pueden añadir a favoritos ni recargar.
Arquitectura cliente-servidor
- Proceso colaborativo entre dos o más ordenadores conectados a la misma red.
- Ejemplos en diferentes entornos: multimedia, tv por cable o banca.
- Clientes diversos
- Capacidad del servidor.
- Dualidad local del servicio
- Si el entorno es multimedia, el cliente es el dispositivo que visualiza el vídeo, cuadros y texto, o reproduce el audio distribuido por el servidor. El cliente puede ser un ordenador personal o un asistente digital personal, incluso una televisión inteligente que pueda comprender datos digitales.
- El servidor es el depositario del vídeo digital, audio, fotografías digitales y texto, y los distribuye bajo demanda; debe ser una máquina capaz de almacenar los datos y ejecutar todo el software que suministra éstos al cliente.En el entorno de computación actual, un ordenador Macintosh, Windows, UNIX o una computadora grande, puede ser un cliente.
- Cualquiera de estas plataformas puede actuar como servidor e incluso puede actuar como cliente y servidor simultáneamente. Esta doble función es posible debido a las capacidades multitarea de los modernos sistemas operativos.
Cada interlocutor usa su lenguajes
- Lenguajes del lado cliente. Un poco de historia.
- Lenguaje servidor. No sólo bases de datos.
- La panacea del XML
- Ejemplo práctico
- Lenguajes cliente: JavaScript, JScript, VBScript. JavaScript sólo tiene que ver con Java en que coinciden las cuatro primeras letras del nombre (gran error cometieron al denominarlo así). Si entendemos que el navegador convierte todo el código HTML en pequeños objetos que analiza para renderizar posteriormente, JavaScript me permite instanciar e interactuar en algunos casos con ellos.
- Lenguajes servidor: Java en parte (JSP), ASP, PHP, Perl o C++.
- XML es tan simple como lo quieras complicar (XPath, XSLT, XForms o el propio XML DOM que se desarrolla en la siguiente diapositiva). XML no es requerido en AJAX
¿y llega AJAX?
- Primera implementación a cargo de Microsoft sobre su navegador Internet Explorer que se incluyó con Windows 98SE
- La recomendación W3C aprobada en Abril 2004: Document Object Model Level 3 Load and Save Specification, cubre funcionalidad similar
- El boom de las "puntocom" ¿lo pasa por alto?: ya se usaban ténicas alternativas. Los efectos de "mouseover". Cuando se cambia vía JavaScript el atributo "src" de una imagen se está siguiendo un proceso similar.
- ¿Por qué ahora?
- En febrero 2005, Jesse James Garrett arquitecto de interfaz y fundador de Adaptive Path "acuña" el término:Asynchronous JavaScript and XML. Se trata de un modelo de desarrollo para aplicaciones web: "Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways." (extraído del artículo en el que apareció por primera vez el término AJAX.)
- Ahora el momento es otro. Se comienza a cumplir estándares.
- Hace dos años que el soporte XHTML y CSS se encuentra muy extendido.
- La base radica en la separación de presentación y contenido.
- El adorno: JavaScript y el "olvido" de la sigla: el importante DOM.
- Asincronía: el dilema de la recarga de página. Aplicaciones de escritorio en internet.
- Mini historia de los navegadores: 1993 aparece Mosaic de la National Center Supercomputing Applications. En 1994 aparece Mozilla Netscape Navigator como parte de la Suite Navigator. Ese año Mosaic vende derechos del motor de su navegador a SpyGlass que licencia su uso (también a Microsoft).Con la aparición de Windows 95 se presenta también Internet Explorer 4, que en su versión 5 se "empotra" junto a Windows 98 y que más tarde, en 1999 obtendrá el 99% del mercado. Ese año AOL compra Netscape. En el 2002 aparece la versión open source Mozilla (diferencia entre Suite Mozilla y Firefox)
- En Internet Explorer se implementa bajo el entorno de ejecución para objetos ActiveX. El proyecto pionero sobre el objeto comenzó con el navegador Microsoft IE4 concretamente sobre su cliente de correo electrónico, Outlook Web. El soporte es Mozilla 1.0, Opera 7.6 o Safari 1.2 de Apple. Antes de existir el objeto era común utilizar frames o iframes ocultos o con ventanas emergentes que se "comunicaban" con sus ventanas "padre" para realizar las peticiones de forma "transparente" al usuario.
- Debemos primero asegurarnos una buena base para nuestra aplicación web basada en XHTML y CSS que separe correctamente LA ESTRUCTURA Del contenido de la presentación. Tenemos que poder eliminar las capas de presentación y comportamiento y que quede sólo contenido. CSS se usa para separar la estructura (NO contenido), que hace que el contenido sea inteligible, de la presentación. Contenido: puede venir de una base de datos o de ficheros de texto. Estructura: puede venir de plantillas, transformaciones XSL o de un CMS . SI el contenido NO depende de estructuras podremos integrarlo luego en cualquier interfaz. Usaremos un CSS entonces para cada una (terminal móvil, PDA, PC o una nevera). Una vez hecho esto podremos "adornar" con soluciones de tecnología cliente, como JavaScript o DOM.
- El modelo de extensiones DOM permite acceder al árbol que el navegador construye como representación interna de los elementos de la página, permitiendo la adición, modificación o eliminación de dichos elementos (las ramas del árbol).
Realidad online
- Empresas especializadas: Backbase
- Librerías y scripts. Integración con el lado servidor
- Tecnologías derivadas
- GMail, el Cliente de correo web de Google. GoogleMaps
- Writely, procesador de textos online.
- Agencias de viajes: Orbitz o Kayak
- En Wikipedia podemos encontrar extensa información sobre el modelo en cuestión.
- Existen múltiples librerías y aplicaciones con diferentes alcances para la integración de AJAX con tecnologías de todo tipo: .NET, PHP, Perl, Java, ColdFusion. Análisis de latencias, formularios, integración DHTML, componentes (emulador de google suggest), generación de modelos para diferentes arquitecturas o entornos completos de arquitecturas J2EE (Ruby on Rails, basado en el modelo vista controlador tras el previo éxito de Apache con Struts y Tomcat).
- Hasta hay un IDE orientado a AJAX, morfik o,
- tecnologías ya existentes adaptadas al modelo AJAX, como JavaServerFaces y AjaxFaces.
Ventajas
- Todo el código es público
- Simplificación en las capas básicas de toda arquitectura cliente-servidor,
- Reduce la carga en servidor (validación de formularios)
- Reduce tiempos de escritura y tiempos de espera
- Estadísticas y tests de usabilidad
- Causa-efecto: el flujo de navegación lo va creando el usuario, te evitas una capa de control de flujo (J2EE). La mejor forma para guiar por el flujograma es ofrecer respuesta visual e inmediata a las acciones del usuario.
- Las arquitecturas para aplicaciones web profesionales implementan ademñas validación de formularios en el lado servidor por motivos de seguridad. Ambas validaciones han de existir.
Alternativas, críticas y problemas
- XUL (open source, solo Mozilla) y XAML (Microsoft). JSON (Java-JavaScript). XForms.- YAML de ruby on rails. Flash.
- Se ha criticado a la consultora que acuñó el término de esconder tras todo esto un vehículo de marketing para tecnologías ya existentes
- Problemas sobre el comportamiento del navegador. El navegador está concebido para la navegación de "puntero y clic" y las aplicaciones AJAX no preven este funcionamiento.
- Botones de adelante y atrás o Añadir a Favoritos
- Ser encontrado por buscadores
- Implicaciones sobre los diseñadores y arquitectos de interfaz.
- Actualmente los navegadores almacenan en sus historiales únicamente las visitas a páginas estáticas.
- Cambia el comportamiento estándar de los botones adelante y atrás pero es posible controlarlo en contenedores de la aplicación. El dilema del botón volver atrás: ¿no tendrá también algo de culpa el navegador? podrían asociarse eventos explícitamente a esos botones. Incapacidad para añadir a favoritos un estado de página concreto (puede usarse el fragmento identificador de la URL o ancla, lo que hay tras la #, para almacenar/recuperar el estado de la página).
- Además ¿añades a favoritos cada estado de tu cliente de correo local? Multitud de aplicaciones web han duplicado los botones del navegador.
- Si queremos que una aplicación web parezca una aplicación de escritorio no debería depender del navegador para que el modelo mental del usuario sea el adecuado (o mejor, de la interfaz de usuario del mismo).
- EL objetivo es que el desarrollador tenga su propio botón Volver o Añadir a Favoritos. Los navegadores podrían identificar las llamadas http AJAX y proveer funcionalidades (por medio de una cabecera especial, por ejemplo).
Cómo puede todo esto favorecer a la accesibilidad
- El W3C es claro en la directriz 6.3 de las WCAG, estableciendo como prioridad 1 que las páginas sean usables desactivando la funcionalidad JavaScript.
- Lectores de pantalla y JavaScript.
- Indiscutible el hecho que si JavaScript está desactivado nada del modelo descrito es aplicable.
- Necesaria implicación de las herramientas de ayuda.
- Por supuesto, es imprescindible ofrecer la misma funcionalidad. Localizar al cliente con JavaScript desactivado y ofrecerle las mismas funcionalidades.
- Soporte JavaScript de los lectores de pantalla: puede que técnicamente no lo soporten pero como se ejecutan "sobre o por encima" de la aplicación de navegación (que sí lo soporta).
- Algunos incluso "intentan" inferir lo que hace e intentar darle algún sentido. Los lectores de pantalla puede que lo infieran pero "nunca" lo interpretarán (en sentido estricto).
- Los lectores de pantalla no tiene un DOM parser, pero la última versión localiza onmouseovers únicamente "INLINE" e informa al usuario del cambio (que activa el mouseover con Control + Enter)
La vuelta de tuerca
- Posibilidad de favorecer al usuario con lector de pantalla y JavaScript activado
- Localización del lector en el cliente.
- Muestra de simples ejemplos prácticos.
- Reflexión final.
- Muestra de una serie de ejemplos prácticos de cosecha propia, en las que el modelo AJAX puede favorecer y ofrecer funcionalidades adicionales a los usuarios que usan lectores de pantalla.Se publicarán junto a la ponencia.
- Paralelismo entre una aplicación tradicional - análisis de usabilidad para localizar necesidades de ajax.
- Demo con lector de pantalla
- Ejemplos sobre cuando usar AJAX y cuando no. Soluciones sólo con JavaScript. Cuando prescindir de XML. Ejemplos de alternativas: GreaseMonkey, XUL y JSON
