Índice

• ¿Qué es y para qué sirve?
• Descripción detallada
  • Hoja "1. Datos generales"
  • Hoja "2. Páginas de la muestra"
  • Hoja "3. Evaluación Nivel A"
  • Hoja "3.1 Gráficas y estadísticas A"
  • Hoja "4. Evaluación Nivel AA"
  • Hoja "4.1 Gráficas y estadísticas AA"
  • Hoja "5. Resultados por criterio"
  • Hoja "6. Resultados por nivel y principio"
  • Hoja "7. Resultados detallados por página"
• Licencia
• Mejoras futuras

¿Qué es y para qué sirve?

Es una excel que permite ir recogiendo los datos obtenidos durante la revisión automática y manual de un sitio o aplicación web de acuerdo a las WCAG 2.0

El informe de una evaluación de accesibilidad suele incluir:

• el resumen ejecutivo de la evaluación, destinado a las personas que han contratado la consultoría y que no tienen por qué tener conocimientos técnicos. En este resumen se indica de manera concisa y clara, sin entrar en aspectos técnicos, cuáles son los principales problemas en base a su criticidad y recurrencia, el nivel de adecuación alcanzado por la muestra y por cada una de sus páginas, etc.
• el análisis detallado donde incluyes, por cada criterio de conformidad y página de la muestra, qué se pretende evaluar y cómo se ha evaluado, qué errores se han encontrado, cómo solucionarlos técnicamente y cómo evitarlos en el resto del portal. Este apartado debe estar orientado a los desarrolladores que van a realizar los cambios.

Las tablas de resultados y las gráficas que genera la herramienta son especialmente útiles para el resumen ejecutivo y su presentación, pero además ayudan a:

• comparar en el tiempo los resultados de distintas evaluaciones de un mismo sitio;
• comparar los resultados de la evaluación de un sitio con la evaluación de otros sitios, por ejemplo de la competencia;
• identificar con rapidez cuáles son los criterios de conformidad y las páginas que presentan más problemas.

Descripción detallada

La herramienta es una excel de 9 hojas que creé para mi uso personal pero que comparto en el blog desde comienzos del 2012 (por eso la URL del artículo es de 2012).

Solo están desprotegidas las celdas en las cuales hay que introducir datos, de esta manera se evita modificar o eliminar por error celdas que se actualizan automáticamente.

La descripción detallada que incluyo a continuación está actualizada a la versión 3.

Hoja "1. Datos generales"

Hoja "1. Datos generales"

En la primera hoja de la excel se nos solicita información general sobre el sitio a evaluar:

• Cliente: cliente para el cual se está haciendo la evaluación.
• Nombre del sitio: identificación del sitio o aplicación web que estamos evaluando.
• Alcance de la evaluación: tiene que ser una definición no ambigua que permita determinar sin lugar a dudas si una página o contenido está o no dentro del alcance de la evaluación. Por ejemplo, todas las páginas y contenidos de la parte pública de la web Usable y accesible, en el dominio http://www.usableyaccesible.com.
• Periodo de revisión: periodo durante el cual se ha realizado la evaluación.
• Evaluador: persona que realiza la evaluación.
• Nivel evaluado: A o AA. En esta versión no se incluye la evaluación del nivel AAA.
• Soporte de accesibilidad: dispositivos, sistemas operativos, navegadores y productos de apoyo que deben ser soportados por el sitio o aplicación web que se está evaluando.
• Tecnologías compatibles con la accesibilidad: tecnologías compatibles con la accesibilidad de las que depende el sitio, por ejemplo HTML5, CSS, DOM. Comprender el concepto "compatible con la accesibilidad (accessibility-supported) de las WCAG 2.0"

Hoja "2. Páginas de la muestra"

Hoja "2. Páginas de la muestra"

En la segunda hoja de la excel se nos solicita información sobre las páginas del sitio que componen la muestra a evaluar:

• Número de páginas de la muestra: esta versión está pensada para un número máximo de 15 páginas.
• Alias: es el nombre que le damos a cada página de la muestra. El alias que le demos a la página será el que automáticamente se le asigne en todas las hojas para identificarla con más claridad. Se puede modificar en cualquier momento y las hojas se actualizarán en consecuencia para reflejar el cambio.
• URL: indicamos la URL de cada página de la muestra.
• ¿Página de control?: la metodología WCAG-EM del W3C indica que se deben incluir en la muestra páginas al azar como muestra de control. Por ejemplo, en nuestra muestra de 15 páginas, 2 serían páginas seleccionadas al azar.

Hoja "3. Evaluación Nivel A"

Hoja "3. Evaluación Nivel A"

En esta hoja se listan todos los criterios de conformidad de nivel A. Por cada uno de los criterios tenemos el listado de las páginas de la muestra.

Tenemos que seleccionar por cada página, mediante un desplegable (columna "¿Cumple?"), uno de los siguientes valores:

Desplegable asociado a cada página

• Sí: para indicar que la página cumple con ese criterio de conformidad.
• No: para indicar que la página no cumple con ese criterio de conformidad.
• No se aplica: cuando el criterio de conformidad no se aplica a la página. Por ejemplo, si la página no incluye vídeos, no se aplicarán los criterios relacionados con el contenido multimedia. La metodología WCAG-EM indica que se puede optar por marcarlos como "Sí" o como "No se aplica". Lo importante es que decidamos una u otra manera y seamos coherentes y consistente a la hora de aplicarla.

En los resultados tendremos columnas separadas para reflejar los resultados teniendo en cuenta los "no se aplica" y sin tenerlos en cuenta. En las gráficas generales de cumplimiento e incumplimiento, como se indica, no se contabilizan los "no se aplican". Es decir, si por ejemplo en el nivel A, 10 criterios se cumplen, 10 no y 5 no se aplican, el porcentaje de cumplimiento es del 50% para el nivel A, sin contabilizar los "no se aplican".

Tenemos que indicar además si la muestra en su conjunto cumple con ese criterio de conformidad:

Desplegable "Muestra completa" de cada criterio de conformidad.

Los valores disponibles son los mismos que en el caso anterior. El evaluador debe rellenar este campo teniendo en cuenta:

• si alguna de las páginas de la muestra no cumple el criterio de conformidad, la muestra en su conjunto no cumple ese criterio;
• si el criterio de conformidad "no se aplica" en todas las páginas de la muestra, el criterio "no se aplica" en la muestra completa;
• si ninguna de las páginas incumple el criterio de conformidad (es decir, solo hay páginas que lo cumplen o en las que "no se aplica"), la muestra en su conjunto cumple el criterio de conformidad.

Automáticamente, por cada criterio de conformidad, se va actualizando el resumen del número de páginas de la muestra que lo cumplen, no lo cumplen o no se aplica.

Además, por cada criterio de conformidad se incluye su descripción, su enlace a las WCAG 2.0 y su ayuda, basada en la traducción de "WebAIM`s WCAG 2.0 Checklist" de Jose Ramón Quevedo.

Hoja "3.1 Gráficas y estadísticas A"

Esta hoja es solo de resultados. Se actualiza automáticamente en base a los datos incluidos en la hoja anterior.

Hoja "3.1 Gráficas y estadísticas A. Nivel de adecuación A de la muestra en su conjunto"

Muestra en primer lugar una gráfica de tarta con el porcentaje de cumplimiento de la muestra en su conjunto. Para elaborarla se utilizan los datos introducidos en los campos "Muestra completa" que ya hemos comentado en la hoja anterior. Por tanto es imprescindible, para obtener datos completos, que todos los campos "Muestra completa" se hayan rellenado.

Bajo la gráfica se muestra la tabla con los porcentajes, con una columna para los porcentajes teniendo en cuenta los "no se aplica", y una columna para los porcentajes sin tener en cuenta los "no se aplica".

La gráfica muestra los porcentajes sin los "no se aplica".

A continuación se muestran los datos en formato tabla y en formato gráfica desglosados por página.

Hoja "3.1 Gráficas y estadísticas A. Datos desglosados por cada página de la muestra"

Hoja "4. Evaluación Nivel AA"

Hoja "4. Evaluación Nivel AA"

El funcionamiento de esta hoja es el mismo que el de la hoja 3 "Evaluación de nivel A", solo que los criterios de conformidad listados son los de nivel AA.

Hoja "4.1 Gráficas y estadísticas AA"

Esta hoja es igual que la hoja 3.1 "Gráficas y estadísticas A", pero refleja los resultados de nivel AA en base a los datos introducidos en la hoja 4 "Evaluación Nivel AA".

Hoja "4.1 Gráficas y estadísticas AA. Nivel de adecuación AA de la muestra en su conjunto"

Hoja "4.1 Gráficas y estadísticas AA. Datos desglosados por cada página de la muestra"

Hoja "4.1 Gráficas y estadísticas AA. Gráfica de cumplimiento de cada página"

Hoja "5. Resultados por criterio"

En esta hoja se muestran los resultados desglosado por criterio y nivel.

Hoja "5. Resultados por criterio"

Se listan todos los criterios de conformidad (primero los de nivel A y luego los de nivel AA), y automáticamente va reflejando todos los datos introducidos en las hojas 3 y 4, indicando así en cada criterio el número de páginas que lo cumplen, no lo cumplen o no se aplica.

En base a dichos resultados se generan para el nivel A y para el nivel AA, gráficas de barras desglosando los resultados por criterio de conformidad.

Esta pestaña nos da una perspectiva global de los criterios de conformidad que más o menos problemas están generando.

Hoja "6. Resultados por nivel y principio"

Gracias a la colaboración del profesor Roberto Muñoz y sus alumnos de la Facultad de Ingeniería de la Universidad de Valparaíso, Chile, desde la versión 2 se incluyen las hojas 6 y 7.

La pestaña 6 "Resultados de la evaluación por nivel y principio, mediando resultados por página" incluye una tabla resumen que desglosa por cada página: su % de cumplimiento A y AA, y su % de cumplimiento de cada uno de los cuatro principios en los que se agrupan los criterios de las WCAG 2.0: perceptible, operable, comprensible y robusto.

Incluye además dos gráficas de barras para mostrar la media del % de cumplimiento de las páginas por nivel y por principio.

Hoja "6. Resultados por nivel y principio"

Como ya he indicado en la hoja 3, el porcentaje de cumplimiento A y AA no tiene por qué coincidir con los de la hojas 3.1 y 4.1. Allí el porcentaje se calcula para la muestra en su conjunto, y aquí mediando el cumplimiento de las páginas.

Hoja "7. Resultados detallados por página"

Hoja "7. Resultados detallados por página"

Esta pestaña muestra los mismos resultados que la pestaña 6 (de hecho se basa en ellos para generarse) pero mucho más detallados.

Licencia

La descarga de la excel es directa y gratuita, pero está prohibida su distribución y su uso comercial sin permiso del autor.

Mejoras futuras

En futuras versiones:

• Evaluación del nivel AAA.
• Comparación automática entre las páginas de la muestra de control y las páginas seleccionadas estructuradamente.
• Actualización automática del dato "Muestra completa" de cada criterio de conformidad que actualmente es manual.
• Alerta si no se ha cumplimentado algún campo de la hoja 3 y 4.
• Mejorar la accesibilidad de la excel.
• Poder añadir automáticamente más de 15 páginas a la muestra.

Cualquier otra sugerencia me la podéis dejar en los comentarios.

Servicio relacionado:Consultoría de accesibilidad web

Artículos relacionados:

• WCAG 2.0
• Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)
• Descarga la herramienta para realizar evaluaciones heurísticas basadas en Sirius
• Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online
• Herramienta de ayuda para realizar una consultoría de acuerdo a las WCAG 1.0 y la Norma UNE 139803:2004

Índice

• WCAG-EM (Website Accessibility Conformance Evaluation Methodology)
• Visión general de la WCAG-EM Report Tool
• Inclusión de datos para la generación del informe
• Informe generado
• Mejoras que me gustaría proponer
• Herramienta de ayuda para la realización del informe de una consultoría de accesibilidad de acuerdo a las WCAG 2.0 (versión 3.0 - 2015)
• Enlaces de interés

WCAG-EM (Website Accessibility Conformance Evaluation Methodology)

En el artículo Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM) os explicaba en detalle la metodología del W3C/WAI para la evaluación de un sitio web de acuerdo a las WCAG 2.0

En ella se describe un método fiable para determinar de forma global el nivel de accesibilidad de un sitio web completo. En el documento se especifican las buenas prácticas y los pasos concretos para definir el alcance de la evaluación, explorar el sitio, seleccionar una muestra representativa cuando no es factible evaluar todo el sitio, auditar la muestra seleccionada y reportar los resultados de la evaluación mediante informes estructurados y uniformes.

Los pasos del procedimiento de evaluación, como detallaba en ese artículo, son 5:

Algunos de los pasos pueden solaparse o llevarse a cabo en paralelo, pero es importante que se tengan en cuenta todos ellos para garantizar una evaluación fiable así como documentar claramente cada paso.

Para comprender mejor la herramienta WCAG-EM Report Tool y utilizarla correctamente, os recomiendo que os familiaricéis primero con la metodología WCAG-EM.

Visión general de la WCAG-EM Report Tool

La WCAG-EM Report Tool es una herramienta online y gratuita.

Esta herramienta no realiza ninguna evaluación automática de accesibilidad, sino que nos guía en la aplicación de la metodología WCAG-EM, nos permite introducir todos los datos y nos genera el informe en base a los datos introducidos.

Pantalla de inicio de WCAG-EM Report Tool

En la parte superior tenemos cuatro opciones de menú:

• New Report: crea un nuevo informe.
• Open: abre un informe guardado previamente con la opción "Save", recuperando así todos los datos introducidos en los campos de los diferentes pasos.
• Save: aunque los datos que se van introduciendo en cada paso se guardan, si cierras la ventana del navegador los habrás perdido. Esta opción permite guardarlos localmente en tu equipo (mediante un fichero JSON) que puedes recuperar posteriormente con la opción "Open".
• Key Resources: incluye enlaces a los documentos WCAG 2.0, WCAG-EM y How to Meet WCAG 2.0 Quick Reference.

A continuación tenemos un menú con 7 elementos en forma de pasos. Recorreremos cada uno de ellos para introducir los datos que se nos solicitan y de esta manera obtener el informe en el último paso.

Aunque la navegación está ideada para que sea secuencial, no es restrictiva, en cualquier momento puedes avanzar o retroceder a cualquiera de los pasos, bien a través del menú, bien a través de los botones inferiores "Next step" o "Previous step".

Las siete opciones del menú secuencial son:

• Start: ofrece información general sobre la herramienta y cómo utilizarla.
• 1. Define Scope: se corresponde con el primer paso de la metodología WCAG-EM Step 1: Define the Evaluation Scope. En la metodología este paso se divide en cuatro subpasos y su objetivo es definir el alcance de la evaluación, el nivel de adecuación deseado (A, AA, AAA), el soporte de la accesibilidad (navegadores y productos de apoyo que debe soportar) y los requisitos de evaluación adicionales.
• 2. Explore Website: se corresponde con el segundo paso de la metodología WCAG-EM Step 2: Explore the Target Website. En la metodología se divide en cinco subpasos y el objetivo es que el evaluador explore el sitio para comprender mejor su uso, propósito y funcionalidad. Como resultado, debe identificar las páginas y funcionalidades relevantes, los diferentes tipos de páginas o tecnologías de las que se depende. Esta información servirá después para seleccionar la muestra de páginas a analizar.
• 3. Select Sample: se corresponde con el tercer paso de la metodología WCAG-EM Step 3: Select a Representative Sample. En él se selecciona una muestra de páginas a analizar, en base a los datos recabados en el paso anterior, que nos asegure que los resultados de la evaluación reflejarán la accesibilidad de todo el sitio con suficiente fiabilidad. Se seleccionan también páginas al azar como muestra de control.
• 4. Audit Sample: se corresponde con el cuarto paso de la metodología WCAG-EM Step 4: Audit the Selected Sample. En este paso es donde se realiza la evaluación de la muestra de acuerdo a las WCAG 2.0 y el nivel de adecuación definido (A, AA, AAA). Por cada uno de los criterios de conformidad podremos indicar si la muestra en su conjunto (o cada una de las páginas individualmente) los cumple o no e incluir comentarios.
• 5. Report Findings: se corresponde con el quinto paso de la metodología WCAG-EM Step 5: Report the Evaluation Findings. En la metodología se divide en cinco subpasos. El primero define la información que se debe incluir obligatoriamente en el informe. En los otros cuatro subpasos se indica otra información que se puede ofrecer opcionalmente. La herramienta permite introducir en este paso datos generales (el nombre del evaluador, la fecha de la evaluación, etc.), redactar un resumen ejecutivo o incluir otra información adicional (herramientas de evaluación y navegadores y productos de apoyo utilizados, etc.)
• View Report: aquí podremos ver el informe generado y descargar el HTML y/o la CSS del informe, o grabarlo como fichero JSON.

Inclusión de datos para la generación del informe

Para la generación completa del informe en el último paso ("View Report") debemos rellenar los campos de cada una de las páginas precedentes, que como hemos visto se corresponden con cada uno de los pasos definidos en la metodología WCAG-EM.

Cada página (cada paso) es un formulario que nos solicita datos basados en los subpasos descritos en la metodología.

Pantalla del paso "2. Explore Website" de WCAG-EM Report Tool

Para rellenarlos correctamente hay que estar familiarizado con la metodología, que nos dirá no solo qué información recabar sino también cómo. A modo de ayuda, cada campo tiene un icono que despliega información adicional, pero que en última instancia remite a cada paso y subpaso concreto de la WCAG-EM.

Como he avanzado antes, en el paso 4 podemos ir introduciendo los resultados de nuestra evaluación de la muestra de acuerdo a las WCAG 2.0.

Pantalla del paso "4. Audit Sample" de WCAG-EM Report Tool

En esta página se muestran los criterios de conformidad de las WCAG 2.0 del nivel de conformidad (A, AA, AAA) que has indicado que quieres evaluar.

Por cada uno puedes indicar si la muestra completa cumple o no cumple este criterio (también puedes indicar: no chequeada, no presente, no sé), o bien indicarlo individualmente por cada una de las páginas de la muestra (para ello debes seleccionar en el menú izquierdo qué páginas de la muestra quieres evaluar individualmente).

También puedes añadir observaciones, por ejemplo podrías querer añadir la descripción de los errores, posibles soluciones, técnicas que se aplican, aunque para ello solo tenemos un textarea (por criterio y página) y no podemos adjuntar imágenes.

Un criterio de conformidad lo has podido evaluar manualmente o con alguna herramienta, pero la WCAG-EM Report Tool no hace ninguna evaluación automática de los mismos, solo sirve para recoger los resultados.

También indica que el contenido de las páginas o estados de páginas que tienen versiones alternativas se evalúan juntas (la página y la versión alternativa) como una unidad.

Informe generado

El informe generado, como he indicado, se encuentra en el último paso "View Report". Está en inglés pero podemos descargarlo para personalizarlo y traducirlo.

En primer lugar incluye los datos generales y el resumen ejecutivo.

Pantalla del paso "View Report" de WCAG-EM Report Tool. Datos generales y resumen ejecutivo

A continuación incluye una tabla resumen del número de criterios cumplidos, no cumplidos o no presentes, por cada uno de los cuatro principios de accesibilidad (sería muy útil que se desglosará también por nivel A, AA, AAA). Después se inserta el detalle de la evaluación, es decir, los datos introducidos en el paso 4.

Pantalla del paso "View Report" de WCAG-EM Report Tool. Resumen de los resultados y resultados detallados.

Al final del informe se incluye la relación de páginas auditadas y enlaces a las WCAG y la metodología WCAG-EM.

Mejoras que me gustaría proponer

Ayuda asociada a cada criterio de conformidad (paso 4)

Se entiende que la herramienta será utilizada por personas expertas en las WCAG 2.0, por eso no se incluye información adicional sobre cada criterio, solo su nombre. Sin embargo sería interesante que cada criterio tuviera, al igual que los campos en los pasos anteriores, un icono de ayuda que mostrara la descripción completa del criterio, el enlace al mismo y las recomendaciones (por ejemplo como en Interactive WCAG 2.0)

Mejorar la inclusión de observaciones asociadas a cada criterio

Para un análisis preliminar o para presentar un resumen ejecutivo, puede servir un informe sencillo como el que genera la herramienta, pero cuando el informe es para el equipo de desarrollo tienes que detallar qué significa cada criterio, cómo lo evalúas, poner ejemplos concretos de los errores con pantallazos y describir las soluciones. Como hemos visto, solo contamos con un textarea, que en este caso se quedaría escaso.

Según el tipo de informe que se quiera generar podría mejorarse la inclusión de observaciones, por ejemplo seleccionando que quieres incluir un problema, una solución, poder añadir un pantallazo, etc.

Más información en la tabla resumen del informe

La tabla resumen es de la muestra en su conjunto, no se puede desglosar por niveles, páginas o criterios de conformidad.

Sería muy útil que generara tablas resumen, estadísticas y gráficas de cumplimiento e incumplimiento más detalladas para incluir en el informe y en su presentación.

Ayuda en la comparación con la muestra de control

En el paso 4c de la metodología (y en el texto introductorio del paso 4 de la herramienta) se indica que se deben comparar los resultados de la evaluación de las páginas de la muestra que seleccionaste, con los resultados de la evaluación de las páginas que escogiste al azar como muestra de control.

Sería muy interesante que la herramienta diferenciara las páginas de la muestra de control y que en base a los datos introducidos pudiera emitir advertencias (por ejemplo si para un criterio de conformidad la única página que presenta errores es una de las páginas de control)

Herramienta de ayuda para la realización del informe de una consultoría de accesibilidad de acuerdo a las WCAG 2.0 (versión 3.0 - 2015)

En 2012 compartí la primera versión de una herramienta interna que utilizo para recoger los datos de una evaluación de accesibilidad, actualmente podéis descargaros la versión 3 que publique el 14/07/2015.

Ver Herramienta de ayuda para la realización del informe de una consultoría de accesibilidad de acuerdo a las WCAG 2.0 (versión 3.0).

La excel no genera el informe, pues para eso tengo diferentes plantillas según el tipo de informe, pero sí diferentes tablas resuen, estadísticas y gráficas de cumplimiento e incumplimiento (por nivel, principio, criterio de conformidad, página de la muestra o muestra completa) que son muy útiles para:

• elaborar el informe ejecutivo y su presentación;
• comparar en el tiempo los resultados de distintas evaluaciones de un mismo sitio;
• comparar los resultados de la evaluación de un sitio con la evaluación de otros sitios, por ejemplo de la competencia;
• identificar con rapidez cuáles son los criterios de conformidad y las páginas que presentan más problemas.

Por tanto esta herramienta (una excel cuya descarga es directa y gratuita) es un complemento muy útil para mejorar el informe del WCAG-EM Report Tool.

Hoja "6. Resultados por nivel y principio" de la excel

Enlaces de interés

• WCAG-EM Report Tool. Website Accessibility Evaluation Report Generator
• Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0
• Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM), Olga Carreras
• Herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0 (version 3.0- 2015), Olga Carreras
• Interactive WCAG 2.0

Artículos relacionados

• BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web
• Responsabilidad de accesibilidad de cada uno de los roles profesionales implicados en el ciclo de vida de un proyecto web, 2013
• Metodología para la evaluación de la accesibilidad Web: "Evaluating Web Sites for Accessibility" de la WAI, 2009
• Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA, 2011
• Introducción a las WCAG 2.0, última actualización 2013
• Metodologías, certificaciones y entidades certificadoras de la accesibilidad web en España, última actualización 2015

Título original:Don´t Make Me Think

Autor: Steve Krug

Nº páginas: 216

Idioma: inglés. Está traducido al español.

Formato:ebook y libro impreso

Fecha de publicación:2005 (2nd Edición, inglés)

Web del libro "Don´t Make Me Think"

Título original:Rocket Surgery Made Easy

Autor: Steve Krug

Nº páginas: 224

Idioma: inglés. Está traducido al español.

Formato:ebook y libro impreso

Fecha de publicación:2010

Web del libro " Rocket Surgery Made Easy"

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

Sobre los libros

He decidido reseñar los dos libros de Steve Krug juntos porque en realidad "Haz fácil lo imposible" podría considerarse un apéndice de "No me Hagas Pensar", o más concretamente una ampliación del capítulo en el que explica cómo realizar una prueba de usabilidad.

"No me Hagas Pensar. Una aproximación a la usabilidad en la Web" es otro de los libros clásicos de usabilidad, con miles de copias vendidas. La primera edición se publicó en el año 2000. La segunda edición, con varios capítulos más, se publicó en el año 2005 (en español en el 2006)

Dado el gran éxito del libro, firmó un contrato para escribir un segundo libro "Haz fácil lo imposible. La guía para detectar y determinar los problemas de usabilidad" que publicó en 2010.

Ambos están escritos con un estilo divertido, directo e informal.

En "No me Hagas Pensar" repasa las claves básicas de la usabilidad web con bastantes ejemplos. En general todo lo que dice sigue estando vigente porque son conceptos básicos que es imprescindible conocer, aunque a veces se nota el paso del tiempo y cómo ha evolucionado la Web desde que publicó el libro. Si podéis, es preferible leerlo en inglés porque a veces la traducción chirría un poco.

"Haz fácil lo imposible" no pretende convertir al lector en un experto en pruebas de usabilidad, para ello recomienda otros libros en el capítulo 15 "Lecturas recomendadas". Su objetivo es explicar cómo pueden llevar a cabo pruebas sencillas, informales y con muestras pequeñas (pruebas "hágalas usted mismo") aquellos que no pueden contratar a un profesional.

Capítulo 1. ¡No me hagas pensar! Primera norma de la usabilidad de Krug

Una página web ha de ser obvia, evidente, clara y fácil de entender.

La primera clave de usabilidad es que la página no presente interrogantes al usuario como "¿por dónde empiezo?", "¿por qué lo llaman así?" o "¿puedo hacer clic en esto?".

Los interrogantes aumentan el trabajo cognitivo y distraen nuestra atención de la tarea que estamos realizando. Las distracciones aunque leves se acumulan y pueden llevarnos a abandonar el sitio.

Capítulo 2. ¿Cómo usamos realmente la web? Ojear, ser suficiente y arreglárselas

Nota: he usado el término hojear/ojear tal y como aparece en cada título/subtítulo del libro traducido al español.

Factor de vida 1: no leemos las páginas, las hojeamos.

Tenemos prisa y queremos encontrar lo relevante. Centramos nuestro interés en las palabras y frases que encajan con la tarea que queremos realizar, que coinciden con nuestros intereses, o que nos causan una reacción repentina como "gratis", "oferta".

Factor de vida 2: no tomamos decisiones óptimas, nos es suficiente.

La mayor parte de las veces no seleccionamos la mejor opción sino la primera que nos parece más razonable (estrategia llamada satisficing)

Y esto es así porque tenemos prisa y porque las consecuencias del error no son importantes: siempre puedes volver atrás. Además, sopesar distintas opciones tampoco garantiza a menudo mejorar nuestras oportunidades.

Factor de la vida 3: no averiguamos el funcionamiento de las cosas, nos las arreglamos.

A la mayoría le da igual entender el funcionamiento de las cosas en tanto pueda usarlas. Si nos funciona de una manera, sea acertada o no, dejamos de buscar una solución mejor.

Ir arreglándonoslas funciona a veces, pero termina siendo ineficaz y proclive al error, por ello es importante que el usuario entienda el sitio.

Capítulo 3. Diseño de rótulos 101. Diseño de páginas para hojear, no para leer

Las claves para diseñar páginas fáciles de hojear son:

Creación de una jerarquía visual clara en cada página

Una buena jerarquía visual nos ahorra tales esfuerzos a la hora de preprocesar la página, organizar y establecer prioridades en los contenidos, lo que nos permite captar todo de forma casi instantánea.

Tres características de una jerarquía visual clara son:

• lo más importante es lo más prominente,
• lo que está relacionado lógicamente también lo está visualmente,
• todo se engloba visualmente bien para que queden delimitadas las partes que pertenecen a cada bloque.

Aprovechamiento y uso de las convenciones

Todas las convenciones nacen de la idea brillante de alguien. Si funcionan lo suficientemente bien, otros sitios la imitan y termina viéndose en tantas partes que no necesita ningún tipo de explicación.

Las convenciones son útiles. No hay que intentar reinventar la rueda: innova solo cuando sepas que la idea es mejor pero aprovecha las convenciones cuando no haya ideas mejores.

División de las páginas en zonas claramente definidas

Esto ayuda al usuario a decidir rápidamente en qué partes quiere centrarse y cuáles puede con tranquilidad ignorar.

Dejar claro sobre lo que se puede hacer clic

Los enlaces y botones tienen que distinguirse con claridad.

Minimizar el ruido visual

El ruido puede ser resultado de que todo esté abigarrado y/o reclamando tu atención. Pero también puede ser un ruido de fondo donde infinidad de diminutos fragmentos de ruido visual nos terminan agotando.

Capítulo 4. ¿Animal, vegetal o mineral? ¿Por qué le gustan al usuario las opciones mecánicas?

El número de clics para acceder a cualquier página del sitio no es tan importante como la dificultad en la elección de ese clic, esto es, el esfuerzo de pensamiento y la incertidumbre sobre si la elección tomada es correcta.

No importa el número de clics mientras la elección sea sencilla y obedezca a una confianza continuada de que se sigue la pista correcta.

Tres clics mecánicos e inequívocos equivalen a un clic que requiere cierto grado de reflexión.

Las opciones de navegación tienen que resultar tan excluyentes como la elección entre "animal", "vegetal" y "mineral", de ahí el título del capítulo.

Capítulo 5. Omisión de palabras innecesarias. El arte de no escribir en la web

Su premisa es:

Elimina la mitad de las palabras en todas las páginas y luego deshágase de la mitad de lo que quede.

Hay que eliminar el discurso innecesario. Por ejemplo aquel que carece de información práctica o aquel que está enfocado a elogiar lo buenos que somos en vez de definir qué nos hace tan buenos.

También hay que eliminar las instrucciones. El sitio debe ser autoexplicativo, pero si las instrucciones son absolutamente necesarias hay que reducirlas a lo esencial.

Eliminando lo innecesario se reduce el ruido de la página, se realza el contenido verdaderamente práctico y se acortan las páginas, permitiendo al usuario ver más de un solo vistazo.

Capítulo 6: Señales en la calle y migas. Diseño de la navegación

Comienza con un hombre intentando comprar una motosierra, para pasar a explicar las semejanzas y diferencias entre comprar en una tienda física y en la web.

La navegación web nos ayudará a encontrar lo que buscamos pero también nos indicará dónde nos hallamos. Evita que nos perdamos, nos dice lo que hay en cada lugar, nos enseña a usar el sitio (porque implícitamente nos muestra por dónde empezar y las opciones que hay) y nos permite confiar en las personas que la han creado.

Una navegación clara y bien desarrollada es una de las mejores oportunidades con las que cuenta un sitio para dar una buena impresión.

La navegación debe seguir las convenciones para localizarla con facilidad y distinguirla del resto del contenido. También ha de ser coherente y consistente a lo largo de las páginas, esto nos permite tenerla siempre a mano y aprenderla una única vez. Como excepción, en la home y en ciertos formularios (por ejemplo en la formalización de tu pedido) podemos tener una versión mínima de esta navegación coherente, pues en este caso la navegación puede ser una distracción innecesaria.

Otras claves que explica en este capítulo son:

• Se debe identificar en todo momento en qué sitio nos encontramos, para ello debemos utilizar también la convención de incluir el logotipo en la esquina superior izquierda.
• Las utilidades deben estar diferenciadas de las opciones principales de navegación y ser menos prominentes.
• Se tiene que volver con facilidad a la página de inicio, tanto desde el logotipo como incluyendo la opción en las utilidades.
• Se debe incluir una opción de búsqueda a no ser que el sitio sea muy pequeño. Repasa las buenas prácticas y las convenciones a seguir en el buscador, como por ejemplo no limitar el ámbito de la búsqueda.
• Se debe resaltar la opción de menú en la que te encuentras.
• Es importante incluir migas de pan y seguir unas buenas prácticas, como poner en negrita el último elemento o que este no sustituya al título de la página.
• Los enlaces visitados deben cambiar de color.
• Recalca la importancia del título de las páginas: su ubicación, su estilo o su texto.

• El nombre de los enlaces, menús y títulos de las páginas han de ser coherente entre si.

  Si hay una mayor gran diferencia entre el nombre del vínculo y el nombre de la página o muchas discrepancias menores, mi confianza en el sitio (y en la competencia de las personas que lo han publicado) se verá disminuida.

Por último defiende su predilección por las pestañas de navegación. Indica que son claras y fáciles de entender, que es difícil perderlas de vista o confundirlas con algo que no sea la navegación, y que refuerzan que el contenido está dividido en secciones y que nos encontramos en una de ellas.

Las claves de las pestañas es que haya una seleccionada por defecto y que estén perfectamente dibujadas para que parezcan solapas de verdad: la pestaña activa debe pasar al frente.

Indica que es mejor que estén codificadas por color (un color diferente para cada sección) siempre y cuando no se confíe en que todos los usuarios perciban esta distinción, el color es genial como clave adicional, pero nunca debería basarse en él como clave única.

Capítulo 7. El primer paso para la recuperación es admitir que ha perdido el control de la página principal. Diseño de la página principal.

Comienza enumerando todo lo que debería contener una página de inicio. Después habla de cómo la home va degenerando porque todos desean estar ella, todos tienen una opinión sobre ella y, además, se espera que atraiga a cualquier de sus visitantes independientemente de sus intereses.

