¿La accesibilidad web es obligatoria por ley? Lo que la EAA, las multas y la trampa de los overlays significan para tu sitio en 2026

¿Qué leyes te obligan, exactamente?

Varios marcos que se solapan alcanzan hoy a casi cualquier sitio al público, y todos apuntan a un mismo estándar técnico: WCAG 2.1 AA. En la Unión Europea, la European Accessibility Act (Directiva 2019/882) entró en vigor el 28 de junio de 2025; en España la transponen la Ley 11/2023 y el Real Decreto 193/2023, que extienden la obligación al sector privado —comercio electrónico, banca, transporte—, más allá de la Administración, que ya estaba obligada por el Real Decreto 1112/2018 (inSuit, 2026). El estándar técnico de referencia es la norma UNE-EN 301549:2022, que incorpora WCAG 2.1 AA y la amplía a software, aplicaciones móviles, documentos y hardware (inSuit, 2025).

El alcance es más amplio de lo que parece. La EAA considera al e-commerce un sector clave, así que una microempresa con menos de 10 empleados o menos de 2 millones de euros de facturación que vende por internet tampoco queda exenta (Inclusif, 2025). Y la frontera no te protege: si vendes a Estados Unidos, los tribunales aplican la ADA a tu web; si vendes a la UE, te alcanza la EAA, sin importar dónde estés. En Latinoamérica, la Convención de la ONU sobre los Derechos de las Personas con Discapacidad —ratificada en la región— reconoce la accesibilidad digital como un derecho, y varios países tienen su propia norma. La conclusión práctica para casi cualquier negocio: construye a WCAG 2.1 AA como piso, apunta a 2.2, y habrás respondido al estándar al que apuntan todos estos marcos a la vez.

¿Cuánto te puede costar incumplir?

Bastante, y por primera vez con multas de verdad. Hasta 2025, la norma española de accesibilidad privada carecía de un mecanismo sancionador efectivo; con la EAA, el incumplimiento ya conlleva sanciones reales (inSuit, 2026). En España las multas van desde 301 euros por faltas leves hasta 1.000.000 de euros por las muy graves (DaaS Group, 2026), y un producto o servicio digital no conforme puede ser retirado del mercado de la UE hasta corregirse (Inclusif, 2025).

Al costo legal se suma el reputacional. Una aerolínea fue multada con 90.000 euros por una web con cerca del 70% de los requisitos de accesibilidad incumplidos (Inclusif, 2025) — el tipo de noticia que daña la imagen pública de una marca. Y si operas también en Estados Unidos, el panorama es más duro: allí se presentaron más de 5.000 demandas de accesibilidad web en 2025, con el comercio electrónico como blanco principal, porque un proceso de pago que un cliente con discapacidad no puede completar es a la vez fácil de documentar y una venta perdida. La cuenta cambia cuando sumas multa, honorarios, remediación de urgencia y las conversiones que una barrera ahuyentó en silencio.

¿Los overlays o widgets te hacen cumplir?

No — y los datos ya tratan al overlay como un riesgo, no como un escudo. Un overlay es ese ícono, a menudo una figura azul en una esquina, que se vende como un camino al cumplimiento. En abril de 2025 la FTC de Estados Unidos multó a accessiBe con un millón de dólares, prohibiéndole de forma permanente afirmar que su overlay con IA puede hacer cualquier sitio conforme a WCAG (Blue Atlas, 2026). Un regulador dijo, con todas las letras, que la promesa central era engañosa.

