WCAG 2.2 explicado: la guía práctica de accesibilidad web para developers

Durante años, “accesibilidad web” fue la sección que se dejaba para el final del sprint, si es que llegaba a entrar. En 2026 eso ha dejado de ser una opción para una parte enorme de la web europea: la European Accessibility Act (EAA) es obligatoria desde el 28 de junio de 2025, y exige que webs, apps y servicios digitales cumplan WCAG 2.2 nivel AA. No es una recomendación de buenas prácticas; es una directiva con sanciones que en algunos estados miembros llegan a millones de euros.

La buena noticia es que WCAG 2.2 no es un texto legal indescifrable. Es una lista de criterios técnicos, muchos de ellos tan concretos como “este botón debe medir al menos 24×24 píxeles”. Esta guía traduce esos criterios a decisiones que tomas mientras escribes HTML, CSS y JavaScript, sin la jerga de consultoría legal que suele rodear el tema.

Qué cambia (y qué no) respecto a WCAG 2.1

WCAG 2.2 se publicó como recomendación en octubre de 2023 y añade nueve criterios de éxito nuevos sobre la base de WCAG 2.1, además de retirar un criterio obsoleto (4.1.1 Parsing, que dependía de validadores HTML que ya no reflejan cómo procesan HTML los navegadores modernos). No es una versión que sustituya conceptualmente a la anterior: es una ampliación centrada en tres colectivos que la 2.1 cubría peor —personas con baja visión, discapacidad cognitiva o de aprendizaje, y movilidad reducida en el uso de puntero o táctil.

Niveles A, AA y AAA, sin rodeos

WCAG organiza sus criterios en tres niveles de conformidad acumulativos:

• Nivel A: el mínimo indispensable. Sin él, ciertos usuarios no pueden usar la web en absoluto (por ejemplo, contenido que depende solo del color, o funcionalidad que solo funciona con ratón).
• Nivel AA: el nivel que exige la inmensa mayoría de la legislación del mundo, incluida la EAA y la norma europea EN 301 549. Es el objetivo real para cualquier proyecto profesional.
• Nivel AAA: el más estricto. El propio W3C reconoce que no es realista exigirlo a un sitio completo, porque algunos criterios AAA entran en conflicto con decisiones de diseño legítimas (por ejemplo, el contraste de color AAA es tan alto que limita mucho la paleta). Se aplica de forma selectiva, no como objetivo global.

Si tu jefe de proyecto te pregunta “¿cumplimos WCAG?”, la pregunta bien formulada es “¿cumplimos WCAG 2.2 nivel AA?”. Eso es lo que audita un organismo de control y lo que exige la EAA a productos y servicios digitales dirigidos a la Unión Europea.

Los nueve criterios nuevos de WCAG 2.2

Aquí está la lista completa, con el nivel y qué implica en código real.

De los nueve, 2.5.8 (Target Size) y 3.3.8 (Accessible Authentication) son los que más código real tocan en un proyecto típico. El primero afecta a cualquier botón, icono clicable o enlace en una barra de navegación móvil:

/* Antes: un icono de 16px difícil de acertar en móvil */
.icon-button {
  width: 16px;
  height: 16px;
}

/* Después: área de toque real de al menos 24x24,
   aunque el icono visual siga siendo pequeño */
.icon-button {
  width: 16px;
  height: 16px;
  padding: 8px; /* el área clicable total sube a 32x32 */
  box-sizing: content-box;
}

Y el segundo prohíbe patrones de login que hoy siguen siendo comunes, como CAPTCHAs que exigen transcribir texto distorsionado sin alternativa de audio, o bloquear el pegado de contraseñas en el campo de password (una “protección” que en realidad empuja a la gente a usar contraseñas más débiles y fáciles de recordar).

<!-- Evita esto: bloquea gestores de contraseñas y el propio pegado -->
<input type="password" onpaste="return false" />

