Quantcast
Channel: Usable y accesible. Olga Carreras
Viewing all 180 articles
Browse latest View live

Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.

$
0
0

Índice

Responsive Design. ¿Qué es?

Responsive Web Design (RWD) o en español diseño web adaptable, es una técnica de diseño y desarrollo de sitios y aplicaciones web que permite que las páginas se adapten al tamaño, la resolución y orientación de la pantalla, y por tanto al dispositivo del usuario. Y todo ello con un código único, una única página, una única URL.

Tenéis 50 ejemplos de Responsive Web Design en el artículo “Responsive Web Design: 50 Examples and Best Practices”, designmodo.com, octubre 2011

No necesitas realmente visualizar estas páginas en diferentes dispositivos para comprobar que son Responsive Web Design, basta con que las visualices desde tu escritorio y redimensiones la pantalla del navegador. Según el tamaño de la pantalla verás que el diseño, la navegación, el contenido y las imágenes se reconfiguran automáticamente.

También puedes cambiar la resolución de pantalla, selecciona una resolución baja y podrás ver la visualización de la web para esa resolución.

A medida que hacemos la pantalla más pequeña o bajamos la resolución, pasamos por ejemplo de una layout de 3 columnas a uno de 2 y finalmente a un layout de una columna. Las imágenes se hacen más pequeñas para adaptarse al espacio disponible o el sistema de navegación se modifica.

Podéis consultar el artículo de Juan Carlos Mejía [MEJIA, 2012] donde incluye varios vídeos que ilustran todo ello con claridad.

Responsive Design. ¿Cómo se hace?

Esta flexibilidad se consigue mediante el uso de un código HTML único pero que se presenta de manera diferente gracias a:

  • La separación entre el contenido y la presentación: todos los estilos están definidos en las CSS.
  • Layouts basados en grids: la información se organiza en ejes verticales y horizontales. Tendremos definidos diferentes layouts en diferentes CSS, por ejemplo uno de 3 columnas, uno de 2 columnas y uno de 1 columna.

    Tres esquemas de una web. El esquema a tres columnas se verá en resoluciones de escritorio. La versión a dos columnas en tablets, y la versión a una columna en móviles.

    Imagen de boatboatool.com

  • Fluids Grids, es decir, el uso de medidas relativas que permitan que el contenido se pueda adaptar realmente como se ve en la imagen anterior. Permite utilizar todo el espacio disponible y evitar el desplazamiento horizontal.
  • Media Queries, permite cargar dinámicamente las diferentes CSS que hemos definido en función del tamaño de pantalla, su resolución o su orientación.

    <link rel="stylesheet" type="text/css" href="style2col.css" media="all and (min-width: 400px) and (max-width: 800px)" />

    En este ejemplo se especifica la CSS a utilizar (layout de 2 columnas) con un viewport (la parte de pantalla donde se representa el documento)de una anchura entre 400px y 800px.

    Media Queries son recomendación del W3C desde junio de 2012.

    En la bibliografía, al final del artículo, tienes algunos artículos relacionados con la resolución y tamaño de los diferentes dispositivos y cómo aplicar Media Queries: [CHELARIU, 2013], [CARRERAS, 2014], [ANDROID], [PRIETO, 2014]

  • Configuración del meta viewport: mediante este meta indicamos que nuestra web es flexible para adaptarse a los diferentes anchos y resoluciones de pantallas, le indicamos al navegador que no aumente o reduzca la página, que use el zoom por defecto.

    <meta name="viewport" content="width=device-width,initial-scale=1.0" />

    Con el uso combinado de Media Queries y la definición del viewport evitamos que nuestra web se vea en miniatura en un dispositivo móvil, que tengamos que hacer zoom y después tener que desplazarnos porque el contenido ocupa más que el ancho de pantalla. Por el contrario, ahora se verá a tamaño real y ajustado a todo el ancho.

    Más adelante veremos cómo, sin embargo, es importante desde un punto de vista de accesibilidad no impedir que el usuario pueda hacer zoom si lo desea. Indicaré cómo evitar una incorrecta configuración del viewport.

  • Imágenes y vídeos de tamaño flexible, que también se adapten al espacio disponible. Se puede conseguir de diferentes maneras, cada una con sus ventajas e inconvenientes. Más adelante hablaré de cómo algunas de ellas tienen implicaciones en la accesibilidad de la página.

    En el caso de los vídeos podemos usar HTML5 y el elemento VIDEO con diferentes sources según la resolución. Tenéis un ejemplo en el artículo de Ian Devlin [DEVLIN, 2012]

    En el caso de las imágenes no es tan sencillo, por ello hay voces pidiendo un atributo srcset para el elemento IMG o un elemento PICTURE con diferentes sources como el elemento VIDEO [W3C_GROUP(b), 2012]

    A falta de estas opciones, se suelen utilizar las siguientes técnicas:

    • La imagen se define como fondo de un elemento en las CSS (background-image) Se tienen diferentes versiones de la imagen a diferentes tamaños, en cada CSS se carga una de ellas. Veremos que aunque es más óptimo para aligerar el peso de las páginas, puede suponer un problema grave de accesibilidad si las imágenes así definidas no son decorativas sino informativas.
    • La imagen se incluye en el código HTML con el elemento IMG pero se define su anchura y altura en las diferentes CSS. El gran inconveniente es que aunque muestras la imagen a diferente tamaño en realidad se carga siempre la de mayor peso.
    • Otras opciones que ya no son propiamente Responsive Design son detectar el dispositivo en el servidor para servir las diferentes versiones de la imagen según el dispositivo, o usar javascript, cookies [W3C_GROUP, 2012].

En cuanto a la metodología de trabajo es muy importante tener ya presente, no solo en la etapa de diseño, sino también en la conceptualización y prototipado, cómo será el sitio en función del tamaño de pantalla.

Desde 2009 Luke Wroblewski viene defendiendo un enfoque Mobile First, basado en el principio de Mejora Progresiva. Pensar primero en la versión móvil y después ir añadiendo complejidad mediante Media Queries, que serán ignoradas por los navegadores que no las soporten. Este enfoque, dada las limitaciones de las pantallas pequeñas, te permite centrarte en las necesidades reales de los usuarios, priorizar las tareas claves:

Los dispositivos móviles requieren que los equipos de desarrollo de software se centren únicamente en los contenidos y en las acciones más importantes de la aplicación. Simplemente no hay espacio en una pantalla de 320x480px para los elementos innecesarios. Hay que priorizar.

Así que, cuando un equipo diseña primero para el móvil, el resultado final es una experiencia centrada en las tareas clave que los usuarios quieren lograr, sin distracciones […] Eso es bueno para la experiencia de usuario y bueno para los negocios.

[WROBLEWSKI, 2009]

Para ampliar cómo se aplica técnicamente Mobile First, cómo se define primero la CSS para los tamaños de pantalla más pequeños impidiendo que esta sea la que se cargue en versiones anteriores a IE9, se puede leer el artículo de Ricardo Prieto [PRIETO, 2014].

Relación entre Responsive Design y accesibilidad

Un sitio desarrollado con la técnica Responsive Design no implica que dicho sitio vaya a ser accesible y a cumplir con las pautas de accesibilidad [WCAG2, 2008], sin embargo es un gran punto de partida.

Ambos parten de un enfoque o filosofía similar: defienden una web única, que los sitios sean flexible, independientes del dispositivo y a disposición de todos los usuarios.

Hay ciertos requisitos de accesibilidad a nivel de código que tienen gran impacto en la accesibilidad de las páginas y que deben tenerse en cuenta desde el comienzo del desarrollo, pues son muy costosos de corregir a posteriori: el uso de estándares, la separación entre el contenido y la presentación, el uso de medidas relativas, evitar las tablas para maquetar o la definición de jerarquías de información estructuradas correctamente.

Como hemos visto, un sitio Responsive Design cumple per se con muchos de estos requisitos.

Por otra parte, también hemos comentado que la metodología Mobile First va más allá de la mera adaptación del sitio al tamaño de pantalla. Ahora, cada pieza de información, cada enlace, debe ganarse su lugar. Esto ayuda a priorizar contenidos y funcionalidades eliminado lo innecesario: las páginas son más cortas y sencillas y la navegación más racional. Como resultado tendremos sitios más fáciles de navegar y entender, con menor carga cognitiva y visual.

Como defiende Luke Wroblewski [WROBLEWSKI, 2010] la metodología Mobile First para Responsive Design ayuda a que las páginas sean más accesibles. Favorece a todos los usuarios, pero sin duda especialmente a los usuarios con discapacidad cognitiva, a los usuarios que utilizan lectores de pantalla o a los usuarios que tienen una discapacidad motora y utilizan dispositivos de entrada alternativos.

Concretando, ¿cómo puede favorecer a la accesibilidad de un sitio que este sea Responsive Design?

  • El contenido y la presentación están separados, los estilos están definidos en las CSS y no se usan tablas para maquetar. Todo ello beneficia a las personas con diferentes discapacidades al permitir a los agentes de usuario adaptar el contenido de acuerdo a sus necesidades (criterio de conformidad 1.3.1, [WCAG2, 2008])
  • Tendencia a un mayor respeto por los estándares web, lo cual maximizará la compatibilidad con las aplicaciones de usuario actuales y futuras, incluyendo las ayudas técnicas (pauta 4.1, [WCAG2, 2008])
  • Tendencia a tener la información estructurada y jerarquizada más correctamente (criterio de conformidad 1.3.1, [WCAG2, 2008])
  • Tendencia al uso de elementos semánticos para poder definir sus estilos en las CSS. Indicar explícitamente la función estructural o valor semántico del contenido permitirá que esta información se pueda determinar mediante software favoreciendo la accesibilidad (criterio de conformidad 1.3.1, [WCAG2, 2008])
  • El diseño flexible y la definición de tamaños relativos permiten que el texto se pueda ampliar sin desbordamientos y hacer zoom con garantías (criterio de conformidad 1.4.4, [WCAG2, 2008])
    • El tamaño flexible de las imágenes y vídeos permitirá que se adapten mejor al espacio disponible para ellas sin que se superpongan con otros contenidos.
    • Mejor experiencia para los usuarios con baja visión que suelen tener resoluciones de pantalla más bajas y suelen ampliar la pantalla.
  • Además, el diseño flexible y que no se usen tablas para maquetar ayuda a garantizar un orden de lectura correcto. Los diseños fluidos tienden a presentar el contenido en el mismo orden que el DOM y este es el mismo orden en que, por ejemplo, los lectores de pantalla presentarán el contenido (criterio de conformidad 1.3.2, [WCAG2, 2008])
  • Se tiene muy presente que el sitio se visualizará en distintos dispositivos y por tanto:
    • Es más probable que tu sitio no sea operable solo con el ratón, la forma de interactuar ahora es muy variable y esto ayuda al diseño inclusivo (principio Operable, [WCAG2, 2008])
    • Es más probable que mejores el contraste de color, que suele ser más pobre en los dispositivos móviles, más dados a tener bajo contraste para ahorrar batería además de que son habituales los reflejos en la pantalla (criterios de conformidad 1.4.3 y 1.4.6, [WCAG2, 2008])
    • Mayor uso de la técnica Progressive Enhancement (Mejora Progresiva) que consiste en una implementación básica, que funciona a través de múltiples dispositivos y con una amplia gama de tecnologías de asistencia, añadiendo después más funcionalidades para los dispositivos que las soportan.
  • Focalizarse solo en lo necesario, priorizar y simplificar, dará como resultado sitios más fáciles de navegar y entender, con menor carga cognitiva y visual, mejorando la legibilidad y la accesibilidad.
    • Mayor uso de la técnica de Progressive Disclosure (Revelación Progresiva), que se basa es diferenciar el contenido primario del secundario. El contenido primario aparece inmediatamente en el flujo normal de la página y es muy visible. El objetivo es mostrar solo lo relevante para el usuario en este momento. Nos beneficia a todos, pero especialmente a los usuarios con discapacidad cognitiva o con déficit de atención, y bien hecho facilita la navegación a los usuarios de lectores de pantalla o a las personas con discapacidad motora.

No es oro todo lo que reluce

Si terminará el artículo aquí podría parecer que Responsive Design es la panacea para la accesibilidad, pero no es así. La mayoría de las veces los desarrollos no cumplen con todos los puntos enumerados anteriormente. También nos encontramos con problemas recurrentes y malas prácticas que suponen barreras de accesibilidad en los desarrollos Progresive Design.

A continuación el artículo se centra en dichos problemas.

Primera norma de accesibilidad para Responsive Design

Como hemos visto, la accesibilidad no tiene por qué verse afecta en un sitio Responsive Design, sino que por lo general suelen cumplir con ciertos requisitos de accesibilidad y ser una buena base para comenzar a trabajarla.

Sin embargo no siempre es así y habrá ciertas cosas a tener en cuenta, porque nos encontramos con problemas recurrentes y extendidas malas prácticas.

La primera norma, y más importante, es que habrá que comprobar la accesibilidad en las diferentes resoluciones establecidas mediante Media Query.

Puede parecer una tontería, puesto que hemos dicho que la página es la misma y que simplemente se cargan distintas CSS, pero no lo es.

Muchas veces se ocultan contenidos en las versiones para tamaños de pantalla más pequeños. Para que determinado contenido no se muestre, a veces lo ocultan con estilos definidos en la CSS para las resoluciones más bajas. Otras veces se hace detectando el dispositivo desde el servidor o por javascript. Todo eso no es Responsive Design, pero son prácticas habituales que, mal hechas, suelen generar problemas de accesibilidad.

A continuación voy a poner 5 típicos ejemplos de errores de accesibilidad que NO encontramos cuando accedemos a la página con el mayor tamaño o resolución definido y SÍ encontramos cuando reducimos la resolución o el tamaño de pantalla, y que son consecuencia de la ocultación de contenido mal implementado o sin medir sus consecuencias.

1. Los encabezados ya no tienen una jerarquía correcta

Hemos dicho que no solo se adapta la visualización sino también a menudo el contenido, eliminando zonas de información en las versiones con resoluciones menores. Cuando cierto contenido desaparece la jerarquía de encabezados puede verse comprometida.

Veamos la página Mashable.

Tenemos un encabezado H1 con el logo, un H2 con la categoría “Tech” y un H3 “Media Trends 2013” (en realidad en la página se saltan un nivel y “Media Trends 2013” es H4, pero vamos a imaginarnos que lo hubieran hecho bien porque para el ejemplo es indiferente)

Parte superior de la página Mashable. El logo es H1, la categoría en H2, el título de la primera zona de contenido es H3

Encabezados de Mashable a una resolución alta

En la imagen que sigue, vemos la misma página al tamaño más reducido de pantalla. El contenido se ha simplificado. Se ha eliminado el H2 “Tech” (tanto visualmente como para los usuarios de lectores de pantalla) junto con la barra de redes sociales. Como consecuencia, tras el H1, nos encontramos con un H3. La jerarquía de encabezados ya no es consistente y esto dificulta ojear el documento cuando accedes con el lector de pantalla.

Parte superior de la página Mashable en resoluciones bajas. El logo es H1, el título de la primera zona de contenido es H3

Encabezados de Mashable a una resolución baja

2. Enlaces para saltar el contenido que ahora solo crean ruido

Estamos en un caso similar al anterior. Si has eliminado o simplificado contenido debes comprobar que los enlaces para saltar contenido ahora tienen sentido, o si simplificada la página, estos solo crean ruido. Lo mismo puede ocurrir con otros elementos, como los WAI ARIA landmarks.

Hay un artículo de Henney Swan [SWAN (b), 2012] que habla sobre los enlaces de saltar contenido en Responsive Design.

3. El contenido se oculta de forma inadecuada

En el caso de que estemos ocultando contenido en las CSS es importante comprobar cómo se está ocultando.

En el artículo "Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página" explicaba las diferentes técnicas para ocultar contenido. En función de cómo lo ocultes, el contenido estará también oculto o no para los lectores de pantalla:

  • Display:none o visibility:hidden, el contenido tampoco estará disponible para los lectores de pantalla.
  • Text-indent:-9999 o la ocultación mediante clip, el contenido sí estará disponible para los lectores de pantalla.

Si en la versión para tamaños de pantalla pequeños has ocultado contenido al usuario para simplificar la página, asegúrate de que también está oculto para los lectores de pantalla, de esta manera estarán en igualdad de condiciones.

Si ocultas unos contenidos con una técnica y otros con otra, sin ningún criterio, la página puede llegar a ser incomprensible para ellos.

En el apartado 4, sobre problemas en la navegación, veremos también un ejemplo de contenido mal oculto.

4. El menú de navegación ahora es diferente, ¿es accesible?

En las versiones para las menores resoluciones o tamaños de pantalla el menú suele convertirse hoy en día, casi un estándar de facto, en un icono con tres rayitas que se despliega.

Pasamos de tener un menú lineal y visible a un menú desplegable, y es por tanto importante asegurase de que la navegación sigue siendo accesible para todos los usuarios.

Los tres ejemplos que pongo a continuación están basados en la modificación de las CSS, el código HTML es el mismo para las dos visualizaciones.

Ejemplo 1: http://www.starbucks.com/

Sistema de navegación lineal: menú con 6 opciones visibles

Menú de navegación con resoluciones de pantallas mayores

Sistema de navegación colapsado bajo un icono. El menú se despliega al pulsar el icono mostrándose bajo el mismo.

Menú de navegación con resoluciones de pantallas menores

En la segunda versión, la versión para resoluciones de pantalla mas pequeñas, el lector de pantalla nos anuncia el icono “Enlace Navigation” (Icono para desplegar el menú), si lo seleccionamos nos anuncia “Lista con seis elementos” y podemos acceder a sus enlaces. Sin problemas.

Pero si después de que me anuncie “Enlace ‘Navigation’” yo decido seguir adelante sin pulsarlo… vaya, también me anuncia “Lista con seis elementos” y tengo la navegación aunque no la he solicitado. Resulta un tanto confuso. No la has ocultado correctamente.

Ejemplo 2: http://antocas.com/demos/menu-responsive-design/

Menú de navegación lineal con cuatro opciones de menú visibles

Menú de navegación con resoluciones de pantallas mayores

Menú de navegación colapsado bajo un icono. Cuando se pulsa el icono el menú se muestra encima del icono.

Menú de navegación con resoluciones de pantallas menores

En la segunda versión, la versión para resoluciones de pantalla mas pequeñas, el lector de pantalla me anuncia el icono “Enlace ‘Nav Menu’” (Icono para abrir el menú ) Si no lo pulso accedo al resto del contenido de la página correctamente, al contrario que en el ejemplo anterior. Sin embargo, cuando lo pulso… no consigo encontrar el supuesto menú desplegado. ¿Por qué? Porque el orden de lectura no es correcto. El código del menú está encima del código del icono. Tengo que adivinar que solo pulsando por ejemplo la flecha arriba conseguiré llegar a él.

Ejemplo 3: http://bradfrostweb.com/blog/web/complex-navigation-patterns-for-responsive-design/

Menú lineal con cinco opciones visibles

Menú de navegación con resoluciones de pantallas mayores

Menú colapsado bajo un enlace 'Menú' acompañado de una flecha. Cuando pulso el enlace el menú se despliega encima del enlace.

Menú de navegación con resoluciones de pantallas menores

En la segunda versión, la versión para resoluciones de pantalla mas pequeñas, el lector de pantalla nunca puede acceder al enlace “Menú”. Las opciones de menú las lee siempre al comienzo de la página como si estuviera en la navegación para escritorio, como si siempre estuvieran visibles, esté o no el menú colapsado. No se ha manejado correctamente la ocultación de los elementos.

5. Asegúrate de que el orden de lectura ahora también es correcto.

Un desarrollo responsive suele favorecer que el orden de lectura sea adecuado, pero cuando se empieza a ocultar contenido es importante asegurarse de que el orden de lectura sigue siendo correcto.

En el punto anterior ponía un ejemplo (ejemplo 2) de un orden de lectura incorrecto en un menú de navegación desplegable.

Otras consideraciones de accesibilidad a tener en cuenta

Hemos visto en el apartado anterior errores comunes relacionados con ocultar contenido en las versiones móviles de manera inadecuada o sin tener en cuenta las consecuencias para la accesibilidad de la página.

Ahora nos ocupamos a ver otras malas y buenas prácticas que hay que tener en cuenta.

Malas prácticas

Explico a continuación tres malas prácticas que hay que evitar.

Mala práctica 1: Tratar imágenes informativas como imágenes decorativas para cargar diferentes tamaños de imagen

Si incluyes las imágenes en el código y quieres mediante las CSS que se muestren a diferente tamaño, puedes definir su ancho y su alto en las diferentes CSS. El problema es que la imagen que descargas es siempre la misma, la más grande, y solo estas cambiando su tamaño de visualización.

Para intentar evitarlo, un error común es tratarlas como imágenes decorativas, de fondo (definirlas en el background-image de un elemento) de esta manera puedes tener diferentes tamaños de la imagen y en cada CSS cargar una.

Utiliza cualquier otra técnica menos esta: tratar imágenes informativas como imágenes decorativas supone un gran problema de accesibilidad, pues las imágenes decorativas no tienen una alternativa textual y si, por diferentes motivos, no se cargan o el usuario no puede verlas (por ejemplo accede con un lector de pantalla), se perderá la información que transmiten.

Mala práctica 2: Definir el viewport con restricción para el zoom

Si el usuario lo desea debe poder hacer zoom con el gesto “pinch” (Gesto con el dedo pulgar e índice, se abren o cierran como una pinza) al menos un 200% (criterio de conformidad 1.4.4, [WCAG2, 2008]). Para ello es importante definir correctamente el viewport:

Mala práctica:

<meta name="viewport" content="width=device-width;initial-scale=1.0; maximum-scale:1.0; user-scalable=1" />

Defiendo así el viewport estamos impidiendo el zoom. Podemos ver un ejemplo en la web http://www.anderssonwise.com/

Buena práctica

<meta name="viewport" content="width=device-width;initial-scale=1.0; maximum-scale:2.0; user-scalable=1" /<

Definiendo así el viewport estamos permitiendo que los usuarios que lo deseen puedan hacer un zoom de hasta 200%.

Mala práctica 3: Ocultar la barra de scroll horizontal

No debes ocultar la barra de scroll horizontal con overflow-x: hidden;

Tu sitio ya se adapta al dispositivo sin barras de scroll, ¿para que la ocultas además si no es necesario? Puede haber circunstancias en las que los usuarios la necesiten, por ejemplo si hacen zoom.

Buenas prácticas

A continuación indico cuatro buenas prácticas que deberías llevar a cabo en tu desarrollo Resposive Design. Y por supuesto la mejor recomendación es que las páginas cumplan con las pautas de accesibilidad WCAG 2.0

Buena práctica 1: Contraste de color mejorado en la versión para las resoluciones o tamaños de pantalla más pequeños.

Para alcanzar el nivel de adecuación AA respecto a las WCAG 2.0, el color de los textos debe tener al menos un ratio de contraste de 4.5:1 (3:1 en texto grandes) Para alcanzar el nivel AAA el contraste debe ser de 7:1 (4.5:1 en textos grandes)

Puesto que tenemos una CSS para dispositivos móviles os animo a que en ella alcancéis un nivel de contraste de color mayor, llegando al nivel AAA. En los dispositivos móviles el contraste suele ser menor, para ahorrar batería, y solemos tener muchos reflejos. También es importante que subrayéis los enlaces para reconocerlos mejor.

Se puede comprobar el contrate de color con la herramienta gratuita Colour Contrast Analyser.

Buena práctica 2: Diseña el tamaño de los elementos y la separación entre los mismos pensando también en los dispositivos móviles

En la web para desarrolladores de Android [ANDORID] tenéis resumida de forma gráfica cuales deberían ser los tamaños y espacios mínimos para que tus elementos sean fáciles de pulsar desde dispositivos táctiles. Nos ayuda a todos y especialmente a las personas con discapacidad motora:

Ten además en cuenta que hay zonas de pantalla más fáciles de pulsar.

Buena práctica 3: El foco sigue siendo importantes en los dispositivos móviles

Sigue siendo importante, tanto que el foco sea visible (no debes ocultarlo en la CSS) como que el orden del foco sea correcto. Muchos usuarios utilizan teclados externos o los usuarios de lector de pantalla deslizan el dedo por la pantalla tabulando de un elemento a otro.

Buena práctica 4: Prueba

Testea tu página, pruébala sin CSS o sin imágenes cargadas, pruébala con un lector de pantalla, prueba con usuarios y si tienes la oportunidad con usuarios con discapacidad. Henny Swan tiene un artículo muy interesante con una lista concreta de comprobaciones recomendadas [SWAN, 2012].

También deberías conocer las Mobile Web Best Practices del W3C, recomendación desde 2008. Hablé de estas y su relación con las WCAG en el artículo Accesibilidad y usabilidad móvil: web móvil y app nativa, mayo 2012.

Bibliografía

Artículos anteriores relacionados

Servicios de accesibilidad web que ofrezco como consultare freelance


Claves del estudio de UserZoom sobre la experiencia de los usuarios de tablet y móvil en portales de reserva de hoteles y viajes

$
0
0

Hace unos meses os comentaba las conclusiones que me parecían más interesante del estudio "Mobile Usability Testing. Estudio de usabilidad en Tablet. E-commerce de moda", realizado por UserZoom.

UserZoom ha publicado ahora otro estudio sobre la experiencia de los usuarios de tablet y móvil en portales de reserva de hoteles y viajes: "Mobile Usability Testing. Estudio benchmark de usabilidad en tablet y móvil en webs de hoteles y viajes".

Como ya os comentaba acerca del estudio anterior, no solo son interesantes las conclusiones que se extraen de estos estudios, sino que son también un buen ejemplo de cómo presentar amigablemente los resultados.

El estudio se ha realizado mediante test en remoto basado en tareas con la herramienta UserZoom (de la que hice una review en UserZoom, una herramienta profesional para consultores UX). Han participado 360 compradores habituales de viajes de ocio online de tres países: UK, Alemania y España. Realizaron las mismas tareas, la mitad desde tablet y la mitad desde el móvil. Los portales que se han testeado en España han sido: Rumbo.es, Logitravel.com y Viajes el Corte Inglés.

A continuación incluyo algunos de los datos y conclusiones que aparecen en el estudio y que me resultan más interesantes:

  • Datos generales:

    • El 80% de los usuarios busca en Internet para planificar su viaje (Google Travel Study 2013)
    • El 42% de los usuarios usa una tablet o un smartphone para buscar información sobre sus vacaciones o viajes (Google Travel Study 2013) Les resulta más cómodo navegar por la web que bajarse una app, de ahí la importancia de que los portales estén optimizados para dispositivos móviles.
    • El 68% de los usuarios busca y compara antes de decidir el viaje (Google Travel Study 2013) La información que encuentran les sirve para decidir su viaje: comentarios, vídeos (cada vez más valorados), qué se puede ver o hacer. Por eso es importante ofrecer la información más completa posible sobre el viaje, así aumentan las posibilidades de que lo compren en nuestra página y no en otra.
    • La compra de viajes online es un experiencia multidispositivo: saltan de un dispositivo a otro según el tiempo libre y el contexto. Inician su consulta en móvil y pueden acabar la compra en la tablet o el ordenador (aunque cada vez más usuarios la acaban desde el móvil)
  • Tarea 1: se ha evaluado encontrar un hotel (en determinada zona y con determinados servicio) y la ficha del hotel.

    • Filtrar por zona o servicios del hotel no siempre resulta fácil, visible o está disponible, porque a menudo el sitio no está optimizado para dispositivos móviles. Sin embargo, el porcentaje de éxito de los usuarios españoles fue bastante alto. Más del 80% lo consiguieron en las tres webs accediendo desde una tablet (porcentaje que también supera Viajes el Corte Inglés en el acceso desde móvil) Un porcentaje de éxito mucho más alto que el de las webs analizadas en UK y Alemania.
    • La información que se ofrece del hotel no siempre les parece suficiente: ¿el parking es de pago?, ¿hay internet gratis?, ¿cuál es el precio total de la reserva? Valoran la información que les aporte un valor añadido como servicios cercanos, planos, vídeos, actividades para hacer en los alrededores, ambiente de la zona en horario nocturno, etc. La valoración de la ficha del hotel ha sido muy justa en los portales españoles, siendo más alta en general en móvil que en tablet. Logitravel destaca bastante sobre los demás.
    • Dan gran importancia a las imágenes a la hora de decantarse por el hotel. Quieren fotos realistas y no comerciales, desde varios ángulos, del baño, de los exteriores, subidas por otros usuarios. La valoración de la fotos en los portales españoles no es demasiado buena, siendo mejor en el acceso desde móvil que desde tablet. Logitravel destaca de nuevo sobre los demás.
  • Tarea 2: se ha evaluado encontrar un crucero (con una ruta concreta desde determinada ciudad) y la ficha del crucero.

    • El fracaso es estrepitoso en general. En España solo se salva Rumbo.es con un porcentaje de éxito bastante alto (80%) en el acceso desde el móvil. La culpa del fracaso es, en general, la falta de optimización de la web para dispositivos móviles. Les fue difícil navegar por la información o usar el buscador: uso de iconos para navegar, mala arquitectura de información, buscador que no devuelve los resultados que se esperan, sitios que no tienen los mismos contenidos en el ordenador, la tablet y el móvil (y esto confunde al usuario en su navegación multidispositivo)
    • En cuanto a la ficha de producto, los usuarios echaron de menos información detallada sobre el crucero, como el precio de las excursiones o más fotos. La valoración de la información para tomar una decisión final es baja, salvo en el caso de Logitravel desde móvil que alcanza una nota superior a la media: un 74% de "muy detallada, puedo reservar sin dudas"
  • ¿Cerrarían la reserva desde la tablet o el móvil?

    • Salvo en Rumbo.es, más de un 60% de los usuarios de los otros dos portales haría la reserva de un hotel o un crucero desde la tablet o el móvil. El resto cerrarían la reserva desde el ordenador (salvo un porcentaje pequeño que no lo reservaría online de ninguna manera). Las razones por las cuales los usuarios preferirían cerrar la reserva desde el ordenador son: porque el dispositivo móvil se percibe como más inseguro que un ordenador, por incomodidad o por no poder imprimir y guardar la reserva.
  • El nivel de satisfacción final de los usuarios fue muy pobre. El portal mejor valorado en tablet y en móvil fue Logitravel.

Artículos anteriores:

Reseña del libro "Pioneros y Hacedores. Fundamentos y Casos de Diseño de Interacción con estándares de Accesibilidad y Usabilidad"

$
0
0
Portada del libro Pioneros y Hacedores

Autor: varios. Compilación Lorena Paz.

Nº páginas: 294

Idioma: español

Formato:ebook y libro impreso

Fecha de publicación: diciembre 2013

Enlaces:

Podéis consultar más reseñas de libros en: "Libros y reseñas"

Sobre el libro

El libro está compuesto por 19 capítulos de distintos autores, pioneros y hacedores en Arquitectura de Información, Diseño Centrado en el Usuario, Usabilidad y Accesibilidad, Ergonomía, Psicología, Diseño participativo y Co-desarrollo, oriundos de Centroamérica, Sudamérica, Norteamérica, Australia y Europa.

El origen de esta selección de textos nace de la necesidad académica de contar con material bibliográfico en español para formar en diseño de interacción con estándares de accesibilidad y usabilidad. El trabajo editorial se justifica por la ausencia, o falta de sistematización, de fundamentos y casos de experiencias de investigación, diseño y desarrollo de Diseño de Interacción en nuestro idioma. La compiladora, Lorena Paz, dirige la Especialización en Diseño de Interacción con Estándares de Accesibilidad y Usabilidad (DIEAU) en la Universidad Tecnológica Nacional de Buenos Aires (Argentina)

Los capítulos, mediante casos o fundamentos, tratan temas que van desde ergonomía física y cognitiva, al desarrollo de un videojuego y de un recurso educativo accesible; de métodos y dispositivos para evaluar la interacción con la nueva televisión interactiva a las técnicas de inspección e indagación heurística; de la internacionalización de la web a las normativas gubernamentales para hacer páginas web accesibles y usables.

Estos son los capítulos y sus autores:

Capítulo 1: El botón de los $300, por Jared M.Spool

Jared M. Spool nos cuenta el caso real de un e-commerce donde estudió la interacción de sus usuarios con los formularios de registro e ingreso. Finalmente, la modificación de un botón supuso un 45% más de usuarios que terminaban las compras y una ganancia adicional de 15 millones de dólares el primer mes tras el cambio, y 300 millones de dólares después del primer año.

Capítulo 2: Cómo usamos la web realmente, por Steve Krug

Steve Krug nos habla sobre las diferencias entre cómo creemos que la gente usa los sitios web y lo que sucede en realidad: las páginas no se leen, se hojean; no tomamos óptimas decisiones, nos conformamos con lo suficiente; y no nos interesa averiguar el funcionamiento de las cosas, nos las arreglamos.

Os recomiendo la reseña de sus libros "No me hagas pensar" y "Haz fácil lo imposible".

Capítulo 3: Mobile Sites vs. Full Site, por Jakob Nielsen

Defiende la necesidad de que los sitios web dispongan de una versión móvil. Nos habla de las buenas pautas a seguir en dicha versión y los desafíos que supone.

Este punto de vista es contrario al de los que defiende una web única implementada mediante Responsive Design, hablé de ello en Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.

Capítulo 4: ¿Qué se mueve?, por Don Norman

Parte de una anécdota personal con un mando a distancia, que tenía solo dos botones y sin embargo los usuarios interpretaban de diferente manera, para reflexionar sobre la elección de las metáforas en un diseño adecuado de la interacción.

Capítulo 5: Diseño de interacción, prácticas de investigación y diseño en materiales digitales, por Jonas Löwgren

Presenta qué es el Diseño de Interacción y la naturaleza de la investigación actual en este campo, para desarrollar lo que podría (y quizás debería ser) el Diseño de Interacción.

Capítulo 6: Diseño participativo para la inclusión digital, por Stephen Grant, Laurel Evelyn Dyson y Toni Robertson

Ofrecen un panorama general del desarrollo histórico del proyecto llevado a cabo en la Universidad Tecnológica de Sydney (UTS) para aumentar la participación de los estudiantes aborígenes australianos en los cursos IT, y el modo en el que, gracias a su éxito, fue evolucionando hasta llegar a ser un programa permanente en la Facultad de Ingeniería y Tecnología Informática: el Programa de Participación Indígena en IT (IPIT)

Capítulo 7: Introducción a la Interacción Persona-Computadora, por Yusef Hassan Montero y Sergio Ortega Santamaría

Introducen y describen los conceptos y aspectos más relevantes de la disciplina Interacción Persona-Computadora, que estudia cómo las personas diseñan, implementan y usan sistemas informáticos interactivos, y cómo las computadoras influyen en las personas, las organizaciones y la sociedad. Aportan también una bibliografía para ampliar y profundizar en el conocimiento de la disciplina.

