WCAG 2.2 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 acessibilidad 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.
Este artículo cubre los 9 criterios nuevos, cómo afectan a productos existentes, y el contexto frente a WCAG 3 (que tardará años).
Los 9 criterios nuevos
Nivel A (mínimo)
2.4.11 Focus Not Obscured (Minimum) (AA en 2.2): 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 clickables deben ser al menos 24×24 CSS pixels (con algunas excepciones). Muchos botones icon y links inline lo violan.
3.2.6 Consistent Help (A): si tu 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 al usuario información ya introducida en la misma sesión. Login → checkout shouldn’t re-ask address.
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). Password managers deben funcionar.
Nivel AA
2.4.12 Focus Not Obscured (Enhanced) (AAA): el elemento con foco no debe estar nada oscurecido. Stricter 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
Los criterios AA son los más relevantes para compliance. Los más impactantes:
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/toggles pequeños.
- Pagination links densos.
Solución: aumentar a mínimo 24×24, o añadir padding que haga el clickable area 24×24 (aunque el visible sea menor).
Dragging Movements (2.5.7)
Cualquier interfaz con drag-and-drop:
- Kanban boards (Trello-style).
- Reordenar listas.
- Image croppers.
- Range sliders custom.
Solución: añadir controles alternativos (botones, inputs numéricos). Mantener drag como preferred, pero no único.
Accessible Authentication (3.3.8)
Patrones que rompen:
- reCAPTCHA v2 con identificación de imágenes (cognitive).
- Password fields que bloquean paste (password manager).
- Custom CAPTCHA con puzzles.
Solución: CAPTCHA accesible (reCAPTCHA v3 silent, Turnstile), permitir paste, authentication métodos alternativos (passkey, social).
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, z-index management, 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:
- Audit con herramientas 2.2-aware: axe-core, Pa11y, WAVE todos soportan 2.2.
- Priorizar los 4 criterios AA nuevos:
- 2.4.11 Focus Not Obscured (Minimum)
- 2.5.7 Dragging Movements
- 2.5.8 Target Size (Minimum)
- 3.3.8 Accessible Authentication
- Revisar drag interactions, icon buttons, CAPTCHAs.
- Actualizar políticas internas de design systems.
Normalmente, 1-2 sprints para un producto mediano ya accesible 2.1.
Target size: cálculo detallado
El criterio 2.5.8 tiene matices:
- 24×24 CSS pixels es el mínimo.
- Exception: si hay suficiente separación (>24px entre targets), tamaño menor es OK.
- Exception: target dentro de bloque de texto (inline links), aunque se recomienda grande.
- Exception: si el user-agent lo controla (browser default).
Testing rápido: en DevTools, verificar getBoundingClientRect() de elementos clickables.
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 — eventual.
- 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.
Herramientas actualizadas
Soporte WCAG 2.2 en tools populares:
- axe-core 4.8+: reglas 2.2 incluidas.
- Pa11y: vía actions customizadas.
- Lighthouse: reglas parciales 2.2 desde Chrome 120+.
- WAVE: actualizada con indicadores 2.2.
- IBM Equal Access Accessibility Checker: soporte completo.
Casos donde 2.2 destaca
Tipos de interfaces donde los nuevos criterios más importan:
- Apps móviles web: target size y dragging movements.
- E-commerce: checkout flows con redundant entry.
- SaaS B2B: consistent help y authentication.
- Dashboards complejos: focus not obscured en sticky navigation.
- Form-heavy apps: redundant entry, accessible auth.
WCAG 3: el horizonte
Mientras 2.2 incrementa, WCAG 3 (codename “Silver”) es una reescritura mayor:
- Modelo de scoring: en vez de pass/fail, niveles graduales.
- Testing más holístico: user journeys completos, no criterios aislados.
- Broader disability coverage: más cognitive, motor, situacional.
- Timeline: 2025+ para draft estable; adoption formal años después.
No esperes a WCAG 3. Trabaja a 2.2 ahora.
Cognitive accessibility: el enfoque nuevo
Un hilo conductor de WCAG 2.2 es 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. Pero es donde WCAG históricamente menos se enfocaba.
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.
Síguenos en jacar.es para más sobre accesibilidad, normativa UE y UX inclusivo.