Lo único que no puede perderse en la home es el objetivo del sitio.

Tiene que responder rápida, correcta y sin ambigüedad a las siguientes cuestiones:

• qué es esto
• qué tienen aquí
• qué puedo hacer aquí
• por qué debería estar yo aquí y no en otro lugar
• por dónde empiezo (si quiero buscar, si quiero navegar…)

Hace una defensa tajante de incluir un tagline en la página como forma eficaz de dar una descripción concisa del objetivo del sitio y de comunicar una proposición de valor. La mayoría de los usuarios esperarán encontrarlo junto al logotipo.

Deberá ser conciso, claro, informativo y expresar la diferenciación y el beneficio del sitio. Aunque no es tan importante en los sitios por todos conocidos o los que son bien conocidos por su origen offline, les beneficia de todas maneras, puesto que la misión online nunca es exactamente la misma y es importante explicar la diferencia.

Admite que la navegación en la home puede ser algo diferente, pero con lo suficiente en común para reconocer que son dos versiones de lo mismo. Para ello es importante que el nombre de las secciones y las claves visuales sean las mismas.

Repasa las ventajas y desventajas de los menús desplegables, que si bien ahorran espacio, hay que desplegarlos para ver su contenido y pueden ser incómodos de consultar.

Recalca que es importante comprender que no se puede promocionar todo en la home, que habrá que recurrir a usar promociones cruzadas o usar el mismo espacio en la home por turnos.

Capítulo 8: El granjero y el ganadero deben ser amigos. Por qué la mayoría de los argumentos de diseño web acerca de la usabilidad son una pérdida de tiempo y cómo evitarlos

La tendencia natural es a proyectar nuestros gustos o disgustos en los usuarios de la Web: creemos que a la mayoría de los usuarios les gustan las mismas cosas que a nosotros.

Para resolver el conflicto a menudo se intenta encontrar qué le gusta a la mayoría de los usuarios. El problema es que no hay un Usuario Medio. Sería estupendo saber si los desplegables son buenos o malos en función de si gustan o no a la mayoría, pero no hay una respuesta simple o correcta a esta pregunta.

La cuestión es que no es nada productivo preguntar cosas como "¿Gustan a la mayoría los menús desplegables?". Lo más acertado es preguntar “¿Supone este desplegable con estos elementos y estos términos dentro de este contexto particular una buena experiencia para la mayoría de las personas que probablemente utilicen este sitio?"

Y solo hay una forma de contestar a este tipo de pregunta: probando.

Capítulo 9: Prueba de usabilidad por 10 centavos al día. Sencillez de las pruebas

Las personas con frecuencia prueban para decidir qué color de cortinas es mejor, sólo para darse cuenta de que olvidaron poner ventanas en la habitación. Por ejemplo, podemos descubrir que no hay mucha diferencia si la barra de navegación es horizontal o existen menús verticales, si nadie entiende el valor del sitio.

Tristemente, así es como se hacen la mayoría de las pruebas de usabilidad: demasiado pequeñas, demasiado tarde y por razones equivocadas.

Dedica bastante tiempo a explicar la diferencia entre un focus group y un test con usuarios. No son lo mismo ni tienen el mismo objetivo.

Defiende la necesidad de realizar test con usuarios: es mejor probar con un usuario que con ninguno; y es mejor probar con un usuario al principio que con 50 al final.

Es bueno probar con personas que vayan a utilizar el sitio, pero más importante es probarlo pronto y con frecuencia. Si reclutar a los usuarios ideales para la prueba va a significar hacer menos pruebas, hazlas con cualquiera (a no ser que necesites un perfil muy concreto o la web sea de un campo muy específico)

Se pueden realizar las pruebas sin invertir mucho tiempo o dinero, y sin necesidad de muchos usuarios o de un laboratorio. Probar puede ser rápido, sencillo y barato.

A veces basta con pruebas tan sencillas como imprimir el formulario que has prototipado, enseñárselo a alguien y ver si tiene sentido para él.

Por ejemplo, realizar un test con solo tres usuarios te permite generar conclusiones más rápidas, agilizar las modificaciones y hacer otra ronda de testing. De esta manera, al final, más pruebas con menos usuarios detectan más problemas.

También es mejor exponer directamente en una reunión las conclusiones al equipo que redactar un extenso informe que al final nadie lee.

A continuación nos da consejos y pone ejemplos concretos basados en su experiencia. Por ejemplo recomienda proponer siempre tareas personalizadas. Es mejor "encuentra un libro que quieras comprar” que "encuentra tal libro"; o "inserta un anuncio de algo que quieras vender" que "insertar tal anuncio". Cuando la gente realiza tareas ficticias no se implica emocionalmente y no puede usar todo su conocimiento personal.

Los problemas habituales que suelen encontrarse en los test con usuarios con:

• no tienen claro el concepto
• las palabras que buscan no están
• lo que buscan está en la página pero no lo ven por el ruido o porque no destaca.

Tras las pruebas hay que resistir el impulso de añadir explicaciones a las páginas o añadir características que han propuesto los usuarios. Pero el mayor desafío suele ser reparar los problemas SIN estropear las partes que funcionan, pues todo cambio tiene consecuencias.

Capítulo 10. La usabilidad como cortesía común. Por qué su sitio web debe ser mensch

¿Qué va minando la buena voluntad del usuario hasta llevarlo a abandonar?:

• ocultar la información que quiere: el teléfono de soporte, los costes de envío, los precios, etc.
• castigarle por no hacer las cosas a tu manera: obligarle a incluir los datos con un determinado patrón, como espacios en el número de la tarjeta
• pedirle información que no necesitas
• la falta de sinceridad, con mensajes como “su llamada es importante para nosotros” pero te tienen 20 minutos a la espera
• los obstáculos en su camino, como tener que verse una introducción Flash a la fuerza
• que el sitio parezca de aficionados: desorganizado, descuidado y poco profesional

Por el contrario, la buena voluntad del usuario aumenta cuando:

• conoces las principales cosas que las personas quieren hacer en tu sitio y estas son obvias y sencillas
• les dices lo que quieren saber
• les ahorras pasos siempre que puedes
• te esfuerzas en dar la información que necesitan, precisa y de utilidad, organizada de forma que puedan encontrarla
• te anticipas a las preguntas probables y las respondes con franqueza
• les proporcionas comodidades como una impresión correcta de las páginas
• les facilitas la recuperación ante los errores
• te disculpas cuando es necesario si algo está causando un problema

Seguramente si hubiera escrito el libro hoy, hablaría menos de introducciones en Flash y trataría otros temas como los dispositivos móviles.

Capítulo 11. Accesibilidad, hojas de estilo en cascada y usted. Simplemente cuando piensa que ya lo ha hecho, aparece un gato con una tostada untada con mantequilla atada a la espalda.

A los vigorosos desarrolladores de 26 años (son palabras del autor, no mías) les es difícil creer que un gran porcentaje de la población necesita ayuda para acceder a la web. Les parece exagerado. También les cuenta creer que hacer las cosas más accesibles nos beneficia a todos.

Temen además que supondrá más trabajo y que el resultado será menos atractivo.

El autor también habla de la tendencia a pensar que el validador de accesibilidad es como un corrector ortográfico. Además la mayoría descuida las advertencias pues no les parecen problemas reales. Sin embargo, las advertencias pueden hacer referencia a requisitos determinantes pero que simplemente no son evaluables automáticamente.

Da cinco consejos:

• Soluciona los problemas de usabilidad que nos confunden a todos... seguro que también estarán confundiendo a los usuarios con alguna discapacidad.
• Lee una página con un lector de pantalla.
• Lee un libro sobre accesibilidad web.
• Usa CSS.
• Revisa tu código HTML para asegurar que:
  • incluyes texto alternativo a las imágenes
  • usas label en los formularios
  • es accesible por teclado
  • no usas javascript sin una buena razón
  • no usas mapas de imagen del lado del servidor

Capítulo 12. Ayuda! Mi jefe quiere que... Cuando los mejores toman malas decisiones de diseño

Pone ejemplos de cómo explicar las razones por las cuales no debería hacerse algo. Normalmente hay una buena intención en la idea que proponen, entender esa buena intención es el mejor modo de descubrir la manera de argumentar a favor de una solución diferente a la propuesta.

"Haz fácil lo imposible"

Comienza explicando la diferencia entre:

• pruebas cuantitativas: su objetivo es demostrar algo ("esta versión de la web es mejor que la anterior", "mi web es mejor que la de mis competidores") y lo hace midiendo algo ("cuántas personas terminan las tareas", "cuánto tiempo les lleva"). Tienen que ser rigurosas o los resultados no serán fiables.
• pruebas cualitativas, donde se enmarcan las pruebas "hágalo usted mismo" de las que trata el libro, pruebas informales y con menos usuarios. Sencillas y eficaces.

  Básicamente se trata de proponer unas tareas al usuario y pedirle que piense en voz alta mientras las realiza. No se recogen datos, simplemente el equipo que observa la sesión comenta sus notas al término de la misma para decidir qué problemas hay y cómo solucionarlos.

  Hay un vídeo de ejemplo de una de estas pruebas en la web del libro.

Krug resume sus recomendaciones en una serie de máximas o factores críticos de éxito, lo único que espera que el lector no olvide de su libro:

• Una mañana al mes, esto es todo lo que pedimos. No se necesita invertir más tiempo, salvo el necesario para preparar la prueba. Durará una mañana y se debatirá lo ocurrido a la hora de comer. Sin informes, basta un email con el resumen.
• Empiece más pronto de lo que crea que tiene sentido. Puedes probar tu sitio, aunque lo vayas a rediseñar, para saber qué evitar; puedes probar los de la competencia para ver qué funciona mejor; y puedes probar no solo el prototipo, también el boceto de la página en una servilleta, un wireframe o el diseño gráfico. Lo importante es no esperar hasta el final para comenzar a probar.
• No sea exigente en la selección, y valore basándose en promedios. No te obsesiones por encontrar usuarios reales o representativos de la audiencia objetivo, especialmente al principio, porque los errores serios los va a encontrar "casi cualquiera". A veces también es interesante conocer la perspectiva de personas ajenas al negocio. Los usuarios pueden ser incluso de tu empresa, siempre y cuando sean de otros departamentos (administración, finanzas, etc.) También enumera las razones por las cuales tres usuarios son suficientes y por qué estos no deberían participar en las siguientes rondas.
• Conviértalo en un deporte de masas: intenta que el mayor número de personas en tu empresa asistan a las pruebas, especialmente consigue que vengan directivos, porque "ver es creer". Observan, aprenden, toman notas y asisten al debate. Deberían sintetizar los tres problemas de usabilidad más graves que han visto en cada usuario de la sesión. Es importante que la sala de observación y la sala de pruebas estén lejos, así que necesitas un cómplice en la sala de observación para que las cosas funcionen y la gente esté concentrada. También habrá que saber lidiar con los egos heridos. Solo deberían asistir al debate posterior los que han asistido a la sesión de prueba.
• Céntrese implacablemente en los problemas más serios. Hay que salir del debate posterior a la sesión con una lista de los problemas de usabilidad más importantes y con una lista de los que se van a solucionar antes de la siguiente ronda. Siempre hay más problemas que recursos, por tanto es muy importante centrarse primero en lo más grave.
• Cuando solucione problemas, intente hacer lo menos posible. Ya tienes la lista de problemas a solucionar, ahora pregúntate, "¿cuál es el cambio más pequeño y sencillo que podemos hacer para impedir que la gente tenga este problema que hemos observado?" Esto nos asegura que el cambio será sencillo de implementar y que se hará en unos días. Un problema serio puede tener una solución sencilla, que suele ser modificar algo (no rediseñarlo, y da 10 razones por las cuales modificar es mejor que rediseñar) o eliminar algo (no añadas, normalmente hay demasiadas cosas y lo que necesitas es quitar)

Una de las cosas que la gente tiene la tentación de hacer cuando hay un problema de usabilidad es añadir algo. Si alguien no ha entendido las instrucciones, añada más instrucciones. Si alguien no ha podido encontrar lo que estaba buscando en el texto, añada más texto. Si alguien no se ha dado cuenta de algo que necesitaba, añádale más color, póngalo en negrita, o más grande.

Pero muy a menudo la mejor forma de solucionar un problema de usabilidad es hacer justo lo contrario: quitar algo. Elimine algo de la página.

[...] La mayoría de las páginas tienen todo tipo de cosas que el usuario no necesita: demasiadas palabras, demasiadas imágenes irrelevantes, demasiada decoración, demasiado "ruido", y ésa es la razón por la que los usuarios no encuentran lo que necesitan.

Un diseñador sabe que ha alcanzado la perfección no cuando ya no que queda nada que añadir, sino cuando no haya nada que quitar", Antoine de Saint-Exupèry.

Los problemas recurrentes que suele encontrar en muchas webs son:

• Los usuarios no entienden el sitio. Si en los primeros segundos no saben de qué va el sitio, quién lo publica, qué tipo de cosas tiene, cómo está organizado, qué puedo encontrar aquí y qué puedo hacer aquí... todo está perdido. Empezarán con mal pie y cada vez estarán más perdidos. En este sentido, las homes suelen tener demasiadas cosas. La home sigue siendo importante porque, si aterrizas en una página interior, a menudo irás a la página de inicio para salir a la superficie y orientarte, para saber de qué va este sitio, qué más ofrece o si es creíble.
• No se ofrecen pistas visuales. Es posible mantener el atractivo visual y no caer en sutilezas a la hora de dirigir la atención de la gente: ese es el botón de pagar, eso es el título, ese es el menú en el que estás, etc.

Los capítulos 6, 7 y 8 los dedica a dar recomendaciones sobre cómo preparar y llevar a cabo las pruebas: la selección de las tareas, la correcta elaboración y presentación de los escenarios (las tareas tal y como se van a proponer a los usuarios: no utilizar palabras que aparezcan en la web, permitir o no el uso del buscador, etc.), un listado de todo lo que tienes que tener en cuenta para que no se te olvide nada, o como realizar correctamente el trabajo de "facilitador" durante la prueba.

Se pueden descargar diferentes plantillas desde su web.

Al final dedica un capítulo a los test en remoto, moderados o no, sus ventajas e inconvenientes.

Sus herramientas preferidas son Camtasia para grabar sesiones (considera que Morae puede ser excesiva para la mayoría de la gente); GoToMeeting para compartición de pantallas; y Usertesting.com para test en remoto no moderados.

Lecturas que recomienda

Al final del libro "No me hagas pensar" recomienda varios libros, todos ellos anteriores a 2004

• Information Architecture for the World Wide Web, Louis Rosenfeld y Peter Morville
• Why We Buy: The Science of Shopping, Paco Underhill
• Sources of Power: How People Make Decisions, Gary Klein
• The Practice of Creativity: A Manual for Dynamic Group Problem-Solving, George M. Price
• Usabilidad de páginas de inicio: análisis de 50 sitios web, Jakob Nielsen
• Web Application Design Handbokk: Best Practices for Web-Based Software, Susan Fowler y Victor Stanwick
• Defensive Design for the Web, Matthew Linderman, Jason Fried
• The Design of Everyday Things, Donald Norman
• A Practical Guide to Usability Testing, Joseph Dumnas y Janice Redish

En "Haz fácil lo imposible" recomienda los siguientes libros:

• Handbook of Usability Testing: Howto Plan, Design, and Conduct Effective Tests, Jeffrey Rubin, Dana Chisnell, Jared Spool. 2008
• A Practical Guide to Usability Testing, Joseph S. Dumas, Janice C. Redish. 1999
• Usability Testing Essentials: Ready, Set...Test!, Carol M. Barnum. 2010
• Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces, C. Snyder. 2003
• Moderating Usability Tests: Principles and Practices for Interacting, Joseph S. Dumas, Beth A. Loring. 2008
• Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics , Thomas Tullis, William Albert.2008
• Recruiting Without Fear, Will Schroeder, David Brittan, Jared M. Spool. 2005
• How to Recruit Participants for Usability Studies, Nielsen Norman Group.
• Letting Go of the Words, Second Edition: Writing Web Content that Works, Janice (Ginny) Redish. 2007.
• Forms that Work: Designing Web Forms for Usability, Caroline Jarrett, Gerry Gaffney, Steve Krug. 2008

Descripción del problema: formulario con ayuda contextual

Imaginemos que tenemos un sencillo formulario de registro como el siguiente:

Tenemos dos campos de formulario obligatorios. Uno de ellos, "Contraseña", tiene una ayuda contextual que nos indica que la contraseña debe tener como mínimo 6 caracteres.

Este requisito del campo "Contraseña" puede pasar inadvertido al usuario que accede con un lector de pantalla. Nuestro objetivo es asociar semánticamente el campo "Contraseña" con el texto informativo sobre sus requisitos, y asegurarnos de que le será leído al usuario cuando el campo coja el foco, evitando de esta manera que cometa un error al rellenar el campo.

Descripción de la solución: uso de la propiedad aria-describedby

La propiedad aria-describedby de la especificación WAI-ARIA identifica el elemento o los elementos que le proporcionan una descripción al objeto que contiene esta propiedad, es decir, que le proporcionan una información adicional.

En nuestro caso vamos a incluir la propiedad al campo contraseña, indicándole que la información adicional nos la proporciona la ayuda contextual bajo el campo:

<label for="contra">Contraseña (obligatorio):</label>
<input name="contra" id="contra" type="password"aria-describedby="descripcionContra" aria-required="true" />
<p id="descripcionContra" class="ayuda">La contraseña debe tener mínimo 6 caracteres</p>


¿Cómo leerá ahora el lector de pantalla el campo contraseña?

Puedes comprobarlo abriendo el ejemplo Ejemplo de aria-describedby para ayuda contextual en un campo de formulario y un lector de pantalla. Accede con el tabulador al campo de formulario "Contraseña". Como observarás, cuando el campo "Contraseña" coge el foco (accediendo al mismo con el tabulador) el lector de pantalla lee:

• NVDA 2013 (con IE11, FF25 y Chrome31) lee el campo de la siguiente manera: "Contraseña obligatorio. Edición contraseña. Requerido. La contraseña debe tener mínimo 6 caracteres. En blanco"
• JAWS 15 (con IE11, FF25 y Chrome31) lee el campo de la siguiente manera: "Contraseña abre paréntesis obligatorio cierra paréntesis. Password edit required. La contraseña debe tener mínimo 6 caracteres"
• VoiceOver (iPad) lee el campo de la siguiente manera: "Contraseña obligatorio. Seguro. Campo de texto para varias líneas. Obligatorio. La contraseña debe tener mínimo 6 caracteres. Pulse dos veces para editar"

Es decir, nos lee la descripción que hemos indicado, de esta manera al usuario no le pasará inadvertido el requisito para rellenar el campo.

Por tanto, aunque versiones antiguas de navegadores o productos de apoyo no interpreten este atributo, esto no interfiere en el funcionamiento ni la accesibilidad del formulario, por el contrario, añadiendo algo tan simple con una propiedad podemos mejorar la accesibilidad del formulario para muchos usuarios.

Otro detalle es que, gracias a la inclusión de la propiedad aria-required="true", nos anuncia que el campo es obligatorio.

Puedes usar la propiedad aria-describedby tanto con HTML 5 como con HTML 4 o XHTML (en el caso de aria-required en HTML5 es solo required)

Solo es importante recordar que si usas (X)HTML, como en mi ejemplo, debes incluir un DOCTYPE específico para que el validador de sintaxis del W3C no te dé errores:

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

Otros usos de aria-describedby

Esta propiedad también se puede utilizar para clarificar enlaces, botones, abreviaturas, widgets o descripciones de imágenes. Pero es importante advertir que antes de aplicarlo como única técnica valores si existe una alternativa accesible con mayor soporte.

• La técnica ARIA1: Using the aria-describedby property to provide a descriptive label for input controls muestra otro uso de aria-describedby dentro de los formularios, concretamente para describir el propósito de un botón.
• Se puede utilizar para describir un widget. Ver ejemplo en: Using the aria-describedby attribute
• También puede clarificar el propósito de un enlace. Ver ejemplos en: Using aria-describedby for link purpose
• Puede relacionar una imagen con su descripción larga. Ver por ejemplo:
  • Using aria-describedby to provide descriptions of images
  • Long Description Example 1: Using aria-describedby to point to a link to an external description
• Un ejemplo similar al mío sería que la ayuda contextual estuviera en un tooltip, visible al coger el foco, en el siguiente ejemplo se ve la utilización de aria-describedby en este contexto: Overview of Tooltip Examples

Por último, me gustaría recalcar que no hay que confundir aria-describedby con aria-labelledby.

aria-labelledby hace referencia al ID del elemento que lo etiqueta, mientras que aria-describedby hace referencia al ID del elemento que lo describe, que le proporciona más información. Podéis ver usos de aria-labelledby en Using the aria-labelledby attribute

Artículos relacionados:

• WAI-ARIA. Introducción, referencias, ejemplos, herramientas
• Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente
• Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA)
• 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
• Descripción extensa de una imagen: accesible con lector de pantalla y visible sin imágenes activas
• Reseña de “Pro HTML5 Accessibility”
• Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online

Servicios de accesibilidad que ofrezco como consultora freelance

• Consultoría y formación. WCAG 2.0 y WAI-ARIA
• PDF accesibles

Prototyper es una gran herramienta de prototipado, muy parecida a Axure y superior a esta en varios aspectos. Permite prototipar portales y aplicaciones web, incluso aquellas que requieren una gran complejidad de simulación de interacción, o simular con facilidad responsive design. También ofrece mucha potencia de prototipado para dispositivos móviles concretos.

La versión profesional, que es la que voy a evaluar en este artículo, es de pago, con un precio entre los 19-29$ al mes. Tiene una versión de prueba completa de 30 días. También tiene una versión gratis pero con muchas menos funcionalidades.

Es una aplicación local disponible para Windows XP, 7 y 8, y para Mac OSX 10.6+

Comparándola con Axure, Axure 7 también está disponible para Windows y Mac, también tiene una versión de prueba de 30 días y su precio es de 289$ para la versión estándar y 589$ para la versión Pro. Si ya tenías la licencia de una versión anterior, la actualización a la nueva versión es gratis.

Ver reseña de las Novedades de Axure 7

Tipo de prototipo

En primer lugar podrás elegir la resolución para comenzar a trabajar, o bien seleccionar un dispositivo concreto.

Tipos de widget

Tienes disponibles muchos elementos para incluir en el prototipo (y se pueden importar más librerías) Todos los elementos se pueden copiar, pegar, eliminar, bloquear, duplicar, añadirles comentarios, ordenar, grabar como imágenes o añadirles un evento (como veremos más adelante)

En el apartado de propiedades de cada elemento se pueden personalizar con bastante detalle: su posición y tamaño (admite posición absoluta, posición siempre en el top, rotación), background (tanto color como imagen), edición de texto (admite edición parcial de una parte del texto), padding, border, alineamiento, sombra o aspectos generales (id, valor, tooltip, oculto)

Static: etiquetas, imágenes, texto y tablas de texto

De estos cuatro elementos el más destacable son las tablas, que admiten más posibilidades de edición que Axure, como por ejemplo la opción de unir celdas.

Sin embargo no se puede incluir un enlace o evento solo a una parte de un contenido (debes simularlo con un ImageMap) algo que Axure ya ha corregido.

Al incluir una imagen permite voltearla y recortarla.

Shapes: rectángulo, elipse, triángulo, bocadillo, líneas y flechas

Estos elementos se pueden rotar, y al igual que el resto, al redimensionarlos nos va indicando su tamaño.

Containers: paneles dinámicos y tablas dinámicas

Puedes seleccionar cualquier conjunto de elementos y convertirlos en un panel dinámico, o crear directamente el panel e incluir dentro los elementos. Los paneles dinámicos son similares a los de Axure y tienen el mismo propósito, que después podamos modificarlos dinámicamente.

Es muy destacable que permite crear tablas dinámicas, en las que cada celda tiene un ID diferente y que nos permitirá modificarlas dinámicamente con mucha más facilidad que Axure.

Inputs: campos de formulario

Permite incluir campos de texto (normal, password y textarea), radiobutton, checkbox, select, selección de fichero o selección de fecha mediante calendario.

Axure 7 incluye como novedad muchos más tipos de campos de textos, propios de HTML5: email, search, phone, etc.

Navigation: botón, mapa de imagen, árbol y menú

Nos permite crear árboles y menús desplegables.

Data Grids

Uno de los aspectos que más me gusta de la herramienta es que permite simularte una BD (Data Master). Defines los campos y los valores (que pueden importarse y exportarse desde una excel) A partir de ese momento puedes indicar que los elementos que aparezcan en un desplegable o en una tabla (Data Grid) estén tomados del Data Master.

Definición de campos de un Data Master:

Además, si así lo indicas, te creará automáticamente pantallas muy útiles para buscar, añadir, modificar, borrar o ver el detalle de un registro.

Ejemplo de pantalla creada automáticamente a partir de un Data Master. Tiene búsqueda, nuevo, edición, eliminar y detalle. Pop-up con pantalla de añadir nuevo registro.

Definición de valores de un Data Master:

Una vez definido el Data Master puedes incluir en la página un Data Grid con los campos del Data Master que te interese y tantas líneas visibles como indiques. Puedes incluir un "Summary", es decir el número de elementos mostrados del total, y un "Index", es decir la paginación. También puedes indicar que otro elemento, como un desplegable, tome los datos del Data Master:

Axure 7 ha incluido un nuevo elemento "Repeater" con un objetivo similar, pero mi opinión es que el de Axure es menos potente y más difícil de usar (Ver reseña de las Novedades de Axure 7)

Web: PDF, Flash, HTML

Permite embeber un PDF, un Flash o una página web (local, por URL o por inclusión directa de código)

Widget específicos de dispositivos concretos: iPad, iPhone, Android (y Twitter Bootstrap)

Por ejemplo, widget de teclado de iPhone:

Masters

Una característica fundamental que debe tener una herramienta de prototipado es la opción de Masters, es decir, de elementos que puedas reaprovechar en diferentes páginas del prototipo. Prototyper la tiene y es bastante similar a la de Axure.

Eventos e interacción

La herramienta permite crear variables globales (igual que Axure), lo cual puede ser muy útil a la hora de definir la interacción en prototipos complejos.

Otros de los puntos fuertes de la aplicación es la potencia para crear interacciones, con una interfaz que a mí me parece más intuitiva y cómoda de manejar que la de Axure.

Ofrece gran cantidad de eventos:

• De ratón: onClick, onMouseDown, onMouseUp, onDoubleClick, onRightClick, onToggle, onMouseEver, onMouseEnter, onMouseLive, onDrag, onDragEnter, onDrag, onDragStop
• De teclado: onKeyDown, onKeyUp
• Gesture (incluye el giro del dispositivo):
• De página: onPageLoad, onPageUnload, onWindowResize

Permite incluir condiciones:

Las acciones que puedes definir son:

• Enlazar con una página del prototipo, con la página anterior o con una página externa. Puedes establecer efectos de transición o abrirla en un pop-up.
• Cambiar el estilo de un elemento.
• Enseñar u ocultar elementos aplicando o no un efecto.
• Activar un panel aplicando o no un efecto.
• Modificar o seleccionar un valor de un elemento o una variable.
• Pausar, mover o redimensionar un elemento.
• Insertar un elemento en otro.
• Añadir, modificar o eliminar campos de un Data Master
• Mover el foco a un elemento.
• Escrolar.
• Habilitar o deshabilitar un campo.
• Paginar (primera página, página anterior, siguiente página o última página)

Axure 7 incluye como novedad el evento de página OnWindowScroll, que no tiene Prototyper, y que nos permite en Axure simular un Parallax Scrolling (Ver reseña Novedades de Axure 7)

Simulación

En la simulación tienes una columna izquierda, que se puede ocultar, con el árbol de las páginas del prototipo para navegar cómodamente por las mismas. Además puedes indicar que resalte las zonas que tienen asociados determinados eventos, para identificar rápidamente las zonas dinámicas.

Prototipos para dispositivos móviles

Como hemos visto anteriormente, al crear un prototipo puedes seleccionar un dispositivo móvil concreto para el cual creas el prototipo. También hemos visto que tendrás widgets específicos para cada dispositivo móvil y que podrás seleccionar eventos gestuales o de rotación de pantalla.

En el caso de prototipos para dispositivos móviles los puedes simular en el navegador. La simulación incluye el prototipo dentro de una imagen del dispositivo y mediante desplegables puedes seleccionar la rotación y emular con el ratón gestos como pinch o rotate:

Prototipos Responsive Design

Aquí tenéis un ejemplo de prototipo creado con Prototyper que simula un diseño responsive, que se adapta a todas las resoluciones.

La creación de este tipo de prototipos no es automática, hay que trabajársela un poco. Por ejemplo, partiendo de una resolución de 1024, puedes tener una zona de cabecera de 1024 inicial. Después debes crearte un evento onWindowResize cuya acción sea "Resize". En ella indicarás que el ancho de esa zona de cabecera sea "Relative to parent: 100% of parent container width". De esta manera, cuando se redimensiona la página la cabecera también se redimensiona al 100%.

Si quieres que, como en el ejemplo, al reducir el tamaño de pantalla los elementos de la cabecera se simplifiquen, tendrás que jugar también con el evento onWindowResize y con paneles dinámicos con diferente contenido.

Axure 7 trae muchas novedades para simular Responsive Design, con la nueva versión es mucho más sencillo y automático que con las versiones anteriores de Axure o con Prototyper (Ver reseña de las Novedades de Axure 7)

Otras opciones de la herramienta

• Árbol de páginas con ordenación y jerarquía.
• Plantillas de páginas.
• Comentarios y anotaciones.
• Diferentes tipos de vistas de la página (ocultar o no comentarios, marcas de acción, etc.)y zoom.
• Visualización del prototipo en mapa web y creación de escenarios.
• Visualización de las páginas y masters en pestañas como en Axure.
• Exportación como .doc (para mí mejor que la de Axure), .pdf, .html o imágenes.
• Centrar página. Alinear, ordenar y agrupar contenido.
• Publicar y compartir online el prototipo (necesitas cuenta de Usernote)
• Reglas y grid con opción de que los elementos se ajusten automáticamente a la misma.

Axure 7 o Prototyper

Para trabajar con prototipos que emulen un Responsive Design, Axure 7 parece mejor opción.

Para prototipos pensados para dispositivos móviles es mejor Prototyper, aunque solo sea por sus eventos gestuales y sus opciones de simulación.

Para prototipos sencillos cualquiera de las dos opciones sobra. Cuando los prototipos son de aplicaciones web que necesitan simular mucha interacción... me lo pensaría, pero creo que si tuviera que trabajar con muchas tablas, como en una herramienta de gestión, de banca, etc. me acabaría decantando por Prototyper.

Artículos relacionados:

• Novedades de Axure 7: Responsive Design, Parallax Scrolling, Repeater Dataset
• UsabilityTools, suite de herramientas UX
• UserZoom, una herramienta profesional para consultores UX
• Test de usabilidad y accesibilidad con usuarios en remoto con Loop11
• Test de usabilidad y accesibilidad con usuarios en remoto con Loop11
• Listado de validadores de usabilidad y accesibilidad

El mes pasado se lanzaba la nueva versión de Axure: Axure 7, que trae muchas y muy interesantes novedades.

Hay versión completa y gratis de prueba (de la versión Pro) de 30 días. El precio de Axure 7 es de 289$ para la versión estándar y 589$ para la versión Pro. Si ya tenías la licencia de una versión anterior, la actualización a la nueva versión es gratis.

Adaptative Views para Responsive Design

Una de las grandes novedades de Axure 7 son las Adaptative Views, que permiten prototipar de forma automática y muy sencilla con Responsive Design.

En primer lugar seleccionas en el menú Project>Adaptative Views los diferentes tamaños de pantalla con los que quieres trabajar, como si estuvieras usando CSS Media Queries:

Después, en cada página tienes una vista para cada una de las resoluciones definidas:

Puedes modificar así el tamaño de los elementos de cada vista o su contenido, pero también puedes hacerlo dinámicamente gracias a los nuevos eventos de página OnWindowResize y especialmente OnAdaptativeViewChange, este último se lanza cuando pasas de un vista a otra.

Tienes también nuevas opciones de borrado de un elemento: borrar de todas las vistas o eliminar solo en las vistas.

Podéis ver aquí un ejemplo muy sencillito de Responsive Design con Axure 7: si redimensionas el navegador, cuando la anchura es menor de 768px, se muestra una vista diferente donde los elementos están dispuesto de otra manera.

Nuevos eventos de página, OnWindowScroll para Parallax Scrolling

He comentado los nuevos eventos onWindowResize y OnAdaptativeViewChange. Otro evento nuevo de página que ofrece muchas posibilidades es OnWindowScroll.

La opción de incluir interacción en el OnWindowScroll nos va a permitir por ejemplo simular un Parallax Scrolling.

Podéis ver un prototipo creado con Axure 7 que simula un Parallax Scrolling en Ejemplo de Parallax Scrolling y descargar el .rp del ejemplo de Parallax Scrolling con Axure 7.

No hay eventos pensados para dispositivos móviles

En comparación con Prototyper se echan en falta eventos propios para dispositivos móviles. Han incluido algunos eventos nuevos pero siempre relacionado con el ratón o el teclado pero no gestuales.

Nuevo widget "Repeater" para crear listados de elementos

