La accesibilidad se construye; no se audita

La accesibilidad suele fallar no porque a un equipo no le importe, sino porque la deja para el final. Construye el producto, programa una auditoría cerca del cierre y luego intenta resolver una lista larga de hallazgos mientras la fecha de lanzamiento ya se retrasa. Para entonces, los problemas forman parte de componentes usados en cincuenta lugares y quienes los escribieron ya están en otro trabajo. La accesibilidad se convierte en una deuda pagada bajo presión, no en una propiedad del producto. La solución tiene que ser estructural: dejar de tratarla como una fase y convertirla en una práctica de ingeniería que se comprueba en cada cambio.

Una auditoría es una foto; una verificación continua evita retrocesos

Una auditoría muestra cómo se veía el producto un día. El siguiente cambio envejece esa imagen. Una verificación de CI funciona de otra manera: cuando ya está instalada, la compilación se niega a retroceder. Una combinación de colores sin contraste suficiente, un div que finge ser botón o una imagen sin texto alternativo útil deben fallar cerca del código que causó el problema. En este sitio, Lighthouse y las comprobaciones de axe en navegador recorren las rutas publicadas en inglés y español, en claro y oscuro. Los controles dinámicos tienen sus propias pruebas de interacción. Eso no reemplaza el juicio humano. Mantiene fuera los fallos evitables para que las personas dediquen su atención a lo que solo las personas pueden juzgar.

Dónde viven las verificaciones

Ninguna herramienta sola lo detecta todo, así que las superpongo. Cada una corre por su cuenta, y cada una bloquea una fusión cuando falla:

• axe dentro de las pruebas unitarias. Los componentes se comprueban contra reglas de accesibilidad en la unidad más pequeña, así que una infracción aparece junto al código que la causó, no tres integraciones después.
• axe dentro de Playwright. Las mismas reglas corren contra páginas completamente renderizadas en un navegador real, en cada ruta en ambos idiomas y ambos temas, donde el estado dinámico, el orden de foco y el contenido que solo existe después de interactuar sí están presentes para comprobarse.
• Lighthouse. Un umbral de puntuación de accesibilidad hace fallar la canalización si baja de 1,0 y detecta problemas de página completa que las pruebas de componentes no ven.

Lo que estas herramientas tienen en común es la honestidad sobre sus propios límites. Las verificaciones automatizadas atrapan de forma fiable una parte real de los problemas de accesibilidad, como el contraste, los nombres faltantes, los roles rotos y la estructura malformada, pero no pueden decirte si tu texto alternativo significa algo de verdad, ni si alguien que usa solo el teclado puede terminar la tarea. Esa es toda la razón por la que quiero que las máquinas se encarguen de los fallos verificables por máquina. Libera las pruebas manuales y con tecnología de asistencia para las decisiones de criterio que ningún analizador hará jamás.

Dos niveles distintos, a propósito

Sé preciso sobre qué estándar te estás exigiendo, porque la respuesta honesta cambia según lo que esté en juego. WCAG, las Pautas de Accesibilidad para el Contenido Web, ahora en la versión 2.2, que el W3C publicó como Recomendación en 2023, define tres niveles de conformidad: A, AA y AAA. AA es una base ampliamente utilizada para servicios digitales del sector público, aunque los requisitos aplicables dependen del servicio y la jurisdicción. AAA es el nivel más estricto y las propias pautas señalan que no es alcanzable para todo el contenido. Por eso, algunos criterios AAA pueden servir como objetivos adicionales para una superficie pequeña con un alcance claramente definido.

Para los servicios públicos, trato la accesibilidad como una práctica continua de ingeniería: definir una base clara, incluir verificaciones automatizadas en la entrega, probar manualmente los recorridos importantes e integrar el acceso lingüístico en el mismo sistema de calidad. Las métricas de una sola herramienta son señales, no una declaración amplia de conformidad.

Este portafolio es una superficie más pequeña donde puedo probar decisiones más estrictas. Apunto a WCAG 2.2 AA y añado de forma deliberada algunas verificaciones de nivel AAA, incluido el contraste de texto de 7:1. No he completado la revisión manual y con tecnologías de asistencia necesaria para una declaración más amplia de conformidad, así que no llamo AAA al sitio. Las verificaciones automatizadas siguen siendo evidencia útil de la práctica y las brechas conocidas permanecen visibles hasta que se aborden.

Por qué una verificación continua cambia la cultura

La razón más profunda por la que prefiero las verificaciones continuas a las auditorías no tiene nada que ver con las herramientas. Es lo que cada una le enseña a un equipo. Una auditoría al final del proyecto le enseña a quienes programan que la accesibilidad es trabajo de otra persona, que alguien revisará después. Una verificación en cada cambio enseña lo contrario. La accesibilidad es parte del trabajo desde ese momento, igual que hacer pasar las pruebas. Cuando la retroalimentación llega en minutos y no en meses, las personas aprenden las reglas mientras trabajan y el siguiente componente nace accesible porque así construye el equipo. La accesibilidad deja de ser una reparación pendiente y pasa a formar parte de cómo trabaja el equipo.

Una auditoría pregunta, al final, si llegaste. Una práctica se asegura de que nunca te fuiste. Para el software que de verdad usan las instituciones públicas y las personas que dependen de ellas, esa diferencia no es pedantería: lo es todo.