Reseña "Inclusive Design Patterns. Coding Accessibility Into Web Design"

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.

En relación con esta manera de abordar la accesibilidad hay una reflexión que me parece muy relevante.

Los consultores de accesibilidad estamos acostumbrados a hacer auditorías de accesibilidad en base a las WCAG 2.0, y por ello a evaluar por los principios, pautas y criterios en los que se organizan las WCAG 2.0.

Sin embargo, la presentación de los resultados a los desarrolladores que van a corregir los errores hay que plantearla de otro modo.

Imaginemos un botón que incumple tres o cuatro criterios de las WCAG. Si organizamos los resultados por criterios, en una tarea les diremos que mejoren la etiqueta del botón; en una tarea distinta (que puede ser resuelta por un desarrollador diferente), o 20 páginas más adelante en el informe, les diremos que ese botón debe poder coger el foco; y luego en otra, más adelante, les decimos que el código asociado a ese botón no es válido y que tienen que hacer determinado cambio en el HTML, etc.

Eso no es práctico.

Si se aborda el botón como un componente (pattern) podemos explicar todos sus problemas de manera unitaria, recomendando enfoques y técnicas alternativas.

De esta manera los errores del botón se solucionarán mejor y más rápido. Les das una solución completa e integrada, un modelo a seguir que les permita tomar decisiones futuras con confianza.

Sin duda esto vuelve nuestro trabajo más agradable, eficaz y gratificante, porque no solo auditas, sino que formas.

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 <h1>, 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.
• <article>, 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:

[undesired pattern] {
/* error style, such as
outline: 0.5em solid red;
*/
}


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:

• Podéis consultar más reseñas de libros en: "Libros y reseñas"
• Novedades WAI-ARIA 1.1
• 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
• Reseña del libro "Inclusive Components" de Heydon Pickering