WCAG 2.1 frente a 2.2: qué cambió y por qué importa

La WCAG 2.2 no sustituye a la WCAG 2.1, es una extensión de ella. Añade nueve criterios de éxito nuevos (seis de nivel AA), elimina un criterio que los navegadores modernos volvieron obsoleto, y mantiene todo lo demás de la 2.1 intacto, así que un sitio que ya cumple con la 2.1 AA tiene una carencia corta y concreta por cerrar, y no una auditoría completa por delante.

Por qué hay dos versiones vigentes de la WCAG a la vez

El W3C publicó la WCAG 2.2 en octubre de 2023. Pero la mayoría de los marcos legales y normativos avanzan más despacio que los organismos de estándares que los definen, así que muchas obligaciones de cumplimiento activas, incluido el estándar técnico armonizado de la EAA, la EN 301 549, todavía citan la WCAG 2.1 AA en su versión publicada actual en lugar de la 2.2. Por eso ambas versiones siguen siendo relevantes en 2026: la 2.2 es el estándar más actual y completo, pero la 2.1 es con frecuencia la que realmente se nombra en la ley.

Este desfase es normal en cómo interactúan los estándares técnicos y la legislación. Una normativa suele nombrar una versión concreta y fechada de un estándar, en lugar de “la versión vigente en cada momento”, en parte por seguridad jurídica y en parte porque actualizar las referencias técnicas de una ley conlleva su propio proceso administrativo. Se espera que la EN 301 549 termine incorporando la WCAG 2.2 en una futura versión (se espera en general que sea la v4.1.1 la que dé ese paso), pero hasta que esa actualización se adopte formalmente y quede referenciada en la normativa, la WCAG 2.1 AA sigue siendo la versión frente a la que realmente se mide la mayor parte del trabajo de cumplimiento en la UE.

Qué hay de nuevo en la WCAG 2.2

Los nuevos criterios de éxito se agrupan en torno a unos pocos temas prácticos, en lugar de estar repartidos al azar por el estándar.

La visibilidad del foco recibe tres adiciones relacionadas: 2.4.11 Foco no oscurecido (mínimo), que exige que al menos una parte del elemento con foco permanezca visible cuando algo como una cabecera fija o un aviso de cookies lo cubriría de otro modo, y los relacionados 2.4.12 (versión mejorada, AAA) y 2.4.13 Apariencia del foco (AAA), que fijan requisitos mínimos de tamaño y contraste para los indicadores de foco.

La autenticación recibe una adición importante: 3.3.8 Autenticación accesible (mínimo), que exige que los procesos de inicio de sesión no dependan únicamente de una prueba de función cognitiva (como recordar una contraseña o resolver un rompecabezas) sin una alternativa, a menos que esa prueba sea algo como el reconocimiento de objetos o cuente de otro modo con asistencia.

La interacción y los objetivos de entrada reciben dos: 2.5.7 Movimientos de arrastre, que exige una alternativa a las interacciones basadas en arrastrar, y 2.5.8 Tamaño del objetivo (mínimo), que fija un mínimo de 24 por 24 píxeles para los objetivos en los que se puede hacer clic, salvo que se apliquen excepciones.

Las adiciones restantes cubren mecanismos de ayuda coherentes (3.2.6 Ayuda coherente, que exige que una opción de ayuda como un enlace de contacto o una función de chat aparezca en el mismo lugar relativo en todas las páginas donde se ofrezca), la entrada redundante (3.3.7 Entrada redundante, que evita pedir a los usuarios que vuelvan a introducir información que ya proporcionaron antes en el mismo proceso, como volver a escribir una dirección de envío ya introducida en un paso anterior) y la Navegación por saltos de página (2.4.13, nivel AAA, pensada para contenido con numeración de página como un libro electrónico o un documento extenso).

Dos adiciones más de nivel AA completan la lista: la 2.4.11 tiene una versión mejorada de nivel AAA, y la lista completa de nivel AA suma en concreto seis criterios nuevos que la mayoría de los programas de cumplimiento realmente van a necesitar revisar: Foco no oscurecido (mínimo), Movimientos de arrastre, Tamaño del objetivo (mínimo), Ayuda coherente, Entrada redundante y Autenticación accesible (mínimo).

Qué se eliminó

La WCAG 2.2 eliminó el 4.1.1 Análisis, el antiguo requisito sobre el HTML bien formado (sin IDs duplicados, etiquetas correctamente anidadas, etc.). Los navegadores modernos y la tecnología de asistencia gestionan el HTML mal formado con la suficiente solvencia como para que el criterio ya no aportara un valor real, así que se retiró en lugar de mantenerlo.

Qué criterios nuevos importan más en la práctica

No las nueve adiciones tienen el mismo peso para el sitio típico de una empresa. Foco no oscurecido (2.4.11) es probablemente la más relevante en general, porque las barras de navegación fijas, los avisos de consentimiento de cookies y los widgets de chat que cubren el indicador de foco del teclado son un problema real extremadamente común, no un caso extremo. Tamaño del objetivo (2.5.8) importa mucho para los sitios muy orientados a móvil con objetivos táctiles pequeños. Autenticación accesible (3.3.8) importa sobre todo para cualquier cosa con un flujo de inicio de sesión, en particular si ese flujo usa CAPTCHA o retos basados en la memoria sin una vía alternativa.