La litigación apunta en la misma dirección. Cerca del 40% de las organizaciones demandadas por accesibilidad en 2025 ya tenían un overlay instalado cuando llegó la demanda (AudioEye, 2026), y más de 600 profesionales de accesibilidad firmaron una declaración pública de que los overlays no cumplen los requisitos legales y muchas veces empeoran la experiencia de quienes dicen ayudar (Blue Atlas, 2026). El motivo es estructural: un widget inyecta JavaScript sobre tu código, así que no puede reparar el HTML de base, la navegación por teclado rota ni la lógica ARIA mal hecha. Pinta por encima del problema que un lector de pantalla todavía tiene que recorrer. Y hay un detalle propio de España: la ley exige una Declaración de Accesibilidad veraz, con el nivel real de cumplimiento — algo que un widget no puede generar con honestidad, porque no sabe qué se arregló de verdad. Desarrollamos la trampa legal del overlay —la multa de la FTC, las demandas y qué funciona en su lugar— en nuestra guía sobre si los overlays de accesibilidad son una trampa legal.

¿Entonces por qué mi validador dice que estoy al 98%?

Porque un validador automático solo ve la parte de la accesibilidad que una máquina puede medir — cerca del 30 al 40% de WCAG. Las herramientas automáticas detectan bien el texto sin alternativa, el contraste bajo o las etiquetas de formulario ausentes. No juzgan si un texto alternativo es útil, si el orden de foco tiene sentido, si un desplegable a medida se anuncia a un lector de pantalla, o si un video tiene subtítulos correctos. Esos juicios necesitan una persona y tecnología asistiva como NVDA, JAWS o VoiceOver (DaaS Group, 2026).

La brecha es medible. El análisis WebAIM Million del millón de páginas de inicio más visitadas encontró que el 94,8% todavía falla la accesibilidad básica, con un promedio de 56,8 errores detectables por página (WebAIM vía beaccessible, 2026). Seis problemas concentran el 96% de todos los fallos detectados: texto de bajo contraste (en el 79,1% de las páginas), texto alternativo ausente (55,5%), etiquetas de formulario ausentes (48,2%), enlaces vacíos (45,4%), botones vacíos (29,6%) e idioma del documento sin declarar (15,8%) (WebAIM vía WCAGsafe, 2026). Un puntaje automático en verde que ignora el otro 60% de la norma no prueba cumplimiento — prueba hasta dónde llegó el escáner.

¿Qué exige de verdad ser “accesible”?

Exige que cualquier persona pueda percibir, operar, comprender y confiar en tu sitio — los cuatro principios de WCAG, conocidos como POUR (perceptible, operable, comprensible, robusto). En la práctica, la conformidad se reduce a un puñado de disciplinas que una construcción cuidadosa resuelve por defecto: contraste de color suficiente; texto alternativo real y descriptivo en las imágenes con significado; cada campo de formulario con su etiqueta; una jerarquía de encabezados lógica; operación completa por teclado con un foco visible; y componentes hechos con HTML semántico para que la tecnología asistiva los entienda. Cuándo ese HTML semántico basta y cuándo hace falta ARIA —y por qué un <div> disfrazado de botón es el error clásico— lo cubre nuestra guía sobre cuándo usar ARIA. Los fallos más comunes de arriba no son exóticos — son lo básico, omitido. Para la versión completa y construible de esas disciplinas —organizada por POUR, con los nueve criterios nuevos de WCAG 2.2 y cómo probarlos— mira nuestra checklist WCAG 2.2.

Hay además una obligación documental propia del marco español: la Declaración de Accesibilidad, enlazada desde todas las páginas, con el nivel de cumplimiento, los contenidos no accesibles, la fecha y el método de evaluación, y un canal de queja (daas-group, 2026). Es un documento que solo puede ser honesto si alguien probó el sitio de verdad. Por eso la accesibilidad es una cuestión de oficio antes que de cumplimiento: se decide mientras construyes, no después. El fallo más común de todos —el texto de bajo contraste, en el 79% de las páginas— es una decisión de diseño pura; nuestra guía sobre diseño accesible y contraste de color cubre cómo acertar. Y si un control se puede usar sin ratón —la operabilidad por teclado y un indicador de foco visible— se decide igual; nuestra guía sobre accesibilidad por teclado y foco lo cubre.

