En 2025, los demandantes presentaron 3,117 demandas de accesibilidad web bajo el Título III de la ADA en tribunales federales, lo que representa un aumento del 27 por ciento respecto a 2024 y la cifra anual más alta desde 2022. Si se suman las presentaciones en tribunales estatales, el total supera las 5,000. Incluso esa cifra principal subestima la presión: los abogados defensores estiman que el año pasado se enviaron entre 35,000 y 50,000 cartas de demanda de accesibilidad a empresas estadounidenses, la mayoría de las cuales se liquidan de forma privada por montos de entre 1,000 y 25,000 dólares sin llegar a figurar en un expediente judicial.
Si su empresa gestiona un sitio web, una aplicación móvil, una tienda en línea, un widget de reservas o un portal de clientes, ahora es un objetivo realista. Y los demandantes en serie ya no se limitan a un pequeño grupo de litigantes recurrentes: aproximadamente el 40 por ciento de las presentaciones federales del Título III de la ADA en 2025 provinieron de personas que se representan a sí mismas, muchas de las cuales utilizan escáneres impulsados por IA para identificar posibles demandados y redactar quejas en cuestión de minutos.
Esta guía detalla lo que realmente requiere el Título III de la ADA para las experiencias digitales, por qué el Nivel AA de las WCAG 2.1 se ha convertido en el estándar de facto, cómo es una hoja de ruta de remediación y cómo construir un registro defendible antes de que llegue una carta de demanda.
Por qué su sitio web está ahora dentro del alcance del Título III de la ADA
El Título III de la Ley sobre Estadounidenses con Discapacidades prohíbe la discriminación por motivos de discapacidad en lugares de alojamiento público. El estatuto fue redactado en 1990 y nunca mencionó explícitamente los sitios web o las aplicaciones móviles, pero los tribunales han pasado la última década resolviendo esa ambigüedad, casi siempre a favor de los demandantes.
El legado de Robles contra Domino's Pizza
El caso más importante es Robles v. Domino's Pizza. Guillermo Robles, un demandante ciego en California, demandó a Domino's en 2016 tras descubrir que no podía utilizar el sitio web o la aplicación móvil de la cadena de pizzerías con un lector de pantalla. El tribunal de distrito inicialmente desestimó el caso por motivos de debido proceso, razonando que, sin regulaciones publicadas sobre accesibilidad web, Domino's no tenía un aviso justo de lo que requería el cumplimiento.
El Noveno Circuito revocó esa decisión en 2019. El tribunal sostuvo que el Título III cubría el sitio web y la aplicación de Domino's porque tenían un nexo con un lugar físico de alojamiento público (los restaurantes de pizza), y que imponer responsabilidad no violaba el debido proceso incluso sin estándares técnicos publicados. La Corte Suprema se negó a revisar la decisión del Noveno Circuito a finales de ese año, dejando la norma en vigor. Domino's finalmente llegó a un acuerdo en junio de 2022 tras seis años de litigio.
El efecto práctico es que cualquier empresa con una ubicación física —y, en muchos circuitos, incluso las empresas puramente en línea— se enfrenta ahora a una exposición real por un sitio web inaccesible.
La norma del Título II de 2024 del DOJ y su repercusión en el Título III
En abril de 2024, el Departamento de Justicia (DOJ) emitió una norma final bajo el Título II de la ADA que exige que los sitios web y las aplicaciones móviles de los gobiernos estatales y locales cumplan con el Nivel AA de las WCAG 2.1. Aunque esa norma vincula formalmente solo a las entidades públicas, los demandantes y los tribunales comenzaron inmediatamente a citarla como la articulación federal más autorizada de lo que significa "accesible".
Para una empresa privada, el cálculo legal cambió de la noche a la mañana. Incluso si el Título III todavía no tiene un estándar técnico publicado, un demandante ahora puede señalar una regulación federal vinculante que nombra al Nivel AA de las WCAG 2.1 como el estándar para entidades del Título II materialmente similares. La mayoría de los abogados defensores aconsejan ahora a sus clientes del Título III que traten el Nivel AA de las WCAG 2.1 como el requisito mínimo.
Lo que realmente requiere el Nivel AA de las WCAG 2.1
Las WCAG (Pautas de Accesibilidad para el Contenido Web), mantenidas por el World Wide Web Consortium, se organizan en torno a cuatro principios, resumidos convenientemente por el acrónimo POUR: Perceptible, Operable, Comprensible y Robusto. El Nivel AA incluye todos los criterios de conformidad del Nivel A más criterios adicionales específicos de AA. Hay 50 criterios de conformidad en total en el Nivel AA, pero unos pocos impulsan la gran mayoría de las cartas de demanda.
Contraste de color (1.4.3 y 1.4.11)
El texto del cuerpo debe tener una relación de contraste de al menos 4.5:1 con respecto a su fondo. El texto grande (18 puntos o 14 puntos en negrita) necesita al menos 3:1. Los botones, los bordes de los campos de formulario, los indicadores de enfoque y otros elementos gráficos interactivos deben cumplir con un 3:1 frente a los colores adyacentes. Muchas cartas de demanda se originan aquí porque los escáneres automáticos detectan fallos de contraste en segundos.
Alternativas de texto para contenido no textual (1.1.1)
Cada imagen, icono, gráfico, foto y elemento gráfico que transmita significado necesita un atributo alt que proporcione la misma información. Las imágenes decorativas reciben un atributo alt vacío (alt="") para que los lectores de pantalla las omitan. Los logotipos deben describir la marca. Los gráficos e infografías necesitan un equivalente de texto más largo cercano o enlazado. Los iconos de entrada de formulario necesitan etiquetas. Los CAPTCHAs necesitan una alternativa de audio.
Operabilidad del Teclado (2.1.1, 2.1.2, 2.4.3, 2.4.7)
Cada elemento interactivo —menús, modales, carruseles, acordeones, pestañas, menús desplegables personalizados— debe ser accesible y operable utilizando únicamente el teclado. Los usuarios nunca deben quedar atrapados dentro de un widget sin forma de salir (el clásico fallo del "modal que no se cierra sin un ratón"). El orden de enfoque debe ser lógico y siempre debe haber un indicador de enfoque visible que muestre dónde se encuentra el usuario en la página.
Etiquetas de Formulario, Errores e Instrucciones (1.3.1, 3.3.1, 3.3.2, 3.3.3, 3.3.4)
Cada entrada de formulario necesita una etiqueta asociada programáticamente (un elemento <label for=""> o un aria-label). Los mensajes de error deben identificar qué campo falló y qué hacer al respecto. Para formularios de alta importancia (pago, creación de cuentas, reconocimientos legales), los usuarios necesitan una oportunidad para revisar y corregir antes del envío.
Subtítulos y Audiodescripciones (1.2.2, 1.2.5)
El video pregrabado necesita subtítulos sincronizados. Si se transmite información esencial de forma visual y no en la pista de audio, también se necesitan audiodescripciones. El video en vivo en el Nivel AA requiere subtítulos en directo.
Estructura de Encabezados y Puntos de Referencia (1.3.1, 2.4.6)
Los encabezados deben seguir una jerarquía lógica (h1 → h2 → h3, sin saltar niveles arbitrariamente). Utilice elementos HTML semánticos —<nav>, <main>, <header>, <footer>— o puntos de referencia ARIA para que los usuarios de lectores de pantalla puedan saltar a la sección que deseen. Evite dar estilo a un <div> para que parezca un encabezado sin asignarle el rol semántico adecuado.
Redimensionamiento y Reajuste (1.4.4, 1.4.10)
El texto debe seguir siendo legible con un zoom del 200 por ciento sin necesidad de desplazamiento horizontal. Los diseños deben reajustarse (reflow) en una ventana gráfica de 320 píxeles CSS sin desplazamiento bidimensional.
Dónde se Concentran las Demandas
Tres distritos federales concentran la mayor parte de las presentaciones de accesibilidad web: el Distrito Sur de Nueva York, el Distrito Central de California y el Distrito Sur de Florida. Nueva York lidera por un amplio margen, en parte porque la Ley de Derechos Humanos del Estado de Nueva York y la Ley de Derechos Humanos de la Ciudad de Nueva York proporcionan mecanismos legales estatales adicionales y barreras de alegación más bajas que las reclamaciones federales bajo la ADA.
California añade la Ley de Derechos Civiles Unruh, que establece 4.000 dólares en daños legales por violación por demandante. Eso cambia drásticamente el cálculo de los acuerdos: una reclamación pequeña puede convertirse rápidamente en una exposición de seis cifras si se certifica una demanda colectiva.
Florida ha surgido como el tercer centro desde 2020, con un puñado de firmas de demandantes que desarrollan prácticas de alto volumen dirigidas a cadenas de restaurantes, marcas de hostelería y tiendas de comercio electrónico directo al consumidor.
Creación de una Hoja de Ruta de Remediación
Si recibe una carta de requerimiento —o, mejor aún, si actúa antes de que llegue una— el trabajo se divide aproximadamente en cinco fases. Trate esto como un proyecto con un presupuesto y una fecha límite, no como una auditoría de una sola vez.
Fase 1: Auditoría Automatizada y Manual
Comience con un escaneo automatizado utilizando una herramienta como axe DevTools, WAVE o Google Lighthouse. Las herramientas automatizadas detectan entre el 30 y el 50 por ciento de los fallos de las WCAG; el resto requiere pruebas manuales con un lector de pantalla (NVDA en Windows, VoiceOver en macOS e iOS, TalkBack en Android), navegación solo por teclado y pruebas de zoom y reajuste.
Documente cada fallo con el criterio de las WCAG violado, la página o plantilla afectada, la gravedad y un esfuerzo estimado de remediación. Este registro de auditoría se convierte en la columna vertebral de cada fase posterior.
Fase 2: Sistema de Diseño y Correcciones de Componentes
La mayoría de los fallos de mayor volumen residen en su sistema de diseño: contraste de botones, indicadores de enfoque, entradas de formulario, patrones de modales, controles de carrusel, menús de navegación. Corregir el componente una vez corrige cada instancia del mismo. Priorice los componentes que aparecen en la mayoría de las páginas.
Fase 3: Revisión de Contenido
El texto alternativo, los subtítulos de video, la estructura de encabezados y las etiquetas de formulario suelen ser correcciones a nivel de contenido que afectan a la mayoría de las plantillas y páginas. Cree una lista de verificación de contenido que los autores deban seguir para cada página nueva y un elemento en el backlog para corregir retroactivamente las páginas existentes.
Fase 4: Coordinación con Proveedores Externos
La mayoría de los sitios web modernos integran widgets de terceros: formularios de pago, chat en vivo, calendarios de reservas, reproductores de video, capas de analítica, widgets de reseñas y ventanas emergentes de captura de correo electrónico. Cada uno de estos puede introducir sus propios fallos de accesibilidad, y los tribunales bajo el Título III generalmente han sostenido que una empresa es responsable de la accesibilidad del código de proveedor que integra en su propio sitio.
Para cada proveedor, solicite un VPAT (Plantilla Voluntaria de Accesibilidad de Producto) actualizado o un Informe de Conformidad de Accesibilidad. Verifique que la versión que entregan cumpla con las WCAG 2.1 Nivel AA. Presione a los proveedores que no cumplan para que remedien la situación o reemplácelos.
Fase 5: Declaración de Accesibilidad y Canal de Retroalimentación
Publique una declaración de accesibilidad claramente enlazada que indique el estándar que pretende cumplir (normalmente WCAG 2.1 Nivel AA), las limitaciones conocidas y un canal de contacto (correo electrónico y teléfono) para que los usuarios informen sobre problemas de accesibilidad. La declaración no proporciona inmunidad legal, pero documenta la buena fe y ofrece a quienes responden a las cartas de requerimiento algo concreto a lo que remitirse.
Una palabra sobre las superposiciones de accesibilidad
Una industria en auge de herramientas de "superposición de accesibilidad" —widgets de JavaScript que prometen el cumplimiento instantáneo de las WCAG mediante una sola línea de código— afirma resolver la accesibilidad de forma rápida y económica. La realidad es más complicada. Las superposiciones han sido citadas en docenas de demandas por causar problemas de accesibilidad al interferir con las tecnologías de asistencia de los usuarios. Varios tribunales han rechazado el argumento de que una superposición por sí sola es suficiente para desestimar una reclamación bajo el Título III.
Las superposiciones pueden tener un papel como complemento de la remediación subyacente —para usuarios que necesitan aplicar sus propias preferencias sobre un sitio que ya es accesible— pero no sustituyen la corrección del código base. Los bufetes de abogados de los demandantes ahora se dirigen específicamente a sitios que ejecutan ciertos productos de superposición.
Documente todo para su defensa
Cuando llega una carta de requerimiento, su estrategia de defensa depende casi por completo de lo que pueda demostrar sobre su programa de accesibilidad en el momento de la supuesta infracción. Construya un rastro documental que incluya:
- Informes de auditoría fechados que muestren el alcance y los hallazgos
- Tickets de remediación con fechas de cierre
- VPAT de proveedores e informes de conformidad de accesibilidad
- Registros de capacitación para diseñadores y desarrolladores
- Listas de verificación internas de revisión de accesibilidad vinculadas a los lanzamientos de productos
- Un registro de cambios para la declaración de accesibilidad
- Comentarios de los usuarios recibidos a través de su canal de contacto de accesibilidad y su respuesta a los mismos
Estos registros no evitan las demandas, pero cambian drásticamente las negociaciones de liquidación. Un demandante que espera un acuerdo rápido de 10,000 USD por "molestias" está mucho menos interesado cuando el demandado puede presentar una auditoría actual, un historial documentado de remediación y un VPAT del proveedor para cada widget integrado.
El aspecto contable del cumplimiento de la accesibilidad
La remediación de la accesibilidad rara vez es un gasto único. Por lo general, aparece en sus libros como un gasto recurrente: facturas de agencias o contratistas por auditorías, licencias de software para herramientas de prueba y servicios de monitoreo, costos de reconstrucción del sistema de diseño, costos de cambio de proveedor y los inevitables acuerdos por cartas de demanda que se filtran a pesar de sus mejores esfuerzos.
Rastrear estos gastos por separado de los gastos generales de marketing o ingeniería facilita varias cosas. Obtiene una visión clara del costo real de cumplimiento a lo largo del tiempo, lo que ayuda al presupuestar el programa del próximo año. Documenta el gasto si más adelante necesita reclamar una deducción o amortizar una mejora capitalizada del sitio web. Y si alguna vez se enfrenta a una demanda colectiva de un demandante en serie, puede presentar rápidamente un registro financiero de su inversión de buena fe en accesibilidad, lo cual es útil tanto en las negociaciones de acuerdo como en cualquier defensa de modificación razonable.
Un segmento simple del plan de cuentas para "Cumplimiento de accesibilidad" con subcategorías para auditorías, mano de obra de remediación, herramientas de prueba, diligencia debida de proveedores y reservas para acuerdos ayuda mucho. Vincúlelo con revisiones trimestrales para que el programa no se desvíe silenciosamente del presupuesto.
Errores comunes que se deben evitar
Algunos patrones aparecen en casi todas las cartas de requerimiento que veo recibir a los dueños de negocios.
Tratar la accesibilidad como un proyecto de una sola vez. Los sitios cambian constantemente. Una nueva página de producto, un proceso de pago rediseñado, un chatbot integrado; cualquiera de estos puede introducir fallos nuevos. Integre la accesibilidad en su ciclo de vida de desarrollo para que cada cambio se verifique antes de su implementación.
Confiar enteramente en escaneos automatizados. Las herramientas automatizadas detectan una minoría de los fallos de las WCAG. Las pruebas manuales con tecnología de asistencia son la única forma de encontrar problemas como un orden de enfoque ilógico, texto alternativo engañoso o widgets personalizados inutilizables.
Ignorar las aplicaciones móviles. Los demandantes del Título III presentan cada vez más reclamaciones duales que cubren tanto el sitio web como la aplicación móvil nativa. iOS y Android tienen cada uno sus propias API de accesibilidad (UIAccessibility y TalkBack/AccessibilityService), y se aplican los mismos principios de las WCAG, pero requieren pruebas específicas para cada plataforma.
Olvidarse de los PDF. Los formularios de impuestos, libros blancos, menús y recursos descargables alojados en su sitio están todos dentro del alcance. Los PDF necesitan un orden de lectura adecuado, etiquetas, texto alternativo y etiquetas de campos de formulario al igual que las páginas HTML.
Asumir que una plataforma de terceros se encarga de ello por usted. Shopify, WordPress, Wix, Squarespace y plataformas similares proporcionan cierta estructura de accesibilidad, pero las elecciones de temas, el código personalizado, los widgets integrados y el contenido que publica siguen siendo su responsabilidad. Una carta de requerimiento no distingue si un tema ya venía preconstruido.
Omitir la declaración de accesibilidad. No cuesta nada publicarla y proporciona evidencia demostrable de buena fe. La ausencia de una a veces se cita específicamente en las quejas.
Mantenga las finanzas de su cumplimiento organizadas desde el primer día
A medida que construye su programa de accesibilidad, los registros financieros de respaldo —facturas de auditoría, acuerdos con proveedores, mano de obra de remediación, costos de capacitación y reservas para acuerdos— deben vivir en un lugar donde pueda encontrarlos dentro de unos años si un demandante en serie nombra a su empresa. Beancount.io ofrece contabilidad en texto plano que le brinda total transparencia e historial controlado por versiones sobre cada partida, sin cajas negras y sin dependencia de un solo proveedor. Comience gratis y vea por qué los desarrolladores, los equipos financieros y los operadores conscientes del cumplimiento eligen la contabilidad en texto plano para mantener un registro defendible en una auditoría.