Accesibilidad web y European Accessibility Act: qué debe hacer tu negocio en 2026

En una cafetería de la Gran Vía, el dueño de una tienda de ropa pequeña me enseña su web desde el móvil y se queja de las ventas. La web es bonita: fotos grandes, un texto gris claro finito sobre blanco, el carrito escondido tras un icono sin etiqueta. Le pido que cierre los ojos un minuto y haga un pedido con la voz: le activo en su propio teléfono el lector de pantalla que ya trae de fábrica. A los veinte segundos se rinde. La voz lee «botón, botón, enlace, imagen», los campos del formulario no tienen nombre, y al pago no llega ni de lejos. «¿Y de verdad alguien compra así?», pregunta. En la Unión Europea compran así decenas de millones de personas, y para ellas la accesibilidad web no es un capricho, sino la única manera de llegar siquiera a la pasarela de pago. Y desde junio de 2025, lo que acaba de ver es además un incumplimiento directo de la ley.

La accesibilidad web dejó de ser un tema «para entusiastas» y una cuestión de buen gusto. Desde el 28 de junio de 2025 rige en la Unión Europea el European Accessibility Act (EAA), y por primera vez una web inaccesible pasó de ser un desliz estético a un riesgo legal con factura concreta. Esto no va de portales benéficos ni de organismos públicos, sino del negocio comercial de toda la vida: tiendas, bancos, servicios de reservas, cualquiera que venda a personas por internet.

Y hay algo que casi nadie dice en voz alta: esa misma web que no deja pasar a la persona con lector de pantalla está medio invisible también para el rastreador de Google. La accesibilidad y el SEO brotan de la misma raíz: una estructura limpia que la máquina entiende. Por eso poner tu web al día con el EAA no es un impuesto-multa que pagas a regañadientes. Es un trabajo que, de paso, sube tus posiciones y tu conversión. Vamos por orden: qué exige la ley, a quién obliga, qué es el WCAG sin jerga y por dónde empezar la auditoría.

Qué es el European Accessibility Act y por qué junio de 2025 es la fecha límite

El EAA es una directiva de la Unión Europea (2019/882) que exige que toda una serie de productos y servicios digitales sean accesibles para las personas con discapacidad. Se aprobó ya en 2019, se dieron varios años a los países para trasladarla a sus leyes nacionales y a las empresas para prepararse. Esa ventana se cerró: desde el 28 de junio de 2025 los requisitos rigen y se aplican en la práctica.

Conviene entender la lógica de la ley para no buscar en ella lo que no hay. El EAA no dicta de qué color ni con qué botón debe ser tu web. Fija un resultado: el servicio tiene que estar disponible para una persona con discapacidad visual, auditiva, motriz o cognitiva en igualdad con el resto. Cómo lo consigues técnicamente lo describe la norma europea EN 301 549, que a su vez se apoya en las recomendaciones internacionales WCAG. La cadena es sencilla: ley (EAA) → norma técnica (EN 301 549) → lista de comprobación verificable (WCAG nivel AA).

Otro detalle que se confunde a menudo. El EAA no es lo mismo que la Web Accessibility Directive de 2016. Aquella directiva, más antigua, afectaba a las webs del sector público. El EAA extiende por primera vez requisitos parecidos al negocio privado y a los servicios de consumo. Si antes pensabas «la accesibilidad es para las webs públicas, a mí no me toca», desde 2025 eso ya no es así.

A quién obliga de verdad

Aquí empieza lo importante, porque la mayoría de los dueños de negocio está convencida de que esto les pasa de largo. Casi siempre se equivocan. El EAA cubre a las empresas que venden a consumidores en la UE dentro de una lista bastante amplia de categorías:

• Tiendas online y e-commerce: prácticamente cualquier venta minorista por internet al consumidor final.
• Servicios bancarios y de pago: banca online, pasarelas de pago, todo lo relacionado con las finanzas de consumo.
• Transporte y billetes: webs y apps para comprar billetes, reservar y consultar horarios.
• Libros electrónicos y sus tiendas, además de los lectores.
• Servicios de telecomunicaciones y los equipos asociados.
• Servicios audiovisuales: acceso a plataformas de streaming y similares.