¿Por qué construirla en vez de parcharla?

Porque la accesibilidad es un proceso que se sostiene, no un producto que se compra una vez — y construirla desde el inicio es la única versión que aguanta. Un sitio cambia muchas veces al día; un overlay o un “proyecto de accesibilidad” puntual no puede seguir ese ritmo, y por eso tantos sitios con widget terminan demandados igual. El consenso experto, y lo que premian los reguladores, es formación, pruebas y corrección desde el origen (Blue Atlas, 2026). Cuando la accesibilidad es parte de cómo se construye el sitio, la conformidad es la consecuencia del buen trabajo y no una capa frágil aparte.

También hay un beneficio defensivo. Un sitio conforme, respaldado por una auditoría manual y por la documentación del trabajo hecho, es prueba sólida si llega una reclamación. Construir la accesibilidad genera ese registro de forma natural; un widget pegado encima genera un recibo y una falsa sensación de seguridad.

¿Es solo un costo extra?

No — es el mismo trabajo que hacer un buen sitio, y devuelve la inversión por más de una vía. El HTML accesible, semántico y bien estructurado es el mismo sustrato que el HTML que carga rápido, rankea en buscadores y puede ser leído por asistentes de IA. El orden de encabezados que sigue un lector de pantalla es el que interpreta un motor de respuesta; el texto alternativo del que depende una persona ciega es el que describe tu imagen a un rastreador. De ese lado, el que mira la máquina, hablamos en nuestra guía sobre si tu sitio es legible para la IA — es la misma página, bien hecha, haciendo doble trabajo.

El caso de negocio es directo. Implementar las pautas de accesibilidad puede aumentar la conversión hasta un 15% en comercio electrónico, porque las barreras que disparan demandas son las mismas que pierden ventas para todos (Inclusif, 2025). El formulario es donde la accesibilidad, las conversiones y la exposición legal se cruzan con más filo; nuestra guía sobre crear formularios web accesibles cubre esa superficie campo por campo. Y el público es enorme: solo en España viven más de 4 millones de personas con discapacidad (Inclusif, 2025), y en el mundo cerca de 1.300 millones. Gastar en accesibilidad no es un impuesto sobre un sitio terminado; es parte de construir uno que funcione, rankee y venda.

¿Qué cambia en 2026 y qué viene?

El marco se endureció en varios frentes a la vez, así que conviene tener el calendario a la vista. Con la EAA, los productos y servicios digitales nuevos deben ser accesibles desde el 28 de junio de 2025; para los ya existentes, el plazo se extiende hasta el 28 de junio de 2030 (inSuit, 2025). El Real Decreto 193/2023 fija fechas propias para el sector privado en España: los portales y aplicaciones nuevos desde el 1 de enero de 2029, y los existentes desde el 1 de enero de 2030 (Olga Carreras, 2026). La norma técnica EN 301 549 evoluciona a su versión 4.1.1 entre 2025 y 2026 para alinearse con la EAA (inSuit, 2025). Qué exige la EAA exactamente, a quién alcanza (incluidos los negocios fuera de la UE) y cómo se fiscaliza lo desarrolla nuestra guía sobre la Ley Europea de Accesibilidad.

Hay capas autonómicas y de vigilancia que se suman. Cataluña aprobó su Código de Accesibilidad (Decreto 209/2023), con requisitos adicionales —audiodescripción, subtitulación reforzada, navegación por voz— y un plazo de 2026 para banca y servicios financieros (Eye-Able, 2025). Y el Real Decreto 143/2026 crea la unidad técnica que coordina a las autoridades de vigilancia, la pieza que le da dientes al control. El hilo conductor de 2026 es constante: los plazos se mueven, la obligación no, y la supervisión se organiza para hacerla cumplir.

¿A quién protege — y por qué son más personas de las que crees?

