Novedades de las WCAG 2.2: los 9 criterios nuevos, sin jerga

Una persona recorre su proceso de compra con el teclado. El foco llega al botón «Pagar ahora», pero encima hay un banner de cookies fijo y no ve dónde está. Con las WCAG 2.1, esa página aún podía aprobar. Con las WCAG 2.2, no.

Ese es el tipo de laguna que cierra la actualización 2.2. A continuación, cada nuevo criterio de conformidad recibe el mismo tratamiento: qué dice, a quién ayuda, una prueba rápida y la solución habitual. Si quiere ver los cuatro principios y los niveles en una sola página, consulte nuestra referencia de las WCAG 2.2.

¿Qué son las WCAG 2.2?

Las WCAG 2.2 son la versión actual de las Pautas de Accesibilidad para el Contenido Web, la norma del W3C a la que remiten la mayoría de las leyes y contratos de accesibilidad. Se convirtieron en Recomendación del W3C el 5 de octubre de 2023 (se abre en una pestaña nueva), se actualizaron el 12 de diciembre de 2024 (se abre en una pestaña nueva) y en octubre de 2025 se aprobaron como norma ISO/IEC 40500:2025 (se abre en una pestaña nueva).

Las WCAG se componen de enunciados comprobables llamados criterios de conformidad, cada uno con un nivel: A (el mínimo), AA (lo que suelen pedir las leyes) o AAA (el más exigente). «Necesitamos las WCAG 2.2 AA» significa cumplir todos los criterios A y AA de la versión 2.2. La especificación indica que las 2.2 «se basan en las WCAG 2.1 y son compatibles con ellas», así que amplían las 2.1 en lugar de sustituirlas.

¿Qué ha cambiado de las WCAG 2.1 a las 2.2?

Las WCAG 2.2 añaden nueve criterios de conformidad y eliminan uno. Seis de los nuevos son de nivel A o AA, así que cuentan para el objetivo habitual AA: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 y 3.3.8. Los otros tres son AAA. El criterio eliminado es el 4.1.1 Procesamiento, que el W3C considera ahora obsoleto.

El 4.1.1 Procesamiento comprobaba errores de marcado como los ID duplicados. Las preguntas frecuentes sobre WCAG 2 (se abre en una pestaña nueva) explican que esos problemas entran ahora en otros criterios, como el 4.1.2 Nombre, función, valor. Un detalle: si un contrato sigue exigiendo las WCAG 2.0 o 2.1, es posible que «tenga que seguir evaluando e informando sobre el 4.1.1».

Foco no oculto y apariencia del foco: ¿ven los usuarios de teclado dónde están?

Estos criterios mantienen visible el elemento que tiene el foco del teclado. En el nivel AA (2.4.11), un enlace o botón con el foco no puede quedar totalmente oculto por contenido que usted haya añadido, como una cabecera fija, un banner de cookies o una burbuja de chat. En AAA, nada puede tapar ninguna parte (2.4.12), y el contorno del foco debe ser grande y tener un contraste claro (2.4.13).

• A quién ayuda: a personas videntes que usan el teclado en lugar del ratón, a menudo por una discapacidad motora. Si no ven el foco, tienen que adivinar dónde están.
• Prueba rápida: abra una página larga con el banner de cookies, la cabecera fija y el widget de chat a la vista, y pulse Tab varias veces. Si el foco desaparece por completo detrás de algo, es un fallo del 2.4.11.
• Solución habitual: añada en el CSS un scroll-padding igual a la altura de la cabecera o el pie fijos, para que el navegador desplace los elementos con foco hasta dejarlos a la vista. El W3C lo recoge como técnica suficiente (se abre en una pestaña nueva). Un banner también puede aprobar si es modal y hay que cerrarlo primero.

La apariencia del foco (2.4.13) pide un indicador al menos tan grande como un contorno de 2 píxeles CSS de grosor alrededor del componente, con un cambio de contraste de al menos 3:1 entre el estado con foco y sin él. Es AAA, pero un contorno continuo de 2 píxeles en un color intenso suele bastar. Nuestra guía sobre el contraste de color explica cómo medir 3:1.

Movimientos de arrastre y tamaño del objetivo: ¿se puede usar su web sin apuntar con precisión?

Estos dos criterios de nivel AA ayudan a quienes tienen dificultades para controlar el puntero con precisión. El 2.5.7 dice que todo lo que se puede hacer arrastrando también debe funcionar con clics o toques sueltos. El 2.5.8 dice que los objetivos deben medir al menos 24 por 24 píxeles CSS, o estar separados de forma que un círculo de 24 píxeles centrado en cada uno no toque otro objetivo.

