Declaración de accesibilidad para WordPress: plantilla + mapeo EN 301 549
Una declaración de accesibilidad es un entregable legal distinto de una auditoría WCAG. Puedes superar cada escaneo automatizado en un sitio WordPress y aun así no cumplir con la Ley 11/2023 o con el Real Decreto 1112/2018, porque ambas exigen la declaración en sí misma: un estado de conformidad publicado, la norma frente a la que se testó, una lista de limitaciones conocidas y un mecanismo de comentarios funcional que un visitante pueda usar para presentar una reclamación. Este artículo es una pieza de apoyo dentro de la pila de cumplimiento de WCAG 2.2, BFSG y la Ley Europea de Accesibilidad, centrada específicamente en el documento de la declaración y en cómo sus secciones se mapean a la EN 301 549, la norma europea que realmente citan los equipos de contratación.
Lo que tienes que publicar, en resumen
- Una página dedicada, enlazada desde el pie de página, no un párrafo dentro de tu política de privacidad.
- Un estado de conformidad: total, parcial con excepciones nombradas, o no conforme.
- La norma frente a la que se testó: en la práctica la WCAG 2.2 AA, referenciada contra la EN 301 549 para audiencias de contratación.
- Una lista de limitaciones conocidas con, cuando sea posible, una fecha de corrección.
- Un contacto de comentarios que realmente llegue a un buzón supervisado, además de una vía de vigilancia o escalado.
- Una fecha de preparación y un ritmo de revisión, porque “probamos esto una vez en 2023” no es una declaración actual.
Nada de esto sustituye a una auditoría técnica. Documenta el resultado de una. Si todavía no has realizado una auditoría WCAG 2.2 AA, la declaración exagerará la conformidad o parecerá un marcador de posición, y ambos resultados atraen más escrutinio que no tener ninguna declaración.
Cuándo es obligatoria una declaración de accesibilidad en la UE
Tres bases legales que se solapan colocan una declaración de accesibilidad en la lista de obligaciones de un operador WordPress, y no todas se dirigen a la misma audiencia.
La Directiva (UE) 2016/2102, la directiva de accesibilidad web, exige a los organismos del sector público publicar y actualizar periódicamente una declaración de accesibilidad para cada sitio web y aplicación móvil que operan. En España, se transpuso mediante el Real Decreto 1112/2018, que exige el cumplimiento de la norma UNE-EN 301549 (equivalente técnico de la WCAG 2.1 AA) y la publicación de una declaración de accesibilidad para toda la Administración pública. Esto es anterior a la EAA y se aplica con independencia de lo demás: un ayuntamiento con WordPress, el blog de una universidad pública, el portal de prensa de un organismo estatal están todos dentro del ámbito, con independencia de todo lo que sigue.
La Ley Europea de Accesibilidad (Directiva 2019/882), en vigor desde 2025-06-28, extiende obligaciones comparables a los operadores privados de categorías concretas de productos y servicios: comercio electrónico, servicios bancarios, transporte, libros electrónicos y otros enumerados en el anexo I de la directiva. En España, esto se implementa mediante la Ley 11/2023, de 8 de mayo, cuyo Título I produce efectos plenos desde el 28 de junio de 2025 y exige conformidad con la norma técnica UNE-EN 301549.
Las transposiciones nacionales rellenan el detalle operativo. Las sanciones por incumplimiento de la Ley 11/2023 pueden alcanzar los 600.000 EUR para las infracciones muy graves, y las autoridades de vigilancia del mercado designadas ya han indicado que fiscalizarán activamente. En la práctica, esto significa que una declaración publicada es la forma más sencilla de demostrar que el proceso de reclamaciones existe antes de que llegue ninguna reclamación.
Las exenciones que conviene conocer antes de redactar nada: las microempresas (menos de 10 empleados, volumen de negocio o balance anual inferior a 2 millones de EUR) están exentas de varias obligaciones de servicios de la EAA, aunque la exención es más estrecha para los fabricantes de productos. Los organismos públicos no tienen ninguna exención por tamaño según el Real Decreto 1112/2018. Las alegaciones de carga desproporcionada existen en ambos regímenes, pero requieren una evaluación documentada, no una nota a pie de página que diga “no aplica”.
El artículo pilar sobre la WCAG 2.2, el BFSG y la Ley Europea de Accesibilidad cubre la pila de cumplimiento completa, incluyendo el ritmo de auditoría que produce el estado de conformidad que documenta esta declaración.
EN 301 549 frente a WCAG 2.2 AA: qué pide realmente la contratación pública
La WCAG 2.2 AA es lo que tu equipo de desarrollo testa. La EN 301 549 es lo que cita un responsable de contratación, un pliego de licitación o una auditoría del sector público, porque es la norma europea armonizada para la accesibilidad TIC en general, no solo para el contenido web.
La versión actualmente en vigor es la EN 301 549 V3.2.1, publicada en marzo de 2021 y citada en el Diario Oficial de la UE bajo la Directiva 2016/2102 mediante la Decisión de Ejecución (UE) 2021/1339 de la Comisión. Su capítulo web, el capítulo 9, incorpora por referencia los criterios de éxito de la WCAG 2.1 nivel A y AA. Una revisión que incorpore la WCAG 2.2 está en elaboración dentro del organismo técnico conjunto ETSI/CEN/CENELEC, con publicación esperada en 2026 bajo el mandato de normalización M/587 de la Comisión Europea, pero todavía no es la versión citada en el Diario Oficial.
Esto crea una brecha práctica que los documentos de contratación rara vez resuelven con claridad: la base legalmente referenciada es la WCAG 2.1 AA, mientras que el objetivo actual de mejor práctica, y a lo que realmente construyen la mayoría de las agencias (incluida la nuestra), es la WCAG 2.2 AA. Como la 2.2 es un superconjunto estricto de la 2.1 con nueve criterios de éxito adicionales, testar y documentar frente a la 2.2 AA también satisface la base 2.1 AA que la EN 301 549 referencia actualmente. No hay riesgo de desajuste de versión al construir sobre el estándar más nuevo; el riesgo va en la otra dirección, si construyes solo para la 2.1 y la revisión de la EN 301 549 se publica a mitad de contrato.
Más allá del capítulo web, la EN 301 549 tiene otros once capítulos. Los tres más relevantes para un despliegue típico en WordPress más allá del propio contenido web:
- Capítulo 10, documentos no web. Los PDF, hojas de cálculo y presentaciones publicados a través del sitio (listas de precios, informes anuales, documentos de licitación) necesitan etiquetado correcto, orden de lectura y tablas accesibles, con independencia de lo accesible que sea la página que los rodea.
- Capítulo 11, software. Relevante cuando el propio panel de administración de WordPress es el producto evaluado, por ejemplo un equipo editorial del sector público que usa el editor de bloques como herramienta de autoría, o un plugin personalizado que expone un interfaz de formulario a los usuarios finales.
- Capítulo 12, documentación y servicios de soporte. Las páginas de ayuda, las guías de incorporación y los canales de soporte enlazados desde el sitio deben cumplir el mismo nivel de accesibilidad que el contenido principal, y la propia comunicación de soporte tiene que estar disponible a través de más de un canal.
Secciones de la plantilla con encabezados listos para copiar
El orden de secciones siguiente es la estructura que aparece en la mayoría de las declaraciones de accesibilidad de la UE construidas sobre el marco EN 301 549 / EAA / transposiciones nacionales. Es ilustrativo: rellénalo con tus resultados reales de auditoría, no con texto de marcador de posición, y haz que lo revise quien se encargue de la aprobación de cumplimiento en tu organización antes de publicarlo.
# Declaración de accesibilidad para [nombre del sitio]
## Estado de conformidad
[Nombre del sitio] es [totalmente conforme / parcialmente conforme / no
conforme] con la WCAG 2.2 nivel AA, evaluado frente a los requisitos
referenciados en la EN 301 549. [Elige uno:]
- Totalmente conforme significa que el contenido cumple totalmente la
norma sin excepciones.
- Parcialmente conforme significa que algunas partes del contenido no
cumplen totalmente la norma, listadas en "limitaciones conocidas" a
continuación.
## Norma aplicable
Esta declaración se basa en una autoevaluación / una evaluación
realizada por [nombre o cargo del evaluador] el [fecha], frente a:
- Web Content Accessibility Guidelines (WCAG) 2.2, nivel AA
- EN 301 549, [versión], capítulo 9 (Web)
[Lista los capítulos 10, 11, 12 aquí solo si también se evaluaron
documentos no web, software o servicios de soporte.]
## Limitaciones conocidas
El siguiente contenido todavía no es totalmente accesible:
- [Limitación específica, p. ej. "el widget de reservas incrustado en
/contacto/ no puede operarse solo con teclado"], que afecta a [qué
criterio de éxito], fecha objetivo de corrección: [fecha o "en
revisión"].
- [Repite por cada problema conocido. No resumas varios problemas en
una línea vaga; lístalos individualmente.]
## Preparación de esta declaración
Esta declaración se preparó el [fecha] y se revisó por última vez el
[fecha]. Se preparó a partir de [autoevaluación / auditoría de un
tercero], cubriendo [alcance: p. ej. "las páginas públicas bajo
ejemplo.com, excluyendo el contenido incrustado de terceros"].
## Comentarios e información de contacto
Si encuentras una barrera de accesibilidad en este sitio, contáctanos:
- Correo electrónico: [dirección supervisada]
- [Opcional: teléfono, URL del formulario de contacto]
Procuramos responder en un plazo de [X] días hábiles.
## Procedimiento de vigilancia
Si no quedas satisfecho con nuestra respuesta, puedes escalar a:
[Organismo nacional de vigilancia o resolución de conflictos, con URL,
relevante para la jurisdicción en la que el operador está establecido
o presta servicio.]
## Especificaciones técnicas
Este sitio se basa en las siguientes tecnologías para la conformidad:
HTML, CSS, JavaScript, WAI-ARIA.Dos secciones merecen más cuidado del que puede darles una plantilla genérica. Limitaciones conocidas es la sección que más declaraciones hacen mal, ya sea omitiéndola por completo (afirmando conformidad total mientras un escaneo automatizado muestra fallos) o redactándola de forma tan vaga que no aporta ninguna prueba de una evaluación real. Procedimiento de vigilancia necesita un destino real, no “contacta con tu autoridad nacional”, porque el sentido de la sección es que un visitante insatisfecho pueda actuar sobre ella sin necesitar más investigación.
Tabla de mapeo: requisito de la EN 301 549 a implementación en WordPress
El capítulo 4 de la EN 301 549 establece declaraciones de rendimiento funcional (uso sin visión, uso con destreza manual limitada y similares) que se usan cuando un criterio de éxito concreto no mapea de forma limpia a un interfaz novedoso. Para un frontend WordPress estándar, la mayor parte del trabajo de mapeo ocurre en los capítulos 9, 10, 11 y 12.
| Cláusula de la EN 301 549 | Qué exige | Entregable en WordPress |
|---|---|---|
| Capítulo 9 (Web), vía WCAG 1.1.1 / 1.3.1 | El contenido no textual tiene una alternativa textual; la estructura del contenido se transmite programáticamente | Campo de texto alternativo exigido en el flujo de trabajo de la biblioteca de medios; niveles de encabezado aplicados mediante bloques de encabezado en el editor de bloques, no mediante estilo visual sobre texto de párrafo |
| Capítulo 9 (Web), vía WCAG 1.4.3 / 1.4.11 | El contraste de texto y de elementos no textuales cumple los ratios mínimos | Tokens de color del tema testados a 4,5:1 para el texto principal, 3:1 para componentes de interfaz, comprobados en el sistema de diseño en lugar de página por página |
| Capítulo 9 (Web), vía WCAG 2.1.1 / 2.4.7 (2.4.11 en 2.2) | Operabilidad total por teclado con un indicador de foco visible y no ocultado | Enlace de salto antes del menú principal, mega-menú operable sin ratón, estilo :focus-visible no eliminado por una hoja de estilos de reinicio |
| Capítulo 9 (Web), vía WCAG 3.3.2 | Los campos de formulario tienen etiquetas o instrucciones visibles | Los formularios de contacto y de checkout usan asociaciones label for en lugar de campos solo con marcador de posición, también en Gravity Forms / WPForms / checkout de WooCommerce |
| Capítulo 9 (Web), vía WCAG 4.1.2 | Los componentes de interfaz personalizados exponen nombre, rol y valor a la tecnología de asistencia | Roles y estados ARIA en acordeones, paneles de pestañas y carruseles construidos con JavaScript propio, no dejados como elementos div sin etiquetar |
| Capítulo 10 (Documentos no web) | Los documentos distribuidos junto con el sitio son en sí mismos accesibles | Exportaciones PDF etiquetadas para listas de precios, paquetes de licitación e informes anuales; los PDF escaneados con imágenes sustituidos por exportación basada en texto |
| Capítulo 11 (Software) | Las herramientas de autoría usadas para producir contenido admiten una salida accesible | Editor de bloques configurado para que los autores puedan fijar texto alternativo y niveles de encabezado sin código personalizado; sin dependencia de HTML crudo del editor clásico para la estructura |
| Capítulo 12 (Documentación y servicios de soporte) | La documentación de soporte y los canales de comunicación son accesibles y están disponibles a través de más de una modalidad | Páginas de ayuda que cumplen el mismo nivel de la WCAG que las páginas de marketing; al menos un canal de contacto sin teléfono; la propia declaración de accesibilidad, en un formato que cumple la norma que describe |
Esta tabla es la columna vertebral de un informe de conformidad al estilo VPAT si un cliente del sector público lo solicita; cada fila se convierte en una línea con estado aprobado, parcial o no aprobado una vez que se ha ejecutado tu auditoría.
Dónde publicar la declaración en WordPress: pie de página, página dedicada, schema
Enlace en el pie de página, en cada página. La señal más comprobada en una revisión de vigilancia es si la declaración es accesible desde cualquier parte del sitio sin necesidad de buscar. Un enlace en el pie de página, junto a la política de privacidad y los términos, satisface esto sin trabajo de desarrollo adicional. Si el pie de página de tu tema se gestiona mediante un área de widgets o una plantilla global de pie de página, añade el enlace ahí una vez, no por página.
Página dedicada, con su propia URL. No integres la declaración dentro de la política de privacidad o los términos de servicio. Dale una URL independiente como /declaracion-de-accesibilidad/, configurada mediante una página normal de WordPress (o una entrada de contenido MDX, en este stack), para que pueda revisarse y versionarse de forma independiente del resto del contenido legal.
Datos estructurados, opcional pero útil para auditorías de contratación. Un bloque JSON-LD de tipo WebPage en la página de la declaración, con el dateModified de la página coincidiendo con tu última fecha de revisión, da a un rastreador automatizado o a una herramienta de checklist de contratación una confirmación legible por máquina de que la declaración existe y cuándo se tocó por última vez. Esto no sustituye al contenido legible por humanos; es una pequeña adición que elimina la ambigüedad cuando alguien ejecuta un escaneo automatizado de cumplimiento contra tu dominio.
Ritmo de revisión, documentado en la propia declaración. Indica con qué frecuencia se revisa la declaración (anualmente, o después de cualquier rediseño importante) y cúmplelo. Una declaración fechada hace tres años, con un campo de “última revisión” que nadie ha tocado, es una de las primeras cosas que marcará un auditor o el equipo legal de un competidor.
Flujo de reclamaciones y comentarios
El mecanismo de comentarios es la parte de la Ley 11/2023 y la EAA que una auditoría puramente de frontend no puede satisfacer, porque es un requisito de proceso, no de código.
- Recepción. Una dirección de correo electrónico supervisada o un formulario de contacto, distinto del soporte general, para que las reclamaciones de accesibilidad no se pierdan en una cola genérica. Enrútala a quien sea responsable del cumplimiento, no solo al webmaster.
- Confirmación. Confirma la recepción dentro de un plazo declarado (habitualmente unos pocos días hábiles). La confirmación debe reformular la barrera reportada para que el visitante sepa que se entendió correctamente.
- Investigación. Reproduce la barrera, compruébala frente al criterio de éxito de la WCAG relevante, y registra el hallazgo, ya sea que confirme una limitación conocida ya listada en la declaración o que revele una nueva.
- Respuesta y plan de corrección. Comunica al visitante qué se encontró y, si es una barrera real, cuándo se corregirá o por qué no puede hacerse (carga desproporcionada, contenido de terceros fuera de tu control y similares, documentado en lugar de simplemente afirmado).
- Vía de escalado. Si el visitante no queda satisfecho, dirígelo al organismo de vigilancia o resolución de conflictos correspondiente. En España, esa función recae en las autoridades de vigilancia del mercado designadas para la Ley 11/2023; otros Estados miembros designan su propia autoridad de vigilancia del mercado según la EAA.
- Registro interno. Mantén un registro de cada reclamación recibida y su resolución. Este registro es lo que convierte “tenemos un proceso” de una afirmación en la declaración en una prueba durante una auditoría o una investigación de vigilancia.
Ninguno de estos pasos requiere software nuevo. Un buzón compartido, una simple hoja de cálculo o una etiqueta de ticket, y un responsable nombrado cubren el requisito para la mayoría de los operadores WordPress. Lo que importa es que el proceso esté documentado en la declaración y se siga realmente cuando llega una reclamación, no que se invente retroactivamente después de que llegue una.
Cómo encaja esto en el entregable del audit de cumplimiento UE
Una declaración de accesibilidad es uno de varios entregables dentro de una auditoría de cumplimiento UE para WordPress más amplia, que también cubre el mapeo de proveedores NIS2/DORA y las obligaciones de etiquetado de contenido de la AI Act cuando corresponde. Dentro de la parte de accesibilidad de esa auditoría, la declaración es el entregable que convierte un informe técnico WCAG 2.2 AA en algo sobre lo que un responsable de cumplimiento, un revisor de contratación pública o un organismo de vigilancia puede actuar sin leer el resultado subyacente del escaneo.
La secuencia que produce una declaración defendible, en el orden en que la ejecutamos:
- Auditoría técnica WCAG 2.2 AA, automatizada más manual, sobre la muestra representativa de páginas descrita en la pila de cumplimiento WCAG/BFSG/EAA.
- Lista de brechas vinculada a criterios de éxito concretos, no un resumen genérico de “se encontraron algunos problemas”, porque la sección de limitaciones conocidas de la declaración necesita elementos concretos y nombrados.
- Borrador de la declaración usando la estructura de secciones anterior, rellenada con el resultado real de la auditoría en lugar de una afirmación de conformidad de marcador de posición.
- Configuración del flujo de comentarios, conectado a un buzón real y a un responsable nombrado, probado con una reclamación de prueba antes de publicar.
- Publicación, enlazada desde el pie de página, en su propia URL, con una fecha de revisión fijada para el siguiente ciclo.
Si estás ejecutando esto como parte de un proyecto más amplio de preparación EAA/WCAG, la visión general de la Ley Europea de Accesibilidad y la WCAG es el punto de partida para preguntas de alcance (quién está exento, qué significa “puesto en el mercado” para un contrato de servicios), mientras que este artículo cubre específicamente el documento de la declaración una vez que la auditoría subyacente está hecha.
