Reseña de "Accessibility Handbook" de Katie Cunningham

Portada de Accessibility Handbook de Katie Cunningham

Autor: Katie Cunningham

Nº páginas: 98

Idioma: inglés

Formato: digital e impreso

Fecha de publicación: 2012

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

"Accessibility Handbook" se publicó hace ocho años, en 2012, pero sigue siendo muy útil como introducción a la accesibilidad web.

La mejor manera de que los desarrolladores comprendan la razón de ser de cada uno de los errores de accesibilidad que se detectan en las auditorías, es que comprendan cómo acceden las personas con diferentes discapacidades a la web y las barreras que se encuentran.

De lo contrario, las soluciones que les describen los auditores pueden parecerles confusas, o incluso erróneas, siendo frecuente que cometan nuevos errores en la implementación de las soluciones.

El libro es conciso, concreto y tiene numerosos ejemplos. Está estructurado en 5 capítulos, cada uno dedicado a un tipo de discapacidad:

Ceguera
Otras discapacidades visuales
Discapacidad auditiva
Discapacidad física
Discapacidad cognitiva

El autor repasa en cada uno de estos capítulos:

cómo acceden las personas con ese tipo de discapacidad a la web;
qué barreras se encuentran;
qué buenas prácticas pueden seguir los desarrolladores para facilitarles la percepción y la compresión de la información de la web, así como la interacción con la misma. Estas buenas prácticas beneficiarán también a muchas personas que, sin tener una discapacidad, sufren las mismas barreras en diferentes contextos de acceso.

El libro también tiene sus limitaciones:

Hay muchos temas en los que no se profundiza, por ejemplo, la introducción a WAI-ARIA es muy breve y no se tratan aspectos importantes como los landmark roles, o los atributos aria-label, aria-labelledby o aria-describedby, que en los desarrollos actuales es imprescindible conocer. También se deja temas en el tintero como, por ejemplo, la accesibilidad de los documentos o de los ficheros SVG. Os recomiendo los artículos de este blog sobre WAI-ARIA y sobre Accesibilidad de documentos digitales.
Se incluyen muchos ejemplos de páginas web y de código, pero el tiempo no pasa en balde, y algunos pueden estar algo desfasados. Por ejemplo, al tratar el tema de las descripciones de las tablas se habla del atributo summary, que ya no es admitido en HTML 5. Más información en: Descripción de las tablas en HTML5. Alternativa a "summary"
Hay temas a los que hoy en día ya no daríamos tanta relevancia, como es Flash, pero, sin embargo, trataríamos otros temas mucho más a fondo, por ejemplo, los relacionados con la accesibilidad en dispositivos móviles. Os recomiendo los artículos sobre Accesibilidad y móvil.

A pesar de todo, creo que el libro sigue siendo muy útil como introducción a la accesibilidad web, especialmente para:

Desarrolladores.
Personas que gestionan proyectos que deben cumplir con los criterios de accesibilidad o que quieren "vender" internamente la necesidad de que los desarrollos sean accesibles.

Sin embargo, el libro se quedará corto para las personas que ya estén familiarizadas con la accesibilidad, a menos que les interese un repaso general por los aspectos más relevantes.

A continuación, resumo cada capítulo, proponiendo en algunos casos recursos de apoyo que los complementen:

Ceguera
Otras discapacidades visuales
1. Baja visión
2. Daltonismo
Discapacidad auditiva
Discapacidad física
Discapacidad cognitiva
1. Dislexia
2. ADHD (Attention Deficit Hyperactivity Disorder) and ADD (Attention Deficit Disorder)
Vender accesibilidad
Recursos adicionales

Ceguera

Un usuario no debería perder ningún contenido o funcionalidad simplemente por la herramienta que está utilizando. El objetivo de este capítulo es crear un sitio web perceptible, comprensible y operable cuando se accede mediante un lector de pantalla o una línea braille.

Un lector de pantalla es el programa que utilizan, entre otras, las personas ciegas para acceder a la web. No solo lee el contenido de la página o del documento, sino que anuncia de qué tipo es cada elemento (encabezado, lista, cita, etc.).

Por otra parte, no se trata de una escucha pasiva, sino que el usuario, mediante atajos de teclado, puede saltar de elemento en elemento, según su tipo (encabezados, imágenes, etc.), o bien mostrar una lista de los diferentes tipos de elementos de la página (un listado de las zonas semánticas, de los enlaces, de los encabezados, etc.)

