main content

Cómo crear un sitio web accesible según WCAG con Drupal

La accesibilidad web ya no es una buena intención: es una obligación legal. La Directiva (UE) 2016/2102, transpuesta a través del Real Decreto 1112/2018, obliga a todas las webs del sector público españolas, y a un número creciente de empresas privadas, a cumplir con el nivel AA de las WCAG 2.1. Y ahí Drupal juega con ventaja. Es el único CMS de adopción masiva que, desde la versión 8, exige cumplir accesibilidad para aceptar cualquier código en su núcleo.

Lo que vas a leer a continuación es una guía práctica sobre cómo crear un sitio web accesible según WCAG con Drupal: criterio por criterio, módulo por módulo, sin sacrificar ni diseño ni funcionalidad.

Qué exigen las WCAG 2.1 y por qué importan en España

Las Web Content Accessibility Guidelines (WCAG) descansan sobre cuatro principios: perceptible, operable, comprensible y robusto. Dentro de cada uno hay criterios de conformidad agrupados en tres niveles: A, AA y AAA. El nivel AA es el listón legal en toda la Unión Europea, y también el que aplica la normativa española.

Si trabajas en el sector privado, la Ley General de derechos de las personas con discapacidad (Real Decreto Legislativo 1/2013) ya impone obligaciones de accesibilidad a empresas con más de 100 empleados o que prestan servicios al público. La European Accessibility Act (Directiva 2019/882) va más allá: desde junio de 2025 alcanza a productos y servicios digitales de empresas privadas que antes quedaban fuera del paraguas.

¿Cuánto cuesta no cumplir? Las sanciones por infracción grave pueden llegar a los 90.000 euros. Y ese es solo el lado punitivo. Una web accesible amplía tu audiencia real: 4,38 millones de personas tienen alguna discapacidad reconocida en España según el INE, y los mayores de 65 años superan los 9 millones. No es un nicho. Es un mercado.

Por qué Drupal parte con ventaja

Drupal mantiene una política de accesibilidad oficial desde 2011 que obliga al core a cumplir WCAG 2.1 AA. Traducido al día a día: el panel de administración, los formularios, los mensajes del sistema y la navegación principal ya vienen preparados de fábrica:

Roles ARIA asignados correctamente a regiones, menús, alertas y formularios.
Gestión del foco en operaciones AJAX. Cuando añades un bloque o guardas un campo inline, el foco se mueve al elemento relevante (criterio 2.4.3 - Orden del foco).
Texto alternativo obligatorio en el campo de imagen por defecto (criterio 1.1.1 - Contenido no textual).
Skip links integrados en los temas base Olivero y Claro (criterio 2.4.1 - Evitar bloques).

Ningún otro CMS open source ofrece estas garantías por defecto. WordPress, sin ir más lejos, deja la accesibilidad casi al 100% en manos del tema y los plugins que elijas.

Configuración del tema: Olivero como punto de partida

Desde Drupal 10, el tema frontal por defecto es Olivero, diseñado con la accesibilidad como requisito de base. Si tu proyecto necesita un diseño a medida, no partas de cero: crea un subtema de Olivero. Así heredas todo lo que ya está resuelto.

Contraste de color (criterios 1.4.3 y 1.4.11)

Olivero trabaja con una paleta que mantiene ratios mínimos de contraste de 4.5:1 para texto normal y 3:1 para texto grande y componentes de interfaz. Si personalizas colores, valida siempre. Las dos herramientas que mejor funcionan son el Colour Contrast Analyser de TPGi y el inspector de accesibilidad integrado en Firefox.

Hay un fallo que veo en casi todos los proyectos españoles: tonos corporativos suaves (amarillos pastel, naranjas claros) sobre fondo blanco. Un naranja #F5A623 sobre blanco te da un ratio de 2.1:1. No pasa ni para texto grande.

Estructura semántica (criterio 1.3.1 - Información y relaciones)

El árbol de encabezados que genera Olivero es limpio: un único H1 por página, H2 para las secciones principales, H3 para las subsecciones. Instala HeadingsMap en tu navegador y comprueba que el contenido editorial respeta esa jerarquía. El abuso más típico viene del lado editorial: meter un H3 porque "se ve más bonito" cuando lo que toca es un H2.

