WCAG 2.2 vs WCAG 2.1: Qué hay de nuevo y qué necesitas actualizar

Más del 96% de las páginas de inicio siguen sin cumplir los requisitos básicos de las WCAG, según el análisis de accesibilidad de WebAIM de 2024, y eso frente a un estándar que ya tenía cinco años. El 5 de octubre de 2023, el W3C publicó WCAG 2.2 como estándar web oficial, elevando el listón con nueve nuevos criterios de éxito y retirando un criterio que había quedado obsoleto. Si gestionas un sitio web, creas productos digitales o supervisas el cumplimiento normativo, esta actualización no es algo que puedas aplazar indefinidamente. Las normativas de la UE, el Reino Unido y, cada vez más, de los estados de EE. UU. ya se están moviendo para referenciar WCAG 2.2 como su punto de referencia.

Una breve historia: de WCAG 2.1 a WCAG 2.2

Las Pautas de Accesibilidad para el Contenido Web han evolucionado de forma constante desde que WCAG 2.0 se lanzó en diciembre de 2008. WCAG 2.1 llegó en junio de 2018, añadiendo 17 nuevos criterios de éxito con un enfoque particular en las personas usuarias de dispositivos móviles y en personas con baja visión o discapacidades cognitivas. Durante cinco años, sirvió como referencia de cumplimiento de facto para leyes como la ADA, la Sección 508 y la Directiva de Accesibilidad Web de la UE.

WCAG 2.2 retoma exactamente donde lo dejó la 2.1. El W3C la inició con el objetivo explícito de seguir mejorando la orientación en accesibilidad para tres grupos principales: personas usuarias con discapacidades cognitivas o de aprendizaje, personas con baja visión y personas con discapacidades que usan dispositivos móviles. Ese linaje importa porque significa que la actualización es evolutiva, no revolucionaria, pero sigue siendo lo suficientemente significativa como para requerir acción por tu parte.

Una de las cosas más importantes que hay que entender a nivel estructural es que WCAG 2.2 es totalmente compatible hacia atrás con WCAG 2.1. Cumplir con WCAG 2.2 significa automáticamente que también cumples con WCAG 2.1 y WCAG 2.0. Si tu organización cumple actualmente con WCAG 2.1 AA, solo necesitas abordar los nuevos criterios introducidos en 2.2: no estás empezando desde cero. El W3C también aconseja que, aunque WCAG 2.0 y 2.1 siguen siendo recomendaciones válidas, las organizaciones deberían usar WCAG 2.2 para maximizar la aplicabilidad futura de su trabajo en accesibilidad.

También se espera ampliamente que WCAG 2.2 sea la última versión menor de la familia WCAG 2.x. La próxima versión principal, WCAG 3.0, es una criatura completamente diferente: una reconsideración desde cero de cómo se estructuran las pautas de accesibilidad. Eso convierte a WCAG 2.2 en el punto final definitivo de un linaje que se remonta a 2008, y en la versión que necesitas tener bien implementada ahora.

Los números: qué cambió realmente

Seamos precisos sobre el alcance del cambio. WCAG 2.1 contenía 78 criterios de éxito repartidos en tres niveles de conformidad (A, AA y AAA). WCAG 2.2 añade nueve nuevos criterios de éxito y elimina uno —el Criterio de Éxito 4.1.1 Análisis sintáctico (Parsing)—, dejando el total en 86 criterios activos. De esas nueve incorporaciones, dos son de Nivel A, cuatro de Nivel AA y tres de Nivel AAA.

Para la gran mayoría de las organizaciones que apuntan al cumplimiento de Nivel AA —el nivel referenciado en la mayoría de las leyes y regulaciones—, el impacto práctico es de seis nuevos criterios que implementar. Las tres incorporaciones de Nivel AAA se consideran buenas prácticas y a menudo se recomiendan en contextos gubernamentales y sanitarios, pero no son un requisito legal estricto en la mayoría de las jurisdicciones hoy en día.

Los nuevos criterios abordan principalmente cuatro áreas problemáticas que las auditorías de accesibilidad en el mundo real habían señalado repetidamente como poco cubiertas por el estándar existente: visibilidad del foco del teclado, interacciones táctiles y con puntero, accesibilidad cognitiva y barreras de autenticación. No son preocupaciones teóricas. Son el tipo de barreras que con frecuencia impiden que las personas con discapacidad completen tareas cotidianas como iniciar sesión, rellenar un formulario o navegar por una página con una cabecera fija (sticky).

