La Carta de Reclamo Que Parece Spam, Hasta Que la Lee Dos Veces

Un cliente me reenvió hace unos meses un correo con el asunto "Aviso de Infracción de Accesibilidad Web". Su primer instinto fue borrarlo — parecía uno más de los intentos de estafa que llegan a diario a cualquier bandeja de entrada de una pequeña empresa. No era spam. Era una carta de reclamo formal de un abogado, citando páginas específicas de su sitio, criterios de éxito de WCAG que su sitio incumplía, y una cifra de acuerdo extrajudicial para que el problema desapareciera en silencio. Nunca había oído hablar de WCAG. No tenía idea de que su formulario de contacto, las imágenes de sus productos o su paleta de colores pudieran exponerlo a una acción legal. En mi experiencia, esa reacción — sorpresa genuina seguida de "¿esto es real?" — es la respuesta más común que veo en dueños de negocio.

No escribo esto para asustar a nadie y venderle un widget de accesibilidad. Lo escribo porque he visto suficientes de estos casos llegar a los escritorios de mis clientes como para saber que el cumplimiento de accesibilidad pasó silenciosamente de ser "un plus" a ser un riesgo operativo, y la mayoría de los dueños de PyMEs gestionan ese riesgo sin ninguna visibilidad sobre él.

Por Qué Este Riesgo Crece, No Disminuye

Las demandas por accesibilidad web bajo el Título III de la Ley de Estadounidenses con Discapacidades (ADA) vienen en aumento constante desde hace años, y los informes recientes ubican a 2025 como el año con mayor volumen de este tipo de demandas registrado hasta ahora, con un crecimiento que ya se extiende mucho más allá de los focos tradicionales de Nueva York, Florida y California. Estados como Illinois, Missouri y Minnesota han visto un aumento marcado en demandas contra negocios locales que nunca se consideraron un blanco de litigio.

Algunas dinámicas explican esta tendencia:

  • Demandantes recurrentes y estudios jurídicos especializados. Un número relativamente pequeño de estudios presenta una porción muy grande de estas demandas, a menudo contra varios negocios la misma semana usando plantillas casi idénticas.
  • Preparación de casos más barata. Las herramientas de escaneo automatizado pueden detectar fallas evidentes de WCAG en miles de sitios en un solo día, lo que abarata construir una lista de futuros demandados.
  • Un conocimiento creciente entre abogados demandantes de que los widgets "overlay" de solución rápida no son una defensa real — vuelvo sobre esto más abajo.
  • Impulso regulatorio. La regla del Título II del Departamento de Justicia ya exige que los sitios web de gobiernos estatales y locales cumplan con WCAG 2.1 AA en un plazo definido. Esa regla no aplica directamente a negocios privados, pero refuerza a WCAG 2.1 AA como el estándar que tribunales y reguladores citan cuando se litigan demandas privadas.

Nada de esto significa que todo negocio será demandado. Significa que la probabilidad ya no es despreciable, y que el costo de prevenir es mucho menor que el costo de una carta de reclamo, un acuerdo y la corrección que de todos modos habría que hacer.

Qué Pide Realmente WCAG

Las Pautas de Accesibilidad para el Contenido Web definen tres niveles de conformidad, y entenderlos ayuda a fijar una meta realista en lugar de adivinar:

  • Nivel A — la base. Cubre las barreras más severas, como contenido totalmente inutilizable con teclado o lector de pantalla. Cumplir solo el Nivel A todavía deja un sitio difícil de usar para muchas personas con discapacidad.
  • Nivel AA — el nivel que tribunales y acuerdos de conciliación citan casi universalmente. Cubre relaciones de contraste de color, texto redimensionable, navegación consistente, indicadores de foco visibles y etiquetas significativas en elementos interactivos. WCAG 2.1 AA (o el más reciente WCAG 2.2 AA) es el objetivo práctico para cualquier sitio comercial.
  • Nivel AAA — el nivel más exigente, generalmente reservado para contenido gubernamental o de salud altamente especializado. El propio W3C no recomienda AAA como política general, ya que algunos criterios de AAA entran en conflicto con necesidades normales de diseño y contenido.

A todos mis clientes les recomiendo apuntar a WCAG 2.1 AA como piso, con la mira puesta en 2.2 AA cuando no implique rediseñar de forma disruptiva. Esa sola decisión resuelve la mayor parte del debate de "cuán accesibles necesitamos ser" antes de que empiece.

