Por qué las pruebas automatizadas de accesibilidad pasan por alto la mitad de tus problemas

La verdad incómoda sobre las pruebas automatizadas de accesibilidad

Las pruebas automatizadas de accesibilidad son uno de los mejores hábitos que puede adoptar un equipo web. Detectan etiquetas de formulario ausentes, texto con bajo contraste, ARIA no válido, IDs duplicados, botones vacíos y otros defectos que nunca deberían llegar a producción.

También se malinterpretan de forma habitual.

Un informe automatizado de accesibilidad sin errores no significa que una página sea accesible. Significa que la herramienta no encontró el subconjunto de problemas que sabe detectar. Ese subconjunto es valioso, pero limitado. Muchos fallos de accesibilidad dependen del significado, el orden, la intención, el contexto y la interacción humana. El software puede inspeccionar el marcado. No puede comprender de forma fiable si la experiencia funciona para una persona que usa un lector de pantalla, teclado, ampliación, control por voz, subtítulos o apoyo cognitivo.

Por eso, afirmar que las pruebas automatizadas pasan por alto aproximadamente la mitad de tus problemas no es cínico. Es generoso. Algunas categorías de problemas son muy automatizables. Otras apenas lo son.

La respuesta práctica no es abandonar las herramientas automatizadas. Es colocarlas en el lugar adecuado: pronto, con frecuencia y como parte de un flujo de pruebas más amplio.

En qué son buenas las pruebas automatizadas

Las herramientas automatizadas son excelentes para encontrar fallos deterministas. Si una regla puede expresarse como una condición legible por máquina, normalmente un escáner puede comprobarla de forma rápida y consistente.

Algunos ejemplos comunes son:

• Imágenes sin atributos alt
• Campos de formulario sin etiquetas asociadas
• Botones sin nombres accesibles
• Texto que no cumple los umbrales de contraste
• Atributos o roles ARIA no válidos
• Niveles de encabezado que saltan de formas sospechosas
• Landmarks ausentes o duplicados
• Enlaces con nombres accesibles vacíos
• Tablas sin estructura básica

Estas comprobaciones merece la pena automatizarlas porque las personas no somos buenas en la inspección repetitiva. Nadie debería revisar manualmente cada página en busca de etiquetas ausentes si una herramienta puede detectarlas en milisegundos.

Las comprobaciones automatizadas también facilitan hablar de accesibilidad dentro de los flujos de ingeniería. Una prueba fallida en CI es concreta. Una advertencia en una pull request llega a tiempo. Una línea de tendencia entre plantillas da al equipo algo que mejorar.

El problema empieza cuando los equipos tratan estas comprobaciones como prueba de accesibilidad, en lugar de como prueba de higiene básica.

Dónde se rompe la automatización

La accesibilidad no es solo una propiedad del código. Es una propiedad del uso.

Una herramienta puede decirte si una imagen tiene texto alternativo. Por lo general, no puede decirte si ese texto alternativo es útil. Una imagen de un producto puede necesitar una descripción detallada en una página de producto, ninguna descripción en un hero decorativo y una descripción completamente distinta en un artículo de ayuda. La respuesta correcta depende del contexto. Por eso los equipos necesitan orientación editorial como un enfoque pragmático para el texto alternativo de las imágenes, no solo una regla de linter.

El mismo problema aparece en todas partes.

Un escáner puede confirmar que cada botón tiene un nombre accesible. No siempre puede decir si el nombre tiene sentido. Una página con cinco botones llamados Enviar puede pasar una regla básica y, aun así, ser una experiencia pésima para quienes usan lectores de pantalla. Un modal puede tener los atributos ARIA correctos pero atrapar el foco de forma incorrecta. Un desplegable personalizado puede parecer conforme en el marcado estático y fallar en el momento en que alguien intenta usarlo con el teclado.

La automatización tiene dificultades con preguntas como:

• ¿El orden del foco coincide con el orden visual y lógico?
• ¿Puede completarse cada tarea solo con el teclado?
• ¿Los mensajes de error son específicos, oportunos y están asociados a los campos?
• ¿La página sigue funcionando cuando se redimensiona o se amplía el texto?
• ¿El orden de lectura tiene sentido para la tecnología de asistencia?
• ¿Las instrucciones se entienden sin depender del color o la posición?
• ¿Los subtítulos, transcripciones y etiquetas comunican realmente el contenido?
• ¿Un componente se comporta de forma predecible en todos sus estados?

Estos no son casos extremos. Son aspectos centrales de la accesibilidad.