Una de las grandes ventajas que vimos en Prototyper es que permitía con mucha facilidad emular una BD para poder aprovechar los datos en diferentes páginas del prototipo: listarlos en una tabla paginada o en un desplegable, añadir nuevos campos, borrarlos, modificarlos, etc.

Axure 7 incluye como novedad el elemento "Repeater" con un objetivo similar. En el Dataset del elemento defines los campos e introduces los valores (texto, imagen o enlace):

Jugando con las opciones de formato y las posibilidades de interacción, puedes lograr listados paginados (en formato lista o cuadrícula), con opción de ordenación o con opciones de añadir e eliminar registros. Sin embargo llevarlo a cabo resulta complejo y poco intuitivo.

La web de Axure dispone de un ejemplo de tabla de productos creada con "Repeater" y se puede descargar el .rp

Otras novedades en los widgets

Las cosas que más me han llamado la atención en relación con las novedades en los widget son:

• Los campos de tipo texto ahora admiten tipos de HTML5: número de teléfono, email, búsqueda, etc. Además se puede incluir un "hint text" (y editarse su estilo), es decir, un texto por defecto en el campo que se borra automáticamente cuando coge el foco.
• Por fin se puede indicar que los paneles dinámicos se ajusten automáticamente a su contenido.
• Desgraciadamente sigue siendo igual de difícil trabajar con las tablas, pues no incluyen opciones básicas como unir celdas.

Visualización del prototipo

En la columna izquierda, donde si sitúa el árbol de páginas, hay ahora nuevos iconos.

• Ver una determinada vista en caso de usar Responsive Design.
• Resaltar elementos dinámicos como vimos en Prototyper
• Ver y resetear variables (Axure tiene variables globales también)
• Ver la URL de la simulación con o sin site map

Prototyper o Axure

Para trabajar con prototipos que emulen un Responsive Design, Axure 7 parece mejor opción.

Para prototipos pensados para dispositivos móviles es mejor Prototyper, aunque solo sea por sus eventos gestuales y sus opciones de simulación.

Para prototipos sencillos cualquiera de las dos opciones sobra. Cuando los prototipos son de aplicaciones web que necesitan simular mucha interacción... me lo pensaría, pero creo que si tuviera que trabajar con muchas tablas, como en una herramienta de gestión, de banca, etc. me acabaría decantando por Prototyper.

Artículos relacionados:

• Prototyper, herramienta de prototipado: web, móvil, responsive design
• UsabilityTools, suite de herramientas UX
• UserZoom, una herramienta profesional para consultores UX
• Test de usabilidad y accesibilidad con usuarios en remoto con Loop11
• Test de usabilidad y accesibilidad con usuarios en remoto con Loop11
• Listado de validadores de usabilidad y accesibilidad

Índice

• Responsive Design. ¿Qué es?
• Responsive Design. ¿Cómo se hace?
• Relación entre Responsive Design y accesibilidad
  • Concretando, ¿cómo puede favorecer a la accesibilidad de un sitio que este sea Responsive Design?
  • No es oro todo lo que reluce
• Primera norma de accesibilidad para Responsive Design

  5 típicos ejemplos de errores de accesibilidad [...] que son consecuencia de la ocultación de contenido mal implementada o sin medir sus consecuencias.

  • 1. Los encabezados ya no tienen una jerarquía correcta
  • 2. Enlaces para saltar el contenido que ahora solo crean ruido
  • 3. El contenido se oculta de forma inadecuada
  • 4. El menú de navegación ahora es diferente, ¿es accesible?
  • 5. Asegúrate de que el orden de lectura ahora también es correcto
• Otras consideraciones de accesibilidad a tener en cuenta

  Malas prácticas:

  • Mala práctica 1: Tratar imágenes informativas como imágenes decorativas para cargar diferentes tamaños de imagen
  • Mala práctica 2: Definir el viewport con restricción para el zoom
  • Mala práctica 3: Ocultar la barra de scroll horizontal mediante la CSS

  Buenas prácticas (además de cumplir con las 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
  • 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
  • Buena práctica 3: El foco sigue siendo importante en los dispositivos móviles
  • Buena práctica 4: Prueba
• Bibliografía
• Artículos anteriores relacionados
• Servicios de accesibilidad web que ofrezco como consultora freelance

Responsive Design. ¿Qué es?

Responsive Web Design (RWD) 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.

http://foodsense.is/

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

http://mashable.com/

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.

  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 post, 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 pantalla, 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, Chrome 38 y Opera 25 ya soportan el futuro elemento de HTML5 <picture>, que al igual que <video>, permite definir varios recursos (imágenes en este caso), una para cada resolución. Os hablo de este elemento y su soporte actual por los navegadores y productos de apoyo en el artículo LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA, HTML5) .

  Otros técnicas que se suelen utilizar son:

  • 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.
  • Los logotipos e iconos se incluyen con SVG adaptándolos mediante media queries. Podéis consultar varios ejemplos en [PUKHALSKI, 2014] [SOUEIDAN, 2014] En estos casos debemos tener en cuenta que en SVG también podemos incluir títulos y descripciones como comenté en LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA, HTML5) .
  • Los logotipos e iconos se incluyen como fuentes personalizadas que añades con @font-face. Esta técnica provoca serios problemas de accesibilidad si no se incluyen con su correspondiente alternativa textual. Si la letra "a" de la fuente personalizada es el icono de "home", el lector de pantalla leerá "a" en vez de "página principal" a menos que pongamos la correspondiente alternativa textual.
  • 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 de 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:

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

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.

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

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 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 leerá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 ya que bajamos el brillo 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 Progressive Disclosure (Revelación Progresiva), que se basa en 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 terminara 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 Responsive 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 comprometida en los sitios Responsive Design, sino que por lo general suelen cumplir con ciertos requisitos de accesibilidad y es una buena base para comenzar a trabajarla.

Sin embargo no siempre es así, habrá ciertos aspectos a los que prestar especial atención porque nos encontramos con problemas recurrentes y extendidas malas prácticas.

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.

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)

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.

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 siguen teniendo sentido, o si simplificada la página, estos solo crean ruido. Lo mismo puede ocurrir con otros elementos, como los WAI ARIA landmarks (ver artículo Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA) ).

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 oculto de forma incorrecta.

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 asegurarse 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/

Menú de navegación con resoluciones de pantallas menores

En la segunda versión, la versión para resoluciones de pantalla más pequeñas, el lector de pantalla nos anuncia el icono “Enlace Navigation” (), si lo seleccionamos nos lee “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 con resoluciones de pantallas menores

En la segunda versión, la versión para resoluciones de pantalla más pequeñas, el lector de pantalla me anuncia el icono “Enlace ‘Nav Menu’” ( ) 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ú de navegación con resoluciones de pantallas menores

En la segunda versión, la versión para resoluciones de pantalla más pequeñas, el lector de pantalla nunca puede acceder al enlace “Menú”. Lee siempre las opciones de menú 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ú desplegado. 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 vamos 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 (definidas 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 grave 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” () 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 cuáles 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:

Imagen de http://developer.android.com/design/style/metrics-grids.html

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

Imágenes de http://www.lukew.com/ff/entry.asp?1649

Buena práctica 3: El foco sigue siendo importante 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", blog Olga Carreras, mayo 2012.

Bibliografía

• [AVILA, 2013] “What Does Responsive Web Design Have to do with Accessibility?”, Jonathan Avila, julio 2013
• [ANDROID] “Metrics and Grids”, developer.android.com
• [BBC] Mobile Accessibility Guidelines v0.8, BBC
• [CARRERAS, 2011] “Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página”, Olga Carreras, noviembre 2011
• [CARRERAS, 2014] “Screen Resolutions: mobile, Tablet, desktop”, Olga Carreras, enero 2014
• [CARRERAS, 2015] "LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA: aria-describedby, aria-describedat, HTML5: figure, picture)", Olga Carreras, enero 2015
• [CHELARIU, 2013] “Responsive Web Design With Physical Units”, Radu Chelariu, marzo 2013
• [DEVLIN, 2012] “Responsive HTML5 video”, Ian Devlin, agosto 2012
• [DESIGNMODO, 2011] “Responsive Web Design: 50 Examples and Best Practices”, designmodo.com, octubre 2011
• [MEJIA, 2012] “Guía de Responsive Web Design: todo lo que necesita saber sobre Responsive Web Design”, Juan Carlos Mejía Llano, enero 2012
• [PRIETO, 2014] “Mobile First: Diseñando la Web para el futuro”, Ricardo Prieto, enero 2014
• [PUKHALSKI, 2014] “Rethinking Responsive SVG” en Smashing Magazine. Ilya Pukhalski, marzo 2014
• [QUESENBERY, 2010] “Accessibility First—for a Better User Experience for All”, Whitney Quesenbery, December 2010
• [SOUEIDAN, 2014]“Making SVGs Responsive with CSS”, Sara Soueidan, Agosto 2014
• [SWAN, 2012] “Mobile accessibility tests”, Henny Swan, octubre 2012
• [SWAN (b), 2012] “Skip links on mobile and tablets”, Henny Swan, abril 2012
• [SWAN, 2013] “Introduction to Mobile Accessibility”, Henny Swan, mayo 2013
• [UXMATTERS, 2013] “Responsive Web Design and Accessibility”, Uxmatters, abril 2013
• [W3C,2008] “Mobile Web Best Practices 1.0”, W3C, 2008
• [W3C,2012] Media Queries, W3C, W3C Recommendation 19 June 2012
• [W3C_GROUP, 2012] “Main page. Responsive Images Community Group”, W3C
• [W3C_GROUP(b), 2012] “Respimg. Responsive Images Community Group”, W3C
• [WAHLBIN, 2013] “Responsive Web Design”, Katheleen Wahlbin, noviembre 2013
• [WCAG2, 2008] “WCAG 2.0”, W3C, 2008
• [WEBAIM, 2012] “Thread: Responsive Web Design and Accessibility?”, Webaim, octubre 2012
• [WROBLEWSKI, 2009] “Mobile First”, Luke Wroblewski, noviembre 2009
• [WROBLEWSKI, 2010] "Mobile First: One Year Later", Luke Wroblewski, noviembre 2010
• [WROBLEWSKI, 2012] "Responsive Navigation: Optimizing for Touch Across Devices", Luke Wroblewski, noviembre 2012

Artículos anteriores relacionados

• Claves para la web móvil, diciembre 2012
• Accesibilidad y usabilidad móvil: web móvil y app nativa, mayo 2012
• iPad, recomendaciones de usabilidad, noviembre 2011
• Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online , julio 2014

Servicios de accesibilidad web que ofrezco como consultora freelance

• Accesibilidad integrada en el proceso de desarrollo
• Consultoría de accesibilidad conforme a las WCAG 2.0 y la Norma UNE 139803:2012

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:

• Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.
• Novedades de Axure 7: Responsive Design, Parallax Scrolling, Repeater Dataset
• Prototyper, herramienta de prototipado: web, móvil, responsive design

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:

• Descarga gratuita del libro en formato ePub y solicitud de libro impreso
• Descarga gratuita de mi capítulo ampliado "Accesibilidad y SEO" en formato PDF (248 KB)

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:

• Investigación sobre la interacción en los procesos de búsqueda en Google (Marcos, Nettleton y Sáez 2012)
• Diferencias culturales en la interacción con el buscador (Marcos, García-Gavilanes, Bataineh y Pasarín 2013)
• Personalización de texto en pantalla para mejorar el rendimiento en la lectura (Rello, Pielot; Marcos; Carlini 2013)

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

Análisis Sistemático de Pautas para la Accesibilidad TIC para Personas con Discapacidad Cognitiva

El trabajo de investigación parte de la revisión sistemática de la extensa bibliografía que aporta el documento del WAI-W3C "Cognitive Accessibility User Research", publicación del grupo de trabajo Cognitive A11Y TF.

La revisión bibliográfica ha supuesto la lectura y análisis de 175 estudios (libros, artículos, conferencias, sitios web especializados) en busca de pautas de accesibilidad que apoyen la integración de las personas con discapacidad cognitiva y dificultades de aprendizaje. Se ha complementado además con búsquedas bibliográficas adicionales para aquellos campos que no estaban adecuadamente cubiertos en las referencias incluidas en el documento del W3C.

En el trabajo se describen las características propias de las discapacidades cognitivas y dificultades de aprendizaje estudiadas, así como las necesidades y problemas potenciales a los que se enfrentan en la Web las personas con dichas discapacidades.

En concreto se aborda:

• Dislexia
• Afasia
• Trastorno de Aprendizaje No Verbal
• Síndrome de Down
• Envejecimiento y demencia
• Trastorno de déficit de atención
• Autismo
• Discalculia

En el capítulo 4 se pasa a identificar y describir las principales pautas de accesibilidad que ofrece la bibliografía revisada para cada una de las discapacidades cognitivas estudiadas. Se incluye además una tabla resumen con el listado de las pautas asociadas a cada discapacidad, con las fuentes bibliográficas en las que se citan cada una de esas pautas.

Aunque se partía de una bibliografía muy extensa, gran parte de las referencias versaban sobre información médica. De este modo, los referentes temáticos de los que se extrae la información sobre las pautas de accesibilidad asociadas a cada discapacidad se reduce significativamente. Por otro lado, el volumen de referencias por tipo de discapacidad es muy desigual.

El capítulo 4 termina extrayendo 36 pautas generales que agrupan las coincidencias y que se han clasificado temáticamente en: texto, navegación y generales.

Pautas de accesibilidad por tipo de discapacidad cognitiva o de dificultad de aprendizaje

Estas son las pautas que describe el estudio para cada discapacidad en base a la bibliografía analizada (en algunos casos pongo notas para clarificar a qué hacen referencia, se puede consultar la descripción en el trabajo):

Dislexia

• Uso de escala de grises en el fondo
• Contraste de color (el ideal: texto negro sobre crema)
• Tamaño de la fuente (mínimo 14 puntos)
• Espaciado de caracteres (clara separación entre palabras)
• Interlineado (clara separación entre párrafos)
• Ancho de columna (muy estrechas o muy anchas dificultan la lectura)
• Simplicidad del lenguaje

No hace referencia a tipografías concretas.

Afasia

• Palabras simples
• Oraciones cortas
• Tipo de redacción (evitar la voz pasiva)
• Redacción cronológica
• Frases positivas (en afirmativa)
• Tamaño de fuente (mínimo de 14-16 puntos)
• Interlineado (que permita diferenciar bloques de texto)
• Tipos de dibujos (se recomiendan dibujos lineales simples)
• Uso de fotos (deben relacionarse bien con el texto, no usar la misma para ilustrar diferentes puntos, no deben contener información innecesaria)
• Uso del audio
• Lectura fácil
• Longitud del contenido (cantidad razonable de información)
• Representación de números (como números, no como palabras)
• Colores (texto negro sobre crema, pero la preferencia puede variar según las personas y debe permitir variaciones)
• Diseño atractivo (que invite a mirarlo, fácil de aprender y utilizar, claro, sin acumulación de palabras o imágenes)
• Sin uso de símbolos
• Encabezados (claros, concisos, a la izquierda y con un uso sistemático del espacio)
• Navegación fácil (predecible, sin desplazamiento horizontal, navegable mediante el tabulador)

Trastorno de Aprendizaje No Verbal

• Lectura fácil
• Uso de símbolos
• Navegación fácil
• Subtítulos
• Uso de audio

Síndrome de Down

• Colores de texto (personalizable)
• Tipos de letra (suficientemente grande y sans-serif)
• Aumento del tamaño de texto
• Configuración del puntero
• Uso de audio
• Uso de símbolos

Envejecimiento y demencia

• Lenguaje fácil
• Uso de audio
• Oraciones simples
• Uso de enlaces (claros, sencillos, explicados)
• Fácil navegación
• Tipo de fuente (sans-serif, sin itálica, sin sombras, evitar el uso de diferentes fuentes)
• Tamaño de fuente (suficientemente grande y que pueda personalizarse)
• Contraste de colores
• Uso de imágenes (con cuidado porque pueden ser confusas y distraer, han de ser simples, relevantes, significativas, atractivas)
• Uso de encabezados

Trastorno de Déficit de Atención

• Uso de colores (código de colores)
• Crear espacios con la información concisa (evitar elementos distractores)
• Uso eficaz de una agenda o un calendario (recordatorio personalizado de citas y plazos)
• Utilizar listas
• Establecer un sistema de archivo (divisores o carpetas para diferentes tipos de documentos, etiquetas y códigos de color)

Autismo

• Navegación consistente
• Elementos de interfaz similares e interacciones similares
• Aumento de tamaño de texto
• Imágenes (mantener su integridad cuando se amplíen, aunque tengan texto, que debe ser legible y comprensible)
• Organización del contenido (uso de encabezados, uso de listas, interacciones complejas en varios pasos cortos, navegación coherente, división de páginas muy largas)
• Evite los sonidos de fondo
• Lenguaje simple
• Lectura fácil
• Expandir abreviaturas y acrónimos
• Tipos de fuente (sans-serif pero algunas personas en el espectro del autismo prefieren un tipo de letra serif)
• Incluir etiquetas con descripciones simples
• Proporcione texto alternativo
• Enlaces (reducir el número de enlaces y asegurar que se identifican como tales)
• Utilice espacios en blanco

Discalculia

• Navegación fácil
• Soportes y ayuda
• Lenguaje fácil
• Texto descriptivo (de imágenes y tablas con un tamaño de texto adecuado)
• Uso de audio

Pautas de accesibilidad comunes para las personas con discapacidades cognitivas o con dificultades de aprendizaje

En el apartado 4.2 del trabajo se muestra un listado de 36 pautas que han sido extraídas de la evaluación por tipo de discapacidad, y en donde se generalizan las pautas que son repetidas en más de una ocasión. Estas directrices fueron seleccionadas por su aporte concreto dentro de alguna de las discapacidades en particular.

La autora las clasifica en: generales, texto y navegación:

Generales

• Diseño atractivo
• Uso de cabeceras para orientar al lector
• Contenido de pantalla predecible
• Navegación mediante tabulador
• Navegación en jerarquía
• Botones grandes
• Lenguaje simple
• Uso de símbolos
• Navegación con símbolos
• Enlaces claros y sencillos
• Evitar el uso de scroll
• Título y etiquetado
• Elementos de interfaz similares e interacciones similares
• Evitar sonidos de fondo

Texto

• Espaciado entre caracteres de una palabra
• Interlineado 1.5
• Ancho de columna
• Oraciones cortas
• Tipos de fuente
• Números escritos como números
• Colores de texto (combinaciones legibles)
• Aumento del tamaño de texto

Navegación

• Lectura fácil
• Uso de escala de grises para colores de fondo
• Pares de colores
• Uso de palabras simples
• Uso de figuras
• Uso de audio
• Colores
• Uso de símbolos
• Personalización del texto
• Presentación visual (sin justificación de texto ni desplazamiento horizontal)
• Expandir abreviaturas y acrónimos
• Proporcionar texto alternativo mediante etiquetas

Conclusiones

Como conclusiones se señala que la bibliografía está muy enfocada a las directrices para una discapacidad concreta. Por tanto cada directriz tiene un enfoque muy sesgado y específico, y es difícil aplicarla a otra discapacidad cognitiva que no sea para la cual se cita. Son pocos los estudios que buscan definir directrices aplicables a dos o más discapacidades cognitivas.

Esto provoca que para lidiar con una limitación dentro la tecnología, sea necesario utilizar las directrices específicas y no directrices generales. De esta manera, los estudios cuyo objetivo sea generalizar directrices que engloben varias discapacidades son el siguiente salto de evolución de la accesibilidad en la tecnología.

La revisión bibliográfica permite hallar pautas comunes entres discapacidades, cuya diferencia radica en la forma de aplicación.

En general, el conjunto de pautas para estas discapacidades puede utilizarse como punto de partida para definir un conjunto efectivo de pautas de accesibilidad web para personas con discapacidad cognitiva.

Sin embargo considera necesario una revisión de las directrices con la participación activa de personas con diferentes discapacidades, y especialmente de las que están menos estudiadas.

Es claro que las directrices que en la actualidad están definidas, fueron analizadas y diseñadas sobre una base de investigación. Sin embargo, muchos de los estudios no revisados ni rediseñados activamente en base a la realidad, que son las mismas personas con estas discapacidades. Además, la participación activa de las personas para una extensa revisión de las directrices y sus características, otorgaría mayor precisión y por consiguiente mejores resultados en su aplicación. En definitiva, las necesidades, preferencias y perspectivas que brinde la misma sociedad con estas características a través de un trabajo en conjunto con las investigaciones y estudios realizados, tendrá consecuencias positivas en la accesibilidad a la tecnología.

[...]

Si bien es cierto existen discapacidades como la Dislexia, Discalculia, Síndrome de Down las cuales las características particulares y principales desafíos están mejor definidos, existen otras como el Trastorno de Aprendizaje No Verbal que tanto en aspecto médico es confuso la orientación y diagnósticos de sus principales limitantes. Por esta razón, se hace necesario un estudio en el aspecto tecnológico sobre las formas y maneras en que la tecnología pueda colaborar a las principales dificultades, de tal manera que las nuevas directrices favorezcan realmente a sus necesidades en particular.

Artículos anteriores:

• Nueva versión (v.3.0 - 2015) de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0
• WCAG-EM Report Tool. Herramienta de generación del informe de una evaluación de accesibilidad
• BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web
• Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes
• Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online

Este documento repasa los requisitos de accesibilidad que deben cumplir los contenidos audiovisuales para cubrir las necesidades de las personas con discapacidad.

Explica los diferentes tipos de contenidos alternativos que se pueden ofrecer, a quiénes benefician y los requisitos que deben cumplir; recoge asimismo los que debería cumplir el sistema, abarcando el proceso de producción o los agentes de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia).

Es un documento íntimamente relacionado con las WCAG y las UAAG, por ello, al final del documento tenemos una checklist con todos los requisitos donde, entre otras cosas, se indica si están relacionados con criterios de conformidad de las WCAG y las UAAG.

Hay que tener en cuenta que está todavía en fase borrador de trabajo, se lleva trabajando en él desde el año 2012. Actualmente la última versión es Editor Draft del 09 de octubre de 2015, y es en la que me voy a basar para presentarlo y resumirlo. Iré actualizando el artículo a medida que el documento evolucione.

Estructura del documento

El documento está estructurado fundamentalmente en cuatro grandes apartados:

• Resumen de los requisitos de accesibilidad de los medios audiovisuales por tipo de discapacidad.

  En este apartado se proporciona una introducción a las necesidades de los usuarios con discapacidad (ceguera, baja visión, daltonismo, sordera, problemas de audición, sordoceguera, discapacidad física y discapacidad cognitiva) en relación con el contenido audiovisual.

• Tecnologías para proporcionar contenido alternativo.

  En esta sección se explican los diferentes tipos de contenidos alternativos que se pueden proporcionar para ayudar a los usuarios con una discapacidad sensorial a acceder al contenido audiovisual. Por cada uno de ellos se incluye un listado de los requisitos que deben satisfacer en el contexto de un desarrollo HTML5 (pero no se entra en aspectos técnicos o de desarrollo concretos).

• Requisitos del sistema

  En este apartado se explica cómo las tecnologías para proporcionar contenido alternativo al vídeo y audio encajan en el panorama más amplio de la accesibilidad, tanto técnicamente, desde de un punto de vista del agente de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia) como desde un punto de vista del proceso de producción. Por ello, los requisitos listados en este apartado están en su mayoría más relacionados con las UAAG que con las WCAG.

• Checklist "Requisitos de Usuario para la Accesibilidad de los Medios Audiovisuales"

  Este es un apartado muy útil porque recoge la checklist con todos los requisitos listados en el documento.

  La checklist está en formato tabla, con una fila para cada requisito y diversas columnas para indicar:

  • su categorización respecto a la tecnología (si ya está en la especificación de HTML 5, si es un nuevo requisito de la especificación, etc.)
  • su relación con criterios de conformidad de las WCAG y las UAAG. Cuando se incluye el signo "+" se está indicando que el requisito de este documento se define con más precisión que en las WCAG o en las UAAG. De hecho, el grupo de trabajo de las UAAG (se está trabajando en las UAAG 2.0 actualmente) ha indicado que revisarán algunos de sus requisitos en base a esta checklist.
  • su prioridad (Must, Should o May)

  Esta checklist se puede consultar también individualmente en la wiki del W3C Media Accessibility Checklist

Resumen de los requisitos de accesibilidad de los medios audiovisuales por tipo de discapacidad

En este apartado se proporciona una introducción a las necesidades de los usuarios con discapacidad para poder percibir, interactuar y comprender los contenidos audiovisuales.

Para una información más amplia sobre cómo las personas con discapacidad interactúan con el contenido web recomienda el documento imprescindible del W3C: How People with Disabilities Use the Web.

Ceguera

Las personas ciegas no pueden acceder a la información visual presente en los vídeos, los controles de los reproductores o los indicadores de estado. Por ello necesitan que la información se presente de forma alternativa mediante texto o audio.

Hay que tener en cuenta que las personas ciegas utilizan un lector de pantalla y/o una línea braille, por tanto necesitan que los medios audiovisuales sean operables cuando se utilizan estos productos de apoyo.

Baja visión

Las personas con baja visión, en función de su capacidad visual, puede ser que tengan problemas específicos, como dificultad para discriminar la información de primer plano de la información de fondo, para discriminar colores, o les pueden deslumbrar los contenidos muy brillantes.

Por otra parte, quizás no puedan reaccionar rápidamente a la información que se presenta en pantalla durante un tiempo limitado. Pueden tener un ángulo de visión estrecho que no les permita detectar la información clave presentada temporalmente si no están mirando en esa dirección, o si el texto se está moviendo o desplazando.

Estas personas utilizarán probablemente un magnificador de pantalla, así que solo estarán viendo una parte de la pantalla, por ello se debe poder gestionar el contenido audiovisual a través de su producto de apoyo.

Las personas con baja visión pueden tener dificultad para leer el texto demasiado pequeño, con poco contraste, con un determinado tipo de fuente o con efectos. Por otra parte, si el texto es una imagen, se verá pixelada al ampliarse.

Pueden estar utilizando un producto de apoyo que modifique los colores, por ejemplo que los invierta, de modo que los contenidos audiovisuales deben ser visibles también en este contexto.

Por último, los usuarios con baja visión a menudo se benefician también de los textos e instrucciones que algunas veces los autores ocultan visualmente (por ejemplo colocándolos fuera de pantalla) dirigidos a los usuarios de lector de pantalla o línea braille.

Percepción del color

Las personas con problemas en la percepción del color (daltonismo) pueden tener dificultades para discriminar entre diferentes colores, o pueden perderse información clave cuando la información se proporciona solo mediante el color, por ejemplo en los controles del audio/vídeo o en las superposiciones de texto.

Sordera

Las personas sordas no podrán escuchar el audio, por tanto será necesaria una alternativa, normalmente a través de subtítulos sincronizados y/o traducción en lengua de signos.

Problemas de audición

Las personas con problemas de audición podrían no ser capaces de discriminar cierto tipo de sonidos, y por tanto pueden perderse información presente en el audio si tiene frecuencias que no pueden oír, o bien a causa del ruido de fondo o la distorsión.

También pueden perderse información si el audio es demasiado bajo o de mala calidad, o si las personas hablan demasiado rápido y no se puede reproducir el audio más lento.

La información que se presenta mediante audio multicanal puede no ser percibida por las personas sordas de un oído.

Por último, las personas con un implante coclear pueden no tener problemas con el volumen del audio, pero la comprensión puede ser difícil si la experiencia multimedia es abrumadora.

Sordoceguera

Según su nivel de ceguera y sordera, las personas sordociegas podrían necesitar: subtítulos y la posibilidad de ampliarlos; cambiar a colores de alto contraste (u otra combinación de colores); subtítulos y/o descripción del vídeo expuestos por su producto de apoyo; o una transcripción que cada usuario pueda leer a su ritmo, es decir, que no esté basada en el tiempo.

Discapacidad física

Algunas personas con discapacidad física, como aquellas con un control muscular limitado (temblores, falta de coordinación, parálisis), con dolor que les impida el movimiento o con la falta de alguna extremidad, no podrán utilizar el teclado o el ratón para interactuar con el contenido y los controles.

El reproductor de los contenidos audiovisuales tiene que poder ser operable solo con el teclado (sin ratón), lo cual incluye el acceso a todos los controles y métodos de selección del contenido alternativo.

Discapacidad cognitiva

Autismo, dislexia, discalculia, trastorno de déficit de atención, problemas de memoria, ... la extensa gama de condiciones que abarca hace que los requisitos de accesibilidad también varíen ampliamente.

Algunas personas podrán procesar la información auditiva mejor que la lectura del texto, por tanto, la información que se presenta como texto embebido en el vídeo también deberá estar disponible como descripciones de audio.

Otras personas pueden necesitar reducir las distracciones o flashes en las presentaciones de vídeo.

En general, la experiencia multimedia para las personas con trastornos del espectro autista debe ser personalizable y estar bien diseñada para no resultar abrumadora.

Se debe tener cuidado en presentar la experiencia multimedia focalizada en el propósito del contenido y proporcionar alternativas al contenido de una manera clara y concisa.

Tecnologías para proporcionar contenido alternativo

En esta sección se explican los diferentes tipos de contenidos alternativos que se pueden proporcionar para ayudar a los usuarios con una discapacidad sensorial a acceder al contenido audiovisual. Por cada uno de ellos se incluye un listado de los requisitos que deben satisfacer en el contexto de un desarrollo HTML5 (pero no se entra en aspectos técnicos o de desarrollo concretos).

Audiodescripción

Una audiodescripción contiene una narración descriptiva de los elementos visuales clave para hacerlos accesibles a las personas ciegas o con una discapacidad visual. Se incluyen acciones, vestuario, gestos, cambios de escena o cualquier otra información visual relevante que alguien que no puede ver la pantalla podría perderse.

Las audiodescripciones son grabaciones de audio que se insertan en las pausas naturales del mismo, aunque a veces pueden oscurecer brevemente la pista de audio principal (ir a audiodescripción ampliada).

Pueden ser de dos tipos:

• Abiertas, se fusionan con la pista de audio y no pueden ser desactivadas por el usuario.
• Cerradas, el usuario puede activarlas o desactivarlas. Puede ser una pista separada, puede estar programada para reproducirse en puntos específicos de la línea de tiempo y en paralelo con la pista de audio principal.

Algunas descripciones pueden ser entregadas como un canal de audio independiente que se mezcla en el reproductor. Otra opción es tener una pista de "texto a voz" generada por ordenador, que se trata en la siguiente sección (ir a audiodescripciones en formato texto).

Las audiodescripciones no solo benefician a las personas ciegas o con problemas de visión. Por ejemplo, pueden beneficiar a los estudiantes que lidian con materiales o conceptos difíciles, puesto que la audiodescripción puede dar información complementaria acerca de lo que se está viendo en pantalla (la estructura de una ecuación, la complejidad de una pintura, etc.).

Hay programas de televisión y salas de cine de EEUU (y otros países) que ofrecen audiodescripciones. Las regulaciones en EEUU y Europa se están centrando cada vez más en ellas, en especial en el ámbito de la televisión, lo que refleja su importancia para las personas con discapacidad visual.

La tecnología necesaria para crear y ofrecer audiodescripciones es sencilla, pero es necesario que los reproductores sean compatibles con varios canales de audio.

Hay que tener en cuenta que las descripciones también podrán después proporcionarse en formato texto para que puedan ser indexadas y ser susceptibles de búsquedas.

El apartado termina con el listado de los 13 requisitos. Se pueden consultar en la tabla resumen (que como ya hemos comentado, incluye su relación con las WCAG y las UAAG): Media Accessibility Checklist.

Audiodescripciones en formato texto

Cuando la audiodescripción se proporciona en formato texto, en vez de en formato voz grabada, se presentan unos requisitos específicos.

Las audiodescripciones en formato texto (TVDs) se entregan al cliente como texto y son renderizadas localmente por los productos de apoyo (lector de pantalla o línea braille). Los ficheros de texto se proporcionan como archivos de texto que contienen los tiempos de comienzo de cada descripción. Las ventajas son que el usuario de lector de pantalla puede tener un control total sobre la voz, la velocidad del habla u otras opciones.

Sin embargo, como consecuencia de todo ello, no podemos saber cuánto tardará en leerlo el lector de pantalla (el usuario ha podido ralentizar o acelerar la voz respecto a lo que hemos estimado; o la descripción de una escena complicada puede requerir más tiempo), y por tanto no sabemos si oscurecerá el audio principal u otra descripción.

Por otra parte, las personas con baja visión también pueden beneficiarse de tener acceso a la audiodescripción en texto.

El apartado termina con el listado de 5 requisitos (Media Accessibility Checklist).

Audiodescripciones ampliadas

Las audiodescripciones se suelen introducir en las pausas naturales del diálogo o la narración. Pero en algunos casos no hay tiempo suficiente. Las audiodescripciones ampliadas (EVD) trabajan pausando el vídeo y el audio en momentos clave para reproducir la audiodescripción extensa, y una vez que termina reanudan la reproducción.

Las audiodescripciones ampliadas benefician por ejemplo a las personas con el síndrome de Asperger u otras personas con trastornos del espectro autista, ya que en ellas se puede explicar conexiones entre la causa y el efecto, se puede señalar lo que es más importante, o explicar los estados de ánimo.

En este caso se incluye un listado de 3 requisitos (Media Accessibility Checklist).

Clean audio

Un desarrollo relativamente reciente en la accesibilidad en televisión es el concepto de "audio limpio", que aprovecha el audio multicanal.

