Ley europea de accesibilidad: revisa tu web por tu cuenta

Si vendes online a consumidores de la UE, los requisitos de la ley europea de accesibilidad (European Accessibility Act) para sitios web se aplican a tu tienda desde el 28 de junio de 2025, salvo que tu empresa sea una microempresa. Muchos de los problemas graves los puedes encontrar tú mismo: haz un pedido de prueba solo con el teclado, amplía la página con el zoom y prueba todos los formularios. Lo que una revisión propia no puede hacer es demostrar que todo el sitio cumple la norma.

Quizá un desarrollador te haya mencionado la ley, o te haya llegado un correo que ofrece un widget que hace «conforme» cualquier web con una línea de código. Un cliente que no consigue completar tu proceso de compra con el teclado o con un lector de pantalla (un software que lee la página en voz alta) puede irse a otra tienda sin quejarse.

¿Se aplica la ley europea de accesibilidad a tu web?

La ley europea de accesibilidad se aplica si tu web vende a consumidores, es decir, a personas que compran para sí mismas, y tu empresa no es una microempresa. La Directiva (UE) 2019/882 incluye los servicios de comercio electrónico entre los servicios que cubre: servicios prestados a través de un sitio web o una aplicación «con vistas a celebrar un contrato con un consumidor». Los países tenían que aplicar sus normas a partir del 28 de junio de 2025. Esta es nuestra lectura de la directiva; para una opinión jurídica sobre tu propio caso, consulta a un abogado.

• Las microempresas que prestan servicios están exentas. Lo establece el artículo 4, apartado 5. La directiva define una microempresa como la que ocupa a menos de 10 personas y cuyo volumen de negocios anual o balance general anual no supera los 2 millones de euros. Cuentan tanto la plantilla como uno de los dos criterios financieros: un equipo de diez personas queda fuera de la exención, por pequeña que sea la facturación.
• Vender solo a empresas. La definición se refiere a contratos con consumidores. Si los particulares pueden hacer pedidos a través de tu proceso de compra, considera que el sitio está cubierto.
• Una web que no vende nada. Una web corporativa sin pedidos, reservas ni pagos no suele ser un servicio de comercio electrónico tal como lo define la directiva. Las reservas y los pagos cambian eso.
• La fecha de 2030 es para productos y contratos antiguos. El periodo transitorio hasta el 28 de junio de 2030 del artículo 32 cubre los productos utilizados para prestar un servicio y los contratos firmados antes de junio de 2025.

Cada país de la UE aplica la ley europea mediante su propia legislación y fija sus propias sanciones; en Alemania esa ley es la BFSG. Si tu empresa está en Suiza o en el Reino Unido y vende a consumidores de la UE, pregunta a un abogado cómo se te aplican las normas de esos países.

¿Por qué las webs de tiendas no superan las revisiones de accesibilidad?

Los fallos que siguen suelen venir de decisiones de diseño y de formularios tomadas una vez en el tema y repetidas en cada página. La Directiva (UE) 2019/882 pide sitios web «perceptibles, operables, comprensibles y robustos». La norma europea que traduce esto en pruebas, EN 301 549, sigue las WCAG, las Pautas de Accesibilidad para el Contenido Web publicadas por el W3C. Las WCAG ordenan sus criterios en tres niveles: A (el mínimo), AA y AAA. El nivel AA es el objetivo que usa la norma.

Se quitó el contorno de foco por estética. Cuando alguien recorre una página con la tecla Tab, el navegador dibuja un marco alrededor del enlace o el botón activo. Algunos temas lo ocultan porque queda desordenado, aunque las WCAG exigen un indicador de foco visible. Un criterio añadido en las WCAG 2.2 dice además que el elemento con el foco no debe quedar totalmente tapado por el propio contenido del sitio, como una cabecera fija o un banner de cookies.

El texto es demasiado pálido. Las WCAG piden una relación de contraste, es decir, cuánto más oscuro o más claro es el texto que su fondo, de al menos 4,5:1 para el texto normal y 3:1 para el texto grande. El análisis de WebAIM de 2026 sobre un millón de páginas de inicio encontró texto con bajo contraste en el 83,9 % de ellas. El gris claro sobre blanco y el blanco sobre un botón pastel son los casos habituales.

Los formularios dependen del texto de ejemplo y del color. Una pista gris dentro de un campo desaparece en cuanto escribes, y un borde rojo por sí solo no dice qué está mal. Las WCAG exigen etiquetas o instrucciones siempre que haya que introducir datos, y errores descritos en texto.

El proceso de compra se hizo para el ratón. Los desplegables personalizados, los CAPTCHA de puzle y los inicios de sesión que piden recordar o volver a escribir un código frenan a quienes usan un teclado o un lector de pantalla. La directiva menciona por separado la identificación, la seguridad y el pago en el comercio electrónico. En marzo de 2026, la autoridad neerlandesa de consumo ACM informó de que en el 61 % de las grandes tiendas online neerlandesas y otras grandes webs de consumo que revisó no se podía hacer un pedido con tecnología de apoyo, como un lector de pantalla.

Un widget o una puntuación sustituye a la corrección. Los widgets superpuestos (overlays) añaden una barra de herramientas de accesibilidad encima del sitio. La Comisión Europea afirma que las superposiciones y herramientas similares que no hacen que la propia web cumpla la norma «no son una solución adecuada». Una prueba automática ayuda, pero en palabras del W3C, «ninguna herramienta por sí sola puede determinar si un sitio cumple las normas de accesibilidad».

Cómo revisar tu web según la ley europea de accesibilidad

Puedes hacer una primera revisión con un navegador y un teclado, sin herramientas de pago. El W3C, el organismo que está detrás de las WCAG, publica con esta idea una serie de comprobaciones sencillas, las Easy Checks. Elige tres páginas: la de inicio, una página de producto o servicio, y el proceso de compra o el formulario de contacto. Ve en orden y apunta cada punto en el que te atascas.

1. Aparta el ratón. Recorre cada página con Tab y Mayús+Tab, y usa Intro, la barra espaciadora y las flechas. Deberías llegar al menú, los filtros, el botón de añadir a la cesta, cada campo de formulario y el botón de pago. En todo momento deberías ver dónde estás. Apunta dónde desaparece el marco detrás de una cabecera fija o un banner de cookies, y si puedes salir de un menú o de una ventana de chat.
2. Amplía con el zoom. Pon el navegador al 200 %. Las WCAG esperan que el texto siga siendo legible sin que el contenido se corte o se superponga. Después deja la ventana en unos 1280 píxeles de ancho y amplía al 400 %: el contenido debería caber en el ancho sin desplazamiento lateral, salvo elementos como mapas y tablas de datos.
3. Revisa el texto pálido. Las herramientas para desarrolladores de Chrome, Edge y Firefox muestran la relación de contraste de un color de texto seleccionado. Revisa el texto principal, los precios, los botones y el texto gris pequeño bajo los campos de formulario.
4. Prueba cada formulario vacío y luego mal rellenado. Cada campo necesita una etiqueta visible que se mantenga al escribir. Envía el formulario vacío: el error debería decir con palabras qué falta, junto al campo, y conservar lo que ya escribiste. Un criterio nuevo de las WCAG 2.2 pide también que los datos que ya introdujiste en el mismo proceso, como una dirección, se rellenen automáticamente o se ofrezcan para elegir. Otras formas en que un formulario te hace perder pedidos están en nuestro artículo sobre una web con visitas pero sin solicitudes.
5. Inicia sesión y pasa el control antispam. Según las WCAG 2.2, iniciar sesión no debe depender de una prueba de función cognitiva, como recordar una contraseña o resolver un puzle, salvo que haya una alternativa o una ayuda, como un gestor de contraseñas o la opción de pegar. Un CAPTCHA de puzle sin otra opción no pasa aquí.
6. Mira las imágenes de producto. Haz clic derecho en una imagen y elige Inspeccionar. El texto alternativo, la descripción breve que lee un lector de pantalla, debería decir qué es el producto; las imágenes puramente decorativas pueden tenerlo vacío.
7. Repite los pasos clave en un móvil. Los iconos pequeños y muy juntos son difíciles de pulsar. Las WCAG 2.2 fijan un tamaño mínimo de objetivo de 24 por 24 píxeles CSS (una unidad de tamaño de la propia página web), con excepciones como tener suficiente espacio alrededor del objetivo.

El W3C advierte de que una página «podría parecer que supera estas comprobaciones y aun así tener barreras de accesibilidad importantes». El siguiente paso es una prueba hecha por alguien que usa un lector de pantalla a diario.

¿Qué deberías corregir primero?

Empieza por las correcciones en el tema y en los componentes de formulario, de la más barata a la más cara. Un cambio en una plantilla corrige todas las páginas construidas con ella. Deja la información de accesibilidad publicada para cuando sepas qué hace y qué no hace el sitio.

1. No instales una superposición. La Comisión Europea aconseja corregir los problemas de accesibilidad «en su origen», que en una tienda significa el tema, los formularios y el proceso de compra.
2. Recupera el marco de foco y oscurece el texto. Ambos suelen estar en los ajustes de color y estilo del tema. Nosotros empezamos fijando el contraste una vez en la paleta del diseño y comprobándolo en las versiones clara y oscura del sitio, para que cada página nueva parta de colores que ya cumplen.
3. Rehaz los formularios. Etiquetas visibles, errores con palabras junto al campo, datos escritos que se conservan tras un error, el foco llevado al primer campo que hay que corregir y autocompletado del navegador para nombre, correo y dirección. En nuestros proyectos web empezamos por el propio componente de formulario, para que cada formulario nuevo nazca con estas correcciones.
4. Añade texto alternativo y el idioma de la página. Describe las imágenes de producto y de contenido, y asegúrate de que cada página declara su idioma, para que un lector de pantalla la pronuncie correctamente. Los buscadores leen el mismo texto alternativo y el mismo atributo de idioma, por eso también forman parte del SEO técnico.
5. Corrige el proceso de compra, el inicio de sesión y los widgets de terceros. Sustituye los CAPTCHA de puzle por comprobaciones que no pidan al cliente resolver nada, y ofrece una forma de iniciar sesión que no dependa de la memoria. Los widgets de pago y de chat vienen de proveedores: pide a cada proveedor su información de accesibilidad y sustituye los que un teclado no puede alcanzar.
6. Publica tu información de accesibilidad. El anexo V de la directiva pide a los prestadores de servicios que describan cómo cumple el servicio los requisitos, en las condiciones generales o en un documento equivalente. Tu legislación nacional fija los detalles.
7. Trabaja hacia las WCAG 2.2 nivel AA. La versión 4.1.1 de la EN 301 549, publicada en septiembre de 2026, añade seis requisitos de las WCAG 2.2, según AccessibleEU. Hasta que la Comisión la cite en el Diario Oficial de la Unión Europea, señala la misma fuente, la referencia sigue siendo la versión 3.2.1, basada en las WCAG 2.1 nivel AA. La National Disability Authority de Irlanda espera esa cita el 16 de diciembre de 2026. Corregir ya según las WCAG 2.2 significa que los nuevos requisitos estarán cubiertos cuando llegue ese momento.

La directiva permite una excepción cuando el cumplimiento supondría una carga desproporcionada, pero exige una evaluación, y sus considerandos indican que «la falta de prioridad, de tiempo o de conocimientos» no es un motivo legítimo.

¿Qué deberías medir después de las correcciones?

Mide si una persona puede completar las tareas principales con el teclado y con la página ampliada. Repite la misma revisión según la ley europea de accesibilidad en las mismas tres páginas y compara dónde te atascabas antes y después de los cambios. Vuelve a revisar cada vez que cambien el tema, un plugin o el proveedor de pagos.

1. Un pedido de prueba solo con el teclado, desde la página de producto hasta la confirmación, sin tocar el ratón.
2. La lista de hallazgos de una prueba automática gratuita, como Lighthouse en Chrome, ejecutada en los mismos tres tipos de página. Revisa los hallazgos y comprueba cuáles siguen ahí.
3. Formularios enviados con errores, para confirmar que cada error se describe con palabras y que no se pierde nada de lo escrito.
4. Tu información de accesibilidad publicada, actualizada tras cada cambio que afecte a cómo hacen pedidos los clientes.

Dónde entramos nosotros

Cuando revisamos el proceso de compra de una tienda, seguimos el camino del cliente: la página de producto, la cesta, los formularios y el paso de pago, primero con el teclado y luego en un móvil. Los problemas que viven en el tema o en los componentes de formulario son más baratos de corregir ahí; lo que una revisión propia no puede resolver queda para una prueba con lector de pantalla. Si quieres que echemos un segundo vistazo a tu proceso de compra, cuéntanos sobre tu web.

← Todos los artículos