WCAG 2.2 AA: qué cambió realmente

WCAG 2.2 AA: Lo que realmente cambió

Las Pautas de Accesibilidad al Contenido Web 2.2 se convirtieron en una recomendación del W3C en octubre de 2023. Para las organizaciones sujetas a la Sección 508, la Ley Europea de Accesibilidad o las regulaciones del sector público en países como el Reino Unido, ya es el estándar requerido. El NHS, por ejemplo, ahora exige WCAG 2.2 AA para todos los servicios orientados a pacientes y al personal.

Si has estado siguiendo WCAG 2.1, la transición no es masiva. Se añadieron nueve nuevos criterios de éxito, se eliminó uno y todo lo demás permaneció igual. Pero esos nueve criterios importan. Abordan deficiencias que han frustrado a usuarios con discapacidades cognitivas, baja visión y discapacidades motoras durante años.

Este artículo cubre qué cambió, qué significan esos cambios para tus sitios y cómo implementarlos.

El panorama general: qué añade WCAG 2.2

WCAG 2.2 es compatible con versiones anteriores. Si cumplías con WCAG 2.1 AA, estás casi allí. Solo necesitas abordar los nuevos criterios.

Nueve nuevos criterios de éxito en total. Seis están en los niveles A y AA, lo que significa que son necesarios para la conformidad en esos niveles. Tres son AAA, que siguen siendo mejoras opcionales.

Los nuevos criterios se centran en tres áreas:

• Accesibilidad cognitiva: reducir la carga de memoria, proporcionar ayuda consistente, prevenir la entrada de datos redundante.
• Accesibilidad motora: objetivos táctiles más grandes, alternativas a los gestos de arrastre.
• Accesibilidad para baja visión: mejor visibilidad del foco para la navegación por teclado.

WCAG 2.2 también eliminó 4.1.1 Análisis (Parsing). Ese criterio requería HTML válido. El W3C determinó que está obsoleto porque los navegadores modernos manejan los errores de análisis con soltura, y el propósito original se cumple ahora por otros medios.

Los seis criterios que necesitas para la conformidad AA

Si tu objetivo es WCAG 2.2 AA, debes cumplir todo lo de 2.1 AA más estos seis nuevos criterios.

2.4.11 Foco no oculto (Mínimo) - Nivel A

Qué requiere: Cuando un componente de la interfaz de usuario recibe el foco del teclado, el componente no queda completamente oculto debido al contenido creado por el autor.

Qué significa: Los encabezados fijos, pies de página fijos, widgets de chat y banners de cookies no pueden ocultar completamente el elemento que actualmente tiene el foco del teclado. El usuario debe poder ver al menos parte de lo que tiene enfocado.

Por qué es importante: Imagina navegar con la tecla Tab por una página y que el enlace enfocado desaparezca detrás de un encabezado fijo. No tienes idea de dónde estás ni de lo que estás a punto de activar. Para los usuarios de teclado, esto es desorientador y puede hacer imposible la navegación.

Fallos comunes:

• Navegación fija que cubre enlaces enfocados
• Widgets de chat que se superponen a campos de formulario
• Banners de consentimiento de cookies que ocultan enlaces del pie de página
• CTAs fijos que cubren elementos interactivos

Cómo solucionarlo:

css

/* Asegurar que los encabezados fijos no cubran el contenido enfocado */ html {  scroll-padding-top: 80px; /* Altura de tu encabezado fijo */ } /* Asegurar que los elementos enfocados se desplacen a la vista */ :focus {  scroll-margin-top: 100px; /* Crea espacio sobre los elementos enfocados */ }

La clave es gestionar la posición de desplazamiento para que los elementos enfocados aparezcan debajo de cualquier contenido fijo.

2.4.12 Foco no oculto (Mejorado) - Nivel AA

Qué requiere: Cuando un componente recibe el foco del teclado, ninguna parte del componente queda oculta por el contenido creado por el autor.