Explicación de los nueve nuevos criterios de éxito

A continuación se presenta un desglose de cada nuevo criterio, lo que exige y por qué importa en la práctica. Los criterios se presentan por nivel de conformidad para que puedas priorizar tu trabajo de remediación.

Nivel A (Mínimo — Requerido para todos)

• 2.4.11 Foco no oculto (mínimo): Cuando un componente de la interfaz de usuario recibe el foco del teclado, no debe quedar completamente oculto por contenido creado por el autor. Los culpables más comunes aquí son las cabeceras fijas, los banners flotantes de cookies y los widgets de chat en vivo que se superponen a la página. Si una persona usuaria que pulsa Tab aterriza en un botón que queda completamente cubierto por tu barra de navegación fija, se incumple este criterio. Ten en cuenta que que esté parcialmente oculto es aceptable en el Nivel A: el elemento simplemente no puede quedar oculto al 100%.
• 2.5.7 Movimientos de arrastre: Cualquier funcionalidad que requiera un movimiento de arrastre —piensa en cargas de archivos mediante arrastrar y soltar, elementos de listas ordenables o controles deslizantes— también debe poder operarse con una única acción de puntero (como un clic o un toque) sin arrastrar. Esto es fundamental para personas con discapacidades motoras que no pueden ejecutar de forma fiable gestos de arrastre controlados. El requisito se aplica al contenido creado por el autor; los comportamientos nativos del navegador están exentos.

Nivel AA (Requerido para el cumplimiento estándar)

• 2.4.12 Foco no oculto (mejorado): Una versión más estricta de 2.4.11. En el Nivel AA, ninguna parte del indicador de foco puede quedar oculta por contenido creado por el autor cuando un elemento recibe el foco del teclado. Esto cierra la laguna de la versión de Nivel A y exige que los elementos con foco sean totalmente visibles, no solo parcialmente.
• 2.5.8 Tamaño del objetivo (mínimo): El área clicable o táctil de los elementos interactivos debe ser de al menos 24×24 píxeles CSS, con excepciones específicas para enlaces de texto en línea, elementos controlados por el agente de usuario y casos en los que exista cerca un objetivo equivalente de 24×24. Este es un cambio significativo respecto a WCAG 2.1, donde un tamaño de objetivo de 44×44 píxeles solo se recomendaba en el nivel AAA. Ahora se puede hacer cumplir un mínimo básico en AA. Ten en cuenta que, aunque 24×24 px es el mínimo, el criterio AAA (2.5.5) sigue recomendando 44×44 px, y ese sigue siendo el estándar de oro para un diseño amigable al tacto.
• 3.2.6 Ayuda consistente: Si un sitio web proporciona mecanismos de ayuda —datos de contacto humanos, herramientas de autoayuda, chat automatizado o un formulario de contacto— y esos mecanismos aparecen en varias páginas, deben aparecer en la misma posición relativa en todas esas páginas. Las personas que necesitan ayuda, especialmente aquellas con discapacidades cognitivas, deben poder encontrarla siempre en el mismo lugar sin tener que buscar.
• 3.3.7 Entrada redundante: La información que una persona usuaria ya haya introducido en un paso anterior del mismo proceso debe rellenarse automáticamente para ella o estar disponible para seleccionar, de modo que no tenga que escribirla de nuevo. Piensa en flujos de pago en varios pasos que piden una dirección de facturación y luego vuelven a pedir una dirección de envío: se debe ofrecer a las personas usuarias una forma de copiar lo que ya introdujeron. Se permiten excepciones cuando volver a introducir la información es esencial por motivos de seguridad (como confirmar una contraseña) o cuando los datos introducidos anteriormente ya no son válidos.
• 3.3.8 Autenticación accesible (mínimo): No se deben exigir pruebas de función cognitiva —como resolver un rompecabezas, memorizar una contraseña o transcribir caracteres de un CAPTCHA de imagen— como único medio de autenticicación. Debe existir un método alternativo o un mecanismo que ayude a la persona usuaria (como permitir el uso de un gestor de contraseñas o permitir copiar y pegar en el campo de contraseña). Este criterio no prohíbe los CAPTCHAs por completo, pero sí exige que nunca sean la única opción para las personas que no pueden completarlos.

