Guía completa para entender WCAG 2.2 de forma amable pero profunda: en qué se diferencia de WCAG 2.1, los 9 nuevos criterios de conformidad, la implementación práctica y la forma de pensar su operación
Resumen rápido primero
- WCAG 2.2 es una Recomendación del W3C para mejorar la accesibilidad del contenido web. Añade 9 criterios de conformidad a WCAG 2.1 y elimina 4.1.1 Parsing.[^1]
- Los 9 elementos nuevos refuerzan áreas que suelen causar problemas reales en la implementación, como la visibilidad del foco, alternativas al arrastre, tamaño del objetivo, autenticación más fácil, ayuda más fácil de encontrar y reducción de la carga de volver a introducir información después de errores.[^2]
- En la práctica, si apuntas a WCAG 2.2 AA, se vuelve especialmente importante revisar formularios, botones, interfaces basadas en arrastrar, flujos de inicio de sesión, rutas de soporte y zonas alrededor de encabezados fijos.[^3]
- WCAG 2.2 es una Recomendación del W3C y también ha sido aprobada como ISO/IEC 40500:2025.[^4]
Lectores objetivo: responsables web, diseñadores UI/UX, ingenieros frontend, personal de QA, especialistas en accesibilidad y personal de operación web en gobiernos, instituciones educativas y empresas
Nivel de accesibilidad: para quienes aspiran a la conformidad WCAG 2.2 AA
1. Introducción: ¿Qué es WCAG 2.2?
WCAG 2.2 es una de las versiones más recientes de las Web Content Accessibility Guidelines publicadas por el W3C, y se convirtió en Recomendación del W3C en octubre de 2023. Su propósito es garantizar que una amplia variedad de usuarios, incluidas las personas con discapacidad, puedan percibir, operar, comprender y usar de forma fiable sitios web y aplicaciones web. En la explicación general del W3C sobre la familia WCAG 2, WCAG 2.2 se presenta como una extensión de 2.1, heredando el enfoque de WCAG 2.1 mientras refuerza áreas donde seguían existiendo problemas prácticos.[^5]
Lo importante al entender WCAG 2.2 es que no es simplemente una “lista de verificación”. Es un conjunto de principios de diseño para evitar que los usuarios se queden bloqueados a mitad de una experiencia. Un sitio puede verse elegante, pero si no puede operarse con teclado, si los usuarios no pueden entender cómo corregir un error, si se exige arrastrar para avanzar o si el inicio de sesión impone una gran carga cognitiva, entonces no es realmente utilizable. WCAG 2.2 entra bastante en este tipo de escenarios de uso real. Está diseñado para reducir exactamente esas situaciones de “no puedo usar esto”.[^3]
2. ¿Qué cambió respecto a WCAG 2.1?
Según el W3C, WCAG 2.2 añade 9 criterios de conformidad a WCAG 2.1. Además, mientras que los criterios de conformidad de 2.0 y 2.1 generalmente permanecen iguales en 2.2, hay una excepción: 4.1.1 Parsing queda obsoleto y se elimina en 2.2. Así que, al aprender 2.2, el enfoque más eficiente es mantener la base de 2.1 y luego centrarse especialmente en los 9 elementos añadidos.[^1]
Esas 9 incorporaciones están organizadas en “What’s New in WCAG 2.2” del W3C. En concreto, son 2.4.11 Focus Not Obscured (Minimum), 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, 3.3.8 Accessible Authentication (Minimum) y 3.3.9 Accessible Authentication (Enhanced). Estos puntos se centran en problemas muy prácticos de interfaces reales: cómo aparece el foco, la dependencia del arrastre, el tamaño de los objetivos táctiles, las rutas de ayuda, la introducción repetida de datos y la dificultad de autenticación.[^2]
Este es un punto muy importante: WCAG 2.2 es más fácil de entender no como “una revolución completamente nueva”, sino como una versión que rellena cuidadosamente vacíos prácticos que 2.1 había dejado. Para quienes ya venían pensando en accesibilidad, no es un mundo totalmente distinto. Pero, por otro lado, para sitios con formularios, flujos de inicio de sesión, interfaces móviles, interfaces basadas en arrastrar o encabezados fijos, deja mucho más claros los puntos de revisión y hace más fácil trasladarlos a la práctica.[^3]
3. La estructura general de WCAG 2.2: cuatro principios y niveles de conformidad
Al igual que el resto de la familia WCAG 2, WCAG 2.2 se basa en los cuatro principios de Perceptible, Operable, Comprensible y Robusto. Debajo de ellos hay pautas, y debajo de estas hay criterios de conformidad verificables. Los niveles de conformidad son A, AA y AAA, y en el trabajo práctico, el objetivo más habitual es AA.[^3]
La idea de conformidad también es importante. En “Understanding Conformance” del W3C, se explica que la conformidad con WCAG 2 significa que no existe contenido que incumpla ningún criterio de conformidad exigido en el nivel declarado. En otras palabras, aunque algunas partes estén bien, si hay un fallo grave en un flujo clave de usuario, entonces resulta difícil considerar conforme la página o la experiencia en su conjunto. Por eso importa revisar no solo la portada, sino también búsqueda, formularios, flujo de compra, inicio de sesión, PDF, interfaces de notificación y otros recorridos reales de uso.[^6]
4. Comprender cada uno de los nuevos criterios de conformidad
4.1 2.4.11 Focus Not Obscured (Minimum)
Este criterio exige que el foco de teclado no quede oculto por otros elementos fijos o superposiciones. Por ejemplo, si un encabezado fijo, un banner de cookies o una CTA fija en el pie ocultan el botón o campo actualmente enfocado, los usuarios pueden perder la referencia de dónde están. Este es un problema muy práctico, especialmente en dispositivos móviles y con zoom.[^2]
4.2 2.4.12 Focus Not Obscured (Enhanced)
Es la versión más fuerte de 2.4.11. Requiere que el elemento enfocado sea completamente visible, no solo parcialmente visible. En la práctica, si tu objetivo es AA, 2.4.11 suele ser la principal preocupación, pero si diseñas con margen adicional, tu interfaz también se vuelve más estable en pantallas estrechas y con zoom.[^2]
4.3 2.4.13 Focus Appearance
Este criterio exige que el indicador de foco tenga suficiente visibilidad, tamaño y contraste. Dicho de forma más simple, evita diseños en los que el anillo de foco es tan tenue y fino que, en la práctica, resulta invisible. Para los usuarios de teclado, el foco es su ubicación actual. Si no pueden verlo, la interfaz se vuelve prácticamente inutilizable.[^2]
4.4 2.5.7 Dragging Movements
Esto establece que no debe obligarse a los usuarios a depender solo del arrastre. En elementos como ordenación, deslizadores, mapas o selección de rangos, deben existir alternativas como botones o interacciones más simples basadas en toques. Esto ayuda en muchos contextos, incluido el uso móvil, discapacidades motrices, métodos alternativos de entrada y acceso mediante pulsadores.[^2]
4.5 2.5.8 Target Size (Minimum)
Este criterio exige que los objetivos táctiles o clicables no sean demasiado pequeños. Las medidas exactas y las excepciones deben consultarse en el texto de WCAG, pero en la práctica la idea clave es garantizar un tamaño cómodo de toque y un espaciado suficiente. Los objetivos demasiado pequeños son difíciles no solo para usuarios móviles, sino también para personas que usan control ocular o personas mayores.[^2]
4.6 3.2.6 Consistent Help
Las rutas de ayuda, soporte y contacto no deben cambiar de lugar de forma impredecible de una página a otra. Deben mantener una ubicación y una facilidad de descubrimiento consistentes. Cuando las personas ya tienen dificultades, que el acceso a ayuda sea inconsistente hace aún más difícil obtener apoyo.[^2]
4.7 3.3.7 Redundant Entry
Este criterio exige que los usuarios no tengan que introducir la misma información repetidamente dentro del mismo proceso. Por ejemplo, si una dirección o un número de cliente ya se han proporcionado o ya se conocen, obligar a escribirlos otra vez añade una carga innecesaria. Esto se relaciona con el autocompletado, el arrastre de datos ya introducidos y el diseño de pantallas de confirmación.[^2]
4.8 3.3.8 Accessible Authentication (Minimum)
Esto exige que la autenticación no dependa solo de la memoria, del recuerdo complejo o de tareas cognitivas tipo rompecabezas. Por ejemplo, obligar a reproducir exactamente una cadena memorizada o forzar un CAPTCHA puramente basado en acertijos impone una carga alta. Funciones como gestores de contraseñas, copiar y pegar, mostrar contraseña, enlaces mágicos y autenticación basada en dispositivo ayudan a reducir la carga cognitiva.[^2]
4.9 3.3.9 Accessible Authentication (Enhanced)
Es la versión más fuerte de 3.3.8 y pide un estándar aún más alto de accesibilidad en la autenticación. Como orientación de nivel AAA, es útil para el diseño futuro entender la dirección de no hacer que la autenticación dependa en gran medida de “lo que el usuario recuerda”.[^2]
5. Áreas con mayor impacto práctico
WCAG 2.2 afecta a toda la experiencia, pero las áreas con impacto práctico especialmente grande son formularios, inicio de sesión, interfaces móviles, elementos fijos, operaciones de arrastre y rutas de ayuda. Por ejemplo, en formularios conviene priorizar si los usuarios están siendo obligados a volver a introducir la misma dirección. En el inicio de sesión, si se obstaculiza el uso de gestores de contraseñas. En encabezados fijos, si el foco queda oculto. En móvil, si los botones son demasiado pequeños. Son lugares donde las mejoras de accesibilidad suelen tener un gran impacto para el usuario.[^3]
El W3C también ha publicado orientación sobre cómo aplicar WCAG 2.2 a aplicaciones móviles. No es un documento normativo, pero sí muestra que el enfoque de 2.2 es muy relevante en la práctica para móvil, apps nativas y apps híbridas. En servicios mobile-first, en particular, 2.5.7 y 2.5.8 pueden tener un impacto muy grande.[^7]
6. Cómo aspirar a WCAG 2.2 AA en la práctica
Intentar leer toda la norma de una vez y lograr conformidad perfecta de inmediato suele agotar a los equipos. Un mejor camino es esta secuencia.
6.1 Primero, confirmar la base existente de WCAG 2.1 AA
Como WCAG 2.2 se construye sobre 2.1, si lo básico está roto —encabezados, etiquetas, acceso por teclado, contraste, texto alternativo, mensajes de error, etc.— ya habrá mucho que corregir antes siquiera de llegar a las nuevas incorporaciones de 2.2.[^1]
6.2 Después, abordar los 9 criterios nuevos empezando por los de mayor impacto
Un orden especialmente práctico es:
- 2.4.11 / 2.4.13 El foco es visible y no queda oculto
- 2.5.7 / 2.5.8 Alternativas al arrastre y tamaño del objetivo
- 3.3.7 / 3.3.8 Entrada redundante y carga de autenticación
- 3.2.6 Ubicación consistente de la ayuda
Estos tienen gran impacto para el usuario y sus mejoras son relativamente fáciles de reconocer.[^2]
6.3 Estandarizar a nivel de componentes
Como he mencionado antes, si botones, formularios, modales, pestañas, notificaciones, búsqueda, banners de cookies y piezas similares forman parte de un sistema de diseño, el trabajo de WCAG 2.2 se vuelve mucho más fácil de mantener operativamente. Es especialmente eficaz integrar desde la especificación de componentes elementos como anillos de foco, tamaño del objetivo, alternativas al arrastre y resúmenes de errores.[^8]
7. Malentendidos comunes
7.1 “WCAG 2.2 significa tirar 2.1 y aprender todo de nuevo”
No, no es así. El W3C también explica que los criterios de conformidad de 2.0 y 2.1 permanecen básicamente iguales en 2.2. Es más fácil entender 2.2 como un refuerzo más práctico de 2.1 que como un reemplazo total.[^1]
7.2 “WCAG 2.2 es algo que solo debería importar a diseñadores o solo a ingenieros”
Tampoco es correcto. La visibilidad del foco y el tamaño del objetivo son temas de diseño, pero la autenticación y la entrada redundante también involucran diseño de producto, implementación, consideraciones legales y operaciones. La ayuda consistente toca la arquitectura de información y los flujos de soporte. Por eso es mejor tratarlo como un lenguaje compartido por todo el equipo.[^2]
7.3 “La conformidad puede juzgarse por completo con herramientas automáticas”
Las herramientas automáticas son útiles, pero aspectos como la carga cognitiva de la autenticación, la consistencia de la ayuda, la entrada redundante y las interfaces de consentimiento manipulativas requieren juicio humano. Usando Quick Reference del W3C y los Understanding Documents, el enfoque más realista es automatización más revisión manual más pruebas basadas en la experiencia real.[^9]
8. Una lista práctica de comprobación de cinco minutos
- ¿Los encabezados o banners fijos ocultan la posición del foco del teclado?[^2]
- ¿El anillo de foco es suficientemente visible? ¿Es demasiado tenue o demasiado fino?[^2]
- ¿Toda interfaz basada en arrastrar tiene una alternativa basada en botones u otra interacción más simple?[^2]
- ¿Los botones y enlaces son lo bastante grandes y fáciles de activar?[^2]
- ¿Las rutas de contacto, ayuda y soporte son consistentes, en lugar de ir cambiando de página en página?[^2]
- ¿Se obliga a los usuarios a introducir otra vez información que ya proporcionaron dentro del mismo flujo?[^2]
- ¿El flujo de inicio de sesión evita bloquear innecesariamente a gestores de contraseñas o el pegado?[^2]
9. ¿Quién se beneficia de esto?
WCAG 2.2 ayuda no solo a personas con discapacidad, sino también a personas mayores, usuarios móviles, personas cansadas, personas que temporalmente usan una sola mano por una lesión, personas con dificultades ante autenticaciones complejas y personas en condiciones de red inestables. El W3C también explica que WCAG 2 está diseñado de una forma que puede aplicarse a móvil, contenido dinámico y TIC en general. La accesibilidad no es un añadido especial. Es mejor entenderla como control de calidad para la diversidad de condiciones reales de uso.[^10]
10. Conclusión
WCAG 2.2 se basa en WCAG 2.1 y al mismo tiempo refuerza cuidadosamente cuestiones muy prácticas como foco, arrastre, tamaño del objetivo, ayuda, entrada repetida y autenticación. Es una Recomendación del W3C y ahora también está aprobada como ISO/IEC 40500:2025.[^4]
Como prioridad de implementación, lo mejor es confirmar primero la base existente de WCAG 2.1 AA y después trabajar los 9 elementos nuevos, empezando por los que tengan mayor impacto. En particular, la visibilidad del foco, los elementos fijos que ocultan el foco, las alternativas al arrastre, el tamaño del objetivo, una autenticación más fácil y la reducción de la entrada repetida influyen directamente en la experiencia del usuario.[^2]
WCAG 2.2 puede parecer un poco difícil al leerlo por primera vez. Pero su núcleo, en realidad, es bastante amable:
no solo “¿pueden verlo?”, sino también “¿pueden pulsarlo? ¿pueden entenderlo? ¿pueden recuperarse? ¿pueden continuar sin una carga indebida?”
Llegar hasta ahí es lo que hace que la web sea más usable y más confiable.
Referencias
- WCAG 2.2 (W3C)
- What’s New in WCAG 2.2 (W3C WAI)
- WCAG 2 Overview (W3C WAI)
- How to Meet WCAG 2.2 – Quick Reference (W3C WAI)
- Understanding WCAG 2.2 (W3C WAI)
- About WCAG Understanding Documents (W3C WAI)
- WCAG 2.2 is a Web Standard “W3C Recommendation” (W3C WAI News)
- WCAG 2.2 Approved as an ISO Standard (W3C WAI News)
- Guidance on Applying WCAG 2.2 to Mobile Applications (W3C)
- WCAG 2 FAQ (W3C WAI)