Capítulo 8: Entre la Arquitectura y la Información, por Jorge Arango

Nos ofrece una introducción a la disciplina Arquitectura de Información, el área de práctica profesional que busca traer orden y coherencia a los medios digitales para lograr que la información sea más fácil de encontrar, navegar y entender a través de múltiples canales y dispositivos.

Capítulo 9: Accesibilidad y SEO, por Olga Carreras

Este capítulo es mi contribución al libro. En un principio era más extenso de lo que aparece en el libro, ya que tuve que reducirlo para ajustarme a las directrices editoriales. Podéis descargar el capítulo ampliado en "Accesibilidad y SEO. Capítulo ampliado" (PDF, 248 KB)

La accesibilidad web y el SEO parecen dos disciplinas muy diferentes, sin embargo tienen muchos puntos de encuentro. Ambas deberían caminar de la mano porque a menudo las técnicas de accesibilidad web y las buenas prácticas SEO se solapan y coinciden.

Comienzo el capítulo con una introducción de ambas disciplinas para pasar a dar un enfoque conciliador y explicar los puntos de encuentro entre ellas.

En la segunda parte del capítulo repaso los requisitos de accesibilidad web (haciendo referencia a las WCAG 2.0) que coinciden con buenas prácticas SEO y que por tanto repercuten directamente en la indexación y posicionamiento de nuestra páginas.

Capítulo 10: Desarrollo de un videojuego accesible, análisis del proceso de trabajo: El Caso Slalom, por Javier Mairena y Daniel Márquez

Nos habla de las claves y las dificultades para desarrollar un videojuego accesible, para lo cual será muy importante tener presente la accesibilidad desde el inicio del diseño hasta su publicación e implicar a todas las personas que forman parten del proyecto.

Los autores nos presentan un caso práctico, el desarrollo del videojuego Slalom (que se puede descargar gratis para Windows) Es un simulador del deporte “Slalom en Silla de Ruedas” practicado por personas con parálisis cerebral.

También nos ofrecen una bibliogafía muy interesante sobre recomendaciones publicadas por distintas entidades que pueden servir como guías para crear videojuegos más accesibles.

Gracias al artículo he conocido la iniciativa de SpecialEffect de utilizar un icono que identifique que el juego ha sido diseñado para ser accesible, icono que debería ir acompañado de una información más detallada sobre su accesibilidad. Y también que hay tiendas, como IndieCity, que clasifican sus juegos por sus características de accesibilidad.

Capítulo 11: Lo que desconocemos que conocemos sobre accesibilidad y usabilidad, por Emmanuelle Gutiérrez y Restrepo

Me gusta mucho el enfoque de Emmanuelle para este artículo, pues trata de acercar la accesibilidad a todo el mundo, mostrándola como algo más cercano al sentido común que a complicadas directrices que haya que seguir.

Mediante la comparación con las técnicas y prácticas habituales en la creación de documentos de texto, y siguiendo los tipos de contenido que suelen encontrarse en la mayoría de los sitios web hoy en día, especialmente aquellos que han sido creados mediante un gestor de contenidos, se analizan los criterios de conformidad que tienen su equivalente en dichas prácticas habituales y que, por tanto, todo desarrollador y diseñador conoce de antemano. Todos ellos tienen en realidad un conocimiento de accesibilidad y usabilidad que no sabían que tenían.

La autora nos muestra que con los conocimientos básicos para crear un documento de texto, bien formateado, legible y comprensible para nuestros destinatarios, conseguimos cumplir con 32 de los 61 criterios de conformidad de las WCAG 2.0. Es decir, cumplimos con el 52% de las pautas de accesibilidad para el contenido web. De los 25 criterios de conformidad de nivel A, cumplimos con 15, lo que significa cumplir con el 60% de ellos. De los 13 criterios de conformidad con nivel Doble A, cumplimos con 8, lo que significa cumplir con el 61,5% de ellos. De los 23 criterios de conformidad de nivel Triple A, cumplimos con 9, lo que significa cumplir con 39% de ellos.

Capítulo 12: Ergonomía física y cognitiva: los sistemas sensoriales humanos y la evaluación ergonómica de interfaces, por Sebastian Betti

Nos ofrece y explica una serie de criterios de conformidad para la evaluación ergonómica de las interfaces humano-computadora, que permiten reducir la carga del esfuerzo mental, visual y físico, y de este modo adaptarse mejor a las capacidades humanas.

Capítulo 13: Evaluación de la usabilidad con tecnología eye tracking. El caso de la TV conectada, por Mari Carmen Marcos y Verónica Mansilla

La tecnología Eye Tracking (ET) es una herramienta que complementa al test con usuarios para estudiar la usabilidad y la experiencia de usuario. La utilizaremos cuando nos interese conocer cómo miran los usuarios una interfaz cuando realizan determinada tarea.

Nos hablan de los modelos que existen, de los requisitos de los participantes y de la sala, de las métricas que obtendremos, de la calibración del ET o de los contratiempos que podemos encontrarnos. Otra parte importante del capítulo está dedicada al análisis de los datos obtenidos, que dependerá de si se ha hecho un análisis cuantitativo o cualitativo.

Nos presentan un caso de estudio concreto, aplicando la ET a la televisión conectada, que usa dos canales para recibir información, uno para los contenidos televisivos, y otro para los datos de Internet. Se estudió la interfaz de los menús, puesto que cada fabricante y cadena tienen su propia propuesta. Primero se hizo un test con usuarios en el que se detectaron muchos problemas de usabilidad. Uno de ellos era que los usuarios no lograban acceder con facilidad a un servicio concreto. Para profundizar en el motivo se llevó a cabo un test con ET. Nos cuentan los resultados y las dificultades del mismo.

La Universitat Pompeu Fabra ha llevado a cabo diversos estudios de ET:

Capítulo 14: Accesibilidad de un recurso educativo: El caso de la Mapoteca, por Manuel Razzari

Presenta como caso práctico la experiencia con el proyecto "Mapoteca" de educ.ar, una aplicación web para que estudiantes de nivel medio interactúen con mapas escolares. La aplicación sería distribuida en los 3.5 millones de netbooks de los alumnos de escuelas secundarias públicas.

Nos habla de los desafíos del proyecto, del marco de trabajo y de la importancia de elegir los componentes adecuados tanto en el back-end como en front-end, así como del testeo de la aplicación, tanto con usuarios reales como con herramientas de evaluación.

También nos describe los problemas detectados: los que habría sido necesario prever con suficiente antelación (como el uso del color); los que se podrían haber evitado formando adecuadamente a las personas que harán la carga de contenidos; los que son difíciles de imaginar hasta que se hace un test con usuarios; o los que simplemente no tienen una solución al alcance de todos, por ejemplo la solución de la aplicación de mapas de Apple 6, que no usa mosaicos de imágenes sino datos vectoriales, así VoiceOver te leerá las calles mientras desplazas el dedo, leyendo por tanto el contenido de cada zona del mapa.

La verdad es que me gusta mucho este capítulo, cómo describe con sinceridad la realidad de su proyecto, que es la de muchos otros, las limitaciones y los problemas que solemos encontrarnos, y los consejos son realistas y acertados. Además le tengo que agradecer la mención de este blog.

Capítulo 15: Elaboración de una Normativa de Usabilidad y Accesibilidad Web: El caso de la web de la Ciudad de Buenos Aires, Verónica Traynor

La autora nos introduce en el Diseño Centrado en el Usuario, en una forma de trabajo evolutiva y en espiral que permite a los integrantes del equipo avanzar y aumentar la calidad de sus bocetos de un modo más certero; según los modelos mentales ya no de ellos mismos, sino de los usuarios finales. El eje pasa a ser el ser humano con sus necesidades de percepción, comprensión, operabilidad y aprendizaje. Todo gira en torno a la observación empírica y metodológica de personas aprendiendo e interactuando.

Nos habla de la observación como metodología: "existe una diferencia significativa entre lo que les sucede a los usuarios, lo que interpretan sobre lo ocurrido y lo que opinan que les sucedió" y de los colores como parte del diálogo: "dejamos de hablar de pintar un cuadro y pasamos a construir un semáforo. Bello, pero fundamentalmente claro". Dos frases que me encantan.

Por último incluye la normativa de Usabilidad y Accesibilidad Web, publicada en 2010, que deben cumplir los sitios web pertenecientes al Gobierno de la Ciudad Autónoma de Buenos Aires.

Capítulo 16: Internacionalización Web, por Claudio Segovia

Nos introduce en la internacionalización de un sitio web (que no se refiere simplemente a crear sitios multilingües) y por qué deberíamos tenerla en cuenta. Detalla diferentes aspectos a los que deberemos prestar atención.

Si os interesa el tema, tengo un artículo relacionado con el mismo: Usabilidad e internacionalización.

Capítulo 17: Prácticas participativas en el Diseño de Interacción: El caso del Design Museum, por Mariana Salgado

Nos cuenta el proyecto "La vida secreta de los objetos" llevado a cabo en el Design Museum de Helsinki. El eje de este proyecto fue que el contenido generado por los visitantes (in situ, online o en los talleres organizados) como comentarios, relatos, opiniones, poemas, recuerdos o sentimientos basados en los objetos expuestos (y que podían estar en forma de texto, sonidos, música, imágenes, vídeos, etc.) estuvieran también en la galería, a disposición de los visitantes y promoviendo su participación. Un nuevo concepto de museo abierto y participativo, donde el diálogo continúe después de la visita.

De esta manera se enriquecería la experiencia de la visita al museo por medio de la inclusión. Esta información subjetiva permitiría disfrutar de las obras expuestas de muchas maneras, dando lugar a un museo abierto, y por tanto más accesible e inclusivo de las diferentes voces de nuestra sociedad.

En las conclusiones me llamó la atención dos párrafos porque se aplican también a la realidad de los proyectos web:

En muchos casos de diseño de interacción en el museo, el equipo de diseñadores no trabaja durante el proceso de incorporación de la pieza al espacio del museo, sino que su rol termina cuando la pieza interactiva está instalada. Eso imposibilita entender el contexto y encontrar ideas innovadoras para diseños futuros.

[...]

El público contribuye en mayor medida cuando ve que los comentarios de otros han sido respetados y exhibidos como parte del mensaje de la exposición.

Capítulo 18: Diseño y desarrollo de un editor de texto accesible bajo modalidad open-source, por Nahuel González

El objetivo del proyecto fue desarrollar un editor de texto accesible open-source. Partiendo de una lista de necesidades que debería atender el software, el artículo describe todas las características de la aplicación final, que a la publicación del libro estaba en la versión 2.0 y que es utilizado por usuarios con diferentes tipos de discapacidad.

Le agradezco al autor su referencia a mi artículo La usabilidad como metodología para el desarrollo de una aplicación (octubre, 2007)

Capítulo 19: Las métricas de accesibilidad desde una perspectiva práctica: eXaminator, por Carlos Benavidez

Carlos Benavidez, el creador de la conocida herramienta de evaluación automática de accesibilidad eXaminator explica por qué eXaminator se planteó como una herramienta que ofreciera una puntación numérica de la accesibilidad de la página. Explica además cómo se calcula la puntuación que otorga así como las ventajas y las limitaciones de la herramienta.

Una página que cumple con el nivel A, pero con ningún criterio de conformidad de nivel AA, obtiene según las WCAG el mismo valor de accesibilidad que una página que cumple con el nivel A pero también con muchos requisitos de nivel AA. La falta de precisión de esta escala tampoco permite conocer cuánto le falta a un sitio para alcanzar el nivel AA. Además, no todos los criterios de determinado nivel de conformidad afectan por igual a todos los usuarios. Estas son las razones para plantearse una puntuación numérica.

A pesar de ello, advierte que la accesibilidad no es una cualidad que se pueda medir con valores absolutos. La nota de eXaminator solo se puede considerar un indicador aproximado para contar con una escala sensible y precisa que nos permita hacer comparaciones (entre distintos sitios o el mismo sitio en el tiempo) o nos permita resumir en un resultado final, un resultado fácil de comprender y con una interpretación clara.

También habla de las limitaciones de cualquier herramienta de validación automática, que solo pueden comprobar un pequeño subconjunto de criterios de conformidad, y que por tanto toda revisión de accesibilidad deberá contar con un experto y una revisión manual.

Advierte que la calificación que otorga la herramienta no mide la accesibilidad general de la página sino el desempeño de la misma con respecto a las pruebas que realiza: no se puede asegurar que un 8 represente el mismo grado de accesibilidad que la misma nota en otro sitio.

Otra limitación de la herramienta es que la estructura de la página determina el número de pruebas que se pueden hacer en ella, habrá página con más de 20 pruebas y páginas que solo recibirán 4 o 5 pruebas, por tanto un mismo error tendrá mayor influencia en el promedio general a medida que disminuya el número total de pruebas posibles.

En el 2012 publiqué un artículo sobre otra limitación que hay que tener en cuenta en los validadores automáticos de accesibilidad: Falsos errores de validadores automáticos de accesibilidad basados en las WCAG 2.0

EN 301 549: primera norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC)

$
0
0

Los organismos europeos de Normalización CEN (Comité Europeo de Normalización), CENELEC (Comité Europeo de Normalización Electrotécnica) y ETSI (Instituto Europeo de Normalización de las Telecomunicaciones) han aprobado la primera norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC).

La EN 301 549 ‘Requisitos de accesibilidad adecuados para la contratación pública de productos y servicios TIC en Europa’, es el resultado del mandato M 376 "Standardisation Mandate to CEN, CENELEC and ETSI in support of European accessibility requirements for public procurement of products and services in the ICT domain" de la Comisión Europea para elaborar un estándar europeo de requisitos funcionales de accesibilidad, en la contratación pública de productos y servicios TIC, que asegure que son accesibiles para todas las personas.

El apartado 9 de la norma EN 301 549 hace referencia a los requisitos de accesibilidad que se aplican al contenido web. No hay que preocuparse, no se trata de requisitos nuevos, sino que figuran todos los de nivel A y AA de las WCAG 2.0 (que sabemos que desde 2012 es también norma ISO: ISO/IEC 40500 (2012): "Information technology - W3C Web Content Accessibility Guidelines (WCAG) 2.0"). De hecho, la EN 301 549 incluye en su página de descarga un archivo ZIP con las WCAG 2.0 en formato PDF.

El apartado 10 hace referencia a los requisitos de accesibilidad en documentos y el apartado 11 a los requisitos de accesibilidad del software, pero hay otros, por ejemplo los referentes al hardware.

Es interesante el Anexo B donde se incluye una tabla con todos los requisitos de accesibilidad de la norma expresados en términos de rendimiento funcional (distinguiendo relaciones primarias y secundarias): uso sin visión, uso con visión limitada, uso sin percepción del color, uso sin audición, uso con audición limitada, minimiza los factores desencadenantes de convulsiones fotosensibles, etc.

En España la legislación ya recoge desde 2007 la obligatoriedad de que los contenidos web de la Administración Pública (entre otros) cumplan con el nivel de adecuación AA de la Norma 139803, que desde 2012 es equivalente a las WCAG 2.0

Artículos relacionados:

Customer Journey Map, Mapa de empatía y Personas en UX Research

$
0
0

Son muchas las técnicas que podemos utilizar para conocer a nuestra audiencia o público objetivo, según las posibilidades y características de cada proyecto, y que nos permitirán recopilar diferentes datos, cuantitativos o cualitativos, según el caso: diferentes tipos de entrevistas (contextuales, en profundidad, en pares, etc. con los propios usuarios, con los departamentos de marketing, de atención al cliente, etc.), encuestas, cuestionarios, observación en contexto, focus group, tutoría entre pares, estudio de datos obtenidos de las herramientas de analítica web, estudiar lo que los usuarios dicen en los comentarios dentro y fuera del sitio o en nuestros canales de redes sociales, etc.

Pero luego es necesario extraer conclusiones, sintetizar los datos y sobre todo humanizarlos, que esos entes vagos y abstractos “usuarios”, “clientes” se conviertan en personas con las que podamos empatizar, personas que tienen motivaciones, necesidades, expectativas y limitaciones.

Para ello los Customer Journey Map, los Mapas de empatía y la técnica de Personas son un gran aliado.

Customer Journey Map

Es un documento que ilustra visualmente la relación de nuestros clientes con la empresa y su percepción de la misma, así como sus necesidades y expectativas en cada fase de la relación.

Para ello se identifican:

  • las diferentes fases de la relación desde el punto de vista del cliente. Cómo interactúan a través del ciclo de vida de la relación y cuáles son las interacciones específicas.

    Por ejemplo, si tenemos un e-commerce, la interacción del cliente va mucho más allá de la interacción en la propia web: busca previamente información en otros sitios, compara los productos en diferentes e-commerces, el cliente recibe el pedido, puede hacer una devolución, puede llamar al servicio de atención telefónica, etc.

  • una vez definidas las fases a alto nivel, se identifican los diferentes touchpoint (puntos de contacto concretos en diversos medios) y los momentos de la verdad (moment of truth) aquellos que son especialmente importantes para el cliente o la empresa por su relevancia.
  • después se plasman las necesidades y las percepciones de los clientes: qué esperan en cada fase e interacción (qué quieren lograr, cómo quieren sentirse y ser tratados), qué piensan y qué sienten en cada una, si están satisfechos, si las consideran adecuadas o valiosas, si les surgen problemas, dudas o incertidumbres.

Vemos aquí varios ejemplos, el primero referente a un e-commerce y el segundo a una reserva de vuelos:

No solo nos permite plasmar los objetivos y percepciones de los usuarios en el contexto de uso, sino que nos permite entender nuestro portal dentro de una relación con el cliente que más allá del propio portal e incluso del propio canal online, pero que repercute en el mismo.

En las referencias podéis encontrar artículos para seguir ampliando información sobre los Customer Journey Map.

Mapa de empatía

Una vez segmentado nuestro público objetivo es necesario empatizar con cada uno de los segmentos definidos, comprenderlos como personas en un contexto, que tienen unas necesidades, motivaciones, expectativas y aspiraciones que debemos entender.

El Mapa de Empatía es una técnica de Xplane que nace pensada para la definición del modelo de negocio. Se puede utilizar la plantilla que proponen y que podéis descargar en alta resolución: descarga de la plantilla 'The Empathy Map' de Xplane

O usar una adaptación al español:

Después necesitarás un paquete de post-it:

Nos ayuda a humanizar a los usuarios y a empatizar con ellos para que las decisiones se tomen en base a sus necesidades y expectativas, convertidas en objetivo común de todo el equipo.

Nos ayuda a evitar o minimizar aquello que les preocupa (por ejemplo el pago por Internet), a mejorar la forma en que nos dirigimos a ellos (por ejemplo en términos de lenguaje), a proponer estrategias para llegar y conectar mejor con ellos (por ejemplo a nivel gráfico o a nivel de canales en redes sociales), etc.

En las referencias podéis encontrar artículos para seguir profundizando en los Mapas de Empatía.

Personas

Esta es una de las técnicas más conocidas y habituales, que se complementa perfectamente con el Mapa de Empatía, y que nos ayudará a pensar en los “usuarios” como “personas”.

Una vez segmentado nuestro público objetivo representaremos y humanizaremos a cada uno con un personaje ficticio (Persona), un arquetipo de usuario, del cual haremos una ficha.

Por cada Persona tendremos un nombre y una foto, una lista con sus características (edad, profesión, origen y ubicación, nivel de estudios, estado civil, su experiencia en Internet, etc.) y una narrativa en tercera persona. Queremos saber sus objetivos y necesidades, sus motivaciones, sus limitaciones o frustraciones.

En esta infografía de Lane Nielsen se resumen la técnica:

Otro ejemplo en el cual se incluye ya escenarios y comportamientos:

Ficha con foto y nombre de un joven y listado de características. Enumeración de necesidades, escenarios, funcionalidades y comportamientos.

Imagen de pulsosocial.com

Podéis encontrar muchos ejemplos diferentes buscando "example personas" en Google.

Los “usuarios” están ahora representados por un número manejable de personas. No solo nos permite comprenderlos y empatizar con ellos, sino que las decisiones o los desacuerdos se resuelven referenciando siempre a estas personas.

En las referencias podéis encontrar más artículos para profundizar en la técnica de Personas.

Propuesta de integración en una sola representación visual

Esta propuesta de BMCreativity intenta mostrar de forma unificada la información extraída de las técnicas de Personas y Mapa de Empatía (en la primera columna) y Customer Journey Map (en la segunda columna). En la parte de la derecha vemos también que se identifican factores críticos de éxito, métricas y stakeholders implicados.

Basado en datos

La elaboración de estos documentos suele partir de suposiciones e hipótesis en las reuniones iniciales con el equipo y el cliente, que después se contrastan y refinan con los datos obtenidos durante el trabajo de investigación.

Pero incluso este taller de reflexión inicial y brainstorming es en sí mismo ya muy valioso, porque obliga a todo el equipo a empezar a pensar quiénes son los usuarios, qué quieren, cuándo y cómo usan nuestro producto, etc.

Definiendo "Personas" en un taller inicial con el cliente y el equipo

Enlaces de interés

Añadidos

Artículos anteriores

Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA)

$
0
0

En este artículo os explicaré cómo en 2 minutos podéis mejorar la accesibilidad de vuestra página, de manera que sea más fácil de "ojear", comprender y navegar para las personas que usan un lector de pantalla.

Cuando una página web está correctamente marcada permitimos que los usuarios que usan un lector de pantalla no tengan que hacer una lectura lineal de toda la página. Utilizando determinadas teclas podrán "ojear" el documento y acceder directamente a las partes del mismo que les interesan.

Por ejemplo, si tenemos una correcta estructura de encabezados, marcados como tales, un usuario de lector de pantalla (como JAWS o NVDA) podrá pulsar la tecla “h” para “ojear” los encabezados. Cada vez que pulse dicha tecla el lector le leerá el siguiente encabezado y podrá seguir leyendo a partir del que le interese.

De esta manera, los usuarios de lector de pantalla, pulsando diferentes teclas, pueden ojear los encabezados de distintos niveles, las listas, las tablas, las imágenes, etc. de la página o sacar un listado de dichos elementos.

Actualmente los lectores de pantalla también pueden anunciar, acceder y saltar por los bloques de la página relevantes: la cabecera, la zona de navegación, el contenido principal, el buscador o el pie de la página.

Sin embargo, para que esto sea posible, debemos marcar dichas zonas en el código HTML como puntos de referencia (landmark), de manera que pulsando la tecla “d” en NVDA o la tecla “r” en JAWS, el lector de pantalla pueda identificarlas, navegar por ellas y anunciar de qué tipo son.

¿Cómo se hace esto? Con WAI-ARIA y los Landmark Roles.

Es algo muy sencillo de hacer, que no solo mejorará la accesibilidad de tu sitio, sino que en un futuro los navegadores podrán implementar teclas de acceso rápido para acceder a estas partes de la página, puesto que se definen igual en todos los sitios y de forma independiente del dispositivo. Existe por ejemplo actualmente una extensión para Firefox: Firefox Landmark Extension.

Son también más consistentes que los enlaces de "saltar contenido" que se incluyen en las páginas, pues como digo, se definen igual en todas las páginas y dan más información semántica que estos. Este es también un punto importante, estamos añadiendo información semántica sobre la estructura de nuestra página. Sin embargo, aunque hay un soporte generalizado de los landmark roles, se pueden mantener los enlace "saltar al contenido" por compatibilidad con versiones antiguas (ir a Soporte de Landmark Roles)

¿Cómo se hace? Landmark roles

La especificación WAI-ARIA define un tipo especial de aria roles, los landmark roles, que se usan para identificar áreas separadas de tu página y transmitir la naturaleza de la mismas. De esta manera añadimos características útiles de navegación global, consistentes en cualquier documento (X)HTML, que transmiten información de la estructura de la página e información semántica sobre estas zonas.

Es tan fácil como añadir al elemento contenedor (el “div” por ejemplo) el código role=”[tipo_landmark]. Por ejemplo, div role=”main” para marcar el "div" que contiene la zona de contenido principal. Incluirlos en las plantillas de vuestras páginas no os llevará ni 2 minutos.

Se pueden añadir en HTML 4, (X)HTML y HTML 5.

En HTML4 y (X)HTML tendrás que usar un DTD específico para que el validador de sintaxis del W3C no te dé errores de validación al usar WAI-ARIA:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN""http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">

Los landmark roles son:

  • Banner
  • Complementary
  • Contentinfo
  • Form
  • Main
  • Navigation
  • Search
  • Application

role="banner"

Debería haber solo uno por página.

Es la zona, normalmente en la parte superior, que contiene el logo o título principal de la página, que tiene no propiamente contenido específico de la página sino contenido orientado al sitio, lo que podría ser la cabecera de la página.

Referencia del role "banner" en WAI-ARIA.

Es lo que en HTML5 podríamos tener marcado como <header>, pero solo podremos tener uno marcado así.

En la especificación de HTML 5 se indica que los roles que admite <header> son efectivamente “banner” (o “presentation”1 ).

role="complementary"

Es una sección diseñada para ser complementaria del contenido principal y relevante para el mismo, pero que sigue siendo significativa cuando se separa de la misma. Por ejemplo sería una zona de artículos relacionados, de información del tiempo, etc.

Referencia del role "complementary" en WAI-ARIA.

Es lo que en HTML 5 marcaríamos como <aside>. En la especificación de HTML 5 se indica que puede tener los roles de "complementary", pero también de "search"; o de "note" o "presentation" (que no son landmark roles), según la función que esté realizando.

role="contentinfo"

Debería haber solo uno por página.

Es una zona que contiene información sobre el documento, como por ejemplo la información de copyright y enlaces de privacidad, en definitiva suele ser el pie de la página.

Referencia del role "contentinfo" en WAI-ARIA.

Es lo que en HTML5 podríamos marcar como <footer> . En la especificación HTML5 se indica que admite efectivamente los roles “contentinfo” (y “presentation”)

Pero en HTML5 solo deberíamos tener marcado un <footer> con el role=”contentinfo”.

role="form"

Es una zona que contiene una colección de elementos y objetos que se combinan para crear un formulario (si es de búsqueda se usaría “search”)

Referencia del role "form" en WAI-ARIA.

En HTML5 añadiríamos este rol a un elemento “form” o a un elemento semánticamente neutro como un “div”.

role="main"

Debería haber solo uno por página.

Es el contenido principal de un documento, un buen apoyo al enlace “saltar contenido”.

Referencia del role "main" en WAI-ARIA.

En HTML5 sería el elemento <main>, que como se indica en la especificación admite los roles “main” y “presentation”.

role="navigation"

Es una colección de enlaces para navegar por la página, es decir, sería un menú de navegación. Puedes tener varios, por ejemplo el principal y el secundario en una columna izquierda.

En la especificación se indica que si hay un menú en el pie no es necesario marcarlo, basta con marcar el role=”contentinfo” en el pie.

Referencia del role "navigation" en WAI-ARIA.

En HTML 5 sería lo que marcaríamos como <nav>, como se indica en la especificación admite los role “navigation” (y “presentation”)

role="search"

Es una colección de elementos y objetos que en su conjunto se combinan para crear una herramienta de búsqueda, lo que sería la zona del buscador del sitio.

Referencia del role "search" en WAI-ARIA.

No hay un elemento equivalente en HTML5, el rol se incluiría en el “form” de la búsqueda o el “div” contenedor.

role="application"

Declara una zona como una aplicación web en contraposición como un documento web.

Los lectores de pantalla tienen un modo formulario (o aplicación) diferente del modo de lectura normal. Cuando navegan a un elemento con el role “application” las tecnologías de apoyo, que normalmente interceptan eventos de teclado estándar, deben cambiar a modo de navegación de aplicaciones, para permitir a la página funcionar como una aplicación. Por ejemplo las flechas arriba y abajo habituales para navegar por el documento puede ser un comportamiento nativo que impida usarlas en una aplicación web.

Hay que tener mucho cuidado con <body role="application"> porque el usuario no podrá fácilmente abandonar el modo aplicación.

El mejor consejo es que se use con moderación y muy seguro de lo que se está haciendo, probando siempre su comportamiento con un lector de pantalla.

Referencia del role "application" en WAI-ARIA. Otro enlace de interés es Using aria=application del W3C.

No hay un equivalente en HTML5, se usaría un elemento semánticamente neutro como un “div”.

En WAI-ARIA hay otro tipo de roles aparte de los landmark roles, por ejemplo roles de estructura que sirven para organizar el contenido de la página: "article", "document", "región", "toolbar", etc.

Sin embargo, a pesar de no ser landmark roles, JAWS (no así NVDA) también anuncia y lista los role="region" y los role="article" como landmarks:

Listado de landmark roles de JAWS.  Dentro de la zona 'main' se lista una 'region': Region prueba region

Listado de JAWS de landmarks de una de mis página donde incluí un role="region" aria-label="Region prueba" para mostrar que los listaba

Veamos unos ejemplos

Hay muchos sitios que incluyen en el código landmark roles: store.apple.com, Google, BBC, Yahoo, Samsung o mi propia web Usable y accesible.

Por ejemplo, estos son los landmark roles en una página interior de samsung.com:

El logo es marcado con banner, el menú de navegación principal con navigation, la búsqueda con search, la zona de contenido con main y la zona del pie con contentinfo. El menú secundario de navegación no está englobado en ninguna de las áreas.

Imagen de Samsung> Landmarks

La página de Samsung hace una cosa mal: deja zonas de contenido huérfanas. Si el usuario usa los landmarks para "ojear" la página no accederá al menú secundario de navegación (que como vemos está fuera de las áreas definidas). Debería haberse marcado también con un role="navigation", pues como hemos dicho puede haber más de uno en la página.

Para saber si una página usa landmark roles podemos usar el lector de pantalla para comprobarlo, o podemos mirar el código, o podemos usar una extensión habitual para revisar la accesibilidad de la página, como es "Web Developer" en Chrome o Firefox. En "Information>ARIA Roles" nos los marcará en pantalla:

Página de accesible, encima de cada zona de la página se indica el landmark role con la que está marcada.

Página de "Usable y accesible" con los landmark roles marcados mediante la herramienta "Web Developer" de Firefox.

¿Cómo acceden los usuarios de lector de pantalla a los Landmark Roles?

Pueden pulsar una tecla ("d" en NVDA, "r" en JAWS15) como he explicado al principio, "ojeándolos" como si fueran cualquier otro tipo de elemento.

También pueden sacar una lista de todos los landmark roles de la página. En NVDA con "Insert+F7", o en JAWS con "Insert+Control+r":

Lista con 5 elementos: banner, navegación, buscar, principal, información de contenido

Lista de landmark roles (puntos de referencia en español) de NVDA

En un iPad, por ejemplo, los tendrán también disponibles en el "rotor" (si indican en la configuración del "rotor" que los muestre, pues por defecto no están). El "rotor", cuando tienes activo VoiceOver, permite seleccionar un tipo de elemento y navegar por los elementos de dicho tipo:

Pantalla de Usable y accesible con el rotor superpuesto en el modo 'puntos de referencia'

Captura de "Usable y accesible" en un iPad con el "rotor" en "puntos de referencia" (landmarks)

Podéis ver el vídeo "How ARIA landmark roles help screen reader users" para comprobar cómo anuncia el lector de pantalla los landmark roles.

Complementarlos con "aria-label" o "aria-labelledby"

Se recomienda etiquetar el elemento al que añades el rol, especialmente cuando hay dos del mismo tipo, para diferenciarlos.

Puedes hacerlo con los atributos "aria-label" y "aria-labelledby". La diferencia es que en el primero pones directamente la etiqueta dentro del atributo: aria-label="Menú principal", y en el segundo solo indicas el ID del elemento que hace de título o etiqueta a esa zona.

Podéis consultar los ejemplos en "Using ARIA landmarks to identify regions of a page", del W3C.

JAWS anuncia las diferentes áreas con la etiqueta indicada en estos atributos, y también la incluye en el listado de landmarks (como se veía en la imagen de ejemplo del role="region")

Sin embargo NVDA2013 las ignora, por ejemplo para un role="complementary", lee "Complementario. Panel de referencia. [el primer elemento, por ejemplo Histórico de artículos. Nivel 2]", independientemente de si le he puesto o no un "aria-label" o una "aria-labelledby". Por ello es importante que el primer contenido de la zona sea significativo.

Buenas prácticas

Las buenas prácticas son por tanto:

  • Usar el rol según la especificación, es decir, respetar si solo puede haber uno de un determinado tipo, o que el contenido de la zona se corresponda realmente con el rol asignado.
  • Que todo el contenido esté englobado dentro de elementos identificados con un rol, que no haya contenido que se quede huérfano. De esta manera el usuario de lector de pantalla puede navegar de forma segura de “landmark” y “landmark” sin perderse nada de la página.
  • Añadir "aria-label" o "aria-labelledby" para diferenciar varias zonas con el mismo rol asignado.
  • El primer contenido de un zona marcada con un landmark role debe ser lógico, por ejemplo, el primer contenido que esperas en un landmark "main" es un encabezado. Ten en cuenta que es lo primero que le anuncia el lector de pantalla de esa área.
  • Revisa en la versión móvil, si se tiene menos contenido, si siguen teniendo sentido.

Soporte

Yo os he comentado el soporte en JAWS15, NVDA 2013 y VoiceOver.

El soporte más detallado según el W3C es:

  • Jaws V.11 and greater has complete support.
  • ChromeVox V.1 and greater has complete support
  • VoiceOver V.3 and greater supports all landmarks except “form”.
  • NVDA 2 supports all landmarks except it will not support navigation to “application”
  • Window Eyes as of V.7 does not support ARIA landmarks.

Paciello Group indica que el soporte es:

  • En Using WAI-ARIA Landmarks – 2013: landmark roles are supported in JAWS (version 10 and above), NVDA, ORCA, Chromevox, Window Eyes and VoiceOver and via a FireFox addon for keyboard users.
  • En Latest ARIA landmark support data, noviembre 2011: Jaws 11/12/13 has complete support; ChromeVox has complete support; VoiceOver supports all landmarks except “form”; NVDA supports all landmarks except “application” and “form”; Window Eyes does not support ARIA landmarks.
  • En HTML5 Accessibility Chops: ARIA landmark support, julio 2011: NVDA and JAWS when using Internet Explorer 9 or Firefox 3+; VoiceOver when using Safari on iOS 4+; Orca (Linux screen reader) using Firefox 3+ supports landmarks (not tested).

En ARIA Landmark role support tests - 21/11/2011 de html5accessibility.com se puede consultar una tabla muy detallada por cada tipo de rol testeado con JAWS 9-13; NVDA 2011.2; Voice Over (en OSx Lion, iPAd2, iPhone4); ChromeVox y Windows Eyes 7.5.

En resumen, indica que salvo el role="application" y el role="form", el resto de roles son soportados por todas la versiones testeadas de los lectores de pantalla salvo por Windows Eyes.