Beneficia especialmente a las personas con problemas de audición. Consiste en aislar el canal de audio que contiene los diálogos o la información relevante que así puede amplificarse (o modificarse de otro modo), mientras que los canales que tienen la música o los sonidos ambientales pueden atenuarse. Esto permite usar filtros y adaptar el audio a las necesidades del usuario, ya que la pérdida de audición es típicamente dependiente de la frecuencia.

Se listan 4 requisitos (Media Accessibility Checklist).

Navegación por el contenido a través de la estructura del contenido

La mayoría de los usuarios están familiarizados con el avance rápido y el rebobinado en el contenido audiovisual. Sin embargo, esta manera de explorar el contenido, basada en el tiempo, es bastante ineficaz y perjudica especialmente a las personas con discapacidad.

Afortunadamente, la mayoría de los contenidos tienen una estructura (los audiolibros tienen capítulos, las películas actos y escenas, los programas de televisión secciones, etc.). Un marcado adecuado puede exponer su estructura en los controles para avanzar y rebobinar.

Sin embargo, una navegación efectiva por la jerarquía de su estructura requeriría un control adicional que no suele estar disponible en los reproductores multimedia actuales. Este mecanismo (que llaman "granularity-level control") permitiría al usuario ajustar el nivel de granularidad aplicado a los controles "siguiente" y "anterior". La personalización sería necesaria porque puede ser muy engorroso acceder a todos los nodos de la jerarquía o insatisfactorio acceder solo a los del nivel superior de la jerarquía.

Se ponen varios ejemplos. Uno de ellos es el de un telediario. Las grandes secciones serían noticias, tiempo o deportes. El segundo nivel serían las noticias individuales de cada sección. Si dispusieras de este "granularity-level control" podrías ajustar el nivel de granularidad de los controles "siguiente" y "anterior" para saltar de sección en sección, o de noticia en noticia.

A continuación se habla de la navegación a través de contenidos auxiliares, como anuncios, resúmenes de noticias, notas al pie de un libro, etc. que interrumpen el "programa" primario, y que el usuario puede querer saltarlos (o tal vez ir directamente a ellos).

Se listan para terminar 10 requisitos (Media Accessibility Checklist).

Subtítulos

Para las personas sordas o con problemas de audición, los subtítulos son la principal alternativa al audio.

A diferencia de los subtítulos para personas cuyo idioma no es el del contenido, el subtitulado para sordos (captioning) no solo debe transcribir el diálogo o la narración, sino también la información importante como efectos de sonido, risas, etc., y debe estar en el mismo idioma que la pista de audio principal.

Los subtítulos pueden ser cerrados, es decir, pueden ser activados o desactivados por el usuario; o abiertos, que están siempre visibles, fusionados con la pista de vídeo y no pueden desactivarse.

Aunque lo ideal es que sea una transcripción literal del audio, a veces se editan por adecuarlos, por ejemplo, a la velocidad de lectura. Si se editan debería indicarse y debería proporcionarse una versión textual completa.

No es estrictamente necesario que el texto del subtítulo coincida con el movimiento de la boca, a veces pueden adelantarse o extender un poco.

Cuando hablan varias personas, en el texto de los subtítulos se debe distinguir a los oradores, por ejemplo indicando el nombre de la persona ("Ana:") antes del texto que representa lo que dice en el audio.

Los subtítulos también son muy útiles para que los clientes de bares, gimnasios, etc. sigan el programa en la televisión (yo añadiría que también para las personas que por el contexto no pueden activar o escuchar el audio y/o no tienen auriculares) o para las personas que no dominan el idioma. Por otra parte, los subtítulos tienen capacidad de búsqueda, lo que permite localizar un vídeo o un punto exacto del mismo.

Se listan por último 28 requisitos para que los formatos de subtítulos (Media Accessibility Checklist).

Subtítulos enriquecidos

Pueden tenerse varias pistas de subtítulos, por ejemplo uno adecuado para cada rango de edad.

Los subtítulos también pueden enriquecerse con más información, por ejemplo con un glosario (podría ser un enlace que pausa el contenido principal y permite acceso al material explicativo). Proporcionar información relevante adicional permite mejorar la comprensión de los elementos esenciales tanto para los usuarios de productos de apoyo como para las personas con dificultad en la lectura.

En este caso son 5 los requisitos que se listan (Media Accessibility Checklist).

Interpretación en lengua de signos

La lengua de signos no es universal, por tanto debe adecuarse a la audiencia. Es importante que la cara, los brazos, manos y gestos corporales se vean claramente, con suficiente resolución para que sean legibles. Por otra parte es preferible una persona que un avatar animado, al menos por el momento.

Igual que los subtítulos, pueden ser abiertos (siempre visibles) o cerrados (se puede activar/desactivar su visualización).

No todos los dispositivos podrán manejar múltiples flujos de vídeo, así que este debería ser un requisito del navegador. En las situaciones en las que no se soporte, por ejemplo en dispositivos móviles, los autores podrían ofrecer dos versiones, una de ellas con la interpretación en lengua de signos insertada en el vídeo. La selección de diferentes pistas de lengua de signos se haría de la misma manera que se manejan diferentes subtítulos.

Se listan 5 requisitos (Media Accessibility Checklist).

Transcripciones

Hay personas a las que no les es posible o les resulta difícil seguir los subtítulos sincronizados, como las personas sordociegas, las personas con problemas cognitivos o con dificultad en la lectura. Incluso las personas que sí pueden seguirlos podrían perderse información al dividir la atención entre lo que ocurre en pantalla y el texto de los subtítulos.

Por tanto, la transcripción completa ayuda a las personas con diferentes necesidades y no es un sustituto de los subtítulos. La transcripción se puede presentar simultáneamente con el contenido audiovisual, pero debería estar también disponible independientemente.

El contenido que se incluye en la transcripción es tanto el de los subtítulos como el de la audiodescripción (y las opciones interactivas si tiene), y es por tanto una representación completa del material.

Se listan 3 requisitos (Media Accessibility Checklist).

Requisitos del sistema

En este apartado se explica cómo las tecnologías para proporcionar contenido alternativo al vídeo y audio encajan en el panorama más amplio de la accesibilidad, tanto técnicamente desde de un punto de vista del agente de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia) como desde un punto de vista del proceso de producción.

Por ello, los requisitos listados en este apartado (se pueden consultar en Media Accessibility Checklist) están en su mayoría más relacionados con las UAAG que con las WCAG.

Acceso a los controles y menús interactivos

Todas las posibilidades de interacción deben estar disponibles para todos los usuarios. Por tanto deben ser independientes del dispositivo de entrada (teclado, ratón, habla, etc.) y ser expuestas a los productos de apoyo. Las posibilidades de interacción deben ser lo suficientemente ricas para un control detallado de la reproducción del contenido.

Se incluyen 6 requisitos.

Control del nivel de granularidad para la navegación por la estructura del contenido

Como se explicó en Navegación por el contenido a través de la estructura del contenido los usuarios deben ser capaces de establecer el rango o alcance de los controles "siguiente" y "anterior" en tiempo real, ajustando en qué nivel de la estructura del contenido quieren navegar con dichos controles.

Se incluyen 4 requisitos.

Modificación de la escala de tiempo

Por ejemplo en muchos reproductores de audiolibros, desde hace años, se puede acelerar o ralentizar la lectura del contenido sin alterar el tono del audio.

Se incluyen 5 requisitos.

Requisitos de la producción y los resultados

En este apartado se habla del desafío que supone la falta de un sistema universal de acceso, la convivencia de sistemas incompatibles, o la falta de formatos comunes que permita el intercambio de datos. Trata también de los recursos que se aportan por separado, pues los contenidos alternativos son a menudo creados por entidades diferentes a las que crean el contenido audiovisual, así como de las posibilidades de edición.

Se incluyen 4 requisitos.

Descubrimiento y activación/desactivación del contenido alternativo por parte del usuario

Se han descrito diferentes tipos de contenido alternativos que permitirán que las personas puedan percibir, interactuar y comprender el contenido audiovisual. Estas alternativas pueden ser parte del contenido, activarse o desactivarse o estar vinculadas al contenido original.

El usuario se enfrenta al reto de poder descubrir y reconocer que se proporcionan estos contenidos alternativos.

Se incluyen 9 requisitos.

Requisitos relativos a hacer que las propiedades estén disponibles para la API de accesibilidad

Los usuarios necesitan acceder a los contenidos, controlar su reproducción y activar las opciones de accesibilidad. Para que los agentes de usuario apoyen la API de accesibilidad implementada para una plataforma, los controles del reproductor tienen que exponer la información, en caso contrario hay que proporcionar la información en formatos alternativos.

Por ello la existencia de pistas de contenido alternativo debe ser expuesta al agente de usuario y la API de accesibilidad debe tener acceso a las mismas.

Se incluyen 3 requisitos.

Requisitos sobre el uso del visor de vídeo

El visor de vídeo juega un papel importante en lo que se refiere a los contenidos alternativos. Ofrece una caja delimitada para muchas de las alternativas que se ofrecen visualmente (subtítulos, lengua de signos, etc.), aunque no todas se basan en una ventana (como las transcripciones completas).

Hay que recordar que un tercio del vídeo será ocupado por el texto de los subtítulos. Los usuarios esperan encontrarlos en un lugar estándar y poder hacer movimientos oculares rápidos entre los mismos y el contenido del vídeo. Por tanto no se debe ocupar este espacio con otras cosas y se debe evitar la superposición con el contenido importante del vídeo.

Los requisitos de este apartado también hacen referencia a la relación entre el tamaño de la ventana de visualización, la posición de contenido audiovisual y la del contenido alternativo.

Por último se tratan las opciones de personalización por parte del usuario: del brillo y el contraste; de las características del texto (por ejemplo de los subtítulos) tamaño, color, etc.; o el ajuste del tamaño de visualización pero preservando la relación y evitando recortes.

Se incluyen 5 requisitos.

Requisitos sobre las pantallas secundarias y otros dispositivos

El término "second screen" hace referencia a que cuando vemos o consumimos contenido (por ejemplo en la televisión), la información contextual adicional o el propio contenido se puede visualizar en un dispositivo complementario (como una tablet o un móvil). Se llama "second screen" a pesar de que puede haber más de dos y a pesar de que no todos los dispositivos secundarios son pantallas de vídeo.

Hay que asumir que muchos usuarios tendrán un dispositivo de visualización adicional y/o un dispositivo de audio adicional (como unos auriculares) conectado al dispositivo de visualización principal. Por tanto debe ser posible configurar ciertos tipos de contenidos para su presentación en dispositivos específicos.

Se incluyen 7 requisitos.

Checklist de los Requisitos de Usuario para la Accesibilidad de los Medios Audiovisuales

Este es un apartado muy útil porque recoge la checklist con todos los requisitos listados en el documento.

La checklist está en formato tabla, con una fila para cada requisito y diversas columnas para indicar:

• su categorización respecto a la tecnología (si ya está en la especificación de HTML 5, si es un nuevo requisito de la especificación, etc.)
• su relación con criterios de conformidad de las WCAG y las UAAG. Cuando se incluye el signo "+" se está indicando que el requisito de este documento se define con más precisión que en las WCAG o en las UAAG. De hecho, el grupo de trabajo de las UAAG (se está trabajando en las UAAG 2.0 actualmente) ha indicado que revisarán algunos de sus requisitos en base a esta checklist.
• su prioridad (Must, Should o May)

Esta checklist se puede consultar también individualmente en la wiki del W3C Media Accessibility Checklist

Artículos relacionados

• Tabla resumen de los requisitos de accesibilidad para los medios tempodependientes según las WCAG 2.0
• Reseña: "Accesibilidad a los contenidos audiovisuales en la web"

Editores invitados: Emmanuelle Gutiérrez y Restrepo, María del Carmen Ugarte García y Loïc Martínez Normand

Autores: Miguel Ángel Valero (entrevista), Terrill Thompson, Olga Revilla, Olga Carreras, Andy Heath, Rory Heap, Lisa Seeman, Shadi Abou-Zahra, Fernando Machicado Martín, José Ángel Martínez Usero y más.

Nº páginas: 86

Idioma: español

Formato: versión digital

Fecha de publicación: 2015

Web: Monográfico "Accesibilidad Web", revista Novática, nº 232, abril-junio 2015

Novática es la revista de la Asociación de Técnicos de Informática (ATI), decana de la prensa informática española, creada en 1975 y de periodicidad trimestral (más información sobre la revista Novática).

El número 232 (abril-junio 2015) es un monográfico sobre "Accesibilidad Web" con tres editores invitados de lujo: Emmanuelle Gutiérrez y Restrepo (Patrona y Directora General de Fundación Sidar), María del Carmen Ugarte García (socia sénior de ATI) y Loïc Martínez Normand (profesor de la Universidad Politécnica de Madrid y presidente de Fundación Sidar).

He tenido el placer de poder colaborar en el monográfico con el artículo "Documentos electrónicos accesibles". En él explico las buenas prácticas, -sencillas y al alcance de todos-, que podemos seguir en los documentos que creamos y divulgamos para favorecer que sean accesibles para todos.

La revista está disponible solo en formato digital. En la web de la revista podéis encontrar el sumario completo y el resumen de cada artículo: "Monografía: Accesibilidad web", revista Novática, nº 232, abril-junio 2015.

A continuación voy a reseñar los 9 artículos que componen propiamente la monografía sobre Accesibilidad Web.

Presentación. Accesibilidad Web: Tendencias de Futuro

Autores: Emmanuelle Gutiérrez y Restrepo, María del Carmen Ugarte García y Loïc Martínez Normand.

En la presentación se introduce qué es la accesibilidad web y los diferentes artículos que se incluyen en la monografía, cuyo objetivo es ofrecer información actualizada y relevante sobre las tendencias de futuro en el campo de la Accesibilidad Web.

De la presentación me quedo con este párrafo:

Hoy en día debería ser natural considerar que un buen profesional del diseño y desarrollo web debe ser capaz de desarrollar sitios web accesibles, de la misma forma que se preocupa de otros aspectos como la eficiencia, la seguridad y la privacidad. Por lo tanto, las técnicas de diseño y desarrollo accesible deben formar parte de la “caja de herramienta” que los diseñadores y desarrolladores tienen a su alcance para realizar correctamente su trabajo.

No obstante, al día de hoy, la accesibilidad sigue considerándose un plus, algo que puede distinguir nuestro trabajo frente a otros, y por supuesto es deseo de estos editores el que esta diferencia desaparezca lo antes posible.

CEAPAT: El diseño para todos como objetivo fundamental

Entrevista a Miguel Ángel Valero, director de CEAPAT (Centro de Referencia Estatal de Autonomía Personal y Ayudas Técnicas)

Es una entrevista extensa y muy interesante. Parte de qué es el CEAPAT y cuáles son sus programas de acción:

Es frecuente que vengan investigadores del área TIC, tanto nacionales como de proyectos europeos, en busca de asesoramiento por parte del CEAPAT con el fin de no reinventar la rueda

Hace hincapié en lo relevante que es la formación, no solo en las carreras técnicas, sino también la formación para los profesores y educadores, donde se enmarca por ejemplo la publicación "Diseño para todos en educación" (PDF), 2015.

Miguel Ángel Valero también reflexiona sobre la situación actual de la accesibilidad web en España o sobre las razones que subyacen tras la falta de accesibilidad en los sitios web.

Una parte muy interesante de la entrevista es la que versa sobre las denuncias, sanciones y el proceso de resolución de quejas así como el papel que en ellas tiene el CEAPAT. Aunque la labor del CEAPAT es más formativa y divulgativa, están haciendo informes técnicos cuando las denuncias llegan al CENTAC, en quien ha delegado Red.es, que es quién lo gestiona y hace la canalización técnica:

Cuando llegan a nosotros esas denuncias es porque la accesibilidad de esas webs ha sido certificada previamente por entidades privadas, y a lo mejor sí lo era el diseño pero no la implementación. Entonces nosotros aconsejamos cómo hacerlo bien, no tanto qué es lo que está mal, porque lo que está mal con validadores o peritajes técnicos es suficiente.

En los casos que conozco de cerca encuentro rigor técnico en la ejecución de los informes, pero hay plazos demasiado largos en las entidades denunciadas para que procedan a su ejecución.

[...]

Entonces el papel del CEAPAT es más formativo, el papel del CERMI y otras entidades es más de denuncia y el de Red.es es la canalización técnica para que se cumpla, y está bien que estemos separados, para que no haya un efecto “juez y parte”.

También comenta que las entidades se suelen aferrar a la norma antigua WCAG 1.0. Por último reflexiona extensamente sobre el futuro de la accesibilidad web, la accesibilidad móvil, la accesibilidad en redes sociales o la accesibilidad para las personas mayores.

El concepto de accesibilidad llega al gran público cuando se da cuenta de que su producto no es solo útil para él, sino también para otros con alguna limitación en su capacidad funcional y para él mismo, caso de que la tuviera. La accesibilidad llega cuando se comprende que un producto no solo te beneficia a ti mismo, sino también a los que te rodean y a tu entorno.

Deberíamos dar a conocer como diseñando para todas las personas se diseña para cada uno y no a la inversa, pues se entendería mejor la accesibilidad universal. Es imprescindible que la gente comprenda que la necesidad también es tuya, porque el gran público, una vez que comprende, colabora.

Vídeos accesibles para todos

Autor: Terrill Thompson, especialista en accesibilidad tecnológica en la Universidad de Washington.

Comienza con una introducción sobre la importancia de hacer vídeos accesibles, y los estándares del W3C relacionados:

• las WCAG 2.0, donde podemos encontrar los criterios de conformidad que han de cumplir;
• HTML 5,
  • con sus nuevos elementos vídeo y track que permiten insertar vídeo usando solo HTML y sincronizar con ellos ficheros de texto marcados con tiempo,
  • o con su API multimedia que permite construir reproductores propios usando JavaScript para controlar los elementos multimedia;
• WebVTT (Web Video Timed Text), formato para las pistas de texto marcadas con tiempo.

En el grueso del artículo repasa las soluciones para hacer más accesibles los vídeos. Además de explicar cada una de ellas, repasa el soporte actual de las mismas:

• Subtítulos para personas sordas (captions) y subtítulos para traducción (subtitles), y el soporte de track y su atributo kind="captions" y kind="subtitles". Habla también de herramientas libres para incluir subtítulos, de experiencias de crowdsourcing para crear subtítulos (como el proyecto OpenTranslation de TED) o de la tecnología ASR (Automatic Speech Recognition) que usa Youtube. Me parece interesante su reflexión, en la que no reparamos a menudo: la mayor barrera que impide el acceso a la información es el idioma, "la mayor parte del contenido en Internet está únicamente en inglés, idioma que habla solo el 14% de la población mundial".
• Audiodescripción y el soporte de track y su atributo kind="descriptions" (donde se referencia al fichero WebVTT para que sea leído por el navegador o el lector de pantalla del usuario).
• Transcripciones, reflexiona sobre la importancia de las transcripciones, no solo para las personas con discapacidad, sino también para las personas que disponen de poco ancho de banda (habitual en los países en desarrollo) o incluso para las personas muy ocupadas, que pueden echar un vistazo a la transcripción sin tener que visualizar todo el texto o que pueden buscar en el mismo.
• Lengua de señas (HTML5 no facilita un mecanismo específico).
• Reproducción a velocidad variable, y como HTML5 incluye la posibilidad de modificar la velocidad de reproducción a través de la API.
• Controles de reproducción accesibles, y repasa criterios de las WCAG 2.0
• Preferencias del usuario

Al final del artículo aborda el tema de los reproductores de vídeo HTML5 nativos frente a los reproductores de terceros. Incluye un listado de reproductores multimedia HTML5 con soporte para accesibilidad (lista completa disponible en Media Player Accessibility Comparisons).

Destaca claramente el reproductor Able Player, disponible en castellano, puesto que incluye soporte para subtítulos para sordos, subtítulos de traducción, audiodescripción, lengua de señas y reproducción a velocidad variable, además de que ha sido cuidadosamente diseñado para asegurar que sus botones y controles sean accesibles para cualquiera usuario.

En definitiva, un artículo muy interesante que merece la pena leerlo detenidamente.

WAI-ARIA, el gran desconocido de la accesibilidad web

Autor: Olga Revilla, autora de "WCAG 2.0 made easy" que reseñé en su día en el blog.

El artículo resume qué es WAI-ARIA, para qué sirve y a quién beneficia o cómo se implementa, incluyendo varios ejemplos. Creo que consigue sintetizar de manera muy clara todo ello, intentando demostrar, como dice, que la complejidad de su implementación es más aparente que real.

La autora reflexiona también sobre las razones que hacen de WAI-ARIA una de las tecnologías menos conocidas e implementadas por los desarrolladores, algo con lo que estoy de acuerdo y por lo cual me parece muy importante que haya artículos como este.

Le agradezco la referencia a mi post "WAI-ARIA. Introducción, referencias, ejemplos, herramientas", que se enmarca en ese esfuerzo por difundir la especificación WAI-ARIA en español.

Documentos electrónicos accesibles

Autor: Olga Carreras.

Le agradezco a Emmanuelle Gutiérrez y Restrepo que haya contado conmigo para divulgar las buenas prácticas que se han se seguir para crear documentos electrónicos más accesibles.

Incluyo el resumen formal del artículo, que espero poder publicar para su libre descarga a corto plazo.

Todos los días se generan y comparten millones de documentos electrónicos, pero por desgracia, la mayoría de estos documentos presentan barreras de accesibilidad. Esto impide que muchas personas puedan participar en la Sociedad de la Información y del Conocimiento con igualdad de oportunidades.

La accesibilidad es un derecho de todos, pero también una responsabilidad compartida. Como creadores y divulgadores de contenidos en formato digital, está en nuestras manos favorecer que todas las personas puedan percibirlos, entenderlos e interactuar con ellos de forma satisfactoria.

Para lograrlo, vamos a repasar una serie de buenas prácticas, sencillas y al alcance de todos, que puedes aplicar a cualquier tipo de documento electrónico en tu día a día.

Texto, imágenes y traducción en Facebook

Autores: Andy Heath, autor y colaborador de muchos estándares internacionales técnicos de soporte a la accesibilidad; y Rory Heap, coordinador de accesibilidad en la Consumer and Public Interest Network dentro del British Standards Institution (BSI).

Gran parte de las publicaciones en Facebook son o incluyen imágenes como parte del contenido. Sin embargo, pocas de estas imágenes son accesibles para las personas que, por cualquier razón, no pueden acceder al contenido visual, o bien necesitan traducir el texto que incluyen; y para demostrarlo exponen los resultados de un estudio informal.

El grueso del artículo, y el objetivo final del mismo, trata sobre la descripción de una solución usable que permita a los usuarios incluir alternativas textuales a las imágenes que publican en Facebook.

En este artículo argumentaremos que la integración del soporte OCR en una interfaz simple, invocada en tiempo de publicación de la imagen, combinada con el soporte de herramientas de autor para la inclusión de un texto alternativo que describa el contenido de las imágenes mejoraría significativamente la accesibilidad y enriquecería la audiencia de muchos posts en Facebook.

Repasan diferentes casuísticas que se pueden dar: imagen informativa, imagen cuyo contenido se describe en el post, imagen decorativa no relevante para la compresión del post (caso muy raro en Facebook) o imagen en la que desvelar el texto alternativo podría interferir con el propósito de publicar la imagen o del propio post (por ejemplo un chiste visual).

La solución que proponen abarca no solo la publicación sino también cuando se comparte un post ya existente que contiene una imagen, ayudando a corregir la falta de texto alternativo a las misma si dicho texto no se está proporcionando ya.

Por otra parte, en la implementación se tiene también en cuenta la usabilidad, mediante un procedimiento no intrusivo, que no ralentice al usuario y que no le suponga mucho trabajo adicional, pues de lo contrario lo más probable es que no use el procedimiento.

En el artículo "Texto, imágenes y traducción en Facebook" (PDF) podéis consultar la propuesta detallada con imágenes que lo ilustran.

Grupo de Trabajo de Accesibilidad para Discapacidades Cognitivas y Dificultades de Aprendizaje (COGA)

Autor: Lisa Seeman, coordinadora del grupo de trabajo COGA del W3C

El objetivo del grupo de trabajo Cognitive A11Y TF consiste en mejorar la accesibilidad de la web para las personas con discapacidades cognitivas y dificultades de aprendizaje. Este trabajo forma parte de las WCAG y de la Iniciativa de Accesibilidad Web (WAI) del W3C.

La autora explica los progresos y primeros borradores (ya comenté en "Pautas de accesibilidad que benefician a las personas con discapacidad cognitiva" que su principal documento es Cognitive Accessibility User Research), o en qué están trabajando. Como dice la autora, conforme la población va envejeciendo encontrar soluciones en este campo es algo cada vez más urgente desde una perspectiva humana, económica y empresarial.

Me quedo con una reflexión muy interesante que hace en el artículo:

Las dificultades de aprendizaje y las discapacidades cognitivas están entre las deficiencias menos comprendidas por los profesionales de la accesibilidad

[...]

La mayoría de las necesidades que debemos satisfacer respecto a la accesibilidad hacen referencia a las discapacidades sensoriales o físicas [...], que representan aproximadamente un 0,4 % de un mercado impulsado fundamentalmente por las denuncias de grandes grupos de defensa internacionales.

No obstante, aunque los usuarios con discapacidades cognitivas representan entre el 6,3 % y el 11 % del mercado en los Estados Unidos, la accesibilidad apenas ha prestado atención a dichas discapacidades y eso que esta cifra no incluye a las personas con un deterioro cognitivo leve debido a la edad.

Evaluación de la accesibilidad de los sitios web

Autor: Shadi Abou-Zahra, líder de la Oficina Internacional de Programas de la W3C Web Accessibility Initiative (WAI)

El artículo es una descripción detallada de la Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0, el documento del W3C que proporciona una metodología armonizada internacionalmente para la evaluación de todo tipo de sitios web.

Traduje en 2012 el documento al español Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM) (y lo he ido actualizando a medida que el documento evolucionaba) por la importancia que creo que tiene.

Debido a que generalmente no es factible evaluar cada una de las páginas de un sitio web, resulta fundamental emplear un método fiable para determinar el nivel de accesibilidad, de forma global, de un sitio web completo.

La WCAG-EM 1.0 especifica los pasos concretos, y ofrece orientación sobre las buenas prácticas para definir el alcance de la evaluación, explorar el sitio, seleccionar una muestra representativa cuando no es factible evaluar todo el sitio, auditar la muestra seleccionada y reportar los resultados de la evaluación mediante informes estructurados y uniformes.

El artículo termina con un apartado dedicado a WCAG-EM Report Tool, herramienta de software libre, que no es un validador sino un generador de informes que guía a los evaluadores por todos los pasos descritos en la WCAG-EM 1.0 (lo reseñé en WCAG-EM Report Tool. Herramienta de generación de informes de una evaluación de accesibilidad).

El autor también comenta que se está rediseñando y actualizando How to Meet WCAG 2.0 para hacerlo más dinámico y personalizable, y que se pretende integrarlo en la WCAG-EM Report Tool para facilitar el paso de la inspección del proceso de evaluación.

Las compras públicas como motor de una mayor accesibilidad TIC en Europa

Autores: Fernando Machicado Martín, de AENOR, secretario de varios comités de normalización relacionados con la accesibilidad y que participó como secretario en las fases finales de los trabajos del Mandato 376 de la Comisión Europea; y José Ángel Martínez Usero, responsable de Asuntos Internacionales de Funka, una empresa sueca especializada en accesibilidad

Se introduce el contexto internacional y europeo en materia de accesibilidad TIC, y se presentan los principales resultados del Mandato 376 de la Comisión Europea sobre la accesibilidad en la contratación pública de productos y servicios TIC. En particular, la norma UNE-EN 301 549 y la herramienta web para facilitar las compras públicas de productos y servicios TIC accesibles (toolkit).

La contratación pública de bienes y servicios supone alrededor del 18% del PIB de la Unión Europea (UE). Este hecho le da la fuerza para ser un sector estratégico con capacidad de hacer de palanca para la implementación de medidas efectivas de accesibilidad, así como para la concienciación de la sociedad.

Por ello, la Comisión Europea lanzó dos mandatos (M/376 y M/420) para elaborar normas técnicas que impulsaran la accesibilidad en las compras públicas, y que fomenta que la industria desarrolle productos más accesibles, más baratos y más eficientes. Ambos mandatos dan soporte técnico a las políticas europeas de accesibilidad y a la futura y esperada Ley europea de accesibilidad (Accessibility Act).

El documento principal resultante del mandato M/376 es la Norma EN 301 549 ‘Requisitos de accesibilidad adecuados para la contratación pública de productos y servicios TIC en Europa’, primera norma europea de accesibilidad para productos y servicios de TIC considerados de modo global, aplicable a las compras públicas, y redactada bajo este enfoque pero no de modo limitativo.

Esta norma establece los requisitos funcionales que garantizarán que los productos y servicios TIC sean accesibles para todas las personas; por ejemplo, desde un teléfono móvil y ordenadores, pasando por páginas web hasta servicios en la nube. Los requisitos para la web se basan en las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.0

Reseñé la norma en el artículo EN 301 549: primera norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC)

También habla de la herramienta desarrollada para facilitar la aplicación de la norma: “Herramienta web para las compras públicas de productos y servicios ICT accesibles”

Por último termina con una reflexión sobre si las WCAG 2.0, de 2008, se adaptan a los tiempos, por ejemplo al acceso mediante dispositivos móviles o a si cubren todos los aspectos de la discapacidad cognitiva. O de la importancia de superar las limitaciones de las legislaciones nacionales que establecen los mínimos requisitos a cumplir pero no el objetivo final que se desea: satisfacer las necesidades de los usuarios, ser competitivos y desarrollar productos de calidad y hacer felices a los usuarios ("Why WCAG is not enough", Funka).

Una posible receta para diseño web accesible orientado a las tendencias del mercado actual, podría ser:

• Usar tecnologías de desarrollo avanzadas: web reactiva.
• Seguir la norma UNE 139803 (WCAG 2.0) como base.
• Utilizar guías profesionales para un diseño accesible sofisticado.
• Considerar los aspectos de accesibilidad que más afectan a los usuarios finales y cubrir esos aspectos con requisitos extra.
• Probar el servicio/producto con usuarios finales

Otras reseñas del monográfico:

• Loïc Martínez Normand editor de la monografía sobre "Accesibilidad Web" en Novática, en la ETSI

El post "Work Begins on Extensions to WCAG 2.0" publicado en el blog del W3C el 1 de octubre de 2015 comienza diciendo:

La semana pasada fue aprobado formalmente por el W3C el nuevo estatuto para el Grupo de Trabajo de las WCAG (WCAG WG), después de haber sido revisado por las organizaciones miembro del W3C. Por primera desde la finalización de las WCAG 2.0 en 2008, este estatuto permite al Grupo de Trabajo explorar maneras de proporcionar directrices más allá de las WCAG 2.0.

El nuevo estatuto se puede consultar en Web Content Accessibility Guidelines Working Group Charter. La fecha de comienzo y fin del mismo es del 24 de septiembre de 2015 al 31 de julio de 2018, pero señalan que quizás finalice antes si se conforma un grupo de trabajo unitario (WCAG, ATAG, UAAG).

Los estatutos de los Grupos de Trabajo de las ATAG y UAAG expiran en 2015, tanto en el Authoring Tool Accessibility Guidelines Working Group Charter como en el User Agent Accessibility Guidelines Working Group Charter la fecha de finalización que se indica es el 5 de noviembre de 2015. Las ATAG 2.0 se han publicado en septiembre de 2015 y las UAAG 2.0 acaban de actualizar su Working Draft.

En el post se indica:

Con el fin de integrar mejor los componentes de la accesibilidad web en un solo conjunto de directrices, el Grupo de Trabajo está estudiando la posibilidad de fusionarse con el Grupo de Trabajo de las ATAG y las UAAG.

En nuevo estatuto del WCAG WG se dice:

El W3C planea revisar las opciones para combinar el contenido, los agentes de usuario y las herramientas de autor bajo un único Grupo de Trabajo, y espera proponer un estatuto para tratar estos temas, evaluar la experiencia hasta la fecha en el desarrollo de extensiones normativas y potencialmente proponer trabajar en nuevas directrices normativas. Si se forma este nuevo grupo de trabajo, el estatuto del Grupo de trabajo de las WCAG podría terminarse antes de esa fecha (31 de julio de 2018)

El artículo Work Begins on Extensions to WCAG 2.0 del W3C sigue así:

Las WCAG 2.0 siguen siendo el referente por excelencia de la accesibilidad web. Un número cada vez mayor de políticas nacionales y de organizaciones de todo el mundo referencian a las WCAG 2.0 (Canadá, Australia, Japón, India, EEUU) Las WCAG 2.0 resisten bien hoy a pesar de los cambios significativos en la tecnología.

Ha habido algunos cambios en el campo de la tecnología que sin embargo no se previeron plenamente durante el desarrollo de las WCAG 2.0.

Los cambios sobre cómo las personas acceden a la Web desde dispositivos móviles requieren criterios de conformidad que aborden estas situación más específicamente.

Los usuarios con discapacidad cognitiva o problemas de aprendizaje y los usuarios con baja visión han sugerido formas en las que los criterios de conformidad podrían abordar mejor sus necesidades.

[...]

Las nuevas tecnologías en el horizonte y la rápida evolución de las tecnologías para la interacción del usuario con la Web es probable que continúen impulsando la necesidad de una nueva orientación.