Las Fallas Que Realmente Encuentro en las Auditorías de Clientes

Cuando reviso la accesibilidad del sitio de un cliente, aparecen una y otra vez los mismos problemas, sin importar el rubro:

  • Texto alternativo ausente o descuidado en fotos de producto, logos e íconos — vacío, o directamente el nombre del archivo (IMG_4021.jpg), lo cual es funcionalmente inútil para un lector de pantalla.
  • Contraste de color insuficiente, especialmente texto gris claro sobre fondo blanco, o colores de marca usados en el cuerpo del texto que se ven bien para un diseñador vidente pero no cumplen la relación de contraste 4.5:1 exigida para texto normal.
  • Trampas de teclado y estados de foco invisibles — botones y menús que solo funcionan con el mouse, o que no dan ninguna señal visual de dónde está el foco del teclado.
  • Campos de formulario sin etiquetas programáticas — un placeholder no es una etiqueta. Los usuarios de lectores de pantalla necesitan un elemento <label> real vinculado al campo.
  • Contenido de video y audio sin subtítulos ni transcripciones, lo cual además perjudica el SEO, porque los buscadores tampoco pueden indexar contenido de audio.
  • Estructuras de encabezado que saltan niveles o existen solo por estética, rompiendo el esquema lógico que los usuarios de lectores de pantalla necesitan para navegar la página.

Una lista de verificación práctica para empezar en cualquier sitio de PyME:

  1. Correr un escaneo automatizado (existen herramientas gratuitas y de bajo costo) para detectar los problemas evidentes de contraste, texto alternativo y etiquetas.
  2. Recorrer todo el sitio usando solamente el teclado — sin mouse — y anotar dónde se queda atascado o pierde de vista el foco.
  3. Revisar cada formulario en busca de etiquetas reales, no solo texto de placeholder.
  4. Verificar que toda imagen con contenido relevante tenga texto alternativo descriptivo, y que las imágenes decorativas estén marcadas como tales.
  5. Probar las relaciones de contraste sobre la paleta de marca real, no solo sobre el texto del cuerpo.
  6. Agregar subtítulos a todo contenido de video, aunque sea autogenerado como punto de partida.

Por Qué los Widgets Overlay No Son la Solución Que Usted Cree

Me preguntan constantemente por los widgets "overlay" de accesibilidad en JavaScript que prometen cumplimiento ADA instantáneo por una cuota mensual. No los recomiendo, y no soy el único — los abogados demandantes ya se volvieron lo suficientemente hábiles como para que una porción significativa de las demandas recientes apunte específicamente a sitios que usan estos overlays, porque el código subyacente sigue roto y el overlay es fácil de detectar. Un overlay puede ajustar el tamaño de fuente o el contraste en la superficie, pero no puede reescribir su HTML para agregar etiquetas reales, corregir la estructura de encabezados, ni hacer que un widget de JavaScript a medida sea operable con teclado. Corregir la accesibilidad a nivel de código y contenido exige más esfuerzo inicial, pero es la única versión de "cumplimiento" que realmente resiste una revisión legal.

Esto se cruza en la práctica con otras dos áreas sobre las que escribo con frecuencia. Un sitio no puede ser genuinamente accesible si no es también responsive en todos los dispositivos, ya que los lectores de pantalla móviles y el comportamiento de zoom dependen de un marcado responsive sólido. Y las correcciones de accesibilidad suelen cruzarse con el trabajo técnico detrás de la optimización de Core Web Vitals — el HTML semántico, una estructura de encabezados correcta y un marcado liviano y bien etiquetado tienden a mejorar ambos puntajes a la vez.

Trátelo Como Gestión de Riesgo, No Como un Casillero para Tildar

Si tuviera que darle una sola recomendación a un dueño de negocio que lee esto, sería que deje de tratar la accesibilidad como una preferencia de diseño y empiece a tratarla como cualquier otra exposición de cumplimiento normativo — seguros, privacidad de datos, derecho laboral. No necesita llegar a la perfección de AAA. Necesita un esfuerzo documentado y de buena fe hacia WCAG 2.1 AA, un plan para cerrar las brechas que encuentre, y alguien que revise el sitio periódicamente a medida que el contenido cambia, porque una página de inicio que hoy cumple puede dejar de cumplir en el momento en que se publica un nuevo artículo de blog sin texto alternativo.

Los negocios que vi terminar demandados no actuaban de mala fe — simplemente nunca miraron. Esa es la parte que sí se puede corregir.

Hablemos de su situación.