En la foto de la derecha, lo tienen mi tío – con su celular touch – intentando (por tercera vez) tocar un área sin seleccionar por error la de al lado.

Diseñar para el error. Diseñar para el usuario ;)

Fuimos con Andrea Cantú y Natalia Vivas a una conferencia de diseño de interacción y salimos indignadas. Sí, mujeres de UX indignadas.

Las frases en el almuerzo fueron:

• “Hacen arte digital, no hacen diseño de interacción”.
• “No hay profesionales que tengan al usuario en la cabeza”.
• “No hay mediciones”.
• “¿Dónde se analizan los movimientos del usuario?

La diferencia es atroz.

• En una animación el usuario experimenta una sensación de movimiento por imágenes o dibujos que cambian más rápido que lo que sus ojos pueden percibir.
• En una interacción el usuario interviene y controla.

Como dicen las Directrices de Accesibilidad del Contenido Web 2.0, todos los elementos de la interfaz presentes en el contenido deben ser operables por el usuario.

Diferencia total si las hay: arte vs. diseño de interacción con el usuario.

Un sitio es accesible cuando le permite a la mayor cantidad de usuarios, acceder a sus contenidos (textos, imágenes, videos), independientemente de sus capacidades, físicas, intelectuales o tecnológicas.

Esto implica trabajar en pos de la inclusión. Este principio hará que cuando nosotros mismos seamos ancianos y discapacitados, no nos dejen exhiliados.

¿A quiénes beneficia?

• Incluye a los que no ven: ¿Cómo navega Internet un no vidente? Existen lectores de pantalla, que van leyendo en “voz alta” a medida que los usuarios utilizan su computadora. Para que estos lectores funcionen correctamente, los diseñadores web debemos tener en cuenta algunos detalles al momento de programar. Por ejemplo, cuando maquetamos en HTML, tenemos que incluirle a las imágenes el atributo ALT (texto alternativo) explicando de qué se trata la imagen; para que los lectores puedan leerlo y no se queden sin poder interpretar de qué se trata.
• Incluye a quienes tienen problemas visuales: Si el tamaño del texto es lo suficientemente grande (o ampliable sin que se desarme el diseño), los usuarios con problemas visuales podrán leerlo sin dificultad.
• Incluye a los que no oyen (¡o no tienen parlantes!): Si a los vídeos les incorporamos subtítulos o ponemos a disposición el texto transcrito, los usuarios con dificultades auditivas podrán acceder a la información. Lo mismo sucede si no tenemos parlantes.
• Incluye a los que tienen problemas motrices: Si el tamaño de los botones es grande y cómodo, facilita a los usuarios que no pueden controlar el mouse con precisión.
• Incluye a los que tienen problemas de aprendizaje: Si los contenidos están escritos en un lenguaje sencillo e ilustrados con diagramas, los usuarios con problemas de aprendizaje estarán en mejores condiciones de entenderlos.
• Incluye a los que tienen conexión a Internet lenta: Las conexiones lentas provocan que algunos usuarios desactiven las imágenes y elementos multimedia para reducir el tiempo de descarga de las páginas web. Debemos generar los contenidos teniendo en cuenta estas posibilidades.
• Incluye a los más modernos: quienes navegan desde su celular.

En mi país, Argentina, el 03 de noviembre de 2010 fue aprobada por unanimidad la ley de Accesibilidad de la Información en las Páginas Web.

En su primer artículo, refiriéndose a los sitios gubernamentales o subsidiados por el Estado, expresa:

“… deberán respetar en los diseños de sus páginas Web, las normas y requisitos sobre accesibilidad de la información que faciliten el acceso a sus contenidos, a todas las personas con discapacidad con el objeto de garantizarles la igualdad real de oportunidades y trato, evitando así todo tipo de discriminación”.

Al respecto, expresó un legislador: “Ley de accesibilidad web para todos: otro avance en la igualdad de derechos”.

El objetivo era verificar que sus sitios fueran comprensibles, perceptibles, operables y compatibles y que estuvieran pensados y diseñados en función de las tareas que los usuarios debían efectuar.