Para hacer frente a estas necesidades, el Grupo de Trabajo de las WCAG ha comenzado a desarrollar un marco para las extensiones de las WCAG 2.0.

Estas extensiones serían documentos de directrices independientes para aumentar la cobertura de las necesidades particulares de accesibilidad. Los autores y responsables de las políticas podrán optar por cumplir las pautas de accesibilidad con una o más extensiones, las cuales inherentemente cumplen con la base de las pautas de las WCAG 2.0, mientras que las organizaciones que tienen políticas construidas alrededor solo de las WCAG 2.0 no se verían afectadas por las extensiones.

[...]

El Grupo de Trabajo está reuniendo requisitos que pueden conducir a la creación de una versión actualizada de las WCAG 2.0 o a unas nuevas pautas de accesibilidad conjuntas, o ambas.

En Extension Integration, W3C

En Extension Integration, W3C

Vamos por tanto a ver que se dice en el nuevo estatuto del WCAG WG (Web Content Accessibility Guidelines Working Group Charter).

En el documento se define el alcance de las actividades del grupo de la siguiente manera:

1. Soporte de las WCAG 2.0
   • mantenimiento de las erratas de las WCAG 2.0 (Web Content Accessibility Guidelines (WCAG) 2.0 Errata, cuya última actualización hasta la fecha es de diciembre de 2014) y publicación de una "WCAG 2.0 Edited Recommendation" solo para incorporar erratas editoriales (según su hoja de ruta se publicaría en abril de 2016)
   • publicar "Understanding WCAG 2.0" y "Techniques for WCAG 2.0". Se marcan como meta dos actualizaciones anuales de estos documentos.
   • responder a los comentarios públicos sobre las WCAG 2.0 y sus materiales de apoyo
   • coordinación con otros grupos para apoyar el conocimiento de las WCAG 2.0 y cómo usarlas
2. Desarrollar extensiones normativas de las WCAG 2.0 y material de apoyo para abordar áreas temáticas especiales, según sea necesario, sin cambiar el significado de la conformidad de las WCAG 2.0
   • Definir criterios para grupos de usuarios específicos y criterios sectoriales en los que se han identificado necesidades de orientación, incluyendo pero no limitado a:
     • dispositivos móviles
     • discapacidades cognitivas y problemas de aprendizaje
     • materiales didácticos digitales
     • baja visión
   • Garantizar que, si bien las extensiones pueden o no pueden redefinir aspectos de las WCAG 2.0 en el contexto de la extensión, el trabajo de la extensión no afecte a la validez de las actuales declaraciones de las WCAG 2.0
   • Proporcionar guías sobre cómo las extensiones de las WCAG 2.0 podrían aplicarse al contenido no web si fuera necesario (actualmente existe el documento Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT))
3. Determinar requisitos necesarios de las futuras pautas de accesibilidad y publicar requisitos
4. Coordinarse con otros grupos de trabajo en actividades relacionadas con las WCAG:
   • Participar en los trabajos de documentación del soporte de la accesibilidad, como una base de datos para almacenar información de soporte de la accesibilidad de múltiples fuentes, aunque el WCAG WG no mantendrá o revisará los datos
   • Colaborar con otros grupos para ampliar el conjunto de test samples para las técnicas de las WCAG 2.0 (podéis ver Complete List of WCAG 2.0 Test Samples)
   • Colaborar con otros grupos para abordar nuevas cuestiones relacionadas con la accesibilidad del contenido

Se indica que los criterios de éxito del grupo serán:

• Publicación periódica de actualizaciones de los documentos "Understanding WCAG 2.0" y "WCAG 2.0 Techniques", que recordemos que no son normativos (solo el documento de las WCAG 2.0 es normativo) y se van actualizando periódicamente; por ejemplo se añaden, eliminan o modifican técnicas y fallos comunes. La última actualización a día de hoy es de febrero de 2015, donde se reemplazaron tres técnicas y se eliminó una técnica y un fallo común. Los hitos que se marcan es actualizarlos dos veces al año ("Public Editors' Draft" en enero y junio y "Note" en marzo y septiembre).
• Publicar las especificaciones de extensión de las WCAG 2.0 y los materiales de apoyo
• Publicar los requisitos de una futura versión de las WCAG

Como vemos, se tiene previsto, a corto plazo (2018) dos extensiones a las WCAG 2.0: WCAG Cognitive Extension y WCAG Mobile Extension.

Los Requisitos de la futura versión de las WCAG 2.0 se espera tenerlos para octubre de 2017. La Note Requisitos para las WCAG 2.0 se publicó en abril de 2006, dos años y medio antes de la publicación de las WCAG 2.0

Sin embargo hay que ser precavidos con las fechas, el estatuto de las UAAG y las ATAG se marcaba como meta tener la recomendación de las UAAG 2.0 en octubre de 2011 y la de las ATAG 2.0 en mayo de 2011. Sin embargo las ATAG 2.0 son recomendación desde septiembre de 2015 y las UAAG 2.0, a día de hoy, son W3C Working Draft 15 September 2015.

Por último vamos a repasar otro párrafo del artículo del blog del W3C:

En los últimos tiempos, el WCAG WG ha formado grupos de trabajo sobre accesibilidad en relación con los dispositivos móviles, la discapacidad cognitiva y las personas con baja visión para definir requisitos y criterios de conformidad para estas tres áreas.

En esta última parte del artículo voy a repasar estos tres grupos y la labor que han llevado a cabo.

Cognitive and Learning Disabilities Accessibility Task Force (Cognitive A11Y TF)

Su principal documento es Cognitive Accessibility User Research, que actualmente es un First Public Working Draft de 15 de junio de 2015.

También están identificando técnicas conocidas y propuestas de técnicas específicas en relación con las necesidades de las personas con discapacidad cognitiva y problemas de aprendizaje.

Artículo relacionado:Pautas de accesibilidad que benefician a las personas con discapacidad cognitiva, Olga Carreras, 2015

Low Vision Accessibility Task Force (Low Vision A11Y TF)

Es de reciente constitución y por ello todavía no tiene publicaciones.

Aquellos que estén interesados en este tema pueden ir consultando su wiki (Low Vision A11Y TF Wiki) donde se está recopilando mucha información: qué es la baja visión, tipos, casos de uso e historias de usuario, o enlaces a artículos de referencia.

Mobile Accessibility Task Force (Mobile A11Y TF)

En la página Mobile Accesibility de la WAI se explica que la accesibilidad móvil hace referencia a hacer que los sitios web y las aplicaciones sean más accesibles para las personas con discapacidad cuando acceden desde dispositivos móviles, incluyendo una amplia gama de dispositivos: teléfonos, tables, TV, etc.

Como se indica, no hay en la actualidad pautas específicas para la accesibilidad móvil sino que quedan cubiertas hoy por las WCAG y las UAAG.

El principal documento del Mobile A11Y TF es Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile, que actualmente es un First Public Working Draft del 26 de febrero de 2015. Trata sobre cómo las WCAG 2.0 se aplican al contenido web móvil y las apps (web o nativas o híbridas).

También tienen un listado de las técnicas actuales de las WCAG 2.0 que están relacionadas con el acceso móvil: WCAG 2.0 Techniques that Apply to Mobile

Están trabajando en las técnicas móvil específicas para incluir en el documento "Techniques for WCAG 2.0". Ya vimos en otro artículo que también se está trabajando en las técnicas HTML 5. Actualmente el documento Techniques for WCAG 2.0 tiene los siguientes tipos de técnicas: Generales, HTML/XHTML, CSS, Scripts de lado cliente, Script del lado servidor, SMIL, Texto plano, ARIA, Flash, Silverlight y PDF, que explican cómo cumplir con los criterios de conformidad de las WCAG 2.0 con dichas tecnologías.

Otros documentos de interés del W3C relacionados con accesibilidad móvil son:

• Mobile Accessibility Examples from UAAG.
• "Mobile Web Application Best Practices" (2010), "Mobile Web Best Practices 1.0" (2008) y "Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG)" (2009), que expliqué en el artículo "Accesibilidad y usabilidad móvil: web móvil y app nativa".
• IndieUI (Independent User Interface), que define una forma de que las acciones del usuario sean comunicadas a las aplicaciones web, incluyendo aplicaciones móviles. Esto hará que sea más fácil que las aplicaciones trabajen con una amplia gama de dispositivos, incluyendo los productos de apoyo.

Artículo relacionado:Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes, Olga Carreras, enero de 2014

El objetivo de este artículo es divulgar las guías "Accesible Mobile Interfaces" (2012) y "Mobile Navigation" (2014) de Funka, una empresa sueca especializada en accesibilidad de reconocido prestigio internacional.

Estas guías nos ofrecen un listado de pautas, estudiadas y testeadas con usuarios, que nos permiten diseñar e implementar interfaces móviles más usables y accesibles.

Al final del post podéis consultar otros artículos sobre accesibilidad y usabilidad en dispositivos móviles.

"Guidelines for the Development of Accessible Mobile Interfaces", Funka, 2012

Funka elaboró las directrices para el desarrollo de interfaces móviles accesibles en el marco de un proyecto financiado por el Swedish Internet Fund.

Los smartphones tienen buen soporte para la accesibilidad y a menudo algún producto de apoyo incorporado. Pero todavía se cometen muchos errores por falta de conocimientos, documentación y prácticas.

Los problemas son tanto en accesibilidad técnica (que afectan especialmente a los usuarios que utilizan productos de apoyo) como en accesibilidad pedagógica (que nos afectan a todos, pero especialmente a las personas mayores, con poca experiencia tecnológica o con discapacidad cognitiva, visual o motriz)

La guía explica que durante el proceso de elaboración inventariaron las directrices y estudios existentes sobre accesibilidad en interfaces móviles, realizaron encuestas, se entrevistaron con usuarios con diferentes tipos de discapacidad y realizaron variados test con usuarios.

Las directrices son de uso gratuito y están disponibles en español: Pautas para el desarrollo de interfaces móviles accesibles, PDF (350Kb)

Son 48 pautas agrupadas en 6 temas. Las enumero a continuación, con alguna anotación interesante en determinados casos. Podéis consultar la descripción de cada pauta en el documento original.

Elección de una solución

1. Observe que su sitio web básico funcione en dispositivos móviles

   Un problema común es el de las opciones de menú que solo se despliegan al colocar el cursor sobre una opción. Recomiendan un enfoque Mobile First

2. No obligue al usuario a utilizar una versión móvil, pero ofrézcala en caso de que las páginas del sitio web básico sean grandes o tengan unas funcionalidades complejas

   Se debe ofrecer enlaces entre las diferentes versiones y recordar la elección del usuario.

3. Una versión móvil del sitio web debe, en la medida de lo posible, facilitar al usuario la misma información y servicios que el sitio web normal, a no ser que se trate expresamente de una versión móvil de un servicio o funcionalidad específicamente delimitados

   Aplicable en el caso de que se ofrezca una versión móvil.

4. Cree aplicaciones para funcionalidades claramente delimitadas a las que el usuario pueda necesitar acceder con frecuencia

   La creación de una app debería hacerse sobre todo para tareas específicas a las que un grupo de usuarios necesite acceder o ejecutar con frecuencia.

Diseño

5. Siga las WCAG 2.0 excepto en los aspectos que las presentes pautas contradigan a las WCAG 2.0
6. Al crear aplicaciones para dispositivos específicos, deberán seguirse las directrices de diseño y accesibilidad, siempre y cuando no contradigan estas pautas

   En caso de que existan. Por ejemplo, cuando se desarrollen aplicaciones para iPhone, deben seguirse las directrices de Apple (siempre y cuando no contradigan estas pautas). Lo traté en el artículo Accesibilidad y usabilidad móvil: web móvil y app nativa

7. Si desarrolla una aplicación para una plataforma específica, deberá ser compatible con las características propias de la plataforma
8. Identifique los elementos gráficos, iconos y botones con su motivo o función

   En los sitios web tendrán un texto alternativo. En las aplicaciones, la forma de incluir la descripción dependerá del sistema operativo.

9. Cada objeto de formulario debe tener una etiqueta o una descripción
10. No utilice marcos (frames, iframes) en interfaces web
11. Ayude al usuario a introducir datos adaptando el teclado virtual al contenido que debe introducirse

    Lo traté en el artículo: HTML5 y accesibilidad: nuevos tipos de input, atributos asociados y validación nativa

12. Minimice el uso de scripts ejecutados en cliente

    Los dispositivos móviles tienen a menudo menor capacidad que los ordenadores normales y el empleo de muchos scripts puede causar problemas.

13. Realice pruebas prácticas de la solución

    Siempre debe realizarse un testeo práctico de la solución con personas que no hayan participado en el desarrollo, incluyendo a personas con discapacidad en los tests de usuario.

Estructura y presentación

14. En las vistas con scroll, coloque las cosas importantes más arriba y las menos importantes más abajo

    Pero ten en cuenta también que es difícil conseguir hacer clic en los objetos que se encuentran arriba del todo en la pantalla. Por lo tanto, una interacción importante no debe situarse en la parte de arriba del todo de la pantalla.

    Lo comentaba en el artículo Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes. .

    Imagen de Responsive Navigation: Optimizing for Touch Across Devices, Luke Wroblewski

15. Agrupe los elementos que van juntos

    La página debe redistribuirse, en la medida de lo posible, de modo que la información relacionada se posicione justo detrás de la sección con la que se relaciona, en lugar de que todo el material relacionado se coloque abajo del todo.

16. Procure crear un diseño limpio y minimice el número de objetos “innecesarios”
17. Procure que el encabezado de la página sea pequeño
18. Cree áreas grandes para hacer clic

    Procure que el área para hacer clic tenga como mínimo el alto de fila del cuerpo de texto en un sentido y el alto de fila del cuerpo de texto multiplicado por 3 en el otro sentido. Los iconos de una aplicación deberían tener, como mínimo, 9 milímetros de ancho y de alto.

19. No coloque los botones de uso frecuente en el margen derecho o izquierdo, a no ser que ocupen, como mínimo, una tercera parte del ancho de la pantalla

    A los usuarios que solo utilizan una mano, o que tienen que equilibrar el móvil sobre la rodilla para poder utilizarlo, les resulta difícil pulsar botones que están en los márgenes.

20. No coloque a la derecha los botones, funcionalidades o grupos con botones y funcionalidades, a no ser que el grupo ocupe, como mínimo, el 75 % de la pantalla en todas las posiciones

    Beneficia específicamente a los usuarios que no ven el sitio web y utilizan el dedo índice para escanear la interfaz.

21. Oriente los botones y los enlaces en filas claras (horizontal y verticalmente)
22. Las etiquetas de los campos de introducción deben colocarse principalmente encima del campo

    Son una excepción las casillas de verificación y los botones de opción, en los que el texto puede situarse a la derecha, pero el título del grupo se colocaría encima del mismo.

23. Las longitudes de línea deben adaptarse al ancho de la pantalla, pero nunca superar un máximo de 70 caracteres por línea, espacios incluidos

    El objetivo es que la longitud sea de 55-60 caracteres por línea, espacios incluidos.

24. Limite la cantidad de información y el número de objetos mostrados

    Esto no significa que se deban eliminar partes del contenido, pero sí que puede ser más fácil para el usuario que se oculten algunas partes en forma de acordeón, o que los submenús se oculten en desplegables. En estos casos, la funcionalidad debe ser clara y el usuario debe poder acceder a las partes ocultas de manera intuitiva.

25. Utilice iconos conocidos
26. Diseñe los objetos clicables para que sean obvios

    Los enlaces no se deben distinguir solo por el color.

27. Utilice contrastes altos
28. Debe ser posible utilizar la interfaz en la visualización tanto horizontal como vertical

Interacción

29. Utilice conceptos de navegación sencillos

    Los mega-menús no funcionan bien en móvil y han de rediseñarse.

30. Si desarrolla una aplicación para un sistema operativo o un dispositivo móvil que pueda tener botones de control (por ejemplo, teclas de flecha y un botón Aceptar), debe ser posible utilizarlos para navegar por la interfaz
31. Si desarrolla una interfaz que se pueda utilizar en dispositivos a los que se pueda conectar un teclado, la interfaz debe, cuando sea posible, poder controlarse con el teclado
32. Inserte atajos para facilitar que el usuario salte de una parte a otra del contenido en las páginas largas

    Aunque estén ocultos inicialmente, deben mostrarse al recibir el foco en la navegación por teclado.

33. Minimice la introducción de texto en la interfaz
34. Si la interfaz admite el control mediante gestos, debe implementarse esta función
35. No incluya funciones que solo se puedan ejecutar mediante gestos, compleméntelas siempre con un botón o enlace
36. Permita controlar la interfaz solo con un dedo
37. Sea sistemático

    Por ejemplo, coloca los botones que tengan una determinada funcionalidad en el mismo lugar de la pantalla o diséñalos de forma homogénea.

38. Utilice los objetos integrados según su uso previsto y de la forma en que el usuario espera que se utilicen

    Es decir, en vez de implementar componentes propios con una funcionalidad equivalente.

39. Proporcione feedback al usuario

    Mediante un sonido y una vibración breve si el dispositivo lo permite, pero siendo posible desconectar esta confirmación. Puede haber excepciones cuando un exceso de confirmaciones se perciba como molesto (por ejemplo, una aplicación que funciona como podómetro no debe confirmar cada paso registrado).

40. Proporcione información de estado clara al usuario

    Por ejemplo, si la aplicación o sitio web están cargando datos, es conveniente mostrar el progreso de la carga.

41. Proporcione al usuario tiempo suficiente y avísele antes de que se supere el límite de tiempo

    Si fuera posible, también debería existir la posibilidad de prorrogar el tiempo de forma sencilla.

42. Ayude al usuario a evitar y a corregir posibles errores

    Por ejemplo con autocompletado o con sugerencias de búsqueda. Si aun así se producen errores, debe informarse claramente al usuario tanto en la parte superior de la página como en el lugar en el que se haya producido el error. Cuando sea posible, se debe ofrecer también propuestas de solución.

Contenido

43. Utilice imágenes solo si son realmente útiles para el usuario
44. Utilice encabezados breves y descriptivos para estructurar la información
45. Evite las abreviaturas

Configuración de usuario

46. Asegure que la interfaz pueda ampliarse
47. Considere la posibilidad de proporcionar una opción para invertir los colores
48. Considere la posibilidad de proporcionar un ajuste para cambiar el tipo de letra

“Mobile Navigation Guidelines”, Funka, 2014

Entre octubre de 2013 y febrero de 2014 Funka encabezó un proyecto con 20 clientes para investigar los conceptos de navegación en interfaces móviles.

En primer lugar analizaron y testearon los conceptos de navegación existentes; y en segundo lugar desarrollaron y testearon con usuarios (también con usuarios con discapacidad) prototipos de nuevos conceptos de navegación.

En base a los resultados elaboraron las "Mobile Navigation Guidelines" (PDF, 315 kb), las directrices a seguir en la definición de la interfaz de navegación de sitios o aplicaciones móviles para asegurar su usabilidad y accesibilidad.

En base al estudio, hemos podido confirmar que hay diversos conceptos de navegación para elegir. No parece que haya uno perfecto, todos tienen sus ventajas y desventajas. La elección del concepto de navegación puede depender del tipo de interfaz o de la cantidad de contenido. Por tanto no se puede decir que se puedan resolver todos los problemas con un concepto de navegación concreto.

Es decir, no podemos decir "este es el mejor sistema de navegación en todos los casos", lo que sí se puede decir es qué directrices debe cumplir.

Aunque se desarrollaron principalmente para sitios web de información, muchas de las directrices se pueden aplicar a otros tipos de sitios o aplicaciones móviles, pero indican que su aplicación en estos casos debería ser siempre testeada con usuarios reales (algo que sería recomendable siempre, claro, pero más todavía en estos casos).

Las directrices son de libre acceso y de uso gratuito. Son 23 pautas que se agrupan en 5 temas. Las enumero a continuación, con alguna anotación interesante en determinados casos. Podéis consultar la descripción de cada pauta en el documento original (solo disponible en inglés).

Interacción

1. El concepto de navegación es fácil de comprender
2. La navegación es consistente y predecible entre los diferentes niveles de la estructura de información.

   Una excepción es la navegación por el nivel superior, que puede ser diferente a la de los submenús sin crear problemas.

3. El usuario recibe feedback relevante

   Por ejemplo, se informa de la opción de menú seleccionada; un título visible indica en qué página se ha aterrizado; etc.

4. La comprensión del concepto de navegación no está basado en la ruta del enlace
5. El tiempo que se necesita para navegar está minimizado

   Por ejemplo, se reduce el número de pasos para alcanzar el contenido si dichos pasos requieren una carga de página. Las pruebas demuestran que a menudo hacer scroll es más rápido.

6. La navegación trabaja en diferentes tamaños de ventana

   No solo en diferentes tamaños sino también en posición vertical y horizontal. Ciertos conceptos funcionan mejor en pantallas grandes y otros mejor en pantallas pequeñas, por ello no cambies demasiado pronto a la versión de navegación móvil.

7. La estructura de navegación soporta diferentes niveles de profundidad (si así se requiere)

   Hay conceptos que solo soportan uno o dos niveles de profundidad. Si tu web tiene una estructura más profunda debes escoger el concepto de navegación adecuado.

8. El menú solo debe contener la estructura de la información

   Si la función de búsqueda está en el menú, habrá personas a las que les costará encontrarla. Tampoco recomiendan que tengas que abrir el menú para cambiar de idioma.

9. La estructura de la información se ha estudiado detenidamente 

   Si la arquitectura de información del sitio es incorrecta o está desequilibrada, el concepto de navegación se vuelve irrelevante, pues la información será difícil de encontrar independientemente del mismo.

Layout y diseño

10. El menú tiene un diseño claro

    Trata la importancia de saber en qué página estás, en qué nivel de la estructura te encuentras y qué otras opciones hay al mismo nivel. O también aspectos como el diseño consistente o la delimitación clara de las diferentes zonas clicables.

11. Presentar el menú verticalmente

    Este punto no se aplica necesariamente al menú superior.

12. Áreas clicables suficientemente grandes

    Indican 9 mm medidos en la pantalla del dispositivo.

13. El menú es fácil de encontrar
14. El icono del menú más texto complementario (si hay icono de menú)

    Utiliza el icono de menú que los usuarios esperan encontrar y acompáñalo del texto "Menú".

15. El menú es de fácil acceso

    Debes poder acceder fácilmente al mismo cuando sostienes el teléfono con una sola mano.

16. Las opciones importantes del menú no están ocultas

    No se refiere al menú oculto tras un botón "menú”, medida eficaz si su ubicación y diseño es claro y que además permite poner el foco en el contenido. Se refiere a ocultar opciones de menú tras un enlace "Mostrar más". Muchos usuarios evitan hacer clic en este tipo de enlaces incluso si no encuentran lo que están buscando en las opciones visibles.

Contenido

17. Poner el foco en el contenido

    Lo prioritario de la página es el contenido, que confirma además si lo que estás buscando es esa página o si llegaste a la página correcta. El menú no debe ocupar toda la pantalla a menos que el usuario así lo haya elegido.

18. Los enlaces a las páginas importantes también están incluidos en el contenido

    Las preferencias de navegación varían: unos usuarios utilizan el menú, otros el buscador, y muchos hojean títulos y enlaces relevantes, evitando el menú y el buscador. Los enlaces deben ser claros, descriptivos y legibles, para lo cual ayuda que estén en líneas separadas.

Diseño técnico

19. El menú trabaja con el lector de pantalla
20. El menú puede ser usado con el teclado

    Además el orden de tabulación ha de ser lógico y el foco visible.

21. Puedes navegar incluso cuando javascript está desactivado

Preferencias de los usuarios

22. El menú admite diferentes tamaños de texto y fuentes

    Es decir, el usuario puede cambiar el tamaño de texto o las fuentes, mediante las opciones de personalización de su navegador o el sistema operativo, y el menú debe admitirlo y visualizarse correctamente.

23. El menú admite zoom

Artículos relacionados

• WCAG 2.0 Extensions. "WCAG Cognitive Extension", "WCAG Mobile Extension", y nueva versión de las WCAG 2.0
• Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes
• Accesibilidad y usabilidad móvil: web móvil y app nativa
• Claves para la web móvil

Ayer, 2 de diciembre de 2015, víspera del Día Internacional de las Personas con Discapacidad, la Comisión Europea ha propuesto la Ley Europea de Accesibilidad o European Accessibility Act, (.doc, 163 KB).

En 2011 la Comisión prometió que propondría esta ley para el año 2012, y desde entonces venía asegurando que la propuesta era inminente. Bien, pues al fin ha llegado.

Para evitar confusiones, creo que lo primero es recordar cuál es el procedimiento legislativo ordinario de la Unión Europea. Se puede resumir en que la Comisión Europea propone las iniciativas legislativas, es decir, los proyectos de las nuevas leyes de la Unión Europea, y el Parlamento Europeo y el Consejo son las que las adoptan, para lo que se requiere la aprobación de un mismo texto.

Hay una primera lectura por parte del Parlamento Europeo y del Consejo, que si es positiva en ambos casos, puede dar lugar a la aprobación directa de la propuesta. En caso contrario, puede haber una segunda y hasta una tercera lectura, donde se van teniendo en cuenta las enmiendas propuestas. Al final se aprobará el texto definitivo de la propuesta legislativa o bien esta no se adoptará. Si se aprueba el texto definitivo, lo firmarán ambas instituciones y se publicará en el DOUE (Diario Oficial de la Unión Europea), adquiriendo a partir de ese momento carácter oficial.

Imagen "Procedimiento legislativo ordinario", web del Parlamento europeo (consultar transcripción textual)

Por tanto, estamos en el comienzo del proceso, y llevará su tiempo (la primera lectura se puede prolongar más de un año). Para hacernos una idea, la directiva relativa a la accesibilidad de los sitios web de los organismos del sector público (Proposal for a DIRECTIVE OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on the accessibility of public sector bodies' websites) se presentó en diciembre de 2012 y se sigue debatiendo (ver estado del proceso). Pero dado que el procedimiento legislativo solo puede dar comienzo a instancia de la Comisión, y ninguna otra institución puede presentar una propuesta para su consideración por el Parlamento o el Consejo, es una gran noticia que por fin se haya presentado la propuesta.

Una directiva indicará los resultados que deben conseguirse en los Estados miembro, pero deja a los gobiernos nacionales la decisión de cómo adaptar sus legislaciones para ello. En cada directiva se especifica la fecha en la que deben adaptarse las leyes nacionales, en la que nos ocupa se establecen los siguientes plazos:

Member States shall adopt national rules to transpose the Directive within two years after it enters into force. Those provisions should become applicable within an additional period of four years. This means six years after its entry into force, it will be applicable in all Member States

A continuación incluyo un extracto de la nota de prensa que ha publicado hoy la Comisión Europea, que resume brevemente la parte introductoria de la propuesta:

Los productos y servicios han sido cuidadosamente seleccionados en consulta con los ciudadanos, las organizaciones de la sociedad civil y las empresas. Entre ellos se incluyen los cajeros automáticos y servicios bancarios, los ordenadores personales, los teléfonos y equipos de televisión, los servicios de telefonía y audiovisuales, el transporte, los libros electrónicos y el comercio electrónico

La Directiva propuesta tiene el objetivo de mejorar el funcionamiento del mercado interior, facilitando el que las empresas proporcionen productos y servicios accesibles a través de las fronteras. También se aplicarán requisitos comunes de accesibilidad en las normas de contratación de la UE y la utilización de los fondos europeos. La iniciativa estimulará la innovación e incrementará la oferta de productos y servicios accesibles para las personas con discapacidad (alrededor de ochenta millones) que viven en la UE.

Se ha puesto especial atención en garantizar la proporcionalidad de los requisitos, en particular para las pequeñas empresas y microempresas. Hay cláusulas de salvaguardia para que los requisitos de accesibilidad no impongan una carga excesiva, y las medidas de cumplimiento para las microempresas son menos rigurosas. La experiencia muestra que, en la mayoría de los casos, es rentable económicamente suministrar productos accesibles, en particular, cuando la accesibilidad se prevé en la fase de diseño.

[...]

La ley europea de accesibilidad hará que sea más fácil para los fabricantes y los proveedores de servicios exportar productos y servicios que cumplan los requisitos de la UE, ya que no tendrán necesidad de adaptarse a normas nacionales divergentes.

[...]

La Convención de las Naciones Unidas sobre los Derechos de las Personas con Discapacidad contiene obligaciones en materia de accesibilidad. En ella se exige que las Partes, como la UE y los Estados miembros, tomen las medidas necesarias, incluida la legislación, para garantizar la accesibilidad. Sin una intervención de la UE, cada país de la Unión continuará adoptando legislaciones diferentes para cumplir sus obligaciones, lo que implicará una fragmentación cada vez mayor del mercado de la UE.

[...]

La UE ratificó en 2011 la Convención de las Naciones Unidas sobre los Derechos de las Personas con Discapacidad, que trata la discapacidad como una cuestión de derechos humanos, y no desde una perspectiva médica o de caridad.

[...]

El artículo 9 de la Convención establece las obligaciones de accesibilidad de los Estados miembros, que deben asegurar el acceso de las personas con discapacidad en igualdad de condiciones con las demás.

Todos los Estados miembros han firmado la Convención y veinticinco de ellos la han ratificado. Irlanda, Países Bajos y Finlandia están preparando su ratificación. Esto significa que la UE y los Estados miembros Partes se han comprometido a promover y proteger los derechos de las personas con discapacidad consagrados en la Convención de las Naciones Unidas, dentro de sus respectivas competencias.

Extracto de la nota de prensa: "La Comisión propone hacer más accesibles los productos y los servicios para las personas con discapacidad", Comisión europea -comunicado de prensa, 2-12-2015

También se puede consultar el vídeo y la transcripción de la presentación que ha hecho la comisaria Marianne Thyssen: "Press remarks by Employment, Social Affairs and Labour Mobility Commissioner Marianne Thyssen on the European Accessibility Act", European Commission - Speech, 2-12-2015.

Accessibility Act proposal

La propuesta de ley es pública, es un documento Word de 49 páginas: Accessibility Act proposal (.doc, 163 KB). Este documento tiene tres anexos donde se incluyen los requisitos, y que comentaré más adelante.

En la parte introductoria se hace referencia a que las diferencias legislativas de los Estados miembro en relación con la accesibilidad, como referenciar a diferentes versiones de las WCAG, crean barreras en el mercado interior.

También se indica que los fabricantes y proveedores de servicios utilizan diferentes enfoques para cumplir con los requisitos de accesibilidad, basados a veces en normas nacionales, otras en normas internacionales, sin que haya armonización de normas entre las regiones y países. En este sentido señala normas que se han desarrollado a nivel europeo como la EN 301 549, de la que hablé en el artículo: EN 301 549: primera norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC)

Se indica además que ha de ser coherente con la legislación de EEUU, dado el carácter global de algunos productos y servicios.

Los requisitos son de carácter general y basados en la funcionalidad. La directiva indica qué características deben cumplir los productos y servicios, pero no entra en los detalles técnicos específicos de las soluciones.

La presente directiva debe hacer obligatoria la utilización de los requisitos de accesibilidad funcionales en términos de objetivos generales. Estos deben ser lo suficientemente precisos para crear obligaciones jurídicamente vinculantes y lo suficientemente detallados como para que sea posible evaluar la conformidad.

Como se indicaba en la nota de prensa, se recoge la excepción por "carga desproporcionada", concretamente se trata en el capítulo 3, artículo 12. Para evaluar si el cumplimiento de los requisitos de accesibilidad impone una carga desproporcionada, se tendrá en cuenta el tamaño, los recursos y la naturaleza del agente, los costes estimados y los beneficios en relación con el beneficio para las personas con discapacidad, teniendo en cuenta la frecuencia y la duración del uso del producto o servicio. Sin embargo no se considerará desproporcionada cuando se compense mediante la financiación pública o privada. Si utilizan esta excepción deberán notificarla (están exentas las microempresas) a la autoridad de vigilancia donde se comercializa.

En el capítulo 4, artículo 13, se indica que los productos y servicios que sean conformes con las normas armonizadas, o partes de las mismas, cuyas referencias se hayan publicado en el Diario Oficial de la Unión Europea, gozarán de la presunción de estar en conformidad con los requisitos de accesibilidad que cubren dichas normas o partes de las mismas, de las referidas en el artículo 3.

En el artículo 15 se trata la declaración UE de conformidad, que afirmará que se ha demostrado el cumplimiento de los requisitos de accesibilidad pertinentes contemplados en el artículo 3. Cuando se ha utilizado la excepción prevista en el artículo 12 ("carga desproporcionada"), se hará constar en la declaración UE de conformidad que los requisitos de accesibilidad están sujetos a esa excepción. Se indica que los requisitos relativos a la documentación técnica evitarán imponer una carga desproporcionada para las microempresas, pequeñas y medianas empresas; y que dicha documentación se traducirá a la lengua o las lenguas requeridas por el Estado miembro del mercado donde el producto se introduzca.

En el artículo 1 se recoge qué productos y servicios alcanza:

• general purpose computer hardware and operating systems;
• the following self-service terminals:
  • Automatic Teller Machines;
  • ticketing machines;
  • check-in machines.