Redimensionamiento de texto (criterio 1.4.4)

Olivero tipográficamente trabaja con rem en lugar de px. ¿La consecuencia práctica? Cuando el usuario amplía el tamaño base del navegador hasta el 200%, el texto escala sin romper la maqueta ni perder funcionalidad.

Módulos imprescindibles para llegar a WCAG 2.1 AA

El core cubre la base. Para el resto hay un puñado de módulos contribuidos que conviene tener bajo control.

CKEditor 5: editor accesible por defecto

Drupal 10 y 11 integran CKEditor 5, que ya cumple WCAG 2.1 AA en su propia interfaz de edición. Los botones de la barra de herramientas llevan etiquetas ARIA, todo se opera con teclado y los diálogos (insertar enlace, insertar imagen) gestionan el foco como deben.

Lo que sí te toca configurar: que el botón de imagen exija texto alternativo y que el de enlace incluya un campo de título descriptivo. Lo encuentras en /admin/config/content/formats.

Editoria11y (Editorial Accessibility)

Editoria11y es un comprobador en tiempo real que se integra en el front del sitio. Te marca con avisos visuales cualquier problema editorial: imágenes sin alt, encabezados fuera de orden, enlaces con texto genérico tipo "clic aquí" o "leer más". Si tu equipo editorial no tiene formación técnica en accesibilidad, este módulo te ahorra disgustos.

Instalación con Composer:

composer require drupal/editoria11y
drush en editoria11y

Automatic Alternative Text

Pensado para sitios con catálogos grandes de imágenes. Genera textos alternativos automáticos con IA. No sustituye a la revisión humana, pero evita que una imagen subida con prisa quede sin descripción (incumplimiento directo del 1.1.1).

Block ARIA Landmark Roles

Te permite asignar roles ARIA (banner, navigation, main, complementary, contentinfo) a cada bloque del sitio. Para alguien que navega con lector de pantalla, esos roles son el mapa que le permite saltar entre regiones semánticas sin recorrer toda la página (criterios 1.3.1 y 2.4.1).

Style Switcher

Le da al usuario la opción de cambiar entre hojas de estilo predefinidas: alto contraste, fuente ampliada, esquema de color alternativo. No es obligatorio para AA, pero ayuda a sumar puntos hacia AAA y mejora muchísimo la experiencia para personas con baja visión.

Formularios accesibles: dónde se rompen las cosas

Los formularios concentran buena parte de los incumplimientos detectados en auditorías reales. Drupal automatiza casi todo, sí, pero hay zonas que dependen de quién desarrolla el frontend.

Etiquetas y campos (criterios 1.3.1 y 3.3.2)

Cada campo de Drupal genera un <label> vinculado mediante el atributo for. El problema clásico aparece cuando un desarrollador esconde la etiqueta con display: none por gusto estético y no añade nada en su lugar. Solución correcta: la clase .visually-hidden de Drupal, que oculta visualmente pero deja el texto accesible para lectores de pantalla.

Identificación de errores (criterio 3.3.1)

Drupal muestra los errores de validación arriba del formulario, con resumen y enlaces directos a cada campo problemático. Funciona perfectamente de serie. La rotura llega cuando un tema personalizado modifica form-element-error.html.twig sin respetar la estructura ARIA original.

Autocompletado (criterio 1.3.5)

Desde WCAG 2.1, los campos de datos personales (nombre, email, teléfono, dirección) deben llevar el atributo autocomplete con los valores adecuados. Drupal no lo pone por defecto. Toca añadirlo vía hook form_alter:

function mimodulo_form_alter(&$form, $form_state, $form_id) {
  if (isset($form['field_email'])) {
    $form['field_email']['widget'][0]['value']['#attributes']['autocomplete'] = 'email';
  }
}

Multimedia accesible: vídeo, audio y PDFs

Subtítulos y audiodescripción (criterios 1.2.1 a 1.2.5)

Si el sitio tiene vídeo, el nivel AA pide subtítulos sincronizados (1.2.2) y audiodescripción o alternativa textual completa (1.2.3 y 1.2.5). El módulo Video Embed Field cubre la incrustación desde YouTube o Vimeo, pero los subtítulos se trabajan en la plataforma origen.

