Posts Tagged ‘accesibilidad’

Nueva web del Ayuntamiento de Granada: foto-comentarios

Thursday, May 15th, 2008

Hace unas semanas que se publico la nueva web del Ayuntamiento de Granada. No le hice mucho caso por falta de tiempo, pero en cuento he tenido un momento para ver qué tipo de rediseño habían hecho… en fín, sin palabras, unas capturas creo que pueden ser reveladoras respecto a cómo se han currado el tema de accesibilidad… a buen entendedor, pocas palabras bastan:

Granada.org en un navegador estándar

mmm… diseño con ancho fijo 800 x 600 optimized

Granada.org

Granada.org desactivando Javascript

Ostia… si no se puede navegar ¿Dónde coj… están los menús?

Imagen 6.png

Granada.org sin CSS

No veo nada…

Granada.org sin CSS

Granada.org sin CSS y sin Javascript

Me temo que esta gente no sabe lo que es un encabezado… pero conocen a fondo el elemento TABLE

Granada.org sin css y sin javascript

Y este sello??

Imagen 10.png

Sin palabras

Imagen 11.png

FW – Ponencia 2: AJAX a prueba de balas

Wednesday, October 3rd, 2007

A que se refiere con el término “a prueba de balas”: se refiere a la metodologóa de “incremento progresivo”. Capas: contenido (el rey), estructura, presentación, comportamiento.

Este planteamiento tiene de bueno que cada capa tiene su propia tecnología

CONTENIDO
ESTRUCTURA-> HTML
PRESENTACIÓN-> CSS
COMPORTAMIENTO.-> Javascript, AJAX

Haciéndolo bien, permite que no usar una capa no impide acceder al contenido. hacerlo bien es usar una tecnología adecuada para cada capa, no mezclar.

Por supuesto también hay que separar el comportamiento y hacerlo como capa que añade pero no afecta a la inferior. En HTML Podemos tener un Enlace, ese es el comportamiento básico, el que se define en la etiqueta A.

Para cambiar el comportamiento la idea no es añadiré un evento onclick al enlace, es mucho más limpio sobre-escribir el comportamiento de todos los enlaces en una función externa. La filosofía que plantea es que al igual que CSS está totalmente separado de la estructura, el comportamiento debe separar de la misma forma

¿Qué ocurre con Ajax? Ajax no es solo utilizar javascript, para el ponente, es comunicarse con el servidor sin refrescar la página (efectivamente). ¿Qué tecnologías permite hacer esto? una posibilidad serían los Frames, realmente cumple con la definición que él hace; también valdrían los iframes, también valdría Flash cuando cargamos movieClips ante determinados eventos, realmente estamos cargando contenido sin refrescar. EVIDENTEMENTE ESO NO ES AJAX

Todo lo anterior es tontería… AJAX es XMLHttpRequest… el objeto javascript clave de todo este asunto. Una breve historia: surgió de Microsoft con el Internet Explorer 5, hace 7 u 8 años. Curiosamente el tema de AJAX es mucho más reciente… ¿En qué momento? cuando otros navegadores, básicamente Mozilla, comenzó a utilizar.

XMLHttpRequest es un elemento intermedio entre navegador y servidor. Realmente es un objeto con propiedades y métodos… en fin… nos explica cómo funciona AJAX y en qué consiste. No voy a postear una información que se puede conseguir en mil sitios.

Tras la explicación vuelve a la base de la ponencia, AJAX como una capa que no debe impedir el acceso al contenido y la visualización de la estructura. Esto es lo importante, no la tecnología sino cómo utilizarla correctamente. AJAX debe ser el medio que nos extrae la información del servidor y punto, no el objetivo en si.

Siguiendo la filosofía correcta un navegador que no disponga de Javascript debe permitir acceder a los mismos contenidos que uno que si lo tenga. El que lo tenga, evidentemente, se beneficiará de la rapidez y comodidad que esta tecnología aporta.

Introduce un término HIJAX, incremento progresivo. :

-Empezar a hacer la web como siempre, html, hipertexto, simplicidad. Se mantiene el procesamiento de los datos en el servidor.
-Si añadimos Ajax lo que cambiaremos es que en vez de solicitar la información mediante un enlace lo podemos hacer con XHR porque el navegador lo permita. Pero no hemos suprimido los enlaces con AJAX, hemos mejorado al cambiar el comportamiento del enlace cuando el navegador lo permite. ¿Donde está la clave? AJAX hay que implementarlo al final, tras haber desarrollado la web en modo tradicional.

Reconoce que lo anterior no es tan sencillo.

AJAX debe utilizarse sólamente cuando es necesario.

-Autentificaciones
-Carritos de la compra
-Sistemas de puntuación / valoración de elementos (la típica estrellita)
-Añadir comentarios en blogs

Defiende que AJAX no debe ser para hacer super aplicaciones webs sino para mejorar las webs, la experiencia del usuario al interactuar con el contenido.

Una magnífica ponencia, una buena explicación de AJAX y defiendo una postura muy coherene: resumiendo, AJAX accesible y cuando hace falta. Hay que asegurarse que el usuario puede acceder al contenido aunque no tenga Javascript. Para super-aplicaciones mejor usar cosas como Flash, que para eso está.

Entra también en el tema de los desafíos que AJAX plantea a nivel de diseño e interacción. Toca el punto clave Si usamos AJAX hay que informar al usuario de lo que está pasando cosa que antes no era necesario debido a que el navegador se encargaba de informar. Un ejemplo, propio, y muy importante… si añado un producto al carrito en el mundo tradicional se me recarga la página, me lleva a la cesta… quedo informado. Con Ajax no, puede añadir el producto al carrito y no observar un solo cambio en la web.