Qué significa: Esta es la versión más estricta de 2.4.11. La versión mínima permite el ocultamiento parcial. La versión mejorada requiere que todo el elemento enfocado sea visible.

Por qué es importante: Para usuarios con baja visión o discapacidades cognitivas, incluso el ocultamiento parcial puede dificultar la comprensión de lo que está sucediendo. Si la etiqueta de un botón está oculta, es posible que no sepan qué hace.

Cómo solucionarlo: Las mismas técnicas que en 2.4.11, pero más exhaustivas. Necesitas auditar cada elemento fijo y asegurarte de que los componentes enfocados sean completamente visibles.

2.5.7 Movimientos de arrastre - Nivel AA

Qué requiere: Toda funcionalidad que utiliza un movimiento de arrastre para su operación puede lograrse con un solo puntero sin arrastrar, a menos que arrastrar sea esencial.

Qué significa: Si tienes interfaces de arrastrar y soltar, controles deslizantes o cualquier funcionalidad que requiera hacer clic, mantener y mover, necesitas una alternativa que funcione con un solo clic o toque.

Por qué es importante: Algunas personas no pueden realizar movimientos de arrastre con precisión. Otras utilizan dispositivos de entrada especializados como punteros de cabeza o sistemas de seguimiento ocular que hacen que arrastrar sea engorroso o imposible. Como explica el documento de comprensión del W3C, arrastrar requiere cuatro acciones discretas: presionar y mantener, mover hasta el punto final, soltar. No todos los usuarios pueden hacer eso.

Fallos comunes:

• Listas ordenables que requieren arrastrar y soltar
• Interfaces de recorte de imágenes
• Controles deslizantes sin alternativas de teclado o botones
• Zonas de carga de archivos sin alternativas de clic
• Tableros Kanban con movimiento de tarjetas solo por arrastre

Cómo solucionarlo:

html

<!-- Lista ordenable con alternativas de botón --> <ul role="list" aria-label="Elementos ordenables">  <li>    <span>Elemento 1</span>    <button aria-label="Mover elemento 1 arriba">↑</button>    <button aria-label="Mover elemento 1 abajo">↓</button>  </li> </ul> <!-- Control deslizante con botones de incremento --> <div role="group" aria-label="Rango de precio">  <button aria-label="Disminuir precio mínimo">−</button>  <input type="range" aria-label="Precio mínimo">  <button aria-label="Aumentar precio mínimo">+</button> </div>

La alternativa debe funcionar con una sola acción de puntero, no solo con atajos de teclado.

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

Qué requiere: El tamaño del objetivo para entradas de puntero es de al menos 24 por 24 píxeles CSS, con excepciones específicas.

Qué significa: Los botones, enlaces y controles interactivos necesitan un área mínima de toque y clic. Si un objetivo es más pequeño de 24x24, aún puede pasar si hay suficiente espacio a su alrededor.

Por qué es importante: Los objetivos pequeños son difíciles para usuarios con temblores en las manos, destreza limitada o cualquier persona que use una pantalla táctil en un autobús en movimiento. WCAG 2.1 tenía un requisito de 44x44 en el Nivel AAA, pero eso era demasiado estricto para la mayoría de las organizaciones. Esto trae un requisito más pequeño, pero aún útil, al Nivel AA.

Las excepciones:

• En línea: Enlaces dentro de oraciones o bloques de texto (se refluyen, por lo que los autores no pueden controlar la posición).
• Espaciado: Si un objetivo es más pequeño de 24x24 pero tiene al menos 24 píxeles CSS de espacio entre él y los objetivos adyacentes, pasa.
• Esencial: Cuando una presentación particular es esencial para la información que se transmite (como pines de mapa que muestran ubicaciones exactas).
• Legal: Cuando se requiere legalmente replicar un formulario en papel con un tamaño específico.

Cómo solucionarlo:

css

