jueves, 18 de junio de 2020

Reseña del libro "Accessibility for everyone" de Laura Kalbag

Portada del libro 'Accessibility for everyone' de Laura Kalbag

Autor: Laura Kalbag

Nº páginas: 168

Idioma: inglés

Formato: digital e impreso

Fecha de publicación: 2017

Web: Ficha en A Book Apart

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

"Accessibility for everyone" es un libro que recomiendo a cualquier persona que quiera introducirse en el mundo de la accesibilidad web. 

El libro hace un repaso por la mayoría de los temas que deben conocerse, pero sin profundizar demasiado en ninguno de ellos. Es sencillo de entender y no usa un lenguaje técnico.

Por tanto, no aportará demasiado a las personas que ya tengan conocimientos de accesibilidad web, ni a los desarrolladores o diseñadores que busquen un libro más técnico o con ejemplos concretos, para ello os recomiendo otros libros (ver "Libros y reseñas").

El libro se estructura en 7 temas que resumo a continuación.

Tema 1. Considerando la accesibilidad

El mensaje más importante de este capítulo es que la accesibilidad no es responsabilidad de un desarrollador que repara todos los errores.

  • Los product manager, los responsables del contenido y los arquitectos de información diseñan el contenido y la estructura en base a la información y los objetivos proporcionados por los researchers y los ejecutivos. Todos ellos deben comprender y tener en cuenta los requisitos de accesibilidad.
  • Los responsables del contenido deben escribir de manera clara y fácil de comprender.
  • Los diseñadores deben hacer el contenido legible y usar bien el color.
  • Los desarrolladores deben implementar páginas que sean accesibles por teclado, por los lectores de pantalla u otros productos de apoyo.

Cada decisión del equipo afecta a la accesibilidad del sitio, por tanto, la accesibilidad no puede abordarse fuera del proceso de creación del sitio web.

La autora desmonta las excusas habituales para no hacer sitios accesibles. Explica la diferencia entre accesibilidad y diseño universal, así como la importancia de la empatía para no crear productos que se ajusten solo a nuestras necesidades.

En este capítulo también repasa los diferentes productos de apoyo o formas de acceso y qué personas las utilizan: lector de pantalla, acceso por teclado, pulsadores, eye tracker, reconocimiento de voz, magnificadores de pantalla, etc.

Tema 2. Discapacidades y limitaciones

En EEUU el 12% de la población tiene una discapacidad, en Reino Unido el 16% de los adultos en edad de trabajar. 

Partiendo de la definición de discapacidad, recorre los diferentes tipos de discapacidad: visuales, auditivas, motoras, cognitivas, desordenes vestibulares (artículo relacionado: Scrolljacking y Parallax Scrolling en accesibilidad web. Peligro para personas con desordenes vestibulares, epilepsia y migrañas).

También repasa los problemas derivados del contexto de acceso según: el dispositivo o el software utilizado; la conectividad del usuario; su idioma materno; cómo accede y desde dónde; si sufre alguna  enfermedad o ha tenido un accidente; su edad; las preferencias de acceso de cada uno; etc.

Tema 3. Planificando para la accesibilidad 

Incorporar la accesibilidad al comienzo del proyecto es más facil, más efectivo y más barato. 

Además, la accesibilidad proporciona una serie de beneficios extras:

  • impacta positivamente en el posicionamiento;
  • mejora la usabilidad y, por tanto, reduce los costes en otros ámbitos, como en la atención al cliente;
  • el sitio es más competitivo;
  • cumple con la normativa legal.

Para integrar la accesibilidad en el proceso de desarrollo propone:

  • Construir el equipo: todo el equipo tiene que estar involucrado en la accesibilidad del sitio, cada uno en el ámbito de su responsabilidad, liderados por un experto en accesibilidad digital.
  • Alcance del proyecto: al comienzo del proyecto se toman muchas decisiones que tendrán un impacto en el enfoque de la accesibilidad y los esfuerzos necesarios para lograrla. Se deben transmitir eficazmente los requisitos de accesibilidad al equipo e informar de forma temprana del impacto en el presupuesto. Por ejemplo, si será necesaria formación o crear alternativas accesibles para los vídeos.
  • Investigación con usuarios: recomienda el libro Just Ask: Integrating Accessibility Throughout Design, 2007 de Shawn Lawton Henry, que reseñé hace tiempo. Lo que aprendes en la investigación es acumulativo, te sirve de un proyecto para otro. También puedes aprovechar la investigación UX con usuarios para incluir en la misma a personas con diferentes discapacidades o limitaciones.
  • Producción y desarrollo: los frameworks, las tecnologías, las herramientas, el CMS o el editor de texto que se seleccionan, pueden tener un gran impacto en la accesibilidad. Es importante testear con diferentes productos de apoyo y en diferentes contextos de acceso.
  • Mantenimiento: la autora comenta los beneficios de tener una política de accesibilidad y cómo debería ser. Pone el ejemplo del portal Post Office de Reino Unido, que sigue la norma "BS 8878:2010 Web Accessibility. Code of Practice" para integrar la accesibilidad en todo el ciclo de vida de un producto web. Lo traté en el artículo BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web 
  • Justifica tus decisiones de accesibilidad: a ti mismo, a tu equipo, a tus clientes y a todos las personas involucradas. 

