WCAG 2.2: lo que trae la nueva versión de accesibilidad
Índice de contenidos
- Puntos clave
- Los 9 criterios nuevos
- Nivel A (mínimo)
- Nivel AA (más impactantes)
- Nivel AAA
- Impacto en productos existentes
- Target Size (2.5.8)
- Dragging Movements (2.5.7)
- Accessible Authentication (3.3.8)
- Focus Not Obscured (2.4.11)
- Migración práctica desde 2.1
- El contexto EAA
- Accesibilidad cognitiva: el enfoque nuevo
- Conclusión
Actualizado: 2026-05-03
WCAG 2.2[1] se publicó como recomendación del W3C el 5 de octubre de 2023, añadiendo 9 criterios nuevos a WCAG 2.1. Los cambios son modestos en número pero significativos en intención: mejoran la accesibilidad en móvil y para usuarios con limitaciones cognitivas. Para empresas trabajando hacia cumplimiento EAA 2025, WCAG 2.1 AA sigue siendo el mínimo legal; WCAG 2.2 AA es la dirección donde va el listón.
Puntos clave
- Los 4 criterios AA nuevos más impactantes son: Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8) y Accessible Authentication (3.3.8).
- Target Size (2.5.8) es el criterio que más probablemente rompe UIs existentes: botones icon de 16×16 y links inline densos violan por defecto.
- Para equipos que ya cumplen WCAG 2.1 AA, el salto a 2.2 AA es 1-2 sprints para un producto mediano.
- WCAG 3 (“Silver”) sigue en desarrollo; no esperes a ella para mejorar la accesibilidad.
- La normativa EAA 2025 referencia WCAG 2.1 AA como mínimo; apuntar directamente a 2.2 AA es más futuro-compatible.
Los 9 criterios nuevos
Nivel A (mínimo)
3.2.6 Consistent Help (A): si el sitio ofrece “contacto”, “help”, “chat”, deben estar en el mismo lugar consistente en todas las páginas.
3.3.7 Redundant Entry (A): no pedir información ya introducida en la misma sesión. Un checkout que re-pregunta la dirección después de haberse introducido en el login viola este criterio.
Nivel AA (más impactantes)
2.4.11 Focus Not Obscured (Minimum) (AA): cuando un elemento recibe foco de teclado, al menos parte de él debe ser visible. Viola: un modal o cookie banner que tapa el elemento con foco.
2.5.7 Dragging Movements (AA): cualquier funcionalidad que requiera arrastrar debe tener alternativa (click, tap). Viola: un reordenamiento drag-only sin botones “subir/bajar”.
2.5.8 Target Size (Minimum) (AA): objetivos clicables deben ser al menos 24×24 CSS pixels. Muchos botones icon y links inline lo violan.
3.3.8 Accessible Authentication (Minimum) (AA): el proceso de login no debe requerir habilidades cognitivas sin alternativa — recordar contraseñas complejas, identificar imágenes. Los gestores de contraseñas deben funcionar (sin bloquear el paste).
Nivel AAA
2.4.12 Focus Not Obscured (Enhanced) (AAA): el elemento con foco no debe estar nada oscurecido. Más estricto que 2.4.11.
2.4.13 Focus Appearance (AAA): el indicador de foco debe tener contraste mínimo 3:1 y área suficiente.
3.3.9 Accessible Authentication (Enhanced) (AAA): aún más estricto que 3.3.8.
Impacto en productos existentes
Target Size (2.5.8)
El que más probablemente rompe tu UI actual:
- Links inline pequeños entre texto.
- Botones icon de 16×16 o 20×20.
- Switches o toggles pequeños.
- Pagination links densos.
Solución: aumentar a mínimo 24×24, o añadir padding que haga el área clicable 24×24 aunque el visible sea menor. Excepción: si hay suficiente separación entre targets (>24px), un tamaño menor es aceptable.
Dragging Movements (2.5.7)
Cualquier interfaz con drag-and-drop:
- Kanban boards (estilo Trello).
- Reordenar listas.
- Image croppers.
- Range sliders custom.
Solución: añadir controles alternativos (botones, inputs numéricos). Mantener drag como preferido pero no como único método.
Accessible Authentication (3.3.8)
Patrones que rompen:
- reCAPTCHA v2 con identificación de imágenes (carga cognitiva).
- Password fields que bloquean paste (impide gestores de contraseñas).
- Custom CAPTCHA con puzzles.
Solución: CAPTCHA accesible (reCAPTCHA v3 silent, Turnstile de Cloudflare), permitir paste, métodos alternativos (passkey, social login). Este criterio conecta bien con la importancia de la accesibilidad en la EAA 2025.
Focus Not Obscured (2.4.11)
- Sticky headers que tapan el elemento con foco al scrollear.
- Cookie banners fijos en bottom.
- Chat widgets que tapan botones.
Solución: scroll-margin-top en CSS, gestión de z-index, viewport unit awareness.
Migración práctica desde 2.1
Si ya cumples WCAG 2.1 AA, el upgrade a 2.2 AA es manejable:
- Hacer audit con herramientas 2.2-aware: axe-core 4.8+, Pa11y, WAVE, todos soportan 2.2.
- Priorizar los 4 criterios AA nuevos: 2.4.11, 2.5.7, 2.5.8, 3.3.8.
- Revisar drag interactions, botones icon, CAPTCHAs.
- Actualizar políticas internas del design system.
Normalmente 1-2 sprints para un producto mediano ya accesible a 2.1.
El contexto EAA
Para empresas preparando European Accessibility Act 2025:
- Mínimo legal: EN 301 549 referencia WCAG 2.1 AA.
- Próxima revisión de EN 301 549 incorporará WCAG 2.2.
- Decisión prudente: apuntar a 2.2 AA ya para no tener que re-auditar cuando cambie la referencia.
En Reino Unido, el GDS Service Manual ya cita WCAG 2.2 en sus criterios de aceptación.
Accesibilidad cognitiva: el enfoque nuevo
Un hilo conductor de WCAG 2.2 es la accesibilidad cognitiva:
- Redundant Entry reduce carga de memoria.
- Accessible Authentication elimina tests cognitivos.
- Consistent Help reduce búsqueda cognitiva.
Esto beneficia a todos los usuarios, no solo a personas con discapacidades cognitivas. Es donde WCAG históricamente menos se había enfocado.
Conclusión
WCAG 2.2 es una actualización incremental pero focalizada. Para equipos ya cumpliendo 2.1 AA, el salto es manejable y vale la pena — los beneficios son reales, especialmente en móvil y para usuarios con carga cognitiva. Para empresas aún trabajando hacia EAA, apuntar directamente a 2.2 AA es más futuro-compatible. La dirección del estándar es clara: cada vez más foco en accesibilidad cognitiva, móvil y situacional. Quedarse solo con criterios técnicos visibles (contraste, ARIA) ya no es suficiente para considerarse producto accesible.