La falsa tranquilidad de una puntuación alta

Las puntuaciones de accesibilidad resultan seductoras porque comprimen un asunto complejo en un número. Un panel dice 98. Un informe muestra marcas verdes. La publicación parece más segura.

Pero la puntuación solo mide lo que mide la herramienta.

Esto es similar a las pruebas de rendimiento. Un informe de Lighthouse puede revelar problemas importantes, pero no es lo mismo que observar a una persona real sufrir durante un checkout lento en un teléfono de gama media. Si tu equipo ya utiliza auditorías de rendimiento, aplica la misma mentalidad: lee el informe con cuidado y luego prioriza los hallazgos que afectan a personas reales. Hemos escrito sobre esa distinción en cómo leer un informe de Lighthouse sin entrar en pánico.

Los informes de accesibilidad requieren la misma contención. Un escaneo automatizado limpio es un punto de partida. No es un certificado.

El riesgo es especialmente alto cuando los equipos ejecutan escaneos solo sobre páginas estáticas. Las interfaces modernas tienen estado: los menús se abren, los paneles se deslizan, aparecen toasts, los mensajes de validación se actualizan, las pestañas cambian de panel, los filtros reescriben el contenido y la autenticación lo cambia todo. Muchos defectos graves de accesibilidad viven en esas interacciones.

Si tu escáner solo ve el DOM inicial, se está perdiendo el producto.

Las categorías que más se suelen pasar por alto

1. Comportamiento del teclado y del foco

El acceso por teclado es uno de los ejemplos más claros de por qué la automatización no basta.

Una herramienta puede detectar si un elemento puede recibir foco. Puede encontrar valores positivos de tabindex o trampas de foco evidentes. Pero no puede juzgar de forma fiable si la secuencia de tabulación resulta coherente, si el foco se desplaza al lugar correcto después de una acción o si un componente descartado devuelve el foco al activador.

Hace falta una persona que pulse Tab, Shift+Tab, Enter, Space, Escape y las teclas de flecha a través del flujo real.

Esto es especialmente importante para los controles personalizados. Los elementos HTML nativos incorporan años de comportamiento accesible sin coste adicional. Reconstruir botones, selects, checkboxes, menús y diálogos con divs significa que ahora tu equipo es responsable de ese comportamiento. Si estás revisando componentes interactivos, empieza por una breve lista de comprobación para botones web accesibles y aplica la misma disciplina a cada control personalizado.

2. Nombres y descripciones significativos

Las herramientas automatizadas pueden detectar la ausencia. Son mucho peores detectando la calidad.

Un enlace llamado Leer más puede tener técnicamente un nombre accesible. Un botón etiquetado como OK puede ser válido. Una ayuda de formulario puede estar presente. Pero ¿son significativos en contexto? A menudo no.

Los nombres accesibles deben indicar a las personas usuarias qué ocurrirá o qué representa el elemento. Eso requiere criterio. También requiere probar la interfaz, no solo el código.

3. Gestión de errores

Los formularios están llenos de fallos de accesibilidad que los escáneres solo detectan parcialmente.

Una herramienta puede señalar un campo sin etiqueta. Puede no detectar que el mensaje de validación aparece demasiado tarde, desaparece demasiado rápido, no se anuncia a los lectores de pantalla o dice Entrada no válida cuando debería decir La contraseña debe tener al menos 12 caracteres.

Una buena gestión de errores es diseño de interacción. Necesita pruebas manuales y, idealmente, pruebas con personas usuarias.

4. Adaptación visual

WCAG incluye requisitos sobre redimensionamiento del texto, reflujo, contraste, espaciado y no depender de una única señal sensorial. Parte de esto puede comprobarse automáticamente, pero la verdadera pregunta es si la interfaz sigue siendo usable cuando cambian las condiciones.

Prueba con zoom al 200%. Prueba el redimensionamiento de texto del navegador. Prueba el modo de alto contraste o colores forzados. Prueba anchos de viewport estrechos. Prueba movimiento reducido. Muchos sitios que se ven pulidos con la configuración predeterminada se rompen rápidamente cuando las personas usuarias imponen sus preferencias.

5. Claridad del contenido

Ninguna herramienta automatizada de accesibilidad puede evaluar por completo si el contenido se entiende.

Puede señalar encabezados ausentes o texto de enlace vago. No puede saber si la página explica un proceso con claridad, si las etiquetas coinciden con las expectativas de las personas usuarias o si una redacción densa crea una carga cognitiva evitable.

