Reseña de “Pro HTML5 Accessibility”

Portada del libro Pro HTML5 Accessibility

Autor: Joshue O’Connor

Nº páginas: 386

Idioma: inglés

Formato: ebook y libro impreso

Fecha de publicación: 26 de marzo de 2012

Este es uno de los mejores libros que me he leído en el último año, detallado y útil de verdad. No tirarás el dinero comprándolo, solo es necesario saber inglés.

Se lo recomiendo a los desarrolladores que trabajan o van a trabajar con HTML5, como una gran introducción a la accesibilidad web y a cómo tenerla en cuenta en sus aplicaciones, incluso si no son en HTML5.

Y desde luego se lo recomendaría a todas las personas que se dedican a la accesibilidad web, porque HTML5 ya no es el futuro, es el presente.

A mucha gente le asusta en un principio el tema, pensando que todo va a ser nuevo. Pero la realidad es que todo lo que sabemos y aplicamos hasta el momento sigue siendo válido y nos sirve de base, porque las personas con discapacidad siguen accediendo de la misma manera a nuestros sitios web y siguen encontrando los mismos problemas.

Si dominas (X)HTML, WAI-ARIA y las WCAG 2.0 no son tantas cosas nuevas las que hay que aprender. La mayor preocupación suele ser el soporte de HTML5 en los diferentes navegadores y productos de apoyo, asegurando la compatibilidad mediante la estrategia de diseño y desarrollo que conocemos como mejora progresiva (progressive enhancement)

El libro se divide en 10 capítulos. A continuación resumo de qué se trata cada uno de ellos.

Capítulo 1. Introduction to HTML5 Accessibility

Este capítulo es una introducción a HTML5 y a la accesibilidad web.

Comienza con un repaso a las diferencias entre (X)HTML y HTML 5, con una introducción a la sintaxis y a los nuevos elementos y atributos de HTML5. Una referencia de interés es el documento del W3C: HTML5 differences from HTML4

El capítulo también se centra en introducir qué es la accesibilidad web, los beneficios que reporta, la legislación relacionada o las WCAG 2.0

Si necesitáis información concreta sobre la legislación española en materia de accesibilidad web o las certificaciones que existen, os recomiendo mis artículos: Referencia sobre legislación española relacionada con la accesibilidad web y Metodologías, certificaciones y entidades certificadoras de la accesibilidad web en España que actualizo en cuanto hay novedades sobre la materia.

En este capítulo hace referencia ya a dos ideas importantes que se irán repitiendo a lo largo del libro:

El uso de la mejora progresiva (progressive enhancement), una estrategia de diseño y desarrollo que permita el uso de HTML5 de forma compatible con diferentes navegadores y productos de apoyo, hablando por ejemplo de Modernizr. En el vídeo “HTML5: Nuevas funcionalidades en formularios 2ª parte” de Mar Martínez para el MOOC iDESWEB, podéis encontrar sitios de referencia para conocer el soporte de HTML5 en los principales navegadores y una breve introducción sobre qué es Modernizr y los Polyfills.
Nuestra preocupación real debe ser hacer sitios accesibles y no que pasen un validador. Habla de los semantics ninjas obsesionados con el código válido, cuando en la mayoría de los casos esto no tiene que ver con el mundo real de la accesibilidad web, y de hecho las WCAG 2.0 son más permisivas en este sentido que las WCAG 1.0 También recomienda testear siempre que se pueda con usuarios.

Capítulo 2: Understanding Disability and Assistive Technology

No se puede comenzar a hablar de accesibilidad y HTML 5 sin comprender los diferentes tipos de discapacidad qué existen ni cómo acceden al contenido las personas con discapacidad.

En este capítulo el autor aborda muy detalladamente estos aspectos. Hace un repaso de los diferentes tipos de discapacidad, explica qué son los productos de apoyo (AT) y cuáles son los más utilizados. Destaca la explicación que realiza de los principales lectores de pantalla, las diferencias entre ellos y cómo manejarlos.

Capítulo 3: Javascript isn’t a dirty word and ARIA isn’t just beautiful music

Me encanta el título de este capítulo. Como se intuye, está centrado en WAI-ARIA y en la accesibilidad en relación con el javascript, que siempre es el aspecto más complejo a la hora de abordar la accesibilidad de una aplicación web.

