Por qué los analizadores automáticos no detectan la mayoría de los desencadenantes de demandas por ADA
La mayoría de las demandas por accesibilidad de sitios web bajo la ADA comienzan con algún tipo de prueba de accesibilidad. Las empresas a menudo asumen que esas pruebas se basan exclusivamente en herramientas de análisis automático. Ejecutan un analizador, ven una lista corta de errores y suponen que el sitio es razonablemente accesible.
Esa suposición es incorrecta.
Los analizadores automáticos de accesibilidad son útiles, pero solo detectan una parte de las barreras que conducen a demandas por sitios web bajo la ADA. La brecha entre la detección automática y la experiencia real del usuario es grande. En muchos casos, las barreras descritas en las demandas son exactamente los problemas que las herramientas automáticas no logran identificar.
Entender esa brecha requiere observar cómo funcionan los analizadores, cómo los demandantes prueban realmente los sitios web y por qué algunos problemas de accesibilidad requieren juicio humano en lugar de detección automática.
Cómo funcionan realmente los analizadores automáticos de accesibilidad
Los analizadores automáticos de accesibilidad analizan la estructura de una página web y la comparan con un conjunto de reglas. Estas reglas provienen de las Pautas de Accesibilidad al Contenido Web, comúnmente llamadas WCAG.
El analizador revisa el HTML, CSS y, a veces, JavaScript de la página. Verifica condiciones específicas vinculadas a los estándares de accesibilidad.
Las comprobaciones automáticas típicas incluyen:
- Falta de atributos
alten imágenes. - Fallos de contraste de color entre texto y fondo.
- Enlaces o botones vacíos.
- Falta de etiquetas en formularios.
- Estructura de encabezados incorrecta.
Herramientas como WAVE, Axe, Lighthouse y Siteimprove pueden ejecutar estas comprobaciones en segundos.
La salida suele aparecer como una lista de errores y advertencias.
Esa velocidad es útil para los desarrolladores. Un analizador puede resaltar rápidamente problemas técnicos en docenas o cientos de páginas.
Pero el analizador solo identifica problemas que pueden confirmarse mediante el análisis del código. Muchas barreras de accesibilidad no son visibles solo en el código.
Esas barreras requieren pruebas humanas.
Lo que las herramientas automáticas no pueden entender
Las pautas de accesibilidad a menudo dependen del contexto. Las herramientas automáticas luchan con el contexto.
Considera el texto alternativo (alt) de las imágenes.
Un analizador puede detectar si una imagen tiene un atributo alt. No puede determinar si la descripción es significativa.
Por ejemplo:
Una tienda en línea podría mostrar una imagen de producto de una zapatilla para correr roja.
El texto alternativo podría ser: "imagen".
Técnicamente, el atributo alt existe. El analizador no informa de ningún error.
Un usuario ciego que usa un lector de pantalla no recibe información útil sobre el producto.
En una demanda, esa imagen puede describirse como inaccesible.
El analizador ve un atributo válido. El usuario experimenta una barrera.
Este tipo de desajuste aparece con frecuencia en las quejas de accesibilidad.
Las herramientas automáticas no pueden interpretar el significado de la página
Muchos problemas de accesibilidad involucran la estructura en lugar de elementos aislados.
Los encabezados ilustran el problema.
Los usuarios de lectores de pantalla a menudo navegan por encabezados. Una estructura de encabezados adecuada les permite moverse rápidamente por una página.
Los analizadores automáticos pueden detectar si existen etiquetas de encabezado. No siempre pueden determinar si los encabezados reflejan la estructura de la página.
Una página podría contener cinco encabezados, todos marcados como H1.
El analizador puede marcarlo como una advertencia. No puede determinar si la estructura tiene sentido.
Un usuario de lector de pantalla que intenta navegar por la página podría escuchar una lista de encabezados que no proporcionan una jerarquía clara.
La página técnicamente pasa algunas comprobaciones automáticas. La experiencia del usuario sigue siendo confusa.
Cuando los demandantes describen barreras de accesibilidad en demandas, a menudo describen este tipo de problema estructural.
Los fallos de navegación por teclado rara vez aparecen en los análisis
La accesibilidad por teclado es una de las barreras más comunes descritas en las demandas por sitios web bajo la ADA.
Muchos usuarios con discapacidades motoras dependen de la navegación por teclado en lugar del ratón.
Se mueven por un sitio usando la tecla Tab.
Los elementos interactivos deben ser alcanzables y utilizables mediante el teclado.
Los analizadores automáticos tienen dificultades para detectar estos fallos.
Considera un menú de navegación desplegable que solo se abre cuando el ratón se sitúa sobre él.
El código del menú existe. El analizador lo ve.
Pero los usuarios de teclado no pueden abrir el menú.
El analizador no siempre detecta ese fallo.
Una prueba manual lo revela inmediatamente.
Un evaluador presiona la tecla Tab. El menú nunca se abre.
Este tipo de problema aparece repetidamente en las demandas de accesibilidad.
La compatibilidad con lectores de pantalla no se puede automatizar completamente
Los lectores de pantalla convierten el contenido de la página web en salida de voz o braille.
Programas como NVDA, JAWS y VoiceOver interpretan la estructura de la página y la leen en voz alta al usuario.
Los analizadores automáticos no pueden simular completamente cómo los lectores de pantalla interpretan el contenido.
Algunos problemas de accesibilidad aparecen solo durante el uso real del lector de pantalla.
Por ejemplo:
Un botón puede estar etiquetado visualmente con texto, pero codificado incorrectamente.
Un lector de pantalla puede anunciarlo simplemente como "botón".
El usuario no puede determinar qué hace el botón.
El analizador puede no detectar el problema porque el texto visual existe en la página.
Solo una prueba manual con lector de pantalla expone el problema.
Los demandantes que presentan demandas por sitios web bajo la ADA utilizan con frecuencia lectores de pantalla para documentar barreras.
Su proceso de prueba identifica problemas que las herramientas automáticas pasan por alto.
El contenido dinámico rompe los supuestos automáticos
Los sitios web modernos dependen en gran medida de JavaScript y contenido dinámico.
Los menús se expanden. Los formularios se actualizan en tiempo real. Los filtros de productos cambian los resultados de búsqueda sin recargar la página.
Los analizadores automáticos a menudo analizan solo la versión estática de la página.
Las interacciones dinámicas pueden no ser evaluadas nunca.
Un ejemplo común aparece en los filtros de comercio electrónico.
Una tienda de ropa puede permitir a los usuarios filtrar productos por talla, color y precio.
Los controles de filtrado pueden aparecer visualmente como botones.
Si esos botones carecen de atributos ARIA adecuados, los lectores de pantalla no pueden interpretarlos.
El analizador puede analizar la página antes de que se abra el panel de filtros.
El problema de accesibilidad permanece oculto.
La prueba manual revela el problema cuando el usuario intenta aplicar un filtro.
Las herramientas automáticas no detectan PDF y documentos inaccesibles
Muchos sitios web de empresas alojan documentos descargables.
Menús de restaurantes, formularios de admisión de pacientes, pólizas de seguros y folletos a menudo aparecen como PDF.
Los analizadores de accesibilidad típicamente analizan páginas web, no documentos adjuntos.
Un análisis automático puede mostrar pocos problemas de accesibilidad mientras el sitio contiene decenas de PDF inaccesibles.
Un usuario ciego que abre un PDF escaneado no recibe texto legible.
El lector de pantalla puede anunciar solo "gráfico".
Este problema aparece regularmente en demandas por sitios web bajo la ADA que involucran restaurantes, oficinas gubernamentales y proveedores de salud.
La barrera de accesibilidad existe en el documento mismo, no en el código de la página web.
Los analizadores rara vez la identifican.
Las demandas por accesibilidad se centran en la experiencia del usuario
Los analizadores automáticos miden el cumplimiento técnico.
Las demandas bajo la ADA se centran en si un usuario pudo completar una tarea.
Esa diferencia explica por qué los analizadores no detectan muchos desencadenantes de demandas.
Una demanda a menudo describe las acciones realizadas por el demandante.
Ejemplos incluyen:
- Intentar programar una cita.
- Intentar pedir comida.
- Intentar ver el menú de un restaurante.
- Intentar comprar un producto.
La demanda luego describe la barrera encontrada durante el intento.
La barrera puede involucrar múltiples fallos de accesibilidad que interactúan entre sí.
Las herramientas automáticas examinan problemas de código aislados. No evalúan la finalización de tareas.
Esta brecha es la razón por la que un sitio web puede pasar un análisis automático y aun así desencadenar una demanda.
Un ejemplo real de un sitio web minorista
En 2022, un usuario ciego intentó comprar ropa en un minorista en línea.
Las páginas de producto parecían funcionales al principio.
Las imágenes tenían atributos alt. Los botones contenían etiquetas de texto.
Los analizadores automáticos reportaron relativamente pocos errores.
Pero el proceso de pago creó un problema.
El formulario de pago utilizaba campos de entrada personalizados creados con JavaScript.
Las etiquetas visuales aparecían sobre los campos.
El código no asociaba esas etiquetas con los campos de entrada.
Cuando el lector de pantalla llegó al formulario, anunció:
"editar texto".
Sin descripción del campo.
El usuario no podía determinar qué campo requería nombre, dirección o número de tarjeta de crédito.
El analizador automático no marcó el problema porque las etiquetas existían visualmente.
La barrera apareció solo durante la prueba con lector de pantalla.
El problema apareció más tarde en una queja de accesibilidad bajo la ADA.
Los analizadores automáticos también generan falsos positivos
Las herramientas automáticas no solo omiten problemas. A veces señalan problemas que no son barreras reales de accesibilidad.
Los profesionales de la accesibilidad a menudo llaman a esto falsos positivos.
Por ejemplo:
Las imágenes decorativas deben contener atributos alt vacíos para que los lectores de pantalla las ignoren.
Algunos analizadores señalan estas imágenes como si les faltaran descripciones.
Los desarrolladores que no conocen las reglas de accesibilidad pueden intentar "corregir" el problema añadiendo texto alternativo innecesario.
El resultado crea ruido para los usuarios de lectores de pantalla.
El analizador reporta una mejora. La experiencia del usuario empeora.
Los falsos positivos pueden desperdiciar el tiempo de los desarrolladores y crear confusión sobre lo que realmente necesita ser corregido.
Se requiere una revisión manual para interpretar correctamente los resultados del analizador.
El problema del porcentaje
Los investigadores de accesibilidad estiman con frecuencia que los analizadores automáticos detectan entre el 25% y el 40% de los fallos de accesibilidad de WCAG.
El número exacto varía según el estudio y el método de prueba.
Pero el patrón sigue siendo consistente.
Las herramientas automáticas detectan solo una fracción de los problemas de accesibilidad.
Los problemas restantes requieren evaluación humana.
Las demandas por accesibilidad a menudo describen esas barreras no detectadas.
Cómo los demandantes prueban realmente los sitios web
Los demandantes involucrados en litigios por sitios web bajo la ADA a menudo siguen un proceso de prueba predecible.
Primero, ejecutan un análisis automático de accesibilidad.
El análisis identifica problemas obvios como la falta de atributos alt o fallos de contraste de color.
A continuación, el evaluador navega manualmente por el sitio.
Los lectores de pantalla juegan un papel central en esta prueba.
El evaluador puede intentar realizar tareas como pedir un producto o enviar un formulario.
Durante este proceso, el evaluador registra las barreras de accesibilidad encontradas.
Estas barreras se convierten en la base de la demanda.
La documentación puede incluir:
- Salida del lector de pantalla.
- Capturas de pantalla.
- Descripciones de interacciones fallidas.
La demanda describe la experiencia del usuario en lugar del informe automatizado.
Este enfoque explica por qué los resultados de los análisis automáticos rara vez coinciden con las barreras descritas en las demandas.
Por qué las superposiciones no resuelven la brecha del analizador
Algunas empresas instalan superposiciones de accesibilidad después de descubrir problemas de accesibilidad.
Las superposiciones añaden un widget que permite a los usuarios ajustar el tamaño del texto, el contraste o el espaciado.
Estas herramientas operan después de que la página se carga.
No reparan la estructura HTML subyacente.
Si a un campo de formulario le falta una etiqueta adecuada, la superposición no la añade.
Si la navegación por teclado falla, la superposición rara vez soluciona el problema.
Debido a esta limitación, las superposiciones no cierran la brecha entre los análisis automáticos y las pruebas de accesibilidad reales.
Las barreras siguen siendo visibles durante las pruebas manuales.
Varias demandas bajo la ADA han mencionado superposiciones que estaban presentes en el sitio web pero que no resolvían las barreras de accesibilidad.
Por qué los desarrolladores confían demasiado en los analizadores
Los analizadores automáticos son atractivos porque son rápidos.
Un análisis completo del sitio puede tomar menos de un minuto.
Los resultados aparecen en un informe simple.
Los desarrolladores pueden ejecutar la herramienta durante el desarrollo y corregir problemas obvios rápidamente.
La conveniencia lleva a una excesiva confianza.
Algunos equipos asumen que pasar un análisis automático significa que el sitio es accesible.
Los profesionales de la accesibilidad generalmente tratan los analizadores como el primer paso, no como el paso final.
Se requieren pruebas manuales para confirmar la accesibilidad real.
Sin pruebas manuales, la mayoría de los problemas de accesibilidad permanecen sin descubrir.
La accesibilidad requiere múltiples métodos de prueba
Una evaluación de accesibilidad confiable generalmente combina varios enfoques.
- El análisis automático identifica problemas técnicos básicos.
- Las pruebas manuales de teclado confirman la funcionalidad de navegación.
- Las pruebas con lectores de pantalla evalúan cómo las tecnologías de asistencia interpretan la página.
- Las herramientas de contraste de color verifican la legibilidad visual.
- Las revisiones de documentos identifican PDF o archivos adjuntos inaccesibles.
Cada método revela diferentes categorías de problemas de accesibilidad.
Ninguna herramienta cubre todo.
Los analizadores automáticos son útiles pero incompletos.
La realidad económica detrás de las demandas de accesibilidad
El litigio por accesibilidad a menudo se centra en sitios web con barreras generalizadas.
Los demandantes no necesitan documentar todos los fallos de accesibilidad.
Necesitan demostrar que las barreras impidieron el acceso a los bienes o servicios ofrecidos.
Las pruebas manuales revelan rápidamente esas barreras.
Los análisis automáticos pueden respaldar la demanda, pero rara vez la definen.
Esta diferencia explica por qué las empresas a veces se sienten sorprendidas por las demandas.
Su informe de análisis mostraba solo un puñado de problemas.
La prueba manual reveló los problemas reales.
La brecha entre el cumplimiento técnico y la accesibilidad real
Las pautas de accesibilidad existen para mejorar la usabilidad para personas con discapacidades.
Las herramientas automáticas miden si se cumplen ciertas condiciones técnicas.
La accesibilidad real depende de cómo los usuarios interactúan con el sitio.
La brecha entre esas dos perspectivas explica por qué los analizadores automáticos no detectan muchos desencadenantes de demandas.
Los analizadores evalúan patrones de código.
Los usuarios experimentan navegación, interacción y significado.
Los problemas de accesibilidad a menudo aparecen en la capa de interacción.
Esa capa no puede ser evaluada solo por análisis automático.
Comments (0)
No comments yet.