WCAG 2.2 nivel AA: qué revisar en una auditoría

Hace un tiempo escribí sobre las funciones de accesibilidad que implementé en plataformas de gobierno: invertir colores, escala de grises, tamaño de fuente, resaltar enlaces. Ese artículo cuenta qué tiene el widget.

Este va de otra cosa, que es lo que se revisa en una auditoría: contra qué se mide un sitio.

Un widget no hace accesible un sitio

Conviene empezar por aquí porque se vende mucho lo contrario: una barra de herramientas de accesibilidad no cumple las WCAG. Ninguna de las funciones que enumeré en aquel artículo satisface un criterio por sí sola.

Un widget le da controles al usuario. Las WCAG piden que el sitio funcione antes de tocar nada: que se pueda navegar con teclado, que el contraste sea suficiente de entrada, que las imágenes tengan texto alternativo y que los formularios digan qué falló.

Si tu sitio necesita que el usuario active “alto contraste” para poder leerse, no cumple el criterio 1.4.3. El widget tapa el problema en vez de resolverlo.

Eso no lo hace inútil. Es una comodidad legítima y en un portal ciudadano se agradece, pero va además del cumplimiento, nunca en su lugar.

Qué cambió en WCAG 2.2

WCAG 2.2 es Recomendación del W3C desde octubre de 2023. Es compatible hacia atrás: si cumples 2.2, cumples también 2.1 y 2.0. Añade nueve criterios nuevos y retira uno.

El que se retira es el 4.1.1 (Parsing), y vale la pena mencionarlo porque confunde: se dio por obsoleto porque los navegadores actuales ya se recuperan solos del HTML mal formado. Si una auditoría todavía lo reporta como fallo, está desactualizada.

De los nueve nuevos, seis son de nivel A o AA, que es lo que suele exigirse en el sector público:

Criterio	Nivel	De qué va
2.4.11 Focus Not Obscured (Minimum)	AA	El elemento con foco no puede quedar tapado
2.5.7 Dragging Movements	AA	Todo lo que se arrastra necesita una alternativa sin arrastrar
2.5.8 Target Size (Minimum)	AA	Objetivos táctiles de al menos 24×24 px CSS
3.2.6 Consistent Help	A	La ayuda, en el mismo sitio en todas las páginas
3.3.7 Redundant Entry	A	No pedir dos veces el mismo dato
3.3.8 Accessible Authentication (Minimum)	AA	Nada de pruebas cognitivas para iniciar sesión

Los otros tres son AAA, y salvo que tengas un requisito específico no vas a ir a por ellos.

Los seis nuevos y cómo comprobarlos

Los ordeno según lo a menudo que suelen fallar.

2.5.8 Target Size

Cualquier elemento interactivo tiene que medir al menos 24×24 píxeles CSS, con algunas excepciones, como los enlaces dentro de un párrafo.

Es de los que más fallan, y casi siempre en los mismos sitios: los iconos de redes sociales del pie de página, el botón de cerrar de los modales y los paginadores. Un icono de 16 px con 2 px de padding no llega.

Una forma rápida de encontrar candidatos, desde la consola del navegador:

[...document.querySelectorAll('a, button, [role="button"], input, select')]
  .filter(el => {
    const r = el.getBoundingClientRect();
    return r.width && (r.width < 24 || r.height < 24);
  })
  .forEach(el => console.log(el.getBoundingClientRect().width.toFixed(0)
    + '×' + el.getBoundingClientRect().height.toFixed(0), el));

Eso te da candidatos, no fallos confirmados. Hay excepciones válidas y hay que revisarlas a mano.

2.4.11 Focus Not Obscured

Cuando navegas con Tab, el elemento que tiene el foco no puede quedar oculto detrás de otra cosa. El culpable habitual es un patrón muy de moda: la cabecera fija. Tabulas hacia abajo, la página se desplaza y el elemento con foco queda justo debajo del header.

Se comprueba solo con el teclado: Tab desde arriba hasta el final de la página, sin tocar el ratón, fijándote en si en algún momento pierdes de vista el foco. Normalmente se arregla con una regla:

:target, a, button, input, select, textarea {
  scroll-margin-top: 6rem; /* la altura de tu cabecera fija */
}

Ya que estás con el teclado, revisa también el 2.4.7 (Focus Visible), que viene de 2.1: que el indicador de foco exista y se vea. Un outline: none sin nada que lo sustituya es un fallo.

2.5.7 Dragging Movements

Todo lo que funcione arrastrando necesita una alternativa con un solo clic o toque. Afecta a las listas que se reordenan, a los selectores de rango y a los mapas.

