En un contexto en el que la European Accessibility Act (EAA) establece criterios claros y obligaciones legales para garantizar el acceso universal a productos y servicios digitales – tal y como detallamos en este artículo sobre la EAA: requisitos y obligaciones – el diseño web accesible se convierte en la clave para que todas las personas, independientemente de sus capacidades, puedan navegar y consumir información sin barreras.
Diseñar pensando en la accesibilidad no es sólo cumplir con un mandato normativo; es ofrecer una experiencia inclusiva
- Facilita la lectura y navegación a usuarios con diversidad visual, auditiva o motriz.
- Mejora la usabilidad y la comprensión para personas con dificultades cognitivas.
- Aumenta el alcance de tu sitio al garantizar compatibilidad con tecnologías de asistencia (lectores de pantalla, teclados adaptados, etc.).
- Optimiza el rendimiento: códigos semánticos, etiquetas ARIA y recursos optimizados reducen tiempos de carga y mejoran el SEO.
- Enriquece la reputación de marca: las empresas comprometidas con la inclusión generan mayor confianza y fidelidad.
En esta guía centrada en diseño web accesible, veremos no solo los principios universales (perceptible, operable, comprensible y robusto) sino también cómo aplicarlos en WordPress, la plataforma que impulsa más del 40 % de la web global.
Principio 1. Perceptible
1.1.1 Contenido no textual (A)
Cada imagen, icono o gráfico necesita un atributo alt descriptivo. En WordPress, abre Medios → Biblioteca en vista de lista y completa el campo “Texto alternativo”. Usa alt="" solo si el gráfico es meramente decorativo. w3.org
1.2.1 Audio-only y vídeo-only pregrabados (A)
Sube transcripciones textuales para audios y ofrece una pista de audiodescripción sincronizada si el vídeo carece de pista sonora esencial. WordPress permite adjuntar la transcripción como archivo o incrustarla en un bloque “Detalles”.
1.2.2 Subtítulos para vídeo pregrabado (A)
Genera un archivo .vtt y súbelo mediante el bloque “Vídeo”. Plugins como VideoPress añaden un selector de subtítulos accesible.
1.2.3 Audiodescripción o alternativa para vídeo (A)
Cuando la información clave solo sea visual (por ejemplo, gestos), incorpora una pista de audiodescripción o un segundo vídeo alternativo con locución.
1.2.4 Subtítulos en directo (AA)
Para streaming en vivo incrustado en WordPress, conecta la salida de herramientas de estenotipia o IA —p. ej. Otter Live Captions— a una pista de subtítulos WebVTT que se sirva en tiempo real.
1.2.5 Audiodescripción (pregrabado) (AA)
Añade narración adicional que describa escenas significativas y súbela como pista de audio secundaria en el bloque “Vídeo”.
1.3.1 Información y relaciones (A)
Utiliza HTML semántico: <header>, <nav>, <main>, <footer>, listas y encabezados correctos. Los constructores visuales modernos respetan esa estructura si no se desactiva el marcado nativo.
1.3.2 Secuencia significativa (A)
Evita reorganizar visualmente el flujo lógico con flex-order o grid-area sin actualizar el DOM; lectores de pantalla siguen el orden del código.
1.3.3 Características sensoriales (A)
No confíes solo en color, forma o posición para transmitir un mensaje. En un formulario, combina el borde rojo con un icono ❌ y un mensaje textual.
1.3.4 Orientación (AA)
Diseña para vertical y horizontal. Prueba tu tema en móvil girando la pantalla: ningún elemento debe desaparecer ni romper el layout.
1.3.5 Identificación del propósito de los campos (AA)
Añade atributos autocomplete como email, name o postal-code en los bloques de formulario (Gravity Forms los incluye por defecto).
1.4.1 Uso del color (A)
Asegúrate de que vínculos, alertas o estados se distingan también por subrayado, texto o iconos.
1.4.2 Control de audio (A)
Si se reproduce sonido automáticamente durante más de tres segundos, ofrece un botón de pausa. El widget de accesibilidad de WP Accessibility agrega ese control global. wordpress.org
1.4.3 Contraste mínimo (AA)
El texto y su fondo deben alcanzar una ratio 4.5:1 (o 3:1 para tipografía ≥ 24 px o 19 px bold). Usa el comprobador de contraste que viene en el inspector del plugin Accessibility Checker. wordpress.org
1.4.4 Redimensionar texto (AA)
Verifica que aumentar el zoom al 200 % no fuerce scroll horizontal; los temas responsive modernos lo gestionan si no se fijan anchos absolutos.
1.4.5 Imágenes de texto (AA)
Reemplaza titulares en PNG/JPG por títulos HTML con la fuente cargada vía CSS.
1.4.10 Reflow (AA)
En un viewport de 320 px de ancho todo el contenido debe seguir disponible sin desplazamiento horizontal; evita tablas de ancho fijo.
1.4.11 Contraste de elementos no textuales (AA)
Iconos, bordes de botones y focos necesitan al menos 3:1 frente a su fondo. Ajusta la paleta en Apariencia → Personalizar → Colores.
1.4.12 Espaciado de texto (AA)
No impidas que el usuario eleve el line-height al 1.5 ni los márgenes párrafo-párrafo al 2; evita overflow:hidden que recorte el texto.
1.4.13 Contenido al hacer hover o focar (AA)
Tooltips accesibles: permanecen visibles al mover el puntero al cuadro emergente y se cierran con Esc. Comprueba accesibilidad con la extensión axe DevTools.
Principio 2. Operable
2.1.1 Teclado (A)
Todo lo que se pueda hacer con ratón debe ser posible con Tab, flechas y Enter. Haz una pasada completa con el teclado y documenta atajos de salto.
2.1.2 Sin trampas de teclado (A)
Un modal debe cerrarse con Esc o un botón con role="button" y foco por defecto.
2.1.4 Atajos de teclas de un solo carácter (A)
Si tu tema define accesos rápidos —por ejemplo, “S” para buscar— incluye un interruptor en Preferencias → Accesibilidad o exige combinaciones con Alt o Ctrl.
2.2.1 Tiempo ajustable (A)
Sesiones que expiran (carritos de compra, cuestionarios) necesitan avisos y opción de alargar el tiempo. Plugins de membership permiten configurar un temporizador con botón “Seguir”.
2.2.2 Pausar, detener u ocultar (A)
Los carruseles automáticos de bloques “Galería” deben mostrar controles de pausa y no reiniciarse al perder el foco.
2.3.1 Tres destellos o menos (A)
Evita GIF o CSS animations que parpadeen más de tres veces por segundo; usa transiciones suaves en su lugar.
2.4.1 Saltar bloques (A)
Asegura un enlace “Saltar al contenido principal” antes del <main>. Plugins como WP Accessibility lo insertan sin código. wordpress.org
2.4.2 Título de página (A)
Cada documento debe tener un <title> único y descriptivo; en WordPress se edita en Ajustes → Lectura o mediante SEO plugins.
2.4.3 Orden de foco (A)
Comprueba que el tabulador siga un flujo lógico visual. Evita tabindex manual salvo para corregir excepciones.
2.4.4 Propósito del enlace (A)
El texto del link debe describir el destino: “Descargar informe PDF” en vez de “clic aquí”.
2.5.1 Gestos de puntero (A)
No dependas de deslizamientos o gestos multipunto: añade alternativas de clic único a carruseles táctiles.
2.5.2 Cancelación de puntero (A)
Acciones arrastrar-y-soltar requieren que sea posible abortar antes de soltar, por ejemplo liberando el dedo fuera de la zona activa.
2.5.3 Etiqueta en el nombre (A)
El texto visible de un botón debe coincidir con su aria-label; si el botón muestra 🔍 “Buscar”, no lo etiquetes como “Ir”.
2.5.4 Activación por movimiento (A)
Si una función usa agitar el dispositivo o girarlo, facilita un control en pantalla para conseguir lo mismo.
2.4.5 Múltiples vías (AA)
Ofrece al menos dos métodos para encontrar contenido: menú, buscador interno o mapa del sitio XML/HTML.
2.4.6 Encabezados y etiquetas (AA)
Emplea <h1> para el título principal y desciende jerárquicamente sin saltos (H2→H3).
2.4.7 Foco visible (AA)
Añade estilos como :focus {outline:3px solid currentColor;} en el customizer o con WP CSS.
Principio 3. Comprensible
3.1.1 Idioma de la página (A)
Define lang="es" (o el idioma principal) en Ajustes → Generales.
3.2.1 Al recibir foco (A)
No abras menús ni ventanas automáticamente al llegar el foco con el teclado; usa clic o Enter.
3.2.2 Al recibir entrada (A)
Un <select> que cambia de página tras elegir debe incluir antes un botón “Ir” o pedir confirmación.
3.3.1 Identificación de errores (A)
Mensajes claros junto al campo: “El correo no es válido”. Plugins de formularios como CF7 permiten mensajes personalizados.
3.3.2 Etiquetas o instrucciones (A)
Cada control de formulario necesita un <label> explicitamente relacionado y, si procede, texto de ayuda.
3.1.2 Idioma de partes (AA)
Si insertas una cita en inglés, encapsúlala con <span lang="en"> para que el lector cambie de síntesis.
3.2.3 Navegación consistente (AA)
La barra de navegación debe mantenerse en la misma posición y con el mismo orden en todas las páginas.
3.2.4 Identificación consistente (AA)
Usa siempre el mismo icono y texto para acciones idénticas; no mezcles “Mis pedidos” con “Pedidos”.
3.3.3 Sugerencias ante errores (AA)
Al validar formularios, ofrece correcciones: “¿Quizás querías ‘.com’ en lugar de ‘.co’?”.
3.3.4 Prevención de errores en transacciones (AA)
Antes de procesar pagos o borrar cuentas, muestra un resumen y solicita confirmación explícita.
Principio 4. Robusto
4.1.1 Parsing (A)
El código debe validar sin errores en el W3C Validator; evita etiquetas sin cerrar y atributos duplicados.
4.1.2 Nombre, función, valor (A)
Los componentes personalizados necesitan roles ARIA; un botón con solo un icono debe tener aria-label="Buscar".
4.1.3 Mensajes de estado (AA)
Notificaciones (“Añadido al carrito”) deben anunciarse con role="status" para que los lectores de pantalla las lean sin cambiar el foco.
Herramientas, recursos y plugins para accesibilidad en WordPress
Google PageSpeed Insights
Aunque su foco principal es el rendimiento, Google PageSpeed Insights también identifica elementos clave de accesibilidad —como errores de contraste, imágenes sin atributos ALT y tamaños de fuente inadecuados— y ofrece recomendaciones detalladas para optimizar tanto la velocidad de carga como la usabilidad en dispositivos móviles y de escritorio.
WAVE: Web Accessibility Evaluation Tool
WAVE es una herramienta online gratuita que evalúa la accesibilidad de tu web y te muestra visualmente errores como falta de contraste, etiquetas ALT ausentes o mal uso de roles ARIA. Puedes usarla online o con una extensión de navegador para revisar incluso páginas en desarrollo. Es muy útil para detectar problemas antes de una auditoría, explicar mejoras al cliente o asegurar que tu sitio sea accesible para todas las personas. Desde Micelia la recomendamos como primer paso hacia un diseño más accesible.
WP Accessibility Helper (WAH)
WP Accessibility Helper ofrece un panel de control front-end que permite a los usuarios ajustar el contraste, activar un lector de pantalla embebido y aumentar dinámicamente el tamaño de texto. Todo ello sin tocar el tema o el código, facilitando la personalización de la experiencia según las necesidades de cada visitante.
Accessibility Checker
Accessibility Checker analiza tu contenido directamente en el editor de bloques Gutenberg y señala problemas en la jerarquía de encabezados, descripciones de imágenes, estructura de listas y más. Es ideal para asegurar que cada página o entrada cumpla con las mejores prácticas de accesibilidad antes de su publicación.
ResponsiveVoice
ResponsiveVoice es un plugin de Text-To-Speech que permite añadir botones para leer en voz alta cualquier texto de tu sitio en varios idiomas. Facilita la experiencia a usuarios con dificultades de lectura o discapacidad visual y se integra de forma sencilla en páginas, entradas y widgets.
Play.ht
Play.ht es otra solución de Text-To-Speech que convierte tus textos en audio utilizando voces realistas basadas en IA. Ofrece opciones de personalización de velocidad y tono, así como la posibilidad de descargar los archivos de audio para su uso offline o en otros canales.
Tema Twenty Twenty-One AU
Twenty Twenty-One AU es un tema oficial de WordPress validado con criterios WCAG 2.1 AA. Proporciona una base sólida y accesible desde el primer momento, con un diseño limpio, navegación optimizada y estructuras semánticas que facilitan auditorías y desarrollos posteriores.
Aly Accessibility
Aly Accessibility es un plugin que evalúa automáticamente tu sitio en tiempo real, detectando incumplimientos de las pautas WCAG y proponiendo correcciones prácticas. Ofrece informes descargables, seguimiento de errores y sugerencias paso a paso para mejorar la accesibilidad sin necesidad de conocimientos avanzados de código. Recientemente ha sido integrado por Elementor Websitebuilder, aunque la opción gratuita no acaba de funcionar al 100%.
Cómo mantener la conformidad … y no perderla nunca
“La accesibilidad no es un proyecto que se entrega, sino un proceso que se integra en tu día a día.”
– Equipo Micelia
Convierte la accesibilidad en un flujo continuo
Cuando editas en Gutenberg verás una pestaña nueva que añade Accessibility Checker. Cada bloque muestra alertas en tiempo real y, si hay un error recurrente (por ejemplo, falta de alt), el plugin puede sugerir una corrección con un solo clic WordPress.org. Así el control pasa del departamento técnico a cualquier editor de contenidos sin fricción.
Automatiza lo automatizable
¿Publicas a menudo? Activa el «escaneo en segundo plano» de Accessibility Checker para que analice cada nueva entrada nada más guardarla; después programa un barrido completo cada noche a las 03:00 con el modo “Bulk Scan”. Al terminar, el plugin actualiza tu declaración de accesibilidad con la fecha del último chequeo, lista los puntos conformes y enlaza los pendientes Equalize Digital.
En paralelo, WP Accessibility añade automáticamente skip links, fuerza el contraste en los focos y marca con outline los elementos navegables con teclado; todo sin tocar código y sin coste adicional WordPress.org.
Refuerzo manual (porque las máquinas no lo pillan todo)
— Mensualmente, dedica 30 min a navegar con NVDA o VoiceOver y con el teclado únicamente.
— Trimestralmente, compara tu CSS en móvil vertical y horizontal para validar el criterio de reflow.
— Anualmente, invita a una persona usuaria de lector de pantalla a probar tareas críticas y graba la sesión (consentimiento mediante).
Revisión trimestral estructurada
En el tablero de proyecto crea tres columnas fijas: Nuevos hallazgos, En curso, Listo para producción. Cada tres meses exporta el informe CSV de Accessibility Checker, arrastra los nuevos issues a la primera columna y asigna responsables. La rotación constante evita “cementerios” de tickets vencidos.
Política interna y formación continua
Define un rol “Editor Accesibilidad” en WordPress que no publica si hay errores críticos pendientes. Complementa con píldoras de micro-formación: vídeos de 3 min sobre “Cómo escribir alt eficaces” o “Cómo verificar contraste en el editor”. La ley española exige “personal formado proporcionalmente a la actividad” Level Access, y esta es una forma sencilla de demostrarlo.
Ciclo de vida de la documentación
Guarda cada informe PDF o CSV durante cinco años y súbelos a un repositorio privado (Git o Drive) etiquetados por fecha; la EN 301 549 y la Ley 11/2023 lo piden explícitamente Equalize Digital. Añade en la cabecera de tu declaración de accesibilidad la leyenda: “Última revisión técnica: 05 ago 2025”.
Línea directa con tus usuarios
Incluye en el pie de página un enlace “Accesibilidad” con un formulario de feedback que envíe un correo a un buzón dedicado; los comentarios de las personas reales son la prueba de fuego. Configura una regla: responder en menos de cinco días laborales y registrar en el tablero la acción correctiva asociada.
Resultado: conformidad viva
Con este circuito —automatización + chequeo humano + trazabilidad— no solo mantienes los 50 criterios AA. También ganas visibilidad SEO, confianza de marca y una experiencia inclusiva que, dicho claro, convierte más y fideliza mejor. La próxima auditoría no será un examen sorpresa; será un paseo por un sitio que ya respira accesibilidad en cada píxel.
Cumplir estos 50 criterios no solo evita sanciones: mejora SEO, reduce rebotes y, sobre todo, garantiza que ninguna persona quede fuera de tu contenido. Empieza hoy a revisar tu tema y tus procesos editoriales; cuando lleguen las auditorías oficiales, tu web ya será un ejemplo de accesibilidad bien lograda.
La accesibilidad no es solo una obligación legal o una mejora en la experiencia de usuario: es también una parte esencial de la sostenibilidad digital. Cuando diseñamos para que todas las personas puedan navegar sin barreras, también estamos creando sitios más eficientes, más comprensibles y más ligeros. Reducimos la necesidad de rehacer contenidos, evitamos soluciones parche y optimizamos el uso de recursos técnicos y humanos. Una web accesible carga mejor, funciona en más dispositivos, dura más tiempo sin necesidad de rediseño y se adapta mejor a futuros estándares. Todo esto se traduce en menos consumo energético, menos emisiones digitales y una menor huella tecnológica.
Si quieres profundizar en cómo crear sitios más responsables con el entorno, te recomendamos leer nuestra guía completa para diseñar webs sostenibles con WordPress. En ella exploramos cómo reducir el consumo energético de una web, optimizar su rendimiento y alinear cada decisión de diseño con criterios de sostenibilidad digital. Una lectura imprescindible si buscas que tu web no solo sea accesible, sino también respetuosa con el planeta.
En Micelia entendemos la sostenibilidad digital como un enfoque integral que une accesibilidad, eficiencia energética, diseño inclusivo y responsabilidad con el entorno. Porque una web que excluye, contamina. Y una web accesible, bien pensada y consciente, construye futuro.