Entrada redundante (3.3.7) suele importar más en los procesos de varios pasos: un checkout que pide una dirección de envío y luego vuelve a pedir la misma dirección en un paso de facturación, sin ofrecer reutilizar lo ya introducido, es un patrón bastante común al que apunta específicamente este criterio. Movimientos de arrastre (2.5.7) importa de forma desproporcionada en sitios con elementos interactivos personalizados como deslizadores de imágenes, listas ordenables o interfaces de mapa, ya que la interacción exclusiva por arrastre ha sido históricamente habitual en esos componentes sin pensar demasiado en una alternativa que no dependa de arrastrar.

¿Necesita rehacer su auditoría?

Si un sitio ya cumple con la WCAG 2.1 AA, pasar a la 2.2 no significa empezar de cero. Como la 2.2 es retrocompatible, el trabajo práctico consiste en revisar el sitio específicamente frente a los nueve criterios nuevos, no en volver a probar todo lo que ya se verificó bajo la 2.1. Las herramientas de prueba construidas en torno al motor axe-core, como las de Deque, han actualizado sus conjuntos de reglas para cubrir las adiciones de la 2.2, lo que hace que esta comprobación sea mucho más rápida que una auditoría completa. Los proveedores que ofrecen monitorización continua, como la plataforma de AudioEye con supervisión humana, también pueden señalar dónde un sitio que antes aprobaba ahora tiene carencias frente a los criterios más nuevos.

Un orden práctico de trabajo: ejecute primero un escaneo automatizado con un conjunto de reglas que contemple la 2.2 para detectar lo que es mecánicamente detectable, como objetivos táctiles pequeños o falta de coherencia en los enlaces de ayuda, y luego haga una pasada manual centrada en los criterios que requieren juicio humano, en particular Foco no oscurecido y Autenticación accesible, ya que ambos dependen de cómo experimenta la página un usuario real y no de algo que un escaneo estático pueda evaluar por completo.

Dónde suelen fallar los sitios en los nuevos criterios

Aparecen unos pocos patrones repetidamente cuando se revisan sitios frente a la 2.2 por primera vez. Las cabeceras fijas y los widgets de chat flotantes que cubren el anillo de foco del teclado mientras un usuario recorre la página con Tab son probablemente el fallo nuevo más común, precisamente porque es un patrón de diseño moderno muy extendido. Los flujos de inicio de sesión y registro que dependen de un CAPTCHA sin ningún método de verificación alternativo fallan directamente Autenticación accesible. Los sitios de comercio electrónico con interacciones basadas en arrastrar, como un carrito reordenable por arrastre o un carrusel de imágenes controlado solo arrastrando, fallan Movimientos de arrastre si no hay un botón o una alternativa táctil. Y los iconos de navegación móvil o los botones de cierre con un tamaño muy por debajo del mínimo de 24 píxeles son un fallo frecuente de Tamaño del objetivo, sobre todo en sitios diseñados principalmente para escritorio y adaptados después al móvil.

A qué versión debería apuntar

Si su ley o contrato aplicable nombra específicamente la WCAG 2.1 AA, cumplirla sigue siendo su requisito legal de referencia, y puede tratar la conformidad con la 2.2 como una mejora de cara al futuro en lugar de una obligación inmediata. Si tiene flexibilidad, o está construyendo algo nuevo, apuntar a la 2.2 AA desde el principio es la opción más a prueba de futuro, ya que es un superconjunto estricto de la 2.1 AA menos un criterio obsoleto. En cualquier caso, nuestro checklist de la WCAG 2.1 AA es una referencia de partida útil si todavía no ha auditado frente a esa base.

Para la mayoría de las empresas, la respuesta práctica termina siendo “las dos, en secuencia”: trate la WCAG 2.1 AA como el suelo del que hoy es legalmente responsable, y sume las adiciones de la WCAG 2.2 como un proyecto de mejora a corto plazo en lugar de una iniciativa aparte. Como los dos estándares se solapan casi por completo, hay poca razón para separarlos en auditorías distintas o en encargos con proveedores distintos. Una única pasada de pruebas que cubra el conjunto completo de criterios de la 2.2 cubre automáticamente también la 2.1 AA, lo cual suele ser la forma más eficiente de abordarlo, incluso si su obligación legal inmediata es solo por la versión anterior.

Mantenerse al día con las futuras versiones de la WCAG

El historial de versiones de la WCAG sugiere que este patrón se repetirá. La 2.0 fue la base durante años, la 2.1 añadió consideraciones de móvil y baja visión, y la 2.2 añadió los criterios cubiertos más arriba; una WCAG 3.0 está en desarrollo con una estructura sustancialmente distinta, aunque sigue siendo un borrador de trabajo y no un estándar terminado, y la adopción en la ley suele ir con un retraso considerable respecto a la publicación, sea cual sea la versión. La conclusión práctica para una empresa no es perseguir cada nuevo borrador, sino incorporar una revisión periódica a su proceso de accesibilidad (una vez al año es razonable para la mayoría de los sitios), de modo que cuando una versión nueva sí se vuelva relevante, ya sea por una normativa actualizada o por buenas prácticas genuinas, no tenga que empezar de cero para saber en qué punto está.