¿Qué son las pruebas de accesibilidad automatizadas?

¿Qué son las pruebas de accesibilidad automatizadas?

Las pruebas de accesibilidad automatizadas usan software, como un motor de reglas, una auditoría del navegador o un linter, para analizar una página o un componente en busca de fallos de accesibilidad que un programa puede detectar: texto alternativo ausente, campos sin etiqueta, bajo contraste de color, ARIA no válido. Son rápidas y repetibles, ideales para cazar regresiones, pero cubren solo una parte de WCAG. El resto lo tiene que juzgar una persona.

Cómo funcionan

Una herramienta carga el DOM renderizado, aplica un conjunto de reglas e informa de cada elemento que falla, normalmente con la regla, el criterio WCAG y una sugerencia de arreglo. Las opciones habituales son:

• Motores de reglas como axe-core, ejecutados dentro de pruebas unitarias, de componentes o de extremo a extremo, para que una regla incumplida haga fallar la compilación.
• Auditorías del navegador como Lighthouse, que convierte un conjunto de auditorías automáticas en una puntuación de accesibilidad de 0 a 100. Lighthouse pondera esas auditorías con las valoraciones de impacto de axe, y cada auditoría es de aprobado o suspenso, así que un botón sin nombre suspende toda la auditoría de nombres de botones.
• Linters en el editor o en la CI que señalan problemas en el marcado antes de publicarlo.

Lo que no pueden hacer

La guía de evaluación del W3C dice que ninguna herramienta por sí sola puede determinar si un sitio cumple los estándares de accesibilidad, y que hace falta una evaluación humana experta. El propio README de axe-core afirma que encuentra de media el 57 % de los problemas de WCAG de forma automática e informa de los elementos dudosos como "incomplete" para revisión manual. Es la cifra del fabricante para sus reglas, así que tómala como orientación aproximada, no como garantía. Una herramienta ve que una imagen tiene texto alternativo, pero no si es útil. No sabe si el orden del tabulador tiene sentido, si un mensaje de error se entiende o qué vive realmente una persona con lector de pantalla. Lighthouse mismo enumera comprobaciones manuales, como el orden lógico del tabulador y la gestión del foco, que no entran en la puntuación.

Un ejemplo en un pipeline

Un equipo añade axe-core a sus pruebas de extremo a extremo de las páginas de registro y de pago. En cada pull request la compilación falla si aparece una nueva infracción, como un campo sin etiqueta. Antes de cada versión, una persona recorre esas páginas con el tabulador y con un lector de pantalla. La ejecución automática detecta regresiones en cada commit y la revisión manual encuentra lo que las reglas no ven, véanse las pruebas manuales de accesibilidad.

Errores frecuentes

• Tomar una puntuación de 100 en Lighthouse como prueba de accesibilidad o de conformidad con WCAG.
• Analizar solo la página de inicio y no los estados con sesión, los diálogos, los errores y el pago.
• No revisar nunca los resultados "incomplete" o "por revisar".
• Arreglar el aviso de la herramienta sin comprobar la experiencia real, por ejemplo poniendo un texto alternativo sin sentido solo para cumplir la regla.
• Ejecutarlas una vez antes del lanzamiento en vez de en cada cambio.

Dónde encajan con las pruebas y la monitorización

Las pruebas automatizadas son una capa más. Van junto a las comprobaciones con teclado, las pruebas con lector de pantalla y los métodos formales de accessibility conformance testing. Ni siquiera una auditoría exhaustiva es un informe de conformidad: qué es ese documento se explica en accessibility conformance report. La monitorización de velocidad de página de LoadFocus ejecuta auditorías Lighthouse programadas y registra la categoría de accesibilidad junto a Rendimiento, SEO y Buenas prácticas, para que veas la puntuación como tendencia. Es un monitor de regresiones, no una auditoría de accesibilidad ni un informe de conformidad. Para profundizar, consulta pruebas de rendimiento y métricas de accesibilidad y el repaso de herramientas de pruebas de accesibilidad.

Preguntas frecuentes: pruebas de accesibilidad automatizadas

¿Qué porcentaje de problemas de accesibilidad encuentran las herramientas automáticas?

Depende de la herramienta y del sitio. El README de axe-core habla de un 57 % de media de los problemas de WCAG, una estimación de Deque para sus propias reglas. En cualquier caso, una parte requiere pruebas manuales.

¿Lighthouse es una auditoría de accesibilidad?

No. Ejecuta un conjunto de auditorías automáticas y da una puntuación ponderada. Un 100 significa que esas auditorías pasaron, no que la página sea accesible.

¿Puede la prueba automatizada hacer mi sitio conforme a WCAG?

No. Ayuda a encontrar y evitar muchos fallos, pero la conformidad exige una evaluación manual de los criterios de éxito.

¿Cuándo debo ejecutar pruebas de accesibilidad automatizadas?

En cada pull request o compilación para las páginas y componentes clave, y de forma programada en las páginas en producción, para detectar pronto las regresiones.

¿Qué debo probar a mano?

El manejo por teclado y el orden del foco, el comportamiento con lector de pantalla, el zoom y el reflujo, los textos alternativos con sentido, los mensajes de error y cualquier widget personalizado.