Cómo probar la accesibilidad web: herramientas automatizadas, pruebas manuales y lectores de pantalla

Los números son difíciles de ignorar. Según el informe WebAIM Million 2026, los análisis automatizados de un millón de páginas de inicio detectaron más de 56 millones de errores de accesibilidad distintos, un promedio de 56.1 errores por página, un aumento de más del 10% con respecto al año anterior. Y dado que las herramientas automatizadas solo pueden detectar aproximadamente el 30–40% de las posibles infracciones de las WCAG, la verdadera magnitud del problema es significativamente mayor. Si tu estrategia de pruebas de accesibilidad empieza y termina con un único análisis mediante una extensión de navegador, solo estás viendo una fracción de las barreras a las que se enfrentan tus usuarios cada día.

Por qué una estrategia de pruebas en múltiples capas no es negociable

Las pruebas de accesibilidad web no son un evento único: son una disciplina que abarca herramientas, juicio humano y experiencia vivida. Las Pautas de Accesibilidad para el Contenido Web (WCAG) se basan en cuatro principios fundamentales, comúnmente llamados POUR: el contenido debe ser Perceptible, Operable, Comprensible y Robusto. Las herramientas automatizadas pueden verificar que una imagen tenga un atributo alt, pero no pueden juzgar si ese texto alternativo realmente describe la imagen de manera significativa. Un script puede confirmar que un botón tiene una etiqueta, pero no puede decirte si una persona usuaria de lector de pantalla entendería qué hace al pulsarlo en contexto.

Por eso todo programa serio de accesibilidad superpone tres enfoques distintos: análisis automatizado para detectar infracciones sistémicas y repetibles a escala; pruebas manuales para evaluar criterios dependientes del juicio que requieren un cerebro humano; y pruebas con tecnologías de asistencia —especialmente lectores de pantalla— para validar la experiencia real de las personas usuarias que dependen de estas herramientas a diario. Cada capa compensa los puntos ciegos de las demás. Omitir cualquiera de ellas deja brechas que eventualmente se manifestarán como quejas de usuarios, fallos en auditorías o exposición legal.

WCAG 2.2, el estándar actual del W3C a finales de 2023, pone mayor énfasis en la usabilidad para la navegación con teclado, las interacciones táctiles y la accesibilidad cognitiva, manteniendo todos los requisitos existentes de WCAG 2.1. Hacer pruebas con respecto a este estándar no es opcional para la mayoría de las organizaciones: cada vez está más exigido por la normativa, desde la ADA en Estados Unidos hasta la European Accessibility Act, que entró en vigor en junio de 2025. Entender cómo hacer pruebas es la base práctica que hace posible el cumplimiento.

Pruebas automatizadas: tu primera línea de defensa

Las herramientas automatizadas aceleran el proceso de pruebas e integran sin problemas en los pipelines de CI/CD, ayudando a los equipos a detectar y corregir errores de accesibilidad de forma temprana y frecuente. Es mejor entenderlas como un filtro: no detectarán todo, pero detectarán de forma fiable las infracciones más comunes y más medibles, y a una velocidad que ninguna persona revisora puede igualar. Piénsalas como un corrector ortográfico: esenciales, pero no un sustituto de una persona editora experta.

Las categorías más comunes de problemas que las herramientas automatizadas detectan de forma fiable incluyen texto alternativo ausente o vacío en imágenes, relaciones de contraste de color insuficientes, campos de formulario sin etiquetas asociadas, texto vacío en enlaces o botones, declaraciones de idioma de página ausentes y estructuras de encabezados duplicadas o faltantes. Según los datos de WebAIM Million, el 96.4% de los errores detectados se concentran en solo seis categorías, lo que significa que las herramientas automatizadas, aplicadas de forma consistente, pueden reducir sustancialmente tu número de infracciones antes de que cualquier persona revisora toque la interfaz.

Herramientas clave de pruebas automatizadas

