WCAG 2.2 nivel AA: qué cambió y cómo verificarlo

Las WCAG 2.2 añadieron nueve criterios de conformidad a las WCAG 2.1 y eliminaron uno, el 4.1.1 (Procesamiento). De los nueve, seis cuentan para quien necesita el nivel AA: cuatro son de nivel AA (2.4.11, 2.5.7, 2.5.8 y 3.3.8) y dos son de nivel A (3.2.6 y 3.3.7), que el AA también exige. Los otros tres son de nivel AAA. Todo lo demás de la 2.1 sigue igual, así que un sitio que ya cumplía la 2.1 AA tiene que probar esos seis puntos y puede dejar de probar el 4.1.1.

El texto trata de las WCAG 2.2 en la edición del 12 de diciembre de 2024, la vigente en octubre de 2026, y de su relación con la ABNT NBR 17225:2025, la norma técnica de accesibilidad web de Brasil.

Qué son las WCAG 2.2

Las Pautas de Accesibilidad para el Contenido Web (WCAG, por su sigla en inglés) son la recomendación del W3C, el consorcio que mantiene los estándares de la web, sobre cómo hacer que las páginas sean usables por personas con discapacidad. Cada exigencia comprobable se llama criterio de conformidad y tiene un número (por ejemplo, 1.4.3), un nombre y un nivel: A, AA o AAA.

La versión 2.2 se convirtió en Recomendación del W3C el 5 de octubre de 2023, según la página What's New in WCAG 2.2. La edición actual es del 12 de diciembre de 2024. El W3C afirma que el contenido que cumple la 2.2 también cumple la 2.0 y la 2.1; las versiones anteriores siguen siendo válidas, pero la recomendación es adoptar la 2.2 (WCAG 2.2, sección de introducción). Las WCAG 3.0 todavía son un borrador de trabajo y no sustituyen a la 2.2.

Niveles de conformidad: A, AA y AAA

Los niveles son acumulativos. Para declarar un nivel, la página tiene que cumplir todos los criterios de ese nivel y de los inferiores (WCAG 2.2, 5.2.1).

Además del nivel, las WCAG tienen otros cuatro requisitos de conformidad (WCAG 2.2, 5.2):

• La conformidad se aplica a la página entera. No se puede excluir una parte, y cada variación responsiva de la página (móvil, tableta, escritorio) también tiene que cumplir.

• En un proceso de varios pasos, como un checkout, todos los pasos tienen que cumplir el nivel. Si uno falla, ninguna página del proceso puede declarar conformidad.

• Solo cuentan las formas de usar la tecnología que funcionan con los recursos de accesibilidad (el W3C las llama "accessibility supported").

• Lo que no cumple no puede impedir el uso del resto de la página. Es el requisito de no interferencia.

Los nueve criterios nuevos de las WCAG 2.2

Los nombres en español que siguen son traducciones de este texto; la NBR 17225 usa nombres propios, que se enumeran más adelante. Fuente: WCAG 2.2, New Features y el texto de cada criterio.

Para no cambiar la numeración antigua, los criterios nuevos se colocaron al final de cada pauta. Por eso la posición de un criterio dentro de la pauta no indica su nivel; el nivel aparece en cada criterio.

Lo que se eliminó: 4.1.1 Procesamiento

El 4.1.1 pedía HTML bien formado: etiquetas completas, anidamiento correcto, ningún atributo duplicado e ID únicos. Existía porque las tecnologías de apoyo, como los lectores de pantalla, leían el HTML directamente. Según el W3C, eso dejó de ocurrir, y los problemas que cubría ya no existen o ya los cubren otros criterios (WCAG 2.2, 4.1.1). En las propias WCAG 2.1, una nota añadida después indica que el criterio se considere siempre cumplido en contenido HTML o XML (WCAG 2.1, 4.1.1).

Dos salvedades. Quien está obligado por contrato o por política a cumplir las WCAG 2.0 o 2.1 puede tener que seguir probando e informando el 4.1.1, como advierte el W3C. Y el documento Understanding Parsing dice que muchos problemas que fallarían en el 4.1.1 ahora fallan en el 1.3.1 (Información y relaciones) o en el 4.1.2 (Nombre, función, valor). Un ID repetido que hace que un label apunte al campo equivocado es el tipo de error que sigue contando.

Cómo verificar cada criterio nuevo de los niveles A y AA

Las herramientas automáticas ayudan, pero el W3C es directo: no determinan si un sitio es accesible, solo ayudan en esa evaluación, y parte de las verificaciones exige juicio humano (Selecting Web Accessibility Evaluation Tools). El mismo límite vale para los widgets instalados encima del sitio, tema de ¿un overlay de accesibilidad cumple la ley?. Los seis criterios siguientes dependen mucho de la prueba manual.

