Qué hay de nuevo en WCAG 2.2: Explicación de los 9 nuevos criterios de éxito

Los estándares de accesibilidad web no se quedan quietos. A medida que los hábitos de navegación cambian hacia dispositivos móviles, más personas dependen de la navegación por teclado y voz, y las brechas en las pautas anteriores se hacen más evidentes, las reglas para construir sitios web accesibles se actualizan para mantenerse al día. La actualización más reciente es WCAG 2.2(opens in a new tab).

Una distinción importante: WCAG 2.2 no reemplaza WCAG 2.0 ni 2.1 — los tres siguen siendo estándares activos. Pero el World Wide Web Consortium (W3C) recomienda trabajar hacia la versión más reciente, porque se basa en todo lo anterior.

Para la mayoría de las organizaciones, la pregunta es “¿qué cambió en WCAG 2.2 y qué debo hacer al respecto?” en lugar de “¿qué es WCAG 2.2?”. Si ya cumples con WCAG 2.1 Nivel AA, ya tienes gran parte del camino recorrido: WCAG 2.2 añade nueve nuevos criterios de éxito y retira uno, así que la brecha es pequeña, pero específica.

A continuación, desglosaremos los nueve nuevos criterios, explicaremos qué cambió respecto a WCAG 2.1 y mostraremos cómo comprobar dónde tu sitio no cumple.

La evolución de las Pautas de Accesibilidad para el Contenido Web

WCAG ha evolucionado de forma constante desde que el W3C publicó la primera versión en 1999. WCAG 2.0 (creada en 2008) introdujo los cuatro principios de la accesibilidad web y extendió las pautas a todo el contenido digital; WCAG 2.1 (creada en 2018) añadió criterios para móviles y una gama más amplia de discapacidades; y WCAG 2.2, publicada en octubre de 2023, añade los nueve nuevos criterios de éxito que se cubren a continuación, enfocados en usuarios con baja visión, discapacidades cognitivas o de aprendizaje y habilidades motoras limitadas.

WCAG 2.2: Qué hay de nuevo y por qué importa

Las nueve adiciones se agrupan en tres niveles de conformidad: A, AA y AAA, que indican hasta dónde debe llegar un sitio para conformar, siendo la mayoría de los objetivos legales y organizacionales el Nivel AA. El desglose a continuación cubre cada nuevo criterio: qué requiere, a quién ayuda y por qué importa en la práctica.

WCAG 2.4.11: El foco no está oscurecido (Mínimo) (Nivel AA)

WCAG 2.4.11(opens in a new tab) requiere que, cuando un elemento recibe el foco del teclado, al menos una parte permanezca visible y no esté completamente oculta por otros contenidos, como encabezados fijos o ventanas emergentes. Para los usuarios videntes que dependen del teclado para navegar por sitios web, saber dónde está el foco es fundamental para navegar por las páginas. Sin embargo, los elementos enfocados pueden quedar ocasionalmente ocultos por otros elementos web.

Agregar un elemento de foco visible puede ayudar a mejorar el enfoque y la navegación para usuarios con discapacidades cognitivas o visuales; sin embargo, cuanto más visible sea el indicador de foco, más fácil será para los usuarios seguirlo mientras navegan por las páginas web.

WCAG 2.4.12: El foco no está oscurecido (Mejorado) (Nivel AAA)

WCAG 2.4.12(opens in a new tab) va más allá que 2.4.11, exigiendo que un elemento enfocado por teclado sea completamente visible, sin que ninguna parte esté oculta por otro contenido en la página. Esto garantiza que el elemento enfocado sea completamente visible para el usuario, lo que mejora la navegación para quienes tienen visión limitada o baja. Los usuarios con limitaciones de atención (como limitaciones de memoria a corto plazo) también pueden concentrarse más fácilmente cuando todo el foco es visible.

WCAG 2.4.13: Apariencia del foco (Nivel AAA)

WCAG 2.4.13(opens in a new tab) requiere que los indicadores de foco sean lo suficientemente grandes y tengan al menos una relación de contraste de color de 3:1 entre los estados enfocado y no enfocado, para que los usuarios puedan ver claramente qué elemento está enfocado. Por ejemplo, cuando un enlace recibe el foco, aparece un contorno a su alrededor. El color de este contorno debe tener suficiente contraste con el color de fondo de la página.