Comienza defendiendo la utilidad de javascript cuando está bien usado. El 98% de los usuarios navega con compatibilidad con javascript, el problema ya no es tanto que esté desactivo, sino que no suponga una barrera de accesibilidad para las personas que utilizan productos de apoyo. De hecho, una de las grandes novedades de las WCAG 2.0 es que reconoce tecnologías compatibles con la accesibilidad, entre las que podemos considerar el javascript. Por ello el autor explica qué es WAI-ARIA y su importancia para hacer las aplicaciones web accesibles, pues permite informar del propósito, estado y propiedades de los elementos dinámicos e interactivos.

Por ejemplo, una diferencia entre (X)HTML y HTML5 es que en (X)HTML solo pueden coger el foco nativamente los enlaces y los controles de formulario, y con HTML5 el foco lo pueden coger más elementos. Esto no implica que sea más accesible, solo lo será si se informa a la API de accesibilidad de su rol, estado y propiedades, y esto no siempre ocurre. Por ello vuelve a hacer hincapié en el principio de mejora progresiva: defiende que los contenidos deben estar siempre disponibles aunque el javascript no funcione, lo cual además mejora el SEO de nuestra web.

Tampoco podía dejar de mencionar la importancia del uso de javascript no intrusivo y de un código limpio. El autor explica por qué no debe usarse <noscript>, elemento que todavía está permitido en HTML5.

Repasa los principales problemas de accesibilidad relacionados con el uso de javascript y las técnicas Client-Side Scripting de las WCAG 2.0, que se aplican igual en HTML5. También repasa la accesibilidad de diferentes toolkits (DOJO, JQuery o Fluid)

En el resto del capítulo se centra en WAI-ARIA, da ejemplos de uso o de cómo es anunciado por los productos de apoyo, muestra cómo se puede usar de forma complementaria con HTML5 para asegurar la compatibilidad con diferentes versiones de navegadores y productos de apoyo.

Podéis consultar todos mis artículos sobre WAI-ARIA en: Índice temático: Accesibilidad y JavaScript / Ajax / WAI -ARIA

Capítulo 4: API and DOM

En este capítulo explica cómo funcionan internamente los navegadores, qué son las APIs de accesibilidad y cómo trabajan (también hace un repaso de las diferentes APIs de accesibilidad que hay), que es el DOM, cómo se comunican los navegadores y los productos de apoyo, qué productos de apoyo usan OSM (Off-Screen Model) o qué es el virtual buffer.

Un documento de gran interés es HTML to Platform Accessibility APIs Implementation Guide, muy útil para verlo en formato tabla. También recomienda herramientas como INSPECT 32 (Win) y AccProbe (MSAA/IAccessible2 en Windows)

Capítulo 5: HTML5. The new semantics and new approaches to document markup

En este capítulo se detiene especialmente en los nuevos elementos estructurales semánticos de HTML5: header, section, article, etc. con diversos ejemplos.

Desde un punto de vista de accesibilidad, no hay mucho cambio por usar HTML5, la mayor preocupación se centra en el soporte para los diferentes navegadores y productos de apoyo.

Para ello se utilizará ARIA junto a los elementos nativos HTML5, tal y como recomienda también la especificación de HTML5. Hay que tener en cuenta que la semántica ARIA suele predominar (no siempre) y anular la semántica por defecto, y que hay ciertas restricciones. Es necesario por tanto estar al corriente de cómo interacciona la semántica de HTML5 y ARIA.

Podemos ver la tabla de correspondencia y la tabla de restricciones en la especificación de HTML5 del W3C .

Comenta algún bug como el problema con el uso de <header> y JAWS 10/11 + Firefox 4 o anterior; pero más importante y conocido es el bug por la aplicación del HTML5 outline algorithm (que permite el uso de varios encabezados H1) y los lectores de pantalla. El autor recomienda que si no vas a sindicalizar el contenido uses un solo H1 en la página: los usuarios de lectores de pantalla te lo agradecerán.

También es interesante el ejemplo que incluye del elemento canvas (aunque en realidad este elemento lo tratará en el capítulo 6), para mostrar cómo incluir información alternativa tanto si el elemento no es soportado como si se accede con un producto de apoyo que soporte ARIA, mostrando una aplicación del role ARIA presentational.

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

Capítulo 6: Images, rich media, audio and video in HTML 5

Imágenes

Repasa los diferentes tipos de imágenes que se pueden encontrar en una web (gráficos, iconos, imágenes decorativas, imágenes funcionales, iconos, etc.) y la forma más adecuada de hacer accesibles cada una de ellas con ejemplos concretos.