Tema 4. Contenido y diseño

Las decisiones de diseño hechas en nombre de la accesibilidad benefician a todas las personas. Para mejorar la experiencia de todas ellas podemos poner el foco en la usabilidad, haciendo sitios que sean fáciles de ver, de oír, de comprender y de interactuar con ellos.

Muchos de los principios para hacer sitios más accesibles son comunes a los principios para hacer los sitios más usables:

  • Affordance y convenciones para que las personas reconozcan los elementos de la interfaz e intuyan su función.
  • Navegación y orientación: es más difícil que una persona se pierda en una página con una sólida arquitectura de información, por ello, tenemos que proporcionarle caminos consistentes, para que sepa en todo momento dónde está y encuentre lo que necesita (artículo relacionado: Arquitectura de información. Fundamentos)  La autora habla del menú de navegación; los títulos; el aspecto y redacción de los enlaces; o las migas de pan, especialmente importantes para las personas con problemas de memoria o confusión, como las personas con síntomas de demencia.
  • Redacción: el contenido debe ser comprensible, útil y apropiado para tu audiencia. Trata la jerarquía y la estructura del contenido, así como el uso de un lenguaje sencillo y conciso.
  • Tipografía: es relevante su tamaño; su grosor; la longitud de las líneas; y que crezca en todos los contextos, por ejemplo, en móvil no se debe impedir el zoom (artículo relacionado Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes). Dedica un apartado específico a las fuentes de iconos y a los problemas que pueden dar según su implementación.
  • Diseño de interacción: se centra en la importancia de dar tiempo al usuario para hacer las tareas y leer el contenido, algo que resulta difícil, por ejemplo, en los carruseles si no se pueden parar. Otros temas que abarca son: evitar que los usuarios comentan errores en los formularios y ayudarles a reponerse de ellos rápidamente; o la importancia de que los mensajes y las alertas del sitio sean comprensibles y todas las personas puedan percibirlos, por ejemplo, si acceden con un lector de pantalla.
  • Color: trata el contraste de color. Hay que recordar que el contraste blanco y negro no es el más adecuado, por ejemplo, para las personas con síndrome de Irlen. También habla de la importancia de no transmitir la información solo con el color. 
  • Rich media
    • Imágenes: aborda temas como el texto alternativo en las imágenes, las imágenes de texto y los gráficos e infografías.
    • PDF: en este caso no estoy de acuerdo con la autora, que en vez de hablar de los PDF accesibles de forma nativa, propone poner la información en HTML en vez PDF, convirtiendo los PDF en HTML mediante algún programa. Si bien es cierto que a veces se incluye información en un PDF cuando podría haberse incluido en una página HTML, en otros muchos casos el PDF es necesario. En estos casos, la conversión de PDF a HTML suele generar un código muy malo, y resulta tanto o más costoso convertir el HTML en accesible que convertir el propio PDF en accesible de forma nativa. Lo que hay que hacer es formar a los editores en las buenas prácticas que deben seguir en los programas de origen para que el PDF generado sea lo más accesible posible, de modo que el trabajo para mejorar su accesibilidad con Acrobat Professional sea mínimo.
    • Subtítulos y transcripciones para vídeos y audios, necesarios, por ejemplo, para las personas sordas, pero que resultan muy útiles para cualquiera de nosotros en determinados contextos: ayudan a concentrarse en lo que se dice en el audio, especialmente si no es tu idioma materno; puedes leerlos si estás en un ambiente ruidoso o en uno en el que se ha de guardar silencio y no tienes auriculares; etc.
La autora da apuntes concisos y generales sobre cada punto, pero sin entrar en mucho detalle en ninguno de ellos.

