Accesibilidad web: guía práctica de WCAG 2.2

La accesibilidad se trata casi siempre como una fase: se construye el producto, y al final alguien pasa un validador y abre veinte incidencias. Ese orden es el que la hace cara. Cuando el foco del teclado se ha roto porque el sistema de componentes nunca lo contempló, arreglarlo no es una incidencia — es reescribir la capa de interacción.

Esta guía va de lo contrario: qué decisiones tomar mientras construyes para que el validador, al final, no tenga nada que decir.

Los cuatro principios: POUR

WCAG organiza todo alrededor de cuatro ideas. No son categorías burocráticas, son cuatro maneras distintas de que alguien no pueda usar tu web.

Perceptible. El contenido tiene que llegar por más de un canal. Una imagen necesita texto alternativo, un vídeo necesita subtítulos, y el color no puede ser el único portador de información — si el campo obligatorio solo se distingue porque está en rojo, una de cada doce personas con visión masculina no lo verá.

Operable. Todo lo que se hace con ratón se tiene que poder hacer con teclado. Sin trampas de foco, sin límites de tiempo imposibles, sin animaciones que disparen crisis vestibulares.

Comprensible. Idioma declarado, comportamiento predecible, errores que expliquen qué ha fallado y cómo arreglarlo. «Error en el formulario» no es un mensaje: es una rendición.

Robusto. El marcado tiene que ser interpretable por tecnologías de asistencia. Aquí es donde el HTML semántico gana siempre a los div con onclick.

Niveles A, AA y AAA

Tres niveles de exigencia. En la práctica solo importa uno.

• A es el mínimo absoluto. Cumplir solo A deja fuera a mucha gente y no satisface prácticamente ninguna normativa.
• AA es el estándar real. Es lo que exige la normativa europea, lo que piden los pliegos públicos y lo que se audita.
• AAA es aspiracional. La propia W3C dice que no es realista exigirlo para todo el contenido de un sitio.

Trabaja siempre contra AA. Si alguien te pide «accesibilidad» sin especificar nivel, está pidiendo AA.

Qué añade WCAG 2.2

WCAG 2.2 es Recomendación del W3C desde octubre de 2023. Es aditiva: mantiene todo lo de 2.1 y suma nueve criterios (uno de 2.1, el 4.1.1 sobre parsing, quedó obsoleto). Seis de los nuevos son de nivel AA. Estos son los que más veces vemos incumplidos:

2.4.11 — Foco no oscurecido. Cuando navegas con tabulador, el elemento enfocado no puede quedar tapado. El culpable habitual es una cabecera fija: tabulas, el foco avanza a un enlace que está justo debajo del header sticky, y visualmente desaparece. Se arregla con scroll-margin-top en los elementos enfocables.

2.5.7 — Movimientos de arrastre. Toda funcionalidad que dependa de arrastrar necesita una alternativa de un solo puntero. Un reordenador de listas por drag and drop necesita también botones de subir y bajar. Un slider de precio necesita campos numéricos.

2.5.8 — Tamaño del objetivo (mínimo). Los objetivos táctiles deben ser de al menos 24×24 píxeles CSS, con excepciones para enlaces en línea dentro de un texto. El infractor clásico es el icono de cerrar de un modal: 16 píxeles y pegado a la esquina.

3.3.8 — Autenticación accesible. No puedes exigir una prueba cognitiva para iniciar sesión. Esto significa permitir pegar en el campo de contraseña, no bloquear los gestores de contraseñas y no obligar a resolver un puzzle. Un CAPTCHA de «selecciona los semáforos» sin alternativa incumple este criterio.

3.2.6 — Ayuda consistente y 3.3.7 — Entrada redundante. El acceso a la ayuda debe estar en el mismo sitio en todas las páginas, y no se puede pedir dos veces el mismo dato en un mismo proceso salvo que sea imprescindible.

Los cinco fallos que salen en casi todas las auditorías

1. Contraste insuficiente. Texto gris claro sobre blanco. El mínimo AA es 4.5:1 para texto normal y 3:1 para texto grande. El gris #999 sobre blanco da 2.85:1: no pasa.
2. Imágenes sin alternativa útil. alt="imagen" es peor que no poner nada. Si la imagen es decorativa, alt="" es la respuesta correcta.
3. Formularios sin etiqueta asociada. El placeholder no es una etiqueta: desaparece al escribir y muchos lectores de pantalla no lo anuncian.
4. Foco invisible. Alguien puso outline: none en el CSS base y nadie lo repuso. Navegar con teclado se vuelve adivinar.
5. Encabezados usados por tamaño. Un h4 elegido porque «se veía bien» rompe el índice con el que la gente que usa lector de pantalla navega la página.

Cómo auditarlo de verdad

Empieza por lo automático porque es barato: axe DevTools o Lighthouse te dan en un minuto los problemas de contraste, atributos ausentes y jerarquía. Pero ten clara la limitación: las herramientas automáticas detectan en torno a un tercio de los problemas reales. No pueden saber si tu alt describe la imagen o si el orden de tabulación tiene sentido.

Lo que sí encuentra el resto:

• Recorre la página entera con el tabulador. Sin tocar el ratón. ¿Se ve siempre dónde estás? ¿Puedes salir de todos los modales? ¿El orden sigue la lectura visual?
• Enciende un lector de pantalla. VoiceOver viene en macOS y iOS, NVDA es gratuito en Windows. Media hora navegando tu propio producto a ciegas enseña más que cualquier informe.
• Sube el zoom al 200%. Es un criterio AA y rompe más maquetaciones de las que parece.

El orden correcto

La accesibilidad sale barata cuando se decide en la capa de componentes y cara cuando se parchea pantalla a pantalla. Si tienes un botón, un campo de formulario y un modal bien resueltos, ya has resuelto el 80% de las pantallas que construyas encima. Es exactamente el argumento a favor de tener un sistema de diseño: lo accesible por defecto se hereda.

Y hay un motivo más para no dejarlo para el final: desde junio de 2025 buena parte del comercio y los servicios digitales en la UE están obligados por ley. El European Accessibility Act fija el suelo y remite a la norma EN 301 549, que a su vez apunta a WCAG en nivel AA — el mismo nivel del que habla este artículo.

¿Quieres saber en qué punto está tu web? En desarrollo web trabajamos la accesibilidad como parte del proceso, no como una auditoría de última hora.