Requisitos de WCAG 2.2 para aplicaciones web: lo que los desarrolladores implementan de verdad, 2026

WCAG 2.2 en un párrafo

WCAG 2.2 añade nueve criterios de conformidad a WCAG 2.1, y seis de ellos son de nivel A o AA, que es el objetivo habitual de los equipos de aplicaciones web. Esos seis cubren la visibilidad del foco del teclado, las alternativas al arrastre, un tamaño mínimo de objetivo de 24 por 24 píxeles CSS, un inicio de sesión compatible con gestores de contraseñas, no pedir al usuario que reescriba datos y la ubicación coherente de la ayuda. El estándar se publicó el 5 de octubre de 2023 y se actualizó el 12 de diciembre de 2024. Esta es una guía de ingeniería, no asesoramiento jurídico: comprueba qué versión y qué nivel exigen tu contrato o la normativa local.

Qué cambió en WCAG 2.2

La página "Novedades de WCAG 2.2" del W3C enumera nueve criterios nuevos. Dos son de nivel A, cuatro de nivel AA y tres de nivel AAA.

Un criterio desapareció. 4.1.1 Procesamiento (Parsing) aparece como "Obsolete and removed" en el texto de WCAG 2.2. Quienes deban cumplir WCAG 2.0 o 2.1 por normativa propia pueden seguir necesitando probarlo y reportarlo.

WCAG 2.2 también es compatible hacia atrás. El W3C afirma que el contenido que cumple WCAG 2.2 también cumple WCAG 2.1 y WCAG 2.0. Adoptar la versión 2.2 no obliga a rehacer el trabajo hecho para 2.1.

Foco no oculto y foco del teclado en el shell de la aplicación

El criterio 2.4.11 (AA) dice: "Cuando un componente de la interfaz recibe el foco del teclado, el componente no queda totalmente oculto por contenido creado por el autor." La palabra clave es "totalmente": si hay solapamiento parcial, se cumple el nivel mínimo; si el solapamiento es total, no.

Las aplicaciones web fallan aquí más que los sitios de contenido, porque su estructura apila capas fijas. Causas habituales:

• Cabeceras fijas y barras de herramientas ancladas que tapan un campo al avanzar con el tabulador por un formulario largo.
• Avisos de cookies y widgets de chat fijados en la parte inferior de la ventana.
• Cajones y paneles laterales que quedan por encima del elemento que acaba de recibir el foco.

La solución habitual está en CSS: define scroll-padding-top y scroll-padding-bottom en el contenedor con desplazamiento con al menos la altura de tus capas fijas, de modo que el navegador desplace los elementos enfocados fuera de ellas. Después, prueba tabulando por todas las pantallas con todo el marco visible. La diferencia entre un sitio de marketing y un panel SaaS importa aquí: un panel tiene muchas más capas persistentes que una página de aterrizaje.

Los dos criterios AAA van más lejos. El 2.4.12 quiere el elemento enfocado totalmente visible, y el 2.4.13 fija reglas de tamaño y contraste para el indicador de foco. Puedes adoptarlos antes de tiempo, aunque no estés obligado a ello.

Tamaño del objetivo y arrastre

2.5.8 Tamaño del objetivo (mínimo)

La regla: "El tamaño del objetivo para entradas de puntero es de al menos 24 por 24 píxeles CSS, excepto cuando" se aplica una de cinco excepciones. La página "Understanding" del W3C las describe:

• Espaciado: un objetivo pequeño cumple si un círculo de 24 píxeles CSS de diámetro, centrado en él, no se cruza con otro objetivo ni con el círculo de otro objetivo pequeño.
• Equivalente: la misma función está disponible mediante otro control de la misma página que cumple la regla de tamaño.
• En línea: el objetivo está dentro de una frase, o su tamaño queda limitado por la altura de línea del texto que lo rodea.
• Control del agente de usuario: el navegador fija el tamaño y el autor no lo ha modificado.
• Esencial: una presentación concreta es esencial, como los marcadores de un mapa en ubicaciones exactas, o es obligatoria por ley.

La intención es que los objetivos sean más fáciles de pulsar sin tocar al vecino. Eso ayuda a personas con temblores, destreza limitada o dispositivos de entrada especializados, y mejora el uso de pantallas táctiles para todos. En la práctica, revisa los botones de icono en filas de tablas, los botones de cierre en chips y avisos, los controles de paginación y las barras de herramientas densas. Un icono de 16 píxeles puede cumplir si tiene un relleno que lleva el área pulsable a 24 píxeles, o si hay espacio suficiente a su alrededor.

2.5.7 Movimientos de arrastre

El criterio 2.5.7 (AA) exige que "toda la funcionalidad que usa un movimiento de arrastre pueda lograrse con un solo puntero sin arrastrar", salvo que el arrastre sea esencial o lo determine el navegador. Las listas ordenables, los tableros kanban, los controles deslizantes y la reordenación de archivos entran en esta categoría.

