Qué cambió en WCAG 2.2 frente a WCAG 2.1

Las Web Content Accessibility Guidelines (WCAG) son el estándar al que apuntan la mayoría de las leyes de accesibilidad. WCAG 2.2 se convirtió en Recomendación W3C el 5 de octubre de 2023, añadió nueve nuevos criterios de éxito y retiró uno. Ahora también es ISO/IEC 40500:2025. Si mantienes un sitio web, design system o producto en 2026, la pregunta práctica es: qué cambió, qué exige cada nuevo criterio y cómo priorizar las correcciones. Este post responde a cada uno, con fuentes citadas para que puedas verificar.

Breve historia de WCAG

El W3C publicó las primeras Web Content Accessibility Guidelines el 5 de mayo de 1999. WCAG 1.0 era prescriptiva y específica de HTML; envejeció rápido cuando la web pasó de documentos planos a aplicaciones ricas.

WCAG 2.0 llegó el 11 de diciembre de 2008. Abstrajo la guía de cualquier tecnología, la organizó bajo los cuatro principios «Perceptible, Operable, Comprensible, Robusto» (POUR), e introdujo el esquema de tres niveles A/AA/AAA que aún se usa. Es la versión que la mayoría de las regulaciones americanas e internacionales referenciaban originalmente.

WCAG 2.1 siguió el 5 de junio de 2018. Añadió 17 nuevos criterios cubriendo móvil (orientación, blancos táctiles, activación por movimiento), usuarios con baja visión (reflow, espaciado de texto, contraste no-texto) y accesibilidad cognitiva (label-in-name, mensajes de estado). Es la versión incorporada al estándar EN 301 549 v3.2.1 referenciado por la European Accessibility Act.

WCAG 2.2 se publicó el 5 de octubre de 2023 y se republicó con actualizaciones editoriales el 12 de diciembre de 2024. Añade nueve criterios nuevos, retira uno (4.1.1 Parsing) y ahora también es ISO/IEC 40500:2025. WCAG 3, un marco sustancialmente distinto con scoring nuevo, sigue en borrador y no se espera adopción general antes de 2027.

Los nueve nuevos criterios de éxito

Los nuevos criterios caen en tres clústeres temáticos: foco, modalidad de entrada, accesibilidad cognitiva.

Clúster foco

2.4.11 Foco No Ocultado (Mínimo), Nivel AA. Cuando un componente de interfaz recibe foco de teclado, no debe estar enteramente oculto por contenido del autor (cabeceras pegajosas, banners de cookies, widgets de chat). El componente puede estar parcialmente ocultado; el criterio solo falla cuando nada es visible.

2.4.12 Foco No Ocultado (Mejorado), Nivel AAA. Versión más estricta de 2.4.11: ninguna parte del componente con foco puede estar oculta. Versión AAA que la mayoría de design systems empresariales apuntan.

2.4.13 Apariencia del Foco, Nivel AAA. El indicador de foco debe tener al menos 2 píxeles CSS de grosor alrededor del control con foco, y su contraste contra el estado no-enfocado adyacente debe ser al menos 3:1. Un anillo de foco 1px por defecto sobre un botón oscuro falla; un anillo 2px de alto contraste pasa.

Clúster modalidad de entrada

2.5.7 Movimientos de Arrastre, Nivel AA. Todo lo que pueda hacerse con un gesto de arrastre debe poder hacerse también sin él. Ejemplos: listas ordenables que solo responden a arrastre, sliders, panorama de mapa. El criterio no prohíbe el arrastre; exige una alternativa como flechas arriba/abajo para reordenar, o campo de entrada de texto para valores de slider.

2.5.8 Tamaño de Blanco (Mínimo), Nivel AA. Los blancos de puntero deben tener al menos 24 por 24 píxeles CSS, salvo que estén en línea (enlaces en un párrafo), expuestos en un default del user-agent (un <select>), esenciales a la función, o tengan un control equivalente en otra parte de la página que cumpla 24x24. El criterio WCAG 2.1 2.5.5 anterior fijaba el umbral en 44x44 pero al nivel AAA; 2.5.8 hace obligatorio un suelo 24x24 más pequeño al nivel AA.

Clúster accesibilidad cognitiva

3.2.6 Ayuda Consistente, Nivel A. Si los mecanismos de ayuda («Contáctanos», widget de chat, enlace de ayuda, teléfono de ayuda) aparecen en varias páginas, deben aparecer en el mismo orden relativo en cada página. La intención es reducir la carga cognitiva.

3.3.7 Entrada Redundante, Nivel A. Los usuarios no deberían tener que reingresar información que ya proporcionaron en el mismo proceso. Los formularios multi-paso deben recordar entradas previas. El criterio no prohíbe volver a preguntar cuando es esencial (verificación de seguridad) o cuando la información ha cambiado.

3.3.8 Autenticación Accesible (Mínimo), Nivel AA. La autenticación no puede exigir pruebas de función cognitiva como recordar una contraseña, resolver un puzzle o transcribir un CAPTCHA basado en imagen, salvo que se proporcione una alternativa. Alternativas aceptables: gestor de contraseñas, código de un solo uso, biometría, token de hardware.