/* Asegurar el tamaño mínimo del objetivo */ button, a:not(.inline-link), [role="button"] {  min-width: 24px;  min-height: 24px; } /* Los botones de icono necesitan un tamaño explícito */ .icon-button {  width: 44px;  /* Aún mejor para toque */  height: 44px;  display: inline-flex;  align-items: center;  justify-content: center; } /* Alternativa de espaciado */ .compact-nav a {  padding: 12px; /* Crea un área de objetivo efectiva de 24px+ */ }

El requisito es independiente del zoom de la página. Cuando los usuarios hacen zoom, los píxeles CSS permanecen del mismo tamaño, por lo que no puedes afirmar que está bien en niveles de zoom más altos.

3.2.6 Ayuda consistente - Nivel A

Qué requiere: Si una página web contiene mecanismos de ayuda (datos de contacto, chat, opciones de autoayuda) y esos mecanismos se repiten en múltiples páginas, ocurren en el mismo orden relativo.

Qué significa: Tus opciones de ayuda deben estar en el mismo lugar en cada página. Si tienes un enlace de contacto en el pie de página, debe estar en la misma posición relativa al otro contenido del pie de página en todo el sitio.

Por qué es importante: Los usuarios con discapacidades cognitivas dependen de patrones consistentes. Mover los mecanismos de ayuda entre páginas crea confusión y aumenta la carga cognitiva. Cuando alguien necesita ayuda, necesita encontrarla de inmediato, no buscarla.

Cómo solucionarlo:

• Colocar enlaces de ayuda en ubicaciones consistentes de encabezado o pie de página.
• Usar etiquetado consistente ("Ayuda", "Contáctenos", "Soporte").
• Mantener el mismo orden cuando existan múltiples opciones de ayuda.

3.3.7 Entrada redundante - Nivel A

Qué requiere: La información ingresada previamente por el usuario o proporcionada a este, que se requiere ingresar nuevamente en el mismo proceso, se autocompleta automáticamente o está disponible para que el usuario la seleccione.

Qué significa: No hagas que los usuarios ingresen la misma información dos veces. Si necesitas direcciones de envío y facturación, proporciona una casilla de verificación para copiarlas. Si pides un correo electrónico en la página uno y nuevamente en la página tres, precárgalo.

Por qué es importante: Volver a ingresar información es frustrante para todos. Para usuarios con dificultades de memoria, discapacidades motoras o aquellos que utilizan tecnologías de asistencia, puede ser una barrera significativa.

Las excepciones:

• Volver a ingresar es esencial (como confirmar una nueva contraseña).
• La información es necesaria por seguridad.
• La información ingresada previamente ya no es válida.

Cómo solucionarlo:

html

<!-- Autocompletar facturación desde envío --> <input type="checkbox" id="same-address"> <label for="same-address">Dirección de facturación igual que la de envío</label> <!-- Precargar desde el paso anterior --> <input type="email" value="{{ previouslyEnteredEmail }}"       aria-describedby="email-note"> <span id="email-note">Precargado del paso anterior</span> <!-- Usar autocompletado para campos comunes --> <input type="text" name="shipping-street" autocomplete="shipping street-address">

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

Qué requiere: No se requiere una prueba de función cognitiva (como recordar una contraseña o resolver un rompecabezas) para ningún paso en un proceso de autenticación, a menos que ese paso proporcione al menos un método alternativo que no dependa de la función cognitiva, o un mecanismo para ayudar al usuario.

Qué significa: No puedes obligar a los usuarios a resolver rompecabezas, transcribir texto o recordar contraseñas complejas sin proporcionar alternativas que no dependan de la memoria o la capacidad cognitiva.

Por qué es importante: La autenticación tradicional crea barreras para usuarios con discapacidades cognitivas, problemas de memoria y discapacidades de aprendizaje. Los CAPTCHAs, en particular, pueden ser imposibles para algunos usuarios.

Alternativas conformes:

• Soporte para administradores de contraseñas (atributos de autocompletado adecuados)
• Códigos de autenticación por correo electrónico o SMS con copiar y pegar habilitado
• Autenticación biométrica
• Claves de seguridad físicas
• Autenticación OAuth o de terceros

Lo que no funciona: Las pruebas de reconocimiento de objetos (seleccione todas las imágenes con semáforos) siguen siendo pruebas cognitivas. Están permitidas bajo los criterios AA mínimos, pero no son ideales.

Cómo solucionarlo:

html

<!-- Permitir autocompletado del administrador de contraseñas --> <input type="email" autocomplete="username email" aria-label="Dirección de correo electrónico"> <input type="password" autocomplete="current-password" aria-label="Contraseña"> <!-- Permitir pegar en campos de verificación --> <input type="text" inputmode="numeric" autocomplete="one-time-code"       aria-label="Código de verificación de 6 dígitos"> <!-- Proporcionar alternativas a CAPTCHA --> <div role="group" aria-label="Verificación">  <p>Por favor, complete un método de verificación:</p>  <button>CAPTCHA de audio</button>  <button>Código de verificación por correo electrónico</button> </div>

Los tres criterios AAA

WCAG 2.2 también añadió tres criterios de Nivel AAA. La mayoría de las organizaciones no los necesitarán para cumplir, pero vale la pena entenderlos.

2.4.13 Apariencia del foco - Nivel AAA

Requiere que los indicadores de foco tengan un tamaño específico (al menos tan grande como un perímetro de 2px del elemento) y contraste (al menos 3:1 entre el estado enfocado y el no enfocado). El patrón del sistema de diseño del gobierno del Reino Unido (fondo amarillo con subrayado negro) no cumple con esto, porque no se extiende a un perímetro de 2px y el contraste sobre fondos blancos es inferior a 3:1.

3.3.9 Autenticación accesible (Mejorado) - Nivel AAA

Requiere que no haya ninguna prueba de función cognitiva para ningún paso de autenticación. Ni siquiera se permiten el reconocimiento de objetos ni el reconocimiento de contenido personal.

Lo que se eliminó: 4.1.1 Análisis (Parsing)

WCAG 2.2 elimina el Criterio de éxito 4.1.1 Análisis, que requería que el HTML estuviera bien formado con etiquetas de inicio y fin completas, anidamiento adecuado y sin atributos duplicados.

El W3C determinó que este criterio está obsoleto porque:

• Los navegadores modernos manejan los errores de análisis con soltura.
• Las tecnologías de asistencia trabajan con los DOM del navegador, no con el HTML sin procesar.
• Los errores de validación rara vez causan fallos de accesibilidad.
• Las herramientas automatizadas señalaban muchos errores de análisis que no causaban barreras reales.

Esto no significa que debas escribir HTML inválido. El HTML válido sigue siendo una buena práctica. Pero ya no es un requisito de WCAG.

Prioridades de implementación

Si estás pasando de WCAG 2.1 AA a 2.2 AA, aborda estos criterios en orden:

1. Foco no oculto: Victorias rápidas ajustando el relleno de desplazamiento y los márgenes.
2. Tamaño del objetivo: Auditar tamaños de botones y enlaces, corregir los pequeños.
3. Entrada redundante: Revisar formularios de varios pasos para campos repetidos.
4. Movimientos de arrastre: Añadir alternativas a las interfaces de arrastrar y soltar.
5. Autenticación accesible: Revisar los flujos de inicio de sesión y añadir soporte para administradores de contraseñas.
6. Ayuda consistente: Verificar la ubicación de la ayuda en todas las páginas.

El manual de servicio del NHS proporciona un buen resumen: "Su servicio debe cumplir con WCAG 2.2. El Servicio Digital Gubernamental, el Departamento de Salud y Asistencia Social y NHS England ahora están monitoreando la accesibilidad según WCAG 2.2".

Esa es la realidad. Estos no son requisitos teóricos para el futuro. Se están aplicando ahora.