axe-core / axe DevTools (Deque Systems) es, probablemente, el motor de pruebas de accesibilidad más adoptado en la industria. Su núcleo de código abierto está integrado en decenas de otras herramientas y frameworks de pruebas. La extensión de navegador funciona en Chrome, Firefox y Edge, y ofrece a las personas desarrolladoras retroalimentación instantánea sobre el DOM renderizado. Para los equipos de ingeniería, axe-core se integra con Cypress, Playwright, Selenium y Jest, lo que facilita incorporar comprobaciones de accesibilidad directamente en tu suite de pruebas existente.

WAVE (WebAIM) es una extensión de navegador y herramienta de evaluación en línea que proporciona retroalimentación visual, en la propia página, mediante iconos codificados por colores superpuestos directamente sobre tu contenido. Es especialmente adecuada para editores de contenido y personas interesadas no técnicas que necesitan entender los problemas de accesibilidad sin leer código. WAVE resalta errores, alertas, elementos estructurales y roles ARIA de una forma que hace que la relación entre el marcado y la experiencia de usuario sea inmediatamente visible.

Google Lighthouse está integrado directamente en Chrome DevTools y ejecuta auditorías de accesibilidad junto con comprobaciones de rendimiento, SEO y buenas prácticas. Es excelente para auditorías rápidas de front-end durante el desarrollo y puede ejecutarse desde la línea de comandos para su integración en CI. Su puntuación de accesibilidad está impulsada por axe-core internamente, por lo que cubre áreas superpuestas pero no idénticas.

Pa11y es una herramienta de línea de comandos y una biblioteca de Node.js diseñada para la integración en pipelines. Es compatible tanto con axe como con el motor HTML_CodeSniffer, puede probar múltiples URLs desde un archivo de configuración y genera informes legibles por máquina adecuados para paneles o sistemas de tickets. Es especialmente útil para monitorizar sitios grandes o para organizaciones que necesitan auditar URLs en bloque de forma programada.

Integrar axe en tu pipeline de CI/CD

La forma más eficaz de prevenir regresiones de accesibilidad es tratarlas como cualquier otro error: detectarlas antes de que lleguen a producción. Integrar axe-core en tu pipeline de CI significa que cada pull request se analiza automáticamente, y las compilaciones pueden configurarse para fallar cuando las infracciones superan los umbrales aceptables. Aquí tienes un ejemplo mínimo usando Playwright y el paquete @axe-core/playwright:

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

test.describe('Homepage accessibility', () => {
  test('should have no automatically detectable WCAG violations', async ({ page }) => {
    await page.goto('https://your-site.com/');
    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
      .analyze();
    expect(results.violations).toEqual([]);
  });
});

Esta prueba navega a tu aplicación, ejecuta axe-core sobre la página renderizada limitada a las reglas de WCAG 2.x de nivel A y AA, y falla si se devuelve alguna infracción. Puedes conectar esto a un flujo de trabajo de GitHub Actions para que se ejecute en cada push a main o en cada pull request. Ten en cuenta que, cuando añadas por primera vez pruebas automatizadas de accesibilidad a un proyecto maduro, es posible que descubras docenas de problemas preexistentes. En lugar de bloquear todas las implementaciones de inmediato, configura un recuento de infracciones de referencia y ve ajustando el umbral de forma incremental a medida que las soluciones.

Limitación importante: Las herramientas automatizadas detectan aproximadamente el 30–40% de las infracciones de las WCAG. Son necesarias pero no suficientes. Las pruebas manuales son imprescindibles para descubrir el alcance completo de las barreras de accesibilidad.

Pruebas manuales: lo que las máquinas no pueden juzgar