Nivel AAA (Mejorado — Recomendado pero no obligatorio para la mayoría)

• 2.4.13 Apariencia del foco: Cuando el indicador de foco del teclado es visible, debe cumplir requisitos mínimos específicos de tamaño y contraste: el área de foco debe ser al menos tan grande como un perímetro de 2 píxeles CSS de grosor alrededor del elemento, y debe haber una relación de contraste de al menos 3:1 entre los estados con foco y sin foco. Este criterio se planificó originalmente para el Nivel AA, pero se trasladó a AAA debido a su complejidad. Significa que, para el cumplimiento solo de AA, todavía no hay un tamaño mínimo definido normativamente para un indicador de foco, solo que debe ser visible.
• 2.5.9 Movimientos de arrastre (mejorado): Espera: no hay 2.5.9 en esta versión. La mejora AAA sobre arrastre se recoge en 3.3.9 más abajo.
• 3.3.9 Autenticación accesible (mejorada): Una versión más estricta de 3.3.8. En el Nivel AAA, también se prohíben las pruebas de reconocimiento de objetos y de contenido personal (como “haz clic en todos los semáforos” o “selecciona fotos de tu cuenta”), no solo las excepciones contempladas en el Nivel AA. Solo quedan dos excepciones en lugar de cuatro.

Qué se eliminó: 4.1.1 Análisis sintáctico (Parsing)

WCAG 2.2 elimina un criterio de éxito que había estado vigente desde WCAG 2.0: 4.1.1 Análisis sintáctico (Parsing). Este criterio exigía originalmente que el HTML estuviera bien formado, con etiquetas de inicio y fin completas, anidamiento correcto y sin atributos duplicados. La intención era garantizar que los navegadores y las tecnologías de apoyo pudieran analizar el marcado de forma fiable y presentar el contenido correctamente a las personas usuarias.

La eliminación no es controvertida: refleja un cambio real en el panorama técnico. Desde 2008, los navegadores se han vuelto extraordinariamente buenos a la hora de gestionar con elegancia el HTML mal formado, siguiendo un algoritmo de corrección de errores coherente y estandarizado. Las tecnologías de apoyo como los lectores de pantalla ahora dependen del Modelo de Objetos del Documento (DOM) del navegador, no del código fuente HTML en bruto. El W3C concluyó que el criterio ya no aporta ningún beneficio significativo de accesibilidad en el entorno moderno. Los problemas de accesibilidad que antes se detectaban con 4.1.1 siguen estando cubiertos por criterios más específicos como 1.3.1 (Información y relaciones) y 4.1.2 (Nombre, función, valor).

Las implicaciones prácticas para tu equipo: si tus herramientas de pruebas automatizadas han estado señalando fallos de 4.1.1 Análisis sintáctico, estos ya no son problemas de WCAG 2.2. Es posible que veas una reducción en los fallos reportados únicamente por la actualización de versión, no porque se haya corregido nada. Dicho esto, escribir HTML válido y bien estructurado sigue siendo una buena práctica sólida: simplemente ya no es un requisito de cumplimiento por sí mismo.

Implicaciones normativas y legales

Entender los nuevos criterios es una cosa. Entender lo que significan para tu exposición legal es otra. La respuesta breve es: WCAG 2.2 se está convirtiendo en la ley de facto en múltiples jurisdicciones, y el calendario avanza más rápido de lo que muchas organizaciones creen.

En el Reino Unido, los organismos del sector público ya están obligados a cumplir WCAG 2.2 Nivel AA en virtud de las Public Sector Bodies Accessibility Regulations. En la Unión Europea, la norma EN 301 549 —el estándar técnico que sustenta la Ley Europea de Accesibilidad— está en proceso de adoptar WCAG 2.2 como su base. La propia EAA tiene un plazo de aplicación en junio de 2025 para la mayoría de las organizaciones del sector privado que ofrecen productos y servicios en la UE. Varios estados de EE. UU., incluido Colorado, también han expresado su intención de actualizar sus leyes estatales de accesibilidad de WCAG 2.1 a WCAG 2.2.

