La accesibilidad web consiste en que las personas con discapacidad puedan percibir, manejar y entender un sitio, y con la Ley Europea de Accesibilidad es ya una obligación legal para muchas empresas que venden a consumidores en la UE. En la práctica, la ley remite a la norma armonizada EN 301 549, que a su vez se apoya en las Pautas de Accesibilidad para el Contenido Web (WCAG) del W3C en el nivel AA. Esta guía explica a quién afecta y desde cuándo, qué piden las normas, los fallos que encontramos con más frecuencia y cómo corregirlos, un proceso de auditoría numerado, la declaración de accesibilidad y cómo se controla su cumplimiento en los Estados miembros.
Última actualización: 27 de octubre de 2026.
¿Qué es la Ley Europea de Accesibilidad?
La Ley Europea de Accesibilidad es la Directiva (UE) 2019/882, adoptada el 17 de abril de 2019. Fija requisitos de accesibilidad comunes para una lista de productos y servicios en todo el mercado único de la UE, de modo que una empresa cumpla un solo conjunto de normas en lugar de uno distinto en cada país.
Al tratarse de una directiva, cada Estado miembro tenía que incorporarla a su legislación nacional antes del 28 de junio de 2022 y aplicar esas normas desde el 28 de junio de 2025. Desde el 28 de junio de 2025, la Ley Europea de Accesibilidad se aplica a los productos afectados que se comercializan y a los servicios afectados que se prestan a consumidores. Lo que una empresa tiene que hacer exactamente lo fija cada ley nacional, que sigue de cerca la directiva pero añade sus propios organismos de control y sus sanciones.
La ley convive con un texto anterior, la Directiva de accesibilidad web, que cubre las webs y las apps del sector público. La Ley Europea de Accesibilidad es la que llega a las empresas privadas.
En resumen: si vendes determinados servicios a consumidores en la UE, tu web y tu app deben ser accesibles. La referencia es la EN 301 549, que utiliza el nivel AA de las WCAG. Las microempresas de servicios están exentas. Cada país controla el cumplimiento de su propia versión de las normas.
En Odduel, agencia de creatividad y tecnología en Barcelona y São Paulo, la accesibilidad forma parte de cada web desde el primer wireframe, y así planteamos el alcance de nuestros proyectos de diseño y desarrollo web. El resto de esta guía es lo que explicamos a los clientes que nos preguntan en qué situación están.
¿Quién debe cumplir la Ley Europea de Accesibilidad?
La ley cubre productos y servicios concretos, no todas las webs. En el lado de los servicios, los que afectan a la mayoría de webs y apps son:
- Servicios de e-commerce: cualquier servicio que se vende a consumidores a distancia a través de una web o una app móvil, por lo que la mayoría de las tiendas online entran en el ámbito de aplicación.
- Servicios bancarios para consumidores, incluidas las webs y apps a través de las que se ofrecen.
- Libros electrónicos y el software con el que se leen.
- Servicios de comunicaciones electrónicas y los servicios que dan acceso a medios audiovisuales.
- Elementos de los servicios de transporte de viajeros aéreo, en autobús, ferroviario y por vías navegables: webs, apps, billetes electrónicos e información de viaje en tiempo real.
En el lado de los productos entran artículos como ordenadores, smartphones, lectores de libros electrónicos, terminales de pago, cajeros automáticos y máquinas expendedoras de billetes. Si los fabricas o los importas, la ley se aplica al hardware y a su software, no solo a una web.
Una empresa de fuera de la UE no queda fuera de su alcance: lo que cuenta es que el servicio se ofrezca a consumidores en la UE. Una empresa que solo vende a otras empresas, sin ningún servicio dirigido al consumidor, suele quedar fuera del ámbito del comercio electrónico, aunque muchas webs atienden a ambos públicos y entonces la parte de consumo sí está cubierta.
La exención de las microempresas
La directiva exime a las microempresas que prestan servicios. Según la definición de la directiva, una microempresa emplea a menos de diez personas y tiene un volumen de negocio anual o un balance general por debajo de un límite bajo fijado en el texto. Un estudio pequeño que vende servicios online puede, por tanto, quedar fuera de la obligación.
Hay dos puntos que se suelen pasar por alto. La exención es solo para servicios: una microempresa que fabrica o vende productos cubiertos debe cumplir igualmente los requisitos de producto, con menos trámites. Y estar exento hoy no convierte una web inaccesible en buena idea, porque una empresa que crece por encima del umbral entra en el ámbito de la ley, y los clientes con discapacidad son clientes en cualquier caso.
Contenidos y contratos con un tratamiento especial
La directiva deja algunos contenidos fuera de los requisitos: audio y vídeo pregrabados publicados antes del 28 de junio de 2025, documentos ofimáticos publicados antes de esa fecha, contenidos archivados que no se han editado desde entonces, mapas online cuando la información esencial se ofrece de forma accesible y contenidos de terceros que la empresa ni financia ni controla. Los contratos de servicios firmados antes del 28 de junio de 2025 pueden seguir sin cambios hasta que terminen, durante cinco años como máximo.
Una empresa también puede alegar que un requisito le supondría una carga desproporcionada o alteraría de forma fundamental el servicio. Esa alegación debe evaluarse y documentarse según los criterios de la directiva, y las autoridades pueden pedir verla. No es una vía general para quedar exento.
¿Qué norma se aplica?
La directiva describe la accesibilidad en términos funcionales: el contenido debe ser perceptible, operable, comprensible y robusto. Para convertir eso en pruebas, la UE se apoya en normas armonizadas, y para webs y apps la pertinente es la EN 301 549, la norma europea de accesibilidad de las tecnologías de la información y la comunicación. Cumplir una norma armonizada cuya referencia se ha publicado para la ley da presunción de conformidad.
Para el contenido web, la EN 301 549 incorpora los criterios de conformidad de las Pautas de Accesibilidad para el Contenido Web del W3C en los niveles A y AA. La versión actual de la norma se basa en las WCAG 2.1. Las más recientes WCAG 2.2, recomendación del W3C desde octubre de 2023, mantienen los criterios de la 2.1 (salvo un criterio obsoleto sobre el análisis del código) y añaden nueve más, seis de ellos en los niveles A y AA.
Nuestro consejo es diseñar, desarrollar y probar con las WCAG 2.2 AA como referencia. Una web que las cumple también cumple los criterios de la 2.1 que la norma evalúa hoy, y está lista para la próxima revisión de la EN 301 549 sin necesitar una segunda pasada.
| WCAG 2.1 AA | WCAG 2.2 AA | |
|---|---|---|
| Estado | Recomendación del W3C, 2018 | Recomendación del W3C, octubre de 2023 |
| La usa hoy la EN 301 549 | Sí | Todavía no |
| Foco visible y no oculto | El foco debe ser visible | Además, el foco no puede quedar oculto del todo tras barras fijas o banners |
| Controles pequeños | Sin tamaño mínimo en AA | Objetivos de al menos 24 por 24 píxeles CSS, o suficiente separación |
| Acciones de arrastre | No se cubre en AA | Una alternativa al arrastre con un solo puntero |
| Formularios | Etiquetas y ayuda ante errores | Además, no volver a pedir datos ya facilitados |
| Inicio de sesión | No se cubre | Ninguna prueba de memoria ni rompecabezas sin alternativa |
| Ayuda | No se cubre | Opciones de ayuda en el mismo lugar en todas las páginas |
¿Qué significa WCAG 2.2 AA en la práctica?
Las WCAG se redactan como criterios de conformidad comprobables, agrupados en cuatro principios. Traducido a lo que vive un visitante, el nivel AA pide más o menos lo siguiente:
- Perceptible: las imágenes llevan alternativas de texto, los vídeos tienen subtítulos, el texto tiene suficiente contraste con el fondo (4,5 a 1 para el texto general, 3 a 1 para el texto grande y los elementos de interfaz) y la página sigue funcionando cuando el texto se amplía al 200 % o la pantalla es estrecha.
- Operable: todo se puede hacer solo con el teclado, el foco siempre es visible, nada parpadea de forma peligrosa, el contenido en movimiento se puede pausar y los visitantes tienen tiempo suficiente para actuar.
- Comprensible: la página declara su idioma, la navegación se comporta de forma coherente, los formularios tienen etiquetas y explican los errores, y nada cambia de contexto sin avisar.
- Robusto: el código expone correctamente nombres, funciones y estados a las tecnologías de apoyo, como los lectores de pantalla, y los mensajes de estado se anuncian.
Nada de esto obliga a hacer una web sosa o aburrida. Las webs que hacemos tienen movimiento, tipografía grande y color intenso; lo que cambia es que el movimiento respeta el ajuste de movimiento reducido del visitante, el color nunca transmite significado por sí solo y cada interacción tiene un camino con teclado. La accesibilidad funciona mejor cuando forma parte de las reglas de identidad: un manual de marca que especifica pares de colores accesibles ahorra discusiones más adelante.
¿Cuáles son los fallos de accesibilidad más comunes y cómo se corrigen?
La mayoría de auditorías encuentran los mismos fallos una y otra vez. Nacen de decisiones de diseño tomadas sin tener en cuenta las reglas y de componentes copiados de un proyecto a otro. La tabla recoge los que vemos con más frecuencia y cómo se corrigen.
| Fallo | A quién afecta | Criterio WCAG | Solución |
|---|---|---|---|
| Texto con poco contraste, sobre todo gris sobre blanco o blanco sobre un color vivo | Baja visión, personas mayores, cualquiera a pleno sol | 1.4.3 Contraste (mínimo) | Fijar pares de colores accesibles en los tokens de diseño y medir cada par nuevo |
| Imágenes sin un texto alternativo útil | Usuarios de lectores de pantalla | 1.1.1 Contenido no textual | Describir las imágenes informativas; dejar el alt vacío en las decorativas |
| Campos de formulario sin etiqueta, o con el texto de ejemplo como única etiqueta | Usuarios de lectores de pantalla y de control por voz | 1.3.1, 3.3.2, 4.1.2 | Una etiqueta visible vinculada a cada campo; errores en texto junto al campo |
| Controles que solo funcionan con ratón | Usuarios de teclado y de conmutadores | 2.1.1 Teclado | Usar botones y enlaces reales; probar cada recorrido solo con el teclado |
| Contorno del foco eliminado u oculto tras una cabecera fija | Usuarios de teclado | 2.4.7, 2.4.11 | Un estilo de foco marcado; margen de desplazamiento para que el foco nunca quede tapado |
| Encabezados usados por tamaño, no por estructura | Usuarios de lectores de pantalla | 1.3.1 Información y relaciones | Un solo H1, encabezados en orden, estilos aplicados por clase |
| Enlaces que solo dicen “haz clic aquí” o “leer más” | Usuarios de lectores de pantalla | 2.4.4 Propósito de los enlaces | Un texto de enlace que nombra el destino |
| Vídeos sin subtítulos | Personas sordas o con pérdida auditiva | 1.2.2 Subtítulos | Subtítulos en cada vídeo con voz; transcripciones para el audio |
| Banners de cookies y ventanas emergentes que atrapan o saltan el foco | Usuarios de teclado y de lectores de pantalla | 2.1.2, 2.4.3 | Llevar el foco al diálogo, mantenerlo dentro y devolverlo al cerrar |
| Botones de icono diminutos y muy juntos | Discapacidad motriz, usuarios de móvil | 2.5.8 Tamaño del objetivo (mínimo) | Objetivos de al menos 24 por 24 píxeles CSS, o espacio a su alrededor |
| Animaciones que no se pueden detener | Trastornos vestibulares, dificultades de atención | 2.2.2 Pausar, detener, ocultar | Un control de pausa; respetar el ajuste de movimiento reducido |
Las herramientas automáticas detectan algunos, como la falta de texto alternativo, el contraste bajo o las etiquetas ausentes. No pueden saber si un texto alternativo tiene sentido, si el orden del teclado es lógico o si un mensaje de error ayuda. Por eso el proceso siguiente combina herramientas con pruebas manuales.
¿Cómo auditar y corregir la accesibilidad de una web?
Una auditoría solo sirve si termina en correcciones y sigue siendo válida tras la siguiente publicación. Este es el proceso que seguimos, tanto si la web es nuestra como si la heredamos.
- Fija el objetivo y el alcance. Acuerda las WCAG 2.2 AA como referencia y enumera las plantillas y los recorridos que hay que probar: inicio, una página de contenido, una ficha de producto o de servicio, la búsqueda, el carrito y el checkout, el inicio de sesión, los formularios de contacto y el banner de cookies. En la mayoría de webs, una docena de plantillas cubre casi todas las páginas.
- Lanza las comprobaciones automáticas. Usa un motor de reglas reconocido en todas las plantillas y en cada versión de idioma. Registra los problemas por criterio, no por página, porque un fallo de un componente se repite en todas partes.
- Prueba solo con el teclado. Completa cada recorrido clave sin ratón: llega a cada control, ve el foco en todo momento, abre y cierra menús y diálogos, envía los formularios con errores y sin ellos.
- Prueba con un lector de pantalla y con zoom. Escucha los recorridos principales con al menos un lector de pantalla en escritorio y otro en el móvil, y después amplía el texto al 200 % y mira la web a un ancho estrecho. Revisa encabezados, regiones, etiquetas y avisos.
- Revisa contenidos y elementos multimedia. Comprueba los textos alternativos, la redacción de los enlaces, los subtítulos, los documentos descargables y el lenguaje claro en instrucciones y errores.
- Prioriza por impacto. Corrige primero lo que impide completar una tarea (un checkout que no se puede terminar con el teclado), después lo que la dificulta y luego el resto. La mayoría de correcciones van en los componentes compartidos y en los tokens de diseño, así que un solo cambio arregla muchas páginas.
- Corrige y vuelve a probar. Repite las mismas pruebas en las plantillas corregidas y guarda los resultados con fecha, para poder demostrar qué se encontró y cuándo se corrigió.
- Publica la declaración y mantenla en el proceso de publicación. Redacta la declaración de accesibilidad (más abajo) y añade comprobaciones de accesibilidad a cada nueva versión, junto al resto de tu checklist QA web.
Las pruebas con usuarios con discapacidad aportan lo que ninguna lista puede: saber si la web resulta de verdad agradable de usar. Si el presupuesto lo permite, una ronda breve de sesiones sobre los recorridos principales vale más que otro análisis automático.
La accesibilidad también se solapa con el mantenimiento. Los plugins y temas que se actualizan sin revisión pueden romper la gestión del foco o las etiquetas, así que la misma disciplina que mantiene segura una web, descrita en nuestra guía de seguridad en WordPress, la mantiene accesible.
¿Necesitas una declaración de accesibilidad?
Según la Ley Europea de Accesibilidad, los prestadores de servicios deben facilitar información sobre cómo cumple su servicio los requisitos de accesibilidad, en sus condiciones generales o en otro lugar fácil de encontrar, y en un formato accesible. La mayoría de empresas lo resuelven con una declaración de accesibilidad enlazada desde el pie de cada página.
Una declaración clara recoge:
- la norma que persigues (WCAG 2.2 AA, a través de la EN 301 549) y hasta qué punto la cumple la web;
- las carencias conocidas, con el motivo y una fecha de corrección cuando la tengas;
- cualquier contenido que quede fuera de los requisitos y cualquier carga desproporcionada documentada;
- cómo y cuándo se evaluó la web por última vez;
- un contacto a través del cual los visitantes puedan comunicar un problema o pedir un contenido en otro formato, y en cuánto tiempo respondes;
- dónde puede reclamar un visitante si la respuesta no le satisface, que depende de tu autoridad nacional.
Redáctala con claridad y mantenla al día. Una declaración que afirma un cumplimiento total en una web con fallos evidentes hace más daño que una honesta que enumera lo que aún se está corrigiendo.
¿Cómo se aplica la ley y qué sanciones hay?
Cada Estado miembro designa sus propias autoridades de vigilancia del mercado y fija sus propias sanciones, que la directiva exige que sean efectivas, proporcionadas y disuasorias. Por eso los organismos, los procedimientos y la cuantía de las sanciones varían de un país a otro, y algunas leyes nacionales también permiten que actúen las organizaciones de consumidores o los particulares.
Para una empresa que vende en varios países de la UE, la respuesta práctica es cumplir la norma común en todas partes en lugar de seguir cada variante nacional. Si necesitas las reglas exactas de sanciones de un mercado, lee la ley de transposición de ese país o consulta a un abogado que ejerza allí: las cifras son nacionales y no las citamos aquí.
Lo que las autoridades suelen poder pedir son pruebas: la norma que seguiste, los resultados de tus pruebas, tu declaración y cualquier evaluación de carga desproporcionada. El registro de auditoría del proceso anterior es esa prueba.
Preguntas frecuentes
¿Afecta la Ley Europea de Accesibilidad a mi web?
Se aplica si tu web o tu app presta un servicio cubierto a consumidores en la UE, como comercio electrónico, banca para consumidores, libros electrónicos, comunicaciones electrónicas o información de transporte de viajeros. Una web corporativa meramente informativa puede quedar fuera, y las microempresas que prestan servicios están exentas. Compruébalo con la lista de la directiva y con la ley de transposición de tu país.
¿Son obligatorias por ley las WCAG 2.2 AA?
La ley exige accesibilidad, y la norma armonizada EN 301 549 da presunción de conformidad. Esa norma utiliza hoy las WCAG 2.1 AA para el contenido web. Las WCAG 2.2 AA incluyen esos criterios y añaden algunos más, así que trabajar con las WCAG 2.2 AA cumple la norma actual y prepara la web para su próxima revisión.
¿Puede un overlay o un plugin de accesibilidad hacer que mi web cumpla?
No. Los overlays y las barras de herramientas cambian cómo se ve o se lee una página, pero no corrigen el código de base, las etiquetas, el orden del teclado ni el contenido, y algunos interfieren con los lectores de pantalla que los visitantes ya usan. Una web que cumple necesita corregir sus plantillas y componentes. Los plugins pueden ayudar con comprobaciones durante la edición, pero no sustituyen ese trabajo.
¿Cuánto dura una auditoría de accesibilidad web?
Depende del número de plantillas y recorridos más que del número de páginas, porque la mayoría de fallos están en componentes compartidos. Una web pequeña con pocas plantillas se audita rápido; una tienda grande con cuentas de usuario, búsqueda y checkout lleva más tiempo. Tras un breve repaso de la web y de sus recorridos clave, llega un plan cerrado.
¿Qué pasa si mi web no es accesible?
Te arriesgas a que actúe la autoridad nacional de vigilancia del mercado, que puede exigir correcciones e imponer sanciones según la ley nacional, y en algunos países a reclamaciones de consumidores u organizaciones. Igual de importante: pierdes a los clientes que no pueden completar una compra. Corrige primero los problemas que bloquean y publica una declaración honesta mientras se resuelve el resto.
Si no tienes claro si tu web cumple la Ley Europea de Accesibilidad, empieza por auditar las plantillas y los recorridos que más importan, y después corrige los componentes compartidos que causan la mayoría de fallos. Hacemos webs accesibles desde el primer wireframe y reparamos las heredadas dentro de nuestros proyectos de diseño y desarrollo web. Cuéntanos cómo es tu web y te diremos con claridad en qué punto está.
Para seguir leyendo: Checklist de auditoría UX: qué revisar y cómo hacerla en siete pasos.