Las pruebas manuales cubren los vacíos que las herramientas automatizadas, por estructura, no pueden cubrir. Requieren que una persona evaluadora —idealmente alguien formado en las WCAG y familiarizado con las tecnologías de asistencia— recorra páginas e interacciones usando una metodología definida. El objetivo no es volver a verificar lo que el analizador automatizado ya encontró, sino evaluar los criterios que requieren juicio humano: ¿el orden de lectura es lógico? ¿La gestión del foco tiene sentido después de que se abra un modal? ¿El mensaje de error es realmente útil o solo dice "entrada no válida"?

Una sesión práctica de pruebas manuales cubre varias áreas distintas. La primera es la navegación solo con teclado. Desconecta el ratón y navega por toda tu interfaz usando solo Tab, Shift+Tab, Enter, Space y las teclas de flecha. Cada elemento interactivo —enlaces, botones, campos de formulario, menús desplegables, selectores de fecha, modales, pestañas— debe ser alcanzable y operable sin ratón. El foco nunca debe quedar atrapado (a menos que sea intencional, como en un modal que debe retener el foco). El indicador de foco visible debe ser lo suficientemente claro como para seguirlo. WCAG 2.2 añadió el Criterio de Conformidad 2.4.11 Apariencia del foco, que establece un tamaño mínimo y un requisito de contraste para los indicadores de foco; esto casi siempre es una comprobación manual.

La segunda área es la revisión de contenido y estructura. Lee la página con ojo crítico hacia la jerarquía de encabezados. Los encabezados deben reflejar el esquema de la página: <h1> para el título de la página, <h2> para secciones principales, <h3> para subsecciones, sin saltarse niveles. Verifica que el texto de los enlaces sea descriptivo por sí solo ("Descargar el Informe Anual 2025" es bueno; "haz clic aquí" no lo es). Comprueba que las imágenes con contenido significativo tengan un texto alternativo preciso y que las imágenes decorativas tengan atributos alt vacíos (alt=''). Revisa las etiquetas de los formularios: cada campo debe tener una etiqueta asociada de forma programática, no solo un placeholder.

La tercera área son las interacciones dinámicas y ARIA. Las interfaces con mucho JavaScript —aplicaciones de una sola página, modales, resultados de búsqueda en vivo, carruseles, acordeones— crean desafíos de accesibilidad que los analizadores estáticos pasan por alto con frecuencia. Cuando se abre un modal, ¿el foco se mueve dentro de él? Cuando se cierra, ¿el foco vuelve al elemento que lo activó? Cuando se actualiza una región en vivo (un recuento de resultados de búsqueda, un mensaje de validación de formulario), ¿se anuncia a las tecnologías de asistencia? El uso incorrecto de ARIA es una de las fuentes más comunes de regresiones de accesibilidad. Los datos de WebAIM Million muestran de forma consistente que las páginas que usan atributos ARIA promedian significativamente más errores que las que no los usan, no porque ARIA sea malo, sino porque se implementa incorrectamente con frecuencia.

Lista de comprobación práctica para pruebas manuales

• Navegación con teclado: Recorre con Tab cada elemento interactivo; confirma un orden lógico, ausencia de trampas de foco e indicadores de foco visibles que cumplan con WCAG 2.2 SC 2.4.11.
• Estructura de encabezados: Verifica una jerarquía lógica, sin saltos, usando una extensión de navegador como HeadingsMap o la barra de herramientas WAVE.
• Texto de enlaces y botones: Confirma que todos los elementos interactivos tengan nombres accesibles descriptivos y únicos, no "haz clic aquí" o "más información" repetidos docenas de veces.
• Accesibilidad de formularios: Comprueba que cada campo tenga una etiqueta explícita, que los mensajes de error sean específicos y estén asociados de forma programática, y que los campos obligatorios se indiquen de una forma que las tecnologías de asistencia puedan transmitir.
• Color y contraste: Revisa manualmente cualquier texto o componente de la interfaz que las herramientas automatizadas hayan marcado como incierto. Se encontró texto con bajo contraste en el 83.9% de las páginas de inicio en el informe WebAIM Million 2026: es el fallo de accesibilidad más común.
• Tamaño de los objetivos táctiles: WCAG 2.2 SC 2.5.8 exige que los objetivos interactivos tengan al menos 24×24 píxeles CSS (con una buena práctica recomendada de 44×44 píxeles). Revisa botones pequeños, enlaces solo con iconos y elementos de navegación móvil.
• Zoom y reflujo: Prueba con zoom del navegador al 200% y al 400%. El contenido debe refluír sin desplazamiento horizontal al 400% (WCAG SC 1.4.10).