Repasa el buen uso de los atributos alt y title, o la conveniencia de poner nombres de fichero descriptivos a las imágenes.

El autor explica que el atributo longdesc ya no forma parte de la especificación HTML 5 y que, aunque nunca estuvo bien soportado por los productos de apoyo, él era partidario de haberlo mantenido.

NOTA 2015

Finalmente LONGDESC sí forma parte de HTML5, podéis consultar toda la información y un estudio detallado en mi artículo LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA:"aria-describedby" y "aria-describedat", HTML5: "figure" y "picture"). En este artículo se incluye también el análisis de otras propiedades ARIA ("aria-describedby") y otros elementos HTML5 ("figure") que el autor trata también en este capítulo.

Trata el uso de aria-labelledby o aria-describedby (que son parte de la especificación WAI-ARIA) como opciones para descripciones largas y cómo usarlos junto a otras alternativas más compatibles con todos los productos de apoyo.

También aborda las distintas formas de tratar las imágenes decorativas y cuál es la más conveniente (definidas en las CSS, con alt=”” o con role=”presentation”)

Por último, como algo específico de HTML5, trata el uso de <figure> y <figcaption>, que se usan para crear una sola unidad que pueda ser referenciada desde otra parte de la página. Dentro de <figure> se incluye la imagen (con la etiqueta <img>) y el elemento <figcaption>, el caption de la imagen, que no hay que confundir con su alternativa textual. También incluye ejemplos para clarificar su uso.

Os recomiendo el documento "HTML5: Techniques for providing useful text alternatives" del W3C.

Vídeo y audio

Es una de las novedades más conocidas de HTML 5, la posibilidad de incluir estos contenidos de forma nativa sin plugins propietarios como el de Flash.

Además de introducir los elementos y sus propiedades, explica que el principal problema actualmente es que los controles nativos son más o menos accesibles en función del navegador y de cómo en este se hayan implementado. Al final la alternativa es hacer tus propios controles y va explicando el proceso (ver el reproductor de vídeo accesible en HTML5 que propone el autor) Trata también cómo incluir una versión alternativa si no se soporta el elemento.

Yo os recomiendo echar también un vistazo al trabajo fin de carrera de Alberto Sánchez-Heredero Pérez, tutorizado por Lourdes Moreno López, "Accesibilidad a los contenidos audiovisuales en la Web a través de HTML5" (PDF, 2MB), ganador del premio Fundación Universia-Fundación Vodafone España. Se puede ver el visor que propone en "HTML 5 support for an accessible user-video-interaction on the Web. ACCESSIBLE HTML5 MEDIA PLAYER"

Por último habla del elemento <track> para las audiodescripciones y subtítulos, y de que por desgracia está mal soportado por los navegadores. Él recomienda usar la librería javascript open-source Captionator.

Para el tema concreto del elemento <video> recomienda el libro "The Definitive Guide to HTML5 Video (Expert's Voice in Web Development)" de Silvia Pfeiffer

Canvas

Se usa para hacer imágenes dinámicas y la idea principal es que actualmente no puede considerarse accesible, pues por ejemplo el contenido dentro de <canvas> no puede ser representado como nodos de un objeto DOM. La recomendación de la propia especificación es usarlo para aquello para lo que sirve y para lo que tiene sentido, y no usarlo cuando hay otro elemento más adecuado (por ejemplo es una mala práctica usarlo para texto)

Si se utiliza se debe proporcionar contenido que transmita la misma función o propósito, y que puede estar contenido dentro del elemento <canvas> como ya explicó en el capítulo 5.

Recomiendo el artículo "Introducción al elemento canvas de HTML5" de Genbeta Dev que explica el uso inteligente de <canvas>

Capítulo 7: HTML 5 and Accesible Data Tables

Comienza repasando los problemas que tienen los usuarios de lectores de pantallas para comprender las tablas si no están bien hechas. Da también unas recomendaciones generales que son las habituales cuando hablamos de accesibilidad y tablas.

Repasa el uso de <caption>, nuevo elemento de HTML5, como título de la tabla, que debe ser el primer elemento dentro de la misma.

Explica que el atributo summary ya no forma parte de la especificación HTML5, pero insta a seguir utilizándolo como medio para incluir una descripción que ayude a comprender la tabla aunque el validador dé error por su uso.