Landmark Roles y HTML5

Ya he comentado que se pueden incluir landmark roles en HTML5 y que tienen semejanzas con algunos de sus nuevos elementos semánticos, aunque no es siempre una correspondencia exacta.

La relación queda bien expresada en esta imagen de carmenwiki.osu.edu.

Header se corresponde con role=banner; Nav se corresponde con role=navigation; main se corresponde con role=main; footer se corresponde con role=contentinfo; aside se corresponde con role=complementary

La pregunta es, ¿el lector de pantalla nos anunciará los elementos semánticos de HTML5 y los landmark roles, y por tanto la información será redundante y anunciada por duplicado?

Lucica Ibanescu hizo la prueba en 2011 y nos lo cuenta en "Cómo leen los lectores de pantalla una página con HTML5 y ARIA". En resumen, comprobó que ni NVDA, ni JAWS ni Windows Eyes anunciaban los elementos semánticos de HTML5, lo trataban como si fueran simplemente "divs". Sin embargo sí que los anunciaron incluyendo los landmark roles (salvo Windows Eyes que ya hemos dicho que no los soporta).

En marzo de 2011 Jason Kiss publicó también sus resultados "HTML5, ARIA Roles, and Screen Readers in March 2011". En resumen, solo NVDA con FF4 anunciaba algún elemento semántico de HTML5.

Se puede ver una tabla más actualizada del soporte de los elementos en html5accesibility.com en la que se ve que el soporte dista mucho del que tienen los landmark roles.

Por tanto, hasta que los elementos semánticos de HTML5 tengan un soporte generalizado en los lectores de pantalla es recomendable incluir los landmark roles.

Podéis ver varios vídeos de cómo en HTML5 distintos lectores de pantalla anuncian los landmark roles, como se observa, no se anuncia la información por duplicado:

Criterio de conformidad de las WCAG 2.0 asociados

La inclusión de landmark roles en las páginas está relacionado con los siguientes criterios de conformidad de las WCAG 2.0

  • 1.3.1 Información y relaciones: La información, estructura y relaciones comunicadas a través de la presentación pueden ser determinadas por software o están disponibles como texto. (Nivel A)
  • 2.4.1 Evitar bloques: Existe un mecanismo para evitar los bloques de contenido que se repiten en múltiples páginas web. (Nivel A)
  • 4.1.2 Nombre, función, valor: Para todos los componentes de la interfaz de usuario (incluyendo pero no limitado a: elementos de formulario, enlaces y componentes generados por scripts), el nombre y la función pueden ser determinados por software; los estados, propiedades y valores que pueden ser asignados por el usuario pueden ser especificados por software; y los cambios en estos elementos se encuentran disponibles para su consulta por las aplicaciones de usuario, incluyendo las ayudas técnicas. (Nivel A)

Enlaces de interés:


Nota 1: role=presentation, no es un landmark role. Es un rol que oculta los roles nativos de los elementos y sus descendientes a los productos de apoyo, y por tanto se usa solo para marcar elementos puramente decorativos.

Otros artículos de WAI-ARIA

En artículos anteriores he explicado cómo mejorar de forma muy sencilla la accesibilidad de las páginas aplicando WAI-ARIA:

Reseña "El Content Curator. Guía básica para el nuevo profesional de Internet"

$
0
0
Portada del libro El Content Curator

Autor: Javier Guallar y Javier Leiva-Aguilera

Nº páginas: 164

Idioma: español

Formato: libro impreso (12x17,5cm)

Fecha de publicación: noviembre 2013

Web:El Content Curator. Guía básica para el nuevo profesional de Internet

Podéis consultar más reseñas de libros en: "Libros y reseñas"

Sobre el libro

El libro está dividido en dos partes.

El objetivo de la primera parte es comprender qué es la "content curation" e introducir los conceptos básicos: contexto, origen, términos y definiciones; el perfil profesional que la lleva a cabo; y el sistema de "content curation", características básicas, sistemas relacionados, tipos y métodos de "content curation".

La segunda parte es un acercamiento práctico a través de la cuatro fases (las 4 S's) que componen el sistema y las herramientas que facilitan su ejecución.

La verdad es que os recomiendo su lectura, ágil, entretenida, bien estructurada y documentada. Muy útil tanto a nivel personal como profesional.

Sobre la Content Curation

La especialidad, o el sistema, se denomina "content curation" y el profesional "content curator".

Es un término cuyo origen suele atribuirse a Rohit Barghava y su "Manifesto for the content curation" (2009).

El término surge en el contexto de la web de finales de la primera década del siglo XXI, caracterizada por ser una web social, multimedia, a la que se accede desde diversos dispositivos y en continuo crecimiento, lo cual nos provoca una abrumante sobrecarga informativa.

Content Curation es el sistema llevado a cabo por un especialista (content curator) para una organización o a título individual, consistente en la búsqueda, selección, caracterización y difusión continua del contenido más relevante de diversas fuentes de información en la web sobre un tema (o temas) y ámbito (o ámbitos) específicos, para una audiencia determinada, en la web (tendencia mayoritaria) o en otros contextos (por ejemplo, en una organización), ofreciendo un valor añadido y estableciendo con ello, una vinculación (engagement) con la audiencia/usuarios de esta.

Por tanto, no es la mera recomendación social de contenido. Tampoco se trata de generar más ruido replicando o duplicando contenido. Ni tampoco basta con una buena selección y difusión de contenidos. El "curator" debe darles sentido, interpretarlos, debe aportar valor añadido, ofrecer algo distintivo, personal y de calidad que hará que su audiencia valore y aprecie su aportación, estableciendo una profunda vinculación con ella.

Es una actividad muy cercana al profesional de la documentación (bibliotecario, documentalista o gestor de la información) y sus habilidades de gestión de la información (búsqueda, filtrado y difusión), pero para la que son también necesarias habilidades propias de los profesionales del marketing online, el marketing de contenidos y la comunicación corporativa, así como habilidades propias de los periodistas: redacción, búsqueda de fuentes y verificación de la información.

Por tanto es un perfil entre la documentación y la comunicación, que debe ser especialista en la temática a curar y experto conocedor de los medios sociales. Es una actividad, además, que no puede ser llevada a cabo totalmente por un sistema automatizado.

Los autores repasan diversos modelos (Bhargava, Ben Kanter, Curata, Archanco, Robin Good) para finalmente esbozar su método (de las 4 S's), basado en cuatro grandes fases (búsqueda, selección, caracterización, difusión), que a su vez se dividen en diversas tareas. A las cuatro etapas les precede una fase de diseño o planificación y les sigue una fase de evaluación o análisis. Entendido todo ello como un proceso cíclico.

Los objetivos de la "content curation" pueden ser muy diversos: posicionar la marca personal o institucional en un tema concreto, diferenciarnos de la competencia, aumentar nuestra visibilidad, crear una comunidad virtual en torno a un tema, hacer crecer la comunidad virtual de usuarios de una organización, etc.

Método de las 4 S's

  • Diseño, donde se toman decisiones estratégicas como:

    • objetivos;
    • investigación de la competencia, la densidad del tema y el interés de la audiencia para decidir el tema a curar;
    • localización de fuentes documentales, personales y búsquedas persistentes;
    • el producto resultante (blog, social media, etc.) y la frecuencia de publicación;
    • definición de hitos personales de evaluación
  • Búsqueda y selección de contenidos (search, select):

    • sistemas de alertas: Google Alerts, Talkwalker Alerts, Yahoo! Alerts, Mention
    • seguimiento de RSS: Feedly, The Old Reader, Feedspot, AOL Reader, Digg Reader, Tiny Tiny RSS, Zite, Flipbord, Pulse, Google Currents
    • monitorización de medios sociales, con un amplio apartado sobre Twitter
    • buscadores de medios sociales: Socialmention (en el que existe una clasificación basada en sentimientos), Boardreader, herramientas de marcadores sociales como Delicious o Diigo
    • servicios comerciales de seguimiento (clipping) como Acceso, TNS, Mynews, Augure o iConoce

    Repasan también herramientas para guardar los contenidos seleccionados como Pocket y Evernote, así como una serie de recomendaciones para esta fase.

  • Caracterización y difusión de contenidos (sense making, share): en esta fase, una vez seleccionado lo que queremos usar, aportaremos nuestro sello personal al producto de "curator" y lo daremos a conocer, en una primera fase en la plataforma de la "curation" y después difundiéndolo en otros canales.

    El nivel de curación puede ser profundo, aportando valor a través de la reelaboración, fusión de distintos contenidos y aportación de contexto.

    Repasan los cuatro grandes tipos de productos de "content curation", curación basada en:

    • listas, que pueden ser posts de blogs, los típicos "Las diez mejores..."
    • blogs, opción que más posibilidades ofrece, o sitios web
    • en tiempo real, donde la estrella es Twitter. También tiene un segundo enfoque, la elaboración de una historia de alto nivel informativo a partir de un determinado acontecimiento, poniendo el caso real de una conferencia y el uso de Storify
    • servicios social media, Scoop.it, Pinterest, Paper.li

    Dan también recomendaciones para la caracterización y difusión de contenidos.

  • Evaluación del grado de cumplimiento de los objetivos marcados así como detección de errores y oportunidades para mejorar.

Tratan de forma específica la herramienta Curata, de pago, que permite realizar de forma integral un proceso de "curator". Hablan también de otras como Pearltrees, ContentGems, Basgtheweb o MyCurator para WordPress.

Me quedó una sensación curiosa después de leer el libro, la de que llevo mucho tiempo en este blog haciendo (o intentando hacer) "content curation", siguiendo de manera instintiva las fases del sistema y las herramientas que proponen, sin haberle dado antes un nombre :)

Artículos anteriores

Nuevas técnicas ARIA en las WCAG 2.0. Novedades de la actualización del documento "Techniques for WCAG 2.0" del 11 de marzo de 2014

$
0
0

Sobre las "Techniques for WCAG 2.0"

El documento Web Content Accessibility Guidelines (WCAG 2.0) es el documento normativo y estable de las WCAG 2.0, es decir, es un documento que no se modifica porque está concebido para ser un estándar web perdurable en el tiempo. Por ello está redactado de forma neutral, sin hacer referencia a una tecnología concreta.

Para explicar cómo cumplir los criterios de conformidad definidos en las WCAG 2.0, estas tienen una serie de documentos complementarios, no normativos, que se van modificando con el tiempo y que sirven de guía de implementación para diferentes tecnologías y situaciones.

Uno de estos documentos es "Techniques for WCAG 2.0", en el cual se recogen las técnicas que se pueden emplear para cumplir con los criterios de conformidad de las WCAG 2.0.

Digo "que se pueden emplear" porque se admite que puedan usarse otras técnicas diferentes. Por ello, cada cierto tiempo, a medida que evolucionan los productos de apoyo, las diferentes tecnologías y se documentan nuevas técnicas que permiten mejorar la accesibilidad o cumplir con determinados criterios de conformidad, este documento se actualiza incorporándolas. Por ejemplo, en la actualidad se está trabajando en las técnicas relativas a HTML5.

En los documentos "Understanding WCAG 2.0" y "How to Meet WCAG 2.0" se puede consultar qué técnicas (o combinación de técnicas) son suficientes para cumplir con cada criterio de conformidad en función de la tecnología usada (HTML, PDF, Silverlight, etc.) o la situación.

Se enumeran también técnicas recomendables para mejorar la accesibilidad de la página, aunque por sí mismas no permiten cumplir con todos los requisitos del criterio de conformidad (o solo son apropiadas en determinadas circunstancias)

Por último se incluyen fallos comunes, es decir, prácticas de uso común que impiden que se cumpla con uno o varios criterios de conformidad.

Novedades de la actualización del 11 de marzo de 2014

Esta semana (11 de marzo de 2014) se actualizaron los documentos "Techniques for WCAG 2.0" y "Understanding WCAG 2.0".

Comparando las técnicas enumeradas en la nueva versión del documento, con las de la versión anterior ("Techniques for WCAG 2.0" del 5 de septiembre de 2013) las novedades son las siguientes:

Las nuevas técnicas por tanto son todas referidas a WAI-ARIA, y puesto que incluyen ejemplos, son una buena oportunidad para repasar la aplicación de WAI-ARIA y una serie de buenas prácticas.

Las nuevas técnicas están relacionadas con los criterios 1.1.1, 1.3.1, 2.4.4 y 4.1.2 en mayor medida, y algunas también con los criterios 2.4.9, 3.3.1, 3.3.2, 3.3.3, como iré concretando a continuación.

La mayoría son relativas a los atributos aria-label y aria-labelledby, pero también al uso de landmark roles y al uso de otro tipo de roles (role="presentation", role="heading", role="group", role="radiogroup", role="alertdialog", role="alert") y atributos (aria-describedby, aria-valuemin, aria-valuemax, aria-valuenow, aria-pressed).

Descripción de las técnicas y fallos comunes incluidos

"F92: Failure of Success Criterion 1.3.1 due to the use of role presentation on content which conveys semantic information"

Está asociado al criterio de conformidad "1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)"

El role="presentation" oculta los roles nativos de los elementos y sus descendientes a los productos de apoyo, y por tanto se usa solo para marcar elementos puramente decorativos.

Este fallo común hace referencia a la aplicación de role="presentation" a elementos cuya finalidad es transmitir información o relaciones en el contenido.

ARIA4: Using a WAI-ARIA role to expose the role of a user interface component

Es un técnica suficiente asocida a la G10 para cumplir con el criterio de conformidad "4.1.2 Name, Role, Value" (level A) en la situación "Situation D: If creating your own user interface component in a programming language"

Hace referencia al uso del atributo role según la especificación WAI-ARIA. Ejemplifica el uso de roles en una toolbar y en un tree widget.

ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component

Al igual que en el caso anterior, es un técnica suficiente asocida a la G10 para cumplir con el criterio de conformidad "4.1.2 Name, Role, Value ... (level A)" en la situación "Situation D: If creating your own user interface component in a programming language"

Trata del uso de WAI-ARIA para indicar el estado, propiedad o valor de un elemento de forma que sus cambios puedan ser notificados a los productos de apoyo. Lo ejemplifican con el atributo aria-pressed de un botón y con los atributos relacionados con el valor de un slider: aria-valuemin, aria-valuemax, and aria-valuenow.

Como he comentado, ha desaparecido la técnica recomendable "ARIA3: Identifying valid range information with the aria-valuemin and aria-valuemax properties", que precisamente hacía referencia a estos atributos porque ya son tratados en la nueva técnica ARIA5.

ARIA6: Using aria-label to provide labels for objects

Es un técnica suficiente en diversas situaciones para cumplir con el criterio de conformidad "1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)"

Trata del uso del atributo aria-label para etiquetar los objetos.

Advierte que:

  • puede ser desatendida por los productos de apoyo si se usa junto a aria-labelledby
  • anulará otras formas nativas de etiquetado, como el alt de las imágenes o el elemento <label> para etiquetar un campo de formulario

Ejemplifican su uso para identificar landmarks o para distinguir varios del mismo tipo (como os comenté en "Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA)") o para etiquetar una función matemática.

ARIA7: Using aria-labelledby for link purpose

Es un técnica suficiente para cumplir con el criterio de conformidad "2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A) "

Trata de la aplicación del atributo aria-labelledby, que permite aprovechar un elemento de texto de la página (o varios) para etiquetar a otro elemento, en este caso un enlace para aclarar su propósito.

De esta manera, el lector de pantalla, en vez de leer el texto del enlace, leerá los textos que se han identificado en el atributo aria-labelledby mediante su ID (o IDs, de forma concatenada, separados por espacios). Es decir sustituye al texto del enlace.

Se proporcionan varios ejemplos típicos, como es su uso para reemplazar el texto del enlace "Leer más", o para concatenar etiquetas a los enlaces de un recurso en diversos formatos "Memoria del 2002 en PDF" (sin tener que incluir en el texto del enlace más que "PDF").

ARIA8: Using aria-label for link purpose

Es una técnica suficiente para cumplir con el criterio de conformidad "2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)" pero también para cumplir con la versión más restrictiva de este criterio (de nivel AAA) "2.4.9 Link Purpose (Link Only): A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general. (Level AAA)

Trata del uso del atributo aria-label para identificar el propósito de un enlace, como se hacía en la técnica anterior mediante aria-labelledby, pero en este caso cuando no hay elementos visibles que se puedan usar para etiquetarlo. Si los hubiera se debe usar aria-labelledby.

Indican que en algunos productos de apoyo el valor del atributo aria-label (el texto indicado directamente en el atributo) se mostrará en la lista de enlaces en vez del texto utilizado en el enlace.

Los ejemplos que se incluyen son de su aplicación para los típicos enlaces "Leer más".

ARIA9: Using aria-labelledby to concatenate a label from several text nodes

Es una técnica suficiente en combinación con la G82 para cumplir con el criterio de conformidad "1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)" en la situación C "Situation C: If non-text content is a control or accepts user input"

También es una técnica suficiente, en combinación con la G131, para cumplir con el criterio de conformidad "3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)"

Trata del uso del atributo aria-labelledby pero en este caso para etiquetar text inputs en situaciones en las que la etiqueta descriptiva debe construirse a partir de más de un elemento, por ejemplo "[Ampliar tiempo de espera a] [20] [minutos]":



<form>
<p><span id="timeout-label" tabindex="-1">
<label for="timeout-duration">Extend time-out to</label>
</span>
<input type="text" size="3" id="timeout-duration" value="20"
aria-labelledby="timeout-label timeout-duration timeout-unit">
<span id="timeout-unit" tabindex="-1"> minutes</span>
</p>
</form>

Otro ejemplo de uso que incluyen es cuando no nos cabe el label de un campo de texto. Ponen un ejemplo de campos de texto incluidos en una tabla y etiquetados con varios de los encabezados de la misma de forma concatenada.

ARIA10: Using aria-labelledby to provide a text alternative for non-text content

Es una técnica suficiente para cumplir con el criterio de conformidad "1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)", en combinación con otras y en diversas situaciones.

Trata del uso del atributo aria-labelledby pero en este caso para incluir una descripción corta al contenido no textual. Ponen un ejemplo para etiquetar las típicas estrellas que simulan una puntuación. Permite englobarlas todas en un DIV con role="image" y etiquetarlas en su conjunto ("4 de 5").

ARIA11: Using ARIA landmarks to identify regions of a page

Es un técnica suficiente para cumplir con el criterio de conformidad "1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)" en la situación A "Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable"

También es un técnica suficiente para cumplir con el criterio de conformidad "2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)"

Trata el uso del landmarks roles para identificar partes de una página como os contaba en "Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA)"

ARIA12: Using role=heading to identify headings

Es un técnica suficiente para cumplir con el criterio de conformidad "1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)" en la situación A "Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable"

Habla del uso de role="heading" para identificar encabezados y aria-level para indicar su nivel. Advierten que siempre es preferible usar H1, H2, etc. pero incluyen algún ejemplo en el que puede ser útil, como por ejemplo en encabezados con un nivel H7 o superior (la especificación HTML incluye hasta H6)

ARIA13: Using aria-labelledby to name regions and landmarks

Es un técnica suficiente para cumplir con el criterio de conformidad "1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)" en la situación A "Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable"

Aborda el uso del atributo aria-labelledby para proporcionar nombre a los landmark roles.

ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used

Es una técnica suficiente del criterio de conformidad "4.1.2 Name, Role, Value ...(level A)" en la situación A "Situation A: If using a standard user interface component in a markup language (e.g., HTML)"

Aborda el uso de aria-label para proporcionar un nombre accesible a elementos que no tienen una etiqueta visible, por ejemplo por el enfoque de diseño elegido (incluyen el ejemplo de etiquetar la "X" que sirve para cerrar una capa), o porque el elemento no admite el etiquetado nativo (un div de tipo contentEditable)

ARIA15: Using aria-describedby to provide descriptions of images

Es una técnica suficiente para cumplir con el criterio de conformidad "1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)", en combinación con otras, para incluir contenido textual alternativo largo en la situación B "Situation B: If a short description can not serve the same purpose and present the same information as the non-text content (e.g., a chart or diagram)".

Trata del uso del atributo aria-describedby para dar descripciones largas a las imágenes cuando un breve texto alternativo no resulta suficiente. Su función es similar al longdesc, pero lo que incluimos no es una url, sino el ID (o IDs) de los elementos de la página que proporcionan la descripción de la imagen.

Señalan que en la fecha de redacción (octubre 2013) algunos productos de apoyo leen la descripción definida por el atributo aria-describedby después de leer el alt de la imagen, sin mediar activación de los usuarios, mientras que la mayoría de las implementaciones de longdesc requieren que el usuario solicite la acción explícita de leer la descripción adicional.

En el artículo "Ayuda contextual de los formularios más accesible con "aria-describedby" (WAI-ARIA)" os hablaba de otro uso muy útil de este atributo.

ARIA16: Using aria-labelledby to provide a name for user interface controls

Es un técnica suficiente para cumplir con el criterio de conformidad "1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)" en la situación A "Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable"

También es una técnica suficiente del criterio de conformidad "4.1.2 Name, Role, Value ...(level A)" en la situación A "Situation A: If using a standard user interface component in a markup language (e.g., HTML)"

Trata del uso del atributo aria-labelledby pero en este caso para etiquetar campos de formulario.

Se detallan las diferencias entre aria-labelledby y el elemento <label>

  • aria-labelledby can reference more than one text element; label can only reference one.
  • aria-labelledby can be used for a variety of elements while the label element can only be used on form elements.
  • clicking on a label focuses the associated form field. This does not occur with aria-labelledby. If this behaviour is required then use label or implement this functionality using scripting.

Note that as of December 2013, label has better support than aria-labelledby, especially in older browsers and assistive technologies.

ARIA17: Using grouping roles to identify related form controls

Es un técnica suficiente para cumplir con el criterio de conformidad "1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)" en la situación A "Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable"

También es una técnica suficiente junto a la G131 para cumplir con el criterio de conformidad "3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)"

Trata del uso de roles de agrupación (role=group, role="radiogroup") para identificar controles del formulario relacionados.

ARIA18: Using aria-alertdialog to Identify Errors

Es un técnica suficiente para cumplir con el criterio de conformidad "3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)" en la situación B "Situation B: If information provided by the user is required to be in a specific data format or of certain values."

También es un técnica suficiente para cumplir con el criterio de conformidad "3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)" en varias situaciones.

Trata del uso role="alertdialog" para identificar una notificación modal, que debe cumplir con ciertos requisitos:

  • aria-label or aria-labelledby attribute gives the alertdialog an accessible name.
  • aria-describedby provides a reference to the text of the alert.
  • The alertdialog contains at least one focusable control, and the focus should move to that control when the alertdialog opens.
  • The tab order is constrained within the alertdialog whilst it is open.
  • When the dialog is dismissed, the focus moves back to the position it had before the dialog opened, if possible.

ARIA19: Using ARIA role=alert or Live Regions to Identify Errors

Es un técnica suficiente para cumplir con el criterio de conformidad "3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)" en la situación B "Situation B: If information provided by the user is required to be in a specific data format or of certain values."

Trata del uso del role="alert" para notificar errores, por ejemplo, los errores de validación al rellenar un campo.

El uso de role="alert" es equivalente a usar aria-live="assertive". Os hablé del atributo aria-live y las live regions en Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente

ARIA 1 y ARIA 2

Por tener recopiladas en un mismo artículo todas las técnicas ARIA, incluyo a continuación la descripción de las técnicas que se mantienen respecto a la versión anterior.

ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls

Es un técnica recomendable del criterio de conformidad 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A).

También es una técnica suficiente junto a la G131 para cumplir con el criterio de conformidad 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)

Trata del uso general de la propiedad aria-describedby para propocionar una descripción a un elemento. Uno de ellos es la asociación de la ayuda contextual de un campo con dicho campo, un tema que traté en "Ayuda contextual de los formularios más accesible con "aria-describedby" (WAI-ARIA)"

ARIA2: Identifying a required field with the aria-required property

Es un técnica recomendable del criterio de conformidad 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A).

También es una técnica suficiente junto a la G131 para cumplir con el criterio de conformidad 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A), aunque esta asociación no se indique en la ficha de la técnica, sí se indica en la del criterio 3.3.2

Trata el uso del atributo aria-required para indicar que un campo de formulario es obligatorio. Es beneficioso incluso aunque se indique con un asterisco o un texto "obligatorio" en el label del campo.

Artículos relacionados

Servicios de accesibilidad que ofrezco como consultora freelance


HTML5 y accesibilidad: nuevos tipos de input, atributos asociados y validación nativa

$
0
0

Una de las novedades de HTML5 son los nuevos tipos de input en los formularios y los nuevos atributos de los mismos.

En (X)HTML tenemos input de tipo text, password, checkbox, radio, submit, image, reset, button, hidden, file. Consultar Elemento input en la especificación HTML 4.01 del W3C.

En HTML5 tenemos además input de tipo search, tel, url, email, datetime, date, month, week, time, datetime-local, number, range, color.

Además hay nuevos atributos bastante útiles como: pattern (el valor del campo debe cumplir un patrón que se define mediante expresiones regulares), placeholder (para incluir un texto por defecto en el campo), required (campo obligatorio), autofocus (el campo tiene por defecto el foco), etc.

Consultar Elemento input en la especificación HTML5 del W3C.

Dos ventajas importantes que supone utilizar estos nuevos tipos y atributos de campos de formulario son:

En este artículo voy a hablaros de la accesibilidad en relación con estos nuevos tipos de input de HTML5 y algunos de sus atributos asociados, y para ello tendremos que tener en cuenta:

Y en base a ello extraeremos unas conclusiones para hacer los formularios de HTML5 accesibles para todos.

Soporte en diferentes navegadores y versiones

Lo primero que hay que decir, y que es bastante relevante, es que si el navegador no comprende uno de los nuevos input lo interpreta como un campo de type="text" y por tanto siempre podremos rellenarlo.

Para consultar el actual soporte de los nuevos tipos y atributos de campos de formulario de HTML5 podéis consultar dos webs:

Como se puede comprobar en estas webs, en las últimas versiones de los navegadores se comienza a soportar la mayoría de los nuevos tipos de campos, pero el soporte no es generalizado ni total, especialmente en los dispositivos móviles. En versiones anteriores el soporte puede ser nulo (por ejemplo en Explorer 9 o anterior) o reducido. Lo mismo pasa con los nuevos atributos. En algunos casos el soporte es parcial, por ejemplo se puede reconocer un nuevo tipo de campo pero no realizarse la validación nativa.

Soporte en diferentes lectores de pantalla con diferentes navegadores

Un recurso imprescindible es html5accessibility.com, que se actualiza periódicamente.

Soporte de accesibilidad de los nuevos input y propiedades de HTML5 en las últimas versiones de Chrome, Opera, Firefox, Explorer

Imagen de html5accessibility.com

Os voy a poner varios ejemplos de soporte en NVDA 2014.1, JAWS15 y VoiceOver para Explorer 11, Firefox 27 y Chrome 33 en un formulario sencillo implementado en HTML5:

Formulario con tres campos y un botón enviar. El primer campo es de tipo teléfono tiene los atributos required y pattern y una ayuda contextual bajo el campo. El segundo campo es de tipo url y tiene el atributo required. El tercer campo es de tipo email, tiene el atributo required y placeholder.

El código es:


<label for="telefono">Ejemplo de campo teléfono, obligatorio, con patrón de datos,
ayuda contextual asociada: </label>
<input type="tel" id="telefono" name="telefono" required aria-describedby="descripcionContra"
pattern='[\+]\d{2}[\(]\d{2}[\)]\d{4}[\-]\d{4}'>
<p id="descripcionContra" class="ayuda">Formato: +99(99)9999-9999</p>

<label for="url">Ejemplo de campo url obligatorio: </label>
<input type="url" id="url" name="url" required size="50">

<label for="email">Ejemplo de campo email obligatorio y texto por defecto: </label>
<input type="email" id="email" name="correo" required placeholder="midireccion@gmail.com" size="50">

<input type="submit" name="Enviar" id="Enviar" value="Enviar">

NVDA 2014.1

Chrome 33

Los campos son leídos de la siguiente manera:

  • Campo teléfono: [label] edición requerido formato +99(99)9999-9999 en blanco
  • Campo URL: [label] edición requerido en blanco
  • Campo email: [label] edición requerido midireccion@gmail.com en blanco

En cuanto a la validación, no lee el texto del mensaje de error, simplemente vuelve a leerme el campo (tal y como la he indicado antes) que ha cogido el foco por dar un error.

Por tanto:

  • No me anuncia de que tipo es el campo (teléfono, url, email)
  • Sí me anuncia que es un campo requerido.
  • Sí me anuncia el contenido de ejemplo del campo incluido con placeholder, aunque no me da información concreta de que es un ejemplo.
  • No me anuncia que el campo requiere un formato específico incluido con el atributo pattern, pero sí que me lee la ayuda contextual incluida al pie del campo y asociada mediante aria-describedby.
  • No me anuncia el mensaje de error de la validación, solo vuelve al leer el campo porque ha cogido el foco.

Explorer 11

Los campos son leídos de la siguiente manera:

  • Campo teléfono: [label] edición formato +99(99)9999-9999 en blanco
  • Campo URL: [label] edición en blanco
  • Campo email: [label] edición en blanco

En cuanto a la validación, no lee el texto del mensaje de error, simplemente vuelve a leerme el campo (tal y como la he indicado antes) que ha cogido el foco por dar error.

En resumen:

  • No me anuncia de que tipo es el campo (teléfono, url, email)
  • No me anuncia que es un campo requerido.
  • No me anuncia el contenido de ejemplo del campo incluido con placeholder.
  • No me anuncia que el campo requiere un formato específico incluido con el atributo pattern, pero sí que me lee la ayuda contextual incluida al pie del campo y asociada mediante aria-describedby.
  • No me anuncia el mensaje de error de la validación, solo vuelve al leer el campo porque ha cogido el foco

Firefox 27

Los campos son leídos de la siguiente manera:

  • Campo teléfono: [label] edición entrada inválida requerido tiene autocompletado formato +99(99)9999-9999 en blanco
  • Campo URL: [label] edición entrada inválida requerido tiene autocompletado en blanco
  • Campo email: [label] edición entrada inválida requerido tiene autocompletado blanco

En cuanto a la validación, lee el texto del mensaje de alerta "Alerta Rellene este campo", "Alerta Ajuste el formato al solicitado" pero no me indica qué campo ha cogido el foco y por tanto ha dado error.

Por tanto:

  • No me anuncia de que tipo es el campo (teléfono, url, email)
  • Sí me anuncia que es un campo requerido.
  • No me anuncia el contenido de ejemplo del campo incluido con placeholder.
  • No me anuncia que el campo requiere un formato específico incluido con el atributo pattern, pero sí que me lee la ayuda contextual incluida al pie del campo y asociada mediante aria-describedby.
  • Me anuncia el mensaje de error de la validación pero no me indica qué campo ha dado el error y ha cogido por tanto el foco.

JAWS

El comportamiento es muy similar al visto con NVDA:

  • Chrome 33 y Firefox anuncian el atributo required pero Explorer 11 no.
  • Chrome 33 y Explorer 11 no anuncian el mensaje de error, solo leen en campo que coge el foco. Firefox 27 lee el mensaje de alerta pero no identifica el campo que ha dado error (aunque sí que le devuelve el foco)
  • Chrome 33 lee el contenido del atributo placeholder.
  • Ninguno indica de que tipo es el campo (email, url, teléfono)
  • Ninguno me indica que teléfono tiene un formato asociado con pattern, pero sí leen la ayuda contextual asociada con aria-describedby.

Voice Over

En un iPad, tanto en Chrome como en Safari, lee los campos de la siguiente manera:

  • Campo teléfono: [label] campo de texto para varias líneas obligatorio formato +99(99)9999-9999 pulse dos veces para editar
  • Campo URL: [label] campo de texto para varias líneas obligatorio pulse dos veces para editar
  • Campo email: [label] midireccion@gmail.com campo de texto para varias líneas obligatorio pulse dos veces para editar

En este caso ninguno de los navegadores hace la validación nativa, simplemente envían el formulario.

Por tanto:

  • No me anuncia de que tipo es el campo (teléfono, url, email)
  • Sí me anuncia que es un campo requerido.
  • Sí me anuncia el contenido de ejemplo del campo incluido con placeholder aunque no me indica concretamente que es un texto de ejemplo.
  • No me anuncia que el campo requiere un formato específico incluido con el atributo pattern, pero sí que me lee la ayuda contextual incluida al pie del campo y asociada mediante aria-describedby.
  • No se produce validación nativa del navegador.

Conclusiones

  • No podemos confiar solo en el atributo required de HTML5 para indicar que un campo es obligatorio. Deberemos apoyarnos también en aria-required. Si incluimos los dos required aria-required="true", Chrome y Firefox NO dan la información por duplicado y Explorer sí nos anunciará que el campo es obligatorio. No está de más recordar que la forma de que a ningún usuario le pase desapercibido que el campo es obligatorio es incluir en el texto de la etiqueta (obligatorio), aunque en este caso la información sí se daría por duplicado.
  • Si incluimos un patrón de datos con pattern deberemos siempre incluir como ayuda contextual el patrón requerido y asociar esta ayuda con el campo mediante el atributo aria-describedby.
  • En muchos casos no se anuncia el texto por defecto del campo incluido con placeholder, por lo que sigue siendo mejor práctica incluirlo como un texto de ejemplo bajo el campo, asociado igualmente al campo con aria-describedby
  • Hemos visto que en ningún caso se anuncia de que tipo es el nuevo campo (url, email, teléfono) pero esto no tiene porque suponer un problema (incluso si el navegador no soporta el nuevo tipo de input, pues lo interpretará como un type="text") si la etiqueta es clara y por supuesto, siempre incluida en un label y asociada al ID del campo que etiqueta mediante el atributo for.
  • No podemos confiar únicamente en las validaciones nativas del navegador, tanto por compatibilidad con los navegadores y versiones de navegadores que no las soportan, como porque no siempre los productos de apoyo anuncian los mensajes de error o los campos que los han producido.

    Recordemos que las WCAG 2.0 indican como requisito de nivel A (criterio de conformidad 3.3.1) que hay que identificar el campo que ha dado el error y describir el error con texto, y de ser posible proporcionar sugerencias para su corrección (criterio de conformidad 3.3.3).

    Por ello, debemos tener en cuenta:

    • Existen maneras de detectar si el navegador soporta la validación nativa con librerías como Modernizr, y en caso contrario usar la validación javascript.
    • Tenemos que asegurarnos de que todos los usuarios podrán saber qué campo dio error, el mensaje de error y sus posibles sugerencias de corrección.

      Las WCAG 2.0 admiten diferentes técnicas como el uso de alerts que informen del error y retornen el foco al campo que lo ha provocado; o desde mi punto de vista más recomendable insertar una zona de errores al comienzo del formulario implementada como se indica en la SCR32: Providing client-side validation and adding error text via the DOM, a la que se debe remitir el foco o asegurarse de que será anunciada a los usuarios de lector de pantalla mediante el uso de role="alert" (ver descripción y ejemplo en la técnica ARIA19: Using ARIA role=alert or Live Regions to Identify Errors)

    • Y por supuesto, siempre es una buena práctica, no solo por accesibilidad sino por seguridad, hacer también después la validación desde la parte servidor.