En una plataforma de gobierno suele aparecer en dos sitios: los mapas, que necesitan botones de zoom además del gesto de pellizcar y arrastrar, y los selectores de rango, que necesitan también un campo para escribir el número.

3.3.8 Accessible Authentication

No se puede exigir una prueba cognitiva para iniciar sesión, como recordar una contraseña, resolver un puzle o copiar caracteres, sin ofrecer otra forma de hacerlo.

En la práctica tiene dos consecuencias. Un CAPTCHA de copiar texto distorsionado incumple el criterio si no hay alternativa. Y bloquear el pegado en el campo de contraseña también, porque impide usar un gestor de contraseñas:

<!-- incumple 3.3.8: impide usar un gestor de contraseñas -->
<input type="password" onpaste="return false" />

Además, deja que el navegador ayude con autocomplete="current-password".

3.3.7 Redundant Entry

Si ya pediste un dato en el paso 1, no lo vuelvas a pedir en el paso 4: rellénalo tú o deja que el usuario lo seleccione. El ejemplo típico es la dirección de envío y la de facturación, que se resuelve con una casilla de “son la misma”.

En los trámites municipales de varios pasos es donde más se nota, y donde más gente abandona.

3.2.6 Consistent Help

Si ofreces ayuda (teléfono, chat, formulario de contacto), tiene que estar en el mismo lugar en todas las páginas. El criterio no te obliga a tenerla, solo a no cambiarla de sitio.

Lo que hay que revisar aunque no sea nuevo

Los criterios nuevos no son los que más fallan. Estos otros, que vienen de 2.0, fallan mucho más:

• 1.1.1 Contenido no textual. Toda imagen con información necesita alt, y las decorativas, alt="". Ojo también con lo contrario: un alt vacío en una imagen que sí comunica algo es tan fallo como no ponerlo. Lo sé porque me pasó: la portada de mi propio artículo sobre accesibilidad tuvo el alt vacío durante meses.
• 1.4.3 Contraste mínimo. 4.5:1 para texto normal y 3:1 para texto grande. Es donde más daño hacen los degradados y el glassmorphism.
• 1.3.1 Información y relaciones. Encabezados en orden, sin saltar de h2 a h4. Tablas con <th scope>. Formularios con un <label> asociado, no con un <span> que parece una etiqueta.
• 2.1.1 Teclado. Todo lo que se hace con el ratón se tiene que poder hacer con el teclado. Los <div onclick> son los sospechosos habituales.
• 2.1.2 Sin trampas de teclado. Por ejemplo, un modal que atrapa el foco y no deja salir con Esc.
• 3.3.1 Identificación de errores. El error tiene que decir qué campo falló y por qué. “Error en el formulario” no cumple.
• 4.1.3 Mensajes de estado. Un “guardado correctamente” que aparece sin recargar la página necesita role="status" para que un lector de pantalla lo anuncie.

Cómo auditar en la práctica

El orden importa, porque cada paso encuentra cosas que el anterior no ve.

1. Un analizador automático, para lo evidente. Detecta problemas de contraste, alt que faltan, formularios sin etiqueta y encabezados mal ordenados. Es rápido y es lo primero que conviene pasar.
2. El teclado, que es donde aparece lo caro. Tab por toda la página sin tocar el ratón: ¿se ve siempre el foco?, ¿el orden tiene sentido?, ¿puedes salir de todos los modales con Esc?, ¿puedes activarlo todo con Enter o la barra espaciadora? Diez minutos con el teclado encuentran más que muchos informes.
3. Zoom. Al 200 % el texto tiene que seguir completo y legible (criterio 1.4.4), y al 400 %, que en un escritorio equivale a una pantalla de 320 px de ancho, el contenido no debería obligar a desplazarse en horizontal (1.4.10).
4. Un lector de pantalla, aunque lo uses con torpeza. NVDA en Windows y VoiceOver en Mac son gratuitos. No hace falta ser experto: recorre tu propio formulario con los ojos cerrados y vas a encontrar cosas que ningún analizador reporta.

Por qué no se puede automatizar del todo

Antes de fiarte de un informe automático conviene tener claro su límite: las herramientas automáticas detectan solo una parte pequeña de los problemas reales.

Un analizador comprueba que la imagen tiene alt, pero no si el texto describe la imagen. Verifica que existe un <label>, pero no si lo que dice tiene sentido. Mide el contraste de un color sólido, pero no el de un texto sobre un fondo que cambia. Y puede saber que hay un orden de tabulación, pero no si es lógico.

Todo lo que depende del significado se le escapa, y ahí está la mayor parte de la accesibilidad real.

En el próximo artículo quiero medir justo esa diferencia: pasar un auditor automático por un sitio real, revisarlo después a mano y comparar lo que encuentra cada uno.