3.3.9 Autenticación Accesible (Mejorada), Nivel AAA. Versión más estricta: puzzles de reconocimiento de objetos y contenido personal también prohibidos, salvo alternativa.

El criterio retirado

4.1.1 Parsing se retiró como obsoleto. Exigía que el contenido fuera analizable: etiquetas de inicio/fin completas, sin IDs duplicados, elementos correctamente anidados. En 2008 esto importaba porque las tecnologías asistivas parseaban HTML ellas mismas y fallaban con markup malformado. En 2024 cada tecnología asistiva consume el árbol de accesibilidad del navegador, no HTML crudo. WCAG 2.2 reconoce esto retirando el criterio. Sigue apareciendo en conformidad WCAG 2.0 y 2.1, no en 2.2.

Niveles de conformidad, repaso

Impacto práctico, por dónde empezar

1. 2.5.8 Tamaño de Blanco (Mínimo), 24x24 píxeles CSS. Auditar botones, enlaces de icono y toggles pequeños. Controles menores a 24x24 necesitan área de clic mayor, más espacio alrededor o un control equivalente más grande en la página. Fallo 2.2 más común en sitios existentes.
2. 2.4.11 Foco No Ocultado (Mínimo). Buscar barras pegajosas inferiores, footers pegajosos, widgets de chat, banners de cookies que solapan el bottom del viewport. Cuando un elemento focalizable se desplaza tras uno de ellos, el criterio falla. Arreglo: scroll-margin-bottom en elementos focalizables igual a la altura de la barra pegajosa.
3. 3.3.8 Autenticación Accesible (Mínimo). Retirar CAPTCHA de imagen de flujos de login; reemplazar con CAPTCHA invisible o enfoque por límite de tasa. Permitir gestores de contraseñas (no desactivar autocomplete en campos password). Permitir pegado de códigos de un solo uso.
4. 2.5.7 Movimientos de Arrastre. Proporcionar alternativa no-arrastre para cualquier interacción solo-arrastre. Listas ordenables: flechas arriba/abajo. Sliders: input numérico. Mapas: botones de pan.
5. 3.2.6 Ayuda Consistente. Si tu enlace «Contacto» o «Ayuda» aparece en varias páginas, posiciónalo consistentemente.
6. 3.3.7 Entrada Redundante. Formularios multi-paso deben recordar entradas previas.

Errores comunes implementando los nuevos criterios

• Tratar 4.1.1 Parsing como ido en todas partes. 4.1.1 está retirado de WCAG 2.2 pero sigue siendo exigido por WCAG 2.0 y 2.1. Si tu contrato o regulación especifica 2.1, la regla parsing aún aplica.
• Malinterpretar 2.5.8 Tamaño de Blanco. El mínimo 24x24 es para el blanco, no el icono visible. Un icono 16x16 dentro de un botón 24x24 pasa. Un icono 16x16 en un botón 16x16 falla.
• Olvidar excepciones a 2.5.8. Enlaces en línea dentro de un párrafo, controles user-agent por defecto, blancos esenciales y controles equivalentes más grandes en otro lugar de la página están exentos.
• Implementar 3.3.8 retirando todo CAPTCHA. Puedes mantener CAPTCHA; solo necesitas un camino alternativo accesible. Tests de Turing inversos, límites de tasa, magic links, passkeys o tokens hardware califican.
• 2.4.11 confundido con 2.4.13. Foco No Ocultado (2.4.11) es si el elemento con foco es visible. Apariencia del Foco (2.4.13) es sobre el propio indicador siendo grueso y contrastado. Requisitos distintos a niveles distintos.
• Saltar 2.4.13 por ser AAA. Varios gobiernos (Noruega, partes de Canadá) han adoptado reglas nivel AAA para sitios del sector público.

Herramientas para comprobar conformidad WCAG 2.2

Las herramientas automatizadas capturan aproximadamente 30 a 40 % de fallos WCAG en su mejor caso. Los nuevos criterios 2.2 son particularmente duros de automatizar (2.5.7, 3.2.6, 3.3.7, 3.3.8) porque exigen entender flujo de usuario, no solo markup. Plan: test manual de teclado en cada release.

Privacidad y las herramientas

El verificador de contraste, el verificador de cabeceras WCAG y el generador de paleta accesible de Absolutool corren todos enteramente en tu navegador. El HTML o valores de color que pegas se procesan por JavaScript en tu dispositivo, los resultados se renderizan en la página, y no se envía nada a un servidor. Sin telemetría sobre la entrada, sin scripts de terceros tocando el contenido, sin caché después de navegar. Para auditorías internas de design system, colores de marca aún no lanzados, o cualquier dato de auditoría bajo embargo, ese flujo estrictamente local es el valor por defecto correcto. Las herramientas pueden correr offline una vez cargada la página, lo que puedes verificar desconectando la red y recomprobando un par de contraste.