El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia
HOME Mis cursos Finalizados
◄ Anterior
◄

Herramientas de Pruebas Automatizadas

Siguiente ►
►

En la lección 06-01 hiciste el trabajo lento y honesto: recorrer la ficha de curso de Cursalia con teclado, NVDA, zoom y DevTools. Funciona, pero no escala. Nadie va a repetir a mano ese recorrido en 40 páginas, en cada despliegue, en cada pull request. Ahí entran las herramientas automatizadas: analizan el código (el DOM ya renderizado) y encuentran, en segundos, problemas objetivos que a un humano le llevaría media hora. Pero antes de la primera captura, grábate esta cifra en la frente: lo automático detecta solo un 30-40% de los problemas de accesibilidad. No sustituye a las pruebas manuales de 06-01, ni a los usuarios reales de 06-03. Es la primera capa de una defensa en profundidad, no la defensa entera.

Contenido

  1. Qué puede y qué no puede ver una máquina
  2. axe-core y axe DevTools (la extensión)
  3. WAVE
  4. Lighthouse en Chrome DevTools
  5. Pa11y (línea de comandos)
  6. Accessibility Insights
  7. Linting en desarrollo: eslint-plugin-jsx-a11y
  8. Integración en CI: que nadie rompa lo arreglado
  9. Tabla comparativa
  10. Falsos positivos y falsos negativos

  1. Qué puede y qué no puede ver una máquina

Un analizador automático es un programa que recorre el árbol del DOM y aplica reglas deterministas: "todo <img> debe tener atributo alt", "un control de formulario debe tener nombre accesible", "este ratio de contraste es 2.9:1 y AA exige 4.5:1". Son comprobaciones binarias y objetivas, y ahí las máquinas son imbatibles: rápidas, incansables y sin criterio propio que las despiste.

El problema es todo lo que requiere juicio humano:

Lo que SÍ detecta una máquina Lo que NO puede detectar
Falta el atributo alt Si el alt describe bien la imagen ("foto profesor" vs "IMG_2043")
Contraste de color por debajo del umbral Si el orden de foco es lógico para la tarea
Un <label> sin for asociado Si el nombre del botón tiene sentido en contexto
aria-* con valores inválidos o rol inexistente Si un mensaje de error se anuncia al aparecer
Encabezados que saltan de nivel (h1→h3) Si la página es usable de verdad con NVDA
Idioma de página ausente (<html lang>) Si un icono comunica algo que el texto no dice

Regla mental: la máquina te dice que el alt existe; solo un humano sabe si el alt es bueno. Por eso el 30-40%: casi todo lo cualitativo se le escapa.

  1. axe-core y axe DevTools (la extensión)

axe-core (de Deque) es el motor de reglas de accesibilidad más usado del mundo: es open source y está dentro de casi todo lo demás (Lighthouse, Accessibility Insights, muchos tests). Aprender axe es aprender el vocabulario común del sector.

La forma más rápida de empezar es la extensión axe DevTools para Chrome/Firefox/Edge:

  1. Instala la extensión y abre el catálogo de Cursalia.
  2. DevTools → pestaña axe DevTools → Scan all of my page.
  3. Lee la lista de Issues agrupada por severidad.

Leer una violación en el catálogo

Supón que axe reporta esto sobre las tarjetas de curso:

VIOLACIÓN: Buttons must have discernible text  (crítico)
Regla: button-name
Criterio WCAG: 4.1.2 Name, Role, Value (Nivel A)
Elemento: <button class="fav-btn"><i class="bi bi-heart"></i></button>
Cómo arreglar: el botón no tiene texto ni aria-label; añade un
nombre accesible ("Añadir a favoritos").

