Tu score de accesibilidad te está mintiendo

¿Por qué seguimos tratando la accesibilidad como si fuera un test que se aprueba? Llevamos años construyendo herramientas que miden lo que pueden medir automáticamente, y mientras tanto asumimos que eso es suficiente. Algo está fundamentalmente roto en cómo la industria entiende esto.

Hace tres semanas corrí Lighthouse y axe-core contra juanchi.dev. 98/100. Verde. Hermoso. Me sentí bien conmigo mismo durante exactamente cuatro días.

Después le pedí a Martín — un amigo que usa NVDA todos los días para navegar — que me diera feedback real de la página. Me mandó un audio de 8 minutos. No llegué al minuto tres sin querer cerrar la computadora.

Accesibilidad web real: lo que Lighthouse no puede ver

Lighthouse y axe-core son herramientas brillantes. No estoy en contra de ellas. El problema es que detectan lo que es verificable automáticamente: contraste de colores, atributos alt presentes, labels en formularios, orden de headings. Eso cubre aproximadamente el 30-40% de los problemas reales de accesibilidad.

El otro 60% requiere un humano.

Esto no es mi opinión. Es lo que dice WebAIM en sus estudios de auditoría manual versus automática. Las herramientas automáticas no pueden saber si tu aria-label tiene sentido en contexto, si el flujo de navegación por teclado es confuso, o si tus anuncios de estado dinámico están llegando en el momento correcto.

Lo que Martín encontró en juanchi.dev en menos de 10 minutos:

1. El menú de navegación anunciaba mal su estado. Tenía aria-expanded correctamente seteado pero el label del botón no cambiaba. NVDA leía "abrir menú" incluso con el menú abierto.
2. Los skip links estaban ahí... pero no funcionaban en la práctica. El link de "saltar al contenido" existía, pasaba la validación automática, pero el foco después del skip iba al contenedor en lugar del primer elemento interactivo. Resultado: Tab inmediato después del skip te tiraba de vuelta al header.
3. Las animaciones CSS estaban desactivables vía prefers-reduced-motion — eso sí lo tenía bien — pero había un carousel de proyectos que cambiaba contenido automáticamente cada 5 segundos y eso NVDA lo leía como ruido constante.
4. Los íconos SVG inline tenían aria-hidden="true" como mandan los cánones, pero en un caso puntual era el único indicador visual de un estado de error. Para un usuario de lector de pantalla: invisible.

Ninguno de esos cuatro problemas aparecía en el reporte de axe. El score seguía siendo 98/100 con todos ellos presentes.

El código que me estaba fallando (y cómo lo arreglé)

Empecemos por el caso del menú. Este era mi componente original:

// ❌ Versión rota — pasa Lighthouse igual
function NavMenu() {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <nav>
      <button
        aria-expanded={isOpen}
        aria-controls="nav-list"
        onClick={() => setIsOpen(!isOpen)}
      >
        {/* El ícono cambia visualmente, pero el label no */}
        <MenuIcon />
      </button>

      <ul id="nav-list" hidden={!isOpen}>
        {/* items */}
      </ul>
    </nav>
  );
}

El aria-expanded estaba. axe lo verificaba, pasaba. Pero NVDA leía "botón" cuando hacías focus en él, sin ningún contexto. El label era el ícono SVG con aria-hidden. Técnicamente correcto según las reglas automáticas. En la práctica: inútil.

// ✅ Versión que realmente funciona
function NavMenu() {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <nav aria-label="Navegación principal">
      <button
        aria-expanded={isOpen}
        aria-controls="nav-list"
        // El label cambia con el estado — el lector lo anuncia
        aria-label={isOpen ? "Cerrar menú de navegación" : "Abrir menú de navegación"}
        onClick={() => setIsOpen(!isOpen)}
      >
        {/* Ícono puramente decorativo ahora */}
        <MenuIcon aria-hidden="true" />
      </button>

      <ul
        id="nav-list"
        hidden={!isOpen}
        // El rol ayuda a contextualizar la lista cuando se anuncia
        role="list"
      >
        {/* items */}
      </ul>
    </nav>
  );
}

El skip link era más interesante. El problema no era el link en sí, era el target:

// ❌ El foco va al div, que no es focusable de forma útil
<a href="#main-content" className="skip-link">
  Saltar al contenido principal
</a>

<div id="main-content">
  <h1>Título</h1>
  <p>Primer párrafo...</p>
</div>

Cuando tab llega al skip link, lo activás, el foco va a #main-content. Pero div no retiene el foco de manera que Tab después continúe dentro del div — depende del browser. En algunos casos, Tab siguiente saltaba de vuelta al inicio del documento.

// ✅ tabIndex="-1" permite recibir foco programático
// sin meterlo en el orden natural de tabulación
<a href="#main-content" className="skip-link">
  Saltar al contenido principal
</a>

<main
  id="main-content"
  tabIndex={-1} // Clave: permite foco programático
  // Sin outline en focus porque el usuario no llegó aquí con Tab directamente
  className="focus:outline-none"