El inconveniente surgió cuando algunos proveedores comenzaron a negarse a hacer modificaciones, dado que estas exigencias no formaban parte de los requerimientos de las licitaciones.

De este modo, surgió la idea de desarrollar una normativa que los instara a hacerlo. Para esto, tuve el privilegio de ser corregida y aconsejada por Martín Baldassarre, Enrique Stanziola, Juan Lanús, Santiago Bustelo, Eduardo Mercovich, Gonzalo Auza, Guillermo Ermel, Celeste Oliveri,  José Allona, Juan Manuel Carraro y Mariano Goren, quien generó rápidamente un encuentro a través de IXDA para sumar aportes.

También se contactaron conmigo Mario Carvajal y Juan Saab Vanegas de Colombia, para enviarme como referencia la leyes de su país.

La normativa fue aprobada por el Secretario de Comunicación Social Gregorio Centurión y se estableció dentro de la Resolución 76/SCS/10 que fue publicada en el boletín oficial del GCBA el día 04/05/2010. La misma hace referencia al texto detallado debajo,  que ya se encuentra en la Intranet de la Agencia de Sistemas de Información del GCBA, disponible para los proveedores:

Normativa de Accesibilidad y Usabilidad Web

1. Ámbito de Aplicación.

Las disposiciones a las cuales se refiere la presente resolución, son de obligatorio cumplimiento para todos los sitios web pertenecientes al Gobierno de la Ciudad Autónoma de Buenos Aires.

2. Objetivos:

Los objetivos de la presente resolución son:

2.1. Garantizar un acceso equitativo a la información.

2.2. Contribuir con la construcción de un Gobierno que preste mejores servicios a los ciudadanos, facilitando a los usuarios el alcancen a sus objetivos con eficacia y satisfacción a través de la optimización de las tecnologías de información y comunicación.

3. Definiciones de usabilidad y accesibilidad web:

Un sitio web es accesible cuando sus contenidos son perceptibles, comprensibles y operables para todo tipo de usuarios, independientemente de sus capacidades, tipo y dispositivo de acceso a internet, sistema operativo y/o programas utilizados

La usabilidad es una medida empírica que califica que tan fácil, rápido y agradable es un sitio web para un cierto tipo de usuario, con determinado tareas y contexto de uso.

4. Definición de políticas y estándares de accesibilidad:

El Consorcio W3, organismo internacional encargado de crear y supervisar los estándares en la Web, ha publicado una serie de pautas denominadas Directrices¹ de Accesibilidad del Contenido Web 2.0. (Versión en inglés Web Content Accessibility Guidelines WCAG – 2.0: http://www.w3.org/TR/WCAG20/#guidelines. Traducción recomendada (aunque no oficial) en español: http://www.sidar.org/traducciones/wcag20/es/), las cuales son aceptadas internacionalmente.

Las Pautas se organizan en cuatro principios básicos que constituyen su base filosófica (perceptible, operable, comprensible y compatible). Las mismas se encuentran clasificadas por niveles de conformidad (A, AA, AAA).

Las aplicaciones y sitios web pertenecientes a los organismos mencionados, creados a partir de abril de 2010 deberán alcanzar el nivel de conformidad AA, aunque se sugiere a los responsables, que traten de llegar al nivel de conformidad AAA.

Las aplicaciones que ya se encuentran en vigencia deberán adoptar dichas pautas a lo largo de un período de dos años a partir del momento en que la presente resolución entre en vigencia.

Para verificar este aspecto se deberán utilizar como referencia las herramientas de validación descriptas en la de Guía de Usabilidad y Accesibilidad Web detallada debajo.

5. Adopción de una Guía de Usabilidad y Accesibilidad Web:

El Área de Usabilidad y Accesibilidad Web creará una Guía para los desarrolladores. La misma deberá ser solicitada al inicio de cada proyecto.

Debido a la dinámica propia de las tecnologías de comunicación, la información de esta Guía, podrá actualizarse periódicamente. Para cada proyecto se establecerá cuál es la versión de los lineamientos a aplicar. Los mismos serán de obligatorio cumplimiento por parte de las entidades a las cuales se refiere la presente resolución.

Documentos para descargar:

Normativa de Usabilidad y Accesibilidad Web (pdf)

Guía Web – Primera Versión (pdf)

Con el fin de que nuestros Sitios sean perceptibles, comprensibles, compatibles y operables generamos este listado de verificación para maquetadores (para seguir revisando!).

• HTML Y CSS

1. ¿Las etiquetas utilizadas son sintácticamente correctas?
2. ¿Están íntegramente independizados los estilos a través de CSS?
3. ¿El uso de tablas se restringe a la tabulación de datos y no para diagramar el contenido del Sitio Web?
4. ¿Se puede navegar el Sitio íntegramente (incluyendo objetos incrustados) a través de un teclado?

• Compatibilidad con Navegadores

1. ¿El Sitio es compatible con el navegador Internet Explorer 6?
2. ¿El Sitio es compatible con el navegador Internet Explorer 7?
3. ¿El Sitio es compatible con el navegador Internet Explorer 8?
4. ¿El Sitio es compatible con el navegador Mozilla Firefox?
5. ¿El Sitio es compatible con el navegador Safari?
6. ¿El sitio es compatible con un lector de pantalla como JAWS o NVDA?

• Identificación del lenguaje:

1. El lenguaje está identificado de esta forma: <HTML lang=”es”>
2. Las abreviaturas se encuentran señaladas con el atributo <abbr>? (Ejemplo “Alte”: <abbr title=”Almirante”>Alte.</abbr>)
3. Las abreviaturas se encuentran restringida a las definidas por la Real Academia Española (Evitando por ejemplo “ascend.” para decir “ascendente”)
4. ¿Los acrónimos se encuentran señalados con el atributo <acronym>? Ejemplo: “GCBA”: <acronym title=”Gobierno de la Ciudad de Buenos Aires”> GCBA </acronym>)
5. ¿Las etiquetas <abbr> y <acronym> han sido utilizadas exclusivamente para su función y no para mostrar como “tooltip” información adicional de otra naturaleza? (Ejemplo de mala práctica: <acronym title=”Founded in 2006″>  Twitter </acronym>)

• Imágenes y animaciones:

1. ¿Todas las imágenes y animaciones cuentan con un texto alternativo?
2. ¿Los textos alternativos representan una alternativa válida para transmitir la misma información que comunica el formato no textual? (NOTA: Quien elabore el contenido debe proveer el texto alternativo para las imágenes informativas, de forma que el programador pueda incluirlas) Ejemplos: El texto alternativo de un banner debe incluir la descripción de los objetos y/o textos que figuren en la imagen. No debe decir “banner”.El texto alternativo de una flecha (botón) debe decir “siguiente” o “volver”. No debe decir “flecha”.
3. ¿Todas las animaciones pueden ser controladas (pausadas) por el usuario?

• Multimedia:

1. ¿Los audiovisuales o archivos de audio se encuentran subtitulados o incluyen el texto en un archivo tipo HTML u opciones Word o PDF accesible?
2. ¿La voz principal se distingue con facilidad del sonido ambiente?

• PDF:

1. ¿Los documentos PDF pueden ser interpretados por un lector de pantallas para no videntes? (Validar con un lector de pantallas Ejemplo NVDA )
2. Las imágenes del PDF ¿cuentan con un texto alternativo?
3. Si un documento PDF no fuera accesible, ¿existe una versión alternativa accesible en Word o HTML?
4. ¿Todos los enlaces se encuentran acompañados con el ícono identificativo de Adobe PDF?
5. ¿Todos los enlaces PDF abren en una nueva ventana?

• Formularios: Carteles de error:

1. ¿Evitan el lenguaje técnico, utilizando un lenguaje claro y comprensible por los usuarios?
2. ¿Señalan claramente el campo en cuestión (no basándose sólo en el color, sino, acompañándolo también de un icono)?

