Accesibilidad (WCAG 2.2) en 2026: Es legal tu sitio WordPress?

En junio de 2025, el panorama digital cambio para siempre. La Ley Europea de Accesibilidad (EAA) entro en plena aplicación, convirtiendo la accesibilidad web en un requisito legal para casí todas las empresas digitales que operan en la UE.

Ya no es algo “bueno de tener”. Es similar al RGPD. El incumplimiento arriesga multas significativas y demandas judiciales.

Para los desarrolladores WordPress y propietarios de sitios, el estándar es WCAG 2.2 Nivel AA. Esta guía de más de 2500 palabras desglosa exactamente que cambio en 2026 y como asegurar que tu tema no este infringiendo la ley.

#1. La EAA: Por que 2025 fue el punto de inflexion

Anteriormente, las leyes de accesibilidad se aplicaban principalmente al sector público (gobierno y universidades). La EAA expandio esto al comercio electronico, banca, transporte y libros electronicos.

• Alcance: Si vendes una camiseta a un clientes en Francia, tu flujo de checkout debe ser accesible. Si ofreces servicios de consultoria a empresas en Alemania, tu sitio web debe cumplir. No importa donde este ubicado tu servidor - lo que importa es donde estan tus clientes.
• La penalizacion: Las multas varian por pais, pero pueden ser severas, sumadas al daño reputacional de excluir al 15% de la poblacion global. En España, las multas pueden alcanzar los 100.000 euros para infracciones graves.

#Que empresas estan obligadas a cumplir?

La EAA se aplica a practicamente cualquier empresa que ofrezca productos o servicios digitales a consumidores europeos. Esto incluye:

• Tiendas online (WooCommerce, Shopify, cualquier e-commerce)
• Servicios bancarios y financieros en linea
• Plataformás de reserva de transporte y alojamiento
• Editoriales digitales y plataformas de e-learning
• Servicios de telecomunicaciones y streaming

Las únicas excepciones son las microempresas con menos de 10 empleados y menos de 2 millones de euros de facturacion anual. Pero incluso estas empresas son animadas a cumplir voluntariamente.

#2. WCAG 2.2: Los nuevos criterios explicados

WCAG 2.2 construyo sobre 2.1, añadiendo 9 nuevos criterios. Los más críticos para temas WordPress son:

#2.4.11 Foco No Oscurecido (Minimo) (AA)

• El problema: Navegas con Tab por una página. Un elemento recibe el foco, pero tu “cabecera fija” o “banner de cookies” lo cubre. El usuario sabe que esta en algun lugar, pero no puede ver donde.
• La solución: Usa CSS scroll-padding-top en el elemento html para asegurar que los elementos enfocados se desplacen al area visible debajo de tu cabecera fija.

html {
  scroll-padding-top: 80px; /* Altura de tu cabecera fija */
}

Este ajuste aparentemente simple tiene un impacto enorme en la usabilidad para personas que dependen del teclado para navegar. En WordPress, asegurate de que tu tema aplique esta propiedad y la ajuste dinamicamente si la altura de la cabecera cambia (por ejemplo, cuando aparece una barra de notificación).

#2.5.8 Tamaño de Objetivo (Minimo) (AA)

• La regla: Los objetivos interactivos (botones) deben tener al menos 24x24 pixeles CSS.
• La realidad: Esos pequeños botones “X” de cierre en tus popups? Son ilegales. Hazlos más grandes. Los toques con el dedo son imprecisos, y las personas con discapacidades motoras necesitan areas de toque generosas.

En la práctica, esto significa revisar cada elemento interactivo de tu sitio WordPress: botones de formulario, enlaces de navegación, checkboxes, selectores de fecha, controles de carrusel y botones de cierre de modales. Todos deben tener un tamaño minimo de 24x24px con separacion adecuada entre elementos adyacentes.

#3.2.6 Ayuda Consistente (A)

• La regla: Si ofreces mecanismos de ayuda (como un enlace de contacto o un chatbot), deben aparecer en la misma ubicacion relativa en todas las páginas.
• El impacto WordPress: Los widgets de pie de página con información de contacto deben mantenerse consistentes en todo el sitio. No muevas el enlace de “Soporte” del footer a la barra lateral en diferentes secciones.

#3.3.7 Entrada Redundante (A)

• La regla: No obligues al usuario a ingresar la misma información dos veces en el mismo proceso.
• El impacto WordPress: En WooCommerce, si la dirección de envio es la misma que la de facturacion, no obligues al usuario a escribirla dos veces. Usa un checkbox “Misma que la dirección de facturacion” o auto-rellena los campos.

#3.3.8 Autenticación Accesible (AA)

• La regla: No fuerces a los usuarios a resolver puzzles (CAPTCHAs) o memorizar contrasenas sin ayuda.
• El impacto WordPress: Soporta gestores de contrasenas (no bloquees el pegado en campos de contrasena) y usa “Magic Links” o WebAuthn (Biometria) cuando sea posible. Los CAPTCHAs visuales son una barrera crítica para usuarios ciegos - usa alternativas como reCAPTCHA v3 que funciona sin interacción visible del usuario.

#3. HTML semántico: La base de todo

El 90% de los problemas de accesibilidad se resuelven escribiendo HTML correcto. No se necesitan plugins magicos ni overlays - solo marcado semántico apropiado.

#Landmarks

Usa <main>, <nav>, <aside>, <footer>. Los usuarios de lectores de pantalla saltan entre estas regiones para navegar eficientemente. No ahogues todo en una sopa de <div>. Un sitio WordPress bien estructurado deberia tener exactamente un <main>, una <nav> primaria, y landmarks claramente definidos.

#Jerarquía de encabezados

h1 a h6 es una jerarquía, no una eleccion de estilo. No saltes de h2 a h4 solo porque quieres una fuente más pequeña. Usa CSS para el dimensionamiento. En WordPress, esto es especialmente problematico cuando los editores de contenido usan encabezados para dar estilo visual al texto en lugar de estructurar la información logicamente.

Conoce más sobre servicios de SEO y GEO en WPPoland.

#Botones vs. Enlaces

• Va a una nueva URL? Usa <a>.
• Cambia algo en la página actual (abre un menú)? Usa <button>.
• Nunca uses <div onClick="...">. Es invisible para los teclados y los lectores de pantalla no lo anuncian como elemento interactivo.

Esta distincion puede parecer trivial para desarrolladores visuales, pero es fundamental para la accesibilidad. Un lector de pantalla anuncia links y botones de forma diferente, y los usuarios confian en estas distinciones para entender la estructura de la página.

#4. La trampa del “Overlay”

Los has visto. El pequeño icono de “persona en circulo” en la esquina que abre un menú para cambiar contraste o tamaño de fuente.

Evitalos.

• Falsa seguridad: Afirman hacerte cumplir instantaneamente con una linea de JavaScript. No lo hacen. No pueden corregir errores de HTML semántico.
• Friccion del usuario: Los usuarios ciegos ya tienen lectores de pantalla. No necesitan tu overlay interfiriendo con sus herramientas configuradas y personalizadas durante años.
• Riesgo legal: En EE.UU., empresas que usan overlays han sido demandadas con más frecuencia porque demuestra que sabian que tenian un problema pero eligieron una solución de “curita” en lugar de corregir el código subyacente.
• Conflictos técnicos: Los overlays frecuentemente entran en conflicto con tecnologías de asistencia existentes, creando una experiencia peor, no mejor, para los usuarios que más necesitan accesibilidad.

La única solución real es escribir código accesible desde el principio o remediar el código existente para cumplir con los estándares. No hay atajos.

#5. Pruebas: Automatizadas vs. manuales

No puedes automatizar la accesibilidad al 100%. Las herramientas automatizadas son un punto de partida, pero nunca un sustituto de las pruebas humanas.

#El flujo de trabajo de pruebas

1. Automatizado (30%): Usa axe-core o la auditoria de “Accesibilidad” de Lighthouse. Esto detecta texto alternativo faltante, bajo contraste, etiquetas ARIA invalidas y roles duplicados. Es rápido y debe ejecutarse en cada despliegue como parte de tu pipeline de CI/CD.

2. Teclado manual (50%): Desconecta tu raton. Puedes navegar todo el menú, abrir los submenus y llenar el formulario de contacto usando solo las teclas Tab, Enter y Espacio? Si no, no apruebas. Presta atención especial a:

   • Los indicadores de foco son visibles?
   • El orden de tabulacion es lógico?
   • Los modales y dropdowns atrapan el foco correctamente?
   • Puedes cerrar modales con la tecla Escape?

3. Lector de pantalla (20%): Activa VoiceOver (Mac) o NVDA (Windows). Cierra los ojos. Puedes entender que esta pasando? Los formularios tienen etiquetas descriptivas? Las imágenes tienen textos alternativos significativos? Los cambios de estado se anuncian correctamente?

#Herramientas recomendadas para WordPress

• axe DevTools: Extension de navegador que analiza la página actual y ofrece correcciones específicas.
• Wave: Herramienta web de WebAIM que proporciona una visualización clara de los problemas de accesibilidad.
• Pa11y: Herramienta de linea de comandos ideal para integrar en pipelines de CI/CD.
• Accessibility Checker (Plugin WP): Audita el contenido directamente desde el editor de WordPress.

#6. Formularios accesibles en WordPress

Contact Form 7 y Gravity Forms son populares, pero frecuentemente estan mal configurados desde el punto de vista de accesibilidad.

#Etiquetas

Cada campo de entrada necesita un <label> asociado programaticamente. Los placeholders NO son etiquetas - desaparecen cuando escribes, dejando al usuario sin referencia de que información se solicita.

<!-- Correcto -->
<label for="email">Correo electronico</label>
<input type="email" id="email" name="email">

<!-- Incorrecto -->
<input type="email" placeholder="Correo electronico">

#Mensajes de error

“Error encontrado” es inutil. “La dirección de correo electronico no contiene el símbolo @” es accesible. Los mensajes de error deben ser específicos, estar asociados programaticamente al campo correspondiente usando aria-describedby, y aparecer cerca del campo con error.

#Gestión de foco

Cuando un usuario envia un formulario y hay un error, mueve programaticamente el foco del teclado al primer campo con error para que puedan corregirlo inmediatamente. No obligues al usuario a buscar donde esta el problema.

#Indicadores de campo obligatorio

No dependas solo del asterisco rojo (*) para indicar campos obligatorios. Usa el atributo required, proporciona texto explicativo (“Los campos marcados con * son obligatorios”) y asegurate de que los lectores de pantalla anuncien el estado requerido.

#7. Accesibilidad en WooCommerce

Las tiendas WooCommerce tienen desafios adicionales de accesibilidad que deben abordarse:

#Flujo de compra

Todo el proceso desde la seleccion del producto hasta la confirmacion del pago debe ser navegable por teclado. Esto incluye:

• Agregar productos al carrito
• Modificar cantidades
• Aplicar cupones
• Completar el checkout
• Recibir confirmacion

Conoce más sobre desarrollo WooCommerce en WPPoland.

#Tablas de productos

Las tablas de comparación de productos y las listas de variaciones deben usar <table> semántico con encabezados <th> apropiados y atributos scope para que los lectores de pantalla puedan interpretar la relación entre celdas.

#Notificaciones dinámicas

Cuando se agrega un producto al carrito o se aplica un descuento, usa aria-live="polite" para anunciar el cambio a los lectores de pantalla sin interrumpir la actividad actual del usuario.

#8. Accesibilidad en WordPress Headless

Los sitios WordPress Headless que usan React, Next.js o Astro como frontend enfrentan desafios únicos de accesibilidad:

#Gestión de foco en cambios de ruta

En una Single Page Application (SPA), los cambios de ruta no provocan una recarga de página. Esto significa que el foco del teclado y los anuncios del lector de pantalla no se actualizan automáticamente. Debes implementar:

• Mover el foco al contenido principal despues de cada cambio de ruta
• Anunciar el título de la nueva página usando una region aria-live
• Actualizar el document.title con el título de la nueva página

#Renderizado del lado del servidor para accesibilidad

El SSR (Server-Side Rendering) es crucial para la accesibilidad porque asegura que el contenido este disponible inmediatamente cuando la página carga, sin esperar a que JavaScript se ejecute. Los usuarios de lectores de pantalla que navegan rápidamente necesitan contenido en el HTML inicial.

#9. Conclusion: La accesibilidad como indicador de calidad

La accesibilidad a menudo se enmarca como una restriccion. En realidad, es un indicador de calidad. El código accesible es más limpio, más robusto y mejor para SEO. En 2026, construir una web inclusiva no es solo la ley - es la única forma profesional de trabajar.

Los beneficios van más alla del cumplimiento legal:

• Mejor SEO: Los motores de búsqueda interpretan las señales de accesibilidad como indicadores de calidad del sitio.
• Mayor audiencia: El 15% de la poblacion mundial tiene alguna discapacidad. Eso son mil millones de personas que podrias estar excluyendo.
• Mejor UX para todos: Las mejoras de accesibilidad (contraste claro, botones grandes, navegación lógica) benefician a todos los usuarios.
• Menor riesgo legal: El cumplimiento proactivo es infinitamente más barato que la remediacion despues de una demanda.

Necesitas una auditoria de accesibilidad? WPPoland ofrece servicios de remediacion WCAG 2.2 para empresas. Contactanos para una evaluación de tu sitio.