Repasa entonces las alternativas que tenemos para añadir una descripción a la tabla que sí esté admitida por la especificación, como el uso del atributo aria-describedby, o del elemento <details> que se incluiría dentro del elemento <caption>. El elemento <details> proporciona información adicional (podría mostrarse o no visualmente) y a su vez tiene un elemento hijo <summary> con el título del contenido adicional.

No recomienda incluir las tablas dentro del elemento <figure> (podrías hacer entonces uso de su elemento <figcaption>) porque esta anidación no está bien soportada por los productos de apoyo y la descripción y la tabla no están asociadas por código.

También dedica buena parte del capítulo a explicar las diferentes formas de asociar las celdas de encabezado y de contenido. Aunque ahora hay una forma más fácil y rápida de usar scope (especialmente para las tablas complejas) que el tradicional uso de headers/id, recomienda este último por ser más robusto y mejor soportado. Pone diversos ejemplos para clarificar ambas posibilidades.

Capítulo 8: Forms

Dedica un capítulo a otra de las novedades de HTML5 que son los nuevos elementos y atributos relacionados con los formularios.

La idea principal es que se aplican muchas de las técnicas de accesibilidad que ya conocemos, pero que al haber mucha validación nativa, es necesario que esta sea accesible.

Los usuarios de productos de apoyo deben estar informados convenientemente:

deben saber que ha habido un error
deben poder acceder al error y se deben dar instrucciones de cómo solucionarlo
deben poder volver a enviar el formulario.

Y por ello, aunque las nuevas validaciones nativas son muy potentes, la falta de soporte de las mismas para los diferentes navegadores y productos de apoyo, obliga a apoyarlas con las validaciones javascript correctamente implementadas, como pueden verse en el artículo "Accessible forms using jQuery’s Validation plug-in" de Matt Lawson

La forma de asociar las etiquetas con los campos de formulario en HTML5 sería incluir el campo dentro de la etiqueta <label>, algo que ya se podía hacer en (X)HTML, pero que siempre estuvo pobremente soportado por los productos de apoyo. Por ello se recomienda utilizarlo junto al uso de for/id como hacemos actualmente.

Repasa los nuevos elementos y cómo apoyarse en WAI-ARIA, o incluso javascript, para hacer accesibles aquellos que no lo son de forma nativa por cómo los han implementado los diversos navegadores (porque no avisan del cambio de valor, porque no son accesibles mediante el teclado, etc.) Por ejemplo, un uso de progress accesible apoyado en WAI-ARIA

Hay nuevos atributos bastantes útiles, autofocus que podemos usar para poner el foco en el campo que ha dado el error (pero, como indican las WCAG 2.0, nunca bastará solo con esto); placeholder que permite poner un texto por defecto en un campo y se borrará solo al coger el foco sin necesidad de javascript (si no se entiende la propiedad el campo simplemente aparece vacío); etc.

Hay otros atributos que tienen un equivalente en WAI-ARIA como el nuevo atributo de HTML5 required para los campos obligatorio (equivalente a aria-required) y que aunque podrían combinarse, si el lector de pantalla entiende los dos lo anunciará dos veces. Al final lo más robusto es apoyarlo con la información de “campo obligatorio” en el texto, como hacemos habitualmente.

Trate este tema en el artículo: HTML5 y accesibilidad: nuevos tipos de input, atributos asociados y validación nativa

Capítulo 9: HTML5, Usability, UCD

Este capítulo no está directamente relacionado con HTML5, es una introducción a la usabilidad y las principales técnicas que se usan, y que todas las personas involucradas en el desarrollo de sitios web deberían conocer.

Define la usabilidad y su relación con la accesibilidad y los principios del diseño universal. Explica la importancia de incluir a los usuarios durante todo el proceso, así como las diferentes técnicas que se usan en el Diseño Centrado en el Usuario, con especial énfasis en los test con usuarios.

Capítulo 10: Tools, Tips and Tricks. Assessing your accessible HTML5 Project

Hace un repaso de diferentes herramientas de utilidad a la hora de revisar la accesibilidad de un sitio web, haciendo hincapié en que solo deben ser una ayuda y nunca pueden sustituir a la evaluación de un experto.

No propone herramientas novedosas, podéis consultar una lista más detallada en: Mis validadores

Por último, como ya comenté en HTML 5 y accesibilidad, el grupo de trabajo WCAG WG está trabajando en las Técnicas HTML5 para las WCAG 2.0, tal y como existen ahora para HTML, PDF, Flash, etc. (Techniques for WCAG 2.0) Es una gran noticia, aunque de momento están en un estado muy inicial.

Artículos relacionados: