» accesibilidad

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 desactivando Javascript

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

Granada.org sin CSS

No veo nada…

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

Y este sello??

Sin palabras

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

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:

• 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?

Related Link: Hoteles Paris en Destinia.com, haga ya su reserva de hotel y no se quede sin plaza.

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).

[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.

[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.

[Via Oficina Española W3C y torresburriel] Y está bien que lo adviertan porque es una práctica cada vez más frecuente y extendida y está calando entre la comunidad de desarrollo que pasando un test automática se ha hecho una web accesible. Como explicó Enmanulle Gutiérrez en Alzado eso no tiene porqué ser así.

Claro que uno se queda muy tranquilo viendo que pasa el el test y no teniendo que aprender a manejar un lector de pantalla o haciendo un tedioso repaso manual de los distintos puntos de prioridad. También hay que reconocer que conseguir pasar uno de estos test es ya un avance pero que no vale ponerse el iconito para esto es necesaria la “revisión humana”.

Aprovecho para poner un vídeo (en inglés) emitido por la CBS que muestra como utiliza internet una persona ciega, las dificultades que se encuentra y algunos temas legales relacionados que mi escasa compresión del inglés me impide detallar.

El inMundo acaba de lanzar el rediseño de su site.

No soy experto en usabilidad por lo que no ahondaré en el tema, pero a primera vista no parece que hayan mejorado mucho en ese aspecto y en Cadius lista de correo de profesionales de la usabilidad comienzan a arreciar las críticas.

Lo primero que veo es que está optimizado para 1024… a 800 no encaja demasiado bien. Todavía hay un buen porcentaje de gente con 800×600 (por las estadísticas de mis sitios entre el 15 el 20%). Ellos sabrán
La navegación por categorías… en la zona de cabecera… bueno ya no les caben más elementos. ¿Pero es que no leen el New York Times? a ver si vamos aprendiendo. ¿no es mucho más interesante para el usuario un enlace a “lo más popular” que el de “internacional”?

Un detalle interesante. El buscador, elemento básico donde los haya, permite buscar en Google y dentro del periódico; por defecto está seleccionado buscar en Google!! pero vamos a ver, señores/as, para buscar en internet una usuario no irá directamtente a Google y, en todo caso, no debería buscar por defecto dentro del periódico y como opción secundaria (en mi opinión absurda), buscar en Google?.

¿Estándarés? decenas de errores para XHTML 1.0 transicional… ¿Para que ponen ese doctype?

• Muchas etiquetas sin cerrar
• sintaxis deficiente.
• Imágenes sin atributo alt a porrillo.
• Javascript no va en Cdata
• Uso continuo de entidades de código no admitidas

Accesibilidad: escasa… las WAI por el forro, desde luego. Las descripciones alternativas de los contenidos que no son texto brillan por su ausencia. Curiosamente ponen a disposición del usuario una herramienta muy interesante, Rosa, que lee la noticia y permite tanto oirla on-line como descargarla en Mp3. Contando con esa tecnología ¿tanto costaría hacer una versión accesible basada en ese sistema de lectura?

Seguramente han echado una pasta en el rediseño y opino que con un poco de más ciudado podrían haber cubierto mucho mejor aspectos como la utilización de estándares, accesibilidad del contenido y mejoras de la usabilidad.

Durante este fin de semana he tenido la oportunidad de asistir al curso de Usabilidad que, a modo de gira, está impartiendo Eduardo Manchón.

Se ha hablado bastante de este curso en otros sitios (como siempre Torres Burriel se adelanta) y no voy a ahondar en el contenido sino hacer algunas reflexiones personales.

Comienzo recomendado a quien esté interesado en el tema que se apunte (se impartirá proximamente en Sevilla, Barcelona y Madrid). Con un enfoque básico y práctico el curso permite que nos adentremos en el mundo de la usabilidad y, gracias al conocimiento que Eduardo tiene del tema, adquirir una idea bastante clara del enfoque con el que debe analizarse la usabilidad de un sitio web. Durante el curso se vén las técnicas más importantes mezclando perfectamente teoría y práctica (incluso con usuarios reales!).

Además, al tratarse de un curso con pocas plazas el enfoque es muy personalizado y realmente se adapta perfectamente al nivel y necesidades de los asistentes. No solo eso, Edudardo no viene a dar su charlita y largarse si no que hace un magnífico trabajo docente ayudando a cada uno de los asistentes e incluso haciendo recomendaciones a los proyectos de cada uno ya que éstos pueden usarse como material práctico durante las clases.

Aunque se declara seguir de Jacobo Nielsen, Eduardo tiene un enfoque mucho más pragmático y abierto que sabe transmitir a los alumnos.

Y pese el temario en sí me ha aprotado muchísimo para poder empezar a evaluar usabilidad es quizás su perspectiva lo que considero que más me ha aportado en este curso. No se trata de ser un talibán anti-diseño sino más bien el plantearse si los elementos de un sitio web sirven para cumplir los objetivos del mismo. Y no se trata de criticar por criticar sino de analizar con diversas técnicas si estos elementos permiten al usuario cumplir sus objetivos cuando navega por un sitio; se analiza en base a unos criterios objetivos y además comprobarlo con usuarios reales.

Además de dar el temario, Manchón tiene una actitud muy positiva a la hora de ayudar y aconsejar a cualquiera de los asistentes en cualquier cosa aunque no tenga una relación directa con el curso.

Respecto al curso en sí (y no quería entrar en el tema), los test de usuario con usuarios reales!! son espectaculares y dan resultados sorprendentes, utilizando la terminología del profe… resultan “evangelizadores”. Además se apreden las técnicas de evaluación heurística y de card sorting que son de gran ayuda a cualquier desarrollador web.

No me extiendo más… y vuelvo a recomendar el curso a todo desarrollador web esté o no directamente interesado en la Usabilidad. Espero escribir otro post sobre la usabilidad en sí, lo que supone y reflexiones sobre sus técnicas.

El artículo de 456bereastreet para evaluar accesibilidad más que un artículo se trata de un auténtico manual. Genial.

Agrupado en los tres puntos que ya comentan en blog posible:

• Evaluating website accessibility part 1, Background and Preparation
• Evaluating website accessibility part 2, Basic Checkpoints
• Evaluating website accessibility part 3, Digging Deeper

Desarrollan mucho cada uno de esos puntos dando información y herramientas para evaluar la accesibilidad de los sitios que desarrollemos.