La accesibilidad sirve a muchas más personas de las que la palabra “discapacidad” suele evocar. Incluye a quienes son ciegos o tienen baja visión, a quienes son sordos o tienen pérdida auditiva, a quienes navegan por teclado en vez de ratón por una condición motriz, y a quienes dependen de una estructura clara y un lenguaje sencillo por una diferencia cognitiva. Cada grupo llega a tu sitio por un camino distinto, y a cada uno lo frena un fallo distinto — una etiqueta ausente, un subtítulo que falta, una trampa de teclado, un muro de texto sin estructura. Ese último grupo —los lectores con una diferencia cognitiva o de aprendizaje— se sirve con lenguaje claro y una maquetación predecible, el tema de nuestra guía sobre accesibilidad cognitiva y lenguaje claro.

El público es todavía más amplio, porque la discapacidad suele ser temporal o situacional. Un brazo enyesado, el sol fuerte sobre la pantalla del móvil, una sala ruidosa sin auriculares, una conexión lenta — cada uno pone a una persona sin discapacidad, por un rato, en la misma situación que alguien con una limitación permanente. Diseñar para el borde mejora la experiencia en el centro: los subtítulos que sirven a una persona sorda sirven a cualquiera que mira sin sonido, y el soporte de teclado que sirve a alguien con una limitación motriz sirve al usuario avanzado que nunca toca el ratón.

¿Cómo consigues ayuda sin caer en la trampa?

Busca trabajo, no un widget — alguien que pruebe y corrija el sitio, no quien venda un script que esconde las fallas. Las señales son concretas. Un proveedor real hace una auditoría manual contra WCAG 2.1 o 2.2 AA, prueba con tecnología asistiva de verdad, y te entrega hallazgos mapeados a criterios de éxito específicos en vez de un porcentaje de panel salido de un escaneo (daas-group, 2026). Habla de remediar tu código y documenta lo que hizo. No promete “cumplimiento total” desde una línea de JavaScript, porque —como dejó claro la FTC— ningún overlay puede entregar eso.

Como no vendemos overlays ni revendemos ningún widget de cumplimiento, este consejo no nos cuesta nada darlo derecho: si la promesa central de un proveedor es cumplimiento instantáneo, trátalo como la advertencia, no como la función. La versión honesta de este trabajo es más lenta, vive en tu código real y produce un sitio accesible esté o no mirando un escáner.

¿Cómo compruebas que tu sitio es accesible?

Lo pruebas como lo usaría una persona con discapacidad, y guardas el registro. Pasa los escaneos automáticos para limpiar los problemas mecánicos, y después prueba a mano: recorre todo el sitio con el teclado, úsalo con un lector de pantalla, revisa el orden de foco y que cada elemento interactivo se anuncie. Documenta qué probaste y qué corregiste. Esa documentación es a la vez el camino a la conformidad real y la defensa más fuerte si llega una reclamación — y, en España, la base de una Declaración de Accesibilidad que diga la verdad. El método completo —la base automática, la pasada de teclado y la prueba de lector de pantalla paso a paso— está en nuestra guía sobre cómo probar la accesibilidad de tu sitio.

Esta es la disciplina que sostenemos con nuestro propio trabajo, en público — los sitios que entregamos cumplen WCAG 2.2 AA por construcción, y nuestra página principal se audita a sí misma frente a ti. Un estudio que te dice que la accesibilidad se construye, no se compra, debería ser la prueba de su propia afirmación.

---

Una última idea, porque resume todo. El signo de nuestro nombre es un infinito, y la accesibilidad es uno de sus lazos: la misma página semántica, estática y rápida que abre limpia para un lector de pantalla es la que carga en un parpadeo, rankea en buscadores y puede ser citada por un asistente de IA. No le agregas accesibilidad a un sitio terminado, igual que no la agregas a un edificio terminado pegando una rampa a la escalera. Construyes para que cualquier persona —y cualquier lector, humano o máquina— siempre haya podido entrar.