Cumplimiento ADA para sitios web: la ilusión de seguridad después de contratar a un desarrollador web

Cumplimiento de la ADA en sitios web: la ilusión de seguridad después de contratar a un desarrollador web

El cumplimiento de la ADA (Ley para Estadounidenses con Discapacidades) en sitios web es donde la mayoría de los dueños de negocios son engañados, y suele comenzar justo después de que pagan a un desarrollador y ven cómo una página de inicio limpia carga en menos de dos segundos.

Un dueño de negocio contrata a un desarrollador, paga entre $3,000 y $15,000, obtiene un diseño moderno, pasa algunas pruebas de velocidad, quizás ve una puntuación de Lighthouse en los 90, y asume que el trabajo se hizo bien. Esa suposición es incorrecta.

Lo que compraron fue un producto visual. Lo que necesitaban era cumplimiento legal y funcional con los estándares de accesibilidad vinculados a la Ley para Estadounidenses con Discapacidades (ADA). No son lo mismo. Ni siquiera se acercan.

Lo que los desarrolladores entregan realmente vs. lo que requiere el cumplimiento

La mayoría de los desarrolladores siguen una lista de verificación predecible:

• Diseño adaptable a dispositivos móviles (responsive).
• Velocidad de página decente.
• SEO básico en la página (etiquetas de título, meta descripciones).
• Interfaz de usuario limpia con fuentes y espaciado modernos.

Luego se detienen.

• No realizan pruebas de navegación solo con teclado.
• No usan lectores de pantalla como NVDA o VoiceOver.
• No auditan etiquetas de formularios, atributos ARIA ni estados de enfoque.
• No prueban el manejo de errores para tecnologías de asistencia.

Entregan lo que parece completo. No lo que está completo.

El cumplimiento de la ADA en sitios web, vinculado a las WCAG 2.1 Nivel AA en la mayoría de los contextos legales, requiere un flujo de trabajo totalmente diferente. Es más lento, más técnico e incómodo para los desarrolladores que fueron entrenados para priorizar la estética y la velocidad sobre la función.

Por qué este error sigue ocurriendo

Los desarrolladores no están capacitados en riesgo legal. Están capacitados en entregas. Un desarrollador independiente que cobra $5,000 por un sitio web está optimizando para:

• Terminar a tiempo.
• Mantener el alcance limitado.
• Evitar casos extremos (edge cases) que los ralenticen.

La accesibilidad es un caso extremo para ellos. Ese es el problema. Asumen que:

1. Los lectores de pantalla son raros.
2. Los usuarios con discapacidad son un segmento pequeño.
3. Los clientes no notarán la falta de funciones de accesibilidad.

Están equivocados en los tres puntos. Al sistema legal no le importa cuántos usuarios se vean afectados. Le importa que exista una barrera.

La parte que los clientes nunca ven

Las fallas de accesibilidad son invisibles si no sabes qué buscar.

• Un botón puede verse perfecto y aun así ser inutilizable.
• Un formulario puede parecer funcional y aun así bloquear completamente a un usuario ciego.
• Un menú de navegación puede funcionar con un ratón y fallar completamente con un teclado.

Nada "parece roto". Es por eso que los dueños de negocios asumen que están a salvo. No hay ninguna señal visual que les diga lo contrario. Hasta que llega una carta de demanda.

Aplicación real: no es teórica, no es rara

La idea de que el cumplimiento de la ADA para sitios web es vago o se aplica poco está desactualizada. Tomemos el caso de Robles v. Domino’s Pizza, LLC (2019).

Un usuario ciego, Guillermo Robles, no pudo pedir comida a través del sitio web y la aplicación móvil de Domino's usando su lector de pantalla. Domino's argumentó que la ADA no se aplicaba claramente a los sitios web.

La Corte de Apelaciones del Noveno Circuito rechazó ese argumento. El tribunal permitió que el caso procediera porque la inaccesibilidad del sitio web y la aplicación negaba la igualdad de acceso a bienes y servicios vinculados a ubicaciones físicas. Domino's llevó el caso a la Corte Suprema, la cual se negó a escucharlo. Esa decisión dejó intacto el fallo del tribunal inferior.

Sin ambigüedad. Sin lagunas. Si tu sitio web bloquea el acceso, estás expuesto.

Esto no solo afecta a las grandes marcas

Domino's tenía recursos legales. La mayoría de las empresas no. Las empresas más pequeñas son atacadas constantemente. Simplemente no llegan a los titulares.

Un dentista en Florida pagó aproximadamente $8,000 por un rediseño de sitio web en 2022. Diseño limpio. Carga rápida. Adaptable a móviles. A los pocos meses, recibieron una carta de demanda. El problema no era el diseño. Era la función:

• Los formularios de citas no tenían etiquetas accesibles.
• Los campos de entrada no eran anunciados por lectores de pantalla.
• Los mensajes de error no estaban vinculados a los campos.
• La navegación saltaba de forma impredecible al usar un teclado.