Principales barreras que se encuentran las personas con ceguera

El autor explica cómo funciona un lector de pantalla, cuáles son los principales lectores de pantalla y las barreras que se encuentran sus usuarios:

HTML mal estructurado.
Imágenes sin texto alternativo significativo.
Flash inaccesible.
Características que requieren visión, o donde el feedback está mal implementado.
Elementos repetitivos que no se pueden omitir.
Formularios mal estructurados.

Buenas prácticas para mejorar la accesibilidad para las personas con ceguera

Las buenas prácticas que se tratan en este capítulo son:

HTML y Formato:

Orden lógico de lectura: estructura el código HTML como lo harías si la página se fuera a imprimir sin formatear o se fuera a visualizar sin CSS.
Texto oculto: hay diversas formas de ocultar contenido de la página. Depende de la técnica que se utilice, el contenido se ocultará visualmente pero el lector de pantalla lo anunciará; o se ocultará visualmente y para el lector; o el contenido será visible pero el lector de pantalla lo ignorará. Hay que tener claro en cada caso qué técnica de ocultación usar. Artículo recomendado: Ocultar contenido visualmente y/o para el lector de pantalla (tabla resumen).
Encabezados: la página tiene que estar correctamente estructurada con encabezados (h1, h2, h3…)
Saltar la navegación: se trata la opción de incluir un enlace inicial para saltar el contenido. No se trata el uso de landmarks roles o zonas semánticas de la página. Artículo recomendado: Landmark Roles (WAI-ARIA). Navegación más accesible y semántica en 2 minutos.
Tablas: se deben usar para incluir datos tabulares y hay que codificarlas adecuadamente. Se habla del atributo summary, pero este atributo ya no está permitido en HTML5. Actualmente se opta por incluir la descripción con aria-describedby. Artículo recomendado: Ayuda contextual de los formularios más accesible con "aria-describedby" (WAI-ARIA)
Imágenes: resume lo básico sobre la descripción de las imágenes. Creo que se deja muchas cosas por decir. Artículo complementario recomendado: Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online
Gráficos y diagramas: se centra en gráficos incluidos mediante una imagen y con un pie de foto. El código con el que los incluye se queda obsoleto, hoy lo incluiríamos con figure/figcaption; y hablaríamos de SVG y accesibilidad. Artículo recomendado: HTML 5 y accesibilidad
Formularios: habla sobre cómo etiquetar los campos (pero solo trata la etiqueta label) y de que es necesario explicar los errores con texto. Trata el uso de captcha de imagen, sonoro o de campo oculto, pero hoy en día haríamos una mención especial al recaptcha de Google.
JavaScript: según la encuesta de Webaim de 2019, en el que el 87.6% de los participantes son usuarios con discapacidad que usan un lector de pantalla, el 99.3% de los encuestados navega con JS activo. Las WCAG no obligan a que la página funcione sin JS si este se hace accesible de forma nativa con WAI-ARIA. A pesar de todo, un 0.7% de los usuarios agradecerán que programes según el principio de mejora progresiva.
Frames e iframes: deben tener un title; hay que dar un nombre significativo a la página que cargan; y escribir un mensaje entre las etiquetas de apertura y cierre.
Flash: se puede hacer accesible de forma nativa; además, debe ser accesible por teclado, no reproducir sonido por defecto y no usarse nunca para la navegación.
Accesskeys: lista cuáles son las más las habituales, que no se corresponden al 100% con el que fue el estándar de accesskey del Gobierno de Reino Unido.

WAI-ARIA: hace una introducción muy básica. Artículos de este blog relacionados con ARIA,
Testing: lista algunos validadores automáticos. Podéis consultar mi recopilación de validadores automáticos de accesibilidad. Las limitaciones de los validadores automáticos son muchas, por eso, propone también ciertas pruebas manuales sobre todo usar el lector de pantalla para acceder a la página.

Otras discapacidades

En este capítulo trata la baja visión y el daltonismo.

Baja visión

Principales barreras que se encuentran las personas con baja visión

Las barreras habituales que se encuentran las personas con baja visión en la web son:

Sitios que pierden funcionalidad o contenido cuando se cambia el tamaño de fuente (habría que añadir también cuando se hace zoom).
Colores que no contrastan lo suficiente.
Sitios donde los estilos predeterminados no pueden ser anulados.
Texto en imágenes.
Formularios confusos.

Buenas prácticas para mejorar la accesibilidad para las personas con baja visión