Artículos relacionados

Servicios de accesibilidad que ofrezco como consultora freelance

Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online

$
0
0

En este artículo os ofrezco dos herramientas para ayudaros a que vuestras imágenes sean accesibles.

Mapa de decisión para proporcionar textos alternativos adecuados a las imágenes de tu web

Mapa de decisión para proporcionar textos alternativos adecuados a las imágenes

Descripción detallada de la imagen

Es un árbol de decisión de consulta rápida.

En función del tipo de imagen, su contexto y su función, recomienda la forma adecuada de incluir un texto alternativo a esa imagen.

Cada resultado del árbol incluye ejemplos y es un enlace a la página de resultados detallada de la segunda herramienta, el wizard online.

El mapa de decisión está en formato PNG e incluye una descripción detallada accesible.

Ir al mapa de decisión (PNG, 614KB)

Wizard online para adecuar el texto alternativo de tus imágenes al tipo de imagen, su contexto y función

Es un formulario online, basado en el mapa de decisión, que os guía, según el tipo de imagen, su contexto y su función, hasta llegar a una página de resultado final, con ejemplos, recursos y técnicas a usar en ese caso concreto.

Ir al wizard

Sobre las herramientas

Posiblemente uno de los requisitos de accesibilidad más conocidos es que las imágenes de una página web deben tener un texto alternativo.

Sin embargo, uno de los errores más habituales, incluso en los sitios que han trabajado la accesibilidad de sus páginas, es encontrar textos alternativos inadecuados porque no se ha tenido en cuenta el tipo de imagen, su función o el contexto en el que se inserta.

Es más, incluso en los validadores automáticos de accesibilidad se reportan a veces falsos errores porque no se tienen en cuenta las diferentes casuísticas que se pueden dar (ver Falsos errores de validadores automáticos de accesibilidad basados en las WCAG 2.0 )

Esto me hizo pensar en idear alguna herramienta que permitiera consultar de forma sencilla la técnica más recomendable para incluir un texto alternativo en base al tipo de imagen, su propósito y función.

Las herramientas están basadas en el documento de apoyo de las WCAG 2.0 para comprender el criterio de conformidad 1.1.1 "Non-text Content: Understanding SC 1.1.1" donde se explican los diferentes casos y las técnicas o combinación de técnicas que se pueden aplicar.

El objetivo es divulgar estas buenas prácticas y facilitar su compresión y su aplicación. Se han seleccionado las técnicas comúnmente utilizadas, las más compatibles y mejor soportadas. Las técnicas que se proponen no incluyen técnicas alternativas de WAI-ARIA o HTML5, pero como recursos complementarios se irán proponiendo:

Cualquier comentario, propuesta o duda sobre las herramientas será muy bien recibida.

Mi objetivo es sacar tiempo, lo cual últimamente no es fácil, para proporcionarlas también en inglés a corto plazo, pero si alguien se anima a echar una mano en este sentido tendrá además de los créditos, mi eterno agradecimiento :)

Otros artículos y herramientas relacionadas

Servicios

Consultoría y formación en accesibilidad web y PDF

Novedades de Adobe Acrobat XI Pro relacionadas con la accesibilidad de los PDF

$
0
0

Después de probar Adobe Acrobat XI Pro os cuento aquellas novedades de interés para los que nos dedicamos a convertir PDF en PDF accesibles.

Nueva herramienta "Establecer texto alternativo"

Dentro de las herramienta de accesibilidad nos encontramos con una opción nueva "Establecer texto alternativo" que nos va a simplicar mucho la vida:

Ventana emergente 'Establecer texto alternativo' de Adobe Acrobat XI Pro. Tiene un textarea para incluir texto alternativo y un check para indicar que es una imagen decorativa, para cada una de las imágenes del documento.

Hasta ahora podíamos incluir el texto alternativo de una imagen en sus "Propiedades". Para ello teníamos que seleccionar una a una cada imagen, bien en el panel Etiquetas, bien desde la vista "orden de lectura".

De la misma manera, podíamos convertir una imagen en "artifacto" (imagen decorativa que no será leída por los lectores de pantalla) seleccionando cada imagen en la vista "orden de lectura" y pulsando "fondo", o bien en el panel de Etiquetas seleccionado el contenido de su etiqueta "Figure" y la opción "Cambiar etiqueta a artifacto".

La nueva herramienta nos da una tercera manera mucho más eficaz: detecta todas las imágenes del documento y podemos ir indicando rápidamente para cada una de ellas su texto alternativo o si es decorativa.

Advertencia: no presupongas que todas las imágenes serán realmente imágenes ni que todas las imágenes aparecerán en esta ventana, primero tendrás que comprobar que el documento está correctamente etiquetado. A veces hay imágenes no etiquetadas como "Figure" y a veces hay contenido etiquetado como "Figure" que no es una imagen.

Nuevas opciones en la herramienta "Retocar orden de lectura"

Los que estéis familiarizados con la conversión de PDF en PDF accesibles notaréis en seguida las mejoras en la herramienta "Retocar orden de lectura" que es una de las que más utilizamos.

Ventana 'Retorcar orden de lectura' de Adobe Acrobat XI Pro con las nuevas opciones destacadas: botones para encabezados 4,5 y 6, mostrar orden o tipo de contenido, mostrar elementos en un único bloque

Las nuevas opciones son:

  • Posibilidad de marcar encabezados de nivel 4, 5 y 6. Antes solo podíamos marcar los de nivel 1, 2 y 3, el resto de niveles había que modificarlos en las propiedades de la etiqueta.
  • Mostrar orden o tipo de contenido. Hasta ahora, en la vista "orden de lectura" cada contenido aparecía resaltado con un número (su orden de lectura). En la nueva versión de Acrobat podemos indicar que nos muestre, no el número del orden de lectura, sino el tipo de contenido que es (el nombre de la etiqueta, tal y como se ve en la imagen de ejemplo) lo cual resulta muy útil. Pero yo me pregunto, ¿por qué han puesto las opciones como excluyentes? Me hubiera gustado poder ver simultáneamente las dos.
  • La opción "Mostrar elementos similares en un único orden" está marcada por defecto y se corresponde con el comportamiento de las versiones anteriores. En la nueva versión si, por ejemplo, un texto largo está compuesto por varios párrafos, podremos verlo como un único elemento como hasta ahora o desmarcar el check y ver las diferentes etiquetas de párrafo en las que se subdivide. Esto es de gran ayuda, pues por fin vamos a poder seleccionar texto dentro de un párrafo, pulsar el botón "texto" y que efectivamente este se divida en varios párrafos. Es muy necesario para poder marcar dentro de un párrafo texto en otro idioma, abreviaturas, etc. y que ahora era casi obligatorio hacerlo desde el panel Etiquetas, o usar algún truco un poco engorroso.

Mejoras en el asistente para hacer más accesibles los PDF

El asistente se llamaba "Crear archivos PDF accesibles" y ahora se llama "Hacer accesible":

Ventana del asistente 'Hacer accesible' de Adobe Acrobat XI Pro. Tiene tres pasos: preparar, establecer etiquetas e idioma, ejecutar comprobar de accesibilidad

El asistente hasta ahora no permitía realizar acciones necesarias como indicar el idioma del documento o incluir el texto alternativo de las imágenes (te decía que debías hacerlo manualmente)

Con la nueva versión ya puedes desde el asistente indicar el idioma o incluir el texto alternativo a las imágenes (mediante la herramienta vista anteriormente).

Es muy importante advertir que este asistente te ayuda a hacer los PDF más accesibles, pero que estas acciones no son las únicas necesarias: tendrás que revisar el etiquetado, el orden de lectura, los vínculos, las tablas, etc.

Validador de accesibilidad

Es el mayor cambio, una gran mejora y posiblemente una razón de peso para actualizarse a la nueva versión.

En Acrobat X Pro se podía elegir entre validar de acuerdo a las WCAG 1.0, las WCAG 2.0 (la validación era en base a la versión de 2006, no la definitiva de 2008), la Seccion 508 o la validación por defecto Adobe PDF.

Ahora hay una única validación dividida en cuatro apartados:

  • Documento:
    Asistente de Adobe Acrobat XI Pro. Seleccionada la categoría Documento
  • Contenido de la página:
    Asistente de Adobe Acrobat XI Pro. Seleccionada la categoría Contenido de la página
  • Formularios, tablas y listas:
    Asistente de Adobe Acrobat XI Pro. Seleccionada la categoría Formularios, tablas y listas
  • Texto alternativo y título:
    Asistente de Adobe Acrobat XI Pro. Seleccionada la categoría Texto alternativo y título

Ahora puedes evaluar (o no) por 32 criterios individuales basados en las WCAG 2.0 y el estándar PDF/UA. Sobre PDF/UA indicar que NO se puede guardar, exportar o validar el PDF según el nuevo estándar (más información en PDF/UA. Descripción de la norma. Comparativa y relación con las WCAG 2.0 ).

Por otro lado, la mejora del resultado de la validación de accesibilidad es enorme y una gran alegría.

Es muy importante recordar que el validador de accesibilidad no asegura la accesibilidad del PDF, porque hay muchos requisitos que no pueden evaluarse automáticamente y otros que necesitan siempre de una revisión manual.

Pero es una herramienta de gran utilidad y ahora mucho más.

El resultado de la validación deja de ser un horror para convertirse en un árbol:

Resultado del comprobador de accesibilidad de Adobe Acrobat XI Pro. Un árbol con 7 elementos: documento, contenido de página, formularios, texto alternativo, tablas, listas, encabezados

Cuando despliegas el árbol puedes ver todas las validaciones realizadas. Se indica si han sido correctas, ha habido problemas o se requiere una validación manual. Aquellas validaciones que han dado un problema tienen a su vez un árbol con todos los elementos erróneos. Una de las grandes novedades es su menú contextual:

Resultado del comprobador de accesibilidad de Adobe Acrobat XI Pro. Menú contextual de una imagen sin texto alternativo, tiene las opciones: solucionar, omitir regla, explicar, mostrar en panel Contenido o en panel Etiquetas, comprobar de nuevo, mostrar informe, opciones

Maravilloso, ¿verdad?

  • Solucionar: en el ejemplo del pantallazo, al estar seleccionada una imagen sin texto alternativo, nos abrirá la herramienta ya descrita para indicar el texto alternativo.
  • Omitir regla: no marca este error en el árbol del resultado de la validación.
  • Explicar: abre una página de ayuda que explica el error, cómo solucionarlo y los criterios de conformidad de las WCAG 2.0 a los que hace referencia. El algunos casos no hay un criterio de las WCAG 2.0 asociado, por ejemplo la asignación de caracteres Unicode, que sí trata el estándar PDF/UA, aunque curiosamente no hacen referencia al mismo.
  • Mostrar en panel Contenido: te abre el panel Contenido con el contenido del elemento que ha dado error seleccionado.
  • Mostrar en panel Etiquetas: te abre el panel Etiquetas con la etiqueta del elemento que ha dado error seleccionado, y esto es muy útil, la verdad.
  • Comprobar de nuevo: vuelve a hacer la comprobación.
  • Mostrar informe: un informe útil de verdad, no como el actual:
    Informe de accesibilidad de Adobe Acrobat XI Pro. Los datos se estructuran en tres columnas: nombre de la regla, estado y descripción.
  • Opciones: abre la ventana de configuración del validador de accesibilidad.

Cosas que no cambian

Dos cosas que me molestan mucho siguen igual:
  • Los elementos del desplegable para seleccionar el tipo de etiqueta siguen sin estar ordenados alfabéticamente. Una de esas cosas absurdas a las que te acabas acostumbrando:

    Desplegable para elegir tipo de etiqueta en Adobe Acrobat XI Pro desordenadas alfabéticamente.

    Lo que pasa en realidad es que siguen ordenadas por su nombre en inglés.

  • Sigue sin funcionar "control+z" para poder deshacer un cambio en el árbol de etiquetas, como borrar una sin querer (ahhh, se siente, estate más atento la próxima vez...)

Actualizarse o no actualizarse

Cuando salió la versión Adobe Acrobat X Pro no le veía muchas ventajas frente a la versión 9, no me parecía necesario actualizarse. Aunque la verdad es que el gran cambio en la interfaz que hubo en la versión X, con las herramientas a la derecha, hizo el trabajo más ágil. También es verdad que incluyeron la opción de guardar y validar como PDF/A-2.

Pero esta vez no tengo dudas, los cambios de la versión XI eran bastante necesarios y harán nuestro trabajo más fácil. Personalmente creo que merece la pena actualizarse a la nueva versión.

Artículos relacionados:

Jornada sobre Recursos Tecnológicos para la Inclusión Social

$
0
0

Dentro de una semana tendré el placer de participar en la Jornada sobre Recursos Tecnológicos para la Inclusión Social que organiza la Universidad de Alicante y la Fundación Vodafone España. La cita es el 7 de octubre en el Salón de Actos de la Escuela Politécnica Superior de la Universidad de Alicante.

Con la intención de concienciar, formar y sensibilizar hacia una cultura de inclusión digital, los objetivos de la jornada serán:

  • Comprender la importancia de las Tecnologías de la Información y de la Comunicación (TIC) para las personas con discapacidad, prestando atención a las nuevas barregas digitales que se introducen.
  • Conocer la importancia de la investigación en TIC Accesibles.
  • ¡Podrás ver en acción las Google Glass!
  • Aprender buenas y malas prácticas para la creación de documentos electrónicos accesibles.
  • Aplicar conceptos de TIC Accesibles a la enseñanza.

Mi intervención será de 16:00 a 17:30 impartiendo el taller "Buenas y malas prácticas de accesibilidad en documentos electrónicos".

Enseñaré a hacer documentos más accesibles para todos: las buenas prácticas a seguir y las malas prácticas a evitar. Aprenderemos por qué son buenas o malas prácticas, a quiénes benefician o a quiénes perjudican y en qué contextos.

He preparado muchos ejemplos concretos pero también aprenderemos qué siempre existe una manera de aplicar estas buenas prácticas independientemente del tipo de documento o programa y versión que estemos utilizando.

Podéis consultar el programa en la web de la Jornada.

La inscripción es gratuita aunque el aforo limitado, por ello es necesario cumplimentar el formulario de inscripción a la jornada.

Si no puedes acercarte podrás seguirlo en directo pues se retransmitirá por streaming. La retransmisión comenzará el día 7 de octubre a las 10:00. Ir a la página de la retransmisión en directo

¡Os esperamos!

Documentos electrónicos accesibles: word, excel, powerpoint, openoffice, pdf y más

$
0
0

El día 7 de octubre impartí el taller "Buenas y malas prácticas de accesibilidad en documentos electrónicos" en la Universidad de Alicante, en el marco de la Jornada sobre Recursos Tecnológicos para la Inclusión Social.

Os dejo la presentación y el vídeo del taller.

Vídeo del taller "Buenas y malas prácticas de accesibilidad en documentos electrónicos"

La dirección en la que se han publicado los vídeos de todas las ponencias es: Videos "Jornada sobre recursos tecnológicos para la inclusión social

Presentación del taller "Buenas y malas prácticas de accesibilidad en documentos electrónicos"

Presentación en SlideShare

Os recomiendo también la guía que ha publicado el CENTAC "Guía para elaborar documentación digital accesible. Recomendaciones para Word, PowerPoint y Excel de Microsoft Office 2010", Lourdes Moreno, Paloma Martínez y Yolanda González, 2014.

Artículos relacionados:

Validador automático de accesibilidad Tanaguru

$
0
0
Tanaguru

Estos días he estado probando el validador de accesibilidad Tanaguru.

En este artículo os voy a explicar cómo funciona y qué me ha parecido, porque tiene cosas bastante interesantes.

¿Qué es Tanaguru?

Es una herramienta de evaluación automática de la accesibilidad web. Es una aplicación web opensource (ver proyecto en GitHub) que puedes desplegar en tu propio servidor o bien acceder a las demos que tienen publicadas online:

La aplicación web está disponible actualmente en inglés y en francés, pero ya se está traduciendo al español, de hecho puedes unirte y colaborar.

Panel de control

En el panel de control tendrás tus diferentes proyectos, en la "free trial" será uno.

Panel de control de Tanaguru. Se lista un proyecto con su URL y un pantallazo del mismo. El listado puede ordenarse

Panel de control "My Projects" de Tanaguru

Dentro del proyecto tendrás acceso a las diferentes auditorías que hayas realizado en él.

Tipos de auditorías

Hay disponibles cuatro tipos de auditorías.

Auditar páginas

Puedes evaluar entre 1 y 10 páginas.

Pantalla de opciones de la auditoria de páginas de Tanaguru. A continuación se describe las opciones que presenta

Auditoría de páginas en Tanaguru

A continuación puedes indicar el estándar y el nivel respecto al cual quieres evaluar la página. En este punto hace falta detenerse un poco, porque puede resultar confuso que las opciones disponibles actualmente sean RGAA 2.2 y Accessiweb 2.2, aunque ya están desarrollando la evaluación de acuerdo a las WCAG 2.0

La norma de certificación para los sitios web públicos en Francia es el Référentiel Général d'Accessibilité pour les Administraciones (RGAA), que define el conjunto de requisitos y el proceso de evaluación para determinar si un sitio web es accesible. El RGAA utiliza las pautas WCAG 2.0 como base y define una serie de requisitos adicionales para la accesibilidad. El elemento más notable en el RGAA es la inclusión de pruebas unitarias que definen la forma de determinar el cumplimiento de cada requisito. Esto es para asegurar que la conformidad con la norma en su conjunto se puede probar en un sitio a través de la ejecución de esta serie de pruebas unitarias.

Fuera de los requisitos oficiales RGAA para sitios web del sector público, BrailleNet proporciona el estándar de certificación AccessiWeb que conduce a una etiqueta de certificación que se puede colocar en un sitio web. Similar a RGAA, la etiqueta AccessiWeb ofrece una certificación del nivel de accesibilidad de un sitio web. Las normas AccessiWeb se basan en los requisitos WCAG 2.0 pero se reestructuran de una forma diferente en torno a una serie de recomendaciones. La conformidad con las normas AccessiWeb no es requerida por ley, pero es ampliamente reconocida dentro de Francia como marca de certificación que demuestra un alto grado de cumplimiento.

En la auditoría por páginas además podemos indicar opcionalmente el "id", "class" o "role" de las tablas de datos y de las tablas de presentación, así como de de las imágenes informativas y decorativas, por si quieres que se tenga en cuenta en la evaluación. De este modo, por ejemplo, la aplicación podría encontrar errores de forma automática como que una tabla de presentación tenga un "summary" o que una imagen decorativa tenga un texto alternativo, en vez de sugerir simplemente que revises esos puntos manualmente.

También puedes indicarle si en el sitio hay una funcionalidad que permita mejorar el contraste cargando otra CSS de alto contraste. Si no es así evaluará automáticamente el contraste de color del texto con el fondo.

Auditar sitio completo

Permite evaluar un sitio completo. Además de las opciones descritas en la auditoría de páginas, también se puede:

  • Indicar la profundidad de la evaluación, estableciendo el límite por tiempo, número de páginas o nivel de profundidad.
  • Incluir y excluir URLs

Auditar ficheros

Esto no es lo que parece, NO es evaluación de documento PDF, Word, etc. Simplemente es que se puede subir el HTML como un fichero en vez de auditar por URL.

Auditar escenario

Esta opción es muy interesante porque te va permitir evaluar páginas que requieren autenticación, o una serie de páginas que forman parte de un proceso, o incluso diferentes estados de una página.

En la pantalla de auditoría de escenarios hay dos campos: nombre del escenario y campo para adjuntar el escenario

Pantalla de "Auditoría de escenario" de Tanaguru

Como se observa en la imagen tienes que adjuntar un fichero, en concreto un fichero JSON.

¿Cómo generas el escenario y dicho fichero? Pues tienes que instalarte la extensión de Firefox "SeBuilder".

Pantalla de SeBuilder. Indica la URL en la que estás y tiene dos botones con los nombres Selenium1 y Selenium2

SeBuilder, extensión de Firefox

Vas a la página en la que quieres comenzar, pulsas el botón "Selenium2" y comienzas a navegar. Cuando terminas pulsas "Stop recording" y desde el menú "File" lo exportas a JSON. Es este fichero el que tienes que importar en Tanaguru.

Hay más información sobre los escenarios en la documentación de la aplicación.

Resultados

Los resultados de la auditoría de una página se muestran de la siguiente manera:

Pantalla de resultados de la validación de una página según el estándar RGAA 2.2. A continuación se detalla el contenido que presenta

Pantalla de resultados de la auditoría de una página

Los resultados se pueden exportar en "ods", "cvs" y "pdf" y son los siguientes:

  • Datos estadísticos:

    • porcentaje general de cumplimiento del estándar y nivel elegido
    • gráfica y porcentaje de requisitos cumplidos, fallidos, no aplicables, que necesitan validación manual o no testeados
    • gráfica de barras con el porcentaje desglosado por cada uno de los temas de la evaluación
  • Detalle de los resultados, que pueden filtrarse o plegarse y desplegarse. Los resultados se agrupan en 12 o 13 temas en función de si validamos de acuerdo a las RGAA o las Accessiweb (actualmnte están desarrollando la evaluación de acuerdo a las WCAG 2.0)

    • Temas en la evaluación de acuerdo a las RGAA (como se observa tienen un problema con la traducción y aparecen en francés)

      1. Cadres
      2. Couleurs
      3. Formulaires
      4. Images
      5. Multimédia
      6. Navigation
      7. Présentation
      8. Scripts
      9. Standars
      10. Structure
      11. Tableaux
      12. Textes
    • Temas en la evaluación de acuerdo a las Accessiweb:

      1. Images
      2. Frames
      3. Colours
      4. Multimedia
      5. Tables
      6. Links
      7. Scripts
      8. Mandatory elements
      9. Structuration of information
      10. Presentation of information
      11. Forms
      12. Navigation
      13. Consultation

En cada uno de los temas ya tenemos listados los requisitos, su estado y una explicación detallada de los mismos.

En el caso de la validación de un sitio completo tendremos una página general con estadísticas en conjunto. porcentaje de cumplimiento del sitio en su conjunto, de los temas con más errores, etc. y diferentes listados de las páginas, como las 10 con más errores.

Mi opinión sobre la herramienta: ventajas e incovenientes

Le encuentro muchas ventajas:

  • Es online y opensource.
  • Es fácil de utilizar y comprender.
  • Permite evaluar una página, varias, un sitio completo o incluso, como hemos visto, el escenario que tu definas (páginas que necesitan verificación, estados de páginas)
  • Los resultados son útiles y detallados.
  • Incluye estadísticas que siempre viene bien para incluir en los informes y para realizar comparaciones en el tiempo.
  • Evalúa el contraste de color.
  • Detecta automáticamente el cambio de idioma para indicarte que lo especifiques

Las desventajas que se me ocurren son pasajeras:

  • Estamos evaluando de acuerdo a estándares basados en las WCAG pero no directamente respecto a las WCAG. El criterio de verificación al que hace referencia cada resultado y su enlace de referencia es respecto a estos estándares. Es necesario conocer bien las WCAG 2.0 para "traducir" a qué criterio están haciendo referencia.

    Sin embargo, actualmente están desarrollando la evaluación de acuerdo a las WCAG 2.0, así que es cuestión de tiempo. Por otra parte el motor está separado de las reglas para testear las páginas, por tanto se pueden crear nuevas reglas: SEO, o de calidad, o de usabilidad, etc. (ver documentación Referential-Creator helps the referential creation)

  • Los resultados respecto a las RGAA se presentan en francés, aunque imagino que se corregirá. De todas maneras ya he comentado que se está traduciendo al español.
  • El número de proyectos y de auditorías de sitio completo, en la versión online, son limitados y expiran. Pero siempre podemos descargar y desplegar la aplicación web, en Ubuntu, lo cual tiene su complejidad. Por cierto, que si alguien lo hace, podía animarse a compartir una máquina virtual (vhd o similar) con Ubuntu y la aplicación desplegada [sonrisa]

Artículos relacionados

Servicios relacionados

LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA, HTML5)

$
0
0

Este artículo es un estudio sobre el atributo LONGDESC.

Vamos a hablar de su soporte por parte de los diferentes navegadores y productos de apoyo, así como de las alternativas al mismo, tanto las documentadas en las WCAG 2.0 como las que no.

Así que al final se ha convertido también en un estudio sobre el soporte de los atributos ARIA "aria-describedby" y "aria-describedat", y de los elementos <figure> y <picture> de HTML5.

La página que he utilizado para realizar muchos de los test es: "Test de longdesc, aria-describedby, aria-describedat, figure, picture"

El estudio es muy extenso, al final del mismo podéis consultar las conclusiones y las recomendaciones

Índice

LONGDESC en HTML4

LONGDESC es un atributo de HTML1, normalmente aplicado a una imagen, que especifica un vínculo a una descripción larga.

La descripción larga es complementaria a la descripción corta cuando esta no es suficiente para transmitir adecuadamente la función o información que transmite la imagen.

Siempre es necesario que la descripción corta esté presente, pues permite que la imagen sea anunciada a los usuarios de lector de pantalla y que decidan si desean acceder o no a la descripción larga.

Por tanto, LONGDESC se puede aplicar al elemento IMG2 como complemento al atributo ALT con el que habitualmente se especifica la descripción corta de la imagen.

Hay que tener en cuenta que una imagen puede estar incluida dentro de un enlace. Por ello, la especificación HTML 4.01 indica que el mecanismo del agente de usuario para acceder al recurso vinculado con LONGDESC debe ser diferente al mecanismo para acceder al recurso vinculado desde el atributo HREF del enlace contenedor de la imagen.

Los elementos FRAME e IFRAME3 también pueden incluir el atributo LONGDESC como complemento al atributo TITLE.

El atributo LONGDESC especifica una URI, que puede ser a una página diferente (o a una zona de dicha página diferente) o a otra parte de la misma página.

Por ejemplo:

<!—Descripción en otra parte de la misma página -->
<p><img src="grafico1.jpg" alt="Gráfico de ventas 2014" longdesc="#grafico1Descripcion"></p>
<!—Descripción en otra página, exclusiva para esta descripción -->
<p><img src="grafico1.jpg" alt="Gráfico de ventas 2014" longdesc="descripciones/grafico1Descripcion.html"></p>
<!—Descripción en otra página en la que se incluyen varias descripciones -->
<p><img src="grafico1.jpg" alt="Gráfico de ventas 2014" longdesc="http://miweb.com/descripciones.html#grafico1"></p>

LONGDESC en HTML5

En un principio, en las primeras versiones, la especificación HTML54, -que es recomendación desde octubre de 2014-, no incluyó el atributo LONGDESC.

Actualmente “HTML 5 Image Description Extension (longdesc)” es propuesta de recomendación del W3C desde el 4 de diciembre de 2014.

De hecho, el validador de código del W3C “Markup Validation Service” no reporta como error el uso del atributo LONGDESC en una página HTML 5. Podéis comprobarlo con la página “Test de longdesc, aria-describedby, aria-describedat, figure, picture“, que es la página que he utilizado para realizar los test relativos a este artículo y que está codificada en HTML5.

En el documento “HTML 5 Image Description Extension (longdesc)” se indica que:

  • Una imagen puede tener ninguno o 1 atributo LONGDESC.
  • Debe contener una URI válida que sea un enlace a la descripción de la imagen.
  • La descripción a la que vincula debe estar en un formato accesible.
  • Cuando la descripción es solo una parte del documento de destino, debe vincularse al elemento contenedor de la descripción en el documento de destino.

    Por ejemplo:

    <img src="grafico1.jpg" alt="Gráfico de ventas 2014" longdesc="http://miweb.com/descripciones.html#grafico1">

  • Si el LONGDESC es válido, los agentes de usuario deberían poner el enlace a disposición de los usuarios a través de la interfaz y exponer el LONGDESC a la API de accesibilidad.
  • Los agentes de usuario deberían permitir a los usuarios saber que una imagen tiene una descripción larga.
  • Aunque el LONGDESC esté en una imagen que a su vez esté dentro de un hipervínculo, se debe poder seguir el enlace.
  • Recomienda una experiencia consistente en el comportamiento de encontrar, leer y volver desde la descripción larga a la imagen.

Cuando tratemos posteriormente el soporte del atributo LONGDESC por parte de los diferentes navegadores y productos de apoyo, iremos viendo si se cumplen actualmente o no estos requisitos, y de qué manera.

Ejemplos reales de páginas que usan LONGDESC

Se pueden consultar listados de páginas que están utilizando el atributo LONGDESC en:

En este blog también lo he utilizado cuando ha sido necesario, por ejemplo, en el artículo Wireframes

Uso y mal uso de LONGDESC

En agosto de 2007 Ian Hickson analizó 1 billón de imágenes del índice de Google5.

Concluyó que un 0.13% incluían el atributo LONGDESC. De este porcentaje solo un 1% tenían un LONGDESC adecuado.

Los problemas recurrentes que encontró fueron:

  • La imagen incluía el atributo LONGDESC pero vacío.
  • La URI no era válida, no enlazaba con la descripción o llevaba a una página de error 404.
  • Se incluía la descripción directamente en el atributo, en vez de la URI a la misma.
  • Enlazaba con otras imágenes.
  • La descripción no era adecuada, por ejemplo tenía el mismo texto que el atributo ALT, o no era accesible.

Al final del artículo recopilaremos las buenas prácticas en el uso de LONGDESC.

Qué opinan los usuarios de lector de pantalla, ¿creen que LONGDESC es útil?

WebAIM suele presentar todos los años, desde 2009, su encuesta a usuarios de lector de pantalla. Podéis consultar el enlace a todos ellos en mi artículo “Sobre el uso de lectores de pantalla”.

En las encuestas posteriores a 2011 no se ha preguntado a los usuarios sobre el atributo LONGDESC, el último dato por tanto es de la encuesta realizada a finales de 2010.

En esta encuesta se preguntó a los usuarios: “How useful is longdesc (a method of providing a long description for complex images) to you?”.

El 60.6% consideraban muy útil o bastante útil el atributo LONGDESC; un 22.7% no saben. Desde entonces, como veremos, el soporte del atributo por parte de los productos de apoyo ha mejorado, y seguramente hoy en día el porcentaje de usuarios “no saben” sería sensiblemente menor.

Soporte de LONGDESC por parte de los navegadores actuales

Vamos a repasar el soporte actual del atributo LONGDESC por parte de los navegadores, tanto de forma nativa como a través de extensiones.

Recordemos que en el documento “HTML 5 Image Description Extension (longdesc)” se indicaba que los agentes de usuario deberían cumplir cuatro requisitos respecto al atributo LONGDESC:

  • Debe estar disponible a través de interfaz.
  • Debe exponerse a la API de accesibilidad.
  • El usuario debe poder saber que la imagen tiene una descripción larga.
  • Se debe poder seguir el enlace del LONGDESC aunque la imagen que tiene dicho atributo esté a su vez dentro de un vínculo.

Vamos a ver si cumplen estos requisitos.

Nota: he analizado el soporte de los navegadores con la página Wireframes, que incluye imágenes con LONGDESC. La imagen que se muestra de ejemplo a lo largo de todo el apartado es una de las imágenes de este artículo, tiene el atributo LONGDESC y pertenece originalmente a "La diagramación en la arquitectura de información" de Rodrigo Ronda León.

Opera

Soporte nativo

Desde 2009, con la versión 10.1, Opera tenía soporte nativo para el atributo LONGDESC desde la opción “Descripción larga” del menú contextual de la imagen.

Esta opción del menú se mostraba solo en las imágenes que incluían el atributo LONGDESC y permitía abrir el recurso enlazado en una pestaña nueva.

Visualmente no se diferenciaban (ni se podía configurar que se diferenciaran) las imágenes que tenían descripción larga.

Menú contextual sobre una foto. Destacada la opción 'Descripción larga'

Opera 12.17. Menú contextual “Descripción larga” sobre una imagen con el atributo LONGDESC

Sin embargo, en las últimas versiones de Opera ya no está disponible esta opción de menú.

Menú contextual sobre una foto. No está la opción 'Descripción larga'

Opera 26. Menú contextual sobre una imagen con el atributo LONGDESC. No se muestra la opción “Descripción larga”

Extensiones

Para las versiones de Opera 11 y Opera 12 teníamos la extensión “TellMeMore”, no disponible para versiones posteriores.

Esta extensión incluía el icono de un ojo junto a la barra de direcciones. Cuando la página tenía imágenes con el atributo LONGDESC, este botón se habilitaba. Pulsando el botón te mostraba el listado de dichas imágenes (con una miniatura de cada imagen y descritas con su atributo ALT), pudiendo acceder así en pestaña nueva al recurso enlazado desde su atributo LONGDESC.

Navegador Opera. El icono de un ojo junto a la barra de direcciones está activado. Se muestra una capa emergente con un listado de imágenes, por cada una hay una miniatura con un interrogante y el contenido del alt de la imagen.

Extensión TellMeMore. Ventana con listado de las imágenes que tienen el atributo LONGDESC (captura con Opera 12.17)

Se observa que la extensión a veces tenía problemas para mostrar las miniaturas de las imágenes.

Cómo expone LONGDESC (DOM, API de accesibilidad)

En la siguiente imagen se puede comprobar cómo expone (DOM, API de accesibilidad) Opera 26 el atributo LONGDESC:

MSAA accDescription: sin valor. IAccessible2 Description: sin valor. HTML Atributes longdesc:descripcion.html

Imagen con LONGDESC en Opera 26. Inspeccionada con aViewer.

Firefox

Soporte nativo

Desde la versión 25, Firefox tiene soporte nativo del atributo LONGDESC desde el menú contextual“Ver descripción”.

La opción de menú solo se muestra si la imagen tiene el atributo LONGDESC.

La opción de menú abre el enlace en la misma pestaña y lo hace correctamente aunque la imagen esté dentro de un enlace.

No se diferencia visualmente (ni permite configurar que se diferencien) las imágenes que tienen o no tienen el atributo LONGDESC.

Menú contextual sobre una imagen. Se resalta la opción de menú activa 'Ver descripción'

Firefox 30. Menú contextual “Ver descripción" sobre una imagen con el atributo LONGDESC

Extensiones

Existen varias extensiones para Firefox que permiten que el usuario pueda acceder a la descripción larga, incluida con el atributo LONGDESC, de las imágenes.

“Longdesc” para Firefox