En Estados Unidos, el Título II de la ADA hace referencia actualmente a WCAG 2.1 AA como estándar técnico para los sitios web de gobiernos estatales y locales. Sin embargo, los tribunales estadounidenses han citado cada vez más WCAG 2.2 en demandas por accesibilidad, y la trayectoria es clara. Esperar a un mandato federal formal antes de actuar es una estrategia de cumplimiento que conlleva un riesgo legal creciente, especialmente para organizaciones de comercio electrónico, servicios financieros y sanidad, que son objetivos de alto valor para litigios de accesibilidad.

Aunque tu organización aún no esté legalmente obligada a cumplir WCAG 2.2, cumplir los nuevos criterios de éxito más pronto que tarde garantizará que te adelantes a los cambios normativos y, lo que es más importante, a las barreras reales de accesibilidad a las que se enfrentan tus personas usuarias hoy.

Cómo auditar y actualizar tu sitio

Si ya cumples con WCAG 2.1 AA, la ruta de actualización a WCAG 2.2 es manejable. Aquí tienes un marco práctico para abordarla.

Empieza con una auditoría específica de los seis nuevos criterios de Nivel AA. Estos son los que tienen peso legal para la mayoría de las organizaciones. Concéntrate especialmente en 2.4.11 y 2.4.12 (foco oculto), 2.5.8 (tamaño del objetivo), 3.2.6 (ayuda consistente), 3.3.7 (entrada redundante) y 3.3.8 (autenticación accesible). Una persona ingeniera de accesibilidad con experiencia puede auditar manualmente estos criterios en unas pocas horas para un sitio de complejidad moderada.

Audita primero tus elementos fijos/posicionados de forma sticky. Los criterios de foco oculto (2.4.11 y 2.4.12) se incumplen con algunos de los patrones de interfaz más comunes en la web: cabeceras fijas, botones de acción flotantes, barras de consentimiento de cookies y widgets de chat. Recorre todo tu sitio usando solo la tecla Tab y observa si algún elemento con foco desaparece bajo una capa fija. La corrección en CSS suele ser sencilla:

/* Evitar que la cabecera fija cubra elementos con foco */
:focus {
  scroll-margin-top: 80px; /* iguala la altura de tu cabecera fija */
}

Audita el tamaño del objetivo táctil de cada elemento interactivo. A menudo esto es una mejora rápida tanto en términos de cumplimiento como de experiencia de usuario. Los botones, enlaces, controles de formulario e iconos necesitan un mínimo de 24×24 píxeles CSS. Muchos sistemas de diseño ya superan este umbral, pero los botones de icono pequeños —iconos de cierre, botones de compartir en redes sociales y enlaces de acción en línea— son infractores frecuentes. Inspecciona tus componentes y añade relleno o ajusta las dimensiones cuando sea necesario.

Revisa detenidamente tus flujos de autenticación. El CE 3.3.8 (Autenticación accesible) tiene un impacto real. Si utilizas un CAPTCHA que no se puede omitir o resolver mediante un método alternativo, probablemente no cumples. Evalúa si tus flujos de inicio de sesión, registro y autenticación de dos factores permiten que los gestores de contraseñas autocompleten, permiten copiar y pegar, ofrecen un método de verificación alternativo (como un enlace mágico o un código de un solo uso) o proporcionan cualquier otra adaptación para las personas que no pueden completar una prueba cognitiva.

Audita los formularios de varios pasos en busca de entradas redundantes. Mapea cualquier proceso que abarque varios pasos —pagos, flujos de incorporación, solicitudes— e identifica cada caso en el que se pide a una persona usuaria que proporcione información que ya facilitó. Añade lógica de autocompletado o un conmutador de “igual que arriba” cuando proceda. Normalmente se trata de un cambio de back-end o de gestión del estado del formulario más que de una revisión arquitectónica compleja.

Verifica que los mecanismos de ayuda estén posicionados de forma consistente. Si tienes un widget de chat, un enlace de ayuda o un número de teléfono que aparece en un pie de página o barra lateral en varias páginas, comprueba que su posición relativa no cambie. Normalmente se trata de un problema de plantilla o de diseño, más que de una cuestión página por página: arréglalo en tu biblioteca de componentes o en la plantilla de tu CMS y se propagará a todas partes.