El principio clave es el territorio de venta, no el de registro. Si tu empresa está registrada en España, en México, en el Reino Unido o incluso fuera de la UE, pero vendes a consumidores finales dentro de la Unión, te obliga. Esto importa especialmente al negocio que mantiene una web multilingüe y acepta pedidos de varios países de la UE: ya estás en ese mercado.

Hay una excepción notable: las microempresas que prestan servicios, es decir, las que tienen menos de 10 personas y una facturación (o balance) anual que no supera los 2 millones de euros, quedan exentas de parte de los requisitos referidos a los servicios. Pero no te confíes. Primero, la excepción es estrecha y no alcanza a los fabricantes ni vendedores de productos físicos. Segundo, en cuanto el negocio crece, desaparece. Tercero, aunque formalmente entres en ella, una web inaccesible te sigue costando clientes y posiciones en el buscador. La ley es el suelo, no la meta.

Test rápido de si te incumbe: ¿vendes algo a personas en la UE a través de una web o una app? Si la respuesta es sí, parte de que el EAA te obliga, y demuestra lo contrario solo con una norma concreta de la ley nacional, no «a ojo».

El WCAG sin jerga: qué es una web accesible

WCAG (Web Content Accessibility Guidelines) suena a algo que requiere una carrera aparte. En realidad se sostiene sobre cuatro principios muy humanos: el contenido debe ser perceptible (se puede ver u oír), operable (se puede usar sin ratón), comprensible y robusto (las tecnologías de apoyo lo leen bien). El nivel de cumplimiento que exige el EAA es el AA. Esto es lo que significa en la práctica, sin jerga.

Contraste del texto

El texto gris claro sobre fondo blanco queda «aireado» en el portfolio de un diseñador e ilegible para una persona con poca visión, y de paso para cualquiera que mire la pantalla bajo el sol. El WCAG AA exige un ratio de contraste de al menos 4,5:1 para el texto normal y 3:1 para el grande. Es el error más frecuente y el más barato de arreglar: basta con oscurecer el texto y comprobar los pares de colores con un verificador de contraste. Si vas a renovar la paleta, es el momento natural de meter el contraste en los propios tokens de diseño durante el rediseño de tu web, en lugar de parchearlo después.

Manejo con teclado

Una parte enorme de los usuarios (personas con discapacidad motriz, personas ciegas y también usuarios avanzados) no toca el ratón. Toda la web tiene que funcionar con teclado: se debe poder recorrer con la tecla Tab, hay que ver qué elemento está enfocado en cada momento (ese borde que los diseñadores tanto se empeñan en quitar) y se debe poder salir de las ventanas emergentes. Se comprueba en un minuto: aparta la mano del ratón e intenta hacer un pedido solo con el teclado. Donde te atascas, ahí hay un fallo.

Alternativas de texto (alt)

El lector de pantalla no ve la imagen: lee su descripción del atributo alt. Sin descripción, para la persona ciega ahí queda un hueco, a veces leído como un nombre de archivo sin sentido. Cada imagen con contenido debe llevar una descripción corta y con sentido; las puramente decorativas, un alt vacío para que la voz las salte. La ventaja por la que les encanta a los responsables de marketing: ese mismo alt lo lee también Google, y es uno de los factores de posicionamiento de las imágenes.

Formularios con etiquetas

Un campo de entrada sin etiqueta es un campo-acertijo. El texto gris dentro del campo (el placeholder) no cuenta como etiqueta: desaparece en cuanto empiezas a escribir y el lector de pantalla a menudo no lo anuncia. Cada campo debe tener un <label> asociado por programación, y los errores («correo no válido») deben explicarse con texto, no solo con un borde rojo. Para el negocio esto es doblemente crítico: el formulario es el lugar donde nace la solicitud, y un formulario inaccesible recorta ventas directamente. Si estás poniendo orden en tus formularios que convierten, la accesibilidad y la conversión se arreglan de un mismo gesto.