La accesibilidad no consiste solo en la compatibilidad con tecnologías de asistencia. También consiste en reducir la fricción para personas bajo estrés, que usan un idioma desconocido, que lidian con limitaciones de atención o que navegan por tareas complejas.

Un mejor flujo de pruebas

Un flujo de accesibilidad equilibrado tiene capas.

Ejecuta comprobaciones automatizadas de forma continua

Usa pruebas automatizadas en desarrollo, pull requests, vistas previas de componentes y CI. Deben ser aburridas, rápidas e innegociables. Descubrir nuevas etiquetas ausentes y ARIA no válido no debería requerir una auditoría trimestral.

Trata estos fallos como fallos de linting. El objetivo no es hacer heroicidades, sino prevenir regresiones.

Añade pruebas manuales con teclado

Para cada flujo de usuario relevante, prueba sin ratón. Esto incluye navegación, búsqueda, creación de cuenta, checkout, filtrado, modales, menús y envío de formularios.

Como mínimo, verifica:

• Todos los elementos interactivos son alcanzables
• El foco es visible en todo momento
• El orden del foco es lógico
• Las teclas esperadas funcionan
• Escape descarta las superposiciones descartables
• El foco se gestiona tras abrir y cerrar componentes
• No existe ninguna trampa de teclado

Este único hábito detecta una gran clase de problemas que los escaneos automatizados pasan por alto.

Prueba con al menos un lector de pantalla

No necesitas convertirte en una persona experta en lectores de pantalla para aprender cosas útiles. Sí necesitas humildad. Las pruebas con lectores de pantalla tienen una curva de aprendizaje, y las personas principiantes pueden diagnosticar mal los problemas.

Aun así, una prueba básica con VoiceOver, NVDA o JAWS puede revelar nombres rotos, un orden de lectura confuso, actualizaciones no anunciadas y problemas de landmarks que un escáner quizá no detecte.

Combina esto con HTML semántico. Cuantos más elementos nativos uses, menos frágil será tu accesibilidad.

Revisa contenido y estados

Comprueba estados vacíos, estados de carga, estados de error, estados deshabilitados, mensajes de éxito y fallos de permisos. Los errores de accesibilidad suelen ocultarse fuera del camino feliz.

Revisa también las palabras reales. Las etiquetas, los encabezados, las instrucciones y los mensajes de error forman parte de la interfaz.

Incluye a personas con discapacidad cuando el riesgo sea alto

Para flujos críticos, una revisión manual experta no basta. Las pruebas con participantes con discapacidad encuentran problemas que los equipos no anticipan. Esto es especialmente importante en servicios públicos, salud, finanzas, educación y cualquier flujo donde la exclusión tenga consecuencias graves.

Las pruebas automatizadas escalan. Las pruebas humanas comprenden.

Cómo interpretar los resultados automatizados de forma responsable

No preguntes: ¿hemos aprobado?

Haz preguntas mejores:

• ¿Qué categorías de problemas puede detectar esta herramienta?
• ¿Qué plantillas y estados ha escaneado?
• ¿Se ejecutó después de las interacciones o solo en la carga inicial?
• ¿Las infracciones están agrupadas por causa raíz o se cuentan repetidamente?
• ¿Qué fallos impiden a las personas completar tareas?
• ¿Qué sigue requiriendo revisión manual?

Este enfoque cambia la conversación. Las herramientas automatizadas se convierten en evidencia, no en autoridad.

También ayuda a los equipos a evitar trabajo innecesario. Corregir un solo componente puede eliminar cientos de infracciones repetidas. A la inversa, una página con un único problema informado puede contener una trampa de teclado grave. Los recuentos no son impacto.

El estándar práctico: automatiza lo obvio, prueba manualmente la experiencia

Los mejores equipos de accesibilidad no son contrarios a las herramientas. Son contrarios a la fantasía.

Automatizan lo que las máquinas pueden detectar de forma fiable. Prueban manualmente lo que depende del comportamiento y del significado. Usan estándares como WCAG como una base compartida, no como sustituto de usar el producto.

Si tu proceso actual es solo un escaneo automatizado antes del lanzamiento, mejóralo en este orden:

1. Añade comprobaciones automatizadas antes en el desarrollo.
2. Prueba manualmente con teclado los flujos principales.
3. Revisa nombres, etiquetas, errores e instrucciones.
4. Prueba componentes comunes con un lector de pantalla.
5. Incorpora pruebas expertas y con personas usuarias para recorridos de alto riesgo.

No es un proceso perfecto. Es un proceso realista. Y encontrará mucho más que una puntuación verde de accesibilidad.