• consumer terminal equipment with advanced computing capability related to telephony services;
• consumer terminal equipment with advanced computing capability related to audio-visual media services.
• telephony services and related consumer terminal equipment with advanced computing capability;
• audiovisual media services and related consumer equipment with advanced computing capability;
• air, bus, rail and waterborne passenger transport services;
• banking services;
• e-books;
• e-commerce.
• public contracts and concessions which are subject to Directive 2014/23/EU Directive 2014/24/EU and Directive 2014/25/EU.
• the preparation and implementation of programmes under Regulation (EU) No 1303/2013 of the European Parliament and of the Council laying down common provisions on the European Regional Development Fund, the European Social Fund, the Cohesion Fund, the European Agricultural Fund for Rural Development and the European Maritime and Fisheries Fund; and Regulation (EU) No 1304/2013 of the European Parliament and of the Council.
• tender procedures for public passenger transport services by rail and by road under Regulation (EC) No 1370/2007 of the European Parliament and of the Council.
• transport infrastructure in accordance with Regulation (EU) No 1315/2013 of the European Parliament and of the Council.

Anexo I

Descarga: Annex I to the Proposal for a European Accessibility Act

En el anexo I se listan los requisitos para cada uno de los productos y servicios que abarca la directiva.

Por ejemplo, la sección VI para "Banking services; websites used for provision of banking services; mobile device-based banking services; self-service terminals, including Automatic Teller machines used for provision of banking services" dice así:

A. Services in general:

1. The provision of services in order to maximise their foreseeable use by persons with functional limitations, including persons with disabilities, shall be achieved by:

(a) ensuring the accessibility of the products they use in the provision of the service, in accordance with the rules laid down in point D:

(b) providing information about the functioning of the service and about its accessibility characteristics and facilities as follows:

(i) the information content shall be available in text formats that can be used to generate alternative assistive formats to be presented in different ways by the users and via more than one sensory channel,

(ii) alternatives to non-text content shall be provided;

(iii) the electronic information, including the related online applications needed in the provision of the service shall be provided in accordance with point (c).

(c) making websites accessible in a consistent and adequate way for users’ perception, operation and understanding, including the adaptability of content presentation and interaction, when necessary providing an accessible electronic alternative; and in a way which facilitates interoperability with a variety of user agents and assistive technologies available at Union and international level;

(d) including functions, practices, policies and procedures and alterations in the operation of the service targeted to address the needs of persons with functional limitations.

B. Websites used for provision of banking services:

The provision of services in order to maximise their foreseeable use by persons with functional limitations, including persons with disabilities, shall be achieved by:

(a) making websites accessible in a consistent and adequate way for users’ perception, operation and understanding, including the adaptability of content presentation and interaction, when necessary providing an accessible electronic alternative; and in a way which facilitates interoperability with a variety of user agents and assistive technologies available at Union and international level;

C. Mobile device-based banking services:

1. The provision of services in order to maximise their foreseeable use by persons with functional limitations, including persons with disabilities, shall be achieved by:

(a) providing information about the functioning of the service and about its accessibility characteristics and facilities as follows:

(i) the information content shall be available in text formats that can be used to generate alternative assistive formats to be presented in different ways by the users and via more than one sensory channel,

(ii) alternatives to non-text content shall be provided;

(iii) the electronic information, including the related online applications needed in the provision of the service shall be provided in accordance with point (b).

(b) making websites accessible in a consistent and adequate way for users’ perception, operation and understanding, including the adaptability of content presentation and interaction, when necessary providing an accessible electronic alternative; and in a way which facilitates interoperability with a variety of user agents and assistive technologies available at Union and international level;

D. Self-service terminals, including Automatic Teller machines used for provision of banking services:

1. Design and production:

The design and production of products in order to maximise their foreseeable use by persons with functional limitations, including persons with disabilities and those with age related impairments, shall be achieved by making accessible the following:

(a) the information on the use of the product provided in the product itself (labelling, instructions, warning), which:

(i) must be available by more than one sensory channel;

(ii) must be understandable;

(iii) must be perceivable;

(iv) shall have an adequate size of fonts in foreseeable use conditions;

(b) the user interface of the product (handling, controls and feedback, input and output) in accordance with point 2;

(c) the functionality of the product by providing functions aimed to address the needs of persons with functional limitations, in accordance with point 2;

(d) the interfacing of the product with assistive devices.

2. User interface and functionality design:

In order to make accessible the design of the products and their user interface as referred to in points (b) and (c) of point 1 they must be designed, where applicable, as follows:

(a) provide for communication and orientation via more than one sensory channel;

(b) provide for alternatives to speech for communication and orientation;

(c) provide for flexible magnification and contrast;

(d) provide for an alternative colour to convey information;

(e) provide for flexible ways to separate and control foreground from background including for reducing background noise and improve clarity;

(f) provide for user control of volume;

(g) provide for sequential control and alternatives to fine motor control;

(h) provide for modes of operation with limited reach and strength;

(i) provide avoidance of triggering photosensitive seizures.

Anexo II

Descarga: Annex II to the Proposal for a European Accessibility Act

Trata del procedimiento de la evaluación de la conformidad.

El control interno es el procedimiento de evaluación de conformidad mediante el cual el fabricante cumple las obligaciones establecidas en los puntos 2,3 y 4, y garantiza y declara, bajo su exclusiva responsabilidad, que los productos o servicios en cuestión satisfacen los requisitos pertinentes de la presente Directiva.

En el punto 2 se trata la documentación técnica:

El fabricante elaborará la documentación técnica. La documentación permitirá evaluar la conformidad del producto con los requisitos de accesibilidad pertinentes mencionados en el artículo 3 y, en el caso de que fabricante utilice la excepción prevista en el artículo 12, demostrará que los requisitos de accesibilidad pertinentes impondrían una alteración fundamental o una carga desproporcionada.

La documentación técnica tiene que contener al menos los siguientes elementos:

• una descripción general del producto
• una lista de las normas armonizadas y/u otras especificaciones técnicas pertinentes, cuyas referencias se hayan publicado en el Diario Oficial de la Unión Europea, aplicadas total o parcialmente, y la descripción de las soluciones adoptadas para cumplir con los requisitos contemplados en el Artículo 3 cuando no se hayan aplicado dichas normas armonizadas; en el caso de normas armonizadas parcialmente aplicadas, la documentación técnica especificará las partes que se hayan aplicado.

En el punto 4 se indica que el fabricante (o su representante autorizado) colocará el marcado CE en cada producto que satisfaga los requisitos aplicables de la presente Directiva; que redactará una declaración de conformidad para el producto; y una copia de la misma se pondrá a disposición de las autoridades competentes que lo soliciten.

Anexo III

Descarga: Annex III to the Proposal for a European Accessibility Act

En el artículo 11 de la directiva se dice:

Los proveedores de servicios deberán preparar la información necesaria de conformidad con el anexo III que explica cómo los servicios cumplen con los requisitos de accesibilidad a los que se refiere el artículo 3. La información se pondrá a disposición del público en formato escrito y oral, y en una forma que sea accesible para las personas con limitaciones funcionales y las personas con discapacidad, disponible mientras el servicio esté en funcionamiento.

El Anexo III al que hace referencia este artículo dice así:

El proveedor del servicio deberá incluir la información de la evaluación de cómo el servicio cumple con los requisitos de accesibilidad en los términos y condiciones generales, o un documento equivalente. La información deberá describir los requisitos aplicables y cubiertos, en la medida necesaria para la evaluación del diseño y el funcionamiento del servicio. Además de los requisitos de información al consumidor de la Directiva 2011/83 / UE del Parlamento Europeo y del Consejo 1, la información deberá, en su caso, contener los siguientes elementos:

• una descripción general del servicio en formatos accesibles;
• las descripciones y explicaciones necesarias para la comprensión del manejo del servicio;
• una descripción de cómo los requisitos de accesibilidad pertinentes establecidos en el anexo I son cumplidos por el servicio.

Para cumplir con el punto 1, el proveedor de servicios puede aplicar en su totalidad o en parte las normas armonizadas y/u otras especificaciones técnicas pertinentes, cuyas referencias se hayan publicado en el Diario Oficial de la Unión Europea.

El proveedor de servicios deberá proporcionar información que demuestre que el proceso de prestación de servicios y su supervisión garantizan la conformidad del servicio con el punto 1 y con los requisitos aplicables de la presente Directiva.

Enlaces de interés

• Propuesta de ley Accessibility Act proposal (.doc, 163 KB)
• Annex I to the Proposal for a European Accessibility Act
• Annex II to the Proposal for a European Accessibility Act
• Annex III to the Proposal for a European Accessibility Act
• Folleto de presentación de la propuesta de ley: Factsheet. European Accessibility Act
• Preguntas frecuentes de la propuesta de ley: Disabilities: proposal for an Accessibility Act - frequently asked questions
• Nota de prensa: Commission proposes to make products and services more accessible to the disabled persons, European Commission - Press release
• Presentación de la comisaria: Press remarks by Employment, Social Affairs and Labour Mobility Commissioner Marianne Thyssen on the European Accessibility Act
• Sobre la historia de la promesa de la Accessibility Act: European Accessibility Act: European Commission breaks promises, European Blind Union, 12-2-2015
• Explicación del procedimiento legislativo de la Unión Europea: "Procedimiento legislativo ordinario", web del Parlamento europeo

Artículos relacionados:

• EN 301 549: primera norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC)
• Legislación sobre accesibilidad web en España, Europa y otros países

1. ¿Qué es Accessibility Scanner?
2. Instalación y activación
3. Funcionamiento de la aplicación
4. Evaluación y resultados
5. Evaluar la accesibilidad de una app en Android

1. ¿Qué es Accessibility Scanner?

Accessibility Scanner es una app gratuita para Android que Google lanzó en marzo de este año.

Es el primer validador automático de accesibilidad para apps de Android y permite escanear cualquier aplicación que tengamos instalada en el móvil.

Su objetivo es ofrecer propuestas de mejora de accesibilidad para las aplicaciones, pero en ningún caso sustituye a una evaluación manual ni garantiza que una aplicación sea accesible.

Como veremos, no valida de acuerdo a una norma concreta, solo evalúa automáticamente un número reducido de aspectos relacionados con la accesibilidad de la aplicación. A pesar de ello puede ser una ayuda muy útil.

Actualmente solo está disponible en inglés y solo para móviles y tablets con Android 6.0 o superior. No requiere ningún permiso especial para su instalación.

2. Instalación y activación

Instalamos la aplicación desde Google Play Store.

La primera pantalla muestra un botón “Get started” que nos pide permiso para abrir la pantalla "Ajustes > Accesibilidad" de Android.

En "Ajustes > Accesibilidad" ha aparecido una opción "Accessibility Scanner" que permite activar y desactivar la herramienta. Si la activamos nos avisa de las acciones que va a llevar a cabo y nos pide permiso para capturar pantallas:

Una vez activada la herramienta tendremos siempre visible en pantalla un botón azul que podemos arrastrar para situar en cualquier zona de la pantalla:

A partir de este momento solo hay que abrir la aplicación que queremos evaluar y pulsar ese botón.

También se crea un acceso directo a la aplicación:

La primera vez que accedemos a la aplicación a través de este enlace se nos informa de cómo usarla:

Las siguientes veces tendremos el histórico de todas las evaluaciones que hemos realizado:

En la esquina superior derecha está el icono de menú (tres puntos verticales), pero este solo contiene un enlace a la ayuda.

3. Funcionamiento de la aplicación

El funcionamiento de la herramienta es muy sencillo. Solo hay que abrir la aplicación que queremos evaluar, por ejemplo Twitter, y pulsar el botón azul flotante que está siempre presente si la herramienta está activada.

Al pulsar el botón se realiza el escáner de la aplicación. En un pantallazo de la misma se resaltan los elementos que han dado error:

En esta pantalla podemos hacer 4 acciones:

1. Ir al listado completo de sugerencias

Pulsando el icono:

En el listado, el elemento que ha provocado el error está identificado mediante su ID. Se informa del tipo de error y una flecha permite mostrar más información como el enlace de ayuda.

2. Ver las sugerencias una a una

Si se pulsa en uno de los elementos resaltados de la captura, se accede a la vista de sugerencias una a una.

En esta vista es más fácil identificar a qué elemento hace referencia cada sugerencia, ya que incluye un slide con la captura del elemento resaltado.

Un mismo elemento puede tener varias sugerencias:

3. Compartir los resultados

Pulsando el icono:

Permite enviarlos por SMS o por correo. En este caso recibes un correo con el listado y descripción de las sugerencias y el pantallazo de la captura.

4. Volver a la pantalla principal

Pulsando el icono:

Permite volver a la pantalla inicial con el histórico de evaluaciones.

4. Evaluación y resultados

La herramienta evalúa los siguientes aspectos:

1. Etiquetado del contenido

El error se describe de la siguiente manera:

Item label

com.twitter.android:id/profile_header

This item may not have a label readable by screen readers.

En ese ejemplo, el elemento que ha dado error es el que tiene el ID profile_header.

Las etiquetas de los elementos interactivos no se presentan visualmente, pero son leídas por TalkBack u otros lectores de pantalla, por ello son tan relevantes.

La herramienta busca los siguientes errores:

1.1 Elementos que pueden coger el foco pero no tienen una etiqueta

La etiqueta se incluye con android:contentDescription. Debería incluirse en ImageButton, ImageView, Checkbox y otros controles que requieran información adicional.

Ejemplo:

<ImageButton

android:id=”@+id/add_note_button”

android:src=”@drawable/add_note”

android:contentDescription=”@string/add_note”/>

Para los campos de texto se incluye el atributo android:hint en vez de la descripción. El atributo android:hint será leído cuando el campo esté vacío, ayudando así a comprender qué tipo de contenido se espera en el campo. Hay que tener en cuenta que cuando el usuario rellene el campo TalkBack leerá el texto introducido por el usuario.

1.2 Elementos con etiquetas redundantes

Es decir, etiquetas en las que se indica el tipo o el estado. Por ejemplo daría error que la etiqueta de un botón incluya el texto “button”, puesto que el lector de pantalla ya anuncia que es un botón; o por ejemplo que en la etiqueta de un check se indique su estado (“checked”).

Como la herramienta solo está en inglés, si la descripción del botón es “Botón que envía el formulario” no da error, aunque la etiqueta adecuada sería “Enviar el formulario”.

1.3 Etiquetas duplicadas

Por ejemplo, dos botones con la misma descripción “Más opciones”.

2. Contraste de color del texto y las imágenes

Se evalúa basándose en las recomendaciones del W3C. Es decir, el texto pequeño debe tener al menos un contraste de 4.5:1 y el texto grande (14pt negrita o 18pt normal) un contraste al menos de 3:1.

El error se describe de la siguiente manera:

Text contrast

com.twitter.android:id/button_edit_profile

The item's text contrast ratio is 2,94. This ratio is based on an estimated foreground color of #8899A6 and an estimated background color of #FFFFFF. Consider increasing this item's text contrast ratio to 3,00 or greater.

Image contrast

com.twitter.android:id/composer_write

The image's contrast ratio is 2,83. This ratio is based on an estimated foreground color of #FFFFFF and an estimated background color of #1DA1F2. Consider increasing this ratio to 3,00 or greater.

3. Tamaño de los elementos interactivos

Se evalúa si tienen al menos 48dp de alto.

El error se describe de la siguiente manera:

Touch target

com.twitter.android:id/button_edit_profile

This item's height is 36dp. Consider making the height of this touch target 48dp or larger. A parent container may be handling touch events for this item. If selecting the larger container performs the same action as selecting this item, consider defining this item as not clickable. If a different action is performed, consider increasing the size of this item.

5. Evaluar la accesibilidad de una app en Android

Como vemos, no son muchos los aspectos que evalúa y no puede sustituir a una evaluación manual, aunque sin duda puede ser una herramienta muy práctica.

Para ayudar a evaluar manualmente una app tenemos diferentes documentos, uno bastante útil es Accessibility Developer Checklist que incluye:

• Accessibility Requirements:

1. Describe user interface controls.
2. Enable focus-based navigation.
3. Custom view controls.
4. No audio-only feedback.
5. Test.

1. Android Design Accessibility Guidelines.
2. Framework-provided controls.
3. Temporary or self-hiding controls and notifications.

1. Text field hints for EditText.
2. Custom controls with high visual context.
3. Custom controls and click handling.
4. Controls that change function.
5. Prompts for related controls.
6. Video playback and captioning.
7. Supplemental accessibility audio feedback.
8. Custom controls with complex visual interactions.
9. Sets of small controls.
10. Decorative images and graphics.

Otros documentos de interés de developer.android.com y Google son:

• Accessibility Testing Checklist
• Android >Design > Accessibility
• Making Applications Accessible
• Building Accessibility Services
• Google Accessibility
• Google Material Design Accessibility

Artículos relacionados:

• Accesibilidad y usabilidad móvil: web móvil y app nativa
• Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.
• Pautas de usabilidad y accesibilidad móvil. "Accesible Mobile Interfaces" y "Mobile Navigation" de Funka
• WCAG 2.0 Extensions. "WCAG Cognitive Extension", "WCAG Mobile Extension", y nueva versión de las WCAG 2.0
• aXe Rules, Google ADT Rules y el Mobile Web Accessibility Checker

Resumen:

El objetivo de este artículo es repasar y comparar:

• dos conjuntos de reglas de validación automática de accesibilidad web: las aXe Rules de Deque y las Google ADT Rules, y su relación con las WCAG 2.0;
• las herramientas de validación automática que las utilizan:
• aXe Extension, que usa las aXe Rules,
• Google Accessibility Developer Tool, que utiliza las Google ADT Rules,
• la app para iPhone y iPad, Mobile Web Accessibility Checker, que permite evaluaciones de varios sitios y múltiples páginas con ambas reglas, las aXe Rules y las Google ADT Rules.

Índice:

• aXe Rules
• aXe Extensions
• Google ADT Rules
• Google ADT Extension
• Comparativa aXe vs Google ADT
• app Mobile Web Accessibility Checker

aXe Rules

aXe (The Accessibility Engine) es una librería portable JavaScript open source de 100 KB desarrollada por la empresa americana Deque.

Ejecuta una evaluación automática de accesibilidad de páginas web integrada en el navegador, mediante una extensión, o integrada en el framework de testeo (Karma, Jasmine, Mocha, QUnit, etc.). La evaluación es inmediata y no hay límite de uso diario.

Su filosofía es que las pruebas sean automáticas y no puedan dar falsos positivos.

La API soporta IE, Chrome, Firefox y Safari. Las extensiones disponibles son para Chrome y Firefox.

Listado de las aXe Rules

Las aXe Rules son las reglas de validación automática que utiliza aXe. La primera versión, las aXe 1.0, eran 45 reglas.

En julio de 2016 se actualizaron y actualmente las aXe Rules 2.0 son 54.

Se pueden consultar en:

• Listado de reglas con enlace a su detalle (deque academy). En el detalle de cada regla se incluye la descripción, la criticidad, la normativa relacionada (por ejemplo en el caso de las WCAG 2.0 las técnicas y criterios relacionados), las tecnologías relacionadas (HTML4, HTML5, Aria, JavaScript), enlaces de interés, etc.
• Tabla resumen (github). En esta tabla, por cada regla, se informa de su ID, su descripción, la normativa y criterios asociados, y si la evaluación de esa regla está activa por defecto.

A continuación incluyo el listado de las aXe Rules, y por cada una, la información relevante cuando se está haciendo una evaluación de acuerdo a las WCAG 2.0, esto es, las técnicas y criterios asociados:

accesskeys
Ensures every accesskey attribute value is unique

• Criterios: 2.1.1 A
• Técnicas: no se indican. Nota mía: en realidad hay una pero es additional (no sufficient) y no está desarrollada.

applet*
<applet> elements should have alternate text

• Criterios: no se indican.
• Técnicas: H18. Nota mía: actualmente esta técnica se ha eliminado de la documentación de las WCAG 2.0.

* Esta regla se incluye en el listado con detalle pero no en la tabla resumen de github

area-alt
Ensures <area> elements of image maps have alternate text

• Criterios:1.1.1 A
• Técnicas: F65; H24

aria-allowed-attr
Ensures ARIA attributes are allowed for an element's role

• Criterios: 4.1.1 A ; 4.1.2 A
• Técnicas: no se indican. Nota mía: en realidad esta regla,- y las siguientes reglas ARIA sin técnicas asociadas-, estarían relacionadas con las técnicas generales asociadas a estos criterios sobre usar HTML válido y de acuerdo a la especificación.

aria-required-attr
Ensures elements with ARIA roles have all required ARIA attributes

• Criterios: 4.1.1 A; 4.1.2 A
• Técnicas: no se indican

aria-required-children
Ensures elements with an ARIA role that require child roles contain them

• Criterios: 1.3.1 A
• Técnicas: no se indican

aria-required-parent
Ensures elements with an ARIA role that require parent roles are

• Criterios: 4.1.1 A; 4.1.2 A
• Técnicas: no se indican

aria-roles
Ensures all elements with a role attribute use a valid value

• Criterios: 4.1.1 A; 4.1.2 A; 1.3.1 A
• Técnicas: no se indican

aria-valid-attr-value
Ensures all ARIA attributes have valid values

• Criterios: 4.1.1 A; 4.1.2 A; 1.3.1 A
• Técnicas: no se indican

aria-valid-attr
Ensures attributes that begin with aria- are valid ARIA attributes

• Criterios: 4.1.1 A
• Técnicas: no se indican

audio-caption
Ensures <audio> elements have

• Criterios: 1.2.2 A
• Técnicas: G158

blink
Ensures <blink> elements are not used

• Criterios: 2.2.2 A
• Técnicas: F47

button-name
Ensures buttons have discernible text

• Criterios: 4.1.2 A
• Técnicas: no se indican. Nota mía: aunque no nombran ninguna está relacionada con varias técnicas ARIA y HTML de este criterio.

bypass
Ensures each page has at least one mechanism for a user to bypass navigation and jump straight to the content

• Criterios: 2.4.1 A
• Técnicas: G1; H69; ARIA11

checkboxgroup
Ensures related <input type="checkbox"> elements have a group and that that group designation is consistent

• Criterios: 1.3.1 A
• Técnicas: H71; ARIA17

color-contrast
Ensures the contrast between foreground and background colors meets WCAG 2 AA contrast ratio thresholds

• Criterios: 1.4.3 AA
• Técnicas: G18

definition-list
Ensures <dl> elements are structured correctly

• Criterios: 1.3.1 A
• Técnicas: H40; H48

dlitem
Ensures <dt> and <dd> elements are contained by a <dl>

• Criterios: 1.3.1 A
• Técnicas: H40; H48

document-title
Ensures each HTML document contains a non-empty <title> element

• Criterios: 2.4.2 A
• Técnicas: H25

duplicate-id
Ensures every id attribute value is unique

• Criterios: 4.1.1 A
• Técnicas: F77

empty-heading
Ensures headings have discernible text

• Criterios: 1.3.1 A
• Técnicas: G130; ARIA12

frame-title
Ensures <iframe> and <frame> elements contain a unique and non-empty title attribute

• Criterios: 4.1.2 A
• Técnicas: H64

heading-order
Ensures the order of headings is semantically correct

No lo asocian a ningún criterio ni técnica y le da un criticidad mínima.

href-no-hash *
Ensures that href values are valid link references to promote only using anchors as links

No lo asocian a ningún criterio ni técnica.

* Esta regla se incluye en la tabla resumen de github pero no está en el listado con detalle.

html-has-lang
Ensures every HTML document has a lang attribute

• Criterios: 3.1.1 A
• Técnicas: H57

html-lang-valid
Ensures the lang attribute of the <html> element has a valid value

• Criterios: 3.1.1 A
• Técnicas: H57

image-alt
Ensures <img> elements have alternate text or a role of none or presentation

• Criterios: 1.1.1 A
• Técnicas: F65; H37; H67; ARIA10

image-redundant-alt
Ensure button and link text is not repeated as image alternative

• Criterios: 1.1.1 A
• Técnicas: F65; H36

input-image-alt
Ensures <input type="image"> elements have alternate text

• Criterios: 1.1.1 A
• Técnicas: F65; H36

label-title-only
Ensures that every form element is not solely labeled using the title or aria-describedby attributes

No lo asocian a ningún criterio ni técnica pero le dan una criticidad importante.

label
Ensures every form element has a label

• Criterios: 1.3.1 A; 3.3.2 A
• Técnicas: F68; H44; ARIA16; ARIA14; H65

layout-table
Ensures presentational <table> elements do not use <th>, <caption> elements or the summary attribute

• Criterios: 1.3.1 A
• Técnicas: F46

link-in-text-block
Links can be distinguished without relying on color

• Criterios: 1.4.3 AA
• Técnicas: G18

link-name
Ensures links have discernible text

• Criterios: 1.1.1 A; 4.1.2 A
• Técnicas: H30; F89; ARIA7

list
Ensures that lists are structured correctly

• Criterios: 1.3.1 A
• Técnicas: H48

listitem
Ensures <li> elements are used semantically

• Criterios: 1.3.1 A
• Técnicas: H48

marquee
Ensures <marquee> elements are not used

• Criterios: 2.2.2 A
• Técnicas: F16

meta-refresh
Ensures <meta http-equiv="refresh"> is not used

• Criterios: 2.2.1 A; 2.2.4 AAA; 3.2.5 AAA
• Técnicas: H76; F41

meta-viewport-large
Ensures <meta name="viewport"> can scale a significant amount

• Criterios: 1.4.4 AA
• Técnicas: no se indican

meta-viewport
Ensures <meta name="viewport"> does not disable text scaling and zooming

• Criterios: 1.4.4 AA
• Técnicas: no se indican

object-alt
Ensures <object> elements have alternate text

• Criterios: 1.1.1 A
• Técnicas: H53

radiogroup
Ensures related <input type="radio"> elements have a group and that the group designation is consistent

• Criterios: 1.3.1 A
• Técnicas: H71; ARIA17

region
Ensures all content is contained within a landmark region

• Criterios: 2.4.1 A; 3.2.3 AA
• Técnicas: ARIA11

scope-attr-valid
Ensures the scope attribute is used correctly on tables

• Criterios: 4.1.1 A; 1.3.1 A
• Técnicas: no se indican. Nota mía: no se indica la técnica pero sería la H63.

server-side-image-map
Ensures that server-side image maps are not used

• Criterios: 2.1.1 A
• Técnicas: no se indican.

skip-link
Ensures the first link on the page is a skip link

• Criterios: 2.4.1
• Técnicas: G1

tabindex
Ensures tabindex attribute values are not greater than 0

• Criterios: 2.4.3 A
• Técnicas: F44

table-duplicate-name
Ensure that tables do not have the same summary and caption

• Criterios: 1.3.1 A
• Técnicas: H39; H43; H51; H63; H73

table-fake-caption
Ensure that tables with a caption use the <caption> element.

• Criterios: 1.3.1 A
• Técnicas: H39; H43; H51; H63; H73

td-has-header
Ensure that each non-empty data cell in a large table has one or more table headers

• Criterios: 1.3.1 A
• Técnicas: H43; H51; H63; H73

td-headers-attr
Ensure that each cell in a table using the headers refers to another cell in that table

• Criterios: 1.3.1 A
• Técnicas: H43; H51; H63; H73

th-has-data-cells
Ensure that each table header in a data table refers to data cells

• Criterios: 1.3.1 A
• Técnicas: H43; H51; H63; H73

valid-lang
Ensures lang attributes have valid values

• Criterios: 3.1.1 A; 3.1.2 AA
• Técnicas: H58

video-caption
Ensures <video> elements have captions

• Criterios: 1.2.2 A; 1.2.3 AAA
• Técnicas: G87; G93

video-description
Ensures <video> elements have audio descriptions

• Criterios: 1.2.5 AA
• Técnicas: G8 ; G78

aXe Extensions

Hay dos extensiones "oficiales" para navegadores que utilizan aXe (The Accessibility Engine) y una “no oficial”:

• Chrome:aXe Extension for Chrome (oficial), actualmente la versión 2.0, actualizada el 13 de julio de 2016, y a11yChromePlugin (no oficial)
• Firefox: aXe Developer Tools, actualmente la versión 1.0.2, actualizada en agosto de 2016.

Todas ellas están en inglés.

En el caso de la extensión oficial de Chrome, una vez instalada, en la ventana de “Herramientas de desarrolladores” aparece una nueva pestaña “aXe” que simplemente incluye el botón “Analyze” para analizar la página que estás visualizando.

aXe Extension. Pestaña "aXe" de "Herramientas de desarrolladores" de Chrome

Los resultados se muestran de la siguiente manera:

aXe Extension. Resultados del análisis de accesibilidad.

En la zona izquierda se incluye el listado de errores y, por cada uno de ellos, el número de veces que se ha encontrado en la página.

Al pulsar en un tipo de error del listado izquierdo, en la zona derecha se muestra la descripción del error que consta de los siguientes elementos:

• Paginación entre los errores de un mismo tipo.
• Relevancia del error. Cada tipo de error tiene asignada por defecto una criticidad que no depende de la página analizada. En el detalle de cada tipo error se puede consultar su criticidad.
• Breve descripción del tipo de error y enlace a su página de detalle.
• Normativa relacionada. Por ejemplo, en el caso anterior "wcag2a2 (significa WCAG 2.0 criterio de conformidad A) y "wcag242" (significa criterio 2.4.2 de las WCAG 2.0). Es una lástima que no incluyan las técnicas asociadas, que como hemos visto sí las tienen en la documentación; o que no incluyan más información sobre el criterio asociado, podrían incluir su nombre y nivel.
• Botón “Inspect”: abre la pestaña “Elements” de “Herramientas de desarrolladores” con el elemento que ha dado el error resaltado.
• Otra información sobre el error: elemento o id del elemento que ha dado error, HTML del error y el resumen del error.

El validador está bien para validar automáticamente criterios y técnicas concretas de las WCAG 2.0 y realiza muchas validaciones. Sin embargo, a los evaluadores con poca experiencia les puede parecer menos práctico que otros validadores que listan todos los criterios de las WCAG 2.0, que indican cuáles han evaluado y cuáles debes evaluar manualmente, o que incluyen más información sobre los criterios y las técnicas.

Google ADT Rules

Google Accessibility Developer Tool es una extensión de Google para Chrome que permite realizar una validación automática de la página que se está visualizando en el navegador.

Listado de las Google ADT Rules

Las reglas de validación automática que utiliza Google ADT son 29, por tanto 25 menos que las aXe Rules (que son 54).

Se pueden consultar en:

• Listado de reglas (github). Incluye el listado, descripción detallada y ejemplo de cada regla.
• Relación de reglas y criterios de las WCAG 2.0 (github). Esta información se queda muy pobre puesto que solo incluye tres criterios y su relación con tres de las reglas, cuando en realidad cubre más criterios y hay más reglas relacionadas con ellos.

A continuación incluyo un listado de las reglas y su relación con las WCAG 2.0, completada en este caso por mí, puesto que como he comentado, su documentación es muy pobre en este aspecto:

AX_ARIA_01
Elements with ARIA roles must use a valid, non-abstract ARIA role

Las reglas ARIA están relacionadas fundamentalmente con los criterios 4.1.1 y 4.1.2. Estas reglas ARIA también se validan en las aXe Rules. Se resumen en que el documento esté bien formado y se apliquen correctamente los roles y atributos. Sin embargo en las Google ADT se especifican algunas reglas de manera más concreta.

AX_ARIA_02
aria-labelledby attributes should refer to an element which exists in the DOM

AX_ARIA_03
Elements with ARIA roles must have all required attributes for that roleElements with ARIA roles must use a valid, non-abstract ARIA role

AX_ARIA_04
ARIA state and property values must be valid

AX_ARIA_05
role=main should only appear on significant elements

Relacionada con los criterios 1.3.1 y 2.4.1, y con la técnica ARIA 11. Aunque en las aXe Rules también hay validaciones relacionadas con los landmark roles, no se específica en concreto esta validación.

AX_ARIA_06
aria-owns should not be used if ownership is implicit in the DOM

AX_ARIA_07
An element's ID must not be present in more than one aria-owns attribute at any time

AX_ARIA_08
Elements with ARIA roles must ensure required owned elements are present

AX_ARIA_09
Elements with ARIA roles must be in the correct scope

AX_ARIA_10
This element has an unsupported ARIA attribute

AX_ARIA_11
This element has an invalid ARIA attribute

AX_ARIA_12
This element does not support ARIA roles, states and properties

AX_ARIA_13
A tabpanel should be related to a tab via aria-controls or aria-labelledby

AX_AUDIO_01
Audio elements should have controls

No se detalla más y es bastante genérica.

AX_HTML_01
The web page should have the content's human language indicated in the markup

Relacionada con el criterio 3.1.1 y la técnica H57. También se valida en las aXe Rules.

AX_HTML_02
An element's ID must be unique in the DOM

Relacionada con el criterio 4.1.1 y el fallo común F77. También se valida en las aXe Rules.

AX_TEXT_01
Controls and media elements should have labels

Relacionada con el criterio 3.3.2. También se valida en las aXe Rules.

AX_TEXT_02
Images should have an alt attribute, unless they have an ARIA role of "presentation"

Relacionada con el criterio 1.1.1. También se valida en las aXe Rules.

AX_TEXT_03
Labels should only contain one labelable element

AX_TEXT_04
The purpose of each link should be clear from the link text

Relacionada con los criterio 2.4.4 y 2.4.9, pero no se da más información al respecto. En las aXe Rules se valida concretamente que no haya nombres de enlaces repetidos.

AX_TITLE_01
The web page should have a title that describes topic or purpose

Relacionada con el criterio 2.4.2. También se valida en las aXe Rules.

AX_IMAGE_01
Meaningful images should not be used in element backgrounds

Relaciona con el criterio 1.1.1, con la técnica C9 o con el fallo común F3.

AX_FOCUS_01
These elements are focusable but either invisible or obscured by another element