Estructura de encabezados y semántica

El lector de pantalla recorre la página como un índice: salta de encabezado en encabezado. Si en la página hay un único <h1> de verdad y luego una jerarquía lógica de <h2> y <h3>, la persona ciega se orienta al instante. Si todos los «títulos» son simplemente texto grande en negrita sin etiquetas, no hay navegación. Esa misma semántica (los botones marcados como botones, los enlaces como enlaces, las listas como listas) la necesita también el rastreador. La estructura, en el fondo, es la misma.

Accesibilidad web y SEO: por qué es un solo trabajo, no dos

Esta es la idea por la que valía la pena leer todo lo anterior. El lector de pantalla y el rastreador de Google «ven» tu página de forma sorprendentemente parecida: ninguno de los dos mira la foto bonita, ambos van por el código, por la estructura, por el texto. Por eso casi cada requisito de accesibilidad resulta ser, por coincidencia, un factor que ayuda en el buscador.

Requisito de accesibilidad	Qué aporta en SEO
alt en las imágenes	Posicionamiento en la búsqueda de imágenes, contexto para la página
Estructura limpia h1→h2→h3	Google entiende la jerarquía, opciones de fragmentos enriquecidos
Textos de enlace con sentido	Mejor reparto de la autoridad, anclas más claras
Subtítulos y transcripciones en vídeo	Texto indexable en lugar de un vídeo «ciego» para el robot
Marcado semántico	Análisis más limpio de la página, base para Schema.org
Maquetación ligera y rápida	Aporte directo a los Core Web Vitals

La última fila es un tema aparte. Las webs accesibles suelen estar montadas de forma más ligera y ordenada, y eso mejora directamente los Core Web Vitals: LCP, INP y CLS, que Google tiene en cuenta en el ranking en 2026. Una maquetación que salta al cargar (mal CLS) tortura por igual a la persona con discapacidad motriz que no acierta con el botón «huidizo» y a tus posiciones.

Y otro giro de 2026: los AI Overviews de Google y asistentes como ChatGPT arman sus respuestas a partir de páginas con una estructura clara y legible para la máquina. Esa misma semántica que necesita el lector de pantalla es justo la que ayuda a tu contenido a entrar en la respuesta de la IA. La accesibilidad web, el SEO y la citabilidad en la búsqueda con IA resultaron ser tres nombres de la misma higiene del código.

Por no hablar de la aritmética simple de la audiencia: según distintas estimaciones, alrededor del 15% de las personas en el mundo vive con alguna forma de discapacidad, y si sumas la pérdida de vista y oído ligada a la edad, la proporción de quienes agradecen de verdad la accesibilidad al comprar es aún mayor. Una web inaccesible manda en silencio a esas personas a la competencia, antes incluso de que entre en juego ningún regulador.

Cómo hacer una auditoría de accesibilidad: por dónde empezar esta semana

La auditoría completa por WCAG es trabajo de especialista, y parte de los criterios solo se comprueban a mano y con tecnologías de apoyo reales. Pero el primer diagnóstico lo puedes sacar tú en una tarde y entender el tamaño del problema. Este es el orden honesto, de mayor a menor utilidad:

1. Pasa un escáner automático. Herramientas gratuitas (las extensiones axe DevTools o WAVE, la auditoría Lighthouse de Chrome) te marcan en un minuto el contraste, los alt que faltan y los campos sin etiqueta. La salvedad: la automática caza, con suerte, un 30–40% de los problemas. No sustituye la revisión manual, solo te enseña la punta del iceberg.
2. Recorre el camino clave solo con teclado. Aparta el ratón e intenta hacer la acción principal de la web: completar un pedido, enviar un formulario, reservar. Donde se pierda el foco o te atasques, ahí hay un fallo prioritario.
3. Activa un lector de pantalla y escucha. En Mac es VoiceOver (Cmd+F5), Windows trae Narrador integrado, y existe el gratuito NVDA. Cierra los ojos y recorre la página principal y el proceso de compra. Eso espabila más que cualquier informe.
4. Comprueba el contraste a mano en las pantallas clave: botones, enlaces, texto sobre fotos, etiquetas en gris claro.
5. Anota los hallazgos y estima el volumen. Parte de los arreglos (contraste, alt, etiquetas de formularios) son horas. Otra parte (la navegación con teclado rota, las ventanas modales que no funcionan, los «botones» caseros hechos con <div>) se va a las plantillas y los componentes, y entonces es más honesto plantear un rediseño con la accesibilidad en la base que tapar un agujero tras otro.

