Accesibilidad web y GDPR en Drupal: cumplimiento legal y buenas prácticas

Accesibilidad web en Drupal: un compromiso que también es obligación legal

La accesibilidad web ha dejado de ser un nice-to-have para convertirse en un requisito legal en la Unión Europea. La Directiva Europea de Accesibilidad (European Accessibility Act) exige que los sitios web de empresas que ofrecen productos y servicios al público cumplan con los estándares WCAG 2.1 nivel AA. Drupal es una de las plataformas mejor posicionadas para cumplir con estos requisitos, gracias a su compromiso histórico con la accesibilidad.

En los proyectos que desarrollamos desde nuestro servicio de desarrollo y mantenimiento Drupal, la accesibilidad se integra desde la fase de diseño, no como una capa de correcciones al final del proyecto.

El marco legal en 2026: EAA, EN 301 549 y RGPD

Conviene entender qué te obliga exactamente. La EAA (Directiva 2019/882) amplía las obligaciones de accesibilidad —que antes recaían sobre todo en el sector público— al sector privado: comercio electrónico, banca, telecomunicaciones, transporte y, en general, servicios prestados a consumidores. El mecanismo técnico de cumplimiento es la norma armonizada EN 301 549, que «traduce» la ley a criterios verificables tomando como base las pautas WCAG. Por eso, cuando hablamos de «cumplir la EAA», en la práctica hablamos de cumplir WCAG a nivel AA.

La accesibilidad no viaja sola. Convive con la normativa de protección de datos (RGPD y, en España, la LOPDGDD) y con un marco de ciberseguridad cada vez más exigente. Si tu empresa opera en sectores regulados, es probable que también te afecten normas como la directiva NIS2 de ciberseguridad. La buena noticia es que todos estos frentes comparten un mismo principio de fondo: diseñar desde el inicio pensando en el usuario y en el dato, en lugar de parchear al final.

Drupal y WCAG: qué viene de serie

Drupal ha sido pionero entre los CMS en adoptar estándares de accesibilidad. El core incluye soporte nativo para ARIA landmarks, gestión de foco en diálogos modales, anuncios de live regions para lectores de pantalla, tabulación lógica en formularios, y temas base (Olivero, Claro) que cumplen con WCAG 2.1 AA de serie.

El módulo Inline Form Errors mejora la experiencia de validación de formularios mostrando errores junto al campo afectado en lugar de solo en la parte superior del formulario. Y el sistema de temas de Drupal permite implementar alto contraste, tamaños de fuente ajustables y otros requisitos de accesibilidad sin modificar el contenido.

En 2026, con Drupal 11.4 como versión estable de referencia, el editor CKEditor 5 incorpora comprobaciones de accesibilidad en la propia interfaz de edición, y el ecosistema contribuido ofrece módulos muy útiles para equipos editoriales: Editoria11y (un corrector de accesibilidad que avisa a los redactores en tiempo real), Sa11y, Automatic Alternative Text (generación asistida de alt) o Text Resize. Si estás valorando actualizar tu plataforma, merece la pena revisar antes nuestra guía sobre las novedades de Drupal 11 y, si vienes de una versión antigua, el proceso de migración paso a paso.

WCAG 2.2: los criterios nuevos y por qué adelantarte

WCAG 2.2 se publicó en octubre de 2023 y es retrocompatible: si cumples 2.2, cumples también 2.1 y 2.0. Añade nueve criterios de conformidad (dos de nivel A, cuatro de nivel AA y tres de nivel AAA) y retira, por primera vez en la historia de las pautas, el criterio 4.1.1 Parsing, que había quedado obsoleto. Los criterios de nivel AA que más impacto tienen en un proyecto real son:

• Foco no oscurecido (mínimo): el elemento con foco de teclado no puede quedar tapado por barras fijas, banners de cookies o chats flotantes.
• Movimientos de arrastre: toda acción que dependa de arrastrar debe tener una alternativa con un solo clic o toque.
• Tamaño del objetivo (mínimo): las áreas interactivas deben medir al menos 24×24 px, algo crítico en móvil.
• Ayuda coherente: los mecanismos de ayuda (contacto, chat, FAQ) deben aparecer en el mismo lugar en todas las páginas.
• Entrada redundante: no pedir dos veces el mismo dato dentro de un mismo proceso, salvo que sea imprescindible.
• Autenticación accesible: no obligar a resolver puzzles cognitivos (por ejemplo, recordar y transcribir) para iniciar sesión.

Nuestra recomendación es clara: aunque la ley todavía se apoye en WCAG 2.1, construye ya para 2.2. Es esfuerzo que no tendrás que repetir cuando EN 301 549 se actualice, y varios de esos criterios (tamaños táctiles, foco visible) mejoran la conversión para todos los usuarios, no solo para quienes tienen una discapacidad.

Auditoría de accesibilidad: más allá de las herramientas automáticas