Relacionada con el criterio 2.4.7. En las aXe Rules no se específica que se valide este aspecto.

AX_FOCUS_02
Elements with onclick handlers must be focusable

Relacionada con el criterio 2.1.1. En las aXe Rules no se específica que se valide este aspecto.

AX_FOCUS_03
Avoid positive integer values for tabIndex

Relacionada con el criterio 2.4.3 y el fallo común F44. También se valida en las aXe Rules.

AX_COLOR_01
Text elements should have a reasonable contrast ratio

Relacionada con el criterio 1.4.3. También es validado por las aXe Rules.

AX_VIDEO_01
Video elements should use <track> elements to provide captions

Relacionada con los criterios 1.2.2 y 1.2.3. También es validado por las aXe Rules.

AX_TABLE_01
Tables must have appropriate headers

Relacionada con el criterio 1.3.1. También es validado por las aXe Rules.

AX_TOOLTIP_01
Elements with role=tooltip should have a corresponding element with aria-describedby

Relacionada con el criterio 1.1.1. En las aXe Rules no se específica que se valide este aspecto.

Google ADT Extension

Una vez instalada la extensión Google Accessibility Developer Tool en Chrome, en la pestaña "Audits" de "Herramientas de desarrolladores" se incluye la opción de evaluar la accesibilidad de la página que se está visualizando en el navegador:

Google ADT. Pestaña Audits.

Los resultados se muestran en un listado en forma de árbol donde se pueden encontrar diferentes tipos de mensajes: errores, no aplicados y correctos:

Google ADT. Resultados de la pestaña Audits>Accessibility.

Cada mensaje de error incluye:

• descripción breve y el número de veces que aparece en la página,
• enlace "más información" que enlaza con el listado de reglas de github,
• código donde se ha localizado el error (si te colocas sobre el mismo se resalta el elemento en la página).

Por tanto, la información que se ofrece es muy pobre. Tienes que acceder a la documentación para averiguar más sobre la regla y no se incluye información sobre su relación con los criterios o técnicas de las WCAG 2.0, lo cual resulta poco práctico cuando estás realizando una consultoría en base a las WCAG 2.0.

Comparativa aXe vs Google ADT

Como hemos visto, las aXe Rules son 54 y las Google ADT Rules 29. Además, la mayor parte de las Google ADT Rules están incluidas en las aXe Rules, aunque hay algunas excepciones señaladas mi listado de las Google ADT Rules.

En la documentación, la descripción propiamente de la regla es más detallada en las Google ADT Rules y suele incluir ejemplos de códigos correctos e incorrectos. Sin embargo, en las aXe Rules se ofrece mucha más información por cada regla: las tecnologías, normativas, criterios o técnicas relacionadas.

En cuanto a las extensiones, tanto la presentación de la información como la propia información que se muestra es mucho más completa en la aXe Extensión que en la Google ADT. Si tuviera que quedarme con una me quedaría con las aXe Rules y su extensión.

Mobile Web Accessibility Checker

Mobile Web Accessibility Checker es una aplicación para iPhone y iPad. Es un evaluador automático de accesibilidad web que permite auditar varios sitios y múltiples páginas.

La versión gratuita permite tener un proyecto, evaluar una página y exportar los resultados (las opciones de exportación son a CVS y a Google Sheets).

La versión de pago (9.99 Euros al mes) admite un número ilimitado de proyectos y de páginas a evaluar o hacer un batch de páginas importantes.

Las validaciones se realizan de acuerdo a las aXe Rules o a las Google ADT Rules, de forma excluyente.

Mobile Web Accessibility Checker > Settings > Audits

En la pantalla principal se pueden hacer tres acciones:

Mobile Web Accessibility Checker. Página de inicio.

• Cambiar las preferencias. El icono "Settings" está situado en la esquina superior izquierda. Puedes elegir las reglas de validación (aXe Rules o Google ADT), cambiar al plan de pago, integrar la aplicación con Google Sheets o consultar las WCAG 2.0
• Dar de alta un proyecto. El icono está situado en la esquina superior derecha. Los datos que se solicitan es el nombre del proyecto y la URL a evaluar.
• Acceder a un proyecto. En la zona central tenemos el acceso a todos nuestros proyectos.

Al acceder a un proyecto tenemos dos menús:

Mobile Web Accessibility Checker. Dashboard de un proyecto.

• Pages: en este menú tienes el listado de las páginas auditadas y las puedes visualizar.
• Audits: en este menú tienes el listado de auditorías, en cada auditoría el listado de páginas analizadas, y al seleccionar una página los resultados de su evaluación.

Por su parte, en el dashboard, se informa del número de páginas evaluadas, el número de errores encontrados y el número de errores por página. Tenemos tres opciones:

• Pages (por defecto): con el listado y gráficas de las páginas analizadas.
• Top Issues: con el listado y gráficas de los errores encontrados.
• Trends: con el listado y gráficas de las evaluaciones realizadas y los errores encontrados en cada una.

Si accedemos a los resultados de una página auditada, los errores encontrados en un página se muestran listados a la izquierda de la visualización de la página. Por cada tipo de error se indica cuántas veces se ha encontrado en la página:

Mobile Web Accessibility Checker. Listado de errores de una página (evaluado con las aXe Rules).

Si se selecciona un error, la información que se ofrece es la siguiente:

Mobile Web Accessibility Checker. Descripción del error de una página (evaluado con las aXe Rules).

• Nombre y descripción del error, y un cuadrado de color verde, amarillo o rojo que indica su criticidad.
• Target y HTML: identificación del elemento que ha dado error por su ID y el código HTML en el que se inserta. Además en la visualización de la página se resalta en rojo.
• Enlace a más información: enlaza con la página de detalle de cada una de las aXe Rules en Deque University (enlace que os he incluido yo también en el listado de las aXe Rules) o con el listado de reglas de las Google ADT en github (enlace que os he incluido yo también en el listado de las Google ADT Rules)

La información y la manera de mostrarla es la misma tanto si evalúas de acuerdo a las aXe Rules o a las Google ADT Rules, salvo por el enlace de más información.

Desgraciadamente no informa de los criterios, técnicas o tecnologías asociadas al error, debes para ello acceder a la documentación, lo cual dificulta la evaluación en base a la normativa concreta de las WCAG 2.0

Por último también integra una herramienta de evaluación del contraste de color:

Mobile Web Accessibility Checker. Auditar Contraste de color.

Artículos anteriores

• Accessibility Scanner, evaluar la accesibilidad de una app de Android
• WCAG-EM Report Tool. Herramienta de generación de informes de una evaluación de accesibilidad
• Validador automático de accesibilidad Tanaguru
• Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online

Resumen:

En este artículo os voy a hablar del producto Siteimprove, una herramienta online para el análisis programado o manual de sitios completos o secciones concretas.

Las evaluaciones detectan problemas de accesibilidad en las páginas y PDF de acuerdo a las WCAG 2.0 (en los tres niveles: A, AA, AAA); pero también, y entre otros, los enlaces rotos, las faltas de ortografía en diferentes idiomas o los problemas relacionados con SEO.

Me ha gustado mucho por la utilidad y potencia de sus funcionalidades; la calidad de su validador de accesibilidad; las posibilidades de personalización y configuración; y su diseño, limpio y muy intuitivo. Por el contrario, apenas le he encontrado pegas.

Índice:

• Características generales
  • Gestión de usuarios
  • Gestión de portales y grupos de páginas
  • Análisis periódicos automáticos del sitio completo pero también manuales
  • Resumen y listado de la información
  • Priorización de errores y agrupación por el rol del corrector
  • Histórico y anulación de decisiones
  • Facilidades para comprender y corregir los errores
• Resumen de las funcionalidades de la aplicación
  • Quality Assurance (calidad)
  • Accessibility
  • SEO
  • Policy (análisis personalizados)
  • Informes
  • Configuración
  • Analytics
  • Response
• Funcionalidades que describo con más detalle:
  • Quality Assurance: enlaces, ortografía e inventarios
  • Accessibility: evaluación de páginas y PDF de acuerdo a las WCAG 2.0
  • Policy: análisis personalizados
  • Informes
• Conclusiones

Características generales

La aplicación es online, está disponible en español y es de pago. El precio depende de diferentes factores, como los módulos contratados o el tamaño del sitio, y por ello no está publicado en la web sino que se informa de manera personalizada.

No hay una demo pública pero se puede solicitar una demostración gratuita en su web.

A continuación repaso las características y funcionalidades generales que me han llamado al atención o que creo que merece la pena destacar.

Gestión de usuarios

Tiene gestión de usuarios, de manera que diferentes roles puedan tener diferentes permisos y niveles de acceso.

Gestión de portales y grupos de páginas

Puedes tener diferentes portales incluidos y, dentro de estos, si lo deseas, diferentes grupos de páginas. Esto te permite analizar de forma independiente, por ejemplo, diferentes secciones del sitio.

Para cambiar de uno a otro de tus sitios o grupos de páginas, hay dos desplegables siempre disponibles en la cabecera de la aplicación, al estilo de Google Analytics:

Imagen 1. Desplegable de tus sitios y desplegable de sus grupos de páginas en la cabecera de la aplicación. Ver más grande

Análisis periódicos automáticos del sitio completo pero también manuales

El análisis completo de tus portales se programa para que se realice de forma periódica pero también se puede lanzar manualmente.

Además, en cualquier momento se puede analizar una página concreta de forma muy sencilla desde los listados de páginas, el detalle de una de ellas o las utilidades de comprobación de una sola página.

Resumen y listado de la información

Cada sección tiene un resumen inicial con gráficas y listados de la información más relevante a modo de visión general.

La mayor parte de la información se muestra en listados que acaban remitiendo a una página de detalle. Estos listados tienen muchas funcionalidades pero a la vez son rápidos y fáciles de usar: permiten ordenación por columnas, filtros, búsqueda, detalle en línea, acciones asociadas a cada celda o fila, y exportación de los datos o su inclusión en un informe personalizado.

Imagen 2. Ejemplo de listado de la aplicación. Ver más grande

Priorización de errores y agrupación por el rol del corrector

Los problemas detectados se clasifican por diferentes parámetros que permiten después agrupar y filtrar los errores. Por ejemplo, como veremos, los errores de accesibilidad se clasifican por:

• Tipo: errores en el texto, en las imágenes, en los formularios, etc.
• Gravedad: error, advertencia, necesita revisión.
• Nivel de adecuación: A, AA, AAA.
• Rol de la persona que ha de corregir los errores: editor, desarrollador, administrador web. Algo muy práctico y de lo que hablé en el artículo Responsabilidad de accesibilidad de cada uno de los roles profesionales implicados en el ciclo de vida de un proyecto web.

Las páginas tienen además una puntuación en base a los problemas encontrados en las mismas. Esto también ayuda a priorizar páginas de cara a las correcciones.

Histórico y anulación de decisiones

Todas las decisiones que se toman en el portal (por ejemplo ignorar determinados errores, añadir palabras al diccionario, etc.) quedan registradas en un histórico. De esta manera se puede consultar la fecha de un cambio o el usuario que tomó la decisión, y deshacerla si es necesario.

Facilidades para comprender y corregir los errores

El informe de una página tiene una pestaña para cada análisis (Accesibilidad, SEO, etc.) en el cual, como veremos, se detallan los errores con mucho detalle. Además incluye la vista de la página (se resaltan los errores que seleccionas) y se muestra el código del elemento implicado.

Destacan varias herramientas útiles en el informe de una página:

• CMS: enlaza con la página en el CMS para poder hacer los cambios.
• Inspeccionar: te muestra el listado de las rutas para llegar a esta página y todas las páginas remitentes con enlace a la misma.
• Volver a comprobar: permite lanzar en el momento un nuevo análisis de la página.
• Mostrar página/ Mostrar HTML: para tener una vista de la página o de su código HTML.
• Activar/desactivar CSS

Imagen 3. Herramientas del informe de una página. Ver más grande.

Resumen de las funcionalidades de la aplicación

Las opciones de menú de la aplicación, los grandes apartados, son los siguientes:

Quality Assurance

Analiza los enlaces rotos (internos, externos, en PDF, a dominios no seguros) y la ortografía del sitio en los diferentes idiomas del mismo. Además hace inventario de los distintos tipos de contenidos del portal.

Lo analizo en detalle: Quality Assurance: enlaces, ortografía e inventarios

Accessibility

Realiza una evaluación automática conforme a las WCAG 2.0 en los tres niveles de conformidad (A, AA, AAA), tanto de las páginas como de los PDF del portal. Se informa de los errores, las advertencias y los aspectos que necesitan una revisión manual.

Es bastante práctico porque, tal y como veremos, la manera de mostrar y organizar la información la hace comprensible tanto para las personas que no tienen demasiados conocimientos de accesibilidad, como para las que sí los tienen. Se indican por ejemplo los criterios y técnicas asociadas a cada error, con su enlace a las WCAG 2.0.

Lo analizo en detalle: Accessibility: evaluación de páginas y PDF de acuerdo a las WCAG 2.0

SEO

Incluye el análisis de los problemas asociados con el posicionamiento de la página: aspectos relacionados con el título, los metas, su exclusión con noindex/nofollow, redirecciones 302, páginas no incluidas en el mapa XML, etc.

Policy

Permite crear y configurar tus propios análisis personalizados en relación con el texto, el código, el contenido multimedia o los documentos del sitio. Los defines mediante reglas (incluyentes o excluyentes). Como veremos luego, la potencia de esta funcionalidad es muy grande, y las posibilidades y aplicaciones muchas.

Lo analizo en detalle: Policy: análisis personalizados

Informes

Es donde se ejecutan, programan y consultan los informes, en HTML o PDF. La facilidad para personalizar dichos informes con los análisis y tipos de datos que desees es otra ventaja de la aplicación que comentaré más adelante.

Lo analizo en detalle: Informes

Configuración

Permite administrar el perfil de usuario y la gestión de roles y permisos, además de otros aspectos como el idioma, la zona horaria, los formatos de fechas, etc.

Analytics

Es el análisis del portal al estilo de Google Analytics.

Response

Incluye información sobre caídas del sitio, tiempos de respuesta o comportamiento irregular.

Voy a detenerme a continuación en describir con más detalle cuatro de las grandes funcionalidades de la herramienta que más me interesan personalmente: Quality Assurance, Accessibility, Policy e Informes.

Quality Assurance: enlaces, ortografía e inventarios

La manera de consultar los resultados es muy amplia: resumen general, por sitios, por grupos, por páginas, por errores, etc.

Imagen 4. Resumen inicial Quality Assurance. A la izquierda todas sus opciones de menú desplegadas. Ver más grande

Enlaces rotos

Se analizan los enlaces rotos internos y externos, incluidos los presentes en documentos PDF, y los enlaces a dominios no seguros.

Ortografía

Encuentra errores y posibles errores de ortografía en diferentes idiomas.

Se ofrecen sugerencias por cada error, la posibilidad de ignorarlo en una página o en todo el sitio (decisiones que quedan guardadas y pueden anularse), o la posibilidad de agregar la palabra al diccionario y así mantener un vocabulario propio.

Además de poder consultar los resultados por listado de páginas con errores, listado de palabras erróneas o listado de posibles palabras erróneas, me encanta la opción de consultar todas las palabras de tu portal.

Dicha vista, “Lista de palabras”, tiene las opciones habituales (agregar, ignorar, sugerencias, etc.) y permite filtro por idioma, estado (agregada al diccionario, ignorada en todo el sitio etc.) y búsqueda. Puedes de esta manera saber qué palabras estás usando en el portal y con qué frecuencia.

Imagen 5. Listado de las palabras de tu sitio. Ver más grande

Otra funcionalidad es consultar los idiomas utilizados en el portal y su porcentaje de uso.

Inventario

Este apartado me parece también muy útil pues te proporciona un inventario de multitud de elementos. La página inicial es una visión general de todos ellos, con gráfica incluida.

La gran cantidad de inventarios disponibles, unido a sus funcionalidades de ordenación, búsqueda y filtrado, hacen de ella una herramienta muy útil.

Los diferentes inventarios que puedes consultar son:

Contenido

• Páginas. Listado de páginas del portal, y por cada una: tamaño, número de páginas que remiten a la misma (y acceso a ese listado), fecha en que se detectó la página, puntuación en base a los errores que presenta y nivel en el mapa web.
• Enlaces. Listado de todos los enlaces del sitio, y por cada uno: estado HTTP, número de páginas y PDF en los que aparece (y acceso a ese listado).
• Documentos. Listado de documentos por tipo (Excel, PDF, PPT, Word, XML, etc.) con el número que hay (internos y externos), y ya en cada uno: su tamaño, número y acceso a las páginas y PDF en los que aparece, hora de la última modificación y estado.
• Archivos multimedia. Igual que en el caso anterior pero para archivos multimedia (audio, imágenes, vídeo, Flash, applets, etc.)
• Javascript. Listado de los JS del sitio, y por cada uno: número de páginas que los incluyen y que no los incluyen (y acceso a ese listado).
• CSS. Igual que en el caso anterior pero con las hojas de estilo.
• Texto de enlace. Listado de todos los textos de enlace del portal, y por cada uno: número de páginas que los tienen (y acceso a ese listado). Es una buena manera de ver si son comprensibles fuera de contexto.
• Marcas comerciales. Busca los nombres seguidos de ® o TM. Pero también se muestran los duplicados posibles si al nombre le sigue un símbolo de marca comercial diferente, un símbolo de copyright o sin símbolo de marca comercial.

Personal

• Direcciones de correo electrónico, este listado es muy útil para ver si hay direcciones obsoletas, equivocadas, etc.
• Números de teléfono
• Números de identificación (DNI, Seguridad Social, etc.)

Técnico

• Etiquetas META. Listado de todos los metas encontrados en las páginas, y por cada uno: número de páginas que los contienen (y acceso a ese listado) y detalle de su contenido.
• Mapa del sitio. Es un mapa físico de la estructura de directorios en el servidor, y por cada uno: número de páginas (y acceso a ese listado). Es una manera de acceder directamente al detalle de una página en base a su ubicación física.

Accessibility: evaluación de páginas y PDF de acuerdo a las WCAG 2.0

Uno de los apartados que más me interesaba analizar era el de la evaluación de accesibilidad, para valorar la calidad y el detalle del análisis y los resultados.

La evaluación se realiza de acuerdo a las WCAG 2.0 y admite los tres niveles: A, AA, AAA. Los problemas se dividen en errores, advertencias y necesitan revisión manual.

Como ya he comentado antes, una gran ventaja es que los errores se clasifican por diferentes parámetros: nivel de conformidad (A, AA, AAA), gravedad (errores, advertencias, necesitan revisión), tipo (encabezados, imágenes, enlaces, formularios y otros problemas) y rol del corrector (administrador web, desarrollador y editor).

Imagen 6. Parte del resumen donde se observa la agrupación de los errores por diferentes criterios. Ver más grande

Esta clasificación facetada se explota luego en los filtros de las tablas:

Imagen 7. Filtro de las tablas por tipo de problema. Ver más grande

Imagen 8. Filtro de las tablas por el rol del corrector. Ver más grande

Los problemas de accesibilidad detectados en el sitio se pueden consultar de diversas maneras:

Mis sitios

El listado de todos mis sitios permite ver un resumen general: número de páginas y PDF que tienen problemas de accesibilidad, y número de páginas que tienen problemas en cada nivel de conformidad. Desde este listado se puede acceder al listado concreto de páginas.

Grupos

Igual que en el caso anterior pero para los grupos de páginas del sitio que tenemos definidos. Puedes tener, por ejemplo, un grupo para cada sección del portal, y así analizarlas y consultarlas de manera independiente.

Políticas de accesibilidad

Listado de los análisis personalizados que he creado y que he relacionado con la accesibilidad, así como el acceso a sus resultados.

Hablo de esta funcionalidad más adelante (Policy: análisis personalizados) pero podrían ser por ejemplo páginas con determinado texto o código y/o con contenido de más de determinada longitud de caracteres y/o con contenido multimedia o documentos de más de determinado tamaño, etc. Son muchas las reglas que se puede definir, de manera excluyente o no excluyente.

Comprobación de una sola página

Puedo evaluar en el acto una sola página, por ejemplo una que se acabe de incluir en el portal. En cualquier caso, en los listados y detalles también puedo en cualquier momento volver a analizar una página.

Problemas

Me parece un listado amigable para las personas que no tienen muchos conocimientos de accesibilidad, pues no se les asusta de primeras con los números de criterio o las técnicas. Por el contrario, es un listado de los problemas con un nombre comprensible, organizados por nivel de conformidad, pero con posibilidad de filtro.

Además es muy visual, pues incluye tanto una barra de progreso general muy destacada como una por cada página. Se genera en positivo, en base al porcentaje de problemas resueltos. Creo que este planteamiento es acertado, siempre anima más ver el vaso medio lleno que ver el porcentaje en rojo, en negativo, en base a los problemas que faltan por resolver.

Tanto en el icono de ayuda, como después en los detalles, sí se informa ya del principio, pauta, criterio de conformidad, técnicas asociadas, etc.

Imagen 9. Listado de problemas con la ayuda asociada a uno de ellos abierta. Ver más grande

Veremos luego la página de detalle, es decir, el informe de una página concreta.

Directrices

Este es ya un listado más técnico. Se incluyen todos los principios, pautas y criterios de conformidad, indicando el número de páginas que presentan errores, advertencias y necesidad de revisión.

Por cada uno de los criterios de conformidad podemos abrir el listado de todos los aspectos que se están evaluando y el número de páginas en los que se detectan problemas.

Imagen 10. Listado de pautas y criterios de conformidad de las WCAG 2.0. Está abierto el listado de problemas evaluados en uno de ellos. Ver más grande

También se señalan aquellos criterios de conformidad para los cuales no se puede hacer ninguna revisión automática:

Imagen 11. Listado de pautas y criterios de conformidad de las WCAG 2.0. Está abierta la información asociada a uno de los que no admite evaluación automática. Ver más grande

Hubiera estado bien que se pudiera hacer un seguimiento manual de estos criterios no evaluables para que los revisores avanzados de accesibilidad pudieran registrar si se están cumpliendo. Así se podría tener una visión completa de si las páginas son realmente AA en base a todos los criterios de conformidad.

El listado de aspectos evaluados dentro de cada criterio de conformidad remite a la página de detalle del problema, con el listado de páginas que presentan errores.

Páginas

Listado de todas las páginas, y por cada una, el número de errores que presentan de cada nivel.

Este listado es un arma de doble filo porque el número de errores que indica en cada página es el sumatorio de todas las instancias de cada error, advertencia y "necesita revisión". Lo que voy a comentar a continuación sirve también para tenerlo en cuenta cuando hacemos una consultoría de accesibilidad: hay que ser prudentes con la manera de dar la información y explicarla muy bien para no distorsionar los datos.

Por una parte, está bien contabilizar el sumatorio de todas las instancias de los errores. Esto nos ayuda a priorizar las páginas a corregir, ya que no es igual de prioritaria una página que tienen 5 tipos de errores 1 vez cada uno, que una página que tiene 3 tipos de errores 50 veces cada uno:la primera tiene 5 errores y la segunda 150 errores. Si solo contáramos los tipos de errores parecería que la primera con 5 es más prioritaria que la que tiene 3. Combinado con la ordenación por nivel de conformidad (A, AA, AAA), me ayuda a priorizar las páginas.

Pero por otra parte, contabilizar el sumatorio de todas las instancias de los errores, sin distinguir si son errores, advertencias o "necesita revisión" (esta tabla no permite filtro por gravedad), nos puede dar una idea equivocada de la problemática de una página.

Si, por ejemplo, tienes 30 imágenes en tu página, saldrán ya fijos 30 errores relativos al “necesita revisión” del criterio 1.4.5 que indica que debes revisar manualmente que no son imágenes de texto. Si esto lo multiplicamos por todos los "necesita revisión", el número de errores que presenta la página es tan elevado que nos puede hacer pensar que es muy problemática. Quizás una página sin imágenes (y por tanto sin estos errores iniciales) pueden ser más problemática pero tener menos errores. Se mitigaría con un filtro por gravedad, o con la posibilidad de consultar el número de errores y/o el sumatorio de todas las instancias del error.

Al final es cierto que los vas puliendo a medida que confirmas o ignoras errores en las páginas, y en este sentido el sumatorio que hace te dará una idea del número de elementos por página que te quedan por mirar. Pero hay que tener cuidado a la hora de utilizar esta información en un informe para no distorsionar los datos.

PDF

Listado de todos los PDF que presentan problemas de accesibilidad.

En cada PDF se indica:

• su título
• si es legible por máquina, es decir, si es un PDF resultante de un escaneo y por tanto inaccesible.
• si está etiquetado, requisito imprescindible para ser accesible.
• el número de errores que presenta. Los errores que se detectan son evidentemente solo los que se pueden detectar con una evaluación automática (si se ha definido el idioma, si la estructura de encabezados es correcta, etc.) pero ayuda a asegurar un mínimo de accesibilidad en los PDF, que no es poco.

Igual que en el informe detalle de una página, en el informe detalle del PDF se visualiza también el fichero.

Hubiera estado bien que los revisores avanzados de accesibilidad pudieran hacer el seguimiento de los aspectos que deben revisarse manualmente (el orden de lectura, el etiqueta correcto, etc.) para poder indicar si el PDF es accesible más allá los aspectos que se pueden evaluar automáticamente.

Validaciones HTML/CSS

Por otra parte hay dos apartados para los resultados de la validación HTML y CSS de las páginas:

• Validación HTML. Listado de todas páginascon el número de errores detectados por el validador automático de código del W3C (y enlace al detalle en el mismo).
• Validación CSS. Listado de las CSS del sitio con el número de errores detectados por el validador automático de CSS del W3C (y enlace al detalle en el mismo).

Decisiones e Historial

En el apartado “Decisiones” se puede hacer el seguimiento de todos los problemas y elementos que has marcado que se ignoren. Esto nos permite tener un histórico, poder supervisar las decisiones y deshacerlas si es necesario.

En “Historial” podemos ver de manera gráfica la evolución de los problemas (número de páginas con problemas de nivel A, AA, AAA) en el tiempo.

Detalle de una página

Al final, en todos los listados, puedes llegar al detalle o informe de una página. Donde, como hemos visto, tienes una pestaña específica para los problemas de accesibilidad de la página:

Imagen 12. Detalle de una página. A la izquierda listado de criterios de conformidad con errores. Está abierto el listado de errores del criterio 1.3.1. Ver más grande

Al seleccionar un error concreto asociado a un criterio, accedes al detalle de dicho error:

Imagen 13. Detalle de un error. A la izquierda la información detallada del error: instancias del mismo en la página, técnicas asociadas, etc. Ver más grande

En la zona derecha se visualiza la página con el error resaltado y el código HTML del elemento implicado.

En la zona izquierda está toda la información detallada del error. Esta incluye un listado de todas las instancias del error en la página así como todas las técnicas que se pueden usar para resolverlo.

Tenemos botones para volver a analizar la página o para abrir la página en el CMS para corregir los errores.

Policy: análisis personalizados

Una política, en el argot de la aplicación, es la creación de un análisis personalizado que defines mediante la combinación de reglas predefinidas.

Cuando creas la política le das un nombre y una descripción para que los editores sepan por ejemplo qué hacer con el listado de páginas que lo cumplan. Puedes indicar los sitios en los que quieres incluirla, darle una prioridad (alta, media, baja) y asociarla con Quality, Accessibility y SEO, de manera no excluyente, para que sus resultados aparezcan en estos apartados y sus informes si lo así lo decides.

La política se define en base a una serie de reglas predefinidas. Se pueden añadir varias reglas de manera excluyente o no excluyente. Las reglas se clasifican según estén relacionadas con el contenido, los documentos o los archivos multimedia.

Por ejemplo, podría buscar páginas con determinado texto, con determinado código HTML, o con un tipo concreto de contenido multimedia o documento, y hacerlo en base a su URL, tamaño, tipo, fecha, nivel de página, o incluso en función de las visitas que tiene la página o los clics en un enlace, y todo ello de manera no excluyente.

Ejemplo 1: todas las imágenes de más de 300KB con texto alternativo que comience por “undefined” en páginas con más de 1000 páginas vistas en los últimos 30 días.

Ejemplo 2: páginas HTTPS con contenido HTTP:

Imagen 14. Ejemplo de política con varias reglas no excluyentes. Ver más grande

La potencia de esta herramienta es tremenda. También, como alternativa a la creación manual de una política, puedes añadir políticas de la biblioteca existente.

Podrás consultar las políticas por sitios, páginas, documentos o archivos multimedia que presenten coincidencias con las reglas definidas.

También hay un registro de eventos para cualquier acción asociada a la creación y modificación de políticas, de manera que quedan registradas con la fecha y el usuario que las realizó.

Informes

El apartado “Informes” es donde se ejecutan, programan y consultan los informes Quality Assurance, Accessibility, SEO, Analytics y Policy.

En Policy tienes tus análisis personalizados, pero si un análisis lo asocias a cualquiera de las otras categorías como hemos visto, también lo tendrás disponible en los informes de dichas categorías.

Al programar un informe se puede indicar el intervalo de tiempo, programar para determinados sitios y grupos de páginas, seleccionar destinatarios, el formato (HTML o PDF) y la plantilla del correo electrónico de la notificación. Mi experiencia es que la generación del informe es bastante rápida.

Puedes tener tantos tipos de informes como desees. Cada tipo de informe diferente que te creas es una plantilla.

Imagen 15. Dos plantillas de informes de accesibilidad. La general de la aplicación y la mía personalizada “WCAG 2.0 AA Detallado”. Ver más grande

Una de las cosas que me han gustado es la forma de personalizar un informe. En cualquier listado o gráfica de la aplicación hay un botón “exportar” que, además de permitir exportarlo a Excel, permite incluir ese tipo de contenido en una plantilla de informe.

Imagen 16. Listado de pautas de accesibilidad y páginas que presentan errores en las mismas. La opción exportar permite indicar en qué plantilla de informe se quiere incluir esta información. Ver más grande

La información se insertará en el informe en base a los filtros aplicados. Si yo aplico un filtro a la tabla y añado la tabla al informe, la tabla se incluirá con dicho filtro.

Sin embargo es una pena que no funcione de la misma manera con el ordenamiento de las columnas. En algunos casos sería muy útil poder incluir en el informe la tabla ordenada por una columna determinada, pero al incluir un tipo de tabla al informe recuerda el filtro pero no la ordenación.

Además de la funcionalidad anterior, puedes crear una plantilla desde cero o basada en una existente, y podrás seleccionar todos los componentes que desees añadir:

Imagen 17. Creación de una plantilla. Selección de los componentes que se quieren añadir. Ver más grande

Al editar una plantilla puedo modificar el título de cada sección, cambiar el orden en que aparece la información, seleccionar el número de filas a mostrar (en aquellas que tienen un formato de listado), etc.

Conclusiones

Me parece una herramienta recomendable para monitorizar nuestros portales mediante análisis periódicos automáticos que impidan que la accesibilidad y la calidad del portal se degrade con el tiempo, algo habitual en los portales que se actualizan con frecuencia. Entre sus clientes hay universidades (Berkeley o Stanford), bancos, aseguradoras o empresas como Microsoft, Vodafone, Audi o Adecco.

Me parece potente, útil y fácil de usar. Los aspectos que he ido comentando que podrían mejorarse son poca cosa si se comparan con todas funcionalidades y ventajas que ofrece la aplicación. Sí que sería relevante cuidar la accesibilidad de los informes generados. La he probado en diferentes navegadores y, salvo un problema muy concreto en una página y zona específica con Explorer y Firefox, me ha funcionado bien con todos ellos.

Me interesaba especialmente el validador de accesibilidad, y me ha sorprendido que sea uno de los puntos fuertes de la herramienta, al contrario de lo que suele ocurrir en estos casos. Es fiable, ofrece información detallada desde diferentes puntos de vista y comprensible para expertos y no expertos en accesibilidad, así como muchas funcionalidades relevantes, algunas poco habituales.

Por mi parte he revisado mi web en base a los errores que indicaban los informes para corregir aquellos que efectivamente lo eran.

Enlace: Siteimprove

Artículos relacionados

• Nueva versión de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0
• Validadores y herramientas para consultorías de accesibilidad y usabilidad
• Responsabilidad de accesibilidad de cada uno de los roles profesionales implicados en el ciclo de vida de un proyecto web
• Falsos errores de validadores automáticos de accesibilidad basados en las WCAG 2.0 en otros
• aXe Rules, Google ADT Rules y el Mobile Web Accessibility Checker
• Accessibility Scanner, evaluar la accesibilidad de una app de Android

Resumen:

En español readability lo traducimos como legibilidad lingüística, que es diferente de la legibilidad tipográfica. Nos referimos a la legibilidad que viene condicionada por el léxico y las construcciones gramaticales utilizadas, y no por el tamaño, forma o diseño de la fuente y sus caracteres. Otros autores lo traducen como comprensibilidad (también inteligibilidad, perspicuidad o lecturabilidad) pues lo que estamos intentando medir es la facilidad para comprender un texto.

El objetivo del artículo es evidenciar la problemática que tenemos actualmente para medir la readability de los textos en español, al contrario de lo que ocurre con los textos en inglés, para los cuales tenemos diferentes fórmulas y herramientas que las aplican.

El artículo termina describiendo una herramienta ideal que nos permita medir la readability de los textos en español, con fiabilidad, y en base a los diferentes parámetros que influyen en que un texto sea fácil o difícil de comprender. En última instancia se reflexiona sobre las limitaciones que puede tener medir automáticamente la legibilidad de un texto.