Lo que no debes hacer bajo ningún concepto es colgar un widget de superposición: ese botón flotante de «accesibilidad» que promete «arreglar» la web con un interruptor de fuente y contraste. Es la trampa más extendida. Las superposiciones no tocan el código fuente, los lectores de pantalla a menudo las ignoran o entran en conflicto con ellas, y los criterios del WCAG quedan sin cumplir. Tanto los reguladores como la comunidad de personas con discapacidad advierten sin rodeos: la superposición no garantiza el cumplimiento del EAA y, en varios países, ha sido motivo de demanda por sí misma. La accesibilidad de verdad se arregla en el marcado y en el diseño, donde vive la causa, y no en una capa sobre el síntoma.

Qué significa esto para el dinero y los plazos

Con honestidad sobre el coste: no hay una factura universal, porque todo depende de lo hondo que esté metido el problema en el código. Si la web está construida sobre componentes modernos y semántica cuidada, llevarla al WCAG AA son sobre todo arreglos de contraste, alt, etiquetas y foco, y la cuenta va en decenas de horas-persona. Si la web es antigua, con «botones-imagen» caseros y maquetación con tablas, sale más barato reconstruir que reparar, y entonces tiene sentido hacer la accesibilidad como parte del rediseño y no como una partida aparte. Los órdenes de magnitud y las bifurcaciones los analizamos en el artículo sobre de qué depende el coste de una web; la accesibilidad se integra en ese mismo presupuesto, no lo duplica, si se prevé desde el principio.

El mayor ahorro está en el tiempo. La accesibilidad prevista en la fase de diseño y maquetación es casi gratis: el contraste correcto, las etiquetas semánticas y los formularios bien etiquetados no cuestan más que los incorrectos. La accesibilidad enroscada a una web ya terminada cuesta varias veces más y siempre sale a medias. Por eso, si tienes por delante una web nueva o un rediseño, la decisión más barata de tu vida ahora mismo es exigir el cumplimiento del WCAG AA en el propio pliego de condiciones.

Y no lo tomes como un gasto puro «para cumplir la ley». Pagas una vez y te llevas tres cosas a la vez: el riesgo legal del EAA neutralizado, el acceso a una audiencia que antes perdías en la puerta y un conjunto de mejoras técnicas que te suben en el buscador y en las respuestas de la IA. Pocas inversiones en una web amortizan por tres ejes al mismo tiempo. Si lo que dudas es a quién encargarlo, vale la pena leer cómo elegir una agencia que meta la accesibilidad en el contrato desde el día uno.

Quién gana al final

Volvamos al dueño de la tienda en la cafetería. Al final de la conversación dejó de preguntar «¿quién compra así?» y empezó a preguntar «¿cuánto cuesta arreglarlo?». Ese es el giro correcto. La accesibilidad dejó de ser un gesto voluntario de buena voluntad: desde junio de 2025 es una exigencia del mercado de la UE, con multas, demandas y una fecha límite que ya pasó, no que está por venir.

Pero en esta historia no gana quien, con un suspiro, cumple los requisitos mínimos de la ley. Gana quien entendió que una web accesible es, sencillamente, una web bien construida: la leen las personas con lector de pantalla, le gusta a Google, la cita la IA y no pierde al comprador a mitad de camino hacia el pago. El EAA no hizo más que volver obligatorio lo que ya valía la pena hacer. Quienes lo han oído están llevándose ahora, en silencio, la audiencia y las posiciones de los vecinos que todavía esperan salir del paso con un botón flotante en la esquina de la pantalla.