Asegurar que los indicadores de foco tengan suficiente contraste de color garantiza que los usuarios puedan ver fácilmente pequeños cambios en la apariencia visual. Esto es especialmente beneficioso para personas mayores o usuarios de teclado, ya que pueden rastrear fácilmente su posición en una página mientras navegan.

WCAG 2.5.7: Movimientos de arrastre (Nivel AA)

WCAG 2.5.7(opens in a new tab) requiere que cualquier acción realizada mediante arrastre también tenga una alternativa de un solo puntero, como un toque o un botón en pantalla, a menos que el arrastre sea esencial. Por ejemplo, un sitio web podría permitir el uso del teclado con las teclas de flecha arriba/abajo/izquierda/derecha o proporcionar botones en pantalla que un usuario pueda presionar para mover un control deslizante o reordenar una lista. Esto garantiza que los usuarios que tienen dificultades o no pueden realizar movimientos de arrastre aún puedan operar dentro de la interfaz de arrastrar y soltar.

WCAG 2.5.8: Tamaño del objetivo (Mínimo) (Nivel AA)

WCAG 2.5.8(opens in a new tab) requiere que los objetivos clicables tengan al menos 24x24 píxeles CSS de tamaño, o suficiente espacio a su alrededor para evitar activaciones accidentales. Cuando los botones y otros elementos clicables son pequeños, es difícil para personas con temblores en las manos y otras limitaciones motoras finas activarlos sin activar accidentalmente otro elemento.

Esta nueva capacidad permite que las personas con limitaciones motoras finas hagan clic en los botones fácilmente. También mejora la experiencia móvil al proporcionar suficiente espacio para seleccionar botones pequeños.

WCAG 3.2.6: Ayuda consistente (Nivel A)

WCAG 3.2.6(opens in a new tab) requiere que los mecanismos de ayuda, como los datos de contacto o una opción de chat, aparezcan en el mismo orden relativo en cada página donde se ofrezcan. Por ejemplo, si un sitio web tiene una opción de ‘Chat’, debe aparecer en la esquina inferior derecha de cada página. O los datos de contacto, incluyendo un número de teléfono, horario de atención o dirección de correo electrónico, deben figurar en el pie de página de cada página.

Al listar la información útil de forma consistente en el mismo lugar, las personas que pueden tener dificultades para encontrar ayuda o recordar dónde está la información pueden encontrarla más fácilmente.

WCAG 3.3.7: Entrada redundante (Nivel A)

WCAG 3.3.7(opens in a new tab) requiere que la información que un usuario ya ha ingresado en un proceso se autocomplete o esté disponible para seleccionar en lugar de volver a solicitarla. Esto evita que los usuarios tengan que ingresar la misma información repetidamente, reduce la probabilidad de errores y disminuye la necesidad de escribir texto.

WCAG 3.3.8: Autenticación accesible (Mínimo) (Nivel AA)

WCAG 3.3.8(opens in a new tab) requiere que los inicios de sesión no dependan de una prueba de función cognitiva(opens in a new tab), como memorizar una contraseña o resolver un acertijo, a menos que haya disponible un método alternativo o asistencia. Esto simplifica el proceso de autenticación para personas con discapacidades cognitivas y les permite autenticarse de formas que se adapten a sus necesidades individuales. Un mecanismo que puede ayudar con esto es el uso de gestores de contraseñas. Estos pueden ayudar a reducir la necesidad de memoria y la carga de volver a escribir información.

WCAG 3.3.9: Autenticación accesible (Mejorada) (Nivel AAA)

WCAG 3.3.9(opens in a new tab) aplica la misma regla que 3.3.8 pero de forma más estricta, prohibiendo el reconocimiento de objetos o el contenido proporcionado por el usuario (como una imagen subida) como métodos de autenticación. Esto garantiza que los usuarios con problemas cognitivos relacionados con la memoria, la lectura (dislexia, por ejemplo), los números o las limitaciones de procesamiento perceptivo puedan iniciar sesión o autenticarse fácilmente.

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

WCAG 2.2 eliminó un criterio, 4.1.1 Análisis sintáctico, marcando la primera vez que se retira un criterio de éxito de las pautas. El criterio originalmente requería un marcado HTML limpio y bien formado, pero el W3C determinó que era obsoleto porque los navegadores modernos y las tecnologías de asistencia ahora manejan los errores de marcado que cubría sin problema.