2.4.11 Foco no oculto (mínimo)

Falla cuando una cabecera fija, un pie de página fijo, un banner de cookies o una ventana de chat tapa por completo el elemento que acaba de recibir el foco. El W3C cita el banner de cookies como fallo cuando oculta totalmente el elemento con el foco; un modal bien construido pasa, porque el usuario tiene que cerrarlo antes de continuar (Understanding 2.4.11).

1. Abre la página como un visitante nuevo, con el banner de cookies y el chat todavía en pantalla.

2. Navega solo con Tab, y Mayús+Tab para volver, del principio al final de la página.

3. En cada parada, comprueba que el elemento con el foco se vea al menos en parte. Oculto por completo es un fallo. Parcialmente cubierto cumple el AA; el AAA (2.4.12) pide que nada quede cubierto.

4. Repite con el ancho de un móvil, donde las cabeceras fijas ocupan más espacio.

Una corrección habitual es la propiedad CSS scroll-padding, que reserva espacio para la cabecera o el pie fijos y hace que el desplazamiento se detenga con el elemento visible. Es la técnica C43 del W3C.

2.5.7 Movimientos de arrastre

Afecta a listas reordenables, controles deslizantes, mapas, tableros kanban y carruseles que solo responden al arrastre. Que funcione con teclado no lo resuelve: el W3C dice que la equivalencia por teclado no cumple este criterio por sí sola, porque quien usa una pantalla táctil puede no tener teclado (Understanding 2.5.7).

1. Haz una lista de los componentes que responden al arrastre.

2. En cada uno, intenta hacer la misma acción solo con clics o toques simples, sin mantener pulsado y mover.

3. Si no hay forma, es un fallo. Alternativas que el W3C acepta: botones de subir y bajar, clic en cualquier punto del recorrido del control deslizante, botones de dirección en el mapa, un campo para escribir el valor.

2.5.8 Tamaño del objetivo (mínimo)

El objetivo es el área que recibe el clic o el toque de un enlace, botón o control. Tiene que medir al menos 24 por 24 píxeles CSS, la unidad de medida de CSS, que no depende de la densidad de la pantalla. Un objetivo más pequeño pasa si se aplica una de estas excepciones (WCAG 2.2, 2.5.8):

• Espaciado: un círculo de 24 píxeles CSS de diámetro, centrado en el objetivo, no toca otro objetivo ni el círculo de otro objetivo pequeño.

• Equivalente: la misma función existe en otro control de la página que sí cumple el tamaño.

• En línea: el objetivo está dentro de una frase, como un enlace en medio de un párrafo.

• Control del navegador: el tamaño es el predeterminado del navegador y el sitio no lo modificó.

• Esencial: esa presentación es esencial o la exige la ley.

Para probarlo, mide con las DevTools los controles pequeños: cerrar un modal, íconos de redes sociales, paginación, filtros, flechas del carrusel. En el ejemplo del W3C, seis íconos de 20 píxeles pegados fallan, y los mismos íconos con 4 píxeles de separación pasan (Understanding 2.5.8). El criterio AAA equivalente, el 2.5.5, pide 44 por 44 píxeles CSS.

3.2.6 Ayuda consistente (nivel A)

El criterio se aplica a cuatro tipos de ayuda: datos de contacto de una persona (teléfono, correo electrónico, horario), mecanismo de contacto con una persona (chat con un agente, formulario de contacto), autoservicio (como una página de preguntas frecuentes) y contacto totalmente automatizado (como un chatbot). Si uno de ellos se repite en varias páginas, aparece en el mismo orden respecto al resto del contenido, salvo cuando el propio usuario cambia algo (WCAG 2.2, 3.2.6). El criterio no obliga al sitio a ofrecer ayuda; pide consistencia cuando la ayuda existe.

1. Elige páginas de tipos distintos: inicio, categoría, producto, carrito, contacto.

2. Anota la posición de cada mecanismo de ayuda en el orden del código, que es el orden de lectura del lector de pantalla, y no solo en la posición visual.

3. Compara páginas con el mismo ancho de pantalla y el mismo zoom. Las WCAG comparan el orden dentro de la misma variación de la página.

3.3.7 Entrada redundante (nivel A)

