accessibility

Errores de accesibilidad de Lighthouse

Cuenta las auditorías concretas de accesibilidad que Lighthouse marca. La lista de alto impacto — la mayoría se arreglan con una línea de markup o CSS.

Qué comprueba esta verificación

Cuenta cuántas auditorías de accesibilidad de Lighthouse han fallado en la página. Lighthouse ejecuta axe-core por debajo y agrupa los resultados en pass/fail/manual. Esta regla reporta el número de fail y los lista — la puntuación de accesibilidad de Lighthouse es el titular, esta regla es la lista de tareas.

Infractores típicos que MetricSpot suele detectar:

  • color-contrast — texto por debajo del ratio de contraste 4.5:1 AA.
  • image-alt<img> sin alt (distinto de calidad del texto alternativo, que puntúa lo significativo del texto).
  • link-name / button-name — elementos interactivos sin nombre accesible (los botones solo con icono son los culpables habituales).
  • label — controles de formulario sin un <label> asociado.
  • html-has-lang / html-lang-valid — cubierto por declarar el idioma de la página.
  • document-title<title> vacío o ausente.
  • aria-* — roles inválidos, atributos requeridos ausentes o aria-hidden sobre elementos enfocables.
  • list / listitem<li> fuera de un padre <ul>/<ol>.

Por qué importa

Los errores de Lighthouse son la mitad arreglable de la accesibilidad. Cada auditoría de esta lista es algo que un agente de build puede verificar de forma mecánica — sin juicio humano. También son las auditorías que con más frecuencia aparecen en una demanda legal: el contraste y la falta de etiquetas de formulario son los dos problemas más citados en demandas ADA de accesibilidad web en EE. UU., y la Ley de Accesibilidad de la UE (en vigor desde junio de 2025) lee la misma lista.

Llevar este recuento a cero no convertirá al sitio en plenamente conforme con WCAG — alrededor de un tercio de los criterios WCAG 2.1 AA requieren revisión manual — pero elimina las objeciones de menor esfuerzo.

Cómo arreglarlo

Lee los fallos en orden. Cada error de Lighthouse incluye un fragmento de “Failing elements” — ese es tu punto de partida.

Ver la lista por auditoría:

  • Lighthouse CLI / DevTools — ejecuta una auditoría, baja hasta “Accessibility” y haz clic en cada entrada roja para ver la lista de elementos que fallan.
  • PageSpeed Insightspagespeed.web.dev/?url=<tu-url> devuelve las mismas auditorías con selectores de elemento.
  • DevTools → panel Issues — Chrome 109+ muestra los problemas de axe-core en vivo mientras navegas.

Intégralo en CI. No confíes en que un humano abra Lighthouse. Añade axe-core a tu suite e2e:

bun add -D @axe-core/playwright axe-playwright
// e2e/a11y.spec.ts
import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("home has no detectable a11y violations", async ({ page }) => {
  await page.goto("/");
  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag21aa"])
    .analyze();
  expect(results.violations).toEqual([]);
});

Para builds con React/Next/Astro, añade además eslint-plugin-jsx-a11y para capturar los obvios en tiempo de lint.

Los 5 arreglos de una línea más comunes:

FalloArreglo
color-contrastSube el primer plano o el fondo hasta que el ratio supere 4.5:1 (3:1 para texto 18 pt o más). Usa el selector de color de DevTools — muestra el ratio en vivo.
image-altAñade alt="...". Para imágenes puramente decorativas, usa alt="" (vacío, no ausente). Ver alt-text de imágenes.
button-nameLos <button> solo con icono necesitan aria-label="Cerrar menú". Los iconos SVG dentro necesitan aria-hidden="true".
link-nameIgual que los botones. Envuelve los enlaces con icono en texto descriptivo o aria-label. Ver texto descriptivo de enlaces.
labelEnvuelve el <input> en <label>, o usa <label for="id"> + id="id". Ver etiquetas de formulario.

Si la puntuación es n/a en lugar de un número, mira accesibilidad de Lighthouse no disponible — la auditoría no se ejecutó.

Preguntas frecuentes

¿Arreglar cada fallo me llevará al 100?

Normalmente te quedarás en los 90 altos. La puntuación de accesibilidad de Lighthouse está ponderada, pero no es lineal — color-contrast pesa mucho, otros pesan poco. Los puntos restantes suelen venir de comprobaciones manuales (orden de foco, narración del lector de pantalla) que la auditoría automática lista como “Additional items to manually check”.

¿Puedo silenciar auditorías con las que no estoy de acuerdo?

Sí, a través del array skipAudits de la configuración de Lighthouse, pero piénsalo bien antes de silenciar. El falso positivo habitual es color-contrast sobre banners hero con texto encima de imagen — arregla el contraste (añade una capa o un fondo sólido) en lugar de saltarte la auditoría.

¿En qué se diferencia esto de axe-core en DevTools?

En realidad, en poco. Lighthouse incluye axe-core y ejecuta un subconjunto de sus reglas. La extensión axe de DevTools ejecuta el conjunto completo, así que ahí puedes ver más problemas — esos extras suelen estar etiquetados como best-practice y no son requeridos por WCAG.

Fuentes

Última actualización 2026-05-11