Resumen Rápido de los Cambios
WCAG 2.2, publicado en octubre de 2023, introduce 9 nuevos criterios de conformidad y elimina uno existente. Los cambios incluyen 2 criterios de nivel A, 4 de nivel AA y 3 de nivel AAA, enfocándose principalmente en mejorar la accesibilidad para usuarios con discapacidades cognitivas y usuarios de dispositivos móviles.
El criterio eliminado, 4.1.1 Análisis Sintáctico (Parsing), se consideró obsoleto debido a que los navegadores modernos manejan automáticamente los errores de HTML. Esta actualización refuerza el compromiso de W3C con estándares de accesibilidad que reflejan las necesidades actuales de los usuarios y las capacidades tecnológicas.
Introducción a los Nuevos Criterios de Conformidad
Los nuevos criterios de WCAG 2.2 abordan brechas identificadas en versiones anteriores, particularmente en áreas como la visibilidad del foco del teclado, interacciones táctiles y procesos de autenticación. Estos cambios responden directamente a investigaciones de usabilidad y comentarios de usuarios con discapacidades.
La mayoría de los nuevos requisitos se centran en el nivel AA, el estándar recomendado para cumplimiento legal en muchas jurisdicciones, incluida la Directiva Europea de Accesibilidad (EAA). Las organizaciones que ya cumplen con WCAG 2.1 nivel AA encontrarán que la transición a 2.2 requiere esfuerzos específicos en áreas como tamaños de objetivo táctil y gestión del foco visual.
2.4.11 Foco No Oscurecido (Mínimo) - Nivel AA
Este nuevo criterio de nivel AA requiere que cuando un componente de interfaz recibe el foco del teclado, al menos parte del indicador de foco debe ser visible sin que el usuario tenga que mover la ventana o el contenido. Esto aborda un problema común donde encabezados fijos, cookies banners o barras de herramientas cubren completamente el elemento enfocado.
Para cumplir con este criterio, los desarrolladores deben asegurar que al menos un píxel del indicador de foco permanezca visible cuando el usuario navega por teclado. Las soluciones típicas incluyen ajustar automáticamente el scroll para mantener elementos enfocados visibles, o rediseñar componentes fijos para que no obstruyan áreas de contenido interactivo. Este requisito beneficia significativamente a usuarios con discapacidades motoras que dependen exclusivamente de la navegación por teclado.
2.4.12 Foco No Oscurecido (Mejorado) - Nivel AAA
La versión mejorada de nivel AAA de este criterio exige que ninguna parte del indicador de foco sea oscurecida por contenido creado por el autor cuando un componente recibe el foco. Esto va más allá del requisito mínimo al prohibir cualquier oclusión, incluso parcial.
Mientras que el nivel AA permite oclusión parcial siempre que algo del foco permanezca visible, el nivel AAA requiere visibilidad completa y sin obstrucciones. Esto puede requerir técnicas avanzadas como reposicionamiento dinámico de elementos flotantes, gestión de z-index sofisticada, o mecanismos de scroll automático más agresivos. Las organizaciones que buscan la máxima accesibilidad deben considerar este estándar más estricto.
2.4.13 Apariencia del Foco - Nivel AAA
Este criterio de nivel AAA establece requisitos específicos para cómo debe verse el indicador de foco. Requiere que el indicador de foco tenga un área mínima equivalente a un borde de 2 píxeles CSS de grosor alrededor del componente, y que el contraste de color entre los estados enfocado y no enfocado sea de al menos 3:1.
El criterio también permite que el indicador de foco use el contorno predeterminado del navegador, que típicamente cumple estos requisitos automáticamente. Para diseñadores que crean indicadores de foco personalizados, esto significa calcular cuidadosamente el área del indicador (generalmente el perímetro del elemento multiplicado por 2 píxeles) y asegurar suficiente contraste de color. Estos requisitos cuantificables eliminan ambigüedad sobre qué constituye un indicador de foco adecuado.
2.5.7 Movimientos de Arrastre - Nivel AA
El criterio 2.5.7 requiere que toda funcionalidad que use movimientos de arrastre (como reordenar listas, sliders o gestos de deslizamiento) también pueda ser operada con un solo puntero sin arrastrar, a menos que el arrastre sea esencial. Esto beneficia a usuarios con temblores, control motor limitado o que usan tecnologías de asistencia alternativas.
Las implementaciones típicas incluyen proporcionar botones de flecha para reordenar listas, campos de entrada numérica para sliders, o gestos de toque simple como alternativa a deslizamientos. Por ejemplo, un carrusel de imágenes que requiere deslizar debe también ofrecer botones de siguiente/anterior. Este requisito reconoce que las interacciones de arrastre, aunque intuitivas para muchos usuarios, crean barreras significativas para otros.
2.5.8 Tamaño de Objetivo (Mínimo) - Nivel AA
Este criterio de nivel AA introduce un requisito de tamaño mínimo de 24x24 píxeles CSS para objetivos táctiles, con varias excepciones. Objetivos más pequeños son aceptables si hay suficiente espacio alrededor (al menos 24 píxeles de separación de otros objetivos), si el objetivo está en una oración, si el tamaño es controlado por el agente de usuario, o si una presentación particular es esencial.
Este estándar es más flexible que el criterio existente 2.5.5 de nivel AAA (que requiere 44x44 píxeles), reconociendo desafíos prácticos de diseño mientras aún proporciona protecciones significativas. Las áreas de objetivo más grandes benefician a todos los usuarios, particularmente aquellos con discapacidades motoras, temblores o aquellos que usan dispositivos móviles en contextos desafiantes. Los diseñadores deben auditar elementos interactivos como iconos de navegación, botones de cerrar y enlaces en línea para cumplir con este umbral.
3.2.6 Ayuda Consistente - Nivel A
El criterio 3.2.6 requiere que cuando mecanismos de ayuda como información de contacto, soporte técnico, autoayuda u opciones de contacto humano aparezcan en múltiples páginas, deben aparecer en el mismo orden relativo en cada página. Esto ayuda a usuarios con discapacidades cognitivas a ubicar ayuda de manera predecible.
El criterio no dicta qué tipo de ayuda debe proporcionarse o dónde debe aparecer en la página, solo que su posición relativa permanezca consistente en todo el sitio. Por ejemplo, si tu página de contacto lista correo electrónico, luego teléfono, luego chat, todas las páginas con estas opciones deben usar el mismo orden. Esta predictibilidad reduce la carga cognitiva y ayuda a usuarios que pueden necesitar múltiples intentos para encontrar información de ayuda.
3.3.7 Entrada Redundante - Nivel A
Este criterio de nivel A previene que se requiera a los usuarios ingresar la misma información múltiples veces durante una sesión única, a menos que la re-entrada sea esencial para seguridad, la información previa ya no sea válida, o sea necesaria para asegurar que el contenido sea correcto. La información debe ser auto-rellenada o seleccionable por el usuario.
Las implementaciones comunes incluyen llevar direcciones de envío a formularios de facturación, recordar información de usuario a través de procesos multi-paso, o pre-poblar campos con datos previamente ingresados. Este requisito beneficia particularmente a usuarios con discapacidades cognitivas, limitaciones de memoria, o aquellos que usan métodos de entrada alternativos donde escribir es costoso. Los formularios de comercio electrónico, procesos de registro multi-paso y aplicaciones largas son candidatos principales para optimización bajo este criterio.
3.3.8 Autenticación Accesible (Mínimo) - Nivel AA
El criterio 3.3.8 requiere que las pruebas de función cognitiva (como recordar contraseñas o resolver puzzles) no sean requeridas para ningún paso en un proceso de autenticación, a menos que ese paso proporcione alternativas. Métodos alternativos aceptables incluyen reconocimiento de objetos, contenido personal (como fotos que el usuario subió), o mecanismos que no dependen de recordar o transcribir información.
En la práctica, esto significa que sitios deben ofrecer opciones como autenticación biométrica, gestores de contraseñas, links mágicos de correo electrónico, o códigos de acceso de un solo uso junto con contraseñas tradicionales. Este requisito reconoce que recordar contraseñas complejas crea barreras significativas para usuarios con discapacidades cognitivas, mientras también beneficia a usuarios mayores y aquellos con condiciones que afectan la memoria. La autenticación de dos factores debe también cumplir con este criterio si es requerida.
3.3.9 Autenticación Accesible (Mejorada) - Nivel AAA
La versión mejorada de nivel AAA de este criterio elimina completamente la excepción permitida en el nivel AA, requiriendo que ninguna prueba de función cognitiva sea necesaria para ningún paso en un proceso de autenticación. Esto significa que incluso reconocer objetos o contenido personal no puede ser el único método de autenticación.
El cumplimiento del nivel AAA típicamente requiere implementar métodos de autenticación completamente no cognitivos como biometría (huella digital, reconocimiento facial), tokens de hardware, o autenticación basada en posesión de dispositivos (links mágicos, códigos de un solo uso). Mientras que este nivel es opcional, representa el estándar más alto de accesibilidad de autenticación y debería ser considerado por organizaciones que sirven a poblaciones con necesidades cognitivas significativas o aquellas que buscan la máxima inclusividad.
Criterio Eliminado: 4.1.1 Análisis Sintáctico
WCAG 2.2 elimina oficialmente el criterio 4.1.1 Análisis Sintáctico, que requería que el contenido implementado usando lenguajes de marcado tuviera elementos con etiquetas de inicio y fin completas, elementos anidados según sus especificaciones, sin atributos duplicados, y IDs únicos. Este criterio fue considerado obsoleto porque los navegadores modernos han mejorado dramáticamente en el manejo de errores de HTML.
Sin embargo, la eliminación no significa que el marcado válido sea sin importancia. Un HTML bien formado sigue siendo crucial para la accesibilidad porque las tecnologías de asistencia dependen de estructuras DOM predecibles. El Grupo de Trabajo actualizó la nota explicativa para aclarar que mientras el análisis sintáctico estricto ya no es un requisito de conformidad, los desarrolladores aún deben seguir las mejores prácticas de HTML para asegurar compatibilidad con tecnologías de asistencia. Las herramientas de validación siguen siendo valiosas para identificar problemas que podrían afectar la experiencia del usuario.
Requisitos de la Directiva Europea de Accesibilidad (EAA)
La Directiva Europea de Accesibilidad (EAA), que entra en vigor el 28 de junio de 2025, hace referencia a WCAG 2.1 nivel AA como su estándar técnico. Sin embargo, los reguladores y grupos de defensa han indicado que si bien WCAG 2.1 es el requisito mínimo legal, las organizaciones deberían apuntar a WCAG 2.2 cuando sea posible, ya que representa las mejores prácticas actuales.
Los estados miembros de la UE están implementando la EAA a través de legislación nacional, y algunos pueden adoptar WCAG 2.2 como su estándar de referencia directamente. Las organizaciones que operan en Europa deberían monitorear los desarrollos regulatorios en sus mercados específicos mientras planean sus estrategias de accesibilidad. Implementar WCAG 2.2 ahora proporciona una protección más sólida y prepara las organizaciones para futuros requisitos regulatorios probables.
¿Debería Apuntar a WCAG 2.2?
Para la mayoría de las organizaciones, la respuesta es sí. WCAG 2.2 es completamente compatible con versiones anteriores, lo que significa que cualquier cosa conforme a WCAG 2.1 también cumple con 2.1 bajo 2.2 (excepto por el criterio eliminado 4.1.1). Los nuevos criterios abordan brechas de accesibilidad del mundo real que afectan a usuarios reales, particularmente aquellos con discapacidades cognitivas y usuarios móviles.
Las consideraciones prácticas incluyen que WCAG 2.2 representa el estándar actual de la industria y probablemente se convierta en el requisito legal a medida que las regulaciones se actualicen. Los cambios requeridos son generalmente modestos para sitios ya conformes con 2.1 nivel AA, enfocándose en tamaños de objetivo, visibilidad del foco y mejoras de formularios. La adopción temprana demuestra compromiso con la accesibilidad y reduce el riesgo de remedios costosos más adelante. A menos que tengas restricciones muy específicas, implementar WCAG 2.2 ofrece la mejor relación entre mejora de accesibilidad y esfuerzo requerido.
Cómo Probar el Cumplimiento de WCAG 2.2
Las pruebas de WCAG 2.2 requieren una combinación de herramientas automatizadas, inspección manual y pruebas con usuarios. Comienza usando herramientas de accesibilidad automatizadas como axe DevTools, WAVE o Lighthouse para capturar problemas obvios, pero reconoce que la automatización solo puede detectar aproximadamente el 30-40% de los problemas de accesibilidad. La revisión manual es esencial para los nuevos criterios.
Para los criterios específicos de 2.2, prueba la navegación por teclado con encabezados fijos para verificar la visibilidad del foco (2.4.11), mide los tamaños de objetivo con herramientas de desarrollo del navegador (2.5.8), completa formularios multi-paso para verificar la entrada redundante (3.3.7), y revisa los flujos de autenticación para alternativas cognitivas (3.3.8). Considera contratar auditores de accesibilidad profesionales para evaluaciones exhaustivas, y más importante aún, realiza pruebas de usabilidad con usuarios que tienen discapacidades para descubrir problemas que las pruebas técnicas podrían pasar por alto. El cumplimiento no es un evento único sino un proceso continuo de monitoreo, pruebas y mejoras.