Cómo implementar accesibilidad web WCAG en tu sitio Drupal

La primera vez que pasas axe DevTools sobre un Drupal recién entregado y te aparecen 87 violaciones, entiendes que la accesibilidad no es algo que se "añade al final". Suele pasar con sitios técnicamente impecables: arquitectura limpia, Twig ordenado, configuración exportada, y un tema personalizado que ha tirado por la borda media docena de buenas prácticas que el núcleo te regalaba.

Drupal parte con ventaja frente a otros CMS. La Drupal Accessibility Initiative lleva desde la versión 8 empujando mejoras en core, y temas como Olivero se diseñaron con WCAG 2.1 AA como requisito no negociable. Pero un core accesible no salva un sitio si el equipo elige mal el tema, sobreescribe plantillas sin criterio o deja que los editores publiquen imágenes sin alt. La responsabilidad acaba repartida entre desarrollo, contenido y producto.

Esta guía recorre cómo implementar accesibilidad web WCAG en un sitio Drupal real, desde el tema hasta el pipeline de CI/CD, pasando por los módulos contribuidos que de verdad ayudan y por la normativa española que define qué puede acabar en sanción.

Qué dicen las WCAG y por qué afectan a tu Drupal

Las Web Content Accessibility Guidelines son el estándar publicado por el W3C y se organizan en cuatro principios, el famoso acrónimo POUR: Perceptible (alternativas textuales, contraste mínimo), Operable (teclado, tiempos suficientes, sin trampas de foco), Comprensible (legibilidad, comportamiento previsible) y Robusto (HTML válido y compatible con tecnologías de asistencia).

Cada criterio tiene tres niveles: A, AA y AAA. La legislación europea exige AA como mínimo. Si alguien te pide "cumplimiento AAA en todo el sitio", probablemente no haya leído las propias WCAG, porque el W3C reconoce que AAA no es realista como objetivo general.

Cómo llega Drupal al partido

El núcleo trae cosas que un developer Drupal senior agradece: roles ARIA en componentes, skip links, gestión de foco en los modales del sistema, formularios con <label> y <fieldset> correctos, Drupal.announce() para mensajes hacia lectores de pantalla y alt obligatorio donde tiene que serlo. Olivero, como tema por defecto desde 9.4, fue el primero en pasar una auditoría externa de accesibilidad antes de entrar en core.

Esa base se desmonta deprisa. Un tema custom que reemplaza <button> por <div> con un handler de click, un slider de un módulo contribuido sin foco visible, o un editor configurado para que los redactores marquen títulos a base de negritas. Cada decisión cuenta.

Auditoría inicial: saber dónde estás antes de tocar nada

Antes de abrir un solo .theme.yml conviene saber qué tienes delante. Una auditoría inicial te da un mapa de barreras y, sobre todo, una línea base para medir mejoras.

Lo que las herramientas automáticas detectan (y lo que no)

Los validadores automáticos cazan entre el 30% y el 50% de los problemas. Suena poco, pero es ese 30-50% el que llena las primeras reuniones de "esto está fatal". Los que uso a diario:

• axe DevTools como extensión de Chrome o Firefox. Lista violaciones por gravedad y enlaza al criterio WCAG concreto.
• WAVE de WebAIM, útil para mostrar a clientes no técnicos porque superpone iconos sobre la propia página.
• Lighthouse dentro de Chrome DevTools. No es la más exhaustiva, pero entra gratis en cualquier flujo de Core Web Vitals.
• Pa11y en línea de comandos, pensado para meterlo en pipelines.
• Sa11y, que también existe como módulo para Drupal y muestra avisos en el front directamente al editor.

La parte que ninguna herramienta cubre es la manual: navegar el sitio entero con Tab, Shift+Tab, Enter y flechas; pasarle NVDA o JAWS en Windows, VoiceOver en macOS; hacer zoom al 400% para comprobar el reflow (criterio 1.4.10); validar contrastes con Colour Contrast Analyser cuando dudes de la paleta. Si tu auditoría no incluye al menos una pasada con lector de pantalla, no es una auditoría de accesibilidad, es una checklist.

Configurar el tema: donde se gana o se pierde la partida

El tema es el componente con más impacto en la accesibilidad real de un Drupal. Puedes tener el mejor backend del mundo, que un tema mal hecho lo tira todo.

Partir de una base que ya sea accesible

Si arrancas un tema custom, hereda de Olivero o de Claro (este último para administración). Si necesitas Bootstrap, la versión 5 incorpora mejoras serias respecto a la 4. Lo que no haría nunca: arrancar de un tema premium descargado de un marketplace sin auditarlo antes. Suelen depender de JavaScript para contenido crítico, abusan de <div> y <span> y tienen indicadores de foco directamente desactivados.

HTML semántico, foco visible y reflow

El primer regalo que puedes hacerle a tus usuarios es no inventarte la rueda. <header>, <nav>, <main>, <footer> para las regiones; encabezados <h1> a <h6> en orden lógico sin saltar niveles; <button> cuando se ejecuta una acción y <a> cuando se navega; <table> con <th scope="col"> para datos tabulares. Y nunca, jamás, un <div onclick> haciéndose pasar por botón.

El indicador de foco visible es de los criterios más violados en sitios españoles. Mucho diseñador pide quitar el outline porque "queda feo". WCAG 2.2 endurece esto en el criterio 2.4.11 con requisitos de tamaño y contraste. Una base sensata:

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