Eliminarlo no significa que el HTML válido haya dejado de importar; un marcado bien estructurado sigue beneficiando la accesibilidad y sigue siendo una buena práctica. El efecto práctico es limitado: si tus pruebas automatizadas antes marcaban errores de análisis sintáctico como un fallo de WCAG, esos fallos específicos ya no cuentan para la conformidad con 2.2.

WCAG 2.2 vs. WCAG 2.1: Qué cambió realmente

WCAG 2.2 es un superconjunto de WCAG 2.1: mantiene todos los criterios de éxito de 2.1 excepto el retirado 4.1.1 Análisis sintáctico, y añade nueve nuevos. La consecuencia práctica es lo importante: cumplir con WCAG 2.2 también significa que cumples con 2.1, así que no hay desventaja en apuntar a la versión más reciente. Si ya cumples con WCAG 2.1 Nivel AA, la brecha real son solo los seis nuevos criterios de Nivel A y AA; las tres adiciones de Nivel AAA son opcionales. En resumen, pasar de 2.1 a 2.2 no es una reconstrucción — es una lista corta y definida de tareas.

Lista de verificación WCAG 2.2 (Nivel AA)

Si ya cumples con WCAG 2.1 Nivel AA, estos son los seis nuevos criterios que debes revisar para alcanzar WCAG 2.2 Nivel AA. Las tres adiciones de Nivel AAA (2.4.12, 2.4.13 y 3.3.9) son opcionales.

• El foco del teclado permanece visible (2.4.11): Recorre cada página con la tecla Tab y confirma que el elemento enfocado nunca está completamente oculto detrás de encabezados fijos, banners de cookies o ventanas emergentes.

• El arrastre tiene una alternativa (2.5.7): Para cualquier acción de arrastrar y soltar (deslizadores, reordenar, controles de mapa), proporciona una opción de un solo puntero, como toques o botones en pantalla.

• Los objetivos son lo suficientemente grandes (2.5.8): Asegúrate de que los elementos clicables tengan al menos 24×24 píxeles CSS, o suficiente espacio para que los objetivos adyacentes no sean fáciles de activar por accidente.

• La ayuda es consistente (3.2.6): Coloca los mecanismos de ayuda (por ejemplo, enlaces de contacto, chat, información de soporte, etc.) en la misma ubicación relativa en cada página que los ofrezca.

• No pidas la misma información dos veces (3.3.7): Autocompleta o permite que los usuarios reutilicen la información que ya ingresaron antes en el mismo proceso, a menos que sea esencial volver a ingresarla.

• Los inicios de sesión no dependen de la memoria ni de acertijos (3.3.8): Ofrece una alternativa accesible siempre que la autenticación requiera una prueba de función cognitiva, como recordar una contraseña o resolver un CAPTCHA.

Varios de estos, la visibilidad del foco, la ayuda consistente y la autenticación accesible en particular, no pueden ser verificados completamente por herramientas automatizadas. Un escaneo de accesibilidad gratuito es una forma rápida de saber cómo está tu sitio hoy.

Cómo AudioEye simplifica la conformidad con WCAG 2.2

WCAG 2.2 perfeccionó la accesibilidad en lugar de reinventarla, añadiendo nueve criterios enfocados que cierran brechas reales para usuarios que navegan con teclado, gestionan inicios de sesión o usan dispositivos móviles. El reto para la mayoría de las organizaciones es verificar que su sitio realmente cumple y mantenerlo así a medida que los estándares evolucionan.

Ahí es donde el enfoque correcto importa: varios criterios de WCAG 2.2, incluyendo la visibilidad del foco, la ayuda consistente y la autenticación accesible, no pueden confirmarse solo con automatización.

La plataforma AudioEye está diseñada exactamente para ese propósito. AudioEye ayuda a las organizaciones a cumplir con WCAG 2.2 Nivel AA combinando correcciones automatizadas a escala con expertos certificados y pruebas con la comunidad de personas con discapacidad para verificar los criterios que la automatización no puede confirmar por sí sola. Y con monitoreo continuo, tu sitio se revisa a medida que cambia y los problemas se corrigen más rápido, manteniéndose al ritmo de WCAG a medida que evoluciona y no solo donde está hoy.

¿Listo para ver cómo está tu sitio frente a WCAG 2.2? Usa el comprobador gratuito de accesibilidad web para averiguarlo. O agenda una demostración, y te mostraremos cómo AudioEye te ayuda a cumplir con los estándares de accesibilidad y mantenerlos en el tiempo.