Comienzo repasando primero el estado de la medición de la readability de los textos en español e inglés, y las herramientas actualmente disponibles.

Medir la readability en inglés

Existen diversas fórmulas que buscan medir y conocer la legibilidad de un texto. Ofrecen una puntuación (cuanto más alta más fácil de leer) o el nivel de estudios necesario para comprender el texto.

Las fórmulas más conocidas son:

• Flesch-Kincaid (1975):
  • Flesch reading ease:

    206.835 - 1.015 (total words/total sentences) - 84.6 (total syllables/total words))

  • Flesch–Kincaid grade level:

    0.39 (total words/total sentences) + 11.8 (total syllables/total words) - 15.59

• SMOG (1969):

  grade = 1.0430 raíz de cuadrada de (number of polysyllables x (30 / number of sentences)) + 3.1291

• Gunning fog (1952):

  0.4 [(words / sentences) + 100 (complex words / words)]

• Coleman- Liau (1975):

  CLI = 0.0588 L - 0.296 S - 15.8

  Donde L es el número medio de letras por cada 100 palabras y S el número medio de frases por cada 100 palabras.

• Automated Readability Index (ARI):

  4.71 (characteres / words) + 0.5 (words / sentences) - 21.43

Vemos que tienen en cuenta el número de palabras y de oraciones. Las tres primeras se basan en sílabas por palabra y las dos últimas en caracteres por palabra, porque se parte de la hipótesis de que un texto es más fácil de leer cuanto más cortas son las palabras y frases que utiliza.

Existen diversas herramientas (Readability Test, Readability Calculator o Readability Score) que evalúan la complejidad de los textos en base a una o varias de estas fórmulas. Además suelen informar de otros datos generales como el número de letras, sílabas, palabras, frases, etc.

Mis herramientas favoritas son:

TRAY Readability Tool

- TRAY Readability Tool -

Informa del número de letras y espacios (y caracteres en total); el número de frases y palabras; la media de caracteres por palabras; el número de palabras complejas; la media de palabras por frase; el número de sílabas; la puntuación alcanzada en los test: Gunning-Fog, Coleman-Liau, Flesch-Kincaid grade level y reading ease, SMOG y ARI.

Readability Score

Es una herramienta online que ofrece mucha información y bien estructurada, aunque el número de evaluaciones está limitada en la versión gratuita.

La información que aporta es:

• general: número de palabras, de frases, de caracteres, de sílabas, de sílabas por palabra, etc.)
• puntuación según diferentes índices: Gunning-Fog, Coleman-Liau, Flesch-Kincaid grade level y reading ease, SMOG, ARI y más
• otros datos: número de frases en pasiva, número de adverbios, si se está usando un lenguaje positivo o negativo, el tiempo que se estima necesario para leerlo (basado en 225 palabras por minuto) y para leerlo en voz alta (basado en 125 palabras por minuto), las palabras más utilizadas o las frases más largas.

- Readability Score -

También hay utilidades para procesadores de texto y programas locales de pago bastante completos como Readability Studio, que tiene estadísticas, gráficos, listado de palabras difíciles, etc.:

- Readability Studio -

Sin embargo, como ya he indicado, la puntuación en estos test no es válida para los textos en español. Tampoco lo será la información sobre frases en pasiva o el número de adverbios.

Medir la readability en español

Se pueden destacar dos adaptaciones del índice Flesch al español:

Flesch-Fernández Huerta (1959)

Índice Fdez-Huerta = 206.84 - (0.60 x P) - (1.02 x F)

Donde P es el número de sílabas por cada 100 palabras y F el número de frases por cada 100 palabras. Si un texto alcanza una puntuación entre 90-100 significa que es muy fácil de comprender (apto para 4º grado) y entre 0-30 muy difícil (propio de un nivel universitario).

Sin embargo a esta fórmula se le achaca que tiene un error y no es escalable:

Applying the same sanity check, we see that if the number of syllables per word increases, the score decreases, as expected; but if the number of sentences increases, the score also decreases. Now, if the number of sentences in a 100- word sample increases, each sentence must be getting shorter. That should make the readability of the passage increase, not decrease.

Disc: Error in the Fernandez Huerta Readability Formula, Elyssa Winzeler, 2011

Por otra parte, a Fernández Huerta también se le reprocha que no explicó su procedimiento de validación ni validó realmente la escala de interpretación de las puntuaciones.

Flesch-Szigriszt (1993)

IFSZ = 206.84 - (62.3 x Sílabas / Palabras) - Palabras / Frases)

Una puntuación 0-15 indica que el texto es muy difícil; y una puntuación mayor de 90 indica que es muy fácil.

Sin embargo, esta fórmula tampoco está exenta de controversias, como veremos en el siguiente apartado. Se le achaca que la validación de la escala de puntuaciones ha sido realizada con una muestra insuficiente, de conveniencia y no sistemática.

Grado en la Escala Inflesz y herramienta Inflesz

La tesis doctoral de Inés Mª Barrio Cantalejo es uno de los documento de referencia sobre el tema, y fue el origen de la herramienta Inflesz. En ella dice así:

De las fórmulas para la lengua española, el Índice de Legibilidad de Flesch-Szigriszt (IFSZ) debe considerarse de referencia en el momento actual. Sin embargo, la Escala del Nivel de Perspicuidad propuesta por Szigriszt para interpretar dicha fórmula, precisa adaptación, porque ha sido realizada con una muestra insuficiente, no representativa ni aleatoria de textos. No realizó una selección aleatoria de la muestra de estudio ni calculó un tamaño muestral representativo para poder generalizar sus conclusiones. Para comprobar la validez de esta escala Szigriszt, simplemente aplicó manualmente la Fórmula de Perspicuidad a dos muestras de textos de conveniencia.

La aplicación de IFSZ a una muestra representativa de 210 textos escritos en español ofrece como resultado una nueva escala de interpretación denominada “Escala INFLESZ”.

Tesis doctoral "Legibilidad y salud. Los métodos de medición de la legibilidad y su aplicación al diseño de folletos educativos sobre salud" (PDF), Inés Mª Barrio Cantalejo, 2007.

Describe con detalle la metodología en el capítulo 7, donde revisa las hipótesis de Szigriszt, utilizando una muestra de tamaño suficiente y aleatoria. A partir de los resultados de su investigación estable el grado en la escala Inflesz, que reajusta la escala Szigriszt:

- Comparativa de la escala de interpretación del índice de Flesch-Szigriszt por parte de Inflesz, Szigriszt y Flesch.-

El resultado final es una escala de interpretación de la puntuación de IFSZ diferente tanto a la "Escala de Nivel de Perspicuidad de Szigriszt" como a la escala original de la fórmula RES de Flesch. Esta nueva escala, basada en 5 niveles en vez de en 7 por simplicidad, se añade a la interpretación de los resultados del Índice de Flesch-Szigriszt en el programa Inflesz.

- Escala Inflesz -

- Inflesz -

Leyendo la tesis completa no parece que se pueda encontrar ninguna pega a su metodología y conclusiones, ni he encontrado nadie que lo haga. Incluso las limitaciones que indica en las páginas 441-444, no parecen relevantes para el resultado.

Más fórmulas y herramientas

En la tesis de Inés Mª Barrio Cantalejo están todas recogidas, pero se puede consultar un listado más resumido en Fórmulas en español, de Weblegibilidad. Recoge estudios desde 1951 hasta 2002, muchos ligados al estudio de la legibilidad en el ámbito de la información sanitaria ofrecida a los ciudadanos.

De los no nombrados hasta ahora podemos destacar:

En 2001, José Antonio García López (García López JA. Legibilidad de los folletos informativos. Pharm Care Esp 2001; 3:49-56.) propone una ecuación basada en los mismos criterios que la de Flesch, aplicada al castellano, que permite medir la legibilidad de un texto y determinar el grado de legibilidad de dicho texto para lectores de una determinada edad.

Del texto de cada folleto se escoge una muestra de 100 palabras, procurando que cada muestra comience al inicio de un párrafo. Se cuenta el número total de sílabas y se calcula el promedio de sílabas por palabra, denominado SIL. A continuación, se busca la frase que termina lo más cerca posible de la palabra número 100 de la muestra, antes o después de ella. Se cuenta el número de frases y se divide el número total de palabras, que no es necesariamente 100, por el número de frases. El resultado se denomina PAL.

Con los valores promedio de sílabas por palabra (SIL) y de palabras por frase (PAL) se aplica la ecuación: EDAD= 7,1395 + 0,2495PAL + 6,4763SIL). El resultado informa sobre la edad, a la que le corresponde un determinado nivel de estudios, que debe tener un individuo para que el contenido de un folleto le resulte legible.

[..] Avila de Tomás y Veiga Paulet (Ávila de Tomás JF, Veiga Paulet JA. Legibilidad de la información sanitaria ofrecida a los ciudadanos. Una aproximación a través del índice de Flesch. Centro de Salud , 2002 : 589-597) han utilizado la fórmula de García López para medir la legibilidad de la información sanitaria ofrecida a los ciudadanos. La fórmula de Fernández Huerta se utilizó para conocer la legibilidad de las páginas Web de salud dirigidas a pacientes y lectores de la población general.

En Fórmulas en español, Weblegibilidad.

Como he comentado, la única herramienta que aplica las fórmulas adaptadas al español es Inflesz. Podríamos pensar que también podemos utilizar las "Estadísticas de legibilidad" de Word que se muestran al revisar la ortografía del texto:

- Estadísticas de legibilidad de Word -

Sin embargo, el apartado "Readability" de este informe de Word solo aparece cuando se evalúa un texto en inglés (por eso el texto de la pantalla está en inglés). Esto tiene su lógica porque las fórmulas Flesch aplicadas son las originales, las específicas para el inglés. No se aplican en ningún caso, aunque el texto esté en español, las adaptadas para este idioma. Por tanto tampoco podemos utilizar estos indicadores.

Lo que siempre podremos hacer, claro está, es coger la información genérica que da Word u otro programa (número de palabras, de frases, etc.) y aplicarla manualmente a la fórmula Flesch-Szigriszt, por ejemplo en una excel. Una vez que tenemos el resultado podemos consultar su correspondencia en la escala de interpretación de Inflezs y así conocer el grado de complejidad del texto.

Conclusiones. Reto para investigadores y desarrolladores

Hemos visto que existen pocas fórmulas para medir específicamente la legibilidad de los textos en español y que no exentas de controversias. Por otro lado, la única herramienta que podemos citar para evaluar la legibilidad de los textos en español es la herramienta local Inflesz, que podría mejorarse mucho.

¿Cuáles serían las características de una herramienta ideal?

• Versión online y extensión para navegador (ya hemos visto las ventajas de TRAY Readability Tool).
• Posibilidad de evaluar mediante: URL (e idealmente un sitio completo.), subir un fichero, escribir directamente el texto.
• Resultados presentados de manera clara y estructurada.
• Exportación de informes.
• Tipos de datos a mostrar:
  • Generales:
    • número de letras, espacios y caracteres en total
    • número de palabras y frases
    • media y porcentajes de caracteres por palabra
    • media y porcentajes de sílabas por palabra
    • media y porcentajes de palabras por frase
  • Puntuación:
    • hemos visto que la más fiable es la fórmula de Flesch-Szigriszt con la escala de interpretación de la puntuación de Inflesz (Grado en la escala Inflesz).
    • además del grado de dificultad, interesaría su correlación con el nivel de estudios y la edad asociada.
    • lo deseable sería incluir el mayor número de índices adaptados al español para poder comparar e incluso hacer la media. Sería interesante que la investigación avanzara en este sentido y se propusieran más adaptaciones o índices específicos para el español.
    • flexibilidad para poder añadir o modificar los índices.
  • Complementariamente a la puntuación, otra información relacionada con la complejidad de los textos. Esta es más difícil de calcular y no se tiene en cuenta en las fórmulas habituales. Sería un reto poder calcular los siguientes datos y poder relacionarlos de forma fiable con el cálculo de la puntuación, para subirla o bajarla:
    • Número de oraciones en voz pasiva. Puesto que el abuso de la voz pasiva esta relacionada con la complejidad de los texto.
    • Número y porcentaje de tipos de palabras (verbos, adverbios, conjunciones, etc.)
    • Número y porcentaje de oraciones en afirmativa o negativa, y especialmente de dobles negaciones, que reducen la comprensión.
    • Número y porcentaje de texto en otro idioma, puesto que esto evidentemente añade complejidad al texto.
    • Número y porcentaje de abreviaturas y acrónimos sin explicar.
    • El porcentaje de construcciones que no siguen el orden habitual sujeto + verbo + predicado.
    • Errores ortográfico y gramaticales.
  • Palabras y frases concretas:
    • Listado de las palabras más repetidas en el texto
    • Listado de las palabras más largas del texto
    • Listado de las frases más largas del texto
  • Tiempo de lectura y lectura en voz alta estimado, pero con posibilidad de poder personalizar el número de palabras por minuto en que se basa el cálculo.
• Aprovechar el listado de la RAE de las 1.000/5.000/10.000 palabras más frecuentes en español para evaluar en qué porcentaje se están utilizando estas palabras (si el texto utiliza palabras sencillas y habituales es más sencillo).

  También permitiría poder ofrecer sinónimos para las palabras complejas. Se puede ver una aplicación práctica del listado de las 1000 palabras más frecuentes para ofrecer sinónimos en: Convertir a sencilla

  Otros autores (Rodríguez Diéguez, 1994) proponen contrastar los textos con el vocabulario usual de Lorenzo Delgado ("El vocabulario televisivo y su inserción en la enseñanza", 1981) obtenido a partir de una muestra de programas de televisión, aunque no sé su validez actual.

Sin embargo, es verdad que aunque pudieramos calcular toda esta información e integrarla en la fórmula, una herramienta automática siempre tendrá sus limitaciones: no evaluará la adecuación y corrección del contenido, la organización adecuada del mensaje, la legibilidad de gráficas, tablas e ilustraciones, etc.

La legibilidad tipográfica puede ser un elemento tan determinante de la facilidad de lectura como la legibilidad lingüística medida por una fórmula. La legibilidad psicológica, que tiene que ver con elementos motivacionales, la conceptual, la estructural o la pragmática, de que habla Alliende, condicionan obviamente la dificultad de lectura de un texto.

Las experiencias anteriores, el interés previo por lo que va a leerse o el impacto emocional de lo que se va leyendo, condicionan sin duda la comprensión global de un texto. Nada de esto es medido por las fórmulas.

En Tesis doctoral "Legibilidad y salud. Los métodos de medición de la legibilidad y su aplicación al diseño de folletos educativos sobre salud" (PDF), Inés Mª Barrio Cantalejo, 2007.

También es cierto que la validación de una escala siempre es transitoria y circunstancial:

Esto es debido a que la dificultad que un lector encuentre en un texto va a depender de su nivel cultural y sus hábitos de lectura. A una sociedad que crezca en ambas dimensiones le va a resultar más fácil leer un texto que en otro momento de menos desarrollo cultural y de hábitos lectores. Por lo tanto es una escala que resulta válida sólo en las actuales circunstancias y que convendría revisar periódicamente para adaptarla a los cambios culturales y sociales.

Artículos relacionados:

• Reseña: "Cómo escribir para la Web" de Guillermo Franco
• Validadores y herramientas para consultorías de accesibilidad y usabilidad
• Glosario de usabilidad y accesibilidad web

Autor: Heydon Pickering

Nº páginas: 313

Idioma: inglés

Formato: PDF/ePub y/o impreso en tapa dura (calidad alta)

Fecha de publicación: 2016

Web: "Meet 'Inclusive Front-End Design Patterns', A New Smashing Book" en Smashing Magazine.

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

No se publican muchos libros de accesibilidad y tengo que decir que hacía tiempo que no encontraba un libro tan útil y tan inspirador.

Me ha encantado: es ameno, claro, pero a la vez trata muchos temas complejos, con ejemplos concretos de código HTML, CSS y JS.

También me gusta cómo plantea la enseñanza de la accesibilidad desde un enfoque diferente al habitual. En vez de abordar la accesibilidad en base a principios y pautas, lo hace a través de patrones de diseño concretos: una lista de productos, un formulario de registro, un botón hamburguesa, etc.

La explicación de cómo hacer accesibles para todas las personas cada uno de estos componentes le sirve de excusa para ir tratando todos los requisitos de accesibilidad de forma temática.

Esto permitirá que el lector se cree una biblioteca básica de componentes accesibles, pero lo que es más importante, le dota del conocimiento y las herramientas necesarias para poder ir ampliándola con garantías.

Al final, nos está documentado paso a paso el proceso de creación de un pequeño sitio web accesible. No habla de frameworks concretos, deberás buscar uno flexible que te permita aplicar los patrones definidos.

El libro está dirigido a diseñadores, maquetadores y programadores, no solo les recomiendo que lo lean, les suplicaría que lo hicieran.

El autor les quiere transmitir la nueva forma de pensar que define al Inclusive Design, que supone buscar la mejor solución a un problema, siendo esta la que incluye a todas las personas, con sus diferentes capacidades, preferencias y circunstancias. El libro demuestra que es posible hacerlo, que genera una solución más robusta, y que no es ni más costoso ni más difícil, por el contrario, a cambio ganamos una audiencia más amplia y menos frustrada.

La inclusividad es una cualidad del producto, no una mera característica adicional, y si está integrada en el proceso de desarrollo apenas supone trabajo extra. De hecho, usar tecnologías estándar de una forma correcta da en realidad menos trabajo.

El enfoque del libro os será muy útil porque, como digo, ofrece soluciones concretas, con ejemplos y código real. De hecho, vais a encontrar mucho código HTML, CSS, JavaScript, y mucho WAI-ARIA. También es muy recomendable para consultores de accesibilidad, pues aquí encontrarán muchas propuestas concretas de mejora, algunas bastante ingeniosas.

A continuación, comento brevemente los temas que trata el autor en 9 de los patrones que aborda en el libro:

• The Document
• A Paragraph
• A Blog Post
• Navigation Regions
• A Menu Button
• A List Of Products
• A Filter Widget
• A Registration Form
• Test-Driven Markup

The Document

El objetivo final de este capítulo es ofrecer la plantilla base HTML del documento, es decir, el código del esqueleto de la página donde se incluirá el contenido (se puede consultar completo en la página 43).

A lo largo del capítulo va repasando los siguientes temas:

• el DOCTYPE;
• la definición del idioma en la etiqueta HTML y las diferentes ventajas que esto conlleva;
• la importancia del diseño responsivo (Responsive Design) para el diseño inclusivo. Hace hincapié en permitir el zoom en los dispositivos móviles (traté este tema en profundidad en Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes)
• la definición de los tamaños de fuente en medidas relativas. Los problemas de las medidas rem y vh/vw y las soluciones para que incrementen su tamaño proporcionalmente con el viewport y admitan zoom.
• la importancia de la Mejora Progresiva (Progressive Enhancement) como metodología de trabajo. Los patrones del libro están fundados en estructuras HTML semánticas y bien formadas, mejoradas con CSS y JS. Esté o no activo el JS, el HTML semántico asegura una experiencia inclusiva para los usuarios de productos de apoyo, además de hacer la interacción más predecible y eficiente.
• pensar siempre en el peso de la página y la velocidad de carga, optimizando, por ejemplo, recursos como las fuentes externas (propone alternativas a FOIT, cargar las fuentes una vez que se cargue la página, cargar solo el subset necesario, etc.)
• el<title> de la página y sus características;
• las ventajas del uso de etiquetas semánticas como <main>;
• los enlaces "saltar al contenido" y recomendaciones para su implementación.

En esencia, el código final es bastante similar al código que os proponía en mi artículo "Plantilla base HTML accesible", pero mucho más simplificado, más apropiado para el objetivo con el que se inserta en el libro. La mía incluía aspectos como los metas o la navegación semántica que no hubiera tenido sentido incluir en este libro. Otra diferencia importante es que su plantilla está en HTML5, y la mía, escrita en 2007, está en XHTML 1.0 Strict.

A Paragraph

El párrafo es quizás el patrón más básico y le sirve para hablar de la importancia del contenido y del principio "Content firt design". El contenido es lo más importante y el resto de actividades de diseño deben ser tratadas como apoyo al contenido y su forma. Por ello es importante que los prototipos tengan contenidos reales listos para probar con el usuario. En resumen si vas a hacer algo bien desde el principio que sea el contenido.

Otros temas que trata a lo largo del capítulo son:

• Measure o número de caracteres por línea. En este sentido apoya la propuesta de Robert Bringhurst de 45-75 por línea. En el libro incluye el código concreto CSS para definirlo respecto al tamaño de fuente y que al crecer este se reajuste proporcionalmente.
• Justificación, y las razones por las cuales debe alinearse el texto a la izquierda y nunca justificarse.
• Leading o altura de línea (line-height). Incluye el código concreto para que cumpla con las WCAG 2.0, utilizando mediadas relativas y proporcionales, de manera que cuando crezca el texto se mantenga la altura de línea adecuada.
• Contraste. Habla de la importancia de contraste de color, cómo revisarlo y la advertencia de atemperar el contraste extremo (negro sobre blanco).
• Subrayado de los enlaces, y su importancia. Incluye un código concreto CSS para evitar que el subrayado tache los trazos que sobresalen por debajo de la línea base de determinadas letras (p, q, g, etc.) y que permite controlar el estilo del subrayado (grosor, color, distancia del texto, etc.)
• Visibilidad del foco. Cada navegador identifica de una manera el elemento que tiene el foco (punteándolo, coloreándolo). Además de insistir en la importancia de no anular este efecto, propone un código CSS para normalizarlo en todos los navegadores y que sea más visible, al estilo del que tiene el portal gov.uk.
• Iconos automáticos. Explica el código CSS para incluir de forma automática (sin depender de los editores del contenido) un icono tras los enlaces externos.
• Normas de redacción. Traté este tema en la reseña de "Cómo escribir para la Web" de Guillermo Franco.

El autor parte de la premisa de Susana González en Designing for extremes de que no existe el usuario medio, y diseñar para este individuo artificial hace que creemos algo que no encaja con las necesidades de nadie. Diseñar para las situaciones extremas hace que al final diseñemos para todos.

Todas las pautas dadas son adecuadas para un público muy diverso (baja visión, dislexia, bajo nivel de alfabetización, conocimiento técnico limitado, etc.) así que una lectura cómoda y una interacción garantizada para ellos lo será también para todos los demás.

La web de Heydon Pickering, por si queréis ver cómo utiliza el texto y su diseño, es: Heydonworks

A Blog Post

Este componente le sirve para repasar aspectos fundamentales del diseño inclusivo como son la estructura del contenido, y su coherencia con la información visual que se ofrece, el orden del código, el sistema de encabezados o cómo establecer un CSS Flow System robusto y tolerante a los cambios de contexto. Todo ello ayudará a que la página sea navegable y operable por todos los usuarios.

El autor realizó una encuesta sobre las preferencias de los usuarios de lector de pantalla (Screen Reader Strategy Survey), de manera que las afirmaciones que hace (por ejemplo sobre sus preferencias de navegación: landmarks, encabezados o lectura lineal) pueden basarse en datos objetivos.

Podéis consultar una recopilación de este tipo de encuestas en mi artículo Test, estadísticas, encuestas y estudios sobre lectores de pantalla.

Entre los temas que trata en este capítulo están:

• Los encabezados, su importancia y buenas prácticas. Tiene un apartado específico para los &lth1>, con opciones de codificación para casos concretos como los subtítulos (entendidos como frases que complementan un título).
• Orden del código, y su importancia en determinados contextos de uso.
• &ltarticle>, su uso correcto y el soporte actual.
• On single-page applications. Desaconseja el contenido estático generado por JS en cliente y repasa los problemas implícitos a esta práctica.
• La readability de los textos. Traté este tema en mi artículo anterior Medición de la readability o comprensión de los textos en español. Estado actual y retos.
• Las características que deben tener los textos de los encabezados y enlaces (concisos, descriptivos, significativos fuera de contexto).
• El vídeo y la importancia de los subtítulos y la transcripción, una forma de consumir el contenido que mucha gente utiliza en contextos muy diferentes, más allá de que tengan o no una discapacidad. Repasa sus requisitos imprescindibles, así como el del reproductor, que debe ser operable por teclado. Incluye en su recomendación 4 reproductores concretos.
• Flow system. Incluye el código para ir creando una CSS robusta que permita que el contenido fluya regular, -siempre bien espaciado y legible-, independientemente de que se amplíe el texto o se vea en diferentes tamaños de pantalla. Trata con detalle cómo definir los márgenes de los elementos o cómo proteger el código de los párrafos vacíos desde la CSS.

Otro de los aspectos en los que insiste es en la necesidad de que los editores de contenido solo tengan que escribir, sin preocuparse de si rompen o no el diseño visual. Esto se tiene en cuenta en el código CSS que propone, y se consigue en gran de medida gracias a los selectores que utiliza, que hacen que el diseño se aplique de manera general, independientemente de los elementos que se incluyan con el editor.

Navigation Regions

En este capítulo explica cómo crear un menú principal y una tabla de contenidos dentro de las páginas. Ofrece una solución accesible, semántica y construida con un CSS robusto.

El autor parte de una lista de enlaces para, mediante mejora progresiva (Progressive Enhancement) , ir creando un sistema de navegación inclusivo.

Los temas que trata en el capítulo son:

• Correcto etiquetado HTML5 y el uso de Landmark Roles (puedes consultar mi artículo Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA))
• La importancia de seguir las convenciones.
• Dónde colocar los elementos, no solo visualmente, sino en el código, para no perjudicar a los usuarios que acceden por teclado.
• Cómo codificar y resaltar correctamente la opción en la que nos encontramos, y cómo hacerlo de una manera no solo visual.
• Cómo reducir la redundancia, con alguna idea bastante original.
• Los problemas que provoca que los enlaces a las anclas tengan asociado un efecto de scroll suavizado en vez del salto directo habitual.

A Menu Button

Este capítulo está dedicado por completo a cómo diseñar e implementar correctamente el navicon o icono hamburguesa. Las pautas son en realidad válidas para cualquier icono de una página.

Algunos temas que trata son:

• Desde un punto de vista del diseño: las convenciones, si es mejor acompañarlo del texto "menú" y/o recuadrarlo, o el tamaño que debe tener para una correcta interacción táctil.
• Desde un punto de vista del código: las diferentes maneras que hay de incluir y etiquetar el icono, y las ventajas y desventajas de cada una. Al final opta por los SVG sprites, incluyendo el código concreto a utilizar, de tal manera que sea una solución robusta y soportada por navegadores antiguos.
• Desde un punto de vista del comportamiento:
  • el código con el que incluir las opciones de menú que despliega el botón, siendo muy importante su orden dentro del código;
  • cómo ocultar las opciones de menú correctamente;
  • cómo comunicar el cambio de estado (abierto/cerrado) a los usuarios de productos de apoyo;
  • cómo hacer todo esto sin depender de JS o CSS, es decir, que sea accesible cuando el JS o la CSS falle;
  • etc.

Algunos de estos temas los traté en el artículo Responsive Design y accesibilidad

A List Of Products

Este componente es un listado de productos, de tal manera que cada uno de los productos tiene: título, imagen, características, call-to-action ("Comprar ahora") y valoración de los usuarios mediante estrellas. Ofrece el código concreto, con una estructura clara (con o sin CSS cargadas) y un etiquetado semántico.

Este capítulo le sirve para tratar diversos temas:

• Cómo incluir de forma correcta caracteres especiales.
• El texto alternativo de las imágenes en diferentes circunstancias, evitando siempre la redundancia. La primera lección que aprendemos en accesibilidad es que las imágenes deben tener texto alternativo, pero el hacerlo bien es lo que marca a menudo la diferencia (podéis consultar mi artículo Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online).
• La composición consistente en las diversas imágenes de un mismo producto.
• La optimización de las imágenes para su rápida descarga y adecuada para cada dispositivo. Recorre aspectos como la comprensión, el lazing loading o el elemento <picture>.
• El call-to-action ("Comprar ahora") le sirve para tratar errores habituales en el diseño e implementación de los enlaces:
  • los enlaces con el mismo texto,
  • los enlaces con href=javascript:;
  • los block-level links, es decir, la posibilidad de incluir en HTML5 todo el contenido del producto dentro del enlace que, aunque válido, tiene muchos inconvenientes.
  • etc.
• Datos estructurados, puesto que nuestra interface no es el único camino por el cual los usuarios encuentran y consumen nuestra información, en este caso, la información de nuestros productos.

A Filter Widget

En este capítulo se complementa el listado de productos con opciones de filtro y la posibilidad de visualizar el listado en formato lista o cuadrícula. Esto permite al autor insistir en la importancia de principios UX básicos como que el usuario pueda elegir o que tenga el control.

La solución que propone se basa de nuevo en la mejora progresiva, de manera que funciona sin CSS y sin JS, pero después añade ambas tecnologías para mejorar la experiencia.

Además, no es necesario un widget complicado construido a partir de JavaScript y ARIA, sino que sigue el principio básico de si puedes utilizar elementos y atributos HTML nativos, hazlo, no reinventes la rueda.

Este componente se convierte en un claro ejemplo de que a veces las cosas se pueden conseguir simplemente con HTML y CSS, sin necesidad de JavaScript o ARIA. Nos da una solución eficiente y robusta, accesible por teclado y para todos los usuarios, y sin dependencia de JS o CSS.

Este capítulo le sirve para repasar también otros temas:

• Las animaciones "Cargando contenido" y asociadas a las mismas las Live Regions (puedes consultar mi artículo Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente )
• La necesidad de un botón en todos los formularios, repasando todas las razones por las cuales no deberíamos eliminarlo.
• Las ventajas e inconvenientes de diferentes maneras de paginar los resultados del listado. El desplazamiento infinito secuestra la acción de desplazamiento del usuario para realizar un comportamiento inesperado, controlando al usuario y empeorando su experiencia. El botón "Cargar más" invita al usuario a realizar una acción explícita y por lo tanto se ajusta más al principio UX de dar el control al usuario.
• Vista lista/ Vista cuadrícula. Permite decidir al usuario sobre la forma en que quiere visualizar el resultado, aquella que se ajuste mejor a sus necesidades. Le sirve de pretexto para hablar en detalle de Flexbox, que nos permite tener una rejilla ordenada en cualquier resolución (con adaptación a los idiomas que se leen de derecha a izquierda como el árabe), un reflujo automático de columnas sensible al tamaño de la fuente o un ancho máximo para una lectura cómoda.
• La relevancia de que en los prototipos no pongamos texto idealizado, que después en la realidad puede provocar efectos indeseados. Propone evaluarlo con texto aleatorio mediante su librería JS forcefeed.js

A Registration Form

En este patrón implementa un formulario de registro, de manera que le sirve para repasar requisitos de accesibilidad y usabilidad que se han de tener en cuenta en los formularios.

Los temas que trata son:

• La convivencia del formulario de login y el formulario de registro en muchos sitios. Tras repasar los problemas de algunas soluciones habituales, el propone como una alternativa (no la única posible) incluirlos con dos pestañas. En realidad, esto le sirve para repasar la implementación adecuada de pestañas con WAI-ARIA.
• El correcto etiquetado de los campos de formulario.
• El atributo PLACEHOLDER que permite en HTML 5 incluir texto por defecto en el campo. Repasa sus problemas habituales y soluciones. También comenta alguna propuesta ingeniosa como el Float Label Pattern de Brad Frost.
• El correcto uso de fieldset/legend, cuándo es conveniente utilizarlo y cuándo su uso solo añade ruido.
• La implementación de los campos obligatorios. Repasa el uso del asterisco combinado con aria-required para una solución más robusta (lo traté en el artículo HTML5 y accesibilidad: nuevos tipos de input, atributos asociados y validación nativa)
• La implementación de la opción de visualizar el password que se introduce.
• La validación del formulario, a la que dedica buena parte del capítulo. Trata, por ejemplo:
  • la live región que tendrá los mensajes generales de error,
  • el uso de aria-describedby para los mensajes en línea (traté este atributo en el artículo Ayuda contextual de los formularios más accesible con "aria-describedby" (WAI-ARIA) ),
  • el aspecto visual de los mensajes y de los campos con errores,
  • la redacción de los mensajes de error,
  • la implementación correcta de una validación en línea que mejore el rendimiento y la experiencia. En concreto propone incluirla solo en la revisión de los errores, eliminando el error a medida que el usuario lo corrige.

Test-Driven Markup

El último capítulo del libro anima a los desarrolladores a crear su propio test de pruebas. Propone validar la estructura HTML de tu componente mediante una CSS de test que utilice selectores (expresiones basadas en condiciones) para resaltar los errores:

Como ejemplo, presenta y explica una CSS de test bastante compleja. Además, aunque los elementos con errores se resalten en la página, explica cómo podría usarse el inspector CSS de las herramientas de desarrollador como una consola JS, para poner allí los mensajes de error explicativos, en lugar de escribirlos en la página. Al final conseguiríamos algo como esto:

Aunque existen otras soluciones de terceros, alienta a escribir tus propias pruebas para tus propios patrones. El objetivo es que te vayas haciendo tu propia librería de patrones inclusivos con su test de prueba específico. Esto te asegura que, aunque tu patrón evolucione con el tiempo, su integridad se mantenga intacta.

Artículos relacionados:

• Reseña de “Pro HTML5 Accessibility”
• Plantilla base HTML accesible
• Landmark Roles (WAI-ARIA). Navegación más accesible y semántica en 2 minutos.
• Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente.
• Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página