• Enlaces

1. ¿El Sitio es navegable con JavaScript desactivado?
2. ¿Se encuentran los menúes (horizontales y verticales) armados con listas OL o UL?
3. ¿Se encuentran todas las rutas verificadas de tal modo que ninguna lleve a una ruta equivocada o inexistente?

• Validadores:

1. W3C
2. SIDAR
3. Accesibilidad.com
4. Lector de Pantallas NVDA

ver Checklist de accesibilidad para el área de diseño

Este checklist fue una idea que Santiago Bustelo propuso al GCBA para verificar los diseños antes de ser subidos a producción.
También fue debatido en los foros Acceso Web e IXDA.

Con el fin de que nuestros diseños sean perceptibles y comprensibles, generamos este listado de verificación (para seguir revisando!).

• Sobre la navegación:

1. En caso de contar con sub-secciones ¿Incluye Mapa de Sitio o Tabla de Contenidos?
2. ¿Los elementos comunes están localizados en la misma posición en todas las pantallas?
3. ¿Los elementos interactivos se comportan de la misma forma todas las veces que aparecen?

• Sobre los textos:

1. ¿Se distingue el color de los textos de su color de fondo?
2. ¿El tamaño de las tipografías no es de menor que 10px? (*)

• Sobre los enlaces:

1. ¿Se diferencian los enlaces del resto de los textos por su color, subrayado u otra característica?
2. ¿Cuentan todos los links – ya sean textos, botones o íconos – con estado Roll Over?
   (Se satisface con el atributo de CSS a:hover)
3. ¿Queda señalada la solapa (botón/link) dónde se encuentra el usuario?
4. ¿Los textos de los enlaces son lo suficientemente explícitos en su destino?
5. ¿No existen hipervínculos distinguidos con las frases “click aquí” o “+ info”?

• Sobre los colores:

1. ¿La información transmitida a través de los colores también está disponible sin color?

Validadores:

Validador de color SIDAR
Descargar aplicación de Paciello Group para validar contrastes de colores.

ver Checklist de accesibilidad para el área de maquetación

Este checklist fue una idea que Santiago Bustelo propuso al GCBA para verificar los diseños antes de ser subidos a producción.
También fue debatido en los foros Acceso Web e IXDA.

(*) Corregido posterior

Este problema alcanza aproximadamente al 8% de los hombres y el 1% de las mujeres de la población mundial.

El inconveniente surge cuando utilizamos el color como único indicador para diferenciar elementos o transmitir información.

Detalles para tener en cuenta:

1.     Contraste de fondos y textos:

El contraste es lo más importante para un daltónico.

• La mejor opción es utilizar letras negras sobre fondo blanco.
• Los fondos azules, verdes y rojos disminuyen la legibilidad.
• Las tipografías celestes o grises claras aumentan el stress óptico.

2.     Links bien diferenciados:

• Es recomendable marcar los enlaces de alguna forma que no dependa del color, por ejemplo con subrayados, cursiva, negrita… etc

3. Íconos:

• Es conveniente utilizar iconos que describan acciones, en lugar de modificar sus colores para comunicar su estado.
• Y funciona de refuerzo incluirle a cada uno una leyenda explicativa en un tooltip.

4.     Formularios:

El mecanismo más utilizado para comunicar que un campo está incompleto es añadir un texto de aviso con letras rojas.

• Una buena solución sería incluir alguna forma de identificación o un simple asterisco junto a los campos obligatorios.

5. Gráficos de información:

Los gráficos que distinguen las distintas líneas de información sólo a través de los colores, son imposibles de interpretar.

• Una solución es incorporar una leyenda junto a cada línea.
• O también emplear distintas formas de trazado.

Lo importante es complementar el color de distintas formas.

Herramienta de verificación:

Para probar como se ve un diseño, les recomiendo un Sitio donde ingresando la Web se puede observar cómo se visualiza con distintos grados de daltonismo: Coblis — Color Blindness Simulator