Interesante lo que nos trae hoy GUUI – The Interaction Designer’s Coffee Break (un sitio que, si te gusta el diseño de interfaces, de seguro conoces!). Se trata de 10 errores comunes de accesibilidad, o en otras palabras, aquellos típicos detalles que creemos que ayudan a la accesibilidad de un sitio, pero que al contrario sólo la entorpecen. Acá mi traducción, con mis humildes aportes:

1. Usar texto demasiado extensivo o explicativo en el atributo ALT de las imágenes. Este texto debiera se lo más conciso posible. Y ni hablar de ocupar ALT en imágenes decorativas… Las que, obviamente, cargaremos desde el CSS respectivo…
2. Usar texto aleatorio a modo de separación, como por ejemplo, barras verticales… Las cuales obviamente jamás se leerán de buena forma si no es en forma visual.
3. Utilizar texto descriptivo en los campos de un formulario. Al parecer, el famoso “ingrese su mail” no es necesario en los softwares de lectura de pantalla actuales. Si vamos a hacer esto, quizás sea más adecuado generar este texto mediante javascript y CSS.
4. Utilizar teclas de acceso para todo, que eventualmente pasen por encima de las teclas de acceso típicas de otros medios de visualización de contenido.
5. Usar resúmenes de tablas para todo. Lógicamente, si estamos utilizando tablas para diseñar, éstas no debieran contar con resumen… Aunque claro, digamos que esto hace rato ya que es obsoleto!
6. Escribir como si fuera un libro. Recordemos que no necesariamente seremos leídos; esto me recuerda cuando en la universidad teníamos que escribir guiones de radio / televisión: lógicamente, los tiempos no son los mismos. Utiliza párrafos cortos, encabezados, palabras con énfasis, listas ordinales cuando corresponda… Y sin olvidar un lenguaje simple y claro.
7. Escribir páginas de ayuda sobre la accesibilidad del sitio. Vamos, ¿acaso alguien quiere leerse un manual para saber cómo acceder al comentario de la película de estreno?
8. Volverse loco definiendo acrónimos o abreviaciones. Está bien ser semánticos, pero muchos lectores de pantalla ni siquiera se enteran de las etiquetas correspondientes… Tal como se dijo, a veces es mejor recurrir al lenguaje simple y explicar -tal cual como se hace en periodismo- qué significa cada cosa en su primer uso.
9. Cambiar la lógica de seguimiento de “tabs”. Existen formas de hacerlo. La mayoría de las veces, ni siquiera es necesario… Y si lo es, ojalá que sea por una buena razón.
10. No escuchar con un lector de pantalla. Pruebe, pruebe! Es importante!

Interesante, no? A pesar que algunas directrices parezcan ir en contra de algunas normas de semántica… Pero si nos vamos al fondo de todo esto, ¿acaso el fin último no es el usuario?

Vía GUUI – The Interaction Designer’s Coffee Break, que lo obtuvieron vía Webcredible.

La vida es un círculo: en noviembre del 2006, realizando una evaluación de usabilidad para EntelPCS, decidí basar mi análisis heurístico en un clásico de clásicos, el paper Ten Usability Heuristics, del maestro Jakob Nielsen. En aquella ocasión, aprovechando algo de tiempo libre, me propuse traducirlo, mas mi procastinación sólo lo dejó a la mitad. Sin embargo, hoy retomé la tarea… Y justamente a causa de otra evaluación que estoy preparando para una empresa de retail…

En fin, con ustedes, Los 10 heurísticos de la usabilidad:

• Visibilidad del estado del sistema
  El sistema siempre debe mantener informado al usuario acerca de lo que está pasando, utilizando para ello un feedback adecuado y en un tiempo razonable.
• Concordancia entre el sistema y el mundo real
  El sistema debe hablar el lenguaje del usuario, con palabras, frases y conceptos familiares a él, más allá de los términos orientados al sistema. Se deben seguir las convenciones del mundo real, logrando que la información aparezca en un orden lógico y natural.
• Control y libertad del usuario
  Los usuarios escogen frecuentemente por error algunas funciones del sistema, y necesitan de una “salida de emergencia” claramente rotulada, de modo que puedan volver al estado anterior sin pasar por diálogos complejos o extensos. Mantenga y de soporte para Deshacer y Rehacer acciones.
• Consistencia y estándares
  Lo usuarios no deben lidiar con diferentes palabras, situaciones o acciones que signifiquen lo mismo. Siga las convenciones de la plataforma.
• Prevención de errores
  Aunque un mensaje de error bien diseñado es bueno, es mucho mejor cuidar el diseño y evitar los problemas. Intente eliminar las posibilidades de error, o bien determine cuáles serían y muéstrelas a los usuarios con una opción de confirmación antes que realicen la acción.
• Reconocimiento antes que llamadas
  Minimice la carga mnemotécnica del usuario entregando visibilidad a objetos, acciones y opciones. El usuario no tiene porqué recordar la información de un diálogo anterior en presencia de otro. Las instrucciones para el uso del sistema deben ser visibles o fácilmente accesibles cuando es necesario.
• Flexibilidad y eficiencia de uso
  Aceleradores, invisibles al usuario novato, deberían entregar rapidez en la interacción de los usuarios expertos, de tal modo que el sistema satisfaga a ambos. Permita a los usuarios automatizar acciones frecuentes.
• Diseño estético y minimalista
  Los diálogos no deben contener información que sea irrelevante o raramente necesitada. Cada bit extra de información compite con aquella que es relevante, y disminuye su visibilidad relativa.
• Ayude a los usuarios a reconocer, diagnosticar y recuperarse de los errores
  Los mensajes de error deben ser expresados en un lenguaje natural, sin códigos específicos del sistema. Deben indicar con precisión el problema, e indicar en forma constructiva la posible solución.
• Ayuda y documentación
  Aunque se piense que lo mejor es que el sistema sea utilizable sin manuales ni guías de uso, siempre es necesario incluir algún tipo de ayuda y documentación. Al respecto, toda información proporcionada debe ser fácil de encontrar, enfocada en la tarea del usuario y listando los pasos concretos a realizar, y por sobre todo, no ser demasiado larga.