2.5.7 Movimientos de arrastre

Piense en el control deslizante de rango de precios de los filtros de una tienda o en una lista de deseos que se reordena arrastrando. Para alguien con temblor, o que usa un puntero de cabeza, pulsar, mantener, mover y soltar puede resultar muy difícil.

Prueba rápida: complete cada tarea de arrastre solo con clics o toques. Solución habitual: permita hacer clic en cualquier punto de la barra del control deslizante, añada al lado casillas de «mínimo» y «máximo», o ponga botones de «Subir» y «Bajar» en las listas ordenables. No basta con que funcione con teclado: el documento explicativo del W3C (se abre en una pestaña nueva) aclara que la equivalencia por teclado «no cumple automáticamente este criterio de conformidad».

2.5.8 Tamaño del objetivo (mínimo)

Los fallos típicos son las pequeñas «×» de las ventanas emergentes, los números de página muy juntos, las valoraciones con estrellas y las filas de iconos sociales. Tocar el botón equivocado irrita a cualquiera y es una barrera real para quien tiene poca destreza manual.

• Excepciones: enlaces dentro de una frase, objetivos que tienen en la misma página un control equivalente del tamaño exigido, controles cuyo tamaño fija el navegador y que usted no ha modificado, y casos en que un tamaño concreto es esencial o lo exige la ley.
• Prueba rápida: en un móvil, pruebe cada icono y botón pequeño; para medir uno, inspecciónelo con las herramientas para desarrolladores del navegador.
• Solución habitual: añada relleno (padding). El área en la que se puede hacer clic crece aunque el icono se vea igual. Y considere los 24 píxeles un mínimo: el antiguo criterio AAA 2.5.5 pide 44 por 44.

Ayuda consistente y entrada redundante: ¿obliga a la gente a buscar o a repetirse?

Los dos son de nivel A. El 3.2.6 Ayuda consistente dice que, si una ayuda como los datos de contacto, un chat o un enlace a preguntas frecuentes aparece en varias páginas, debe estar siempre en el mismo orden respecto al resto de la página. El 3.3.7 Entrada redundante dice que nadie debería tener que volver a escribir datos que ya ha dado en el mismo proceso.

La ayuda consistente no le obliga a ofrecer ayuda. Solo dice que, si el teléfono está en la cabecera de las fichas de producto, no debería pasar al pie de página en el proceso de pago, justo donde más falta hace. Quienes más se benefician son las personas con problemas de memoria o de atención. La solución suele ser una plantilla compartida, no colocar la ayuda página a página.

La entrada redundante se centra en los formularios de varios pasos. Un formulario de reserva que pide el correo electrónico en el paso 1 y otra vez en el paso 3 no cumple, y tampoco un proceso de pago que obliga a volver a escribir una dirección de facturación idéntica. Rellene el campo automáticamente o deje que se seleccione, por ejemplo, con una casilla «La dirección de facturación es la misma que la de envío». Las excepciones: que repetir el dato sea esencial, que lo exija la seguridad o que la información anterior ya no sea válida.

Autenticación accesible: ¿se puede iniciar sesión sin un examen de memoria?

El criterio de conformidad 3.3.8 (nivel AA) dice que ningún paso del inicio de sesión puede depender de una prueba de función cognitiva, como recordar una contraseña, escribir caracteres distorsionados o resolver un rompecabezas, salvo que ofrezca una alternativa o algo que ayude. En la práctica: deje que los gestores de contraseñas rellenen los campos, permita pegar y ofrezca un método que no dependa de la memoria.

Las WCAG definen la prueba de función cognitiva como «una tarea que requiere que el usuario recuerde, manipule o transcriba información». Introducir su nombre, correo electrónico o teléfono no cuenta, porque son datos personales y siempre los mismos. Un paso de inicio de sesión cumple en AA si ofrece al menos una de estas opciones:

• Una alternativa sin prueba cognitiva, como una llave de acceso (passkey) o un enlace por correo electrónico.
• Un mecanismo de ayuda, como la compatibilidad con gestores de contraseñas o poder copiar y pegar, para no tener que volver a teclear un código de un solo uso.
• Reconocimiento de objetos, por ejemplo, «seleccione las imágenes con una bicicleta».
• Contenido personal, como identificar una imagen que subió usted mismo.

