EAA: 6 razones por las que un producto conforme suspende la auditoría

La brecha en la aplicación de la EAA es la distancia entre un producto que cumple la European Accessibility Act sobre el papel (una declaración publicada, una puntuación verde en Lighthouse, un widget overlay en el pie de página) y un producto que una persona con discapacidad puede usar de verdad para terminar una compra, abrir una cuenta o cambiar una reserva. Las auditorías, las denuncias y los tribunales miden lo segundo. El papeleo es la mitad barata del trabajo, y es la que se hace primero.

La ley se aplica desde el 28 de junio de 2025 a una lista concreta de productos y servicios para consumidores, entre ellos el comercio electrónico, la banca de consumo, los libros electrónicos, las comunicaciones electrónicas y el transporte de viajeros (Directiva (UE) 2019/882). En su primer año, la aplicación se ha hecho sobre todo con requerimientos, órdenes judiciales y plazos para corregir, más que con multas. Es justo la fase en la que aparece la brecha: un inspector o quien presenta una denuncia prueba el servicio con el teclado o con un lector de pantalla, y la declaración de la web deja de contar.

¿Cómo es un producto que solo cumple sobre el papel?

El patrón se reconoce enseguida. El pie de página enlaza una declaración de accesibilidad que afirma la conformidad total con las WCAG 2.1 AA. No tiene fecha de evaluación ni lista de problemas conocidos. La web de marketing saca un 100 en la auditoría de accesibilidad de Lighthouse. Un overlay ofrece un botón de contraste y un control para el tamaño de letra. Luego alguien recorre el checkout con el tabulador y el foco desaparece dentro de un selector de fechas, o el lector de pantalla anuncia el botón de pago como "botón", sin nombre.

Ninguna de estas señales es un fraude por sí sola. Cada una mide algo más estrecho de lo que pide la ley. Los seis errores que siguen son los puntos donde se estrecha.

Seis razones por las que un producto conforme sobre el papel suspende la auditoría

1. La puntuación automática se toma por la auditoría

Las herramientas automáticas leen el marcado. No saben si el texto alternativo describe la imagen, si el orden del foco sigue el orden visual o si un mensaje de error llega a quien usa un lector de pantalla en el momento en que aparece. Cuando el Government Digital Service británico probó 13 herramientas en una página de prueba construida con 142 barreras a propósito, la mejor detectó el 40 por ciento (blog de accesibilidad del GDS). Un 100 en Lighthouse significa que la página, en el estado en que se probó, no tiene ninguno de los errores que Lighthouse busca. Del resto no dice nada.

2. La declaración es una plantilla, no una evaluación

El Anexo V de la Directiva pide a los prestadores de servicios que expliquen cómo el servicio cumple los requisitos de accesibilidad, en las condiciones generales o en un documento equivalente, y que describan su diseño y su funcionamiento en la medida en que la evaluación lo necesite (Directiva (UE) 2019/882, Anexo V). Un párrafo copiado que declara la conformidad total no hace nada de eso. Una declaración sin fecha y sin problemas conocidos da a entender que nadie ha evaluado el producto. Una declaración que indica la norma, la fecha y el método de la última evaluación, los fallos conocidos y cuándo se corregirá cada uno describe un producto bajo control, incluso antes de que sea conforme del todo.

3. Se instala un overlay como remedio

Un overlay añade un widget encima de la página. Las barreras están en la página de debajo: campos sin etiqueta, divs que hacen de botón, diálogos de los que se escapa el foco. En enero de 2025 la Federal Trade Commission de Estados Unidos ordenó a accessiBe pagar un millón de dólares por afirmar que su widget hacía cualquier web conforme con las WCAG, y señaló que la herramienta no había conseguido que elementos básicos como menús, encabezados, tablas e imágenes fueran conformes (nota de prensa de la FTC). Es una resolución estadounidense de protección al consumidor, no una decisión sobre la EAA. Aun así responde a la pregunta práctica: un script puesto encima no arregla el marcado que revisa el auditor.

4. Los componentes aprueban solos y fallan juntos

Es la versión design system de la brecha. Cada componente de la librería supera sus propias pruebas: el botón tiene nombre, el campo tiene etiqueta, el diálogo tiene rol. El fallo aparece al combinarlos. Un diálogo se abre desde un menú y, al cerrarse, el foco vuelve al principio de la página. Un formulario muestra errores en línea que se ven pero nunca se anuncian. Un combobox funciona con el ratón y atrapa el teclado dentro de un panel de filtros. Las stories de los componentes los prueban de uno en uno. Las auditorías prueban tareas, y una tarea cruza varios componentes. Hemos escrito sobre cómo una librería se aleja de sus propias reglas en component drift: cómo se degrada un design system.

5. Se auditan páginas, no recorridos

Una declaración de conformidad a menudo se apoya en una muestra de plantillas: home, ficha de producto, artículo. Las tareas que le importan a la EAA están en otra parte: registro, verificación de identidad, carrito, pago, cambio de reserva, área de cliente. En las demandas que las asociaciones francesas apiDV y Droit Pluriel presentaron en noviembre de 2025 contra cuatro grandes cadenas de supermercados, el objetivo era el propio servicio de compra online, la web y la app con las que una persona ciega o con baja visión hace la compra (Intérêt à Agir). En 2026 un tribunal francés dio a Carrefour seis meses para hacer accesibles su web y su app, con una penalización por cada día de retraso (LSA).

