Normativa Europea de Accesibilidad en 2026: cómo auditar tu app y cumplir (con multas de hasta 1.000.000 €)

Si esperabas a que la normativa europea de accesibilidad "entrara en vigor", llegas tarde: está vigente desde el 28 de junio de 2025. Y ya no es cosa solo del sector público — obliga a apps, tiendas online, banca, transporte y prácticamente cualquier servicio digital dirigido a consumidores. El dato incómodo: el Barómetro de Accesibilidad Web 2025 de inSuit y Tech4access auditó entre abril y agosto de 2025 las webs de grandes empresas españolas en cinco sectores, y solo el 2% salió «plenamente conforme». El resto se expone a multas que llegan a 1.000.000 €, y ya hay sentencias firmes que lo demuestran.

Así que este artículo no va de "prepararte". Va de lo contrario: cómo auditar tu producto digital, qué exige la ley de verdad y cómo cerrar el incumplimiento antes de que lo haga una inspección.

Qué cambió: de "prepárate para 2025" a "ya estás obligado"

La base legal es la Directiva (UE) 2019/882, conocida como European Accessibility Act (EAA). Entró en vigor en toda la UE el 28 de junio de 2025. En España se transpuso con la Ley 11/2023, de 8 de mayo, que extiende al sector privado las obligaciones de accesibilidad que antes solo pesaban sobre la Administración (Real Decreto 1112/2018).

El estándar técnico de referencia es la norma EN 301 549, y aquí hay novedad reciente que conviene tener bien colocada.

La norma cambió en septiembre de 2026, y la nueva todavía no es la que te aplica

ETSI publicó la EN 301 549 V4.1.1 en septiembre de 2026, adoptada el 24 de agosto. No es un retoque: incorpora WCAG 2.2 en lugar de 2.1, realinea con ellas las cláusulas 9, 10 y 11, elimina el criterio 4.1.1 Parsing, trae los seis criterios nuevos de las WCAG 2.2 en nivel A y AA, amplía la obligación de respetar las preferencias de accesibilidad que el usuario ya tiene configuradas en su dispositivo —que no es nueva: la V3.2.1 ya la exige, lo que cambia es cuánto abarca— y suma tres anexos —ZA, ZB y ZC— más una cláusula A.2 con las cinco tablas de la Directiva 2019/882.

Y ahora el matiz que decide tu trabajo de los próximos meses: la referencia técnica con la que se trabaja sigue siendo la V3.2.1, con WCAG 2.1 nivel AA. Ojo con cómo se lee eso, porque la sección siguiente lo desarrolla: bajo la EAA la V3.2.1 tampoco está citada —su cita lo es para la directiva del sector público—, así que para una empresa privada es la referencia de facto, la que aplicará quien te inspeccione, no una base legal que te ampare. Que una norma esté publicada por ETSI y que tenga efecto jurídico son dos cosas distintas y suelen separarlas varios meses.

Lo práctico: audita contra la V3.2.1, que es la que van a aplicarte en la práctica, y construye pensando en la V4.1.1. Si vas a tocar el producto igualmente, hacerlo ya a WCAG 2.2 AA te evita repetir el trabajo; lo que no tiene sentido es medirte hoy contra un listón que todavía no es exigible y darte por incumplidor. El desglose técnico, principio por principio y con qué se comprueba cada punto en un móvil, está en el checklist de la EN 301 549.

La presunción de conformidad que todavía no existe

Esto contradice a buena parte de lo que se publica en español, así que va con la fuente delante.

El artículo 15 de la Directiva 2019/882 dice que los productos y servicios que cumplen normas armonizadas publicadas en el Diario Oficial se presumen conformes. Es el mecanismo habitual del marcado europeo: cumples la norma, se presume que cumples la ley, y quien diga lo contrario tiene que demostrarlo.

El problema es que bajo la EAA todavía no hay ninguna norma armonizada citada. En el índice de normas armonizadas de la Comisión, la única entrada de accesibilidad es «Websites and mobile applications of public sector bodies», que corresponde a la directiva del sector público, no a la EAA. La V4.1.1 sí se ha redactado por encargo de la Comisión para la EAA —lo dice su prólogo—, pero encargarla y citarla en el Diario Oficial son cosas distintas, y la que cuenta para la presunción es la segunda. La propia norma lo deja supeditado a esa cita: una vez citado el documento, cumplirlo conferirá presunción de conformidad.

Qué significa para ti, sin alarmismo y sin falso alivio:

• No existe hoy el argumento «cumplo la EN 301 549, luego estoy cubierto» frente a la EAA. Esa presunción no la tiene nadie todavía, ni tú ni tu competencia.
• Auditar contra la EN 301 549 sigue siendo exactamente lo que hay que hacer. Es el único marco técnico reconocido, es el que aplicará quien te inspeccione y es la prueba documental de que has actuado con diligencia.
• Cambia cómo lo defiendes. En vez de invocar una presunción que no existe, lo que enseñas es la auditoría, el plan de corrección con fechas y lo que ya has arreglado. Eso pesa más de lo que parece.

Cuando la Comisión cite la V4.1.1 en el Diario Oficial, quien haya construido contra WCAG 2.2 se encontrará el trabajo hecho.

A quién obliga (y por qué probablemente te incluye)

La normativa cubre los productos y servicios digitales que llegan al consumidor final:

• E-commerce: tiendas online, marketplaces, cualquier web o app que venda.
• Servicios bancarios y financieros: banca online, apps de inversión, seguros.
• Telecomunicaciones: webs y apps de operadores.
• Transporte: reserva de vuelos, trenes, autobuses, plataformas de movilidad.
• Servicios audiovisuales: streaming y contenido multimedia.
• Libros electrónicos y sus plataformas de lectura.

¿Y las exenciones? Las microempresas que prestan servicios (menos de 10 empleados y menos de 2 millones de euros de facturación anual) quedan fuera de las obligaciones de servicio. Pero cuidado con leerlo como una vía de escape:

• Si vendes productos (no solo servicios), las obligaciones técnicas siguen aplicando aunque seas microempresa.
• Si trabajas con la Administración o te presentas a licitaciones, la accesibilidad es requisito de contratación.
• Las pymes de 10 empleados o más no están exentas.
• Existe la figura de carga desproporcionada, pero se evalúa y se documenta antes, no se alega después. Cómo, más abajo.

Y dos plazos que casi nadie cuenta y que pueden darte aire: los productos que ya estaban en uso prestando un servicio antes del 28 de junio de 2025 disponen de un periodo transitorio de cinco años, salvo que los sustituyas durante ese tiempo; y los terminales de autoservicio pueden seguir en uso hasta el final de su vida útil, con un máximo de veinte años. Son excepciones para el parque instalado, no para lo que lanzas hoy: una app nueva nace obligada.

Las multas son reales (y ya hay sentencias)

La Ley 11/2023 monta un régimen sancionador con dientes:

Y el importe es solo una parte. Una empresa sancionada puede perder el acceso a subvenciones públicas (incluido el Kit Digital), quedar excluida de la contratación pública, sufrir la retirada de productos del mercado y ver publicado su incumplimiento.

No es teoría. La Audiencia Nacional confirmó en 2024 una multa de 90.000 € a Vueling —más seis meses sin poder optar a ayudas oficiales— por mantener una web inaccesible para personas con discapacidad. El informe técnico concluyó que la aerolínea cumplía 4 de 38 requisitos (un 10,5%), y pesó la reincidencia: ya había sido sancionada antes y apenas había corregido nada. Ese expediente es anterior a la EAA, pero deja claro que las sanciones por accesibilidad no son un espantapájaros: se imponen y aguantan en los tribunales. Fuera de España el listón es más alto todavía — en Francia y Alemania las multas por infracción pueden superar los 250.000 €.

Qué exige de verdad: los cuatro principios (POUR)

WCAG organiza los requisitos en cuatro principios. Estos son los que fallan en la mayoría de auditorías:

• Perceptible: texto alternativo en toda imagen, contraste mínimo de 4.5:1 en texto normal, contenido que se pueda ampliar al 200% sin romperse, y nada de transmitir información solo con el color.
• Operable: todo debe funcionar con teclado y el foco tiene que ser visible. Que además no quede tapado por cabeceras fijas, que los elementos clicables midan al menos 24×24 px y que toda acción de arrastrar tenga alternativa con clic son criterios de WCAG 2.2: exigibles cuando la Comisión cite la V4.1.1, recomendables ya si vas a tocar el producto.
• Comprensible: idioma declarado en el HTML (lang="es"), navegación consistente y formularios con etiquetas asociadas. No pedir dos veces el mismo dato en un flujo es también de WCAG 2.2.
• Robusto: HTML semántico (encabezados, listas, landmarks, roles ARIA), y compatibilidad real con lectores de pantalla. La autenticación accesible —nada de logins que dependan de CAPTCHAs de imágenes o pruebas cognitivas— llega igualmente con WCAG 2.2, y es de las que más conviene adelantar.

Carga desproporcionada: la única salida real, y cómo se documenta