Un usuario ciego no podía reservar una cita. Eso es suficiente para una demanda. El acuerdo costó más que la creación original del sitio web. Luego tuvieron que pagar de nuevo para arreglar el sitio correctamente.

Ese es el patrón: Pagar por un sitio web -> Asumir cumplimiento -> Ser demandado -> Pagar de nuevo.

Lo que las WCAG 2.1 realmente requieren (y lo que los desarrolladores omiten)

Las WCAG 2.1 no son una sugerencia de diseño. Son un estándar técnico. Esto es lo que se omite más a menudo:

• Navegación por teclado: Cada elemento interactivo debe ser utilizable sin un ratón. Si alguien no puede navegar lógicamente por tu sitio usando la tecla Tab, ya estás fallando.
• Compatibilidad con lectores de pantalla: Requiere una estructura adecuada (jerarquía de encabezados, texto descriptivo en enlaces, etiquetas en formularios y HTML semántico).
• Accesibilidad de formularios: Requiere etiquetas visibles vinculadas a entradas, instrucciones claras y mensajes de error accesibles.
• Contraste de color: El texto debe cumplir con relaciones de contraste específicas (a menudo, los diseñadores priorizan la estética sobre la legibilidad).
• Indicadores de enfoque: Al navegar con teclado, los usuarios necesitan ver dónde están. Muchos diseños eliminan los contornos de enfoque predeterminados por razones visuales.

Las puntuaciones de Lighthouse no te protegen

Una puntuación de Lighthouse de 90+ no significa casi nada para el cumplimiento de la ADA. Lighthouse ejecuta comprobaciones automatizadas. El cumplimiento de la accesibilidad requiere pruebas manuales. Las herramientas automatizadas detectan quizás el 20-30% de los problemas. No simulan el comportamiento real del lector de pantalla ni validan la usabilidad bajo restricciones.

Los desarrolladores se apoyan en Lighthouse porque es rápido y produce un número que el cliente entiende. Ese número no se sostiene en los tribunales.

El compromiso financiero que nadie explica de antemano

Construir un sitio compatible desde el principio cuesta más.

• Construcción de sitio web básico: $3,000 – $10,000
• Construcción con enfoque en accesibilidad: $7,000 – $20,000

Esa diferencia proviene del tiempo de desarrollo adicional, pruebas manuales y conocimiento especializado. Pero aquí está el compromiso: arreglar la accesibilidad después de una demanda cuesta:

• Honorarios legales: $3,000 – $25,000+
• Costos de acuerdo: $5,000 – $50,000+
• Reconstrucción y remediación: $5,000 – $15,000

Terminas pagando el doble. A veces tres veces.

Por qué el "lo arreglaremos después" falla

La accesibilidad no es un parche. No puedes añadirla después de que el sitio esté construido sin rehacer la estructura, el código y los patrones de interacción. Las herramientas de "cumplimiento instantáneo" (overlays) que prometen arreglarlo todo con un script son, de hecho, un pasivo. No arreglan el código subyacente y, a menudo, han sido citadas en demandas. Depender de ellas demuestra negligencia, no esfuerzo.

Cómo funcionan realmente las cartas de demanda

Esto no es al azar. Los bufetes de abogados escanean sitios web en busca de fallas de accesibilidad usando herramientas automatizadas y luego verifican manualmente. Una vez que encuentran una violación, identifican a la empresa, documentan el problema y envían una carta de demanda. La mayoría de las empresas llegan a un acuerdo, no porque estén de acuerdo, sino porque luchar cuesta más.

Los sectores de alto riesgo incluyen la salud (dentistas, clínicas), hospitalidad (hoteles, sistemas de reservas), comercio electrónico, servicios legales y plataformas educativas. ¿Por qué? Porque dependen de la interacción del usuario (reservar, comprar, enviar formularios). Si esas acciones fallan para los usuarios discapacitados, el caso es más fácil de probar.

La verdad incómoda sobre los precios

Si un desarrollador cotiza $3,000 por un sitio web completo y afirma que el cumplimiento de la ADA está incluido, o está adivinando, mintiendo o desconoce lo que requiere el cumplimiento. No hay suficiente margen en ese precio para realizar las pruebas adecuadas. La accesibilidad requiere mucha mano de obra.

Conclusión: lo que realmente te protege

No son las herramientas. No son los complementos. No son las puntuaciones. Lo que te protege es el proceso:

• Pruebas manuales.
• Auditorías documentadas.
• Desarrolladores que comprenden las WCAG 2.1.
• Monitoreo continuo después del lanzamiento.

Cualquier otra cosa es una solución parcial. El verdadero problema no es la mala intención; es la confianza mal puesta. Los dueños de negocios confían en que los desarrolladores manejen el riesgo técnico, pero los desarrolladores se enfocan en el resultado visible. Esa brecha crea la exposición. Pagaste por un producto "terminado", pero la accesibilidad no estaba incluida en la definición de "terminado". Esa es la ilusión.