Respuesta.

Las pruebas de accesibilidad automatizadas (Accessibility Testing, a11y) han cobrado especial relevancia con el desarrollo de iniciativas para garantizar la inclusión digital. Originalmente, las verificaciones se realizaban manualmente, lo que a menudo conducía a omisiones de errores críticos o descubrimientos tardíos de problemas. El enfoque moderno implica la automatización a través de herramientas especiales e integración de chequeos de a11y en CI/CD.

Historia del tema: Las primeras verificaciones de accesibilidad eran completamente manuales, lo que resultaba laborioso y susceptible al factor humano. Con la aparición de estándares (WCAG, Sección 508) se empezaron a desarrollar herramientas como axe, pa11y y Lighthouse, que permitieron automatizar significativamente el proceso.

Problema: La principal dificultad es que la automatización no puede cubrir todos los aspectos de accesibilidad (por ejemplo, una alternativa correcta para contenido gráfico complejo o la adecuación de textos para lectores de pantalla). También suelen surgir problemas con el soporte de widgets específicos, interfaces asíncronas y la correcta implementación de plugins de a11y en la tubería de pruebas.

Solución: Se combina la automatización de chequeos estándar (contrastes, aria-*, tabindex, estructura, etiquetas) con la validación manual de procesos empresariales críticos, involucrando a especialistas en accesibilidad. Una buena práctica es integrar escáneres de a11y durante las solicitudes de extracción y lanzamientos clave, para no crear "deuda técnica en accesibilidad".

Características clave:

Amplio uso de escáneres de software: axe-core, pa11y, Google Lighthouse.
Integración en procesos CI con retroalimentación automática clara sobre errores.
Actualización regular de herramientas en función de la evolución de los estándares (WCAG 2.2, ARIA, etc.).

Preguntas trampa.

Pregunta 1 trampa

"¿Es suficiente usar solo escáneres automáticos para garantizar la accesibilidad completa?"

Respuesta: No, las herramientas automáticas cubren solo alrededor del 30-50% de los requisitos de accesibilidad. El resto solo puede identificarse mediante pruebas manuales y pruebas con tecnologías asistivas reales.

Pregunta 2 trampa

"¿Si se añade solo role="button" o un atributo similar, se volverá accesible el elemento?"

Respuesta: No siempre. Se debe garantizar un manejo correcto del foco, soporte de teclado, manejo de eventos y textos informativos para lectores de pantalla.

Pregunta 3 trampa

"¿Las pruebas de accesibilidad ralentizan mucho CI: tiene sentido ejecutarlas solo una vez al mes?"

Respuesta: No, estas pruebas deben ejecutarse con cada cambio, de lo contrario, no se detectarán a tiempo las regresiones relacionadas con la accesibilidad, y su corrección será más difícil (y costosa).

Errores comunes y anti-patrones

Limitar la automatización solo al análisis estático sin verificaciones manuales/entrevistas con usuarios con discapacidades.
Enfoque formal: solo asegurar el paso del escáner, ignorando la verdadera accesibilidad para usuarios reales.
Ejecutar pruebas de a11y solo localmente, fuera de CI/CD y fuera de solicitudes de extracción.

Ejemplo de la vida real

Caso negativo

En el equipo decidieron ejecutar Lighthouse una vez y dejarlo así, marcando una casilla en la lista de verificación. Encontraron y corrigieron varios errores, pero más tarde se descubrió que en una aplicación bancaria real, los usuarios ciegos no podían completar correctamente una tarjeta: mensajes importantes no eran leídos, los botones eran "invisibles" para los lectores de pantalla.

Ventajas:

Se implementó rápidamente la automatización.

Desventajas:

Los problemas de los usuarios reales solo salieron a la luz después de quejas y se perdió confianza en el producto.
La corrección resultó costosa, ya que se necesitó una remodelación de la interfaz.

Caso positivo

Desde el principio, los chequeadores de a11y se integraron en la tubería y en el reglamento del proyecto, se llevaron a cabo regularmente verificaciones manuales con tecnología asistiva y entrevistas con expertos externos. Como resultado, los clientes ciegos encontraron conveniente usar la interfaz web del banco.