>
  <h1>Título</h1>
  <p>Primer párrafo...</p>
</main>

El carousel fue el fix más fácil pero el más importante conceptualmente:

// ❌ Autoplay sin control — una pesadilla para lectores de pantalla
function ProjectCarousel({ projects }) {
  const [current, setCurrent] = useState(0);

  useEffect(() => {
    // Cambia cada 5 segundos, interrumpiendo la lectura
    const timer = setInterval(() => {
      setCurrent(prev => (prev + 1) % projects.length);
    }, 5000);
    return () => clearInterval(timer);
  }, []);

  return <div>{projects[current]}</div>;
}

// ✅ Respeta preferencias del usuario y ofrece control
function ProjectCarousel({ projects }) {
  const [current, setCurrent] = useState(0);
  const [isPaused, setIsPaused] = useState(false);
  
  // Detecta si el usuario prefiere menos movimiento
  const prefersReducedMotion = useMediaQuery(
    "(prefers-reduced-motion: reduce)"
  );

  useEffect(() => {
    // No autoplay si el usuario lo pidió o si está pausado
    if (prefersReducedMotion || isPaused) return;

    const timer = setInterval(() => {
      setCurrent(prev => (prev + 1) % projects.length);
    }, 5000);
    return () => clearInterval(timer);
  }, [isPaused, prefersReducedMotion]);

  return (
    // aria-live="polite" anuncia cambios sin interrumpir
    <div
      aria-live="polite"
      aria-label={`Proyecto ${current + 1} de ${projects.length}`}
    >
      {/* Control visible de pausa — no solo para AT */}
      <button
        onClick={() => setIsPaused(!isPaused)}
        aria-label={isPaused ? "Reanudar rotación" : "Pausar rotación"}
      >
        {isPaused ? "▶" : "⏸"}
      </button>
      
      {projects[current]}
    </div>
  );
}

Los errores más comunes que los scores no detectan

Después de hablar con Martín y hacer la auditoría manual, mapeé los patrones que aparecen todo el tiempo en proyectos con scores perfectos.

aria-label que no tiene sentido fuera de contexto visual. Tenés un botón con aria-label="Ver más". Visualmente está claro por el contexto qué es "más". Para un lector de pantalla que lista todos los botones de la página: hay cinco botones que dicen "Ver más" y ninguno es distinguible. Solución: aria-label="Ver más proyectos de React", aria-label="Ver más sobre este cliente".

Focus management en modales y dialogs. Abrís un modal. El foco queda en el botón que lo abrió. El usuario de teclado tiene que tabular por todo el documento para llegar al contenido del modal. O peor: puede tabear afuera del modal mientras está abierto. Este es uno de los patrones ARIA más difíciles de implementar bien y que ninguna herramienta automática valida completamente.

Notificaciones de estado dinámico mal temporadas. Usás aria-live para anunciar que el formulario se envió. Pero el anuncio llega mientras NVDA todavía está leyendo el texto del botón de submit. El usuario escucha dos cosas a la vez y no entiende ninguna.

Imágenes decorativas con alt vacío... correcto. Pero SVGs inline sin rol definido. Este fue mi caso exacto. <img alt=""> pasa la validación. Un <svg> inline que es puramente decorativo necesita explícitamente aria-hidden="true", y si tiene texto o comunica información, necesita un título o aria-label. axe no siempre detecta el caso incorrecto.

Me pasó algo similar cuando construí la extensión de HAProxy para VS Code — el panel de configuración tenía tooltips que sólo eran visibles por hover, sin equivalente para teclado. Pasó toda la validación automática. Era completamente inasequible.

Cómo armar una estrategia de accesibilidad que no sea teatro

No estoy diciendo que tires los scores. Sirven como primera línea. Lo que estoy diciendo es que son el piso, no el techo.

Mi setup actual después de este episodio:

Nivel 1 — Automático (en CI): axe-core via jest-axe en componentes críticos, Lighthouse en las páginas principales. Si algo baja de 95, el build falla.

Nivel 2 — Manual periódico: Una vez por sprint, navego con teclado solamente todas las features nuevas. Sin mouse, sin trackpad. Tab, Shift+Tab, Enter, Espacio, flechas. Si no puedo completar un flujo solo con teclado en tiempo razonable, hay un bug.

Nivel 3 — Lector de pantalla real: Instalo NVDA en una VM con Windows (es gratuito, VoiceOver en Mac también sirve pero tiene diferencias importantes) y navego el sitio. Mínimo una vez por release importante.

Nivel 4 — Usuarios reales: Difícil de escalar, pero es el único nivel que no tiene punto ciego. Martín me dio más feedback accionable en 8 minutos que tres horas de análisis automático.

Es el mismo principio que aplico al vibe coding versus stress coding — las herramientas automáticas te dan velocidad, pero en los momentos que importan necesitás validación humana real. Un LLM te puede generar componentes accesibles con los patrones ARIA correctos, pero no puede decirte si la experiencia como un todo tiene sentido.

Si te interesa la parte de infraestructura de cómo automatizo estas validaciones, en el post sobre cómo Linux ejecuta un binario hablo de por qué entender las capas debajo de tu abstracción favorita cambia cómo debuggeás — es el mismo principio acá: entender que Lighthouse es una capa de abstracción sobre WCAG, que WCAG es una capa de abstracción sobre experiencia real.

FAQ: accesibilidad web real

¿Cuánto porcentaje de problemas de accesibilidad detecta Lighthouse automáticamente? Estudios de WebAIM y Deque (los que hacen axe) coinciden en que las herramientas automáticas detectan entre el 30% y el 40% de los problemas reales. El resto requiere evaluación humana. El porcentaje varía según el tipo de sitio y la complejidad de las interacciones.

¿Cuál es la diferencia entre axe y Lighthouse para testear accesibilidad? Lighthouse usa axe-core por debajo para sus auditorías de accesibilidad, así que en muchos puntos miden lo mismo. La diferencia práctica: axe-core integrado en tus tests (via jest-axe o cypress-axe) te da feedback durante desarrollo y puede testear estados de componentes individuales. Lighthouse analiza la página renderizada completa y te da un score global. Usá los dos: axe en unit/integration tests, Lighthouse como check de página entera.

¿WCAG 2.1 AA es suficiente o tengo que apuntar a AAA? Para la mayoría de los proyectos web comerciales, WCAG 2.1 AA es el target correcto. AAA incluye criterios que en algunos casos son imposibles de cumplir sin sacrificar funcionalidad (por ejemplo, el criterio de contraste AAA para texto normal es 7:1, lo que limita mucho las paletas de colores). Apuntá a AA como mínimo legal y de buenas prácticas. Implementá criterios AAA donde sea razonable sin fricción extra.

¿Next.js tiene ventajas específicas para accesibilidad? Sí, algunas concretas. El componente <Link> maneja el anuncio de cambios de página para lectores de pantalla mejor que una SPA vanilla. El router de App Directory con Server Components reduce el JavaScript necesario en el cliente, lo que puede mejorar el rendimiento en dispositivos de bajo costo (un factor real para usuarios con tecnología asistiva). Y next/image con el atributo alt requerido previene uno de los errores más comunes. Pero ninguna de esas ventajas te salva de errores en tus propios componentes.

¿Cómo testeo accesibilidad con NVDA si solo tengo Mac? Tres opciones. Primera: VoiceOver en Mac (Cmd+F5) — no es idéntico a NVDA pero cubre la mayoría de los casos. Segunda: una VM con Windows y NVDA gratuito, que es lo que yo hago para validaciones importantes. Tercera: usar el servicio de BrowserStack que tiene testing con lectores de pantalla reales incluido en algunos planes. Para proyectos críticos, la VM de Windows vale el setup time.

¿El SEO y la accesibilidad están relacionados? Más de lo que parece. Los crawlers de Google son efectivamente usuarios no visuales — procesan el DOM de manera similar a como lo hace un lector de pantalla. Texto alternativo en imágenes, jerarquía de headings semántica, links descriptivos en lugar de "click aquí", estructura HTML significativa: todo eso beneficia tanto al SEO como a la accesibilidad. No son lo mismo, pero hay un overlap muy grande en las mejores prácticas. Cuando hice el análisis de codebase con IA de juanchi.dev, uno de los patrones que salió fue exactamente ese overlap entre estructura semántica y performance de indexación.

Lo que aprendí y no me esperaba

El score de 98/100 no era mentira. Era incompleto. Hay una diferencia importante.

Lighthouse y axe miden lo que pueden medir. Son honestas dentro de sus límites. El problema es que los usamos como si fueran completos cuando son parciales. Eso sí es un error nuestro, no de las herramientas.

Lo que más me afectó del audio de Martín no fue encontrar los bugs — eso era esperable y arreglable. Fue darme cuenta de que yo había publicado el sitio sintiéndome bien con la accesibilidad. Había marcado la casilla. Y la casilla no representaba la experiencia real de nadie.

En tecnología nos encanta reducir cosas complejas a números. Uptime en 99.9%. Performance score 100/100. Accesibilidad 98/100. Los números son útiles como proxies. Pero cuando un proxy se convierte en el objetivo en sí mismo, perdemos de vista lo que el número representaba originalmente.

Tengo pendiente hacer la misma revisión de accesibilidad para los proyectos de clientes. Ya sé lo que voy a encontrar y ya sé que va a dar trabajo. Pero ahora sé también que el trabajo vale la pena — y que el score verde en el CI no me exime de hacerlo.

Si tenés un proyecto con score alto y nunca lo testeaste con un lector de pantalla real: te propongo el challenge. Abrí NVDA o VoiceOver, cerrá los ojos, y navegá tu propio producto. Diez minutos. Lo que encuentres va a cambiar cómo pensás esto para siempre.