Pruebas con lectores de pantalla: el proxy más cercano a la experiencia real de usuario

Las pruebas con lectores de pantalla son la parte más exigente de un programa de accesibilidad y también la más reveladora. Una persona usuaria de lector de pantalla experimenta una página web como un flujo lineal de texto e información semántica: el diseño visual es irrelevante. Los encabezados, puntos de referencia, listas, tablas, etiquetas de formularios y roles ARIA son el esqueleto de navegación. Si ese esqueleto está roto o falta, la página se vuelve inutilizable, independientemente de lo bien que supere las comprobaciones automatizadas.

Según la encuesta WebAIM Screen Reader User Survey realizada a finales de 2023 y principios de 2024, JAWS sigue siendo el lector de pantalla de escritorio principal más citado, con el 40.5% de las personas encuestadas, con NVDA muy cerca, con el 37.7%. VoiceOver tiene el 9.7% del mercado principal de escritorio, pero es, con diferencia, el lector de pantalla dominante en dispositivos móviles, con el 70.6% de las personas usuarias de lectores de pantalla móviles confiando en él. Esto significa que un programa de pruebas completo debería cubrir, como mínimo: NVDA con Chrome en Windows, JAWS con Chrome en Windows y VoiceOver con Safari en iOS.

Los principales lectores de pantalla de un vistazo

JAWS (Job Access With Speech), desarrollado por Freedom Scientific, ha sido el estándar de oro en entornos empresariales durante décadas. Ofrece una integración profunda con Microsoft Office, scripting avanzado para aplicaciones no estándar y descripción de imágenes impulsada por IA. JAWS requiere una licencia de pago (aproximadamente $1,000 para una licencia estándar, o $95/año para una suscripción doméstica), lo que lo hace menos accesible para pruebas ocasionales pero esencial para validar que los flujos de trabajo de nivel empresarial funcionen para personas usuarias profesionales de lectores de pantalla.

NVDA (NonVisual Desktop Access) es gratuito, de código abierto y de confianza para millones de personas. Su conjunto de funciones ha crecido hasta igualar a JAWS para la gran mayoría de las tareas web cotidianas, y su portabilidad —puede ejecutarse desde una unidad USB en cualquier máquina Windows— lo convierte en la opción práctica para la mayoría de los equipos de desarrollo que comienzan con pruebas de lectores de pantalla. NVDA con Chrome es la segunda combinación de lector de pantalla y navegador más común en el uso real.

VoiceOver viene integrado en todos los dispositivos macOS e iOS, sin necesidad de instalación. En escritorio, funciona mejor con Safari. En iPhone y iPad, es el lector de pantalla dominante por un amplio margen. Si tu sitio tiene un tráfico móvil significativo —y la mayoría lo tienen—, VoiceOver en iOS es una parte obligatoria de tu matriz de pruebas. Su modelo de navegación basado en gestos en pantallas táctiles es significativamente diferente de la navegación con teclado en escritorio, lo que significa que los problemas de accesibilidad específicos de móvil solo pueden encontrarse probando en un dispositivo iOS real.

TalkBack es el lector de pantalla de Google para Android y lo utiliza aproximadamente el 35% de las personas usuarias de lectores de pantalla móviles. Si tu audiencia incluye personas usuarias de Android, las pruebas con TalkBack deberían formar parte de tu programa de accesibilidad móvil.