En contraste, los ratios mínimos son 4.5:1 para texto normal y 3:1 para texto grande y componentes de interfaz. Para reflow, el sitio debe seguir siendo usable a 400% de zoom y en un viewport de 320 píxeles sin scroll horizontal. Si tu menú principal explota a partir de 200%, ya tienes deberes.

Módulos contribuidos que aportan de verdad

Drupal.org tiene decenas de módulos relacionados con accesibilidad. Estos son los que ponen al equipo en una posición distinta:

Editoria11y, el cambio de juego para equipos editoriales

Editoria11y (Editorial Accessibility Checker) es el módulo que más impacto tiene cuando el problema son los contenidos, que es casi siempre. Analiza el nodo en tiempo real desde la propia interfaz y avisa de imágenes sin alt, encabezados desordenados, enlaces tipo "haz clic aquí" y contrastes pobres en texto enriquecido. Lo recomendable es activarlo en todos los content types y darle formación a redactores: la curva de aprendizaje es de una tarde.

Módulos complementarios

Block ARIA Landmark Roles permite asignar roles ARIA y aria-label a los bloques desde la UI, útil cuando tu tema no llega a marcar correctamente todas las regiones. A11y_autocomplete sustituye los autocompletes nativos de Drupal por una alternativa más accesible para lectores de pantalla. CKEditor Accessibility Auditor mete un botón de validación dentro del editor, para que los redactores comprueben antes de guardar. Y Automatic Alternative Text usa servicios de IA para sugerir alt en imágenes recién subidas; no sustituye a una persona, pero evita que se publiquen imágenes con el campo vacío por descuido.

Formularios: el punto donde más se rompe

Los formularios son, junto al editor de contenido, el componente que más errores genera. Drupal los crea con base semántica correcta (<label for> asociado, <fieldset> con <legend>, mensajes de error con aria-describedby), pero cualquier personalización con hook_form_alter o una plantilla custom puede arruinarlo en cinco minutos.

Cuatro comprobaciones que merecen estar en tu checklist de QA: etiqueta visible asociada a cada campo, indicación textual de los campos obligatorios (no solo el asterisco rojo), mensajes de error descriptivos junto al campo correspondiente, y operatividad completa con teclado, incluyendo botones de envío y validaciones inline. Si usas Webform, revisa especialmente los componentes compuestos: los date pickers personalizados son históricamente los peores.

Llevar la accesibilidad al pipeline

Las correcciones de accesibilidad caras son las que se descubren en producción. Las baratas son las que se detectan en una pull request. Mover el control hacia la izquierda del ciclo es el cambio cultural más rentable.

En local, mete eslint-plugin-jsx-a11y si trabajas con componentes JS, y prueba con axe-core desde la terminal antes de subir. En CI/CD, lanza Pa11y CI o axe-core/cli contra las URLs críticas en cada despliegue a staging, con umbral cero violaciones de nivel A y un máximo negociado para AA. Con Cypress + cypress-axe o Playwright puedes integrar pruebas de accesibilidad en los e2e que ya tienes corriendo. En publicación, Editoria11y da feedback inmediato al editor y la revisión de accesibilidad debería ser un paso obligatorio en el workflow de Content Moderation antes de pasar a "Published".

Si tu equipo está dando los primeros pasos con esto y necesita una mano para integrar la accesibilidad WCAG en un sitio Drupal existente, o para abordar una auditoría conforme antes de un despliegue, en Tangram Consulting acompañamos ese proceso completo, desde la evaluación inicial hasta la formación del equipo editorial.

Cumplimiento legal en España y la UE

Aquí no hablamos solo de buenas prácticas. La accesibilidad es obligación legal en buena parte de los sitios web españoles, y la Inspección dependiente de la Administración General del Estado lleva años publicando informes de seguimiento con casos sancionables.

El marco aplicable se apoya en cuatro piezas: la Directiva (UE) 2016/2102, que obliga al sector público a cumplir WCAG 2.1 AA y se transpuso en España mediante el Real Decreto 1112/2018; la Norma EN 301 549, que define los requisitos técnicos detallados; la European Accessibility Act (Directiva 2019/882), conocida como Ley Europea de Accesibilidad, que entró en vigor en junio de 2025 y extiende las obligaciones al sector privado para servicios digitales como banca, comercio electrónico, libros digitales o transporte; y la Ley General de los Derechos de las Personas con Discapacidad y de su Inclusión Social, que da soporte sancionador en España con multas que pueden alcanzar el millón de euros para infracciones muy graves.

Todo sitio afectado debe publicar una declaración de accesibilidad que detalle el nivel de conformidad alcanzado, las áreas no conformes con justificación, las alternativas disponibles, un mecanismo de contacto y la fecha de última revisión. En Drupal lo más limpio es crear un nodo de tipo "Página básica" con esa información y enlazarlo desde el footer junto al aviso legal y la política de privacidad.

Conclusiones

Implementar accesibilidad web WCAG en tu sitio Drupal no es un sprint que se cierra: es una práctica continua que toca tema, módulos, flujos editoriales, pipeline de pruebas y cumplimiento normativo. La buena noticia es que Drupal te da más herramientas y mejor base que prácticamente cualquier alternativa del mercado. La menos buena, que sin disciplina de equipo y sin tratar la accesibilidad como requisito desde el día uno, esa ventaja se evapora.

Un sitio accesible cumple la ley, esquiva sanciones cada vez más reales y mejora el SEO de paso. Pero, sobre todo, hace que más personas puedan usar lo que has construido. Esa, al final, es la métrica que importa.