Automatizar lo automatizable: axe en tu suite

Lo que sí conviene automatizar

Hay problemas de accesibilidad que se detectan con reglas: un contraste insuficiente, un campo sin etiqueta, un botón sin nombre, una imagen sin texto alternativo, un idioma de página sin declarar. Revisarlos a mano en cada cambio es un desperdicio; dejar que una prueba los atrape en el pipeline, no.

La herramienta más usada para eso es axe-core, de código abierto, y se integra con las suites de automatización.

axe en Playwright

Con el paquete @axe-core/playwright, una prueba de accesibilidad se ve así:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('el checkout no tiene violaciones serias de accesibilidad', async ({ page }) => {
  await page.goto('/checkout');

  const resultado = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21aa', 'wcag22aa'])
    .analyze();

  const graves = resultado.violations.filter(
    (v) => v.impact === 'serious' || v.impact === 'critical',
  );
  expect(graves.map((v) => `${v.id}: ${v.nodes.length}`)).toEqual([]);
});

Tres decisiones que están en ese código:

• Las etiquetas limitan la revisión a las reglas de los niveles que tu proyecto exige (A y AA).
• El filtro por impacto define qué rompe el pipeline. Empezar por serias y críticas es razonable; las moderadas se revisan, pero no detienen una salida.
• El mensaje muestra el id de la regla y cuántos elementos fallan, para que quien lo arregle sepa por dónde partir.

Los estados también se revisan

Si axe solo corre al cargar la página, no ve lo que aparece después: el modal abierto, el menú desplegado, el formulario con errores. Muchos de los problemas viven justo ahí. La prueba lleva la página a esos estados y vuelve a correr axe en cada uno.

Deuda conocida, sin desactivar nada

Al sumar axe a un producto que ya existe, lo normal es que aparezcan muchas violaciones. Desactivar la prueba no es la respuesta, porque deja de proteger lo nuevo. Lo razonable:

1. registrar las violaciones existentes en una lista explícita de pendientes, con un comentario de por qué y hasta cuándo;
2. hacer que el pipeline falle con cualquier violación nueva;
3. bajar la lista con un plan.

Lo que no se automatiza

Esta es la parte que más se olvida: que axe no encuentre nada no significa que la página sea accesible. No puede decidir:

• si el orden del foco tiene sentido;
• si un texto alternativo describe bien la imagen ("imagen" pasa la regla, aunque no diga nada);
• si un error se entiende;
• si se puede completar el flujo con teclado o con lector de pantalla.

Por eso la estrategia que funciona combina las dos cosas: axe en cada cambio, para lo que se puede verificar con reglas, y una prueba manual con teclado y lector de pantalla en los flujos críticos antes de cada salida importante.