La ADA no nombra en ningún punto de su texto un estándar concreto de accesibilidad web, ya que se redactó en 1990, antes de que existiera la web moderna. En la práctica, sin embargo, el cumplimiento de la ADA en un sitio web significa alcanzar la WCAG 2.1 nivel AA: esa es la referencia que señalan de forma constante los tribunales, los acuerdos y las orientaciones del Departamento de Justicia, aunque nunca se haya incorporado formalmente a la normativa de la ADA para sitios web.

Por qué no existe un estándar técnico oficial

El Título III de la Ley de Estadounidenses con Discapacidades (ADA) exige que los “lugares de acceso público” sean accesibles, y los tribunales en general han interpretado que eso se extiende a los sitios web y las aplicaciones móviles, al menos para negocios vinculados a un local físico o que ofrecen bienes y servicios al público. Pero como la ley es anterior a la web, no hay una normativa que detalle exactamente cómo debe ser, técnicamente, un sitio web conforme con la ADA. Ese vacío se ha llenado de manera informal: los acuerdos de conciliación del Departamento de Justicia, los decretos de conformidad y la inmensa mayoría de las sentencias judiciales toman la WCAG 2.1 AA como estándar práctico, aunque no esté formalmente incorporada a la normativa de la ADA.

El Departamento de Justicia ha publicado orientaciones a lo largo de los años que confirman que la ADA se aplica a los sitios web, y ha hecho referencia a la WCAG en varios acuerdos de conciliación y documentos de asistencia técnica, pero no ha llegado a emitir una normativa formal con el nivel de detalle que muchas empresas desearían. Eso deja a la WCAG 2.1 AA como una referencia informal pero bien asentada, y no como una lista de comprobación exigida legalmente, una distinción que importa en los tribunales pero que rara vez cambia lo que una empresa debe hacer en la práctica, ya que el objetivo real termina siendo el mismo en cualquiera de los dos casos.

A quién le corresponde cumplir

“Lugar de acceso público” se interpreta de forma amplia e incluye en general a comercios minoristas, restaurantes, hoteles, proveedores de salud, servicios financieros y muchos otros tipos de negocio con un sitio web orientado al público, sin importar el tamaño de la empresa. En la práctica, a las empresas muy pequeñas se les demanda con menos frecuencia, simplemente porque los litigios tienden a dirigirse a sitios con tráfico relevante o a la atención de demandantes recurrentes, pero no existe una exención formal para pequeñas empresas escrita en la ley, como sí ocurre en otras normativas de accesibilidad.

También existe una distinción práctica importante entre las empresas vinculadas a un local físico y los negocios exclusivamente digitales. Los tribunales han sido más constantes al aplicar la ADA a sitios ligados a una presencia física, ya que el argumento del “nexo” (que el sitio web es una extensión de un lugar de acceso público físico) tiene un terreno legal más asentado. Los negocios puramente digitales se han enfrentado a una jurisprudencia más dispar entre los distintos circuitos federales, aunque la tendencia general ha seguido moviéndose hacia una cobertura más amplia y no más reducida.

Qué exige realmente el cumplimiento

La WCAG 2.1 AA abarca un amplio abanico de requisitos: contraste de color suficiente, navegabilidad exclusivamente por teclado, texto alternativo con sentido en las imágenes, campos de formulario correctamente etiquetados, subtítulos en el contenido de vídeo y una estructura de encabezados lógica que funcione con lectores de pantalla, entre muchos otros. Es un estándar genuinamente amplio, no una lista breve, lo que explica en parte por qué el cumplimiento completo requiere un trabajo real y no un único ajuste.

Un dato útil sobre lo lejos que está todavía el sitio promedio de este nivel: el informe WebAIM Million de 2026 encontró que el 95,9% de las páginas de inicio tenía al menos un fallo detectable de la WCAG 2, con texto de bajo contraste presente por sí solo en el 83,9% de las páginas de inicio, el tipo de fallo más común de todos. La mayoría de los sitios, estén o no cubiertos por la ADA, tienen carencias reales por cerrar.

El mismo estudio encontró una media de 56,1 errores detectables por página de inicio, una cifra que merece la pena detenerse a considerar. No se trata de uno o dos detalles pasados por alto, sino de decenas de problemas individuales en una página típica, lo que da una idea bastante clara de por qué un esfuerzo genuino de cumplimiento de la WCAG 2.1 AA exige un trabajo real y sostenido, y no una revisión rápida por parte de quien construyó el sitio originalmente.

Dónde encajan los widgets y dónde no