Plantea aprender un poco del mundo Flash. También el utilizar las convenciones que están surgiendo como las que implemente Basecamp (37Signals).

Un ejemplo que pone sobre este tema ¿Qué ocurre con el botón de volver atrás? ¿Cuando debemos permtir al usuario volver hacia atrás?… plantea que para responder a estas preguntas debemos hacer pruebas de usuario.

Buena ponencia, buena postura, un 8

Disponbile la presentacón en breve en Adactio.com

El caso de AC Hoteles y las ventajas de una web accesible y estándar

Thursday, March 22nd, 2007

Las webs del grupo AC Hoteles han sido eliminadas de Google debido a la utilización de técnicas SEO “no legales”. Podeis informaros sobre el asunto en El Telendro y Google Dirson.

Veo que ya hay discusiones sobre las causas exactas del baneo y no es el fin de este post explicarlas. La idea es aprovechar este caso para defender el desarrollo de webs accesibles y basadas en estándares. Tomemos dos de los factores que pueden explicar el baneo:

  • Cloaking: Presentan a los buscadores una versión de la web con contenidos distintos a los que vería un usuario con un navegador.
  • Keyword stuffing:Ponen meta-keywords y meta-description con contenido no relacionado con el que aparece en la página.

¿Por qué tienen que usar estas técnicas? Pues básicamente debido a que su contenido no es accesible excepto para quien teniendo sus facultades sensoriales y motoras en buen estado dispone de un navegador equipado con el plugin de Flash. Por desgracia los bots de los buscadores no funcionan así y el único contenido que les va a aportar posicionamiento será el que esté fuera del flash.

Hacer una web accesible tiene como consecuencia que se facilita a los buscadores el procesamiento de la misma y es un buen punto de partida para posicionarla y utilizar técnicas legales de optimización para buscadores basadas en relevancia del contenido. Si además la web está correctamente maquetada mediante lenguajes estándares y marcado semántico miel sobre hojuelas para el buscador.

Pero es que no entiedo la puñetera manía de que hacer una web accesible y con estándares impide que tenga un buen diseño. ¿Que tiene la web de AC Hoteles que no se pueda hacer mediante código estandar y accesible? Veamos esta captura de su web:

Imagen 52.png

  • Navegación con pestañas
  • Imágenes que rotan
  • Textos que cambian mediante un pequeño submenú
  • Pie con texto

Mi opinión es que ese diseño no favorece el uso de la web pero es que todo eso se puede hacer sin utilizar flash y mediante lenguajes estándares manteniendo además un nivel aceptable de accesiblidad. ¿Lo intentamos?

WCAG 2 – ¿Qué hacer con ellas?

Thursday, February 8th, 2007

En The Web Standards Project reflexionan sobre el estancamiento en el que se encuentra el documento sobre las nuevas pautas de accesibilidad desarrolladas por la W3C, las WCAG 2. Desde la publicación de la “última llamada” para que la comunidad revise el borrador de trabajo, publicada hace ya un año, parece que el consenso brilla por su ausencia, no hay acuerdo y el tema está estancado.

Son ya 6 los años que han pasado desde que se inició el desarrollo de estas pautas y la pregunta, obvia, es ¿Y ahora que?. El polémico Joe Clark se posiciona en una carta abierta a Tim Berners-Lee (En inglés).

Certificación de accesibilidad por Aenor

Monday, February 5th, 2007

[Vía Torresburriel] AENOR lanza la certificación de accesibilidad web en colaboración con CTIC y ESI.

El tema es interesante. Como siempre hemos dicho, no vale con poner el sellito porque me da la gana ni considerar que una página es accesible porque cumpla los puntos de verificación automáticos de algún test (TAW, hera…).

Al menos el sellito no vale para aquellas webs que deban cumplir la accesibilidad por ley (cualquier web de la administración pública o financiada con fondos públicos) y aquellas otras que deban hacerlo por cuestiones éticas (universidades privadas, grandes empresa, etc.).

Otro asunto son las webs de organizaciones pequeñas y con recursos limitados que nunca van a poder costearse una certificación de este tipo, pero que no por ello deben dejar de tener en cuenta la accesibilidad. Éstas pienso que deberían desarrollar sus sitios webs con personas con un mínimo de conocimientos sobre accesibilidad y hacer tests para comprobar que cumplen los criterios básicos.

Extractos importantes de la noticia

AENOR ha desarrollado un sistema de certificación en esta materia, según la norma UNE 139803:1994 Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad para contenidos Web, que se fundamenta en las directrices de accesibilidad del World Wide Web Consortium (W3C), cuya oficina española está en la Fundación CTIC.

El acuerdo supone que CTIC y ESI prestarán a AENOR servicios técnicos mediante inspectores cualificados que analizarán el grado de accesibilidad de las páginas web, tanto en empresas como en instituciones. El proceso consiste en evaluar un sitio web, combinando sistemas de revisión automática con metodologías de inspección manual.

Google accesible search: prioriza sitios accesibles en sus resultados

Wednesday, December 20th, 2006

[Vía Blog oficial de Google] Google tiene un buscador accesible que prioriza resultados de sitios accesibles. Está en marcha desde julio y yo me acabo de enterar y aunque sea tarde creo que se merece un post.

Tal y como ellos mismo lo describen (traducción libre, como siempre):

es un producto diseñado para identificar y priorizar resultados de búsqueda que son más faciles de usar por ciegos y usuarios con problemas visuales. El buscador normal de Google te ayuda a encontrar un conjunto de documentos que son más relevantes para tus tareas. El buscador accesible va un paso más allá ayudándote a encontrar las páginas más accesibles en tu conjunto de resultados

El maremagnun de información hace que noticias tan importantes como esta se le escapen a uno.