En un mismo proceso, el sitio no vuelve a pedir un dato que el usuario ya dio, a menos que lo traiga completado o lo ofrezca para seleccionarlo. El ejemplo clásico es la opción "dirección de envío igual a la de facturación". El autocompletado del navegador no cuenta, porque quien tiene que ofrecer el dato es el sitio (Understanding 3.3.7). Las excepciones son tres: volver a escribirlo es esencial, la petición existe por seguridad (como confirmar una contraseña nueva) o el dato anterior dejó de ser válido.

1. Recorre los flujos de varios pasos: registro, checkout, presupuesto, reserva de cita.

2. Anota cada campo que pide algo ya informado antes en el mismo flujo.

3. Comprueba si viene completado o si existe una opción para reutilizarlo.

4. Provoca un error de envío y mira si el formulario conserva lo que se escribió. El W3C usa el caso de un número de tarjeta que no debería borrarse después de un fallo.

3.3.8 Autenticación accesible (mínima)

Una prueba de función cognitiva, según la definición de las WCAG, es una tarea que exige recordar, manipular o transcribir información: memorizar una contraseña, escribir caracteres, acertar con la ortografía, hacer cuentas, resolver un rompecabezas. El nombre, el correo electrónico y el teléfono no cuentan, porque son del propio usuario e iguales en todos los sitios (WCAG 2.2, glosario). El inicio de sesión puede tener un paso así siempre que ofrezca una alternativa sin esa prueba o un mecanismo que ayude a superarla. Según el Understanding 3.3.8:

• Un campo de contraseña que acepta el gestor de contraseñas y el pegado cumple. Bloquear el pegado o el autocompletado es un fallo, salvo que haya una alternativa.

• Un CAPTCHA que pide escribir caracteres distorsionados falla si no hay alternativa. Un audio que pide transcribir lo que se oye no vale como alternativa.

• Un CAPTCHA de reconocer objetos se acepta en el nivel AA, pero no en el AAA (3.3.9).

• El código de verificación en dos pasos tiene que aceptar el pegado. Exigir que la persona escriba el código a mano no cumple el criterio.

• El enlace de acceso enviado por correo electrónico y el inicio de sesión con un proveedor externo mediante OAuth aparecen como formas de cumplir.

Para probarlo, abre el inicio de sesión con un gestor de contraseñas y mira si completa el usuario y la contraseña; intenta pegar la contraseña y el código de verificación; identifica si hay CAPTCHA y de qué tipo.

Relación con la NBR 17225 y con la LBI de Brasil

La Ley Brasileña de Inclusión (Lei Brasileira de Inclusão, LBI, Ley 13.146/2015), en su art. 63, hace obligatoria la accesibilidad en los sitios de empresas con sede o representación comercial en Brasil y de organismos de gobierno, "conforme a las mejores prácticas y directrices de accesibilidad adoptadas internacionalmente" (Ley 13.146/2015, traducción libre). La ley no cita las WCAG por su nombre.

La ABNT NBR 17225:2025, "Accesibilidad en contenido y aplicaciones web: Requisitos", tiene su primera edición del 11 de marzo de 2025 y sigue los criterios de conformidad de las WCAG 2.2. Separa los ítems en requisitos y recomendaciones y define dos tipos de conformidad (ABNT NBR 17225:2025, sección 4):

• Conformidad regular: se cumplen todos los requisitos. La norma dice que está alineada con el nivel AA de las WCAG 2.2, de modo que un sitio con conformidad regular también cumple los niveles A y AA.

• Conformidad plena: requisitos y recomendaciones, con una justificación razonable para cada recomendación no cumplida.

Los criterios nuevos de la 2.2 aparecen en la norma con nombres propios:

El 4.1.1 aparece en el anexo A de la norma (A.1.9), que repite la explicación del W3C de que el criterio ya no es necesario. Un punto en el que la NBR va más allá del AA de las WCAG: el ítem 5.11.6 establece como requisito un contraste de al menos 3:1 para el indicador de foco, con base en los criterios 1.4.11 (AA) y 2.4.13 (AAA). Quien audita según la norma brasileña debe probar ese ítem aunque el 2.4.13 sea AAA en las WCAG.

Quién está obligado por la ley y qué pide está en la guía principal de esta serie, Accesibilidad web en Brasil: qué exigen la LBI y la NBR 17225. Este texto explica la norma técnica; no es asesoramiento jurídico.

Cómo verificar tu sitio

La verificación gratuita de WebVyze analiza la página de inicio, sin registro, y señala riesgos de accesibilidad vinculados a la ley. Cubre la parte automatizable. Criterios como el foco oculto, el arrastre, la ayuda consistente y la autenticación necesitan a alguien navegando por el sitio, como se describe arriba. Para los dos temas que más aparecen en las auditorías, mira las guías de contraste de color y de formularios accesibles.