Añade la opción de menú “View Image Longdesc [más la URL]” en el menú contextual de la imagen.

La opción de menú solo se muestra en las imágenes que tienen el atributo LONGDESC. Dicha opción carga la URI definida en el atributo en la misma pestaña, y lo hace correctamente aunque la imagen esté dentro de un enlace.

Menú contextual sobre una imagen. Se resalta la opción del menú 'View Image Longdesc:http://www.usableyaccesible.com/longdesc/de1.html'

Menú contextual “View Image Longdesc” de la extensión “Longdesc” (captura con Firefox 35)

“Longdesk “ para Firefox

Incluye un pequeño enlace “Description”, como una pestaña, bajo la imagen que tiene el atributo LONGDESC.

El enlace carga la URI definida en el atributo, lo hace en la misma pestaña y sin problemas aunque la imagen esté dentro de un enlace.

Una imagen con un enlace 'Description' en la parte inferior izquierda. El enlace está dentro de una pestaña.

Enlace “Description” bajo una imagen con el atributo LONGDESC. Extensión “Longdesk” (captura con Firefox 35)

Cómo expone LONGDESC (DOM, API de accesibilidad)

En la siguiente imagen se puede comprobar cómo expone (DOM, API de accesibilidad) Firefox el atributo LONGDESC:

MSAA accDescription: sin valor. IAccessible2 Description: sin valor. HTML Atributes longdesc:descripcion.html

Imagen con LONGDESC en Firefox 35. Inspeccionada con aViewer

Chrome

Soporte nativo

Chrome no tiene soporte nativo mediante menú contextual como Opera y Firefox.

Extensiones

Existen varias extensiones para Chrome que permiten que el usuario pueda acceder a la descripción larga, incluida con el atributo LONGDESC, de las imágenes.

“Long Description in Context Menu”

Es la extensión oficial que Chrome anunció en 2014.

Incluye en el menú contextual la opción “Open Long Description in New Tab”.

Esta opción de menú se muestra habilitada en las imágenes que tienen el atributo LONGDESC o el atributo ARIA “aria-describedat”, del que os hablo más adelante. Es la única extensión actual, de cualquier navegador, que soporta el atributo ARIA “aria-describedat”.

En el resto de imágenes aparece la opción de menú pero deshabilitada (al contrario que en las extensiones vistas hasta ahora que, en estos casos, no incluían la opción en el menú).

La extensión tiene opciones de configuración que permiten diferenciar visualmente las imágenes que tienen el atributo LONGDESC con un borde de color.

El enlace se abre en pestaña nueva y funciona correctamente aunque la imagen esté dentro de un enlace.

Menú contextual sobre una imagen que está resaltada con un borde azul. Se destaca la opción del menú 'Open Long Description In New Tab'

Extensión de Chrome “Long Description in Context Menu”. La imagen con LONGDESC está resaltada con un borde de color (captura con Chrome 39)

“Longdesc” de graphicdivine.co.uk

Incluye siempre una opción “Show image longdesc [url]” en el menú contextual de las imágenes, habilitada solo en el caso de que tengan el atributo LONGDESC.

Las opciones de configuración permiten:

  • indicar si deseas que el enlace se abra en ventana nueva, en la misma pestaña o en otra pestaña, lo cual realiza correctamente aunque la imagen esté dentro de un enlace.
  • personalizar cómo quieres resaltar las imágenes que tienen el atributo LONGDESC.

Menú contextual sobre una imagen que está resaltada con un borde rojo. Se destaca la opción del menú 'Show image longdesc: http://www.usableyaccesible.com/longdesc/de1.html

Extensión de Chrome “Longdesc” de graphicdivine.co.uk. La imagen con el atributo LONGDESC tiene un borde rojo (captura con Chrome 39)

“Longdesc” de ginader

Está basada en el “JQuery Accessible Longdesc Plugin” del que hablaremos más tarde.

El enfoque es diferente al de las extensiones vistas hasta ahora, pues no se basa en una opción de menú contextual ni en un botón global.

La extensión añade un pequeño icono en la esquina inferior derecha de la imagen que tiene el atributo LONGDESC.

Imagen con un icono 'info' en la esquina inferior derecha. Delante del icono se muestra el texto 'click here for more infos about this image'

Extensión de Chrome “Longdesc” de ginader (captura con Chrome 39)

Al pulsar el icono se sustituye la imagen por la descripción enlazada desde el atributo LONGDESC. El icono es sustituido por un enlace “Close this info” para volver a visualizar la imagen.

Texto descriptivo de la imagen, con encabezado y lista de elementos. Se muestra dentro de una capa con scroll. En la esquina inferior derecha de la imagen hay un enlace 'Close this info'

Extensión de Chrome “Longdesc” de ginader. Presentación de la descripción de una imagen que tiene el atributo LONGDESC (captura con Chrome 39)

Es una solución accesible también para usuarios de lector de pantalla. Por ejemplo con el teclado y NVDA 2014 se puede acceder sin problemas a los enlaces que muestran u ocultan la descripción y los anuncia correctamente, de la misma manera que se puede acceder a la descripción y la lee bien.

Sin embargo la extensión falla cuando la imagen está dentro de un enlace.

Cómo expone LONGDESC (DOM, API de accesibilidad)

Podemos comprobar que la exposición (DOM, API de accesibilidad) del atributo LONGDESC por parte de Chrome es igual a la de Firefox u Opera:

MSAA accDescription: sin valor. IAccessible2 Description: sin valor. HTML Atributes longdesc:descripcion.html

Imagen con LONGDESC en Chrome 33. Inspeccionada con aViewer

Explorer

Soporte nativo

Explorer no tiene soporte nativo mediante menú contextual como Firefox u Opera, o la posibilidad de instalar una extensión.

Sin embargo se puede incluir la opción en el menú contextual, de forma manual, registrándola en “regedit.exe”.

Te explican cómo hacerlo paso a paso en “Configuring Internet Explorer to handle longdesc”, algo que para la mayoría de los usuarios resultará sin duda demasiado complicado.

Cómo expone LONGDESC (DOM, API de accesibilidad)

Explorer expone correctamente el atributo LONGDESC como se observa en la siguiente imagen:

MSAA accDescription: description.html. IAccessible2 Description: description.html. HTML Atributes longdesc:descripcion.html

Imagen con LONGDESC en Explorer. Inspeccionada con aViewer

iCab

Incluyo el navegador iCab porque, además de tener soporte nativo desde el menú contextual, ofrece diferentes cursores cuando la imagen presenta el atributo LONGDESC.

iCab. Una imagen con longdesc o cite presentará un cursor con el icono de una flecha sobre un documento. Una imagen (o cita) que es un enlace y tiene longdesc presenta el icono de una mano con guante y una exclamación.

Imagen de lists.w3.org

Conclusiones del soporte de LONGDESC por los navegadores actuales

Hemos visto el soporte en los principales navegadores y como todos ellos reflejan el atributo LONGDESC en el DOM.

Firefox (desde la versión 25) y Opera (desde la versión 10.1 pero no en las últimas versiones) tienen soporte nativo para LONGDESC mediante el menú contextual de las imágenes que presentan este atributo. Explorer permite añadir manualmente la opción en el menú contextual, pero esto puede resultar muy complicado para la mayoría de los usuarios.

Firefox, Chrome y Opera tienen extensiones que permiten que los usuarios puedan acceder a la descripción larga, incluida con el atributo LONGDESC, de las imágenes .

Los enfoques son diferentes según la extensión:

  • opción en el menú contextual, en unos casos solo presente en las imágenes que tienen el atributo LONGDESC, en otros casos siempre presente pero deshabilitada si la imagen no tiene dicho atributo;
  • enlace bajo la imagen (como “Longdesk “ para Firefox);
  • icono global (como “TellMeMore” para Opera);
  • sustitución de la imagen por la descripción (como “Longdesc” de ginader para Chrome).

Algunas de las extensiones vistas permiten configurar que se diferencien visualmente las imágenes que tienen el atributo LONGDESC.

Todas las extensiones que hemos repasado, salvo “Longdesc” de ginader para Chrome, funcionan bien aunque la imagen esté dentro de un enlace.

Por tanto hemos comprobado el cumplimiento o no de los requisitos que la especificación “HTML 5 Image Description Extension (longdesc)” indicaba que debían cumplir los agentes de usuario:

  • Si el LONGDESC es válido, los agentes de usuario deberían poner el enlace a disposición de los usuarios a través de la interfaz y exponer el LONGDESC a la API de accesibilidad.
  • Los agentes de usuario deberían permitir a los usuarios saber que una imagen tiene una descripción larga.
  • Aunque el LONGDESC esté en una imagen que a su vez esté dentro de un hipervínculo se debe poder seguir el enlace.

En el documento “Implementation Report W3C HTML5 Image Description Extension (longdesc)”, 4 September 2014 se recopilan los resultados de probar estos mismos requisitos con distintas combinaciones de navegadores y sistemas operativos, y por tanto os puede ser útil para complementar la información que os he ofrecido yo. El objetivo de ese estudio que os cito era asegurar que la especificación “HTML 5 Image Description Extension (longdesc)” era implementable y estas implementaciones operables.

Puedes consultar también el soporte en más navegadores en el recurso “Longdesc Tools” de la Universidad de Minnesota.

Soporte de LONGDESC por los lectores de pantalla

La página que he utilizado para realizar los test de soporte de LONGDESC por parte de los lectores de pantalla es "Test de longdesc, aria-describedby, aria-describedat, figure, picture".

NVDA

Desde 2012 NVDA soporta del atributo LONGDESC6 . El lector de pantalla anuncia que la imagen “tiene descripción larga” y se puede abrir el enlace presionando “NVDA+d” (lo cual implica que el usuario debe conocer este atajo de teclado).

Solo funciona con Firefox y Explorer como muestro en el resumen de las pruebas.

Tabla 1. Test LONGDESC con NVDA 2014.

Explorer 11Firefox 35Chrome 39Opera 26
Anuncia “tiene descripción larga” [0] [1] [1]No [2]No [2]
LONGDESC a página diferente. "NVDA+d" abre el enlace [3]
Ventana nueva no redimensionable y sin scroll
[4]
Pestaña nueva
No [5]No [5]
LONGDESC a ancla de la misma página. "NVDA+d" abre el enlace en dicha ancla [6]
Ventana nueva no redimensionable y sin scroll
[7]
Pestaña nueva.
No [5]No [5]
• Lee solo esa descripción o anuncia cuando acabaNo [6]No [6]No [5]No [5]
Si la imagen está dentro de un enlace, ¿funciona? [8][8]No [9]No [9]

[0] La imagen siempre ha de tener ALT. Si la imagen no tiene ALT no se leerá la imagen, el lector de pantalla la ignora como si fuera decorativa (todos los navegadores)

[1] NVDA 2014 (IE11 y FF35) tanto en la lectura en línea, como ojeando las imágenes mediante la tecla de acceso rápido “g”, anuncia que el elemento es un gráfico, su “alt” y que tiene descripción larga (“tiene descripción larga”).

[2] NVDA 2014 (Chrome 39 y Opera26) tanto en la lectura en línea, como ojeando las imágenes mediante la tecla de acceso rápido “g”, anuncia que el elemento es un gráfico, su “alt”, pero NO anuncia que tiene descripción larga.

[3] NVDA 2014 (IE11) tanto en la lectura en línea, como ojeando las imágenes mediante la tecla de acceso rápido “g”, la combinación de teclas “nvda+d” abre el enlace en ventana nueva, lo cual puede pasar desapercibido al usuario si no sabe que este es el comportamiento para dichas teclas.

Ventana de Explorer sin barra de direcciones ni scroll.

NVDA. Nueva ventana con la descripción larga de una imagen que tiene LONGDESC. Abierta tras pulsar “nvda+d”

La ventana con la descripción no se puede redimensionar ni escrolar, solo podrás moverte por ella con las flechas u ojeándola con las teclas de acceso rápido (“h” para encabezados, etc”).

Es un error por tanto poner al final de la descripción un enlace “Volver a la imagen” (tanto con ancla como como URL completa más ancla), porque la cargaría en esta ventana.

[4] NVDA 2014 (FF35) tanto en la lectura en línea, como ojeando las imágenes mediante la tecla de acceso rápido “g”, la combinación de teclas “nvda+d” abre el enlace en pestaña nueva, algo que puede pasar desapercibido al usuario si no sabe que este es el comportamiento de dichas teclas.

Lee la página con la descripción toda seguida, aunque puedes parar la lectura con las flechas u ojear la página con las teclas habituales del lector de pantalla (“h” para los encabezados, etc. )

Es un error por tanto poner al final de la descripción un enlace “Volver a la imagen” (tanto con ancla como como URL completa más ancla), porque la cargaría en esta ventana.

[5] NVDA 2014 (Chrome 39 y Opera26) tanto en la lectura en línea, como ojeando las imágenes mediante la tecla de acceso rápido “g”, la combinación de teclas “nvda+d” siempre dice que no hay descripción larga.

Se evalúa sin tener ninguna extensión de LONGDESC habilitada, si la hubiera, el usuario de lector de pantalla podría acceder a sus opciones.

[6] NVDA 2014 (IE11) Se ha validado tanto si se enlaza al ancla directamente (ejemplo 6: longdesc="#descripcion2") como si se enlaza al ancla pero incluyendo la URL completa más el ancla (ejemplo 7: longdesc="http://www.usableyaccesible.com/test_longdesc/ejemplo.html#descripcion3"). La combinación de teclas “nvda+d” abre en ventana nueva (algo que puede pasar desapercibido a los usuarios que no saben que este es el comportamiento de dichas teclas) la URI actual escrolando hasta el ancla especificada en la URI del LONGDESC.

Ventana de Explorer con la descripción de varias imágenes. La ventana no tienen scroll ni barra de direcciones.

NVDA. Nueva ventana de Explorer tras pulsar “nvda+d” en una imagen con LONGDESC (con ancla a la misma página).

Esta nueva ventana no tiene barras de scroll ni se puede redimensionar.

Esta ventana está escrolada en el ancla especificada en la URI del LONGDESC. NVDA comienza a leer desde este punto todo seguido, aunque puedes parar la lectura con las flechas u ojear el contenido con las teclas habituales del lector de pantalla (“h” para los encabezados, etc.)

Pero es importante indicar que no se para cuando termina de leer el elemento con el “id” especificado en la URI, sigue leyendo la siguiente descripción. Por ello es importante tras cada descripción incluir el texto “Fin de la descripción de la imagen [identificación de la imagen]”

Es un error poner al final de la descripción un enlace “Volver a la imagen” (tanto con ancla como como URL completa más ancla), porque la cargaría en esta ventana. Seguirías por tanto teniendo dos ventanas abiertas con la misma página.

Dos ventanas de Explorer abiertas con la misma página. Una de las ventanas no tiene barra de direcciones ni scroll.

NVDA. Nueva ventana con la descripción. Se ha pulsado "Volver a la imagen". Lo ha hecho en la página de la descripción, por tanto sigues teniendo las dos ventanas abiertas.

Ten en cuenta que con cerrar la ventana de la descripción ya estarías en la página original y con el foco en la imagen desde la que abriste la ventana con la descripción.

[7] NVDA 2014 (FF35) Se ha validado tanto si se enlaza al ancla directamente (ejemplo 6: longdesc="#descripcion2") como si se enlaza al ancla pero incluyendo la URL completa más el ancla (ejemplo 7: longdesc="http://www.usableyaccesible.com/test_longdesc/ejemplo.html#descripcion3").

La combinación de teclas “nvda+d” abre en pestaña nueva (algo que puede pasar desapercibido a los usuarios que no saben que este es el comportamiento de dichas teclas) la URL actual, escrolando hasta el ancla especificada en la URI del LONGDESC.

Por lo demás el comportamiento es igual que en IE 11, no se para al terminar de leer la descripción, ni anuncia que se acaba, sino que sigue leyendo el siguiente contenido.

[8] NVDA 2014 (IE11 y FF35) Cuando la imagen está dentro de un enlace, anuncia correctamente que tiene descripción larga y no hay problemas para acceder correctamente al LONGDESC mediante la combinación de teclas “nvda+d”. Si el enlace tiene un TITLE, como en el resto de navegadores, solo anuncia el TITLE del enlace al coger el foco por tabulación y no en la lectura en línea u ojeando las imágenes con la tecla “g”.

[9] NVDA 2014 (Chrome 39 y Opera26) anuncia correctamente que es un enlace, un gráfico y nos lee su “alt” (y el “title” si accedes con el tabulador) pero si pulsar la combinación de teclas “nvda+d” lee “no hay descripción larga”.

JAWS

Veamos ahora el soporte con JAWS. A continuación incluyo una tabla con el resumen de la pruebas. En esta ocasión no he añadido Opera porque JAWS no funciona con este navegador.

Tabla 2. Test LONGDESC con JAWS 15

Explorer 11Firefox 35Chrome 39
Anuncia que tiene descripción [0] [1] [1] [2]
LONGDESC a página diferente. “Alt +enter” abre el enlace [3] Pestaña nueva [3] Pestaña nuevaNo [2]
LONGDESC a ancla de la misma página. “Alt +enter” abre el enlace en dicha anclaParcialmente [4] [5]No [2]
Si la imagen está dentro de un enlace, ¿funciona?Parcialmente [2]

[0] La imagen siempre ha de tener ALT. Si la imagen no tiene ALT no se leerá la imagen, el lector de pantalla la ignora como si fuera decorativa (todos los navegadores)

[1] JAWS 15 (IE11 y FF35) tanto en la lectura en línea, como ojeando las imágenes mediante la tecla de acceso rápido “g”, anuncia que el elemento es un gráfico, su “alt” y “press alt enter for description”. Al contrario que NVDA nos indica la combinación de teclas para acceder a la descripción por si el usuario no la conoce.

[2] JAWS 15 (Chrome39) tanto en la lectura en línea, como ojeando las imágenes mediante la tecla de acceso rápido “g”, anuncia que el elemento es un gráfico, su “alt” y “press alt enter for description”. Sin embargo, al pulsar dicha combinación de teclas NO abre el enlace.

[3] JAWS 15 (IE11 y FF35) tanto en la lectura en línea, como ojeando las imágenes mediante la tecla de acceso rápido “g”, la combinación de teclas “alt+enter” abre la URI del LONGDESC en pestaña nueva en los dos navegadores (al contrario que con NVDA y IE11 que se abría en ventana nueva).

Anuncia la pestaña en IE11, no tan claramente en FF35.

Lee la página seguida (pero puedes parar la lectura con las flechas u ojear el contenido con las teclas habituales, como “h” para los encabezados, etc.). Además la lee con marcado semántico, es decir, va anunciado cada contenido de qué tipo es.

No tiene sentido incluir un enlace “Volver a la imagen” al final de la descripción, pues navegaría siempre en esa nueva pestaña, nunca volvería a la original, y eso confundiría al usuario. Basta con cerrar esta pestaña y ya estamos en la pestaña original con el foco en la imagen desde la que accedimos a la descripción.