Herramientas como axe, Lighthouse y WAVE detectan problemas técnicos (contraste insuficiente, imágenes sin alt, formularios sin labels), pero solo cubren un porcentaje de los criterios WCAG. Una auditoría completa requiere revisión manual: navegación solo con teclado, pruebas con lectores de pantalla (NVDA, VoiceOver), verificación de la estructura semántica de headings y comprobación de que el contenido es comprensible sin estilos visuales.

Recomendamos hacer una auditoría de accesibilidad al menos una vez al año y después de cada rediseño significativo, además de integrar tests automáticos de accesibilidad en el pipeline de CI/CD para detectar regresiones en cada despliegue.

Como referencia práctica, las herramientas automáticas suelen detectar en torno a un 30–40 % de los problemas reales; el resto solo aflora con pruebas manuales y, sobre todo, con usuarios reales. Por eso una auditoría técnica seria combina ambos enfoques y prioriza los hallazgos por impacto legal y de negocio, no por volumen de avisos del validador.

Accesibilidad y rendimiento: la experiencia también es cumplimiento

Un sitio accesible pero lento sigue excluyendo a mucha gente: quienes navegan con conexiones limitadas, dispositivos antiguos o tecnologías de apoyo que consumen recursos. Accesibilidad y rendimiento son dos caras de la misma experiencia de usuario. En Drupal, técnicas como el caché con BigPipe y Varnish reducen el tiempo hasta que el contenido es utilizable, lo que beneficia directamente a los lectores de pantalla. Y si optas por una arquitectura desacoplada, conviene tener presentes las implicaciones de accesibilidad y SEO que explicamos en la guía sobre cuándo desacoplar el frontend en Drupal: en headless, la semántica y el foco son responsabilidad del frontend, no del core.

GDPR y gestión del consentimiento en Drupal

El cumplimiento del RGPD (GDPR) en Drupal abarca varios frentes: gestión del consentimiento de cookies, tratamiento de datos personales, derecho al olvido, portabilidad de datos y registro de actividades de tratamiento. Módulos como EU Cookie Compliance (ahora Cookies) y GDPR proporcionan herramientas para gestionar estos requisitos.

En nuestra experiencia gestionando el cumplimiento GDPR para múltiples sitios web del Grupo Damm, donde implementamos la gestión de cookies y consentimiento en más de 10 sites, aprendimos que la clave está en diseñar una arquitectura de consentimiento que sea fácil de mantener y que se adapte a los cambios regulatorios sin requerir desarrollo adicional cada vez. Ese enfoque encaja especialmente bien en escenarios de Drupal multisite, donde una misma política de datos debe replicarse de forma coherente en decenas de dominios.

RGPD más allá de las cookies: bases legales, encargados y brechas

Reducir el RGPD al banner de cookies es el error más extendido. El reglamento exige, entre otras cosas, identificar una base de legitimación para cada tratamiento (consentimiento, ejecución de contrato, interés legítimo…), mantener el Registro de Actividades de Tratamiento (RAT), firmar contratos de encargado de tratamiento con cada proveedor que acceda a datos (hosting, email marketing, analítica), controlar las transferencias internacionales y disponer de un procedimiento para notificar brechas de seguridad a la AEPD en un plazo de 72 horas.

Ese último punto conecta directamente con la seguridad: no hay privacidad sin protección del dato. Trabajar con un enfoque de gestión de la seguridad de la información —como el que plantea la certificación ISO 27001— facilita cumplir el RGPD, porque obliga a inventariar datos, clasificar riesgos y definir responsabilidades. Si no sabes por dónde empezar, nuestra guía de ciberseguridad para empresas es un buen punto de partida.

Cookies y tracking: implementación técnica correcta

El error más común que encontramos en auditorías es cargar scripts de tracking antes de obtener el consentimiento del usuario. La implementación correcta requiere que Google Analytics, Meta Pixel, herramientas de remarketing y cualquier cookie no esencial se bloqueen por defecto y solo se activen tras el consentimiento explícito del usuario para cada categoría.

Con Drupal, esto se implementa combinando el módulo de consentimiento de cookies con Google Tag Manager, donde las etiquetas de marketing se configuran para dispararse solo cuando la variable de consentimiento de la categoría correspondiente está activa. Esto centraliza la lógica de consentimiento y simplifica el mantenimiento.

En 2026 hay un matiz que no puedes ignorar: si usas productos de Google (Ads, Analytics 4) para público del EEE, necesitas Consent Mode v2, que envía señales de consentimiento (ad_storage, analytics_storage) antes de activar el tag. Muchas plataformas de consentimiento europeas se apoyan además en el marco IAB TCF v2.2. La forma limpia de orquestar todo esto en Drupal es a través de una capa de datos y de integraciones bien diseñadas con sistemas externos, de modo que analítica y publicidad respeten siempre la decisión del usuario.

Políticas de retención y derecho al olvido

El módulo GDPR de Drupal incluye herramientas para gestionar solicitudes de acceso y eliminación de datos personales. Permite configurar políticas de retención por tipo de dato, anonimizar registros de usuarios que solicitan la eliminación de sus datos, y generar informes de los datos personales almacenados para responder a solicitudes de acceso.