La solución estándar es un segundo camino al mismo resultado: botones de subir y bajar en los elementos de una lista, un menú "Mover a" en las tarjetas o un clic para fijar el valor en la pista de un control deslizante. Acuerda estas alternativas pronto, en el traspaso de diseño, para que estén dibujadas y no se improvisen en el código.

Autenticación, entrada redundante y ayuda coherente

3.3.8 Autenticación accesible (mínimo)

El criterio 3.3.8 (AA) dice que no se requiere una prueba de función cognitiva, "como recordar una contraseña o resolver un puzle", en ningún paso de un proceso de autenticación, salvo que ese paso ofrezca al menos una de estas opciones:

• Otro método de autenticación que no dependa de una prueba de función cognitiva.
• Un mecanismo que ayude al usuario a completar la prueba.
• Una prueba que consista solo en reconocer objetos.
• Una prueba que consista solo en identificar contenido no textual que el usuario aportó al sitio.

Para la mayoría de las aplicaciones se reduce a unas pocas decisiones. No bloquees el pegado en los campos de contraseña y mantén correctos los atributos autocomplete, para que funcionen los gestores de contraseñas. Ofrece una passkey, un enlace por correo u otra alternativa siempre que puedas. Si usas un CAPTCHA que pide resolver un puzle, ofrece un método que lo evite.

3.3.7 Entrada redundante

El criterio 3.3.7 (A) dice que la información introducida antes por el usuario o aportada a él, y que se vuelve a pedir en el mismo proceso, debe rellenarse automáticamente o poder seleccionarse. Las excepciones cubren los casos en que volver a introducirla es esencial, en que es necesario para proteger la seguridad del contenido y en que la información anterior ya no es válida. Los casos típicos son los flujos de pago y de alta: una dirección de facturación que copia la de envío, o un paso de confirmación que reutiliza respuestas anteriores. Confirmar una contraseña nueva es una excepción de seguridad habitual.

3.2.6 Ayuda coherente

El criterio 3.2.6 (A) se aplica cuando los mecanismos de ayuda se repiten en un conjunto de páginas: datos de contacto humano, un mecanismo de contacto humano, una opción de autoayuda o un mecanismo de contacto totalmente automatizado. Deben aparecer en el mismo orden relativo respecto al resto del contenido de la página, salvo que el usuario lo cambie. Coloca tu enlace de ayuda, el lanzador del chat o el correo de soporte en un único componente de diseño compartido, para que no se desvíen de una pantalla a otra.

Cómo probar y qué nivel fijar como objetivo

Apunta al nivel AA. Incluye todos los criterios A y AA de versiones anteriores más los seis nuevos descritos arriba. Trata los tres criterios AAA como mejoras opcionales.

Un orden de trabajo práctico:

1. Recorre con el tabulador cada flujo clave con todas las capas fijas visibles y comprueba que ningún elemento enfocado desaparece (2.4.11).
2. Revisa los elementos interactivos y compara su área pulsable con la regla de 24 píxeles (2.5.8).
3. Haz una lista de cada interacción de arrastre y entrega una alternativa con un solo puntero (2.5.7).
4. Revisa el inicio de sesión, el registro y el pago en busca de pegado bloqueado, puzles obligatorios y campos repetidos (3.3.8, 3.3.7).
5. Confirma la ubicación de la ayuda en el diseño compartido (3.2.6).

Las herramientas automáticas detectan solo una parte, así que conserva la pasada manual con el teclado. Añade a tu pipeline las comprobaciones que se puedan automatizar, igual que haces con el rendimiento al aplicar comprobaciones en CI. Si quieres una segunda opinión sobre el desarrollo de un producto, habla con Kallos Labs.

Preguntas frecuentes

¿WCAG 2.2 sustituye a WCAG 2.1?

No. El W3C indica que el contenido que cumple WCAG 2.2 también cumple 2.1 y 2.0, y que la versión 2.2 añade criterios sin cambiar los existentes. Ni 2.1 ni 2.2 dejan obsoleta a su predecesora, aunque el W3C recomienda usar la versión más reciente.

¿Sigo teniendo que probar 4.1.1 Procesamiento?

WCAG 2.2 marca 4.1.1 como obsoleto y eliminado. Si una política o un contrato te fija a WCAG 2.0 o 2.1, es posible que aún debas probarlo y reportarlo.

¿Cuál es el tamaño mínimo de objetivo en WCAG 2.2?

El criterio 2.5.8 (AA) pide objetivos de puntero de al menos 24 por 24 píxeles CSS, salvo que se aplique la excepción de espaciado, equivalente, en línea, control del agente de usuario o esencial.

¿Un formulario de acceso puede seguir pidiendo una contraseña?

Sí, si cumple 3.3.8: un paso que dependa de recordar una contraseña está permitido cuando ofrece un método alternativo, un mecanismo de ayuda como el pegado o un gestor de contraseñas, el reconocimiento de objetos o contenido personal aportado por el usuario.