[4] JAWS 15 (IE11) falla cuando el enlace del LONGDESC incluye solo el ancla a la descripción en la misma página (longdesc=”#descripcion2”, ejemplo 6)

Abre la pestaña nueva intentando cargar esta página (http://www.usableyaccesible.com/test_longdesc/#descripcion) y por tanto no la encuentra.

Cuando la URL es completa (longdesc="http://www.usableyaccesible.com/test_longdesc/ejemplo.html#descripcion3”, ejemplo 7) el problema desaparece.

Otro error detectado en IE11 es que, en ambos casos (ejemplo 6 y ejemplo 7 de la página de test), no comienza a leer la descripción concreta a la que se ha enlazado. Todas las descripciones están englobadas en un capa “#descripción”, dentro de esta capa, cada descripción está en su correspondiente DIV con su correspondiente “id”.


<div id="#complementary" role="complementary">
<div id="descripcion">
<div id="descripcion2">
<h3>Imagen 6. Disciplinas relacionadas con la Experiencia de Usuario</h3>
<p>[Aquí se incluye la descripción detallada maquetada semánticamente.]</p>
<p>Fin de la descripción de la imagen 6.</p>
<p><a href="#imagen6">Volver a la imagen 6</a></p>
</div>
<div id="descripcion3">
<h3>Imagen 7. Disciplinas relacionadas con la Experiencia de Usuario</h3>
<p>[Aquí se incluye la descripción detallada maquetada semánticamente.]</p>
<p>Fin de la descripción de la imagen 7.</p>
<p><a href="#imagen7">Volver a la imagen 7</a></p>
</div>
</div>
</div>

IE11 empieza a leer todo el contenedor “#descripcion” en vez del contenedor concreto enlazado (“#descripcion2” o “#descripcion3”).

La lectura es seguida y sin marcado semántico (no indica cada contenido de qué tipo es), aunque puedes parar la lectura con las fechas u ojear el contenido con las teclas habituales (“h” para los encabezados, etc.)

JAWS 15 no se para al terminar de leer el contenedor de la descripción a la que se ha enlazado (#descripcion2). Sigue leyendo el siguiente contenido (#descripción3), por ello debe incluirse un texto “Fin de la descripción de la imagen [identificación de la imagen]”.

Como están dentro de un DIV con role=”complementary”, al terminar de leer el contenedor ("#descripcion") anuncia “complementary end”.

Cuando termina de leer el contenedor general “#descripcion” vuelve a leerlo otra vez en bucle hasta que interactúas.

En consecuencia, para evitar este problema, cada descripción debería estar en un contenedor diferente con un role=”complementary”, es decir, en vez de la forma en que se maqueta en la página de test, debería estar implementado así:


<div id="#descripcion1" role="complementary" aria-label=”Descripción de la imagen 6”>
<h3>Imagen 6. Disciplinas relacionadas con la Experiencia de Usuario</h3>
<p>[Aquí se incluye la descripción detallada maquetada semánticamente.]</p>
<p>Fin de la descripción de la imagen 6.</p>
</div>

De esta manera solo leería esta descripción y nos anunciaría cuándo se termina antes de volver a leerla en bucle. Como en otros casos, no tiene sentido un enlace “Volver a la imagen” por que la descripción la ha abierto en ventana nueva.

[5] JAWS 15 (FF35) Con FF35 el comportamiento es igual que en IE11 pero sin los bugs comentados.

Lee correctamente a partir del “id” referenciado, de forma seguida y semánticamente. Cuando termina de leer ese contenedor sigue con el siguiente y no anuncia el final de cada uno.

Como las descripciones están englobadas en un DIV con el role=”complementary” sí que anuncia el final de este contenedor general. Por ello, la manera de organizar el marcado de las descripciones que he propuesto en el punto [4] anterior también beneficia a los usuarios de JAWS15 y FF35.

VoiceOver

VoiceOver (iOS 8.1.2), probado con Safari y Chrome, no soporta el atributo LONGDESC, no anuncia que la imagen tenga descripción larga ni se puede acceder a ella. De hecho Apple hizo una objeción formal a la inclusión de LONGDESC en HTML 5.7

Orca

Orca 3.14 soporta LONGDESC con Gecko (por tanto con Firefox) como se anunció en agosto de 20148.

ChromeVox

Soporta LONGDESC desde la versión 1.269. Anuncia que la imagen tiene descripción larga y se puede activar con "Cvox+C>D".

Sin embargo posteriormente estas mismas teclas se asignaron a otra acción y en la versión 1.31 no se puede abrir el enlace.

Es un bug documentado10 y posiblemente cambien la combinación de teclas a "Cvox+C>L".

Window-Eyes

Es soportado desde la versión 4.1, aunque no hay datos recientes sobre el actual soporte11 y no he añadido este lector a las pruebas. Según la documentación, anuncia que la imagen tiene una descripción larga a la que puedes acceder con ALT-ENTER.

Conclusiones del soporte de LONGDESC por los lectores de pantalla

Las WCAG 2.0 dicen sobre el soporte de LONGDESC:

User Agent support for longdesc varies, but overall support is improving. Screen readers such as JAWS, NVDA, and Window-Eyes support longdesc, but Voiceover 4.0, Orca 2.32.0, and screen magnifier Zoomtext 10.0 do not yet support the longdescattribute. Browsers including Internet Explorer, Firefox, Opera, and Chrome all support longdesc.

WCAG 2.0, “H45: Using longdesc”

Lo que hemos podido comprobar en este apartado, en los test que he realizado, es que:

  • NVDA 2014 lo soporta con IE11 y FF35 (no así con Chrome 39 ni Opera 26).
    • Se anuncia que la imagen tiene descripción larga y se puede acceder a ella mediante “nvda+d”.
    • La página con la descripción se abre siempre (aunque la imagen esté dentro de un enlace, o aunque el enlace sea a un ancla en la misma página) en ventana nueva con IE11 (ventana sin scroll y sin posibilidad de redimensionar) y en pestaña nueva con FF35.
    • Cuando el enlace es a un ancla, NVDA empieza a leer desde esa ancla. Sin embargo, no se para tras leer el contenido del contenedor enlazado, ni anuncia que ha terminado de leerlo, por el contrario, continua leyendo el siguiente.
  • JAWS15 lo soporta con IE11 y FF35 (no así con Chrome 39 ni Opera 26)
    • Se anuncia que la imagen tiene descripción larga y además anuncia la combinación de teclas para acceder a ella:“alt+enter”.
    • La página con la descripción se abre siempre (aunque la imagen esté dentro de un enlace, o aunque el enlace sea a un ancla en la misma página) en pestaña nueva en ambos navegadores.
    • IE11 presenta dos bugs:
      • Con descripciones en la misma página, cuando la URI solo incluye un ancla, no abre la página. Debe incluirse la URI completa más el ancla.
      • Lee desde el contenedor general de las descripciones y no la descripción concreta enlazada con el ancla.
    • Cuando el enlace es a un ancla, en ambos navegadores, no se para tras leer el contenedor al que se ha enlazado. Continua leyendo el siguiente contenido sin anunciar que ha terminado de leer el contenedor al que se enlazó.
  • VoiceOver (iOS 8.1.2), probado con Safari y Chrome, no soporta el atributo LONGDESC.
  • Orca 3.14 soporta el atributo LONGDESC con Gecko (con Firefox por tanto)
  • ChromeVox 1.26 lo soportaba y se podía abrir con Cvox+C>D . Pero en la versión 1.31 estas teclas ya no funcionan por un bug documentado.
  • Windows-Eyes lo soporta desde al versión 4.1.

En base a todo ello veremos en las conclusiones las recomendaciones de uso de LONGDESC.

Puedes consultar el soporte en otros navegadores en el recurso: “Longdesc Tools” de la Universidad de Minnesota.

LONGDESC en las WCAG 2.0

El criterio de conformidad 1.1.1 “Non-text Content” de las WCAG 2.0 admite LONGDESC como técnica suficiente para incluir la descripción extensa de una imagen: técnica “H45: Using longdesc”.

Se admite tanto un enlace a la descripción en otra página (o una parte de otra página) como un ancla a otra zona de la página actual.

En la técnica se enumeran las ventajas y desventajas de ambas opciones.

Las ventajas de incluir la descripción larga en una página diferente, única para cada descripción, son:

  • es fácilmente reutilizable para múltiples instancias de la misma imagen,
  • no se añade en la página desorden visual,
  • el punto final de la descripción es evidente para el usuario.

La ventaja de proporcionar la descripción larga dentro de la misma página es que todos los usuarios, en cualquier contexto de uso, pueden acceder a la descripción.

La desventaja de incluir la descripción en la misma página, o usar una diferente pero común para todas las descripciones, es que las implementaciones actuales de apoyo a LONGDESC, como hemos visto, no identifican el final de la descripción larga. Sin embargo se puede resolver ofreciendo una descripción bien formada que identifique cuándo finaliza la descripción.

Técnicas alternativas a LONGDESC en las WCAG 2.0

LONGDESC no es la única manera de ofrecer la descripción larga de una imagen.

En el artículo “Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online” os explico cuándo es necesario incluir una descripción extensa a una imagen y qué técnicas se pueden aplicar (además de LONGDESC) según las técnicas actualmente referenciadas en las WCAG 2.0.

También se puede utilizar la técnica LONGDESC junto a otras técnicas, por ejemplo, incluir un vínculo a la descripción tras la imagen (técnica de las WCAG 2.0 "G73: Providing a long description in another location with a link to it that is immediately adjacent to the non-text content").

De hecho, sería recomendable que así lo hicieras, como concretaremos al final en las recomendaciones.

Imagen resaltada con un borde rojo. Sobre ella se muestra el contenido del atributo ALT y el atributo LONGDESC (que enlaza con una página). Bajo la imagen un enlace 'DE-1'

Imagen con descripción larga en el artículo “Wireframes”. Se combina la técnica H45 (LONGDESC) y la técnica G73 (enlace “D” a continuación de la imagen). Inspeccionada con la extensión para Firefox “Favelets” de James Thatcher

Estudio de "aria-describedby"

Puesto que en el artículo “Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online” no incluyo las técnicas ARIA, voy a tratar aquí la única técnica ARIA que incluyen las WCAG 2.0 en la actualidad para asociar una descripción larga a una imagen.

Esta técnica es ARIA 15: Using aria-describedby to provide descriptions of images (ARIA).

Por ejemplo,


<p><img src="grafico1.jpg" alt="Gráfico de ventas 2014" aria-describedby="descripcionGrafico1" /></p>
<p id=”descripcionGrafico1”>Aquí se incluiría la descripción</p>

Como se observa, en el atributo “aria-describedby” se incluye el id (o ids) del elemento (o elementos) que proporcionan la descripción larga. Por tanto, mediante este atributo nunca se puede hacer referencia a una descripción que esté en otra página diferente.

Soporte en NVDA 2014

Los usuarios del lector de pantalla NVDA es fácil que no escuchen nunca esta descripción.

NVDA 2014 (tanto en IE11, FF35, Chrome39 y Opera26) no lee la descripción proporcionada mediante “aria-describedby” en la lectura lineal (con las flechas), solo la lee cuando accedes a las imágenes ojeándolas con la tecla “g”.

En estos casos NVDA lee: [alt] “gráfico” [aria-describedby], en el ejemplo anterior “Gráfico de ventas 2014. Gráfico. Aquí se incluiría la descripción”.

Lee la descripción seguida, sin posibilidad de pararla y sin anunciar el marcado semántico (no anunciará por ejemplo que parte de esa descripción es un encabezado).

Soporte en VoiceOver

VoiceOver (iOS 8.1.2), probado con Chrome y Safari en un iPad, anuncia las imágenes que tienen el atributo “aria-describedby” de la misma manera que hemos visto en NVDA: [alt] “gráfico” [aria-describedby] leyendo la descripción de forma seguida sin poder pararla.

Soporte en JAWS 15

JAWS 15 con IE11 y Chrome39 no lee la descripción, ni en la lectura lineal ni ojeando las imágenes con la tecla “g”.

Sin embargo el atributo sí que es soportado por FF35. Tanto en la lectura lineal como ojeando las imágenes con la tecla "g" las anuncia de la siguiente manera: “grafico” [alt] “press insert+alt+r for descripcion”. De esta manera solo se lee la descripción extensa si el usuario la solicita e informa al usuario de la combinación de teclas que podría no conocer.

Pulsando la combinación de teclas “insert+alt+r” lee la descripción seguida y sin marcado semántico.

¿Debo usar aria-describedby?

El atributo “aria-describedby” puede ser muy útil para asociar semánticamente descripciones con un elemento, por ejemplo como expliqué en “Ayuda contextual de los formularios más accesible con "aria-describedby" (WAI-ARIA) en el caso de las ayudas contextuales de los campos de formulario.

En las imágenes, dado el actual soporte, es recomendable que aunque sea una técnica suficiente se complemente con otra técnica como la de incluir un enlace (un ancla) a la descripción tras la imagen.

No es recomendable usar “aria-describedby” cuando la descripción es muy larga, porque ya hemos visto que se lee seguida, sin poder pararse y sin marcado semántico.

Si se usa solo “aria-describedby” no tiene sentido incluir al final de la descripción un enlace para volver a la imagen, ya que no enlaza hasta la descripción, solo la lee pero mantiene el foco en la imagen.

Es importante que el “id” al que enlaza esté aplicado al elemento contenedor de la descripción, al DIV por ejemplo, porque ten en cuenta que leerá todo el contenido de ese contenedor.

Otras alternativas al uso de LONGDESC no documentadas en las WCAG 2.0

En el apartado anterior he incluido las técnicas referenciadas actualmente en el documento de las WCAG 2.0: Techniques for WCAG 2.0. Este documento no es normativo, sino informativo, y se va actualizando periódicamente, por ejemplo para añadir técnicas relativas a otras tecnologías. En este sentido actualmente se está trabajando en las técnicas para HTML5.

Voy a repasar posibles técnicas todavía no documentadas en las "Techniques for WCAG 2.0", las más conocidas al menos. Podéis consultar más en los siguientes recursos:

ARIA. Propiedad"aria-describedat"

De momento, la nueva versión de WAI-ARIA 1.1, en working draft todavía, incluye la propiedad “aria-describedat”, equivalente a LONGDESC.

Hemos visto que solo es soportada por la extensión oficial de Chrome “Long Description in Context Menu”.

En las pruebas realizadas, ni JAWS 15 ni NVDA 2014 soportan esta propiedad con ninguno de los navegadores probados (IE, FF, Chrome, Opera).

Tampoco la soporta VoiceOver (iOS 8.1.2), ni con Safari ni con Chrome.

Por tanto actualmente no es una buena alternativa.

Soluciones basadas en javascript

Solución propuesta por Olga Carreras

En el artículo “Descripción extensa de una imagen: accesible con lector de pantalla y visible sin imágenes activas disponible aunque no se soporte javascript” propongo una técnica basada en javascript pero que funciona sin javacript activo.

Es compatible con los lectores de pantalla y además detecta si las imágenes no se han cargado, o no están habilitadas, para mostrar dicha descripción.

“JQuery Accessible Longdesc Plugin”

Hemos visto que la extensión “Longdesc” de ginader está basada en el “JQuery Accessible Longdesc Plugin”.

Hemos comprobado que esta solución incluye un enlace en la esquina inferior derecha de la imagen. Al pulsarlo, la imagen se sustituye por la descripción, con un nuevo enlace para volver a mostrar la imagen.

Bien, pues puedes usar este plugin directamente en tus páginas. Es una solución accesible, compatible con los lectores de pantalla. Por ejemplo con NVDA se puede acceder sin problemas a los enlaces y lee correctamente la descripción extensa de la imagen.

Pero falla cuando la imagen está dentro de un enlace. Por tanto no lo uses en estos casos.

Otras propuestas javascript

Otros autores proponen una alternativa similar al “JQuery Accessible Longdesc Plugin” en el resultado pero diferente en la implementación.

Por ejemplo “Accessible iframe alternative to html:longdesc” se implementa con un iframe y un botón que permite mostrar la imagen o la descripción.

Steve Faulker propone otra implementación para un resultado similar. En este caso usa el flipbox web component. Puedes ver una demo en “flip box web component demos”.

Alternativas HTML5

Destacan quizás dos:

Elemento <figure>

Se puede incluir la imagen dentro de un elemento <figure> (que no es exclusivo para incluir imágenes) y en su caption (incluido con <figcaption>) incluir el enlace a la descripción extensa, o bien la propia descripción en su <details>.

A continuación explico las dos propuestas.

Enlace en el <figcaption>

Veamos primero el caso más sencillo, incluir un enlace a la descripción en <figcaption>.

Si accedéis a la página de test de este artículo, podéis ver el funcionamiento del código en el test 9.


<figure>
<img src="disciplinas_UX_2013_muypeq.jpg"
alt="Disciplinas relacionadas con la Experiencia de Usuario.">
<figcaption>
<h3>Disciplinas UX. Olga Carreras</h3>
<p><a href="descripcion.html">Descripción en texto de la imagen 9 ‘Disciplinas UX’</a></p>
</figcaption>
</figure>

En IE11, FF35, Chrome 39 y Opera 26 se muestra la imagen y bajo ella el contenido del <figcaption>.

9. Imagen con FIGURE más enlace a descripción en FIGCAPTION. Bajo la imagen se ve el texto 'Disciplinas UX. Olga Carreras' como un encabezado de menos nivel que el título y el enlace 'Descripción en texto'

Imagen incluida con <figure> y enlace a la descripción incluido en <figcaption>. Visualizado con IE11.

Tampoco he tenido problemas con el lector de pantalla, en todos los casos lee el ALT de la imagen y el texto incluido en el <figcaption>.

Ten en cuenta que si no se soportan estas etiquetas HTML5 se ignoran, así que lo único importante es que la imagen tenga el ALT, y que la descripción esté maquetada semánticamente.

Descripción en el elemento <details> del <figcaption>

Como hemos dicho, si usamos <figure> habría una segunda manera de incluir la descripción larga, y es añadirla directamente mediante el atributo <details> del <figcaption>.

<details> y <summary> son soportados desde Chrome 12 y Opera 1512.

Podemos ver el ejemplo “Longdesc Alternative: The details element”

En la esquina inferior derecha de la imagen se incluye un botón “Photo Info”. Al pulsar el botón se muestra la información adicional sobre la imagen y el texto del botón cambia a "Hide Photo Info".

Para su soporte en IE y FF utiliza un polyfill.

Longdesc Alternative:the details element. Sobre la imagen de un niño, hay una capa con scroll que contiene texto informativo acerca la imagen. En la parte inferior de la imagen está el texto Texas Roots y el botón 'Hide Photo Info'

Ejemplo “Longdesc Alternative: The details element”. Descripción detallada vista con IE11.

No he tenido problemas al acceder al ejemplo con NVDA. El lector de pantalla me ha anunciado la imagen como era de esperar. He podido acceder al botón que muestra u oculta la descripción, y me la ha leído correctamente.

Aunque hay que decir que:

  • el autor debería haber puesto en el código, dentro del elemento <figure>, la imagen primero y después el <figcaption>, para que anuncie primero la imagen y luego el botón de la descripción.
  • Hay que tener mucho cuidado con el contraste de color del texto descriptivo sobre la imagen.

Elemento <picture>

En la especificación HTML5 no se incluye el atributo PICTURE, pero seguramente formará parte de la especificación en el futuro13.

Una de las grandes ventajas del elemento <picture> es que, al igual que <video> o <audio>, permitirá incluir diferentes versiones de la imagen. Esto es una gran ventaja en los desarrollos Responsive Design.


<picture aria-label=”Disciplinas relacionadas con la Experiencia de Usuario”
aria-describedby=”descripcion11”>
<source media="(min-width: 64em)" srcset="disciplinas_UX_2013_peq.jpg">
<source media="(min-width: 37.5em)" srcset="disciplinas_UX_2013_muypeq.jpg">
<source srcset="disciplinas_UX_2013_peq.jpg">
<img src="disciplinas_UX_2013_muypeq.jpg"
alt="Disciplinas relacionadas con la Experiencia de Usuario">
<p id="descripcion11">
Aquí descripción extensa (o un enlace a la misma descripción extensa de la imagen 10).
</p>
</picture>

Si accedéis a la página de test de este artículo, podéis ver el funcionamiento del código en el test 10.

Actualmente <picture> solo está soportado por Chrome (a partir de la versión 38) y Opera (a partir de la versión 25)14.

En los test que he realizado, con Chrome 39 y Opera 26 se carga la imagen en grande o en pequeño en función del tamaño de pantalla en el que la estéis viendo. Entiende por tanto el elemento <picture> y carga el primer o el segundo “source”.

Debajo de la imagen se muestra la descripción que hemos incluido con un párrafo dentro del elemento.

Con Chrome 39 y Opera 26, NVDA anuncia correctamente el elemento <picture> gracias a su atributo ARIA “aria-label”. No lee la descripción referenciada con “aria-describedby”, pero accede sin problemas a ella en el párrafo bajo la imagen (que como hemos dicho se muestra también visualmente).

IE 11 y FF35 ignoran el elemento <picture> y muestran sin problemas la imagen incluida con el elemento IMG y el párrafo con la descripción.

Con IE 11 y FF35, NVDA anuncia correctamente la imagen (que tiene su correspondiente ALT) y lee la descripción incluida tras la misma.

Por tanto, no he detectado ningún problema que me haga desaconsejar <picture>, al contrario, puede ser una gran ayuda en los desarrollos Responsive Design.

Su uso no supone un problema para los usuarios que usan navegadores que no lo soportan o para los usuarios que acceden con un lector de pantalla.

Puedes ver un tutorial muy detallado de <picture> en “El nuevo elemento <picture> de HTML5 para crear imágenes responsive”

SVG

Una imagen SVG puede estar formada por varios componentes combinados jerárquicamente, cada uno de los cuales puede tener un título y una descripción. La combinación de la jerarquía y los equivalentes alternativos pueden ayudar a un usuario que accede con un lector de pantalla a crearse un modelo mental de la imagen.

Si a esto le añadimos roles y atributos ARIA, podemos tener imágenes accesibles, pero nos serviría solo para imágenes vectoriales.

Un ejemplo es el “Accessible SVG alternative to html:longdesc” (del artículo “Longdesc alternatives in HTML5”) o el “accessible SVG map of the United States” de Derek Featherstone.

Herramientas de autor

Para evaluar el uso del atributo LONGDESC en una página podemos instalar alguna de las extensiones que permiten diferenciar visualmente las imágenes que tienen el atributo LONGDESC (“Long Description in Context Menu” o “Longdesc” de graphicdivine.co.uk, para Chrome).

También resulta útil la extensión para Firefox “Favelets” de James Thatcher. Esta extensión tiene una opción “Images>Images, Canvas&Longdesc” que resalta las imágenes que tienen el atributo LONGDESC y muestra sobre la imagen sus atributos ALT y LONGDESC.

Las herramientas online “ALT Text Checker” o “Image Analyser” de juicystudio también nos muestran los atributos ALT y LONGDESC de las imágenes de nuestras páginas.

Alt Text Checker. Muestra el alt y el longdesc de una imagen.

Imagen inspeccionada con "Alt Text Checker"

En cualquier caso, la mayoría de los validadores de accesibilidad evalúan el atributo LONGDESC.

Por otra parte, el uso de LONGDESC está también relacionado con su soporte por parte de los editores HTML o los CMS, puesto que si no dan la posibilidad de añadirlo a las imágenes es difícil que su uso pueda extenderse.

Actualmente, editores como Dreamweaver15 o Amaya16 permiten incluir el atributo LONGDESC a una imagen, así como Drupal17 o Wordpress (plugin “Long Description”).

Tenéis un relación bastante completa en WYSIWYG support for @longdesc today. También en la página “Longdesc Tools” de la Universidad de Minnesota podéis consultar otro listado, con diferentes tipos de herramientas.

Conclusiones

Hemos visto que LONGDESC es un atributo aplicable al elemento IMG, tanto en HTML4 como en HTML5, que permite incluir la URI de la descripción extensa de una imagen.

Los usuarios de lector de pantalla, según datos de 2011, consideran en su mayoría que es un atributo muy útil o bastante útil. Sin embargo, hemos visto que según un estudio de 2007 se estaba utilizando solo en un 0.13% de las webs y solo en un 1% de este porcentaje de forma adecuada.

Hemos repasado el soporte en los principales navegadores.

  • Firefox (desde la versión 25) y Opera (desde la versión 10.1 pero no en las últimas versiones) tienen soporte nativo para LONGDESC mediante el menú contextual de las imágenes que presentan este atributo.
  • Explorer permite añadir manualmente esta opción de menú, pero puede resulta muy complicado para la mayoría de los usuarios.
  • Firefox, Chrome y Opera tienen extensiones que permiten que los usuarios puedan acceder a la descripción larga de las imágenes incluidas con el atributo LONGDESC, muchas mediante el menú contextual, pero otras con enfoques diferentes. Además,
    • algunas extensiones permiten configurar que se diferencien visualmente las imágenes que tienen el atributo LONGDESC;
    • la mayoría de las extensiones funcionan bien aunque la imagen esté dentro de un enlace.

También hemos repasado el soporte con diferentes lectores de pantalla.

  • NVDA 2014 lo soporta con IE11 y FF35 (no así con Chrome 39 ni Opera 26).
    • Se anuncia que la imagen tiene descripción larga y se puede acceder a ella mediante “nvda+d”.
    • La página con la descripción se abre siempre (aunque la imagen esté dentro de un enlace, o aunque el enlace sea a un ancla en la misma página) en ventana nueva con IE11 (ventana sin scroll y sin posibilidad de redimensionar) y en pestaña nueva con FF35.
    • Cuando el enlace es a un ancla, NVDA empieza a leer desde esa ancla. Sin embargo, no se para tras leer el contenido del contenedor enlazado, ni anuncia que ha terminado de leerlo, por el contrario, continua leyendo el siguiente.
  • JAWS15 lo soporta con IE11 y FF35 (no así con Chrome 39 ni Opera 26)
    • Se anuncia que la imagen tiene descripción larga y además anuncia la combinación de teclas para acceder a ella:“alt+enter”.
    • La página con la descripción se abre siempre (aunque la imagen esté dentro de un enlace, o aunque el enlace sea a un ancla en la misma página) en pestaña nueva en ambos navegadores.
    • IE11 presenta dos bugs:
      • Con descripciones en la misma página, cuando la URI solo incluye un ancla, no abre la página. Debe incluirse la URI completa más el ancla.
      • Lee desde el contenedor general de las descripciones y no la descripción concreta enlazada con el ancla.
    • Cuando el enlace es a un ancla, en ambos navegadores, no se para tras leer el contenedor al que se ha enlazado. Continua leyendo el siguiente contenido sin anunciar que ha terminado de leer el contenedor al que se enlazó.
  • VoiceOver (iOS 8.1.2), probado con Safari y Chrome, no soporta el atributo LONGDESC.
  • Orca 3.14 soporta el atributo LONGDESC con Gecko (con Firefox por tanto)
  • ChromeVox 1.26 lo soportaba y se podía abrir con Cvox+C>D . Pero en la versión 1.31 estas teclas ya no funcionan por un bug documentado.
  • Windows-Eyes lo soporta desde al versión 4.1.

Las WCAG 2.0 admiten el uso de LONGDESC como técnica suficiente para incluir la descripción extensa de una imagen, pero para asegurar el acceso a la misma para los usuarios que utilicen navegadores o productos de apoyo antiguos o que no lo soporten, es conveniente usarlo junto a otras técnicas como un enlace a la descripción extensa a continuación de la imagen.

También hemos visto otras alternativas al uso de LONGDESC:

  • mediante propiedades ARIA:
    • “aria-describedby” (técnica suficiente de las WCAG 2.0). Esta propiedad es soportada por NVDA 2014 (solo ojeando las imágenes con “g” pero no en la lectura lineal), VoiceOver y JAWS 15 (solo con Firefox y si se solicita con “insert+alt+r”). La lectura es seguida, sin poder pararla y sin marcado semántico. Por tanto es recomendable usarla junto a la técnica de incluir un enlace (un ancla) a la descripción después de la imagen.
    • “aria-describedat”, actualmente no es soportado por NVDA, JAWS o VoiceOver; y solo la extensión oficial de Chrome permite acceder a la descripción enlazada con este atributo desde el menú contextual de la imagen.
  • mediante javascript, hemos visto que existen diversas soluciones accesibles;
  • propias de HTML 5, como el uso de <figure> y <picture>. Hemos visto el soporte de estas etiquetas y que, aunque no se soporten, son ignoradas y se muestra sin problema tanto la imagen como la descripción, pudiendo acceder a ambas mediante un lector de pantalla. También hemos comentado que en el caso de las imágenes vectoriales, con SVG, podemos incluir títulos y descripciones (así como propiedades ARIA) a los elementos que componen la imagen.

Por último hemos comentado que muchas herramientas nos van a permitir evaluar el uso del atributo LONGDESC; y que herramientas de autor como Dreamweaver, Drupal, WordPress, entre otros, nos permiten incluir este atributo a las imágenes.

Recomendaciones

Si usas finalmente LONGDESC, estas son las buenas prácticas que debes cumplir:

  • Una imagen solo puede incluir un atributo LONGDESC, y solo en el caso de que necesite y tenga una descripción larga.
  • Usa el atributo LONGDESC siempre junto al atributo ALT, identificando la imagen, para que el usuario pueda decidir si leer o no la descripción extensa. Si no incluyes el atributo ALT el lector de pantalla ignora la imagen, no la lee, la trata como decorativa.
  • Nunca incluyas la descripción directamente en el atributo LONGDESC.
  • Debes indicar la URI de la página que contiene la descripción extensa.
    • Si hay varias descripciones en esa página debes añadir a la URI un ancla al contenedor de la misma (#descripcion1).
    • La URI debe ser siempre completa, aunque estés enlazando a la misma página, (longdesc="http://miweb.com/mipagina.html#descripcion1"), no solo el ancla, debido al bug que vimos en Explorer.
  • Si la página tiene varias descripciones, y para evitar otro de los bug vistos en Explorer, cada una debe estar en un contenedor diferente, con un role “complementary”. De esta manera el lector de pantalla nos leerá correctamente la descripción enlazada y nos anunciará cuando acaba el contenedor “complementary”.

    <div id="#descripcion1" role="complementary" aria-label=”Descripción de la imagen 6”>
    <h3>Imagen 6. Disciplinas relacionadas con la Experiencia de Usuario</h3>
    <p>[Aquí se incluye la descripción detallada maquetada semánticamente.]</p>
    <p>Fin de la descripción de la imagen 6.</p>
    </div>
    • Por tanto, no incluyas (como en la página de test que hemos estado siguiendo) dentro de un único contenedor todas los descripciones (aunque cada una esté en un DIV con su correspondiente “id”), porque Explorer no enlazará con la descripción concreta que indicas.
  • Al final de cada descripción incluye el texto “Fin de la descripción de la imagen [identificación de la imagen]” para que el usuario de lector de pantalla sepa dónde termina, pues en muchos casos sigue leyendo el siguiente contenido aunque esté en otro contenedor.
  • La página con la descripción, o la propia descripción, debe ser accesible, transmitir la misma información que la imagen, y estar marcada semánticamente.
    • Nunca puede tener el mismo texto que el atributo ALT.
    • Nunca debe enlazar a otra imagen.
  • No incluyas un enlace al final de la descripción para volver a la imagen. Hemos visto que en muchos casos la descripción, aunque esté en la misma página, se abre en página diferente, y por tanto la navegación sería confusa porque el enlace no volvería a la página de origen.
  • Si se modifica la imagen recuerda modificar también la descripción extensa; de la misma manera, si se cambia la URL de las descripciones, recuerda cambiarla también en el atributo LONGDESC de tus imágenes.
  • Vimos que las WCAG 2.0 nos indicaban las ventajas y desventajas de incluir la descripción larga en otra página o en la misma página.

    Las recomendaciones que, para cada una de estas dos opciones, podemos concluir después del artículo son:

    Descripción larga en otra página

    Si tu descripción es muy extensa, como la del ejemplo que hemos seguido en el artículo, es mejor que incluya la descripción extensa en una página diferente, correctamente maquetada de forma semántica.

    Además, debido a los diferentes problemas que hemos visto cuando el enlace es a un ancla, sería preferible que usarás una página diferente para cada descripción.

    Cuando la descripción larga se encuentra en una página diferente se puede usar LONGDESC. Pero ten en cuenta que, por compatibilidad con versiones de navegadores y productos de apoyo antiguos, e incluso actuales que no lo soportan, debe usarse junto a alguna otra técnica, como la del enlace a la descripción tras la imagen, especialmente si la imagen está dentro de un enlace (por el bug que vimos en la extensión que usaba JQuery).

    No se debe usar la propiedad “aria-describedat” (que es parte de ARIA 1.1) porque todavía no es soportada por los navegadores ni por los productos de apoyo.

    Descripción larga en la misma página

    Si la descripción larga se encuentra en la misma página y es breve, se puede usar “aria-describedby”. Es importante que el “id” al que referencia esté aplicado al elemento contenedor de la descripción, al DIV por ejemplo, porque ten en cuenta que leerá todo el contenido de ese contenedor.

    No uses “aria-describedby” cuando la descripción es muy larga, porque ya hemos visto que se lee seguida, sin poder pararse y sin marcado semántico.

    Dado el actual soporte, es recomendable que aunque el uso de “aria-describedby” sea una técnica suficiente de las WCAG 2.0, la uses junto a otra técnica (que la descripción a la que referencias esté a continuación de la imagen; o que tras la imagen haya un enlace, un ancla, a la descripción).

    Hemos visto también otras técnicas válidas, podríamos usar algunas de las soluciones basadas en javascript (como “Descripción extensa de una imagen: accesible con lector de pantalla y visible sin imágenes activas"); o si usas HTML 5 utilizar <figure> o <picture>, añadiendo la descripción según las recomendaciones que vimos, pues hemos comprobado que no daban problemas aunque no se soportarán.

    Si la descripción está en la misma página también podríamos usar LONGDESC, pero después de comprobar los problemas que puede haber en estos casos y el soporte, es preferible usar cualquiera de las técnicas anteriores, o usar LONGDESC en combinación con otra técnica (que la descripción a la que referencias esté a continuación de la imagen; o que tras la imagen haya un enlace, un ancla, a la descripción).

    Referencias

    Artículos relacionados

    Servicios de accesibilidad


    Reseña "The Design of Everyday Things" (2013) de Don Norman

    $
    0
    0
    Portada del libro The Design of Everyday Things 2013 de Don Norman

    Autor: Don Norman

    Nº páginas: 369

    Idioma: inglés

    Formato: libro impreso y versión digital

    Fecha de publicación: 2013 (edición revisada y extendida)

    Web:jnd.org> Books

    Podéis consultar más reseñas de libros en: "Libros y reseñas"

    Sobre el libro

    Sigo reseñando clásicos, y un clásico entre los clásicos es sin duda "The Design of Everyday Things", que se publicó por primera vez en 1988 con el nombre de "The Psychology of Everyday Things". Se considera una lectura obligatoria porque describe y profundiza en los principios sobre los que se asienta el Diseño Centrado en el Usuario o la Experiencia de Usuario.

    En 2013 Don Norman publicó una edición revisada y extendida del libro, que es la que reseño en este artículo. Los principios de la psicología humana siguen siendo los mismos que en 1988, lo que significa que los principios de diseño que se tratan en el libro, -basados en la psicología, en la naturaleza de la cognición humana, la emoción, la acción y la interacción con el mundo-, son los mismos. Sin embargo la tecnología ha cambiado mucho desde la primera edición del libro y los ejemplos se habían quedado obsoletos, por ello uno de los cambios de la nueva edición es la actualización de los ejemplos.

    Pero además hay otras novedades importantes en la edición de 2013. Aunque el libro trata en realidad del Diseño Centrado en el Usuario, en la edición de 1988 no hace referencia explícita al mismo, como un proceso. Sin embargo en la edición revisada de 2013 dedica un capítulo completo a HCD (Human-Centered Design).

    Tampoco hay referencias en la edición de 1988 a UX (Experiencia de Usuario), un término que no existía y que fue precisamente él uno de los primeros en utilizar años después. La primera edición del libro se centró en el diseño de productos comprensibles y usables, pero la experiencia total de un producto abarca mucho más que su usabilidad: la estética, el placer y la diversión juegan también un papel muy importante. De hecho en 2004 publicó un libro dedicado en exclusiva al "Diseño Emocional" ("Emotional Design: Why we love (or hate) everyday things"). En esta nueva edición se tratan también estas cuestiones.

    Por último, cuando escribió el libro en 1988 era un académico; después ha trabajado para empresas como Apple o HP. En la edición de 2013 habla del modelo ideal pero también de lo diferente que puede ser el mundo real, con la presión de los presupuestos, los plazos y la competencia. Los mejores productos no son siempre garantía de éxito, porque para entender los productos no es suficiente entender el diseño o la tecnología, es fundamental entender el negocio.

    Os recomiendo el curso de Don Norman "Introduction to the Design of Everyday Things”, que imparte en la plataforma Udacity y que precisamente está basado en el libro. El curso es gratuito y ya lo han hecho más 58.000 alumnos. Yo lo seguí el año pasado, y además de ameno, inspirador y muy práctico, es fantástico encontrar cientos de ejemplos compartidos por los alumnos.

    A continuación resumo las claves del libro, que os recomiendo que leáis, pues el resumen no puede sustituir a la explicación detallada de todos los conceptos y los numerosos ejemplos que ofrece.

    Objetivos del libro

    El objetivo es convertir a los lectores en grandes observadores del absurdo, del mal diseño que da lugar a muchos de los problemas de la vida moderna, especialmente de la tecnología. También a convertirlos en observadores del buen diseño, de cómo los diseñadores reflexivos han trabajado para que nuestra vida sea más sencilla.

    Un buen diseño es en realidad mucho más difícil de percibir que un mal diseño, porque el buen diseño se adapta a nuestras necesidades tan bien que se vuelve invisible, no llama la atención sobre sí mismo. Un mal diseño sin embargo se hace muy notable.

    El libro nos guiará a través de los principios fundamentales que se requieren para:

    • crear o seleccionar productos usables y comprensibles, que proporcionan placer y satisfacción;
    • eliminar los problemas y buscar alternativas para aquellos productos que no cumplen estos requisitos.

    1. The Psychopathology of Everyday Things

    Un buen diseño (en todo el libro, diseño en el sentido amplio, no en el sentido de diseño gráfico) debe tener dos características: "discoverability" y "understanding", que nos permiten descubrir lo que hace un objeto o producto, cómo funciona, qué operaciones son posibles, dónde y cómo deben hacerse.

    Para ello hay que comprender seis conceptos básicos que desgrana en este y otros capítulos:

    • Affordances. Todas las posibilidades de acción de un objeto que son inmediatamente percibidas por el usuario. No es una cualidad del objeto, es una relación determinada conjuntamente por las cualidades del objeto y las capacidades del usuario, que se nutre de experiencias pasadas, estimaciones comparando otro tipo de vivencias, etc.
    • Signifiers. Comunican dónde debe llevarse a cabo la acción, son señales o etiquetas, muy importantes porque comunican cómo usar el diseño, y que por tanto deben ser perceptibles.
    • Constraints. Las restricciones, las limitaciones del diseño (físicas, lógicas, semánticas y culturales), son indicios poderosos porque reducen el conjunto de posibles acciones, guían el uso y facilitan la interpretación.
    • Mappings. Trata de la relación entre los elementos de dos o más conjuntos. Cuando hay correspondencia espacial entre la disposición de los controles y los dispositivos controlados, así como contigüidad temporal, es más fácil determinar cómo usarlos.
    • Feedback. Es la comunicación completa y continua de los resultados de una acción y del estado actual del sistema. Debe ser suficientemente informativa y diferenciar la información importante de la que no lo es: ofrecer poca información o demasiada puede ser más molesto que no ofrecer ninguna.
    • “The conceptual model of the system", una explicación muy simplificada de cómo funciona algo. No hay que confundirlo con el "modelo mental" que es el modelo conceptual en la mente de las personas, que representa su comprensión de cómo funciona algo;o con la "imagen del sistema", que es lo que se puede derivar del mismo y de su documentación.

      El modelo mental de una persona se crea a través de la interacción con el producto y la imagen del sistema; lo creamos a partir de la experiencia y la formación, a partir de lo que el dispositivo parece y a partir de otras cosas similares que usamos en el pasado, en base a los anuncios, a lo que hemos leído en el manual, etc.

      Los diseñadores esperan que el modelo del usuario sea idéntico al suyo, pero la carga de la comunicación es con la imagen del sistema. Cuando la imagen del sistema es incoherente, inadecuada, incompleta o contradictoria habrá problemas.

      Un buen modelo conceptual permite predecir los efectos de nuestras acciones y nos da una sensación de control. Sin un buen modelo, operamos de memoria, a ciegas; hacemos operaciones que nos dijeron que hiciéramos; no comprendemos por qué, qué efectos esperar, o qué hacer si las cosas van mal.

    Los productos y sus diseñadores deben entender a las personas, no se puede culpar a las personas de:

    • no usar los productos como desearían sus diseñadores;
    • no entender las reglas, a menudo arbitrarias y sin sentido, que dictan los productos para su uso;
    • no haber leído las instrucciones a veces más complejas que el propio producto;
    • cometer errores, porque los humanos cometemos errores.

    2. The Psychology of Everyday Actions

    Diferencia entre:

    • Procesamiento inconsciente. Es rápido y automático, reconoce la relación entre lo que estamos experimentando y lo que vivimos en el pasado.
    • Procesamiento consciente. Es lento y trabajoso, ponderamos decisiones, pensamos a través de alternativas, comparamos diferentes opciones.

    Por otra parte, el pensamiento no puede separarse de la emoción. Los pensamientos conducen a emociones, y las emociones conducen a pensamientos. El cerebro está estructurado para actuar sobre el mundo, y cada acción lleva consigo expectativas, y estas expectativas conducen a emociones.

    Distingue tres niveles de procesamiento dentro del cerebro, diferentes, pero trabajando en concierto, por ello el diseño debe realizarse en los tres niveles:

    • “visceral level”, es el nivel más básico y nos permite responder con rapidez y de forma inconsciente, sin conocimiento o control consciente.

      La respuesta visceral es acerca de la percepción inmediata y los grandes diseñadores utilizan la estética para producir respuestas viscerales, porque en este nivel algo nos atrae o nos repulsa, y esto no tiene que ver con lo usable, eficaz o comprensible que es el producto.

    • “behavioral level”, es el hogar de las habilidades aprendidas. Las acciones y el análisis a este nivel son en gran parte subconscientes. Cuando realizamos una acción bien aprendida, lo único que tenemos que hacer es pensar en la meta y el nivel de “behavioral level” se encarga de todos los detalles.

      En este nivel cada acción se asocia con una expectativa. Un resultado positivo tendrá una respuesta afectiva positiva; y uno negativo una respuesta afectiva negativa. Tenemos sensación de control cuando existe una buena comprensión y conocimiento de los resultados, y una sensación de falta de control y de frustración cuando las cosas no salen según lo planeado, y especialmente cuando no se conoce la razón ni las posibles soluciones. De ahí la importancia del “feedback”, que nos da tranquilidad.

    • “reflective level”: es el hogar de la cognición consciente y por tanto es más lento. Aquí es donde se desarrolla una comprensión profunda, donde tiene lugar el razonamiento y la toma de decisiones conscientes. Si los anteriores niveles eran el hogar de las emociones básicas, aquí reside el nivel más alto de las emociones.

    Por otra parte diferencia en cada acción humana siete etapas, que pasa a identificar con cada uno de estos niveles de procesamiento. Además podemos asociar a cada etapa una pregunta que nos proporciona una lista de comprobación básica:

    • Metas:¿Qué quiero lograr?
    • Ejecución, aquí tratamos de averiguar cómo funciona el objeto o producto. Entran en juego los “signifiers”, los “constraints”, los “mappings”, y el modelo conceptual.
      • Plan (reflective): ¿cuáles son las alternativas?
      • Specify (behavioral): ¿qué puedo hacer?
      • Perform (visceral): ¿cómo puedo hacerlo?
    • Evaluación, cuando fallan las cosas, aquí trataremos de averiguar lo que pasó, y qué otras cosas podemos hacer. Entran en juego el “feedback” y el modelo conceptual.
      • Compare (reflective): ¿he logrado mi meta?
      • Interpret (behavioral): ¿qué significa?
      • Perceive (visceral): ¿qué ha ocurrido?

    No culpes a la gente cuando no pueden utilizar tus productos correctamente, eso es señal de que el producto puede ser mejorado: proporciona ayuda y orientación; informa correctamente de los errores y la solución para que los usuarios continúen con su tarea, no les hagas empezar de nuevo.

    3. Knowledge In the Head and In the World

    En este capítulo trata de la diferencia de que los conocimientos para realizar una tarea estén:

    • “in the world”, y por tanto la necesidad de aprender disminuye
    • “in the head”, y por tanto debemos aprenderlos y hacer uso de la memoria

    Al hablar de la memoria tenemos que diferenciar:

    • La memoria a corto plazo. La información se retiene automáticamente; es recuperada sin esfuerzo; es muy frágil: si te distraes la olvidas; y la cantidad de información que puede ser retenida de esta manera es muy limitada. Se ve afectada por el tiempo (como los mensajes que aparecen poco rato en pantalla y desaparecen), el número de ítems y la familiaridad del material.

      El límite tradicional que se suele indicar es de cinco a siete elementos (recomienda reducirlo de tres a cinco elementos); de diez a doce si el material se repite continuamente (“rehearsing”).

    • La memoria a largo plazo. Es la memoria del pasado y cuesta más tiempo y esfuerzo recuperarla. Además se reconstruye y se interpreta cada vez que la recuperamos, y por eso está sujeta a sesgos y distorsiones.

      La facilidad para recuperar experiencias y conocimientos de la memoria a largo plazo depende de cómo interpretamos el material en primer lugar. Lo que se almacena bajo una misma interpretación probablemente no se puede encontrar más adelante cuando es buscado bajo alguna otra interpretación.

      Cuando lo que se está aprendiendo parece arbitrario, sin relación entre sí ni una estructura subyacente, es más difícil de aprender, lleva más tiempo y esfuerzo; además, cuando surge un problema no tienes pistas sobre lo que ha ido mal o cómo solucionar el problema. Parte de la potencia de un buen modelo conceptual reside en su capacidad de dar sentido a las cosas.

    Recuerda que el pensamiento consciente requiere tiempo y recursos mentales. Pero las habilidades aprendidas, la práctica continuada, automatiza la acción, no necesita del control consciente, salvo para el aprendizaje inicial y para hacer frente a situaciones inesperadas.

    Ofrece estructuras significativas; añade limitaciones apropiadas para obligar a determinadas acciones (“constraints” ); ofrece un buen “feedback”, “affordances” y “signifiers”. Un “mapping” correcto reduce la carga de memoria, aunque hay que tener en cuenta que un correcto “mapping” puede depender de la cultura. La elección de la metáfora dicta el diseño adecuado para la interacción.

    Intenta conseguir, siempre que se pueda, que recordar sea innecesario.

    4. Knowing What to Do: Constraints, Discoverability, and Feedback

    ¿Cómo determinamos cómo operar con algo que nunca hemos visto antes? No tenemos más remedio que combinar el conocimiento “in the world” con el conocimiento “in the head”. Se puede consultar una tabla comparativa entre ambos en la página 110.

    En este capítulo se centra en el conocimiento “in the world”, y comienza con los “constraints”, las restricciones que limitan el conjunto de posibles acciones, que pueden ser físicas, culturales, semánticas o lógicas. Pueden consistir en:

    • forzar funciones
    • forzar a que una operación se haga en la secuencia correcta
    • mantener una operación activa, evitando que alguien la detenga antes de tiempo sin haber realizado las operaciones deseadas
    • impedir, por seguridad, que un evento ocurra

    También trata el tema de las convenciones, que son un tipo de restricción cultural. Las convenciones proporcionan una valiosa orientación en las situaciones nuevas, y las convenciones generalmente aceptadas son difíciles de cambiar, aunque la alternativa propuesta sea mejor. La gente se opone a los cambios porque requieren un nuevo aprendizaje.

    Si una nueva forma de hacer las cosas es solo ligeramente mejor que la anterior, es mejor ser consistente con las convenciones actuales. Solo cuando una nueva forma de hacer las cosas es muy superior a otra, los beneficios del cambio son mayores que la dificultad del cambio.

    5. Human Error? No, Bad Design

    Si el sistema le ha permitido al usuario cometer un error, está mal diseñado. Si el sistema induce a error, entonces está realmente mal diseñado. ¿Por qué se equivoca la gente? Debido a que los diseños se centran en los requisitos del sistema y las máquinas, y no en las personas.

    Distingue dos tipos de errores:

    • “slip”, ocurre cuando una persona tiene la intención de hacer una acción y termina haciendo otra. Distinguimos:
      • “capture slips” en vez de hacer la acción deseada haces otra más frecuente, o que has hecho hace poco, porque tienen partes idénticas y una es más familiar que la otra. Los diseñadores deben evitar los procedimientos que tienen unos pasos idénticos, pero luego divergen. Siempre que sea posible, deben ser diseñados para ser diferentes desde el principio.
      • “description-similarity slips”: se actúa sobre un elemento similar al de destino. Los diseñadores necesitan asegurar que los controles y pantallas para diferentes propósitos son significativamente diferentes unas de otras.
      • “mode errors” ocurre cuando un dispositivo tiene diferentes estados (“modos”) en los que los mismos controles tienen diferentes significados (como un reloj con múltiples funciones). Los errores de modo son inevitables en cualquier cosa que tenga más posibles acciones que controles o indicadores; lo que suele ocurrir cuando agregamos más y más funciones a los dispositivos.
      • memoria-lapse, la memoria falla, por lo que la acción no se realiza (o no se hacen todos los pasos) o sus resultados no se evalúan. La causa inmediata suelen ser las interrupciones o los muchos pasos necesarios entre el inicio y el final de las operaciones que sobrecargan la capacidad de la memoria a corto plazo. Por ello, minimiza el número de pasos y ofrece feedback.
    • “mistakes”, se producen cuando se establece la meta equivocada o se forma un mal plan. A partir de ese momento, incluso si se ejecutan las acciones adecuadamente, estas son inapropiadas porque forman parte de un plan equivocado. Muchos errores surgen porque la gente tiende a confiar en las experiencias recordadas más que en un análisis más sistemático. Tomamos decisiones basadas en la memoria, que está sujeta a sesgos.

      Existen tres modos de comportamiento:

      • Skill-based behavior. Cuando los trabajadores son extremadamente expertos en su trabajo, hacen las tareas rutinarias con poco o ningún pensamiento o atención consciente. Normalmente aquí se producirán “slips”.
      • Rule-based behavior. Si se selecciona la regla equivocada (porque se interpreta mal la situación, el resultado se evalúa incorrectamente, etc.) es un error, que puede llevar a más problemas a medida que continua el ciclo de acción; si se produce un error en la ejecución de la regla normalmente es un “slip”. Se debe proporcionar la mayor orientación posible para asegurar que el estado actual de las cosas se muestra de forma coherente y fácilmente interpretable.
      • Knowledge-based procedures. Cuando ocurren eventos no familiares, donde no se pueden aplicar las habilidades ni las normas existentes, si se diagnostica mal la situación el esfuerzo se dirigirá a resolver el problema equivocado y estaremos ante un error. En este caso lo esencial es un modelo conceptual apropiado para guiar el desarrollo del plan y la interpretación de la situación.

      Y por último también tenemos memory-lapse mistakes cuando el lapso de memoria lleva a olvidar la meta o plan de acción, debido muchas veces a las interrupciones. Por eso hay que asegurar que toda la información relevante está continuamente disponible.

    En resumen, los “slips” son el resultado de acciones subconscientes, y les ocurren más a los usuarios expertos, muchas veces por falta de atención pues hacen las tareas de forma mucho más automática que los novatos; y los “mistakes” son el resultado de deliberaciones conscientes.

    Los “mistakes” se presentan a menudo por la información ambigua o poco clara sobre el estado actual de un sistema, la falta de un buen modelo conceptual o un feedback de baja calidad sobre lo que ha sucedido en realidad. Una fuente importante de errores, especialmente de lapsos de memoria, son las interrupciones o distracciones. La mayoría de los sistemas hacen que sea difícil reanudar la tarea después de una interrupción, pues no ofrecen información crítica que necesita el usuario para recordar las numerosas pequeñas decisiones que había tomado.

    Es relativamente fácil diseñar para la situación en la que todo va bien, donde la gente utiliza el dispositivo de la manera que se pretendía y no se producen acontecimientos imprevistos. La parte difícil es diseñar para cuando las cosas van mal.

    Estos son algunos de los consejos para evitar errores:

    • Añadir restricciones (“constraints”). Por ejemplo, si un control no es relevante para la tarea actual, no está visible en pantalla.
    • Ofrecer la opción de “Deshacer”.
    • Pedir confirmación y ofrecer mensajes de error.
    • “Sensibility checks”. Los sistemas menos inteligentes siguen ciegamente mis órdenes, los inteligentes se dan cuenta, por ejemplo, de que estoy ordenando una transacción de una cantidad enorme, mucho mayor que otras habituales, y me avisan.
    • Minimizar los “slips”. La solución no es que es usuario tenga que prestar siempre mucha atención consciente, porque el comportamiento especializado es subconsciente, y por tanto rápido, sin esfuerzo, y por lo general preciso. Se minimizan diferenciando claramente los diferentes procedimientos (que no tengan pasos similares) y controles. Ofreciendo retroalimentación perceptible, junto a mecanismos que permiten deshacer el error, y evitando las interrupciones.
    • Ponga los conocimientos necesarios para operar la tecnología “in the world”. No obligues a que todo el conocimiento esté en la cabeza, esto ayuda especialmente a los no expertos. Pero también a los expertos cuando necesitan llevar a cabo un operación poco frecuente. Haz las cosas visibles, proporciona información, que sea posible saber qué se puede hacer y poder determinar el estado del sistema fácilmente y con precisión.

    6. Design Thinking

    Normalmente, el problema que nos preguntan no es en realidad el problema raíz, solo un síntoma. Una solución brillante para el problema equivocado puede ser peor que ninguna solución. Los buenos diseñadores nunca empiezan por tratar de resolver el problema que les dicen, comienzan por tratar de entender cuáles son los verdaderos problemas, en un proceso iterativo, antes de proponer una solución, no sin antes considerar una amplia gama de soluciones.

    Este proceso se llama “design thinking” y utiliza dos herramientas: Human-centered Design (HCD) y “The double-diamond diverge-converge model of design”.

    HCD (Human-centered Design) es el proceso que garantiza que las necesidades de las personas se cumplan, que el producto resultante sea comprensible y utilizable, que lleve a cabo las tareas deseadas, y que la experiencia de uso sea positiva y satisfactoria. Por tanto nos garantiza resolver los problemas y hacerlo de una manera acorde con las necesidades y capacidades humanas.

    El principio fundamental es resolver el problema correcto. Y tiene dos grandes fases: encontrar el problema (“discover” and “define”) y encontrar la solución ("develop” and “deliver”) es lo que el Design Council (UK) describió en 2005 como el "double-diamond design process model".

    En Human-centered Design (HCD) se distinguen cuatro fases diferentes e iterativas.

    1. Observation

    El investigador estudia a los potenciales clientes y a las personas que van a utilizar el producto, observa sus actividades, intenta entender sus verdaderos intereses, motivaciones y necesidades. La definición del problema para el diseño de productos provendrá de esta profunda comprensión de las metas que la gente está tratando de lograr y los impedimentos que experimentan.

    Una de sus técnicas es observar al público objetivo en su entorno, donde van a utilizar el producto o servicio en la realidad. Esta técnica se llama etnografía aplicada, un método adaptado del campo de la antropología, pero diferente, porque los objetivos son diferentes.

    Dedica un apartado a la diferencia entre la investigación de diseño y la investigación de marketing. El diseño y el marketing son dos campos complementarios, pero cada uno tiene un enfoque diferente. El diseño quiere saber lo que la gente realmente necesita y cómo utiliza realmente el producto o servicio. El marketing quiere saber lo que la gente va a compra, que incluye el conocimiento de cómo toman sus decisiones de compra.

    Estos diferentes objetivos conducen a diferentes métodos de investigación:

    • Los diseñadores tienden a utilizar métodos de observación cualitativos, mediante los cuales pueden estudiar en profundidad a las personas, entender cómo hacen sus actividades y los factores de su entorno que entran en juego. Normalmente solo examinan un pequeño número de personas.
    • El marketing se ocupa de los clientes. ¿Quién podría comprar el artículo? ¿Qué factores podrían atraerle para considerar la compra de un producto? Se utilizan para ello estudios cuantitativos a gran escala, focus group, encuestas y cuestionarios. O por ejemplo se ha generalizado en los sitios web el uso de test A/B.

    Los diferentes métodos tienen objetivos diferentes y producen resultados diferentes.

    Los diseñadores se quejan de que los métodos utilizados por el marketing no reflejan el comportamiento real, no dicen nada de las necesidades reales de la gente, de sus deseos y de las razones de sus actividades. Que dan una visión superficial de un gran número de personas.

    La gente de marketing se queja de que, a pesar de los que métodos de investigación de diseño dan una visión profunda, el número de personas que se observa es muy pequeño.

    El debate no es útil. Necesitamos ambos. Los diseñadores entienden lo que la gente realmente necesita. El marketing entiende lo que las personas quieren comprar. No es lo mismo, son dos enfoques, y por ello deben trabajar juntos en equipo.

    2. Idea generation (ideation)

    Una vez que se determinan los requisitos de diseño, el siguiente paso para un equipo de diseño es generar soluciones potenciales. Este proceso se llama generación de la idea o “ideation”.

    Hay muchos métodos y muchos de ellos caen bajo el título de "lluvia de ideas." Cualquiera que sea el método utilizado, hay varias reglas:

    • Generar muchas ideas. Es peligroso obsesionarse con una o dos ideas demasiado pronto en el proceso.
    • Ser creativo sin tener en cuenta las limitaciones. Evita criticar las ideas o desecharlas demasiado pronto, incluso las más locas, pueden contener ideas creativas que más tarde se pueden extraer y adaptar a la idea final seleccionada.
    • Pregúntalo todo, incluso si la pregunta parece "estúpida".

    3. Prototyping

    La única manera de saber realmente si una idea es razonable es probarla. Construye un prototipo o maqueta rápida para cada posible solución, por ejemplo a lapiz. A veces las ideas se transmiten mejor por bocetos, sobre todo si están desarrollando servicios de difícil prototipado. Pone como ejemplo la técnica de “Wizard of Oz”.

    Los prototipos durante la fase de especificación del problema se hacen principalmente para asegurar que el problema se entiende bien. Durante la fase de solución del problema de diseño se realizan prototipos para comunicar la solución propuesta.

    4. Testing

    Se testea el prototipo con el público objetivo. Si el producto se utiliza individualmente, la prueba será individual. Aunque a veces es muy interesante hacer que lo utilicen dos personas juntas: una persona opera el prototipo, la otra guía las acciones y la interpretación de los resultados (en voz alta). Esto hace que hablen de sus ideas, hipótesis y frustraciones abiertamente y de forma natural.

    El equipo de investigación debe observar, sin distraer. A menudo se graba, para mostrarlo a otros miembros del equipo o para su revisión. Cuando termina el estudio, se puede obtener información más detallada acerca de los procesos de pensamiento de la gente haciéndoles volver sobre sus pasos, recordándoles sus acciones y cuestionándolas. A veces ayuda mostrarles las grabaciones de sus actividades como recordatorio.

    Según Jakob Nielsen basta con estudiar a cinco personas. Entonces se estudian los resultados, se refinan, y se hace otra iteración, probando con cinco personas diferentes. Cinco es por lo general suficiente para dar grandes resultados. Es mejor más iteraciones que más personas.

    Los test se realizan en la fase de especificación del problema para asegurar que el problema se entiende bien. En la fase de solución del problema se hacen para asegurar que el nuevo diseño responde a las necesidades y capacidades de los que van a utilizarlo.

    La parte más difícil del diseño es conseguir los requisitos correctos, lo que garantiza que se está resolviendo el problema correcto. Los requisitos realizados en abstracto están invariablemente mal. Los requisitos establecidos por preguntar a las personas lo que necesitan están invariablemente mal (aunque expliquen cuidadosamente cómo hacen sus tareas, cuando los observas ves que se desvían de su propia descripción). Los requisitos deben especificarse por ver a la gente desenvolviéndose en su entorno.

    Con cada ciclo, los ensayos y observaciones pueden ser más específicos y más eficientes, las ideas se clarifican, las especificaciones están mejor definidas, y los prototipos son aproximaciones más cercanas al objetivo, al producto real. Después de las primeras iteraciones es hora de empezar a converger en una solución.

    Diseño centrado en la actividad

    ¿Y si el producto está destinado a todo el mundo?¿cómo podemos pretender dar cabida a todos ellos? La respuesta es centrarse en las actividades, no en las personas individuales: lo llama diseño centrado en la actividad.

    El modelo conceptual del producto se construirá en torno al modelo conceptual de la actividad, porque las actividades de las personas en todo el mundo tienden a ser similares. Además las personas están más dispuestas a aprender cosas centradas en las actividades que aquellas que parecen arbitrarias.

    No hay que confundir tarea con actividad. Diseñar para tareas suele ser demasiado restrictivo. Una actividad es una estructura de alto nivel, tal vez "Ir de compras". Conlleva una serie de tareas con un objetivo común. Una tarea es un componente de nivel inferior de una actividad, tales como "conducir al mercado", "encontrar una cesta de la compra", etc.

    Los productos deben dar apoyo a las actividades y a las diferentes tareas de cada una. Los dispositivos bien diseñados empaquetan juntas las diversas tareas que se requieren para una actividad.

    Las actividades son jerárquicas, por lo que una actividad de alto nivel puede tener bajo ella otras de nivel inferior, que a su vez se desglosan en tareas. Las tareas son finalmente ejecutadas por operaciones básicas.

    Diseñe para los individuos y los resultados pueden ser maravilloso para esas personas en particular pero un desastre para otros. Diseñe para las actividades y el resultado será utilizable por todos.

    Insiste en la importancia de que el proceso HCD sea iterativo, especialmente en las etapas iniciales, en las posteriores a veces es complicado, por ejemplo si el producto es un coche. Por ello los mejores métodos combinan los beneficios de la iteración propia de las metodologías ágiles (en este caso iteraciones dentro de cada etapa) y las revisiones por etapa propias de las metodologías tradicionales.

    El truco consiste en retrasar las especificaciones precisas de los requisitos del producto hasta algunas pruebas iterativas con prototipos desplegados rápidamente, manteniendo así bajo control la planificación, el presupuesto y la calidad.

    La gestión de los proyectos

    La parte más difícil del desarrollo de productos complejos es la gestión: organizar, comunicar y sincronizar a las diferentes personas, grupos y divisiones departamentales implicadas.

    El proceso de HCD describe el ideal. Pero la realidad de la vida dentro de un negocio a menudo obliga a las personas a comportarse de manera muy diferente al ideal.

    Hay muchas presiones. Es típico que se pida que incluyas características que está ofreciendo la competencia, o una nueva tecnología. Otros grandes desafíos son los plazos y los presupuestos insuficientes; o la viabilidad financiera, que por lo general significa rentabilidad. También es importante que tenga un fácil mantenimiento. A veces los clientes no son los usuarios finales, y es necesario estudiar a ambos.

    También hay que lidiar con la diferente visión del producto de cada disciplina, a veces con requisitos contradictorios o incompatibles, pero correctos cuando se ven desde sus respectivas perspectivas. Por ello es importante tener equipos multidisplinares, que aprendan a entender y respetar la requisitos de los otros. Si todos los puntos de vista y requisitos son entendidos por todos los implicados, a menudo es posible pensar en soluciones creativas que satisfagan a la mayoría.

    También hay que en cuenta a las personas con necesidades especiales, y el enfoque correcto es el llamado diseño universal, que beneficia a todos los usuarios y especialmente a estas personas. Y la clave para ello es la flexibilidad del diseño, que puedan ajustarlo a sus necesidades.

    Las soluciones fijas invariablemente fallan con algunas personas; las soluciones flexibles al menos ofrecen una oportunidad para que las personas con necesidades diferentes. A veces es imposible construir un producto que se adapte a todos, así que la respuesta puede ser la construcción de diferentes versiones del producto.

    También reflexiona sobre la complejidad y la confusión. La complejidad es buena, la confusión es mala. La confusión no está en el objeto, está en la mente. Y para evitarla es necesario un buen modelo conceptual: las cosas complejas no son complicadas una vez que se entienden.

    La normalización es un avance importante en la usabilidad, por ejemplo puedes conducir cualquier coche, en cualquier lugar del mundo. El problema es que las normas pueden tardar tanto tiempo en establecerse que para el momento en que entran en la práctica pueden ser irrelevantes. Sin embargo, las normas son necesarias. Simplifican nuestras vidas y pueden hacen posible que diferentes equipos de diferentes marcas puedan trabajar juntos en armonía.

    7. Design In the World of Business

    En este capítulo sigue reflexionando sobre la diferencia entre el modelo ideal y el proceso de diseño en el mundo real, donde hay que tener en cuenta la presión de la competencia (con la que solo puedes competir en precio, características y calidad, y además hay que ser más rápidos que ellos), los presupuestos y los plazos, siempre escasos.

    Hace especial énfasis en la "Featuritis", la tentación mortal de añadir más características, porque así lo expresan los clientes, porque las añade la competencia o porque las ventas bajan y así se empuja a los usuarios a actualizarse. Es difícil que un producto puede permanecer utilizable y comprensible con todas las características especiales que se le van añadiendo con el tiempo.

    Hay dos formas de innovación: la incremental y la radical. La más común y poderosa es la incremental, pequeñas mejoras incrementales, producto de las pruebas y el perfeccionamiento continuo. La más espectacular, y la que muchos buscan, es la radical, pero la mayoría de las ideas radicales fallan, e incluso aquellas que tienen éxito es a menudo después de mucho tiempo. Aunque la tecnología cambia rápidamente, las personas son resistentes a cambiar su forma de hacer las cosas.

    También aborda aspectos morales. Estamos rodeados de objetos de deseo, no objetos de uso, ni siquiera de objetos duraderos. Porque las ventas no pueden parar. El diseño de las cosas cotidianas está en peligro de convertirse en el diseño de sobrecargadas cosas superfluas e innecesarias para seguir vendiendo.Reflexiona también sobre las repercusiones que esto tiene sobre el medioambiente.

    Los diseñadores necesitan hacer cosas que satisfacen las necesidades de las personas, en términos de función (comprensibles y usables), y en términos de su capacidad para ofrecer emocionalmente satisfacción, orgullo y deleite. En otras palabras, el diseño debe ser pensado como una experiencia total.

    Pero en el mundo real no es suficiente. Un diseño que la gente no compra es un diseño fallido, no importa lo bueno que sea. Y tiene que ser fiable y estar en la fecha prevista. Y tiene que ajustarse al presupuesto, ser viable, y dentro de las limitaciones de fabricación o programación. Y debe ofrecer un buen servicio al cliente.

    Para satisfacer las múltiples necesidades se requiere paciencia y una combinación de conocimientos técnicos, del negocio y habilidades sociales para interactuar con los muchos grupos de personas involucrados, cada uno con su agenda y todos ellos convencidos de que sus requisitos son críticos.


    Tetera que tiene la boca para servir el té y el asa en el mismo lado.

    Esta tetera está basada en la que aparece en la tapa del libro y que Don Norman toma de la artista francesa Jacques Carelman (de su libro "Catalogue d’objets introuvables"). Ejemplifica que diseñar cosas bonitas, pero que no satisfacen las necesidades y expectativas de los usuarios, es absurdo. Le agradezco a Daniel Mordecki enormemente el regalo, que tengo siempre junto al monitor .

    Podéis consultar más reseñas de libros en: "Libros y reseñas"

    Reseña "Experiencia de Usuario: Principios y Métodos" de Yusef Hassan Montero

    $
    0
    0
    Portada del libro Experiencia de Usuario: Principios y Métodos de Yusef Hassan Montero

    Autor: Yusef Hassan Montero

    Nº páginas: 152

    Idioma: español

    Formato: versión digital

    Fecha de publicación: 2015

    "Experiencia de Usuario: Principios y Métodos" en Amazon (precio 3.99 euros)

    Podéis consultar más reseñas de libros en: "Libros y reseñas"

    No se publican demasiados libros sobre UX en español. Así que estamos de enhorabuena porque Yusef Hassan Montero, yo creo que conocido por todos, acaba de publicar uno muy recomendable. Está pensado tanto para los que quieren introducirse en el diseño de experiencias de usuario, como para ser utilizado a modo de referencia por los profesionales de esta disciplina.

    El libro se estructura en tres grandes bloques.

    Conceptos fundamentales

    En él se describen y explican los conceptos esenciales para comprender y fundamentar los siguientes capítulos: usabilidad, accesibilidad, arquitectura de información, diseño centrado en el usuario, interacción y estilos de interacción, affordance, modelos mentales, necesidades y estrategias de búsqueda de información y relación esfuerzo-beneficio.

    Dedica a cada concepto dos o tres páginas, los explica de forma clara y concisa (no hay paja en este libro), e incluye al final de cada uno bibliografía relacionada.

    Principios de diseño

    En este apartado se recogen y desgranan los principios de diseño más destacados sobre los que partir a la hora de tomar decisiones de diseño: clasificación, color, eficiencia, error humano, estética, fotografías, gestalt, iconos, inteligencia colectiva, jerarquía visual, legibilidad e inteligibilidad, ley de Fitts, mapeo natural, ordenación, relevancia, taxonomías, toma de decisiones, y visibilidad y retroalimentación.

    De nuevo explica cada uno de ellos de forma concisa, en este caso con una media de cuatro páginas por principio. Incluye en cada uno ejemplos, bibliografía y una relación de los principios con los que está relacionado.

    Métodos

    En esta parte se describen los métodos y técnicas más importantes del Diseño Centrado en el Usuario: analítica web, card sorting (y treejack), diagramas de interacción, diseño modular, encuestas y entrevistas, evaluación heurística, personajes y escenarios (y User Journey Maps), pruebas A/B, pruebas con usuarios, ROI y wireframes1.

    La organización es la misma que en los apartados anteriores, una media de cuatro páginas para cada uno, indicando su función y procedimiento, con ejemplos, bibliografía y las etapas del proceso para las que resultan pertinentes.


    Por mi parte os recomiendo sin lugar a dudas el libro. Es claro, es conciso y va al grano, con ejemplos y con bibliografía asociada a cada concepto. El propio diseño y estructura del libro hace que sea muy cómodo de leer, tanto de forma lineal como a modo de consulta, como un glosario muy detallado.

    [1] Le agradezco la referencia en este apartado a mi artículo "Wireframes").

    Podéis consultar más reseñas de libros en: "Libros y reseñas"

    Lanzamos el curso online y gratuito "Aprende Accesibilidad Web Paso a Paso"

    $
    0
    0

    Hoy tengo la satisfacción de anunciaros que, gracias a la Cátedra Telefónica - Universidad de Alicante "Impacto de las Tecnologías del Lenguaje Humano en la Inclusión Social", hemos publicado en la plataforma Udemy el curso "Aprende Accesibilidad Web Paso a Paso".

    Curso 'Aprende Accesibilidad Web Paso a Paso'

    Es un MOOC, y por tanto online y gratuito, para el que hemos preparado más de 6 horas de vídeo y más de 40 ejercicios tipo test para evaluar el aprendizaje.

    No hay fecha de principio ni de fin, tú marcas el ritmo en un proceso de autoaprendizaje guiado. Al finalizar el curso conocerás los principales problemas de falta de accesibilidad que presentan las páginas web y serás capaz de plantear e implementar soluciones para esos problemas.

    Los profesores que hemos preparado el curso somos:

    • Olga Carreras Montoto
    • Sergio Luján Mora. Profesor de informática de la Universidad de Alicante
    • Ester Serna Berná. Responsable del área de Desarrollo Web en el Taller Digital de la Universidad de Alicante.
    • Armando Suárez Cueto. Doctor en Informática por la Universidad de Alicante
    • Antonio Ferrández Rodríguez. Doctor en Informática por la Universidad de Alicante. Director de la Cátedra Telefónica - Universidad de Alicante "Impacto de las Tecnologías del Lenguaje Humano en la Inclusión Social".

    El curso se estructura de la siguiente manera (os indico los vídeos que he preparado en las diferentes secciones):

    1. Bienvenida al curso:

      Es una introducción y una visión general del curso donde ya veremos algunos ejemplos de problemas de accesibilidad.

    2. Qué es la accesibilidad web:

      Repasaremos la definición de accesibilidad web; cómo esta mejora la vida de las personas con discapacidad; los mitos asociados a la accesibilidad web; sus beneficios; o de la mano de Sergio Luján Mora repasaremos cosas que deberías saber sobre la accesibilidad web y ejemplos de sitios web accesibles.

    3. Las personas con discapacidad y la Web:

      En esta sección se repasan los principales tipos de discapacidad y cómo afectan al acceso a la web. Antonio Ferrández nos explicará a lo largo de diversos vídeos los diferentes productos de apoyo que emplean las personas con discapacidad.

      Un total de 21 lecciones donde por ejemplo podremos ver una entrevista con una persona sordociega.

    4. Pautas y leyes:

      En esta sección he preparado una introducción a las WCAG 2.0 y Sergio Luján Mora repasa a través de diferentes lecciones y vídeos la legislación española sobre accesibilidad web y recursos para consultar la legislación existente en otros países.

    5. Contenido accesible:

      En esta sección repasaremos a lo largo de 23 lecciones, la mayoría en vídeo, cómo lograr que el contenido de una página web sea accesible y comprensible.

      Hablaremos de la accesibilidad de las imágenes, del audio y del vídeo; Sergio Luján Mora tratará temas como los subtítulos para el contenido multimedia o los captcha; o Ester Serna nos hablará, entre otras cosas, de la accesibilidad en relación con los encabezados, el idioma o las tablas de las páginas web.

      En esta sección he preparado varias lecciones sobre la accesibilidad del contenido multimedia y he grabado 4 vídeos:

      • Formularios accesibles I, II y II, 16 minutos de vídeo donde os explico cómo hacer accesibles vuestros formularios
      • Introducción a la accesibilidad en documentos electrónicos
    6. Navegación accesible:
    7. En esta sección aprenderemos en 13 lecciones, 12 de ellas en vídeo, a lograr que la navegación dentro de una página web y entre las páginas de un sitio web sea accesible. Por ejemplo Sergio Luján Mora nos hablará del título de la página, los enlaces "saltar a" o de las barras de navegación como listas de enlace.

      En esta sección he grabado 6 vídeos:

    • Enlaces accesibles I, II y III, 25 minutos de vídeo donde os enseñaré a hacer enlaces perceptibles, comprensibles y operables.
    • Navegación por teclado. Problemas habituales con el foco
    • Múltiples vías, ubicación y consistencia I y II
  • Diseño accesible:

    En esta sección aprenderemos a lograr que la presentación de una página web sea accesible. Entre otras cosas, Sergio Luján Mora nos hablará del color, del contraste o de la tipografía.

    Por mi parte, os enseñaré las buenas y malas prácticas así como los errores comunes de accesibilidad en los sitios Responsive Design.

  • Interacción accesible:

    En esta sección aprenderemos a lograr que la interacción de un usuario con una página web sea accesible.

    He preparado el contenido de esta sección con 4 vídeos, 27 minutos donde os hablaré de Javascript y accesibilidad y de WAI-ARIA:

    • Javascript y accesibilidad I y II
    • Introducción a WAI-ARIA I y II
  • Accesibilidad y posicionamiento:

    En esta sección he preparado 3 vídeos donde veremos una introducción al posicionamiento orgánico en buscadores:

    • Introducción al posicionamiento (SEO): conceptos básicos
    • Introducción al posicionamiento (SEO): técnicas básicas I y II, donde repasamos las principales técnicas on page que en gran medida coinciden con técnicas de accesibilidad ya vistas.
  • Análisis y evaluación de la accesibilidad:

    En esta lección os introduzco en la metodología de evaluación WCAG-EM y en las principales herramientas de evaluación automática. Ester Serna os enseñará a utilizar la herramienta TAW y barras de herramientas como Wave o Web Developer Toolbar.

  • Conclusiones
  • 100 lecciones, más de 6 horas de vídeo, por mi parte 17 vídeos que tenéis subtitulados y con transcripción accesible. Os animo a seguirlo o consultarlo, si os interesa un tema en particular. Y por supuesto espero que aprendáis mucho sobre cómo mejorar la accesibilidad web de vuestras páginas.

    Curso online y gratuito en la plataforma Udemy:

    "Aprende Accesibilidad Web paso a paso"

    Servicios de accesibilidad

    Priorizar las actividades críticas y frecuentes. "Red routes" aplicadas a UX. Ejemplos, plantilla, árbol de decisión

    $
    0
    0

    En cualquier aplicación, sea un sitio o aplicación web, app o aplicación de escritorio, el usuario puede realizar una serie de actividades que conllevan determinadas tareas con un objetivo común. Pero no todas tienen la misma relevancia.

    En este artículo repaso el concepto “red routes” de David Travis aplicado a UX, que nos ayuda a identificar las actividades críticas, los “trayectos” clave de nuestros usuarios, y a focalizarnos y a priorizar lo más importante.

    Podréis descargar una plantilla que os ayude a visualizar qué funcionalidades se encuentran en una “red route” o consultar el árbol de decisión que nos ayuda a priorizar los problemas de usabilidad, partiendo de si se encuentran o no en una “red route”.

    Qué son las "red routes"

    El concepto de “red routes” (rutas rojas) aplicado a la usabilidad es acuñado por David Travis, Managing Director de Userfocus, en 2006.

    Las “red routes” son las principales arterias viales de Londres, marcadas con líneas rojas, en las que no se puede parar o estacionar.

    Carretera con una línea roja en el arcén. Una señal indica que es una Red Route y no se puede parar de lunes a sabado de 7 a 19 horas

    Imagen de The Telegraph

    Son un 5% de las vías que soportan el 30% del tráfico rodado. El objetivo es que el tráfico sea fluido y rápido, evitando así problemas y retenciones. Gracias a ellas se ha mejorado un 20% el tiempo de recorrido en las líneas de autobús y reducido en un 6% los accidentes.

    Mapa del area metropolitana de Londres. Ciertas vías, en forma radial y circular, están marcadas en rojo

    Red Routes en Londres. Imagen del Ayuntamiento de Londres

    Con estos datos es fácil pensar en la analogía con nuestros sitios y aplicaciones. Seguro que viendo el mapa de las "rutas rojas" de Londres puedes imaginarte tu sitio web con recorridos marcados en rojo.

    David Travis es quien propuso la metáfora de trasladar el concepto de “rutas rojas” a nuestro sitio o aplicación web en su artículo “Red route usability: The key user journeys with your web site”. Es decir, identificar las actividades críticas, los trayectos clave de nuestros usuarios, y asegurar que los recorren de la manera más sencilla y rápida posible, eliminando todo obstáculo de usabilidad en ellos.

    Una “ruta roja” es un camino crucial que el usuario va a recorrer para lograr un objetivo y tenemos que garantizar que puede recorrerlo de manera sencilla, sin distracciones, sin interrupciones, ofreciendo la mejor experiencia posible.

    Por ejemplo, en un ecommerce una “ruta roja” será “elegir un producto”, otra será por ejemplo “comprar un producto”.

    Para identificar estas “rutas rojas” es necesario tener en cuenta la frecuencia de las actividades y la naturaleza crítica de la actividad. Además, las “rutas rojas” deben estar en sintonía con los objetivos clave de los usuarios.

    Priorizar y enfocarse en lo más importante, las “rutas rojas”, asegura un diseño centrado en las necesidades reales de los usuarios y es una manera de luchar contra la “Featuritis”, que comenté en la reseña "The Design of Everyday Things" (2013) de Don Norman, esa tentación de añadir más y más características. Permite que las funciones menos importantes no distraigan la atención, no sobrecarguen la interfaz.

    Definir las “rutas rojas” también nos permite decidir, en un desarrollo ágil, qué funcionalidades desarrollar primero en un software, las actividades principales que la gente espera poder llevar a cabo y por las cuales compra el producto, serían el MVP (Minimum Viable Product).

    Tal y como comentaba también en la reseña de Don Norman, cuando hablamos del diseño de actividades, hay que diferenciar entre actividad (elegir un producto, comprar un producto, etc.) de las tareas concretas en las que se desglosan.

    En el caso de “elegir un producto”, Travis nos comenta en el artículo lo importante que es para el usuario asegurarse de que está eligiendo la mejor opción. La actividad “elegir un producto” se identifica como “red route”. “Elegir un producto” es la actividad, que se puede materializar en una serie de tareas con un objetivo común: leer los comentarios sobre el producto, comparar productos, etc.

    Las “rutas rojas” según Travis deben tener cinco características:

    • Una “ruta roja“ hace referencia a una actividad completa, no a una simple tarea.
    • Una “ruta roja” tiene implícita una medida de logro obvia, como es el caso de “comprar un producto”, al contrario que las medidas de éxito generalistas, “que el sitio sea fácil de usar”.
    • Una “ruta roja” debe ser portátil a un sitio de la competencia. Una “ruta roja” es una actividad que refleja un objetivo de alto nivel del usuario en el sitio y que, por tanto, seguramente puede realizar en otro sitio de la competencia.
    • Una “ruta roja” se centra los objetivos, no en los pasos del procedimiento, no dicta una implementación concreta.
    • Una “ruta roja” es precisa y realista, se centra en los objetivos más importantes para el usuario y la organización.

    “Red routes” dentro del Diseño Centrado en el Usuario

    En el proceso del Diseño Centrado en Usuario se distinguen varias fases iterativas. En este caso voy a referenciarlas de acuerdo a las fases de Garret (ver reseña "The Elements of User Experience")

    Cinco planos de abajo a arriba: Primero Strategy: User Needs and Product Objetives. Segundo Scope: Functional Specifications and Content Requeriments. Tercero Structure: Interaction Design (en product as functionality) and Information Arquitecture (en product as information). Cuarto Skeleton: Information Design, Interface Design (en product as functionality)and Navigation Design (en product as information). Quinto Sensory Design

    Qué contenidos y funcionalidades le ofrecemos al usuario y su priorización se realizan en la fase de “Scope”.

    Por tanto, no podemos definir la arquitectura de información y el diseño de interacción, ni por tanto comenzar el prototipado (fases “Estructure” y ”Skeleton” ) sin saber cuáles son las "rutas rojas" de nuestro sitio.

    De la misma manera, no podemos identificar las "rutas rojas", sin hacer ux research, sin pasar por la fase de “Strategy”, donde obtendremos toda la información necesaria sobre nuestro público objetivo y sus necesidades, pero también sobre los objetivos de negocio.

    En consecuencia, la definición de las “rutas rojas” se asienta en la información que obtenemos durante la fase de investigación. Como os decía en Customer Journey Map, Mapa de empatía y Personas en UX Research:

    Son muchas las técnicas que podemos utilizar para conocer a nuestra audiencia o público objetivo, según las posibilidades y características de cada proyecto, y que nos permitirán recopilar diferentes datos, cuantitativos o cualitativos, según el caso: diferentes tipos de entrevistas (contextuales, en profundidad, en pares, etc. con los propios usuarios, con los departamentos de marketing, de atención al cliente, etc.), encuestas, cuestionarios, observación en contexto, focus group, tutoría entre pares, estudio de datos obtenidos de las herramientas de analítica web, estudiar lo que los usuarios dicen en los comentarios dentro y fuera del sitio o en nuestros canales de redes sociales, etc.

    Pero luego es necesario extraer conclusiones, sintetizar los datos y sobre todo humanizarlos, que esos entes vagos y abstractos “usuarios”, “clientes” se conviertan en personas con las que podamos empatizar, personas que tienen motivaciones, necesidades, expectativas y limitaciones.

    Para ello los Customer Journey Map, los Mapas de empatía y la técnica de Personas (Escenarios, User Stories) son un gran aliado.

    Por otra parte, la definición de las “rutas rojas” se integra en el análisis de tareas. También es relevante tener en cuenta el análisis comparativo de la competencia.

    ¿Cómo saber si una funcionalidad de nuestra aplicación se encuentra en una “ruta roja”?

    David Travis propone, en "How red routes can help you take charge of your product backlog" hacerse dos preguntas:

    • ¿Cuántos usuarios necesitan/usan esa función?
    • ¿Con qué frecuencia los usuarios necesitan/usan esa función?

    En base a ellas rellenamos una matriz con dos ejes: en el eje vertical la frecuencia y el horizontal el número de usuarios. El código de color nos da la prioridad, si se encuentra en una "red route".

    El ejemplo que pone es el del TomTom:

    Matriz de cuadrados. En el eje vertical: todo el tiempo, la mayor parte del tiempo, algunas veces, pocas veces. En el eje horizontal: pocas personas, algunas personas, la mayoría de las personas y todas las personas. A medida que nos acercamos al cuadrado superior derecho el color de las celdas es más rojo. Dentro de cada celda una funcionalidad, por ejemplo en la esquina superior derecha en rojo: Plan a route

    Imagen de "How red routes can help you take charge of your product backlog" de David Travis

    Para poder crear tu propia matriz puedes descagarte la plantilla en formato excel.

    Matriz de cuadrados. En el eje vertical la frecuencia de uso: siempre, la mayor parte de las veces, algunas veces, rara vez. En el eje horizontal el número de usuarios: pocos, algunos, la mayoría y todos. A medida que nos acercamos al cuadrado superior derecho el color de las celdas es más rojo.

    Descargar "Plantilla: Matriz para identificar si una funcionalidad está en una 'Red route'"(excel, 11 KB)

    Siguiendo el modelo puedes personalizar las variables que utilizas para los ejes, pues dependen mucho del sitio. Por ejemplo a veces en la frecuencia de uso se puede concretar si es diaria, semanal, mensual o ocasional. También es útil a menudo, diferenciar la matriz en base al perfil del usuario.

    La plantilla estará disponible permanentemente en el apartado "Descargas" donde se encuentran el resto de recursos descagables asociados a otros artículos.

    Se pueden encontrar variantes, según el proyecto y sus necesidades. Por ejemplo, junto a la matriz que hemos visto, en “UX Case Study. Arch Waves” de Gradinar Razvan encontramos la siguiente:

    en el eje vertical diario, semanal y mensual, y el eje horizontal las actions.

    Imagen de “UX Case Study. Arch Waves” de Gradinar Razvan

    Podéis ver otro ejemplo en el portfolio de Edmund Yu

    "Red routes" nos ayudan a priorizar los problemas de usabilidad

    David Travis propone tres preguntas que pueden hacernos priorizar los problemas de usabilidad de nuestro sitio y definir si son “críticas” y es urgente resolver, si son “serias” y hay que resolver lo antes posible o si tienen una criticidad “media” o “leve”.

    Se basa en identificar si se produce en una “ruta roja”, si es difícil de superar (y el impacto que tiene en la finalización de la tarea) y de su recurrencia.

    El árbol de decisión propuesto originalmente por Travis es:

    Árbol de decisión del que, partiendo de la pregunta de si el problema ocurre en una red route, se pregunta si es dificil de superar y si es persistente, para en base al número de respuestas No, llegar a definir el nivel leve, medio, serio y crítico

    Imagen de "How to prioritise usability problems", de David Travis

    Rik Williams, basándose en este, propone el siguiente en Red Route Usability Prioritisation Flow Chart:

    Árbol de decisión del que, partiendo de la pregunta de si el problema ocurre en una red route, se pregunta si impacta en el negocio y si es persistente, para en base al número de respuestas No, llegar a definir el nivel leve, medio, serio y crítico

    Si a alguien le interesa, David Travis da un curso online "User Experience. The ultimate guide to usability", y la sección cuatro, con 4 temas, trata precisamente de las "red routes": "SECTION 4: WHAT CAN A LONDON BUS TEACH US ABOUT USABILITY?".

    Bibliografía

    Artículos relacionados

    BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web

    $
    0
    0

    Este artículo describe la norma BS 8878:2010 Web Accessibility. Code of Practice del Reino Unido que estandariza un proceso:

    • para la creación e inclusión de una política de accesibilidad web dentro de la estrategia de cualquier organización;
    • para la consideración de la accesibilidad web a lo largo de todo el ciclo de vida de cualquier producto web.

    Índice

    Qué es la norma BS 8878:2010 Web Accessibility. Code of Practice

    La norma BS 8878:2010 Web Accessibility. Code of Practice es un estándar nacional del Reino Unido creado por el BSI (British Standards Institution).

    La norma define un proceso para la creación e inclusión de una política de accesibilidad dentro de la estrategia de cualquier organización, así como para la consideración de la accesibilidad a lo largo de todo el ciclo de vida de sus productos web.

    Está escrita en un lenguaje no técnico y se dirige a las personas con responsabilidades en materia de estrategia o desarrollo dentro de una organización. El objetivo es que puedan seguir un estándar que les indique, de manera clara y sencilla, qué hacer y cómo conseguir que sus productos web sean más accesibles y fáciles de usar.

    “Producto web”, dentro de la norma, hace referencia a cualquier sitio, servicio o aplicación web que se entrega vía IP a través de un navegador en cualquier tipo de dispositivo.

    WCAG 2.0 y BS 8878:2010

    La BS 8878:2010 no es, ni pretende ser, una alternativa a las WCAG 2.0 (o a otros estándares a los que hace referencia la norma: ISO 9241:171, UAAG, ATAG, WAI-ARIA). Al contrario, los considera indispensables para su aplicación.

    La BS 8878:2010 no establece especificaciones técnicas como lo hacen las WCAG 2.0, se centra en el proceso. Establece un estándar para la calidad del proceso de creación de productos web accesibles.

    La BS 8878:2010 estandariza el proceso necesario para integrar la consideración de la accesibilidad web dentro de una organización a través de:

    • una política general de accesibilidad web de la organización
    • una política de accesibilidad web concreta para cada uno de sus productos web

    El proceso tiene que asegurar que los equipos están tomando decisiones informadas y justificadas sobre la accesibilidad en cada etapa del desarrollo del producto, integrando este tipo de comportamiento dentro de su negocio como una práctica habitual.

    Una declaración de que el producto es conforme a la norma BS 8878:2010 NO es una declaración de que es conforme a las WCAG 2.0

    Una declaración de que el producto es conforme a la norma BS 8878:2010 es una declaración de que durante todo el proceso de desarrollo del producto se ha tenido en cuenta la accesibilidad, se han tomado las mejores decisiones y que estas son siempre justificables.

    Para incluir en un sitio la declaración de conformidad de acuerdo a la BS 8878:2010, la organización debe:

    • atender todas las recomendaciones de la norma;
    • ser capaz de justificar cualquier desviación respecto a dichas recomendaciones;
    • documentar sus procesos de decisión en la política de accesibilidad del producto que acredite que se han seguido las recomendaciones de la norma.

    La declaración puede estar basada en una autoevaluación o en una evaluación llevada a cabo por terceros.

    Antecedentes, autores y publicación

    La BS 8878:2010 se desarrolló a partir de la especificación existente, la PAS 78:2006 Guide to good practice in commissioning accessible websites.

    La PAS 78:2006 fue encargada al BSI por el DRC (Disability Rights Commission), comisión establecida por el Gobierno de Reino Unido en 1999. Su objetivo era ser una guía para el proceso de creación y mantenimiento de un sitio web, que ayudara a orientar a las personas no técnicas sobre cómo utilizar los estándares para garantizar que el sitio resultante fuera accesible.

    Sin embargo se quedó obsoleta por los cambios que han sufrido no solo los propios productos web si no también la manera de consumirlos (ver [HASSELL, 2010]).

    La BS 8878:2010 fue elaborada por la comisión IST/45 Web Accessibility del BSI, cuyo presidente fue Jonathan Hassell, por aquel entonces director de usabilidad y accesibilidad de la BBC.

    Participaron expertos en accesibilidad e inclusión social, personas con discapacidad, representantes de diversas organizaciones de personas con discapacidad u organizaciones como Vodafone, IBM, Opera, BBC, British Computer Society, University of Southampton, entre otras.

    El primer borrador se presentó en 2008 para una consulta pública generalizada y el segundo borrador en mayo de 2010. Fue revisada por 328 expertos mundiales de accesibilidad para asegurarse de que armonizaba con las normas internacionales (W3C, Adobe, etc.) y nacionales de otros países.

    Finalmente se lanzó oficialmente en diciembre de 2010, el mismo año que la ley de igualdad de Reino Unido, la Equality Act 2010 (referenciada en la norma, especialmente en el Anexo C. Discapacidad y la ley) y que establece que los productos web, no solo del sector público, deben ser accesibles para todos.

    Aunque la Equality Act no obliga a cumplir con la BS 8878:2010, es sin embargo reconocida por el UK Government’s e-Accessibility Action Plan del Gobierno Reino Unido como una herramienta clave para el desarrollo de servicios online accesibles.

    Visión general de la BS 8878:2010. ¿Qué nos enseña?

    La BS8878:2010 es un documento de 90 páginas, organizado en 8 capítulos y 15 anexos, que nos va enseñar:

    Cómo crear una política de accesibilidad web de la organización

    La política general de accesibilidad web de la organización estará integrada en la estrategia de la organización. Se refleja en un documento donde se explica el compromiso de la organización con la accesibilidad y se resume su planteamiento.

    En el capítulo 4.3 se describe cómo elaborarla, y en el Anexo E1 se incluye un ejemplo de política de accesibilidad de una organización.

    La norma explica además cómo designar un responsable (un rol o departamento con autoridad para cumplir con esta responsabilidad y que tiene una visión general de todos los productos web) que garantice que todos los productos web creados o adquiridos cumplen esta política.

    Sus responsabilidades serán:

    • elaborar la política de accesibilidad de la organización;
    • delegar responsabilidades a través de diferentes departamentos y asegurarse de que las personas en las que delega son las adecuadas (se detalla la asignación de responsabilidades en el Anexo F);
    • asumir la responsabilidad de asegurar que la organización implementa y mantiene la política de accesibilidad.

    Cómo integrar las consideraciones de accesibilidad a través del proceso de desarrollo

    La norma ayuda:

    • a identificar las decisiones que impactan en la accesibilidad a lo largo de todo el ciclo de vida del producto;
    • a tomar estas decisiones de la mejor manera posible, considerando todas las opciones e implicaciones.

    Cómo asegurar la accesibilidad web a lo largo del ciclo de vida de un producto web

    Integrada dentro una metodología de Diseño Centrado en el Usuario, utilizando diversas técnicas de investigación y pruebas en los puntos clave del proceso de producción, y considerando siempre el impacto en la accesibilidad en cada uno de los pasos que se dan.

    El mejor uso de las pautas de accesibilidad existentes en el proceso de desarrollo de productos web accesibles

    El capítulo 7 (“El uso de las pautas de accesibilidad para dirigir la producción de productos web accesibles”) trata las pautas de accesibilidad del W3C (WCAG, UAAG, ATAG, WAI-ARIA) u otras pautas de accesibilidad como la Section 508 de EEUU, y ofrece recursos y enlaces de interés (selección de librerías Javascript, técnicas para Adobe Flex o Microsoft Silverlight).

    Aborda también la adaptabilidad individualizada en un enfoque personalizado de la accesibilidad web, recomendando la aplicación de AccessForAll 3.0 (al que dedica también buena parte del Anexo K)

    Trata por último, como recomendaciones adicionales a las WCAG 2.0, las pautas de accesibilidad específicas a tener en cuenta en dispositivos móviles e ITPV, así como las pautas de accesibilidad específicas para las personas mayores.

    Cómo garantizar la accesibilidad en los productos que se adquieren o se contratan a terceros

    El capítulo 6.11 trata sobre cómo garantizar que los productos que se adquieren o se contratan a terceros se seleccionan o especifican de manera que se asegure su accesibilidad.

    En el Anexo L se incluye una batería de preguntas que se recomienda hacer antes de adquirir o contratar productos a terceros.

    Cómo documentar y justificar todas las decisiones en la política de accesibilidad del producto web

    Todas las decisiones que impactan en la accesibilidad del producto se documentan y justifican en su política de accesibilidad web.

    La política de accesibilidad de un producto web es un documento específico para ese producto web en particular, que se crea tan pronto como el producto es concebido y se va completando a medida que pasamos por las diferentes etapas de desarrollo.

    Es por tanto un documento vivo que evoluciona a lo largo de todo el ciclo de vida del producto.

    El proceso para crear productos web accesibles ocupa el capítulo 6. A lo largo de él se va detallando, en cada paso, toda la información que se debe incluir en la política de accesibilidad del producto web.

    Este capítulo 6 me parece de especial relevancia y luego lo trataré más detenidamente, indicando en cada paso a qué preguntas debe responder la política de accesibilidad del producto, preguntas que se corresponden con decisiones que siempre se han de justificar.

    El capítulo 5 “Cómo tomar decisiones justificables sobre las opciones de accesibilidad en cada paso” está dedicado en exclusiva a la justificación de las decisiones.

    En el capítulo 4.5 se resume la información que debe incluir la política de accesibilidad del producto web y en el Anexo E2 se proporciona un ejemplo de política de accesibilidad de un producto web.

    Cómo comunicar las decisiones de accesibilidad en una declaración de accesibilidad

    Las decisiones de accesibilidad del producto web se comunican a los usuarios tras el lanzamiento mediante la publicación en la web del producto de una declaración de accesibilidad.

    La elaboración de la declaración de accesibilidad se trata en los capítulos 4.4 y 4.6 y se incluye un ejemplo en el Anexo E3.

    La declaración de accesibilidad resume la política del producto de manera clara, sencilla y sin jerga (de manera que todos los usuarios puedan comprenderla) y muestra cómo se ha tenido en cuenta la accesibilidad durante el desarrollo del producto web.

    Puede incluir referencias a las pautas y especificaciones del W3C, pero si se afirma que el sitio es conforme a las WCAG 2.0 debe ser de acuerdo a los requisitos que estas establecen para incluir declaraciones de conformidad de acuerdo a las WCAG 2.0

    La declaración de accesibilidad:

    • indica cómo utilizar o personalizar el producto web para una experiencia más accesible de acuerdo a sus necesidades individuales (por ejemplo mediante opciones de personalización del navegador, mediante herramientas de preferencias del sitio, mediante versiones accesibles, etc.);
    • señala las limitaciones de accesibilidad del producto web (así como cualquier plan de mejora previsto o las alternativas que se ofrecen);
    • permite acceder a la política completa e incluye formas de contacto para que los usuarios remitan sus comentarios, sugerencias o quejas;
    • se ha de mantenerse actualizada y se debe indicar la fecha de la última actualización.

    Una declaración que sigue el ejemplo del estándar es la de la web Access8878: Accessibility Statement.

    Cómo mantener la accesibilidad tras el lanzamiento y cómo gestionar las comunicaciones de los usuarios sobre la accesibilidad del producto web

    En el capítulo 6.16 se trata el proceso de revisión y evaluación continua del producto. También trata la necesidad de asegurarse de que todos los comentarios (sugerencias, quejas, etc.) sobre el producto web vienen a través de los mecanismos de contacto indicados en su declaración de accesibilidad y que se revisan y responden de manera adecuada.

    En el Anexo M se incluye una guía para tratar las quejas de accesibilidad (cómo extraer información relevante, cómo responder, etc.)

    El proceso en detalle

    Hay dos capítulos que me interesan especialmente y en los que me centraré ahora. El capítulo 6 “Proceso para crear productos web accesibles” y el capítulo 8 “Asegurar la accesibilidad a lo largo del ciclo de vida de un producto web”.

    Proceso para crear productos web accesibles (capítulo 6)

    El proceso es muy similar al del Diseño Centrado en el Usuario, como indica la norma:

    This process is very similar to the user-centred or human-centred design process detailed in ISO 9241-210 that many organizations may already follow. Where the limited resources of the organization or the small size of the web product make the costs of following every step of the process prohibitive, organizations are advised to consider choosing the cheaper or quicker options at each step, rather than omitting steps.

    La accesibilidad se va a tener en cuenta en todo el ciclo de vida del producto web, pues cada decisión a lo largo del mismo afectará a si el producto resultante incluye o excluye a las personas con discapacidad o a las personas mayores.

    El capítulo se articula en 16 pasos. Resumo a continuación sobre qué tratan y a qué preguntas debe responder la política de accesibilidad del producto en cada uno de ellos.

    Investigación, diseño conceptual y análisis de requisitos (pasos 1-6)

    Paso 1: Definir el propósito del producto web.

    ¿Cuál es la finalidad del producto y qué esperan lograr los usuarios al usarlo?

    Paso 2: Definir el público objetivo del producto web.

    ¿Es un producto web interno (como una intranet o extranet a la que se accede con un login obligatorio) o público? ¿Se dirige a un grupo específico de personas?

    Ante una situación en la que no es posible satisfacer las necesidades de todos los públicos potenciales porque divergen o se enfrentan, tendrán prioridad las del público objetivo.

    Definir una serie de audiencias no significa que el resto de usuarios estén excluidos, sino que los requisitos, actividades de diseño y pruebas se centran en estos grupos de usuarios como los usuarios más probables del producto.

    Paso 3: Análisis de las necesidades del público objetivo

    ¿Cuáles son las necesidades generales de tu público objetivo? ¿Tienen necesidades específicas en relación con tu producto web? ¿Cómo estás investigando sus necesidades?

    Las necesidades generales de las personas con discapacidad y personas mayores de tu público objetivo deben analizarse junto a las necesidades generales de las personas sin discapacidad de tu público objetivo.

    En este capítulo se habla de la investigación etnográfica en contexto, o de la técnica Personas. La investigación permite definir y tomar decisiones sobre los requisitos específicos de accesibilidad en la especificación general de los requisitos del producto.

    En el Anexo H se aborda cómo las personas con discapacidad y las personas mayores utilizan los productos web, repasando diferentes discapacidades, necesidades, escenarios o tecnologías, y se recomiendan en cada caso distintos recursos.

    Paso 4: Plataforma y tecnología. Preferencias y restricciones del público objetivo.

    ¿El público objetivo tiene restricciones respecto a la tecnología, quizás por su coste, confianza o compatibilidad (por ejemplo si las personas mayores de nuestro público objetivo están utilizando navegadores antiguos; o si hay usuarios que están utilizando un lector de pantalla en el trabajo y otro diferente en casa; o si los empleados tienen restricciones para usar el dispositivo móvil o un sistema operativo o navegador en el trabajo, etc.)? ¿Impactará la tecnología o plataforma elegida?

    Esta información será útil cuando se tomen decisiones sobre la inclusión de herramientas de personalización (paso 8) o sobre los navegadores y productos de apoyo que se soportarán (paso 10)

    Paso 5: Definir la relación que el producto tendrá con su público objetivo

    ¿El producto web permitirá opciones personalizadas (a través del login o el uso de cookies) o apoyará a grupos más generales de usuarios (un grupo será aquel cuyos usuarios tienen un conjunto común de necesidades)?

    Influirá en las decisiones sobre el enfoque de accesibilidad que se tomarán en el paso 8.

    Paso 6: Definir los objetivos de los usuarios y las tareas que el producto web ofrecerá

    ¿Cuáles son los objetivos que los usuarios quieren lograr y cuáles las tareas que van a realizar para alcanzarlos? ¿Cómo se priorizan los objetivos y cuáles son los criterios de éxito?

    Separamos los objetivos primarios de los secundarios para priorizar el trabajo, investigándolos para nuestros diferentes targets.

    Las tareas serán probadas durante los test con usuarios.

    Se definen los criterios de éxito para evaluar luego el producto y ver si permite a su público objetivo alcanzar sus objetivos. En el anexo J (Medir el éxito del usuario) se incluyen ejemplos de criterios de éxito.

    Toma de decisiones estratégicas basadas en la investigación (pasos 7-10)

    Paso 7: Considerar el grado de experiencia de usuario que el producto web tendrá como objetivo ofrecer.

    ¿El producto web ofrecerá una experiencia “técnicamente accesible”, “usable y accesible”, “satisfactoria y accesible”?

    La organización debe definir el grado de experiencia de usuario que tendrá como objetivo poner en práctica para cada grupo de usuarios y objetivo de usuario, y documentar las razones para la elección de ese grado en la política de accesibilidad del producto.

    Se consideran tres posibles grados de experiencia de usuario:

    • “Técnicamente accesible”:¿es técnicamente posible que los usuarios accedan a la información o realicen los pasos necesarios para realizar la tarea? La accesibilidad técnica no garantiza a las personas con discapacidad una experiencia equivalente a la de las personas sin discapacidad, por tanto esta decisión debe ser justificable y ser recogida en la política como una limitación de accesibilidad.
    • “Usable y accesible”:¿los usuarios son además capaces de completar las tareas eficaz y eficientemente?
    • “Satisfactoria/divertida y accesible”:¿los usuarios están satisfechos con la experiencia? ¿es divertida (si se supone que debe serlo)?

    Los términos "eficaz", "eficiente", "satisfactorio" se toman de la ISO 9241. Se ha separado la satisfacción por ser más difícil de alcanzar que la eficacia y eficiencia.

    En el Anexo I3 (Ejemplos de propósito, audiencias, objetivos de usuario, tareas de usuario y grados de experiencia de usuario para estas tareas. Grados comunes de experiencia de usuario para productos web 2.0) se pueden consultar ejemplos de grados de experiencia de usuario para diferentes objetivos de usuario de diferentes tipos de productos web.

    Paso 8: Considerar el enfoque de accesibilidad: diseño inclusivo o herramientas de personalización de usuario

    ¿El producto tendrá un enfoque de diseño inclusivo (BS 7000-6 Design management systems. Managing inclusive design. Guide), un enfoque de personalización de usuario o una combinación de ambos?

    El diseño inclusivo tiene como objetivo garantizar la accesibilidad siguiendo las pautas y técnicas reconocidas para asegurar la accesibilidad (como la WCAG) para una amplia gama de audiencias sin necesidad de una adaptación especial (que no sea un producto de apoyo).

    Un enfoque de personalización (que también se trata en el Anexo K) permite al usuario especificar sus preferencias de accesibilidad y luego adaptar los productos automáticamente a estas y/o proporcionarle una versión alternativa. Pueden ser herramientas para redimensionar el texto o leer la página; versiones alternativas en las plataformas de eLearning, si diferentes usuarios tienen mejor apoyo en su aprendizaje a través de diferentes estilos y modalidad de aprendizaje, etc.

    El enfoque personalizado complementa al diseño inclusivo, no lo sustituye, a menos que la organización pueda racionalizar las decisiones adoptadas.

    La conveniencia de opciones de personalización surge de la investigación previa, por ejemplo si se descubre que un número razonable de usuarios pueden no poder o no saber utilizar las opciones de su navegador o sistema operativo, o no pueden usar productos de apoyo, etc.

    Paso 9: Dispositivos soportados

    ¿El producto web estará optimizado para un dispositivo en particular, o formará parte de un conjunto de versiones específicas según el dispositivo?

    Trata las diferencias entre el acceso según el dispositivo (ordenador, móvil o tablet, consolas, IPTV), los diferentes grados de apoyo a la accesibilidad para los usuarios que acceden desde diferentes dispositivos o el concepto “accessibility supported” de las WCAG 2.0.

    Por ejemplo hay que tener en cuenta si el dispositivo soportado permite la instalación de productos de apoyo, si expone la información a los productos de apoyo o si sus navegadores incluyen opciones de configuración de accesibilidad habituales como cambiar el tamaño de fuente.

    Paso 10: Navegadores, sistemas operativos y productos de apoyo soportados

    ¿Qué navegadores, sistemas operativos y productos de apoyo (lectores de pantalla, magnificadores de pantalla, sistemas de reconocimiento de voz, etc.) y versiones de los mismos se soportarán?

    En la decisión influyen los que son soportados por los dispositivos indicados en el paso 9, si la organización tiene algún control sobre los que usara su público (por ejemplo en una intranet) o las restricciones o preferencias estudiadas en el paso 4.

    Si se ha optado por un enfoque personalizado, se debe definir el rango exacto de preferencias individuales que se apoyarán con herramientas de personalización o alternativas de accesibilidad.

    Contratación (paso 11)

    Paso 11: Decidir si se crea el producto en la empresa o se adquiere o contrata a terceros

    ¿El producto se creará en la empresa o se adquirirá o contratará a terceros? ¿Cómo nos aseguraremos de que las soluciones de terceros son accesibles?

    Cuando la organización contrata la creación del producto web a un proveedor externo debe cerciorarse de que el proveedor es capaz de entregar los requisitos de accesibilidad y los objetivos especificados en la política de accesibilidad del producto.

    En el Anexo L se incluyen todas las preguntas que se recomiendan hacer para adquirir o contratar productos a terceros y asegurar su accesibilidad.

    Producción del producto (paso 12-13)

    Paso 12: Definir las tecnologías web que se utilizarán en el producto web

    ¿Las tecnologías web usadas para construir el producto web soportan la accesibilidad? ¿Permiten crear productos accesibles? ¿Exponen la información a los productos de apoyo?

    Trata la elección de las tecnologías web utilizadas en la creación del producto web y las versiones alternativas que podrían necesitarse si se utilizan tecnologías no accesibles.

    También se dan pautas a seguir cuando el producto web va a ser creado por la selección y la integración de una combinación de herramientas de autor, software de terceros, componentes o servicios web, en cuyo caso la organización tendrá menos control sobre las tecnologías utilizadas.

    Paso 13: Uso de pautas web para dirigir la producción web accesible

    ¿Cuáles son los mejores estándares de accesibilidad disponibles para las plataformas y tecnologías elegidas? ¿Cómo se ajustará el producto web a ellas?

    Ya hemos visto que no solo se tratan las WCAG 2.0.

    Cuando hay niveles de conformidad (A, AA, AAA) se debe elegir cuál se va a proporcionar para cada grupo de usuarios y objetivo de usuario. Este nivel tiene un impacto en el precio y los plazos. La organización debe ser capaz de justificar su decisión, basada en el equilibrio entre el coste y los beneficios para los usuarios del producto.

    Las directrices de accesibilidad y sus especificaciones técnicas no solo afectan a los desarrolladores, tienen impacto en los diferentes miembros del equipo: diseñadores visuales, diseñadores de interacción o autores y editores de contenido.

    Evaluación del producto (paso 14)

    Paso 14: Asegurar la accesibilidad a lo largo del desarrollo

    ¿Cuál es el plan de pruebas de accesibilidad? ¿Cómo se evaluará la accesibilidad durante todo el proceso de desarrollo del producto web (diseño, prototipos, construcción del producto)?

    Si se contrata a terceros debe requerírseles el plan de pruebas y exigírseles que acrediten que lo han seguido a lo largo del todo proceso de desarrollo del producto.

    Si se externalizan las pruebas de accesibilidad, el Anexo L4 incluye preguntas útiles para la selección de los proveedores que realizarán dichas pruebas.

    También trata cómo afrontar situaciones en las cuales la organización tiene que sacar el producto cuando aún no cumple con el grado de experiencia al que aspiraba. Cómo tomar las decisiones y disminuir el riesgo y las limitaciones de accesibilidad.

    Lanzamiento del producto (paso 15)

    Paso 15: Comunicar las decisiones de accesibilidad del producto web en el lanzamiento

    ¿Qué dirá la declaración de accesibilidad? ¿Cómo estará disponible a través del producto web?

    Ya he comentado que se han de comunicar todas las decisiones a los usuarios a través de la declaración de accesibilidad, que debe ser fácil de encontrar, accesible y comprensible.

    Se recomienda que las organizaciones enlacen esta declaración en todas las páginas del producto web (normalmente con un enlace “Accesibilidad” en la cabecera o el pie).

    Mantenimiento post-lanzamiento (paso 16)

    Paso 16: Plan para asegurar la accesibilidad en todas las actualizaciones posteriores al lanzamiento

    ¿Con qué frecuencia se actualizará el producto? ¿Cuál es el proceso para revisar y evaluar continuamente el producto web?

    Trata temas tales como la manera de afrontar las limitaciones de accesibilidad ya identificadas, el desarrollo e implementación de un programa regular de pruebas de accesibilidad post-lanzamiento, o la revisión periódica de la accesibilidad del producto web a la luz de los nuevos avances de la tecnología o nuevas versiones.

    También trata los mecanismos de contacto de los usuarios y la respuesta adecuada a los comentarios, quejas o sugerencias de accesibilidad, tema que se aborda de forma ampliada en el Anexo M.

    Proceso iterativo

    Este es además un proceso iterativo (especialmente en los pasos 13-14) en el cual se va eliminando progresivamente la incertidumbre. La iteración implica que las especificaciones y los prototipos se van revisando y refinando a medida que se obtiene nueva información.

    Política de accesibilidad del producto web

    La política de accesibilidad del producto web responderá a las preguntas de cada paso, y en ella se recogerán y justificarán todas las decisiones que se han tomado en cada uno de dichos pasos. Hay un ejemplo de política de accesibilidad de un producto web en el Anexo E2.

    En el Anexo G se trata el reto de la accesibilidad en productos que pueden presentar especiales dificultades (redes sociales, juegos en línea, basados en vídeo, sitios que permiten a los usuarios crear sus propios contenidos, plataformas de eLearning, etc.) ofreciendo recomendaciones y buenas prácticas.

    Asegurar la accesibilidad a lo largo del ciclo de vida de un producto web (capítulo 8)

    Para garantizar la accesibilidad del producto, la organización debe asegurarse de que las necesidades de las personas con discapacidad y de las personas mayores se tienen en cuenta desde el inicio, se recogen en los requisitos del producto y se testean a lo largo de todo el ciclo de vida del proyecto, y no solo al final del mismo.

    La identificación de los problemas de accesibilidad lo antes posible mejora la viabilidad de abordar los problemas y reduce el coste de hacerlo.

    Como se ha ido viendo en el capítulo 6, las organizaciones deben integrar las consideraciones de accesibilidad a lo largo del ciclo de vida de un producto.

    Concepción inicial y análisis de requisitos

    Las necesidades de las personas con discapacidad y las personas mayores se reúnen al mismo tiempo que se define la especificación de requisitos del producto web.

    Los métodos de investigación etnográficos deben permitir recoger con precisión los requisitos particulares de las personas con discapacidad y las personas mayores. En el Anexo N se incluyen diferentes perfiles de usuarios con discapacidad que se han de tener en cuenta.

    Adquisiciones o producción

    Se define un plan de pruebas de accesibilidad durante las diferentes fases del desarrollo (diseño, prototipado y construcción), que por razones económicas y logísticas se recomienda armonizar con el plan de pruebas de usabilidad con audiencias más generales.

    El plan de pruebas especifica qué tipo de pruebas se requieren para la aceptación formal de que el producto mantiene el grado de experiencia de usuario al que aspira.

    El plan de pruebas debe indicar claramente:

    • qué métodos de pruebas de accesibilidad se utilizarán, y en qué puntos del proceso de producción;
    • cómo los métodos de pruebas apoyarán al equipo de producción para asegurar el progreso hacia el grado de experiencia de usuario deseado;
    • cómo se documentarán los resultados de las pruebas;
    • cómo los resultados de las pruebas se integrarán en el proceso de producción para mejorar el producto.

    Servicio post-lanzamiento.

    Tras el lanzamiento, y con cada actualización, el producto web se testeará para asegurar que sigue manteniendo el grado de experiencia de usuario al que aspira.

    Involucrar a los usuarios

    Cuando sea razonable y posible, se alienta a las organizaciones a involucrar a los usuarios con discapacidad y a las personas mayores en el proceso de desarrollo. Esto ayuda a los equipos de producción a entender los problemas de accesibilidad en el mundo real y a poner en prácticas soluciones de accesibilidad más eficaces.

    Métodos de evaluación de la accesibilidad web

    Todo el capítulo 8.4 está dedicado a los métodos de testing de accesibilidad.

    La norma indica que las organizaciones deben utilizar una combinación de métodos de prueba en función de la naturaleza del producto que se está probando y los recursos de la organización.

    Cómo mínimo

    Los siguientes métodos se deben utilizar como mínimo:

    • Pruebas de validación de código, herramientas que incluyen la validación de HTML y CSS.
    • Evaluación manual por parte de expertos respecto a las WCAG (también respecto a las ATAG si tiene componentes de autor) puesto que muchos criterios no pueden validarse automáticamente.
    • Pruebas con productos de apoyo y ajustes del navegador y el sistema operativo. Se especifican los pruebas mínimas que han de hacerse.

    Se debería incluir un mecanismo para conseguir feedback de los usuarios con discapacidad.

    Recomendable

    Los siguientes métodos son muy recomendables y deben utilizarse si la organización tiene recursos para probar más rigurosamente la usabilidad y accesibilidad técnica del producto.

    • Opinión de los expertos sobre los primeros diseños o prototipos (para identificar potenciales problemas de accesibilidad durante el diseño visual y el diseño de interacción) y el código final (para identificar posibles problemas de accesibilidad con la codificaciones de estos diseños). La revisión experta emplea una metodología más rigurosa y fiable para encontrar los problemas de accesibilidad y son útiles antes de las pruebas de usuarios.
    • Pruebas con usuarios que incluyan usuarios con discapacidad y personas mayores de la audiencia objetiva para intentar lograr tareas en función de los objetivos de usuario del producto. Detalla cómo y cuándo deben realizarse en el capítulo 8.4.6. En el Anexo N se definen usuarios representativos y en el Anexo O se incluye una guía para hacer pruebas de usuario con personas con discapacidad y personas mayores.
    Periódicamente y tras el lanzamiento

    Para auditar sitios grandes, y sobre todo para garantizar la accesibilidad después del lanzamiento, periódicamente se deben realizar evaluaciones automatizadas de la conformidad del sitio respecto a las WCAG.

    No debe ser el único método de evaluación y no es suficiente para afirmar que sea conforme a las WCAG.

    Por último se aborda la programación de pruebas de accesibilidad tras el lanzamiento. Las organizaciones deben desarrollar un programa regular de pruebas de accesibilidad después del lanzamiento para mantener el grado de experiencia de usuario especificado en la política de accesibilidad del producto.

    Conclusiones

    Al igual que no se puede abordar la usabilidad o la estrategia de posicionamiento en buscadores al final del desarrollo, o peor aún tras el lanzamiento, de un sitio o aplicación web, tampoco debemos abordar la accesibilidad web como una mera evaluación final antes de la puesta en producción. La identificación de los problemas de accesibilidad lo antes posible mejora la viabilidad de abordar los problemas y reduce el coste de hacerlo.

    La accesibilidad debe formar parte de la estrategia de la organización y tenerse en cuenta en todo el ciclo de vida del proyecto, pues cada decisión que se toma a lo largo del mismo afectará a si el producto incluye o excluye a las personas con discapacidad o las personas mayores. Pero no solo a ellas, sino a todos nosotros en muchos contextos de uso. Una web accesible mejora la experiencia de todos sus usuarios.

    La BS 8878:2010 establece un estándar para la calidad del proceso de creación de productos web accesibles. Describe de una manera sencilla, con ejemplos y recursos de interés, cómo integrar la accesibilidad web en todas las etapas de un proceso de Diseño Centrado en el Usuario, con el objetivo de conseguir que los productos web sean más accesibles y fáciles de usar, y que ello impacte lo menos posible en los plazos y los costes.

    Lo aborda también de una manera realista, porque prevé que las decisiones no suelen darse en casos ideales, sino en el mundo real, donde hay unos plazos y un presupuesto al que ajustarse, guiándonos sobre cómo tomar las mejores decisiones en cada caso, considerando todas las opciones e implicaciones.

    Bibliografía

    Estándares y legislación

    Referencias

    Artículos relacionados

    Viewing all 180 articles
    Browse latest View live