Implementar estas funcionalidades de forma correcta desde el inicio del proyecto es mucho más eficiente que intentar adaptar un sitio existente. Si tu sitio Drupal necesita una auditoría de accesibilidad o cumplimiento GDPR, en Keliam podemos ayudarte a identificar las carencias y resolverlas de forma sistemática.

Un apunte técnico importante: el «derecho al olvido» no siempre significa borrar. En muchos casos (facturación, obligaciones fiscales) hay que conservar ciertos datos durante años, por lo que la estrategia correcta es la anonimización o la seudonimización, no la eliminación total. Documentar estos plazos por tipo de dato en el RAT evita decisiones improvisadas cuando llega una solicitud real.

Accesibilidad y seguridad: dos caras del cumplimiento

Accesibilidad, protección de datos y seguridad forman un mismo triángulo de cumplimiento. Un formulario accesible que envía datos sin cifrar, o un gestor de consentimiento vulnerable, no cumplen su función. Por eso recomendamos abordar estos frentes de forma conjunta, apoyándote en servicios especializados como una auditoría de seguridad y pentesting, el desarrollo seguro y la auditoría de código, o el acompañamiento en cumplimiento ENS e ISO 27001 cuando trabajas con la administración pública. Casos como el de Alfil Logistics (Grupo Damm) muestran cómo un mismo proyecto Drupal puede combinar accesibilidad, rendimiento y seguridad sin renunciar a ninguno.

Errores comunes en auditorías de accesibilidad y RGPD

• Confiar solo en el validador automático. Pasar Lighthouse con 100 no significa cumplir WCAG: la mayoría de barreras reales solo se detectan con teclado y lector de pantalla.
• Tratar el banner de cookies como «el RGPD». El consentimiento es una pieza; faltan bases legales, RAT, contratos de encargado y gestión de brechas.
• Cargar scripts antes del consentimiento. Analytics o Pixel disparándose en el primer render es la no conformidad más frecuente y la más fácil de sancionar.
• Accesibilidad solo al final. Corregir contraste, foco y semántica tras el desarrollo cuesta mucho más que diseñarlo bien desde el principio.
• No versionar la configuración de consentimiento. Sin control de cambios ni tests, cualquier despliegue puede romper el bloqueo de cookies sin que nadie se entere.

Hoja de ruta de cumplimiento en 4 fases

Para un proyecto Drupal, este es el camino que seguimos para alcanzar (y mantener) el cumplimiento sin bloquear la operativa del negocio:

La clave de la cuarta fase es la mejora continua: integrar comprobaciones de accesibilidad en el CI/CD, revisar la configuración de cookies tras cada cambio de marketing y programar una auditoría anual. Así el cumplimiento se mantiene vivo en lugar de caducar con el primer rediseño.

Preguntas frecuentes

¿Mi web está obligada a cumplir la EAA? Si vendes productos o servicios digitales a consumidores en la UE y no eres una microempresa (menos de 10 empleados y menos de 2 M€), es muy probable que sí, desde el 28 de junio de 2025.

¿WCAG 2.1 o 2.2? La ley se apoya hoy en 2.1 AA vía EN 301 549, pero 2.2 es retrocompatible y será el estándar cuando la norma se actualice en 2026. Construir para 2.2 evita re-auditar.

¿Drupal es accesible «de fábrica»? El core y los temas Olivero/Claro parten de una base WCAG 2.1 AA muy sólida, pero la accesibilidad final depende del tema a medida, del contenido editorial y de los módulos que añadas.

¿El banner de cookies me hace cumplir el RGPD? No. Es una parte. Necesitas además bases de legitimación, registro de actividades, contratos con encargados y un procedimiento de brechas.

¿Cada cuánto hay que auditar? Al menos una vez al año y después de cada rediseño o cambio importante de funcionalidad, complementado con tests automáticos en cada despliegue.

¿Qué sanciones hay por no cumplir? Varían según la norma y el país. En materia de protección de datos, el RGPD contempla multas de hasta 20 M€ o el 4 % de la facturación global anual. En accesibilidad, cada Estado miembro fija su régimen sancionador al transponer la EAA, además del riesgo reputacional y de perder clientes que no pueden usar tu web. En la práctica, el coste de cumplir siempre es menor que el de no hacerlo.

Conclusión

Accesibilidad y protección de datos han pasado de ser «buenas prácticas» a ser obligaciones legales con consecuencias reales. Drupal ofrece una base excelente para ambas, pero el cumplimiento no se hereda del CMS: se diseña, se implementa y se mantiene. Abordarlo de forma conjunta —accesibilidad, RGPD y seguridad— desde el inicio del proyecto es más barato, más robusto y mucho menos estresante que reaccionar ante una queja o una inspección. Si quieres saber dónde está hoy tu sitio Drupal, una auditoría es el primer paso.