¿Qué proporción de los defectos de accesibilidad hallados en auditorías manuales o por usuarios había superado las comprobaciones automáticas en CI y de qué tipo eran los que escaparon?

Pregunta abierta

Los verificadores automáticos de accesibilidad son baratos de ejecutar: un motor de reglas inspecciona el DOM renderizado en cada build y hace fallar el pipeline cuando falta el texto alternativo, el contraste es bajo, hay controles de formulario sin etiqueta o atributos ARIA no válidos. La guía del W3C WAI sobre la selección de herramientas de evaluación afirma de forma explícita que las herramientas ahorran tiempo pero no pueden hacerlo todo, porque algunas comprobaciones de accesibilidad no se pueden automatizar y requieren intervención manual. Aun así, existe la tentación de considerar que una ejecución automática en verde equivale a "accesibilidad resuelta", porque una auditoría manual cuesta dinero y los reportes de los usuarios llegan por los canales de soporte, no por el build.

Lo que le falta a la wiki es un registro de esa diferencia en sitios reales. Cuando se realizó una auditoría manual (una revisión experta con lector de pantalla y teclado, o una sesión con usuarios con discapacidad) en un sitio cuyos builds ya pasaban un verificador automático, ¿qué proporción de los defectos encontrados estaba presente en las páginas comprobadas y, pese a ello, había superado la verificación? ¿Qué tipos de defecto predominan en esa proporción: orden y pérdida del foco, trampas de teclado en widgets personalizados, textos de enlace sin sentido que técnicamente sí tienen etiqueta, orden de lectura incorrecto, mensajes de estado que nunca se anuncian, texto alternativo presente pero erróneo, animaciones que no se pueden pausar? Y a la inversa: ¿qué proporción de los hallazgos automáticos resultó irrelevante para cualquier usuario del sitio, hasta el punto de que el equipo aprendió a ignorar la herramienta? ¿Se reduce la diferencia cuando la ejecución automática incluye interacción de teclado con scripts, o cuando la propia biblioteca de componentes fue auditada, de modo que los defectos restantes están en la composición de las páginas y no en los componentes?

La respuesta decide hacia dónde debería dirigir un equipo pequeño su limitado esfuerzo de accesibilidad: más reglas en CI, una revisión manual periódica o una auditoría del sistema de diseño.

Qué contiene una respuesta útil

El tipo de sitio, el framework y la biblioteca de componentes, y el verificador con su conjunto de reglas y su versión. El número de páginas cubiertas por la ejecución automática y por la auditoría manual. Por cada defecto encontrado manualmente o notificado por un usuario: el criterio de conformidad afectado, si la página había pasado la ejecución automática y si existe una regla para ello en la herramienta que no se activó. Por cada hallazgo automático en el mismo periodo: si se corrigió, se suprimió o se juzgó un falso positivo, con el motivo. El método de auditoría (revisión experta, pruebas con tecnología de asistencia, sesión con usuarios), ya que cada uno detecta cosas distintas. Si el equipo cambió algo como resultado: añadir reglas, incorporar una lista de comprobación manual a la revisión o sustituir componentes. Los informes de un solo sitio son bienvenidos si se indican el conjunto de reglas y el método de auditoría; las comparaciones entre sitios con la misma herramienta son más útiles.