Utiliza herramientas automatizadas para el descubrimiento inicial, pero no te quedes ahí. Los escáneres automatizados pueden detectar aproximadamente el 40% de los problemas de WCAG 2.2: son útiles para detectar infracciones de tamaño de objetivo y problemas evidentes de gestión del foco, pero no pueden evaluar si un CAPTCHA es la única opción de autenticación o si un mecanismo de ayuda está posicionado de forma consistente. Las pruebas manuales, incluida la navegación solo con teclado y las pruebas con lectores de pantalla, siguen siendo esenciales. Las pruebas con personas usuarias reales con discapacidad detectarán problemas que ninguna herramienta automatizada podrá encontrar jamás.

WCAG 2.2 y widgets de overlay: lo que debes saber

Los widgets y SDK de overlay de accesibilidad —herramientas como Accsible— pueden proporcionar una ayuda significativa para detectar y remediar ciertas categorías de problemas de accesibilidad, especialmente para personas usuarias que necesitan ajustes en tiempo real como aumento del tamaño de fuente, cambios de contraste o mejoras en la navegación por teclado. Conviene tener claro qué pueden y qué no pueden hacer los overlays en el contexto del cumplimiento de WCAG 2.2.

Los overlays pueden ayudar a abordar ciertos problemas de visibilidad del foco, proporcionar modos de navegación alternativos y ofrecer personalización del lado de la persona usuaria que compense algunas carencias a nivel de diseño. Son una capa útil dentro del stack de accesibilidad, especialmente para equipos que necesitan mejorar la experiencia de usuario rápidamente mientras se lleva a cabo un trabajo de remediación a más largo plazo. Sin embargo, no sustituyen a la corrección del código subyacente. Los nuevos criterios de WCAG 2.2 —especialmente los relacionados con la autenticación (3.3.8), la entrada redundante (3.3.7) y los movimientos de arrastre (2.5.7)— requieren cambios estructurales en cómo está construida tu aplicación, no solo en cómo se presenta.

El enfoque más eficaz combina un overlay bien implementado para la adaptabilidad de cara a la persona usuaria con correcciones adecuadas a nivel de código para los nuevos criterios de la 2.2. Piensa en un SDK de overlay como un multiplicador de fuerza: amplía tu alcance, mejora la experiencia para más personas usuarias y cubre lagunas, pero la base sigue teniendo que ser sólida.

Conclusiones clave

• WCAG 2.2 añade nueve nuevos criterios de éxito y elimina una regla obsoleta (4.1.1 Análisis sintáctico). Es totalmente compatible hacia atrás con 2.1, por lo que tu trabajo de cumplimiento existente no se desperdicia: solo necesitas superponer lo que es nuevo.
• Para el cumplimiento de Nivel AA, céntrate en seis criterios nuevos específicos: Foco no oculto (2.4.11 y 2.4.12), tamaño mínimo del objetivo (2.5.8), ayuda consistente (3.2.6), entrada redundante (3.3.7) y autenticación accesible (3.3.8). Estos son los legalmente relevantes para la mayoría de las organizaciones.
• La adopción normativa se está acelerando. El sector público del Reino Unido ya aplica WCAG 2.2, la UE está en transición hacia él en el marco de la Ley Europea de Accesibilidad y los tribunales de EE. UU. lo citan cada vez más. No esperes a un mandato formal en tu jurisdicción antes de actuar.
• Las herramientas automatizadas solo detectan alrededor del 40% de los problemas de WCAG 2.2: las pruebas manuales, los recorridos de navegación solo con teclado y las pruebas con personas usuarias reales son esenciales para lograr un cumplimiento genuino, especialmente en los nuevos criterios relacionados con la autenticación y la accesibilidad cognitiva.
• Las mejoras rápidas más comunes son corregir cabeceras fijas que ocultan elementos con foco, agrandar objetivos táctiles pequeños y auditar tus flujos de inicio de sesión/autenticación para detectar dependencia de CAPTCHA. Estos cambios suelen requerir poco esfuerzo y tener un gran impacto: un buen punto de partida para tu sprint de remediación de WCAG 2.2.