Autopsia de una web no accesible: 5 errores de código que suspenden una auditoría

Una web no suele suspender una auditoría de accesibilidad por cómo se ve, sino por cómo está escrita. Casi siempre fallan las mismas cosas: elementos que parecen controles y no lo son, ARIA mal puesto, campos sin nombre y un foco que se pierde. Estos son los cinco errores que más encontramos y cómo se escriben bien.

Por qué falla técnicamente una web

Un lector de pantalla no ve la página. Lee lo que el navegador le cuenta de ella: qué es cada cosa, cómo se llama y en qué estado está. Esa información sale del HTML. Si el código dice “caja” donde debería decir “botón”, la persona que lo usa recibe una caja.

La UNE-EN 301549 remite a las WCAG 2.1 nivel AA para la web. Los cinco errores de este artículo incumplen criterios de ese nivel.

• Lo que encontramos

  • Un <div> con un evento de clic
  • Una ventana modal que deja escapar el foco
  • aria-hidden en un enlace
  • Un campo con solo placeholder
  • Texto blanco sobre una foto

• Lo que escribimos

  • <button type="button">
  • <dialog> abierto con showModal()
  • El enlace, visible para todos o para nadie
  • <label for> visible
  • El texto sobre un fondo sólido

Los cinco errores

1. Un div que hace de botón

Lo que encontramos: un <div> o un <span> con un evento de clic. Con ratón funciona. Con teclado no se puede alcanzar, y el lector de pantalla no dice que sea un botón.

Incumple los criterios 2.1.1 (Teclado) y 4.1.2 (Nombre, función, valor).

Cómo se escribe: <button type="button">. Se alcanza con Tab, se activa con Intro y con la barra espaciadora, y el lector anuncia que es un botón. Todo eso viene de serie, sin una línea de JavaScript más.

2. Una ventana modal que deja escapar el foco

Lo que encontramos: se abre una ventana y el foco se queda en la página de detrás. Con Tab, la persona sigue recorriendo enlaces que no ve. Al cerrar la ventana, el foco no vuelve a ningún sitio.

Incumple el criterio 2.4.3 (Orden del foco). Lo contrario, una ventana de la que no se puede salir con teclado, es una trampa de teclado e incumple el 2.1.2.

Cómo se escribe: con <dialog> y showModal(). El navegador lleva el foco a la ventana, deja inerte el resto de la página y la cierra con Escape. Comprueba siempre que, al cerrarla, el foco vuelva al botón que la abrió.

3. ARIA que sobra o que estorba

Lo que encontramos: role="navigation" en un <nav>, que repite lo que el elemento ya dice. No rompe nada, pero es ruido. Lo grave es otra cosa: aria-hidden="true" en un enlace o un botón. El teclado llega a él y el lector de pantalla no lo anuncia.

Incumple el criterio 4.1.2 (Nombre, función, valor).

Cómo se escribe: con la primera regla de ARIA. Si existe un elemento HTML que ya hace lo que necesitas, se usa ese elemento. Y lo que se oculta al lector de pantalla se oculta también al teclado.

4. Campos sin etiqueta

Lo que encontramos: un campo con el texto de ayuda dentro, en el placeholder, y sin etiqueta. Al empezar a escribir, el texto desaparece. Suele tener poco contraste y no todos los lectores de pantalla lo anuncian como nombre.

Incumple los criterios 1.3.1 (Información y relaciones) y 3.3.2 (Etiquetas o instrucciones).

Cómo se escribe: cada campo con su <label for="…"> visible, encima del campo, y el placeholder solo para un ejemplo, si hace falta.

5. Texto sobre una imagen sin contraste

Lo que encontramos: un titular blanco sobre una foto. En una parte de la foto se lee y en otra no. En móvil, con otro recorte, se lee peor.

Incumple el criterio 1.4.3 (Contraste mínimo): 4,5:1 para texto normal y 3:1 para texto grande.

Cómo se escribe: el texto sobre un fondo sólido o un velo que asegure el contraste en el peor punto de la imagen, en todos los tamaños de pantalla. O el texto fuera de la imagen.

Cómo lo evitamos en nuestras webs

Lo hablamos en el diseño, antes de escribir código: qué es cada control, cómo se llega a él con teclado y qué contraste tiene. Después, cada cambio pasa comprobaciones automáticas de contraste, reflow y navegación antes de publicarse. Y lo que una máquina no ve lo revisamos con teclado y con lector de pantalla.

Si tu equipo desarrolla la web y quiere saber dónde está, la auditoría es el primer paso.