Accesibilidad WCAG AA para una fundación del autismo en Aragón.

Contexto

La Fundación a·Autismo nace de la unión de tres entidades aragonesas de referencia en autismo —ATADES, Autismo Huesca y Autismo Teruel— para representar con una sola voz a las familias y personas con TEA de Zaragoza, Huesca y Teruel. Para una organización así, la accesibilidad de su web no es un requisito que marcar en una lista: es coherencia con su misión, porque parte de su audiencia es neurodivergente o tiene baja visión.

El problema

El encargo era rediseñar la web institucional con la accesibilidad WCAG 2.1 AA como eje del proyecto —no como capa final—, sobre un sistema de marca ya definido y con una condición firme: que el equipo de la Fundación pudiera editar y publicar por su cuenta, sin depender de desarrollo para cada cambio.

La decisión

Tres decisiones definieron la arquitectura:

• Conformidad nativa, no un overlay. Se descartaron los widgets de accesibilidad de mercado (UserWay, One Click Accessibility y similares): superponen una capa de JavaScript de terceros que no corrige el marcado subyacente y que la propia comunidad de accesibilidad desaconseja. En su lugar, la conformidad se construyó en el HTML y el CSS del tema —un único <h1>, skip-link propio, foco visible, contraste medido— y los ajustes del usuario en un plugin propio, sin dependencias externas.
• Tema de bloques (FSE) para autonomía editorial. El cliente edita con el editor del sitio de WordPress; el tema se «bloquea» en sus valores por defecto para que esa libertad no pueda romper el contraste ni la jerarquía de encabezados.
• Accesibilidad y componentes extraídos a plugins acompañantes, para que sobrevivan a un eventual cambio de tema. La tipografía es Atkinson Hyperlegible —diseñada para baja visión— auto-alojada, sin Google Fonts.

Trade-off asumido y documentado: dos colores de marca quedan justo en el umbral de contraste para texto grande; se mantienen por decisión de marca y se dejan monitorizados.

La implementación

La barra de accesibilidad ofrece cinco controles: escalado de texto en cuatro pasos, modo de contraste/daltonismo, resaltado de enlaces, tipografía para dislexia y reducción de animaciones (que además respeta prefers-reduced-motion). El estado se guarda en el navegador y se aplica antes del primer pintado para evitar parpadeos, con estados ARIA en todos los controles.

El mismo criterio se aplicó al resto: un banner de cookies propio, granular y conforme a RGPD/AEPD, con «Aceptar» y «Rechazar» del mismo peso visual (sin patrones oscuros) y vídeos de YouTube servidos sin cookies; y un formulario de contacto accesible —etiquetas, mensajes de estado y error que reciben el foco— protegido con nonce y honeypot, sin servicios de terceros.

El resultado

Una auditoría interna sobre la web en producción verifica conformidad WCAG 2.1 AA en las plantillas evaluadas, con puntuaciones Lighthouse de accesibilidad de 96–97 y de 100 en buenas prácticas y SEO. El rendimiento acompaña: LCP de 639 ms y CLS de 0 en laboratorio, con cada ratio de contraste medido elemento a elemento. La verificación es una revisión técnica del equipo de desarrollo, no una certificación de un tercero independiente; la prueba con lectores de pantalla queda prevista como cierre.

Preguntas frecuentes

¿Por qué no usar un widget de accesibilidad de mercado? Los overlays superponen JavaScript de terceros pero no corrigen el marcado real; la accesibilidad efectiva —y la conformidad WCAG— vive en el HTML, el contraste y la gestión del foco, no en una capa añadida. Por eso se implementó a medida.

¿Qué significa «WCAG 2.1 AA»? Es el nivel de conformidad de referencia de las Pautas de Accesibilidad para el Contenido Web: cubre contraste suficiente, texto redimensionable, navegación por teclado, foco visible y alternativas textuales, entre otros.

¿Se puede hacer accesible un WordPress que edita el cliente? Sí, si el tema se diseña «bloqueando» sus valores por defecto para que la edición no pueda romper el contraste ni la jerarquía — que es justo el enfoque de este proyecto.