Tu app creada con IA se ve impecable en una captura. Invitas a cinco personas a probar el formulario de registro y una no puede avanzar con el teclado; otra escucha “cuadro de texto” sin saber si debe escribir su correo o contraseña. No es un problema estético: esos usuarios no pueden completar la acción por la que construiste el producto.

Antes de lanzar un prototipo hecho con Lovable, v0, Replit, Cursor o cualquier generador, haz una prueba pequeña pero repetible. Playwright documenta cómo ejecutar el motor axe dentro de un test. Detecta fallos comunes como controles sin etiqueta y problemas de contraste. Después debes probar con teclado y juicio humano: el propio Playwright y la W3C advierten que una herramienta automática no puede certificar toda la accesibilidad.

El caso: un formulario de contacto que sí deja completar la tarea

Imagina una página /contacto con nombre, correo, mensaje y botón de envío. El objetivo no es conseguir un “score perfecto” para presumir. La decisión útil es: ¿puede una persona identificar cada campo, llegar a él por teclado, corregir un error y enviar el formulario sin depender del ratón?

Primero instala Playwright Test y la integración oficial de axe en el proyecto JavaScript o TypeScript. Si Playwright ya existe, instala solo el segundo paquete:

npm install --save-dev @playwright/test @axe-core/playwright
npx playwright install chromium

Arranca tu app en local con el comando habitual del proyecto y confirma en el navegador la URL exacta del formulario. En el ejemplo siguiente se usa http://localhost:3000/contacto; cambia puerto y ruta por los tuyos. Guarda este archivo como tests/contacto-a11y.spec.js:

const { test, expect } = require('@playwright/test');
const AxeBuilder = require('@axe-core/playwright').default;

test('el formulario no tiene fallos automáticos A/AA', async ({ page }) => {
  await page.goto('http://localhost:3000/contacto');
  await expect(page.getByRole('heading', { name: /contacto/i })).toBeVisible();

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

  expect(result.violations).toEqual([]);
});

Ejecuta npx playwright test tests/contacto-a11y.spec.js mientras el servidor local siga abierto. Los tags del ejemplo son los que muestra la guía de Playwright para reglas WCAG 2.0 y 2.1 A/AA; no cubren automáticamente todos los criterios ni todas las versiones de WCAG. Si el test falla, lee el identificador de la regla y los nodos afectados. Corrige la interfaz, vuelve a ejecutar y conserva el test en tu repositorio. No escondas todo el formulario detrás de exclude(): Playwright advierte que eso omite también a sus descendientes.

La revisión manual que evita una falsa seguridad

Haz esta secuencia en el navegador sin tocar el ratón. Pulsa Tab desde el inicio y comprueba que el foco visible recorra campos y botón en un orden que tenga sentido. En cada campo, pregunta: ¿se ve su etiqueta?, ¿el propósito se entiende sin el texto placeholder?, ¿puedes llegar al mensaje de error y corregirlo? Envía el formulario vacío y escucha o inspecciona si el error se anuncia y se asocia al campo adecuado. Repite con zoom del navegador al 200% y una pantalla estrecha para detectar contenido que se corta.

Si puedes, añade una prueba con el lector de pantalla disponible en tu sistema. Pide a una persona ajena al equipo que complete la tarea sin instrucciones: una prueba real puede descubrir confusión que ninguna regla automática detecta. La W3C explica que los evaluadores automáticos ayudan a encontrar problemas, pero el juicio humano sigue siendo necesario.

Cómo usar IA sin que la prueba pierda valor

Entrega a tu agente el resultado concreto del test, no una orden vaga de “hazlo accesible”. Un prompt útil es: “Corrige las violaciones de axe del formulario /contacto. Mantén el comportamiento de envío. Añade etiquetas asociadas a cada control, un foco visible y errores comprensibles. Muéstrame el diff y no marques el trabajo terminado hasta que ejecute el test y revise el flujo con teclado.”

El agente puede proponer cambios, pero tú verificas lo que el usuario experimenta. En particular, comprueba que no haya convertido todos los campos en componentes visualmente bonitos pero difíciles de recorrer o anunciar. Si el test automático pasa y el flujo por teclado falla, la página todavía necesita trabajo.

Límite de esta guía: no ejecuté el test contra tu app ni afirmo que una pasada de axe demuestre conformidad legal. El código se basa en la sintaxis publicada por Playwright y debes adaptar URL, servidor y selectores a tu proyecto. Como criterio de salida, guarda la evidencia de la ejecución, una revisión manual breve y el diff de las correcciones.

Fuentes: Playwright: Accessibility testing; W3C WAI: Selecting evaluation tools. Consultadas el 2 de noviembre de 2026.