La versión AAA, el 3.3.9, elimina las dos últimas opciones, de modo que un CAPTCHA de imágenes puede aprobar en AA pero no en AAA. Fallos típicos: campos de contraseña que impiden pegar o usar un gestor de contraseñas, casillas de código de un solo uso que se rompen al pegar y un CAPTCHA de texto sin alternativa. Las personas con dislexia o problemas de memoria son las más beneficiadas, pero cualquiera que se haya quedado fuera de su cuenta al final de un día largo reconocerá el problema.

¿Exige la ley las WCAG 2.2?

Depende de dónde esté y de quién sea. Las leyes casi nunca citan directamente una versión de las WCAG, y varias siguen remitiendo a las WCAG 2.1 AA. Como las WCAG 2.2 son compatibles con las anteriores, cumplir las 2.2 AA supone cumplir las 2.1 AA, salvo por el 4.1.1 eliminado. Apuntar a las 2.2 cubre ambas. Si un contrato indica una versión, siga el contrato.

• Unión Europea: con la Ley Europea de Accesibilidad, se presume la conformidad cuando se cumple la norma armonizada EN 301 549. Según AccessibleEU (se abre en una pestaña nueva), la versión 4.1.1, publicada en septiembre de 2026, adopta las WCAG 2.2, pero aún no es la referencia legal; hasta que se cite en el Diario Oficial, se aplica la v3.2.1 (basada en las WCAG 2.1 AA). Nuestra guía sobre la Ley Europea de Accesibilidad explica a quién se aplica.
• Reino Unido: la guía del Gobierno (se abre en una pestaña nueva) establece que las webs y apps del sector público deben cumplir las WCAG 2.2 AA. Esa guía se refiere a los organismos públicos, no a las empresas privadas.
• Estados Unidos: la norma del Departamento de Justicia para los gobiernos estatales y locales usa las WCAG 2.1 AA, con plazos de cumplimiento que se aplazaron en abril de 2026 (se abre en una pestaña nueva) al 26 de abril de 2027 y al 26 de abril de 2028. Para las empresas privadas, la guía de 2022 (se abre en una pestaña nueva) del Departamento dice que la ADA se aplica a sus webs, pero no fija ninguna norma técnica concreta.

¿Y las WCAG 3?

Las WCAG 3 son un borrador, así que nadie puede cumplirlas todavía. El W3C publicó borradores actualizados en septiembre de 2026 y prevé que no sean una norma terminada «hasta dentro de unos años». Las WCAG 2 no quedarán obsoletas hasta varios años después, así que la versión con la que trabajar hoy es la 2.2.

¿Cómo comprobar los criterios nuevos en 15 minutos?

La mayoría de los fallos de los seis criterios A y AA se detectan en unos 15 minutos con un teclado, un móvil y su propia página de inicio de sesión. No sustituye a una auditoría completa ni a las pruebas con personas con discapacidad, pero le dice por dónde empezar y da a un desarrollador una lista concreta con la que trabajar.

1. Recorra con Tab su página de inicio, una ficha de producto y el proceso de pago con todos los banners visibles. ¿Ve siempre el foco? (2.4.11)
2. Complete cada control deslizante o tarea de arrastrar y soltar solo con clics o toques. (2.5.7)
3. En un móvil, pruebe cada botón de cierre, número de página e icono pequeño. (2.5.8)
4. Compare dónde aparecen la ayuda y los datos de contacto en tres tipos de página. (3.2.6)
5. Haga una compra o una reserva y anote cualquier pregunta que responda dos veces. (3.3.7)
6. Inicie sesión con un gestor de contraseñas y después pegue una contraseña y un código de un solo uso. ¿Tiene alternativa algún CAPTCHA? (3.3.8)

Para el resto de las WCAG, nuestra guía sobre cómo comprobar la accesibilidad de su web repasa herramientas gratuitas y comprobaciones manuales, y nuestra lista de comprobación de accesibilidad web convierte los fallos más comunes en una lista de tareas. Lo que aún no pueda corregir debe figurar en su declaración de accesibilidad.

Una nota sobre los widgets, incluido el nuestro: ninguno de estos criterios se puede cumplir desde un panel para visitantes. Un cursor grande facilita apuntar a objetivos pequeños, pero no hace que midan 24 píxeles, y resaltar el foco no aparta un banner fijo. Todos los criterios nuevos tratan de cómo están construidas sus páginas, así que la solución está en sus plantillas y en su código.