Consejos avanzados de accesibilidad web

Última actualización: 16/04/2012

Artículo relacionado: Respuesta a 25 dudas habituales sobre accesibilidad web

Los hashtag de Twitter son efímeros, por ello recopilo en este artículo los consejos de accesibilidad que publico en Twitter bajo el hashtag #tipAA. Algunos están ampliados con más de 140 caracteres, tal y como los publiqué en Google + o Facebook, otros los he reescrito para este artículo.

En un formulario web se debe asociar explícitamente cada etiqueta con su control, pero ¿cómo realizar asociaciones complejas? Ejemplo de asociación compleja de radios y labels de forma accesible.
Al validar un formulario web ten en cuenta que: identificar los campos erróneos únicamente resaltándolos en rojo es transmitir información solo con el color, y por tanto incumple el punto de verificación 2.1 de las WCAG 1.0 (prioridad 1) y con el criterio de conformidad 1.4.1 de las WCAG 2.0 (nivel A)
Las WCAG 2.0 indican que puedes borrar el contenido de un input cuando este coge el foco, puesto que es un cambio de contenido pero no de contexto (criterio de éxito 3.2.2). Sin embargo no es correcto implementar que el foco salte al siguiente campo una vez que el actual se ha rellenado (como por ejemplo es habitual al rellenar los campos de una cuenta bancaria) pues en este caso sí se trata de un cambio de contexto. Más información en la técnica G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
Las WCAG 2.0 admite el uso de target="_blank" con (X)HTML Transitional si indicas que el enlace se abre en otra ventana mediante un texto incluido dentro del enlace: <a href="ayuda.html" target="_blank">Ayuda (se abre en ventana nueva) </a> (nivel AAA) Más información en “¿Mi página es inaccesible si utiliza ventanas emergentes?”
En una página web, los enlaces o los campos de un formulario pueden coger el foco, sin embargo un DIV, por ejemplo, no. Aquellos elementos que vayan a cambiar dinámicamente tienen que poder coger el foco para que sean accesibles a los lectores de pantalla. Para que un elemento que no coge el foco pueda cogerlo deberá tener
tabindex="0" Más detalles en el artículo “AJAX accesible”
El interlineado recomendado por las WCAG 2.0 es que el espacio entre líneas (interlineado) sea de, al menos, un espacio y medio dentro de los párrafos y el espacio entre párrafos sea, al menos, 1.5 veces mayor que el espacio entre líneas. Consultar criterio de conformidad 1.4.8 (nivel AAA)
No utilices elementos desaconsejados por el W3C. Consulta la Cheat Sheet HTML 4.01, HTML 5, XHTML Elements
Incluye un menú de navegación semántica en el HEAD de las páginas. WCAG 1.0: punto de verificación 13.2 AA, 13.9 AAA; WCAG 2.0: Técnica H59: “Using the link element and navigation tools”
Si quieres ocultar contenido visualmente pero que sea accesible para usuarios de lectores de pantalla NO uses display:none. Consulta el artículo “Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página”
Identificar el idioma principal del documento, proporcionar resumen a las tablas y asegurar un orden lógico de tabulación: estos son los 3 puntos que pasan de ser nivel AAA en las WCAG 1.0 a A o AA en la Norma UNE 139803. Consultar “Diferencias de prioridad entre los requisitos UNE 139803:2004 y los puntos de control de las WCAG 1.0”
Se debe incluir el atributo SUMMARY solo en las tablas que no se utilizan para maquetar (AA: Norma UNE 139803; AAA: WCAG 1.0)
Si tu web tiene contenido Flash consulta la “Checklist para validar contenido Flash de acuerdo con las WCAG 2.0”
¿Un formulario con varios botones que no dependa de javascript y sea accesible? Mi post más leído con 25.000 visitas: “Formulario con varios botones. Implementación usable y accesible”
Los enlaces y campos de formulario no solo deben coger el foco, sino que este debe ser visible. No usar :focus {outline:0;} o peor aun onfocus="blur()" Consultar Common Failures F55 y Common Failures F78
No es necesario que H1 aparezca en el código antes que H2, lo importante es que H1 sea de primer nivel y H2 de segundo nivel. Consultar “¿Es correcto que aparezca en el código HTML un H2 antes que un H1?”
El ancho de un párrafo no debe ser mayor de 80 caracteres: criterio de conformidad 1.4.8 (AAA) de las WCAG 2.0
Solo un sonido que dura más de 3 segundos debe tener la opción de pausarlo o detenerlo: criterio de conformidad 1.4.2 (nivel A) de las WCAG 2.0
Distinguir los enlaces dentro de un texto solo por el color (sin subrayar) es transmitir información solo con el color, y por tanto incumple el punto de verificación 2.1 de las WCAG 1.0 (prioridad 1) y con el criterio de conformidad 1.4.1 de las WCAG 2.0 (nivel A)
Checklist para validar formularios de acuerdo con las WCAG 2.0 (excel, 85 kb)
No es necesario marcar el cambio de idioma de nombres propios, términos técnicos y palabras extranjeras que se pronuncian igual en el idioma de tu página. Consultar “¿Debo indicar el cambio de idioma en cualquier tipo de palabra?”
No justifiques el texto u ofrece un mecanismo para evitarlo. Consulta “¿Cómo debo presentar el texto: justificado o alineado a la izquierda?”
Conoce las "Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0" (excel gratuita de correspondencias)
En una página de nivel de adecuación AA según las WCAG 2.0 los vídeos (grabados) deben incluir subtítulos sincronizados, transcripción de la banda sonora con descripción de la pista visual y audiodescripción.
Una imagen que funciona como enlace no puede considerarse nunca decorativa. Se incluirá en la página con IMG con un ALT significativo.
Caso en el que una imagen que actúa como enlace puede tener alt=””:
<a href=”enlace.html”><img src=”icono.gif” alt=””>Texto del enlace</a>
Es decir, una imagen junto a un texto, siendo que el enlace los engloba a los dos.
El ALT (texto alternativo) de una imagen debe tener siempre en cuenta el contexto en el que se inserta la imagen. Ejemplo "Accessibility: Images in Context" (vídeo de Youtube con subtítulos, con posibilidad de traducción al español)
Si tienes campos de formulario que se borran al coger el foco, revisa los problemas que les puede provocar a los usuarios con lectores de pantalla. En "Accessibility Testing: Correction Scenarios" Derek Featherstone nos explica casos concretos.
En (X)HTML podemos usar el manejador de evento "onclick" sin necesidad de duplicarlo con "onkeypress". Puesto que los navegadores (X)HTML lo interpretan como el manejador de evento de acción por defecto de enlaces y botones y se activa tanto con el ratón como por el teclado
Un elemento que no sea enlace o botón (por ejemplo: div, img, td, etc.) y tenga un evento "onclick" sí necesita que se duplique con "onkeypress" para ser accesible por teclado. Además se debe incluir el atributo tabindex="0" para que el elemento pueda coger el foco y por tanto ser efectivamente accesible por teclado.
Debe existir contenido textual entre encabezados consecutivos (H1-6) del mismo nivel, entre encabezados consecutivos (H1-6) cuando el segundo sea de mayor nivel que el primero; y entre el último encabezado y el final de página
¿Cómo incluir la descripción larga de una imagen de forma que sea accesible para los lectores de pantalla y se visualice por defecto cuando no se han cargado las imágenes? Descripción extensa de una imagen: accesible con lector de pantalla y visible sin imágenes activas
Las WCAG recomiendan usar accesskey para alcanzar el nivel AAA (en las WCAG 1.0) o como técnica adicional del criterio 2.4.1 (en las WCAG 2.0) ¿Pero cuáles utilizar? Qué teclas de acceso rápido (accesskey) utilizar
Que un párrafo esté incluido en un DIV no le exime de que obligatoriamente también deba estar incluido en un P
Para comprobar en un audio si el sonido de fondo es 20 dB más bajo que la voces para cumplir con el criterio 1.4.7, puedes usar WCAG 2.0 Audio Contrast Analysis Tool incluida en Audacity