Es la excepción que más se invoca de palabra y menos se sostiene por escrito. La ley admite que un operador no aplique un requisito cuando hacerlo suponga una carga desproporcionada, pero la carga hay que evaluarla y documentarla antes, no alegarla después, y el criterio no es que te resulte caro: es la relación entre el coste de la adaptación y tus propios recursos y volumen de negocio.

Lo que una evaluación de carga desproporcionada tiene que contener para que valga algo:

• Qué requisito concreto no vas a cumplir. No «la accesibilidad»: el requisito, identificado.
• El coste estimado de cumplirlo, con el desglose de dónde sale esa cifra.
• La relación con tus recursos: facturación, tamaño, cuánto pesa ese coste sobre el negocio.
• El beneficio para las personas con discapacidad que se pierde al no hacerlo, valorado de verdad.
• Cuándo se revisa. La evaluación caduca: cambia cuando cambia tu producto o tu tamaño.

Dos avisos. El primero, que alegar carga desproporcionada no te exime de informar: sigues teniendo que publicar tu declaración de accesibilidad y decir qué no cumples y por qué. El segundo, que si recibes fondos públicos para la adaptación, el argumento del coste se cae solo.

Qué pasa cuando alguien reclama

El escenario real casi nunca es una inspección de oficio. Es un usuario que no puede terminar una compra, reclama, y a partir de ahí se pone en marcha el expediente.

Lo que se pide en ese momento es siempre lo mismo, y es exactamente lo que no se puede improvisar en una semana: tu declaración de accesibilidad publicada, el informe de auditoría con fecha, el plan de corrección con plazos y responsables, y la evidencia de lo que ya has arreglado desde la auditoría. Una empresa con esos cuatro documentos y un incumplimiento parcial está en una posición muy distinta de una que no tiene ninguno.

La accesibilidad se defiende con trazabilidad, no con intenciones.

Cómo auditar tu app y tu web, paso a paso

Aquí está el trabajo real. La accesibilidad no se resuelve con un widget flotante; se audita y se corrige en el código.

1. Pasa las herramientas automáticas. Detectan el 30-40% de los problemas y son un buen primer barrido: axe DevTools, WAVE y Lighthouse para web; Accessibility Scanner en Android y el Accessibility Inspector de Xcode en iOS para móvil.
2. Haz la prueba manual. El 60-70% restante solo aparece a mano: ¿puedes completar una compra o un registro usando solo el teclado? ¿Un lector de pantalla (NVDA, VoiceOver, TalkBack) interpreta bien tu checkout? ¿Los mensajes de error se entienden? ¿Los modales y desplegables son navegables?
3. Prueba con usuarios reales. Personas con discapacidad detectan barreras que ninguna herramienta encuentra. Es la validación más honesta que existe.
4. Publica tu declaración de accesibilidad. La Ley 11/2023 la exige: debe indicar el nivel de conformidad que alcanzas, los problemas conocidos con su plan de corrección, y un canal para reportar barreras.
5. Prioriza y corrige. Ataca primero lo urgente y barato: imágenes sin alt, contraste, formularios sin etiqueta y navegación por teclado. Luego integra la accesibilidad en el proceso de desarrollo — diseñar accesible cuesta una fracción de lo que cuesta parchear después.

Si lo que tienes entre manos es una app y no una web, el recorrido cambia: lo que se comprueba, con qué ajuste del propio móvil y qué se ve cuando falla está en el checklist de la EN 301 549.

Los seis errores que más se repiten en las webs españolas, por si quieres empezar por ahí: imágenes sin texto alternativo, contraste insuficiente, formularios sin etiquetas, navegación por teclado rota, jerarquía de encabezados incorrecta y enlaces tipo "haz clic aquí" sin contexto.

En resumen

La normativa europea de accesibilidad ya no es un plazo futuro que gestionar, sino una obligación vigente con multas reales detrás. La buena noticia es que casi todo lo que exige —HTML semántico, buen contraste, formularios claros, navegación por teclado— también mejora el SEO y la conversión para todos tus usuarios, no solo para los 4,7 millones de personas con discapacidad que hay en España. Cumplir no es un coste: es construir mejor producto.

En Docastix construimos apps móviles y plataformas web y SaaS accesibles desde el diseño, no con un parche pegado por encima. Quince años de oficio del fundador, la fecha de entrega firmada en contrato y productos como Dormus funcionando en producción. Si necesitas una auditoría de accesibilidad de tu app o tu web, o construir la próxima cumpliendo WCAG desde el día uno, hablamos. ¿Prefieres una cifra primero? Calcula tu presupuesto en menos de 2 minutos.