Más de 5.000 demandas de accesibilidad digital se presentaron en Estados Unidos solo en 2025. El 64% fue contra empresas con menos de 25 millones de dólares en ingresos anuales. WCAG 2.1 AA es el estándar técnico que hoy usan tribunales y el Departamento de Justicia de ese país. Con él deciden si un sitio cumple con la ley de accesibilidad (ADA). Si vendes algo en internet o atiendes clientes en Estados Unidos, esto ya no es un tema exclusivo de gobiernos ni de empresas grandes. Aquí tienes qué es, por qué importa y cómo se ve una auditoría real, con el caso de mi propio sitio.
Qué es WCAG 2.1 AA y en qué se diferencia de ADA
WCAG (Web Content Accessibility Guidelines) es un estándar técnico del W3C, el organismo que define los estándares de la web. No es una ley, es una lista de criterios verificables sobre cómo debe comportarse un sitio. El objetivo es que pueda usarlo una persona con alguna discapacidad, visual, motora, auditiva o cognitiva. La versión 2.1 tiene tres niveles de conformidad (A, AA, AAA); AA es el nivel intermedio y el que exige la práctica real.
Cómo se relaciona ADA con WCAG 2.1 AA
ADA (Americans with Disabilities Act) sí es una ley, aprobada en 1990 en Estados Unidos. Su texto original no menciona la web ni WCAG, porque en 1990 la web casi no existía. Durante años esa fue una zona gris. Eso cambió en 2024: el Departamento de Justicia de Estados Unidos codificó formalmente WCAG 2.1 AA como el estándar técnico vinculante para sitios y apps de gobiernos estatales y locales (Title II de ADA). En abril de 2026 el DOJ extendió esos plazos un año: las entidades grandes, de más de 50.000 habitantes, ahora tienen hasta abril de 2027, y las más pequeñas hasta abril de 2028. Los requisitos técnicos no cambiaron, solo el plazo.
Para negocios privados (Title III de ADA) no existe un plazo fijo como este. Aun así, los tribunales ya usan WCAG 2.1 AA como el criterio de referencia en las demandas.
Un detalle que conviene aclarar: el W3C ya publicó WCAG 2.2, la versión más reciente. Pero WCAG 2.1 AA sigue siendo el estándar que cita la ley y los tribunales hoy. Como 2.2 es retrocompatible con 2.1, cumplir 2.2 AA te deja dentro de 2.1 AA también. La única salvedad es que 2.2 eliminó el criterio 4.1.1 (Parsing), por lo que quien siga una política basada en 2.1 puede necesitar seguir probándolo. Desde octubre de 2025, WCAG 2.2 es también una norma ISO (ISO/IEC 40500:2025).
Por qué le importa a tu negocio, no solo a gobiernos
Los números de 2025 son el argumento más directo que existe. Más de 5.000 demandas de accesibilidad digital se presentaron en Estados Unidos ese año, y e-commerce concentró el 70% de todas ellas. El dato que de verdad rompe el mito: el 64% de las empresas demandadas factura menos de 25 millones de dólares al año. Esto no es un problema de las tiendas más grandes, es un problema de cualquier sitio con tráfico de Estados Unidos.
Tampoco es un golpe único y ya. El 46% de las demandas en cortes federales fueron contra empresas que ya habían enfrentado una demanda de accesibilidad antes. Arreglar el problema una vez y no volver a revisarlo no funciona.
Hay un atajo que muchos negocios prueban primero y que vale la pena descartar de entrada: los widgets de accesibilidad, esos scripts que se instalan con una línea y prometen «hacer tu sitio accesible» con un panel flotante. Los datos de litigio de 2025 son claros en esto: instalar un widget no redujo de forma medible las demandas contra las empresas que los usan. La razón técnica es simple: un widget cambia cómo se ve el sitio desde afuera, pero no corrige el código de debajo. En varios casos incluso interfiere con los lectores de pantalla en vez de ayudarlos.
Qué exige en la práctica: los 4 principios
WCAG organiza todos sus criterios en cuatro principios, conocidos por sus siglas en inglés como POUR:
- Perceptible: la información tiene que poder percibirse de más de una forma. Un texto alternativo en cada imagen, subtítulos en video, contraste de color suficiente entre texto y fondo.
- Operable: cualquier función del sitio tiene que poder usarse sin mouse. El ejemplo más común que falla es navegar todo el sitio con la tecla Tab. Debe haber un indicador visual claro de en qué elemento estás parado.
- Comprensible: el contenido y la forma en que funciona la interfaz no deben sorprender al usuario. Formularios con etiquetas reales, no solo un placeholder que desaparece al escribir, mensajes de error claros.
- Robusto: el código tiene que ser interpretable de forma correcta por lectores de pantalla y otras tecnologías de asistencia. Casi siempre se traduce en usar HTML semántico y atributos ARIA bien aplicados, no de más.
En la práctica, y esto lo confirmé auditando mi propio sitio, un puñado de fallas se repite mucho más que el resto: contraste de color insuficiente, foco de teclado invisible, formularios sin etiquetas reales y roles ARIA mal aplicados.
Cómo se ve una auditoría real: el caso de mi propio sitio
Toda la teoría de arriba se vuelve concreta cuando la aplicas. Audité erickpolanco.com con tres herramientas gratuitas, axe-core, WAVE y Lighthouse, porque cada una detecta cosas distintas y ninguna sola alcanza: axe se integra bien en el flujo de desarrollo. WAVE da un puntaje global fácil de seguir (AIM Score) y señala visualmente cada error sobre la página. Lighthouse mide accesibilidad junto con rendimiento y SEO en una sola pasada.
El punto de partida con WAVE fue un AIM Score de 3.4 sobre 10. Tenía 65 errores de contraste y 3 menús con atributos ARIA rotos. Con Lighthouse, en cambio, el sitio ya rondaba 96 a 100 en la mayoría de páginas, lo que confirma algo importante: ninguna herramienta sola te da el cuadro completo, cada una encuentra cosas que la otra no ve.
Los hallazgos reales y su causa
Algunos hallazgos reales, con causa identificada:
- El 83% de los errores de contraste, 54 de 65, eran en realidad un solo bug repetido: un bloque de texto en movimiento (marquee) con un gris demasiado claro sobre fondo claro. Se multiplicaba porque el mismo texto se repite varias veces en el código para el efecto de scroll infinito. Un solo cambio de color resolvió la mayoría del problema de un golpe.
- Tres menús desplegables del sitio tenían el atributo
role="menu"de ARIA, pensado para menús de aplicación con navegación por flechas, aplicado a simples menús de navegación. El arreglo correcto no fue agregar más ARIA, fue quitar ese atributo porque no correspondía. - El botón principal del header y el enlace de «saltar al contenido» perdían el indicador visual de foco al navegar con teclado. Eran invisibles para cualquiera que no use mouse.
- El formulario de contacto usaba solo
placeholderen los campos, sin una etiqueta real asociada, así que un lector de pantalla no sabía qué pedía cada campo.
Resultado: cómo quedó el sitio frente a WCAG 2.1 AA
Después de corregir esto, las páginas principales del sitio llegaron a 100/100 en Lighthouse. El inicio quedó en 96 por un aviso de contraste que, al revisarlo a mano, resulta ser un falso positivo. Esto también conecta con lo que ya cubrimos en Core Web Vitals 2026: qué cambió y cómo afecta tu ranking, ya que Lighthouse mide ambas cosas juntas. Publicé también una declaración de accesibilidad pública explicando el nivel objetivo, qué se corrigió y qué sigue pendiente. Ninguna auditoría real de este tipo termina en cero pendientes el primer día, y decirlo con honestidad es parte del proceso, no una debilidad.
Cómo saber si tu sitio cumple
- Corre axe-core, una extensión gratuita de navegador, sobre tus páginas principales.
- Corre WAVE (wave.webaim.org), gratis y sin instalar nada, para un puntaje global y una vista visual de cada error.
- Corre Lighthouse, integrado en Chrome DevTools o vía
npx lighthousedesde la terminal, para ver accesibilidad junto con rendimiento y SEO técnico, algo que también toca de lleno en SEO, GEO y AEO: la guía para posicionar tu marca en Google y en la IA. - Navega tu sitio completo solo con la tecla Tab, sin mouse, y fíjate si en todo momento ves con claridad dónde estás parado.
- Revisa el contraste real de los colores de tu marca con una herramienta de contraste, no a simple vista.
- Si encuentras problemas, corrígelos en el código, no con un widget, y publica una declaración de accesibilidad honesta sobre dónde estás parado.
Si tu sitio corre en WordPress y sospechas que tampoco está del todo bien indexado, vale la pena revisarlo de una vez: en cómo saber si tu WordPress está siendo indexado mal por Google cubro el mismo tipo de auditoría práctica, pero para indexación.
Fuentes y documentación oficial
- Web Content Accessibility Guidelines (WCAG) 2.1 (W3C): el estándar técnico oficial, con los cuatro principios y todos los criterios de conformidad.
- Web Content Accessibility Guidelines (WCAG) 2.2 (W3C): la versión más reciente, compatible con 2.1, y qué criterios agrega y elimina.
- DOJ Extends ADA Title II Web Compliance Deadline (Accessible.org): el detalle de la extensión de plazos de abril de 2026 y a quién aplica.
- ADA Web Lawsuit Trends for 2026 (UsableNet): las cifras de demandas de 2025 por sector, tamaño de empresa y el dato sobre los widgets de accesibilidad.
Preguntas frecuentes
¿WCAG 2.1 AA es obligatorio por ley?
Depende de quién seas. Para sitios de gobiernos estatales y locales en Estados Unidos sí es un requisito legal bajo el Title II de ADA. Los plazos llegan hasta 2027 o 2028, según el tamaño de la entidad. Para negocios privados no hay una ley que lo exija letra por letra. Aun así, los tribunales ya usan WCAG 2.1 AA como el criterio de referencia en las demandas bajo el Title III de ADA.
¿Un widget de accesibilidad me protege de una demanda?
Los datos de litigio de 2025 dicen que no de forma significativa. Un widget cambia la interfaz desde afuera pero no corrige el código de fondo. Varias empresas que ya lo usaban fueron demandadas de todas formas.
¿Cuánto cuesta que mi sitio cumpla WCAG 2.1 AA?
Varía mucho según qué tan lejos esté tu sitio del estándar hoy. En mi propio caso, la mayoría de los errores de contraste venía de un solo bug repetido. Por eso un cambio pequeño resolvió una parte grande del problema. Lo más barato siempre es correr una auditoría real primero y arreglar por prioridad, no adivinar.
¿Cuál es la diferencia entre WCAG 2.1 y WCAG 2.2?
WCAG 2.2 es la versión más reciente del W3C y agrega nuevos criterios sobre 2.1. Pero WCAG 2.1 AA sigue siendo el estándar legal vigente hoy. Como 2.2 es retrocompatible, cumplir 2.2 AA te deja también dentro de 2.1 AA.
