La accesibilidad web tiene mala fama de tema aburrido y caro, y suele quedarse en la lista de «cuando tengamos tiempo». Merece la pena replantearlo por tres motivos muy concretos: afecta a mucha más gente de la que parece, buena parte de lo que arreglas mejora la web para todos, y desde hace unos años hay obligaciones legales que alcanzan a bastantes empresas privadas en España.
La buena noticia: la mayor parte de los problemas de accesibilidad de un WordPress normal son cuatro o cinco cosas repetidas, se detectan en una tarde y se arreglan sin rehacer nada.
Antes de empezar: qué detecta una máquina y qué no
Esto marca todo el enfoque, así que va primero.
Las herramientas automáticas —y la IA entre ellas— detectan de forma fiable en torno a un tercio de los problemas reales de accesibilidad. Son excelentes en lo medible: contraste de color insuficiente, una imagen sin atributo alt, un campo de formulario sin etiqueta, una jerarquía de encabezados rota.
Lo que no pueden juzgar es el sentido. Una imagen puede tener un alt que diga «imagen1.jpg» y la máquina lo dará por correcto porque el atributo existe. Un enlace que dice «haz clic aquí» pasa cualquier validador y es inútil para alguien que navega saltando de enlace en enlace.
Conclusión práctica: usa las herramientas para el barrido inicial y reserva media hora para probar a mano. Las dos partes juntas cubren la gran mayoría; ninguna de las dos sola basta.
Paso 1: barrido automático
Empieza con dos extensiones de navegador gratuitas: WAVE y axe DevTools. Las dos analizan la página abierta y señalan los problemas sobre el propio diseño.
Pásalas por cuatro páginas representativas: la portada, una entrada del blog, una página con formulario y —si vendes— una ficha de producto. No hace falta más para el diagnóstico inicial: los problemas de un WordPress son casi siempre del tema y de las plantillas, así que se repiten.
Apunta lo que salga. Verás que se agrupa en muy pocas categorías.
Paso 2: contraste de color
Es el problema número uno, con diferencia, y el más fácil de arreglar.
La norma pide una relación de contraste de al menos 4,5:1 entre texto y fondo para texto normal, y 3:1 para texto grande. En la práctica, los sospechosos habituales son siempre los mismos: el texto gris claro sobre blanco que queda tan elegante, los botones de color de marca con texto blanco encima, el texto sobre una imagen de cabecera y los enlaces del pie de página.
Aquí la IA ayuda de una forma muy concreta: dale tu paleta de marca y pídele combinaciones válidas.
«Mi paleta de marca es: [lista de colores en hexadecimal]. Calcula la relación de contraste de cada combinación de texto sobre fondo y dime cuáles cumplen WCAG AA (4,5:1 para texto normal). Para las que no cumplan, propón el ajuste mínimo del color de texto que sí cumpla manteniendo el tono lo más parecido posible al original.»
Ese «ajuste mínimo manteniendo el tono» es la clave para que el diseñador no se eche las manos a la cabeza: no se trata de cambiar la marca, sino de oscurecer un gris lo justo.
Paso 3: textos alternativos que sirvan
El alt de una imagen es lo que oye alguien que usa un lector de pantalla. También es lo que Google usa para entender la imagen, así que esto es accesibilidad y SEO a la vez.
Tres reglas que resuelven el noventa por ciento de los casos:
- Describe la función, no la imagen. Si la foto ilustra un paso de un tutorial, el
altdebe decir qué se ve en ese paso, no «captura de pantalla». - Si la imagen es decorativa, deja el
altvacío. Vacío de verdad (alt=""), no ausente. Así el lector de pantalla la salta en lugar de leer el nombre del fichero. - Si la imagen es un enlace o un botón, el
altdescribe el destino, no el dibujo. Un icono de carrito que lleva al carrito es «Ver carrito», no «icono de carrito».
Para revisar el estado actual, en Medios > Biblioteca puedes ir viendo el campo de texto alternativo. Si tienes cientos de imágenes, prioriza: las de las páginas con más visitas y las que son enlaces.
La IA puede proponer textos alternativos a partir de las imágenes, y lo hace razonablemente bien. Pero revísalos: describe lo que ve, sin saber para qué está puesta la imagen en tu página, y esa diferencia es justo la que importa.
Paso 4: navegación por teclado
Esta prueba no la hace ninguna herramienta por ti y es la que más problemas destapa. Cuesta cinco minutos.
Abre tu web, deja el ratón quieto y recórrela solo con el tabulador:
- ¿Ves siempre dónde estás? Debe haber un indicador visible en el elemento enfocado. Muchos temas lo eliminan por estética con un
outline: none, y eso deja a ciegas a quien navega así. - ¿El orden tiene sentido? Debe seguir el orden visual. Si salta del menú al pie y vuelve al medio, hay un problema de estructura.
- ¿Puedes abrir el menú desplegable? Los menús que solo responden al pasar el ratón son inaccesibles por teclado.
- ¿Puedes cerrar las ventanas emergentes? Prueba con Escape. Un aviso de cookies o una ventana de suscripción que no se puede cerrar con teclado bloquea la web entera.
- ¿Te quedas atrapado en algún sitio? Un reproductor incrustado o un mapa que captura el foco y no lo suelta es una trampa.
El punto 4 merece atención especial porque afecta a casi todas las webs: entre el aviso de cookies, alguna ventana de captación de correo y algún chat, hay bastantes candidatos a bloquear la navegación por teclado.
Paso 5: formularios
Los formularios concentran mucho problema porque son la parte más interactiva.
Comprueba que cada campo tiene una etiqueta asociada de verdad —no solo un texto de ejemplo dentro del campo, que desaparece al escribir—, que los mensajes de error explican qué corregir en lugar de decir «error», que el error se anuncia también con texto y no solo pintando el borde de rojo, y que los campos obligatorios se indican con algo más que un asterisco de color.
Si usas un plugin de formularios, buena parte de esto viene resuelto de serie. Si el formulario es del tema o está hecho a mano, revísalo entero. Nuestra guía sobre formularios de contacto en WordPress repasa las opciones más habituales.
Paso 6: estructura de encabezados
Mucha gente usa los encabezados por su tamaño de letra: «este texto lo quiero grande, le pongo H2». Para quien navega con lector de pantalla, los encabezados son el índice del documento y saltar de uno a otro es la forma principal de moverse.
Las reglas: un solo H1 por página, que es el título; no saltarse niveles (de H2 a H4 directamente, no); y que el texto del encabezado describa la sección.
Para revisarlo rápido, la extensión WAVE tiene una vista de esquema que te muestra la jerarquía de un vistazo. También puedes pegar el HTML de la página a una IA y pedirle el árbol de encabezados con los saltos de nivel marcados.
Sobre las «capas de accesibilidad» automáticas
Merece un aviso, porque se anuncian mucho.
Son plugins o scripts que prometen hacer tu web accesible y cumplir la normativa añadiendo una línea de código y un botón flotante con opciones de contraste y tamaño de letra.
Conviene saber que estas soluciones han recibido críticas serias por parte de asociaciones de usuarios con discapacidad y de especialistas en accesibilidad, y que han sido objeto de demandas en varios países precisamente por no resolver lo que prometen. En muchos casos añaden una capa que interfiere con los lectores de pantalla que la persona ya tiene configurados.
No hay atajo: la accesibilidad se arregla en el HTML y en el CSS de la web, no con una capa por encima. Si vas a invertir dinero, inviértelo en corregir el tema, no en tapar el problema.
Preguntas frecuentes
¿Estoy obligado legalmente?
En España, el sector público lleva años obligado. Para empresas privadas, la Ley 11/2023 traspone la Directiva Europea de Accesibilidad y extiende obligaciones a determinados servicios digitales —comercio electrónico, banca, transporte, entre otros— con aplicación desde junio de 2025, con excepciones para microempresas. Si tu web vende o presta un servicio de los cubiertos, conviene que lo consultes con un asesor, porque el alcance concreto depende de tu actividad y tamaño.
¿Cuánto se tarda en dejarlo decente?
Una auditoría como esta, una tarde. Corregir lo detectado, entre unas horas y unos días según lo tocado que esté el tema. El grueso suele ser contraste y textos alternativos, que son mucho trabajo mecánico pero ninguna dificultad técnica.
¿Mejora el SEO?
No directamente, pero muchas de las correcciones coinciden con buenas prácticas que sí cuentan: textos alternativos descriptivos, jerarquía de encabezados coherente, enlaces con texto significativo y HTML semántico. Es de esos casos en los que arreglar una cosa mejora la otra de rebote.
¿Puedo pedirle a la IA que corrija el código directamente?
Para cambios acotados —añadir un aria-label, corregir una jerarquía de encabezados, ajustar un color— funciona bien. Para reescribir la plantilla de un tema, no: no tiene el contexto de tu web y romperá algo. Y si tocas ficheros del tema, hazlo siempre en un tema hijo y con copia de seguridad.
Para terminar
La accesibilidad se ha vendido durante años como un proyecto grande y caro, y para una web compleja puede serlo. Para un WordPress normal, no: es contraste, textos alternativos, teclado, formularios y encabezados. Cinco categorías, una tarde de revisión y un rato de correcciones.
La IA es un buen copiloto para las partes calculables y para generar los borradores, y no sirve para la prueba que más destapa, que es recorrer tu propia web con el tabulador. Esa hazla tú: son cinco minutos y es la más reveladora de todas.
Si te van este tipo de revisiones prácticas, en nuestra biblioteca de herramientas gratuitas tienes utilidades que funcionan enteras en tu navegador, sin subir nada a ningún servidor.