Trata los siguientes temas:

Crecer con gracia: todo el texto debe crecer con las opciones del navegador (o una herramienta propia de la página) sin cortes, solapamientos o desbordamientos.
Contraste: el color del texto debe contrastar con el color del fondo. Este apartado se queda escaso, pues no indica ratios mínimas de contraste ni herramientas. Podéis consultar mi recopilación de herramientas relacionadas con el color.
Anulaciones: no impedir que el usuario pueda personalizar el estilo de la página, por ejemplo, con sus propias CSS. Si hay texto en las imágenes, este texto no se podrá personalizar con otro tamaño, otra fuente u otro color.
Formularios: se tiene que percibir claramente qué elementos del formulario tienen el foco.

Daltonismo

Explica qué es el daltonismo y los principales tipos de daltonismo que existen.

Principales barreras que se encuentran las personas daltónicas

Las principales barreras que se encuentran las personas daltónicas al acceder a la web son:

Esquemas de color que no tienen suficiente contrate.
Figuras, como gráficas o mapas, en las que la información se transmite solo por el color; o que son confusas, por ejemplo, al imprimirlas en blanco y negro.
Imágenes con poco contraste.

Buenas prácticas para mejorar la accesibilidad para las personas daltónicas

Los temas que trata son:

Optimización del esquema de color: recomienda herramientas de simulación del daltonismo.
Optimización de imágenes: sus elementos deberían tener suficiente contraste y los códigos de color deberían ser comprensibles para las personas daltónicas.

Trata específicamente los diagramas, gráficos y mapas, con ejemplos concretos. Podéis consultar mi recopilación de herramientas relacionadas con el color.

Discapacidad auditiva

Principales barreras que se encuentran las personas con discapacidad auditiva

Las principales barreras que se encuentran las personas con discapacidad auditiva son:

Vídeos sin subtítulos.
Vídeos con subtítulos deficientes.
Funciones interactivas sin alertas visuales.
Comunicación bidireccional de audio y/o vídeo en tiempo real de baja calidad.

Creo que el autor también debería hablar de que las personas sordas de nacimiento tendrán más dificultades para comprender los textos largos y complejos, y que para muchas de ellas sería de gran ayuda vídeos en lenguas de signos o textos en lectura fácil. Artículo recomendado: Lectura Fácil. Pautas y recomendaciones. UNE 153101:2018 EX

Todas las buenas practicas también serán útiles para las personas que, por el contexto desde el que acceden, no tienen acceso al vídeo o al sonido.

Buenas prácticas para mejorar la accesibilidad para las personas con discapacidad auditiva

Los temas que trata son:

Vídeos: solo trata los subtítulos. Podéis ampliar información en los artículos:

Características interactivas: trata las alternativas a las alertas sonoras.
Comunicación bidireccional de audio y/o vídeo: es importante que la calidad y el tamaño sea el adecuado para que puedan usarlo las personas que utilizan la lengua de signos o que leen los labios; y debería tener transcripción en vivo. Actualmente, en Europa, la norma EN 301 549 regula este tipo de comunicaciones en su capítulo 6.

Discapacidad física

Hace referencia a las personas que tengan temblores, poca precisión en el movimiento, que hayan perdido una extremidad, con parálisis cerebral … pero las buenas prácticas también beneficiarán a las personas que se hayan roto el brazo, se les haya estropeado el ratón o el teclado o que estén acostumbradas a trabajar con el teclado en el portátil. Por otra parte, hay que tener en cuenta que las personas invidentes solo usan el teclado, nunca el ratón.

Principales barreras que se encuentran las personas con discapacidad física

Las principales barreras que se encuentran las personas con una discapacidad física que afecte a las extremidades superiores son:

Interfaces que requieren obligatoriamente el uso del ratón.
Interfaces que requieren obligatoriamente el uso del teclado.
Elementos que necesitan un alto nivel de precisión, por ejemplo, iconos muy pequeños.
Elementos que se activan fácilmente, pero son difíciles de cerrar.

Buenas prácticas

Los temas que trata son:

Formularios: todos los campos deben ser accesibles con el teclado en un orden lógico. El usuario debe distinguir en todo momento qué elemento tiene el foco.
Ventanas emergentes: si se muestran solo en el mouseover no podrán abrirse con el teclado. Por otra parte, el botón de cerrar deberá tener un tamaño adecuado (os recuerdo que el mínimo de las WCAG es 44*44 píxeles). La ventana también debería cerrarse al pulsar la tecla ESC.
Navegación: el menú debe ser accesible por teclado. Los menús que se despliegan/ocultan en el mouseover/ mouseout pueden dar problemas a las personas con temblores.
Moverse por la página: no se debe usar outline:0 para ocultar el foco.
Tiempo: es muy probable que las personas con una discapacidad física tarden más en realizar las tareas, por ello es importante que los límites de tiempo que impone el sitio no supongan una barrera.

Estas buenas prácticas son sencillas de testear, basta con acceder solo con el teclado, sin ratón. También puede probarse a acceder al sitio usando la mano no dominante. Os recomiendo la extensión Funkify, que permite simular el acceso con temblores.

Discapacidad cognitiva

Solo trata la dislexia y el déficit de atención. Os recomiendo los artículos de este blog relacionados con la discapacidad cognitiva.

Dislexia

La problemática de las personas con dislexia puede ir más allá de la lectura, e incluir dificultad en la capacidad de organizar la información, de concentrarse o de mantener un mapa mental.

Las buenas prácticas que trata son:

Tipografía: usan fuentes sans serif como Arial o Verdana. También es importante permitir que puedan cargar sus propias CSS, por ejemplo, porque el texto no esté en imágenes.
Redacción: redacta con frases y párrafos cortos.
Color: el contraste de color blanco y negro no es el más adecuado para las personas con dislexia y genera fatiga visual.
Evitar el texto justificado.
Imágenes: si son significativas ayudan a retener más contenido y a escanear la información, de lo contrario, solo distraen y dificultan la compresión. Puede ser útil el uso de iconos acompañando a las etiquetas de texto. Web recomendada ARASAAC. Recursos gratuitos para la accesibilidad cognitiva como pictogramas.
Animaciones: pueden suponer una distracción, pero si están bien diseñadas pueden agregar más significado y valor sin causar un estrés excesivo a los lectores con dislexia. También ofrece consejos para el caso de que el sitio tenga anuncios de terceros de los que se obtienen beneficios.
Versión de impresión: muchas personas con dislexia optan por imprimir las páginas para leerlas en papel. En la versión para impresión es importante el tamaño de letra o la longitud de las líneas de texto, que recomienda no exceda de 60 o 70 caracteres.
Navegación: la opción de búsqueda del sitio les puede suponer un problema si es sensible a las faltas de ortografía. Es importante tener un buen sistema de navegación consistente y un mapa web.

ADHD (Attention Deficit Hyperactivity Disorder) and ADD (Attention Deficit Disorder)

Hay ciertas buenas prácticas que benefician tanto a las personas con dislexia como a las personas con ADHD y ADD:

Oración y longitud del párrafo: ambos deben ser cortos.
Animaciones: las animaciones deben ser las mínimas posibles y evitar que se reproduzcan automáticamente.
Fondos: deben evitarse los fondos.
Navegación: debe ser global y coherente.

Otros temas que trata son:

Tiempo: pueden requerir más tiempo para realizar las tareas; un formulario muy largo les será más sencillo dividido en partes, más fáciles de enfocar, con menos distracciones y una barra de progreso.
Instrucciones complejas: resultarán problemáticas. Si se formatean como listas resultan más sencillas. También se pueden complementar con instrucciones en vídeo.
Organización: el contenido debe estar bien organizado y las páginas no deben ser demasiado largas. Se debe resaltar el texto importante.
Experiencia de usuario consistente: tanto en la apariencia como en la navegación.

Vender accesibilidad

¿Por qué hacer el esfuerzo de diseñar e implementar sitios accesibles?

Imperativo legal. Artículo recomendado: Legislación sobre accesibilidad web en España, Europa y otros países
La exclusión puede dañar su negocio, para algunos usuarios los errores serán molestos, para otros una barrera que imposibilitará llevar a cabo las tareas para las que accedió a la web.
El sitio accesible es más útil para todos, se pueden arreglar muchas cosas sin mucho esfuerzo para que sea menos molesto para los clientes.

Si quieres consultar muchas más razones, las tratamos en el libro Accesibilidad web. WCAG 2.1 de forma sencilla".

Recursos adicionales

En el último capítulo recomienda recursos y herramientas.

En el apartado “Recursos” de Usable y accesible donde encontraréis descargas, reseñas de libros, un glosario con más de 600 entradas, un listado de validadores y herramientas y enlaces de interés.