6. Los seis errores más comunes se quedan en los tokens

El WebAIM Million 2026 detectó fallos WCAG en el 95,9 por ciento del millón de home más visitadas, frente al 94,8 por ciento de 2025. El texto con poco contraste aparecía en el 83,9 por ciento. Seis tipos de error (poco contraste, falta de texto alternativo, formularios sin etiqueta, enlaces vacíos, botones vacíos, idioma del documento sin declarar) sumaban el 96 por ciento de todo lo detectado, y son los mismos seis desde hace siete años (WebAIM Million 2026). El poco contraste casi nunca es un bug de página. Es un token: un gris elegido para texto sobre un fondo de color y reutilizado luego en cientos de pantallas. Corregirlo página a página es corregirlo cientos de veces y olvidarse de alguna.

¿Cuánto cuesta esta brecha en 2026?

Las sanciones las fija cada Estado, así que el riesgo depende de dónde se vende el producto. Los máximos van de unos 5.000 euros en Estonia a cerca de un millón de euros en España (tabla por país de WebYes), y varios Estados añaden multas diarias o la facultad de retirar un servicio. Un año después, los seguimientos publicados hablan de requerimientos, órdenes y plazos para corregir, más que de multas cobradas (informe de Disability World sobre el primer año).

Los casos muestran también que el ámbito de aplicación sigue en discusión. En mayo de 2026 un tribunal de Lille reconoció que la web de Auchan E-Commerce no era conforme y aun así desestimó la demanda, al interpretar que la ley francesa exime a una filial por debajo de 250 millones de euros de facturación. Las asociaciones recurrieron porque consideran que esa lectura contradice la Directiva (Faire Face). Si una empresa concreta entra o no en el ámbito es una pregunta para un abogado. Si su checkout funciona con el teclado es una pregunta que un equipo de producto responde en una semana.

Para el equipo, el coste real es el tiempo. Una orden judicial con seis meses de plazo concentra en un solo ciclo de lanzamiento el trabajo que un design system habría repartido en un año, y cae sobre los recorridos que generan ingresos.

¿Cómo se cierra la brecha en un producto que ya está en producción?

1. Listar las tareas, no las páginas. Anotar las cinco a diez tareas que un consumidor completa de principio a fin: registrarse, verificarse, buscar, añadir al carrito, pagar, cambiar una reserva, cerrar la cuenta. Esa lista es el alcance de la auditoría.
2. Hacer cada tarea con el teclado y con un lector de pantalla. NVDA en Windows y VoiceOver en macOS e iOS son gratuitos. Apuntar dónde se pierde el foco, qué control no tiene nombre y qué error nunca se anuncia.
3. Llevar cada fallo a su origen. Repartir los hallazgos en tres grupos: un token (contraste, anillo de foco), un componente (diálogo, combobox, campo de formulario) o una sola pantalla. Corregir primero los dos primeros grupos: un cambio ahí arregla todas las pantallas que los usan.
4. Corregir en el design system, publicar y repetir las tareas. Una corrección de contraste en los tokens y una de foco en el diálogo llegan a todas las pantallas en el siguiente lanzamiento. Nuestra checklist para auditar un design system en cinco días cubre la parte de tokens y componentes.
5. Reescribir la declaración al final. Fecharla, indicar la norma (EN 301 549, que incorpora las WCAG 2.1 AA), describir el método, listar lo que aún falla y cuándo se corregirá, y dejar un contacto para comentarios.
6. Quitar el overlay cuando las correcciones estén publicadas, o al menos dejar de citarlo como medida de conformidad.

Una nota sobre la norma. EN 301 549 V3.2.1 es la referencia que usan hoy los auditores, y en 2022 la Comisión Europea pidió a los organismos de normalización que la adaptaran a la EAA (mandato M/587). Diseñar según las WCAG 2.1 AA, y comprobar las WCAG 2.2 donde cuesta poco, cubre también la versión que viene.

¿Cómo se evita que la brecha vuelva a abrirse?

• Pruebas automáticas como mínimo en la CI. Ejecutar axe-core o un equivalente en cada pull request. Detecta las regresiones que una máquina ve y deja el tiempo manual para las que no ve.
• La accesibilidad dentro del contrato del componente. Cada componente documenta su comportamiento con teclado, la gestión del foco y lo que anuncia, con una prueba para cada cosa. Un componente que no cumple el contrato no entra en la librería.
• Pruebas de composición para las tareas críticas. Una prueba end-to-end que completa el checkout solo con el teclado rompe la build cuando el foco se pierde entre dos componentes.
• Contraste comprobado en los tokens. Emparejar cada token de texto con los fondos sobre los que puede ir y comprobar el ratio cuando cambia el token, no cuando sale una página. Un sistema de tokens en tres niveles hace explícitas esas parejas.
• Una revisión manual con cadencia fija: en cada lanzamiento importante y al menos una vez al año, con la fecha de la declaración actualizada cada vez.

Sobre el cambio más amplio en la forma de hacer producto desde que la ley está en vigor, tenemos un artículo sobre el diseño accesible tras la EU Accessibility Act. Este texto describe cómo se forma la brecha. No es asesoramiento jurídico: el ámbito, las exenciones y las sanciones nacionales hay que verificarlos con un abogado cualificado en cada mercado donde se vende el producto.