Cómo se lee una violación de axe, campo a campo:

  • Regla (button-name): el identificador técnico; útil para buscar documentación y para silenciar falsos positivos.
  • Criterio WCAG (4.1.2, nivel A): te dice qué estándar incumples y con qué prioridad.
  • Elemento: el selector exacto en el DOM. Es el icono de corazón "favorito" sin texto — justo el fallo "botones sin nombre accesible" que anticipábamos en 06-01.
  • Impacto (crítico/serio/moderado/menor): la pista de priorización que exprimiremos en 06-04.
  • Cómo arreglar: la recomendación. El cómo real (dar nombre accesible a un icono) lo viste en el Módulo 4.

  1. WAVE

WAVE (de WebAIM) es una extensión que muestra los resultados superpuestos sobre la propia página con iconos: errores en rojo, alertas en amarillo, elementos estructurales, ARIA. Es especialmente didáctica porque ves dónde está cada problema sin leer selectores.

En la ficha de curso de Cursalia, WAVE es excelente para detectar de un vistazo: encabezados fuera de orden, imágenes sin alt, enlaces vacíos, contraste insuficiente y regiones/landmarks. Su vista de Structure/Order ayuda a ver la jerarquía de encabezados de un golpe. Detalle importante: los iconos amarillos son alertas, no errores — cosas que quizá estén mal y que un humano debe revisar. WAVE es honesto avisando de que no está seguro.

  1. Lighthouse en Chrome DevTools

Lighthouse viene integrado en Chrome (DevTools → pestaña Lighthouse → marca Accessibility → Analyze). Da una puntuación de 0 a 100 y usa axe-core por debajo.

Ventaja: es cero fricción, ya lo tienes. Trampa peligrosísima: la puntuación engaña. Un "95/100" en Cursalia no significa "95% accesible"; significa "el 95% de las comprobaciones automáticas pasan", y esas comprobaciones son solo ese 30-40% del total. Puedes tener 100/100 y una página inusable con lector de pantalla. Usa Lighthouse para una foto rápida y para vigilar regresiones, nunca como certificado de accesibilidad.

  1. Pa11y (línea de comandos)

Pa11y es un analizador que corre desde la terminal, sin abrir un navegador a mano. Eso lo hace ideal para automatizar y para meterlo en scripts.

# Instalación global
npm install -g pa11y

# Analizar una página del catálogo de Cursalia
pa11y https://cursalia.example/catalogo

# Elegir el estándar y formato JSON (para procesar después)
pa11y --standard WCAG2AA --reporter json https://cursalia.example/catalogo

Salida típica (resumida):