Tema 5. Accesibilidad y HTML

Para que la página pueda ser correctamente interpretada por el navegador y los productos de apoyo o los crawlers, deberá seguir los estándares y tener una estructura correcta.

Los aspectos de accesibilidad generales al implementar las páginas en HTML son: 

  • Estructura: visualiza la página sin CSS para comprobar que la página tiene una estructura correcta, está bien jerarquizada y los contenidos se encuentran en un orden lógico. Así es cómo leerá la página un lector de pantalla o una araña como GoogleBot, por eso la accesibilidad mejorará también el posicionamiento (artículo relacionado "Accesibilidad y SEO" (PDF, 248)). La página debe tener un buen título; la información más importante debe situarse arriba; tiene que estar estructurada con encabezados; y se deben utilizar las listas cuando sea necesario, pues así la información es más fácil no solo de ojear y de comprender, sino también de acceder y saltar con el lector de pantalla.
  • Formularios: utiliza siempre que se pueda los elementos estándar de los formularios, etiquétalos e indica los campos obligatorios.
  • Acceso por teclado: trata aspectos como los atajos de teclado y las accesskey; los enlaces para saltar al contenido; la importancia del foco en el acceso por teclado, que debe ser visible; o el uso de tabindex= 0 / -1. Esto último lo trato en el artículo WAI-ARIA. Introducción, referencias, ejemplos, herramientas 
  • Separación del contenido y la presentación: se debe trabajar con CSS; no usar los estilos para simular etiquetas, por ejemplo, un tamaño de letra grande para simular un <h2>; y no usar una etiqueta para dar al texto un estilo concreto, por ejemplo <blockquote> para indentar un texto si este no es realmente una cita. 
  • Mejora progresiva y degradación elegante:  trata la diferencia entre ambos términos, siendo siempre más recomendable la mejora progresiva (artículo recomendado Reseña del libro "Designing with progressive enhancement").
  • WAI-ARIA: hace una breve introducción al estándar.

Tema 6. Evaluación y testing

Se debe tener un plan de evaluación y testing, para ello hay que:

  • definir los métodos que se van a utilizar y cuándo se llevarán a cabo; 
  • cómo se documentarán los resultados;  
  • cómo se usará el feedback para mejorar.

Repasa diferentes métodos de análisis y evaluación, así como herramientas de apoyo. 

Propone usar una matriz para validar, como la de Anne Gibson en Reframing Accessibility for the Web, aunque personalmente me gusta la que propone ella en la pagina 126.

Matriz de revisión de accesibilidad. En el eje vertical los dispositivos de entrada (teclado, ratón...), en el horizontal los de salida (monitor con paleta para personas daltónicas, lector de pantalla,... )

Matriz de revisión de accesibilidad de Anne Gibson en A list Apart

Sobre las herramientas para medir la comprensión de los textos, hay que tener en cuenta que en español hacen falta algoritmos específicos, lo traté en: Medición de la readability o comprensión de los textos en español. Estado actual y retos.

Tema 7. Leyes y pautas

Repasa brevemente leyes de accesibilidad en EEUU y Reino Unido, con ejemplos de denuncias por falta de accesibilidad en sitios web. Podéis consultar una recopilación extensa de leyes en el artículo Legislación sobre accesibilidad web en España, Europa y otros países.

Después hace una breve introducción a la estructura de las WCAG.

Artículos relacionados

3 comentarios :
Emma dijo...

¿Cuándo instalaste el paquete tuviste algún problema? Nos da el siguiente error y no avanzamos
[ERROR] Failed to execute goal on project intav-core: Could not resolve dependencies for project es.minhap.oaw:intav-core:jar:5.1.0: Failure to find javax.jms:jms:jar:1.1 in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]
Lo queremos usar para analizar la accesibilidad de la página web de la universidad

Anónimo dijo...

A mi también me da el mismo fallo, habéis conseguido arreglarlo?

[ERROR] Failed to execute goal on project intav-core: Could not resolve dependen
cies for project es.minhap.oaw:intav-core:jar:5.0.4: Could not find artifact jav
ax.jms:jms:jar:1.1 in central (https://repo.maven.apache.org/maven2), try downlo
ading from http://java.sun.com/products/jms/docs.html -> [Help 1]

Olga Carreras dijo...

Sí, daba errores, pero tocando código y la base de datos pudo resolverlos. Fue difícil pero posible.

Publicar un comentario