Los widgets de superposición, ofrecidos por proveedores como accessiBe y UserWay, se instalan con una etiqueta de script y pueden resolver rápidamente ciertos problemas superficiales, como ajustar el tamaño del texto, modificar el contraste o añadir cierto soporte de navegación por teclado. Lo que en general no pueden hacer de forma fiable es corregir problemas que tienen su raíz en el marcado subyacente del sitio, como un formulario que no está correctamente etiquetado en el código o un componente personalizado que no expone los roles ARIA adecuados. Los reguladores han mostrado una postura especialmente escéptica ante las afirmaciones basadas únicamente en superposiciones: en 2025 la FTC ordenó a accessiBe pagar 1.000.000 de dólares para resolver cargos por afirmaciones engañosas sobre cuánto de un sitio podía corregir automáticamente accessWidget, junto con acusaciones relacionadas con reseñas de clientes pagadas.

Eso no significa que todos los proveedores de esta categoría operen de la misma manera. AudioEye, por ejemplo, combina su widget automatizado con pruebas manuales supervisadas por personas en lugar de ofrecer solo automatización, un enfoque más alineado con lo que realmente exige un programa genuino de cumplimiento de la WCAG 2.1 AA.

Qué hacer si ha recibido una carta de requerimiento

Las cartas de requerimiento y las demandas por accesibilidad web bajo la ADA son lo bastante habituales como para que tener un plan sea importante. El primer paso es encargar una auditoría WCAG 2.1 AA real, idealmente una que incluya pruebas manuales y no dependa únicamente de un escaneo automatizado, ya que las herramientas automatizadas solo detectan de forma fiable una parte de los problemas reales. A partir de ahí, priorice las correcciones según la gravedad y cuántos usuarios afecta cada problema, e incorpore a un abogado con experiencia en reclamaciones web del Título III de la ADA antes de responder a cualquier carta, ya que la estrategia de respuesta tiene implicaciones legales reales más allá de la propia corrección técnica.

Vale la pena resistir la tentación de responder de forma defensiva o desdeñosa a una carta de requerimiento antes de haber revisado realmente su sitio. Muchas cartas de requerimiento, sea cual sea su motivación, señalan problemas reales, y contar ya con un plan de corrección documentado en marcha suele colocar a la empresa en una posición mucho más sólida, ya sea porque ese plan termina influyendo en las conversaciones de conciliación o simplemente porque cierra la carencia de fondo antes de que se convierta en un blanco recurrente.

Publicar una declaración de accesibilidad

Una declaración pública de accesibilidad no es un requisito legal específico de la ADA, pero se ha convertido en una práctica habitual y útil de todos modos. Una buena declaración nombra el estándar hacia el que se trabaja (normalmente la WCAG 2.1 AA), describe lo que se ha hecho hasta el momento y ofrece a los visitantes una forma de informar sobre problemas concretos que encuentren. No sustituye al trabajo de corrección real, y los tribunales en general no consideran una declaración por sí sola como prueba de cumplimiento, pero sí transmite un esfuerzo documentado y continuo en lugar de un problema sin atender, y le da un canal directo para conocer los problemas antes de que se conviertan en una reclamación legal.

Construir el cumplimiento a largo plazo

Una corrección puntual no se sostiene con el tiempo, a medida que el contenido y el código de un sitio siguen cambiando. Un enfoque duradero suele combinar una auditoría real frente a la WCAG 2.1 AA, correcciones a nivel de desarrollo para los problemas estructurales y alguna forma de monitorización continua, de modo que el contenido nuevo no reintroduzca silenciosamente problemas antiguos. Una nueva página de producto añadida sin texto alternativo adecuado, un formulario nuevo construido sin campos etiquetados o un nuevo banner promocional que no cumple los requisitos de contraste pueden, cada uno, reabrir una carencia que ya se había cerrado, y por eso tratar la accesibilidad como un proyecto puntual en lugar de una disciplina continua suele producir un cumplimiento que se erosiona en uno o dos años.

Vale la pena recordar que el cumplimiento de la ADA en un sitio web no es puramente un ejercicio legal, aunque la exposición legal sea a menudo lo que impulsa a una empresa a actuar. El objetivo de fondo es que las personas con discapacidad, ya sea ceguera, baja visión, discapacidad motriz o diferencias cognitivas, puedan realmente usar el sitio para explorar, comparar y comprar del mismo modo que cualquier otro cliente. Un sitio que técnicamente supera un escaneo automatizado pero que en la práctica resulta muy difícil de navegar para un usuario de lector de pantalla no ha alcanzado realmente lo que persigue el estándar, aunque sobreviva a una revisión superficial. Mantener presente ese objetivo de fondo suele producir mejores decisiones de priorización que tratar cada criterio de la WCAG como una simple casilla aislada por marcar.

Nuestra guía sobre cómo elegir entre un widget y una auditoría manual profundiza en cómo secuenciar ese trabajo según el tamaño y el presupuesto de su sitio.