Accesibilidad web: incorporar WCAG 2.2 desde el diseño

La versión 2.2 de las Web Content Accessibility Guidelines es una recomendación del W3C desde octubre de 2023. No derriba las versiones anteriores: se mantiene retrocompatible y se limita a añadir nueve criterios de éxito dirigidos sobre todo a la navegación por teclado, las interacciones táctiles y la autenticación. Tratar la accesibilidad en la fase de diseño, en lugar de como un parche de final de proyecto, cambia radicalmente el coste de la conformidad. Un proyecto que lo anticipa absorbe estos criterios sin sobrecoste visible; uno que los descubre en la recepción paga cada corrección al precio más alto.

#Lo que añade WCAG 2.2

Los nueve criterios nuevos se reparten entre los tres niveles de conformidad. La mayoría corresponde al nivel AA, el que fijan los marcos normativos.

Dos criterios merecen atención inmediata. El tamaño del objetivo mínimo (2.5.8) exige zonas pulsables de al menos 24 por 24 píxeles CSS, salvo excepciones: un menú de navegación denso o iconos demasiado juntos pasan a ser no conformes. La autenticación accesible (3.3.8) prohíbe exigir una prueba cognitiva, como recordar una contraseña o resolver un rompecabezas, sin alternativa: un campo compatible con el gestor de contraseñas basta para cumplirla.

Los demás criterios apuntan a molestias concretas. Los movimientos de arrastre (2.5.7) exigen que toda acción de arrastrar y soltar ofrezca una alternativa con un solo puntero, en beneficio tanto de las personas con temblores como de quienes usan pantalla táctil. La ayuda coherente (3.2.6) pide que los mecanismos de asistencia, un formulario de contacto o un enlace a la ayuda, aparezcan en el mismo lugar de una página a otra. La entrada redundante (3.3.7) prohíbe volver a pedir información ya facilitada dentro de un mismo recorrido, salvo necesidad real: una dirección de envío no debería reescribirse en el paso de facturación.

#Tres niveles, un objetivo realista

Los criterios se ordenan en tres niveles acumulativos. Aspirar a AAA en todo un sitio no es obligatorio ni siempre posible; el nivel AA constituye el objetivo de referencia.

#Traducir los criterios a código

La mayoría de los criterios se satisfacen con HTML correcto y unas pocas reglas CSS, sin biblioteca. Un campo de formulario accesible asocia una etiqueta explícita, un tipo adecuado y una ayuda enlazada mediante aria-describedby.

<label for="email">Adresse e-mail</label>
<input id="email" name="email" type="email"
       autocomplete="email" required
       aria-describedby="email-aide">
<p id="email-aide">Format attendu : [email protected]</p>

El atributo autocomplete satisface directamente la autenticación accesible: deja que el navegador y el gestor de contraseñas rellenen el campo, sin esfuerzo cognitivo. En la presentación, el tamaño del objetivo y la visibilidad del foco se ajustan en unas pocas líneas, apoyándose en las variables del tema.

/* 2.5.8 Taille de cible (minimum) : 24 x 24 px */
.btn-icone {
  min-block-size: 24px;
  min-inline-size: 24px;
}

/* 2.4.11 Focus non masqué : un focus toujours visible */
:focus-visible {
  outline: 3px solid var(--focus, #1a9694);
  outline-offset: 2px;
}

Centralizar el color del foco en una variable evita reintroducirlo en cada componente y mantiene una representación coherente en tema claro y oscuro, en la lógica de los design tokens. El mismo enfoque vale para el espaciado de los objetivos: fijar una altura de línea mínima en las listas de navegación resuelve de una vez la conformidad de decenas de enlaces.

La entrada redundante se trata tanto en el servidor como en el marcado. Un formulario de varios pasos gana con conservar los valores ya introducidos y precargarlos, en lugar de mostrar campos vacíos. También aquí, un atributo autocomplete bien elegido y la persistencia del estado entre pasos bastan, sin componente a medida.

#El marco legal europeo

La accesibilidad ya no es solo una buena práctica. La European Accessibility Act se aplica desde el 28 de junio de 2025 a numerosos servicios digitales vendidos a particulares en la Unión: comercio en línea, banca, venta de entradas, plataformas de contenido. En la práctica, la norma técnica de referencia, EN 301 549, remite a los criterios WCAG de nivel AA. En Francia, el RGAA traspone la misma exigencia para los actores afectados, con un principio ya bien asentado: la ausencia de una declaración de conformidad y de un plan de acción es en sí misma un incumplimiento, con independencia de la calidad real del sitio.

El perímetro afectado es amplio y a menudo se subestima. Un mercado en línea, una aplicación de reservas o el área de cliente de un banco entran en el ámbito, mientras que un sitio meramente escaparate puede quedar exento en algunos casos. Comprobar la exposición antes de un rediseño evita descubrir la obligación con el presupuesto ya comprometido, y un sitio no conforme se expone ahora a un riesgo jurídico, no solo a una crítica de ergonomía.

Un criterio corregido en el maquetado cuesta unos minutos; el mismo, rehecho en producción, moviliza a todo un equipo.

#Integrar la accesibilidad en el flujo de trabajo

La automatización atrapa una parte de los defectos sin sustituir el control humano. Una auditoría con un motor como axe o la pestaña Lighthouse del navegador señala los contrastes insuficientes, las etiquetas ausentes y los objetivos demasiado pequeños. Estos controles conviene lanzarlos a lo largo del desarrollo antes que en la entrega, igual que el seguimiento de un sitio se instala en continuo y no al final. Integrados en la cadena de integración continua, bloquean una regresión antes de que llegue a producción, como una prueba unitaria fallida.

El marcado semántico, que sustenta la accesibilidad, sirve también al posicionamiento: un título correctamente estructurado beneficia al lector de pantalla y al motor de búsqueda por igual, y una jerarquía de títulos clara ayuda a ambos. Invertir en una base semántica limpia sirve, pues, a dos objetivos de un solo gesto, lo que vuelve el arbitraje presupuestario mucho más fácil de defender ante un cliente.

#Lo que hay que recordar

WCAG 2.2 no revoluciona nada, pero aprieta las exigencias donde los usuarios más tropiezan: objetivos táctiles, foco de teclado, autenticación. El nivel AA es el objetivo concreto, ahora respaldado por una obligación legal en Europa. El buen enfoque consiste en incorporar estos criterios desde el diseño, apoyarse en HTML semántico y variables de tema, y completar las auditorías automáticas con pruebas humanas. Es menos un proyecto puntual que un hábito que instalar en el flujo de trabajo.

Para profundizar: la especificación de referencia, Web Content Accessibility Guidelines (WCAG) 2.2 (W3C).