<!-- Así el usuario puede pegar desde su gestor de contraseñas -->
<input type="password" autocomplete="current-password" />

Checklist práctica para el día a día

No hace falta memorizar los 86 criterios de WCAG 2.2 AA. La mayoría de problemas reales en producción se concentran en un puñado de decisiones repetidas:

• HTML semántico primero: <button> para acciones, <a> para navegación, encabezados (h1-h6) en orden jerárquico sin saltos, <label> asociado a cada campo de formulario.
• Navegación por teclado completa: todo lo que se activa con clic debe activarse con Tab + Enter/Espacio, en un orden lógico, sin trampas de foco (focus traps) en modales que no se puedan cerrar con Esc.
• Foco visible y no tapado: no elimines el outline por defecto sin sustituirlo por un indicador igual de visible (criterios 2.4.11 y 2.4.13).
• Contraste de color: mínimo 4.5:1 para texto normal y 3:1 para texto grande, en nivel AA. Herramientas como el contraste de Chrome DevTools o WebAIM Contrast Checker lo calculan al vuelo.
• Texto alternativo real: alt descriptivo en imágenes con contenido informativo, alt="" explícito en imágenes puramente decorativas (nunca lo omitas sin más).
• Contenido dinámico anunciado: usa aria-live para mensajes que aparecen sin recarga (errores de validación, confirmaciones, contadores), o el lector de pantalla los ignora por completo.
• Objetivos táctiles de 24×24px mínimo y separación suficiente entre elementos interactivos consecutivos.
• Autenticación sin barreras cognitivas obligatorias: passkeys, gestores de contraseñas permitidos, sin CAPTCHAs sin alternativa.
• Movimiento y animación respetuosos: honra prefers-reduced-motion para desactivar animaciones no esenciales.

Herramientas de auditoría: qué mide cada una y dónde falla

Ningún escáner automático certifica accesibilidad por sí solo. Los estudios sobre estas herramientas coinciden en que detectan entre el 30% y el 50% de los problemas reales; el resto requiere revisión manual.

• axe DevTools (Deque): motor que usa también Lighthouse por debajo. Extensión de navegador con muy pocos falsos positivos; es la referencia para desarrolladores que quieren un informe técnico fiable dentro del propio flujo de trabajo.
• WAVE (WebAIM): superpone iconos y anotaciones directamente sobre la página analizada. Es la mejor opción para revisiones visuales rápidas o para explicar un problema a alguien no técnico.
• Lighthouse (Chrome DevTools / CI): usa axe-core internamente pero solo aplica un subconjunto de reglas con una ponderación propia para calcular su puntuación de accesibilidad. Útil para detectar regresiones en cada build, no como auditoría completa.

Ninguna de las tres sustituye la prueba manual: navegar la página entera solo con teclado, y probarla con un lector de pantalla real (VoiceOver en macOS/iOS, NVDA o Narrator en Windows). Cosas como “¿tiene sentido el orden de lectura?” o “¿el mensaje de error se anuncia de verdad?” solo se detectan así.

Por qué esto también es un tema de SEO y rendimiento

Accesibilidad, SEO técnico y rendimiento comparten más base técnica de la que parece: HTML semántico bien estructurado ayuda tanto a un lector de pantalla como a un crawler a entender la jerarquía de la página, y muchas de las señales que miden Core Web Vitals —como reservar espacio para evitar saltos de layout— también evitan que el contenido se mueva de forma impredecible para alguien que navega con zoom o con un lector de pantalla. No son tres disciplinas separadas que se auditan en momentos distintos: son restricciones que, bien resueltas a nivel de marcado, se refuerzan entre sí.

La recomendación práctica para 2026 es simple: trata WCAG 2.2 AA como un requisito de producción, no como una fase de QA posterior. Es más barato construir con foco visible, contraste correcto y HTML semántico desde el primer commit que auditar y parchear 200 páginas después de un requerimiento legal.