Cómo realizar una prueba eficaz con lector de pantalla

Empieza apagando el monitor o cerrando los ojos. El objetivo es simular la experiencia de alguien que no puede ver la pantalla. Navega por la página usando solo los comandos del lector de pantalla. Para NVDA y JAWS, los patrones de navegación más importantes que debes ejercitar son: leer la página de forma lineal con las teclas de flecha o el comando de lectura continua; saltar entre encabezados usando H; navegar por puntos de referencia usando D (NVDA) o ; (JAWS) para saltar entre las regiones main, navigation y footer; desplazarte con Tab solo por los elementos interactivos; y usar el modo formularios para interactuar con los campos de entrada.

A medida que navegas, pregúntate: ¿el orden de lectura es lógico? ¿El título de la página tiene sentido cuando se anuncia? ¿Las imágenes se describen de forma significativa o el lector de pantalla anuncia "imagen" sin contexto? ¿Los campos de formulario anuncian su etiqueta, tipo y valor actual? Cuando envías un formulario con errores, ¿se anuncian los mensajes de error y son fáciles de localizar? Cuando se actualiza contenido dinámico —un banner de notificación, un estado de carga, un recuento de resultados de búsqueda—, ¿se anuncia la actualización sin que la persona usuaria tenga que volver a navegar para encontrarla?

Los lectores de pantalla permiten a las personas usuarias interactuar en diferentes modos —modo lectura, modo formularios y modo aplicación— y pueden producir resultados muy diferentes en cada uno. Un elemento que funciona correctamente en un modo puede fallar silenciosamente en otro. Prueba siempre la misma interacción en múltiples modos de navegación.

Una de las fallas más comunes y más perjudiciales en las aplicaciones web modernas es la gestión rota del foco. Cuando se abre un cuadro de diálogo modal, el foco debe moverse dentro de él; cuando se cierra, el foco debe volver al elemento que lo activó. Cuando una aplicación de una sola página transiciona a una nueva vista, el título de la página y el encabezado principal deben anunciarse. Cuando se produce un error durante el envío de un formulario, el foco debe moverse al resumen de errores o al primer campo no válido. Estos patrones no pueden validarse con ninguna herramienta automatizada: requieren una persona evaluadora con un lector de pantalla abierto.

Construir un programa de pruebas de accesibilidad duradero

El error más común que cometen las organizaciones es tratar las pruebas de accesibilidad como una auditoría única. Un sitio que hoy cumple desarrollará nuevas infracciones mañana a medida que se publique contenido, se lancen funcionalidades y se actualicen scripts de terceros. La accesibilidad debe integrarse en el ciclo de desarrollo como una práctica continua, no como una casilla periódica que marcar.

Un programa sostenible tiene tres capas funcionando en paralelo. La capa automatizada se ejecuta en cada commit de código, detectando regresiones antes de que lleguen a producción. La capa manual se ejecuta en cada sprint a medida que se desarrollan nuevas funcionalidades, no como una puerta al final, sino como una comprobación durante el desarrollo. La capa de tecnologías de asistencia se ejecuta como parte de las pruebas de aceptación de cualquier funcionalidad que implique patrones de interacción significativos: formularios, cambios de navegación, modales, contenido dinámico y flujos de usuario. Para la mayoría de los equipos, eso significa al menos NVDA con Chrome y VoiceOver en iOS.

La priorización importa. Si tu auditoría revela cincuenta problemas, no todos tienen el mismo peso. Las infracciones de las WCAG se clasifican por impacto: los problemas críticos que hacen que el contenido sea completamente inaccesible para algunas personas deben solucionarse antes que los problemas graves, que a su vez tienen prioridad sobre los moderados y menores. Concéntrate primero en los patrones que afectan a tipos de página completos: si tu navegación está rota para las personas usuarias de teclado, corrige la plantilla de navegación y la corregirás en todas partes a la vez. Si la gestión de errores de tus formularios es inaccesible, corregir el patrón corrige todos los formularios.

La documentación no es opcional para las personas responsables de cumplimiento. Mantén un registro de pruebas de accesibilidad que documente qué páginas se probaron, qué herramientas y tecnologías de asistencia se utilizaron, qué infracciones se encontraron y qué remediación se aplicó y cuándo. Esta documentación se vuelve inestimable durante auditorías de accesibilidad o procesos legales, ya que demuestra un esfuerzo continuo y de buena fe para lograr y mantener la conformidad.

El papel de los widgets de overlay en tu estrategia de pruebas

Los widgets de overlay de accesibilidad, como el SDK de Accsible, desempeñan un papel significativo en una estrategia de accesibilidad en capas, especialmente para organizaciones que necesitan proporcionar mejoras inmediatas al contenido existente mientras se lleva a cabo un trabajo de remediación más profundo. Un overlay bien implementado puede poner a disposición de las personas usuarias herramientas de asistencia, como aumento de texto, ajuste de contraste y mejoras en la navegación con teclado, que abordan barreras comunes sin requerir una reconstrucción completa del sitio.

Sin embargo, los overlays no son un sustituto de las pruebas. Complementan un programa de pruebas en lugar de reemplazarlo. El enfoque más eficaz es usar un overlay para abordar los problemas superficiales, de la capa de presentación, que pueden manejarse de forma programática, mientras se utilizan el análisis automatizado, las pruebas manuales y la validación con lectores de pantalla para identificar y remediar los problemas estructurales —semántica rota, roles ARIA faltantes, widgets personalizados inaccesibles— que requieren correcciones a nivel de código. Los overlays funcionan mejor cuando la base de código subyacente ha sido probada y las brechas restantes se sitúan en el terreno de las preferencias de usuario más que en barreras fundamentales de interacción.

Al evaluar cualquier herramienta de accesibilidad, overlay o no, pregúntate si se ha probado con lectores de pantalla reales. Un widget que crea una barra de herramientas de accesibilidad visible pero introduce trampas de foco o conflictos ARIA en la página ha empeorado las cosas, no las ha mejorado. Las metodologías de prueba de esta guía se aplican a las propias herramientas de accesibilidad, no solo a los sitios en los que se ejecutan.

Conclusiones clave

• Ninguna herramienta por sí sola es suficiente. Los analizadores automatizados detectan solo el 30–40% de las infracciones de las WCAG. Un programa completo requiere pruebas automatizadas, revisión manual y pruebas reales con tecnologías de asistencia trabajando juntas como capas complementarias.
• Desplaza la accesibilidad hacia la izquierda. Integrar axe-core o Pa11y en tu pipeline de CI/CD significa que las infracciones se detectan antes de que lleguen a producción, donde solucionarlas cuesta exponencialmente más en tiempo, reputación y riesgo legal.
• Haz pruebas con los lectores de pantalla que tus usuarios realmente usan. NVDA con Chrome y JAWS con Chrome dominan el uso en escritorio; VoiceOver en iOS domina en móvil. Cubre, como mínimo, estas combinaciones y prueba las interacciones dinámicas —modales, errores de formularios, cambios de ruta en SPA— que las herramientas automatizadas nunca detectarán.
• Corrige patrones, no solo instancias. Si tu estructura de encabezados está rota, corrige la plantilla. Si la gestión de errores de tus formularios es inaccesible, corrige el componente. Las correcciones sistemáticas aportan un valor exponencialmente mayor que los parches puntuales.
• Haz que las pruebas de accesibilidad sean continuas, no periódicas. Un sitio que hoy supera una auditoría se desviará. Integra las pruebas en tu ciclo de desarrollo —automatizadas en cada commit, manuales en cada sprint, pruebas con tecnologías de asistencia en cada funcionalidad significativa— y la accesibilidad se convertirá en una propiedad mantenida de tu producto en lugar de un proyecto de remediación.