Results for URL: https://cursalia.example/catalogo

 • Error: This element has insufficient contrast at this
   conformance level (4.35:1; required 4.5:1).
   — WCAG2AA.Principle1.Guideline1_4.1_4_3.G18.Fail
   — (#precio-curso-python)

 • Error: Anchor element found with no link content.
   — WCAG2AA.Principle4...H91.A.NoContent
   — (.card-link)

Con Pa11y puedes, por ejemplo, escanear una lista de URLs de Cursalia en un bucle y fallar el proceso si aparece cualquier error — la base para el paso de CI de la sección 8.

  1. Accessibility Insights

Accessibility Insights (de Microsoft) también usa axe-core, pero añade dos cosas muy valiosas:

  • FastPass: un escaneo automático rápido (equivalente a axe) más una comprobación guiada de orden de tabulación que dibuja flechas numeradas sobre la página. Es un puente estupendo entre lo automático y lo manual de 06-01.
  • Assessment: una revisión guiada, criterio por criterio, que te lleva de la mano por las comprobaciones manuales que la máquina no puede hacer sola. Reconoce explícitamente que lo automático no basta y te obliga a poner el ojo humano.

  1. Linting en desarrollo: eslint-plugin-jsx-a11y

Las herramientas anteriores actúan sobre una página ya renderizada. El linting actúa antes: mientras escribes el código, en el editor. Para proyectos React/JSX, eslint-plugin-jsx-a11y marca problemas de accesibilidad en el código fuente.

// .eslintrc.js (extracto)
module.exports = {
  extends: ['plugin:jsx-a11y/recommended'],
  plugins: ['jsx-a11y'],
};

Ejemplo: si un desarrollador de Cursalia escribe la tarjeta de curso así...

// El linter avisa AL TECLEAR:
// "img elements must have an alt prop" (jsx-a11y/alt-text)
<img src={curso.portada} />

...ESLint lo subraya en rojo antes de guardar. Es el feedback más barato posible: cuesta cero corregir algo que aún no ha salido del editor. Limitación: solo ve patrones estáticos en el código (falta un alt, un onClick en un <div> sin rol), no el resultado renderizado ni el contraste real.

  1. Integración en CI: que nadie rompa lo arreglado

Arreglar un fallo una vez es fácil; que no vuelva es lo difícil. La solución es correr los análisis automáticos en integración continua (CI): en cada pull request, un robot escanea y bloquea la fusión si aparecen violaciones nuevas.

A alto nivel, un test automatizado con axe-core dentro de las pruebas (Jest + jsdom, o Playwright/Cypress en un navegador real) se ve así:

// Ejemplo conceptual con Playwright + @axe-core/playwright
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('el catálogo de Cursalia no tiene violaciones axe', async ({ page }) => {
  await page.goto('https://cursalia.example/catalogo');

  const resultados = await new AxeBuilder({ page }).analyze();

  // El test FALLA si hay cualquier violación
  expect(resultados.violations).toEqual([]);
});

En un pipeline (GitHub Actions, GitLab CI…) esto se ejecuta solo en cada push. Muchos equipos empiezan de forma pragmática: no bloquean por todo, sino por violaciones críticas y serias, y toleran temporalmente las moderadas mientras las van saldando. Lo mismo se logra con Pa11y en modo CI (pa11y-ci).

  1. Tabla comparativa

Herramienta Tipo Qué detecta bien Límites Dónde encaja en el flujo
axe DevTools Extensión navegador Base amplia de reglas WCAG, muy pocos falsos positivos Solo lo automático; no juzga sentido/usabilidad Revisión ad-hoc en el navegador
WAVE Extensión navegador Muy visual; estructura, encabezados, contraste Menos integrable; alertas requieren criterio humano Aprender y revisar visualmente
Lighthouse En Chrome DevTools Foto rápida con puntuación; usa axe La puntuación engaña; cobertura parcial Vistazo rápido / vigilar regresiones
Pa11y CLI Automatizable, múltiples URLs, salida JSON Sin interfaz visual; configuración inicial Scripts y CI
Accessibility Insights Extensión + guía FastPass + orden de tabulación + revisión guiada La parte de assessment es manual Puente automático↔manual
eslint-plugin-jsx-a11y Linter (código) Errores en JSX al escribir Solo estático; no ve render ni contraste Mientras se programa
axe-core en CI Test automatizado Impide regresiones en cada PR Cobertura del ~30-40%; requiere montaje Puerta de calidad en el pipeline

Combinación recomendada para Cursalia: jsx-a11y mientras se programa, axe-core en CI para no regresar, axe DevTools/WAVE para revisiones puntuales, y siempre encima lo manual (06-01) y los usuarios (06-03).

  1. Falsos positivos y falsos negativos

Ninguna herramienta acierta el 100%:

  • Falso positivo: la herramienta marca un error que no lo es. Ejemplo clásico: WAVE avisa de "contraste bajo" en un texto que en realidad está oculto o sobre una imagen decorativa; o axe marca un aria que es correcto en tu contexto. Se pueden silenciar por regla y selector, pero documenta por qué — un silenciamiento sin justificar es deuda oculta.
  • Falso negativo (el peligroso): la herramienta dice "todo OK" y hay un problema real que no sabe detectar. Un alt="imagen" genérico pasa el análisis (existe el atributo) pero es inútil para Marta. Un orden de foco absurdo pasa. Un mensaje de error que no se anuncia pasa. El verde de la herramienta no es un aprobado.

Por eso el flujo sano es: automático para lo objetivo y repetible → manual (06-01) para el juicio → usuarios reales (06-03) para la usabilidad.

Errores Comunes y Consejos

  • Creerse la puntuación de Lighthouse: "tenemos 98, estamos accesibles" es falso. Cubre solo lo automático. Nunca lo pongas en marketing como sello de accesibilidad.
  • Escanear solo la home: el modal de matrícula, el cuestionario y el reproductor solo aparecen tras interactuar. Muchas herramientas analizan el estado inicial; abre el modal antes de escanear o usa tests que interactúen (Playwright).
  • Ignorar las alertas amarillas: en WAVE/axe, "necesita revisión" no es "aprobado". Es precisamente donde hace falta el ojo humano.
  • Silenciar sin documentar: cada regla desactivada debe llevar comentario y motivo, o se convierte en agujero permanente.
  • No poner nada en CI: sin puerta automática, lo que arreglas hoy alguien lo rompe la semana que viene. Al menos bloquea críticos y serios.
  • Consejo: usa varias herramientas; cada una tiene un catálogo de reglas ligeramente distinto y juntas cubren más.

Ejercicios

Ejercicio 1. Corres Lighthouse en la ficha de curso de Cursalia y da 100/100 en accesibilidad. Tu jefe quiere anunciar "web 100% accesible". ¿Qué le explicas, y qué dos tipos de prueba faltan antes de afirmar eso?

Ejercicio 2. axe reporta en el catálogo: image-alt (crítico), elemento <img src="portada-python.webp">, WCAG 1.1.1 (A). Un compañero lo "arregla" poniendo alt="imagen" y el análisis pasa a verde. ¿Por qué esto es un falso negativo y a qué persona sigue perjudicando?

Ejercicio 3. Diseña la estrategia automática mínima para el equipo de Cursalia usando tres capas (durante el desarrollo, en cada PR y en revisión puntual). Nombra una herramienta por capa y qué haría cada una.

Soluciones

Solución 1. Le explicas que Lighthouse solo ejecuta las comprobaciones automáticas, que cubren aproximadamente un 30-40% de los criterios; el 100 significa "pasan las comprobaciones automáticas", no "la web es accesible". Faltan como mínimo las pruebas manuales (teclado + lector de pantalla + zoom, lección 06-01) y las pruebas con usuarios reales de tecnologías de asistencia (06-03). Afirmar "100% accesible" sin ellas es incorrecto y arriesgado (incluso legalmente).

Solución 2. Es un falso negativo porque la herramienta comprueba que existe el atributo alt, no que su contenido tenga sentido. alt="imagen" satisface la regla pero no aporta información: NVDA leerá "imagen" y Marta seguirá sin saber qué curso es. La máquina no puede juzgar la calidad del texto alternativo; eso se valida a mano (06-01) y se decidió con el árbol de decisión del alt del Módulo 5.

Solución 3. Ejemplo: (1) Durante el desarrollo → eslint-plugin-jsx-a11y, que avisa en el editor de imágenes sin alt o div clicables. (2) En cada PR → un test con axe-core en Playwright que falla el build ante violaciones críticas/serias, evitando regresiones. (3) Revisión puntual → axe DevTools o WAVE en el navegador antes de una release grande, incluyendo estados como el modal abierto. Y por encima de las tres, lo manual y los usuarios.

Conclusión

Las herramientas automatizadas son tu multiplicador de fuerza: rápidas, objetivas, integrables en CI y perfectas para que ningún fallo objetivo regrese. Pero tienen un techo duro —ese 30-40%— y un peligro sutil: el verde de un panel puede darte una falsa sensación de seguridad. Ni el alt con sentido, ni el orden de foco lógico, ni la usabilidad real con un lector de pantalla los ve una máquina. Eso solo lo validan las personas. En la siguiente lección, 06-03 Pruebas de Usuario con Tecnologías de Asistencia, damos el salto definitivo: sentar a Marta, Lucía y Sofía —usuarias reales— frente a Cursalia y descubrir los problemas que ni lo automático ni tu propia prueba manual llegaron a ver.

◄ Anterior
◄
Siguiente ►
►
El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia
© Copyright 2026. Todos los derechos reservados