¿Vídeo alojado localmente? El reproductor HTML5 de Drupal admite pistas WebVTT mediante el elemento <track>. Crea un campo "File" para el archivo .vtt y enlázalo al campo de vídeo desde la plantilla del nodo.

Documentos PDF (criterios 1.1.1 y 1.3.1)

Los PDFs descargables son uno de los puntos negros más constantes de las webs corporativas españolas. Si publicas catálogos, fichas técnicas o documentación legal en PDF, cada archivo debería estar etiquetado estructuralmente (PDF/UA). La alternativa realista, cuando la conversión a PDF accesible no es viable, es ofrecer siempre la versión HTML del mismo contenido junto al enlace de descarga.

Validación y testing: herramientas y flujo de trabajo

Un testing serio mezcla siempre automático y manual. Ninguno funciona por sí solo.

Testing automático con axe-core y Pa11y

Mete axe-core en tu pipeline de CI/CD. Detectarás entre el 30 y el 40% de los problemas reales: los que un robot puede ver. Pa11y CI complementa muy bien al permitirte definir umbrales y lanzar alertas cuando un despliegue introduce regresiones de accesibilidad.

Ejemplo de configuración en .pa11yci.json:

{
  "defaults": {
    "standard": "WCAG2AA",
    "timeout": 10000,
    "wait": 2000
  },
  "urls": [
    "https://tusitio.es/",
    "https://tusitio.es/contacto",
    "https://tusitio.es/servicios"
  ]
}

Testing manual: lo que ningún script va a encontrar

El 60-70% restante solo aparece probando a mano:

Navegación con teclado: recorre el sitio entero usando únicamente Tab, Shift+Tab, Enter y flechas. ¿El foco siempre es visible? ¿Hay trampas de teclado? (criterio 2.1.2).
Lectores de pantalla: prueba con NVDA (gratuito, Windows) o VoiceOver (macOS/iOS). Encabezados, enlaces, formularios y tablas deben anunciarse de forma comprensible.
Zoom al 200%: amplía el navegador al 200% y revisa que ningún contenido ni funcionalidad se pierde por el camino (criterio 1.4.4).

Declaración de accesibilidad

La normativa española exige publicar una declaración de accesibilidad. Debe indicar el nivel de conformidad alcanzado, las áreas no conformes con su justificación, la fecha de la última revisión y un canal de contacto para reportar problemas. En Drupal lo más cómodo es mantenerla como un nodo estándar con revisiones versionadas.

Mantenimiento continuo: no es un hito, es un proceso

La accesibilidad no se "termina". Cada nuevo contenido publicado, cada módulo actualizado, cada rediseño puede meter una barrera nueva sin que nadie lo note.

Conviene tener un protocolo claro con cuatro piezas:

Formación del equipo editorial. Un taller de 4 horas sobre cómo redactar textos alternativos, estructurar encabezados y escribir enlaces descriptivos reduce de manera drástica los problemas que entran por contenido.
Revisión trimestral con axe-core. Lanza un escaneo completo del sitio y documenta los resultados para tener histórico.
Auditoría anual por un tercero. Empresas como Ilunion Accesibilidad o Technosite, ambas con sede en España, realizan auditorías completas con usuarios reales con discapacidad.
Mantener el core de Drupal y los módulos al día. Muchas actualizaciones de seguridad incluyen también mejoras de accesibilidad. Si dejas el sitio congelado, la accesibilidad también se congela.

Más allá del cumplimiento: la accesibilidad como ventaja competitiva

Cumplir WCAG 2.1 AA no es solo blindar el sitio frente a sanciones. Una web accesible carga más rápido (menos JavaScript de relleno, HTML semántico más limpio), posiciona mejor en Google (la estructura semántica y los alt texts son señales de calidad para el rastreador) y convierte más (formularios claros, navegación predecible, mensajes de error comprensibles).

En un mercado donde, según el Observatorio de Accesibilidad Web, el 73% de las webs corporativas españolas suspenden en accesibilidad, ofrecer una experiencia accesible deja de ser un detalle ético para convertirse en una ventaja real frente a la competencia.

Si quieres un equipo que construya tu sitio Drupal con accesibilidad integrada desde la arquitectura hasta la última línea de CSS, cuéntanos tu proyecto. Trabajamos con los criterios WCAG como requisito de aceptación en cada sprint, no como un parche de última hora.