La accesibilidad es una práctica de ingeniería, no una auditoría

La accesibilidad suele fracasar no porque a un equipo no le importe, sino por cuándo deciden que les importe. Construyen todo el producto, contratan una auditoría hacia el final y después clasifican una larga lista de hallazgos contra una fecha de lanzamiento que ya se está retrasando. Para entonces los problemas están incrustados en componentes usados en cincuenta lugares. Quienes los escribieron ya se han ido. Y la accesibilidad se vuelve un impuesto que se paga bajo presión en lugar de una propiedad del trabajo. He acabado pensando que el arreglo tiene que ser estructural. Dejar de tratarla como una fase. Empezar a tratarla como ingeniería, algo que se exige en cada cambio, por máquinas, todo el tiempo.

Una auditoría es una foto; una compuerta es un trinquete

Una auditoría te dice cómo se veía el producto el día en que alguien lo miró. Una fotografía. Se fusiona el siguiente cambio y esa foto ya está desactualizada, y el resultado por el que pagaste empieza a pudrirse. Una compuerta de CI funciona distinto. Es un trinquete. Una vez que una verificación está dentro, la compilación se niega a retroceder. Una nueva combinación de colores que cae por debajo del contraste, un botón que en realidad es un div sin rol, una imagen publicada sin texto alternativo. Dejan de ser cosas que esperas que un revisor note y pasan a ser cosas que hacen fallar la compilación, en minutos, en la rama, antes de que nadie haya fusionado. En este sitio el trinquete es real: un presupuesto de accesibilidad de Lighthouse que tiene que dar un 1.0 perfecto o la canalización falla, y una suite de Playwright que verifica cero infracciones de accesibilidad en cada ruta, en inglés y en español, en claro y en oscuro. Ningún cambio puede hacer retroceder en silencio nada de eso, porque la compilación no lo permite. No intento reemplazar el juicio humano. Intento que los fallos verificables por máquina sean imposibles de publicar por accidente, para que las personas dediquen su atención a las partes 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 presupuesto sobre la puntuación general de accesibilidad que hace fallar la canalización si baja de un 1.0 perfecto, atrapando problemas de página completa que las pruebas de componentes no pueden ver.

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 listones 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. Para los sistemas públicos, AA es el suelo legal y práctico. Es el nivel al que apuntan en la práctica la Sección 508 y la ADA, y es la base correcta para un servicio gubernamental que tiene que atender a todo el mundo. AAA es el nivel más estricto, y las propias pautas señalan que no es alcanzable para todo el contenido. Que es justo lo que lo convierte en un objetivo interesante para una superficie pequeña que controlas por completo.

Por eso sostengo dos listones distintos a propósito, y los mantengo separados. MyCareer.NJ, una plataforma estatal que atiende a cerca de 1,7 millones de residentes, se sostiene en el suelo AA que exigen los servicios públicos, y el historial de ingeniería lo respalda: una puntuación de accesibilidad de Lighthouse del 100%, y un 100% de Core Web Vitals "Good" en casi 200.000 URL, con paridad bilingüe inglés/español tratada como parte de la accesibilidad, no como una función aparte. Ese es el estándar correcto y defendible para un sistema gubernamental de esa escala.

Este sitio es otra cosa. Es pequeño, es enteramente mío y el sustento de nadie depende de él, lo que lo convierte en el lugar perfecto para sostener el listón más alto sin concesiones. Por eso lo construí según WCAG 2.2 AAA: las relaciones de contraste más estrictas, sin depender solo del color, completamente operable con el teclado, estructurado para que la tecnología de asistencia se mueva por él con limpieza. No afirmo que AAA sea el objetivo correcto para todo proyecto. No lo es, y fingir lo contrario sería justo el tipo de imprecisión contra el que argumenta toda esta entrada. Lo reivindico como prueba de práctica. Construir este sitio según AAA es mi forma de mostrar que las compuertas que describo son reales, que las ejecuto sobre mi propio trabajo, y que prefiero demostrar la disciplina antes que solo escribir sobre ella.

Por qué la compuerta cambia la cultura

La razón más profunda por la que prefiero las compuertas 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 los ingenieros que la accesibilidad es trabajo de otra persona, revisado más tarde, por alguien con un portapapeles. Una compuerta en cada cambio enseña lo contrario. La accesibilidad es tu trabajo, ahora mismo, igual que hacer pasar las pruebas. Cuando la retroalimentación llega en minutos y no en meses, las personas aprenden las reglas escribiendo dentro de ellas, y el siguiente componente nace accesible porque así es como construye el equipo. La accesibilidad deja de ser algo que remedias y pasa a ser algo que tienes.

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.