♿ Accesibilidad de sitios web WordPress: una guía completa 2026

Cuando un usuario no puede leer su texto, hacer clic en un botón o simplemente entender a dónde lleva un enlace, se va. No porque el contenido sea malo. Porque el sitio no le habla.

A partir de junio de 2025, la Ley Europea de Accesibilidad (EAA) se volvió obligatoria. En Alemania, su ley nacional de refuerzo de la accesibilidad (BFSG). Multas, órdenes de cumplimiento, pérdida de audiencia. Pero detrás de la presión legal hay una verdad simple: según la OMS, alrededor del 16% de las personas en el mundo, una de cada seis, vive con algún tipo de discapacidad. Ignorarlas significa perder a cada sexto visitante.

WordPress no es aquí ni una excepción ni una sentencia de muerte. El CMS proporciona una base sólida, pero la accesibilidad real es el resultado de acciones deliberadas del desarrollador o del propietario del sitio. Esta guía es un desglose paso a paso: desde la estructura de encabezados hasta la navegación por teclado, desde la selección del tema hasta las comprobaciones automatizadas. Sin relleno, solo lo que puede aplicar hoy. 💡 Resumen rápido:

• Verifique la perceptibilidad: texto alternativo significativo para cada imagen, aria-label para iconos, texto de anclaje claro para cada enlace.
• Logre una relación de contraste de 4.5:1 para texto normal y 3:1 para texto grande usando el Comprobador de Contraste de WebAIM.
• Construya una jerarquía de encabezados: un H1 por página, luego H2 y H3 sin saltarse niveles.
• Asegure la accesibilidad por teclado: todo lo que se pueda hacer clic con un ratón debe funcionar con Tab e Intro.
• Revise los formularios: una etiqueta explícita para cada campo de entrada; un marcador de posición no sustituye a una descripción.
• Ejecute WAVE o Lighthouse: una auditoría automatizada encontrará la mayoría de los problemas en medio minuto.

Qué es la accesibilidad web y por qué es obligatoria en 2026

La accesibilidad web es la práctica de diseñar y desarrollar sitios web que puedan ser utilizados por personas con cualquier capacidad física y cognitiva. Lectores de pantalla para usuarios ciegos, navegación por teclado para personas con discapacidades motrices, contraste suficiente para usuarios con baja visión, subtítulos para usuarios sordos.

El estándar de facto es WCAG 2.2 (Pautas de Accesibilidad para el Contenido Web) del consorcio W3C. Tres niveles: A (mínimo), AA (el objetivo para la mayoría) y AAA (el más alto). La legislación de la UE y EE. UU. exige el nivel AA.

La Ley Europea de Accesibilidad (Directiva UE 2019/882) entró en vigor el 28 de junio de 2025 y cubre el comercio electrónico, la banca, el transporte y los medios de comunicación. En Alemania, la BFSG se aplica en paralelo. Las multas varían: hasta 100.000 € en Alemania, hasta 250.000 € en Francia. Los sitios WordPress de empresas comerciales están directamente sujetos a la normativa.

Perceptibilidad: cómo hacer el contenido comprensible para los lectores de pantalla

El punto de partida para la accesibilidad: la información debe presentarse de modo que el usuario pueda percibirla a través de al menos un canal: vista, oído, tacto.

Imágenes y texto alternativo. Cada etiqueta img debe tener un atributo alt. Para imágenes significativas, una descripción de lo que sucede en ellas (5-8 palabras, sin «imagen» o «foto»). Para imágenes decorativas, alt="" (vacío, pero presente). El lector de pantalla omite un alt vacío y no distrae al usuario.

1
/* functions.php — forced alt for post thumbnails */
2
add_filter('wp_get_attachment_image_attributes', function($attr, $attachment) {
3
    if (empty($attr['alt'])) {
4
        $attr['alt'] = get_the_title($attachment->ID);
5
    }
6
    return $attr;
7
}, 10, 2);

Enlaces y botones vacíos. Un icono de lupa sin texto es un misterio para un lector de pantalla. Añada siempre aria-label a los botones con icono:

1
<button aria-label="Open search">
2
    <span class="dashicons dashicons-search"></span>
3
</button>

Atributos title. Útiles para contexto adicional, pero no duplique en ellos el texto del enlace; el lector de pantalla leerá lo mismo dos veces. WordPress duplica el texto del enlace en el title por defecto; esto debe desactivarse.

Contraste de color: cifras básicas y herramientas de comprobación

Un contraste insuficiente entre el texto y el fondo es el problema más extendido. Según el WebAIM Million 2025, se encontró bajo contraste en el 81% de los sitios analizados.

Requisitos mínimos WCAG 2.2 AA:

• Texto normal (menos de 18pt): contraste 4.5:1
• Texto grande (18pt y superior o 14pt en negrita): contraste 3:1
• Iconos y elementos de interfaz: contraste 3:1

Compruébelo en un minuto usando el Comprobador de Contraste de WebAIM: introduzca los colores del texto y del fondo en HEX y obtenga un veredicto: Aprueba / No aprueba para cada nivel.

Áreas problemáticas típicas en WordPress: texto gris sobre fondo blanco en el pie de página, botones claros con etiquetas blancas, texto sobre fotos sin una capa de oscurecimiento. Se soluciona editando el CSS, generalmente oscureciendo el texto un par de tonos.

Estructura de encabezados: una jerarquía que todos entienden

Los lectores de pantalla construyen una «tabla de contenidos» de la página a partir de los encabezados; el usuario salta entre H2 y H3, evitando la navegación. Si la jerarquía está rota, la navegación se rompe.

Reglas:

• Un H1 por página, típicamente el título de la entrada
• H2 para secciones principales, H3 para subsecciones dentro de un H2
• Los encabezados no se saltan: H2 → H4 (saltarse el H3) es un error
• No use etiquetas h* solo por el tamaño de fuente; use CSS para eso

Un problema típico en WordPress: plugins y temas que insertan H2/H3 para sus propios bloques (sliders con un encabezado, un formulario de suscripción, widgets de la barra lateral). Tres soluciones: busque la configuración de la etiqueta en el plugin, personalice la salida mediante un filtro o cambie a un plugin más cuidadoso. Tolerar una jerarquía rota «porque se ve bien» no es una opción.

Navegación y puntos de referencia: señales para el lector de pantalla

Los puntos de referencia de HTML5 le dan al lector de pantalla un mapa de la página. Cuatro etiquetas clave: header para la cabecera, nav para la navegación, main para el contenido principal y footer para el pie de página. El usuario presiona una tecla de acceso rápido y salta directamente al contenido principal.

1
<header role="banner">
2
<nav role="navigation">
3
<main role="main">
4
<footer role="contentinfo">

El rol role="main" debe aparecer exactamente una vez por página. La mayoría de los temas modernos de WordPress usan estas etiquetas de fábrica; compruébelo con WAVE: la sección «Structure» mostrará todos los puntos de referencia.

Otro elemento obligatorio, «Saltar al contenido», es un enlace invisible situado como primer elemento de la página que permite a los usuarios saltarse el menú e ir directamente al contenido. En WordPress se añade mediante un filtro o un plugin de accesibilidad.

Formularios sin barreras

Formulario de contacto, suscripción al boletín, proceso de compra: cada campo debe estar etiquetado y ser accesible mediante teclado.

*Cada input necesita su propio label (explícito o mediante aria-label):*

1
<label for="user-email">Email</label>
2
<input id="user-email" name="email" type="email">

Un marcador de posición no sustituye a una etiqueta; desaparece al escribir y los lectores de pantalla lo interpretan deficientemente. Use placeholder solo como pista de formato, no como el nombre del campo.

Agrupación: envuelva los botones de opción y las casillas de verificación en un <fieldset> con una <legend>. Campos obligatorios: márquelos con el texto «(obligatorio)», no solo con un asterisco o un color.

Navegación por teclado: su página sin ratón

Algunos usuarios nunca usan ratón: temblor, espasticidad, parálisis. Todo debe funcionar mediante Tab, Shift+Tab, Enter, Escape y las teclas de flecha.

Prueba rápida: abra la página y navegue por ella usando solo la tecla Tab. Cada elemento interactivo debe recibir un indicador de foco visible. Un modal debe cerrarse con Escape. Un menú desplegable debe expandirse con Enter.

Fallos típicos en sitios WordPress:

• Desplegables personalizados sin tabindex ni aria-expanded
• outline: none en CSS (elimina el indicador de foco; no haga esto)
• Trampa de foco infinita en ventanas emergentes
• Controles deslizantes que no son operables con teclado

Nunca desactive por completo el estilo :focus predeterminado. Si no le gusta el contorno del navegador, sustitúyalo por un estilo :focus-visible personalizado con un anillo de alto contraste.

Zoom: no impida a los usuarios ampliar el texto

Muchas versiones móviles de sitios WordPress bloquean el zoom de pellizco mediante una etiqueta meta:

1
<!-- INCORRECT — do not do this -->
2
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
3
 
4
<!-- CORRECT -->
5
<meta name="viewport" content="width=device-width, initial-scale=1">

Las WCAG 2.2 exigen la capacidad de ampliar al 200% sin pérdida de contenido ni funcionalidad; este es el Criterio de Conformidad 1.4.4. Compruebe que el texto no se recorta ni se solapa con otros bloques al aplicar el zoom.

Temas de WordPress y accesibilidad: qué buscar al elegir

Ningún tema es «completamente accesible tal cual se instala»; demasiado depende del contenido y de la configuración. Pero la base de partida sí importa.

Al elegir un tema, preste atención a:

• Que la descripción diga «accessibility ready»; es una etiqueta en WordPress.org que indica un cumplimiento básico de los requisitos
• Estructura HTML5 correcta con landmarks
• Menús de navegación con <nav> nativo y <ul>, no una construcción con divs y JS
• Presencia de estilos :focus para enlaces y botones
• Ausencia de maximum-scale=1.0 en el viewport

Los temas estándar de WordPress (Twenty Twenty-Four, Twenty Twenty-Five) son un punto de partida aceptable. Los temas comerciales con constructores visuales son una zona de riesgo: cuanta más «magia» visual, mayor es la probabilidad de que la accesibilidad falle.

Herramientas de auditoría: de una comprobación rápida a pruebas profesionales

WAVE Evaluation Tool. Una extensión de navegador, WAVE de WebAIM, que superpone iconos directamente sobre la página: rojo para errores, amarillo para advertencias, verde para aciertos. Ideal para una primera auditoría. Muestra contraste, textos alternativos, estructura de encabezados y atributos ARIA.

Google Lighthouse. Integrado en Chrome DevTools (F12 → Lighthouse → Accessibility). Ofrece una puntuación numérica de 0 a 100 y una lista de elementos concretos que corregir. Cómodo para el monitoreo periódico.

Accessibility Checker (Equalize Digital). Un plugin de WordPress, Accessibility Checker, que revisa el contenido directamente en el editor (Gutenberg y el clásico). La versión gratuita analiza una entrada antes de publicarla; la versión Pro añade una auditoría completa del sitio.

WP Accessibility. Un veterano entre los plugins de accesibilidad, WP Accessibility de Joe Dolson. Añade enlaces de salto, landmarks ARIA, elimina atributos title duplicados en enlaces, corrige los estilos :focus, elimina tabindex de los formularios y target de los enlaces. No es una solución mágica, pero resuelve una docena de problemas típicos de una sola vez.

One Click Accessibility. Un plugin con una barra de herramientas, One Click Accessibility, que permite al usuario cambiar el contraste, aumentar el tamaño de la fuente y subrayar los enlaces por su cuenta. No sustituye a la accesibilidad nativa, sino que es una capa adicional para quienes necesitan ajustes específicos.

NVDA. Un lector de pantalla gratuito para Windows, NVDA. Recorra su sitio con el monitor apagado. Escuchará lo que oye un usuario ciego. VoiceOver (integrado en macOS/iOS) es el equivalente para el ecosistema Apple.

Diez pasos hacia un sitio WordPress accesible

Aquí tiene la conclusión destilada de toda la guía, a modo de lista de verificación. Repásela después de cualquier rediseño o lanzamiento de un proyecto nuevo.

• Redacte un texto alternativo para cada imagen. En la biblioteca de medios de WordPress, rellene el campo «Texto alternativo». Para imágenes decorativas, use alt="".

• Describa los enlaces. El texto del enlace debe comunicar hacia dónde conduce. «Haga clic aquí» y «Leer más» son malos anclajes. «Descargar el plugin Accessibility Checker» es uno bueno.

• Disponga los encabezados en orden. Un H1, luego H2, y H3 dentro de H2. Compruébelo en WAVE: Structure → Heading Outline.

• Lleve el contraste a 4.5:1. Pase el Contrast Checker de WebAIM por los colores principales del tema: texto, encabezados, botones, enlaces, pie de página.

• Active un foco visible. Asegúrese de que :focus no esté configurado como outline: none sin un reemplazo. El foco personalizado se hace mediante :focus-visible.

• Compruebe la navegación por teclado. Tabule por todos los enlaces y botones, Enter para activar, Escape para cerrar modales. Si se queda atascado, eso es un error.

• Etiquete los formularios. Cada campo necesita su propio <label>. Los campos obligatorios necesitan un indicador textual. Los grupos van dentro de un <fieldset>.

• No bloquee el zoom. Viewport sin maximum-scale ni user-scalable=no. Compruebe con un zoom del 200%; el contenido no debe quedar cortado.

• Añada un enlace de salto. Un enlace «Saltar al contenido» como primer elemento del <body>. WP Accessibility lo hace automáticamente.

• Ejecute WAVE o Lighthouse. Una auditoría automatizada no sustituye a las pruebas manuales, pero encontrará la gran mayoría de los problemas en un minuto.

⁉️🤔 Preguntas frecuentes

¿Mi sitio WordPress tiene que cumplir con las WCAG?

Si su sitio representa un negocio en la UE, sí, a partir de junio de 2025. La Ley Europea de Accesibilidad cubre comercio electrónico, finanzas, transporte y medios de comunicación. En EE. UU. aplican requisitos similares: la ADA y la Sección 508 para agencias gubernamentales y sus contratistas. Un blog personal no está obligado formalmente a cumplir, pero una parte significativa de los usuarios tiene discapacidades, un sólido argumento comercial.

Sí, los sitios comerciales en la UE deben cumplir con las WCAG 2.2 AA a partir del 28 de junio de 2025 según la Ley Europea de Accesibilidad. Las multas las fijan los estados miembros: los importes pueden alcanzar cientos de miles de euros según la jurisdicción. En EE. UU. aplican requisitos similares a través de la ADA y la Sección 508. Para blogs personales no comerciales no hay obligación legal, pero la accesibilidad amplía la audiencia.

¿Basta con instalar un plugin como One Click Accessibility?

Un plugin de barra de herramientas es una capa de asistencia, no una solución. Permite al usuario cambiar el contraste o el tamaño de letra, pero no arregla la falta de texto alternativo, una jerarquía de encabezados rota o ventanas emergentes inaccesibles por teclado. Empiece por la accesibilidad nativa en código y contenido, y añada la barra de herramientas como toque final.

No. Una barra de herramientas (One Click Accessibility, UserWay) es solo una «superposición» adicional. No sustituye la accesibilidad nativa: no arregla el texto alternativo, la jerarquía de encabezados, las trampas de teclado ni los campos de formulario sin etiqueta. Empiece por corregir el código y el contenido, la barra de herramientas es el último toque.

¿Cómo pruebo un sitio sin comprar herramientas costosas?

Un ciclo completo con herramientas gratuitas: extensión WAVE (primer escaneo rápido) → Google Lighthouse (puntuación numérica + lista de problemas) → recorrido manual con teclado (Tab/Intro/Escape) → NVDA en Windows o VoiceOver en Mac (navegar por el sitio con el monitor apagado). Esto basta para abordar la gran mayoría de los problemas.

Ciclo gratuito: extensión WAVE para el navegador → Google Lighthouse en Chrome DevTools → recorrido manual con teclado → NVDA (Windows) o VoiceOver (macOS/iOS) para pruebas con lector de pantalla. Estas cuatro herramientas cubren el 90% de las tareas. Los servicios de pago solo se necesitan para auditorías periódicas de proyectos grandes.

¿Se puede hacer accesible un sitio construido con un maquetador visual (Elementor, WPBakery)?

Se puede, pero es más difícil. Los maquetadores generan HTML dinámicamente, y algunos widgets rompen la jerarquía de encabezados o insertan envoltorios div sin semántica. Revise cada bloque individualmente con WAVE. Elementor Pro versión 3.15+ añadió ajustes de atributos aria para widgets, utilícelos.

Se puede, pero requerirá más trabajo manual. Los maquetadores visuales tienden a romper la jerarquía de encabezados y a generar envoltorios div excesivos. Compruebe el resultado con WAVE después de cada cambio. Elementor Pro (3.15+) permite establecer atributos ARIA para widgets, lo que resuelve parcialmente el problema.

¿Con qué frecuencia debo revisar la accesibilidad de un sitio?

Después de cada actualización significativa: un tema nuevo, un plugin nuevo, un rediseño, una publicación importante de contenido. Ciclo mínimo: ejecute Lighthouse y recorra las páginas clave con el teclado una vez al trimestre. La monitorización automatizada mediante Accessibility Checker Pro se justifica para sitios con contenido regular.

Como mínimo, después de cada cambio importante (cambio de tema, plugin nuevo, rediseño) y trimestralmente como medida preventiva. Para sitios con publicaciones periódicas, se justifica la monitorización automatizada mediante Accessibility Checker Pro. Una prueba con lector de pantalla es suficiente una vez cada seis meses si la base de código no ha cambiado.

Qué hacer ahora mismo con la accesibilidad de un sitio WordPress

No espere el momento perfecto. WCAG 2.2 AAA es una meta, no un punto de partida. Empiece hoy con tres acciones:

• Ejecute WAVE en su página de inicio. Corrija los errores en rojo (suelen ser entre 5 y 10), son los que cierran las barreras más graves.
• Navegue el sitio con el teclado. Tab, Tab, Tab. Si se atasca, corríjalo. Si el foco no es visible, añada :focus-visible.
• Revise el contraste de tres colores: color de texto, color de botón, color de enlace. Llévelos hasta 4.5:1.

Estos tres pasos, media hora de trabajo, y la mayor parte del resultado. El resto, plugins, lectores de pantalla, ARIA, abórdelos gradualmente.

Si el sitio es comercial y opera en la UE, no lo postergue. La EAA otorga a las autoridades de supervisión un poder real a partir de 2025. Es mejor enfrentar una auditoría con un puntaje verde en Lighthouse que con una carta de un regulador.