Auditoria práctica de accesibilidad: herramientas y flujo de trabajo

El plazo del 28 de junio de 2025 del European Accessibility Act ya pasó. Si construye o mantiene sitios WordPress para clientes que venden a consumidores en la UE (e-commerce, banca, transporte, ticketing, libros electronicos), esos clientes ya cargan con exposicion legal directa si su sitio no cumple WCAG 2.2 AA. La auditoria dejo de ser un “anadido amable de consultoria”; es el documento que el equipo legal del cliente pedira cuando llegue la primera reclamacion.

En Espana, el marco resulta familiar: el Real Decreto 1112/2018 transpone la Directiva (UE) 2016/2102 y obliga a publicar declaracion de accesibilidad en sitios del sector público, con el Observatorio de Accesibilidad Web (OAW) realizando auditorias periodicas y el Ministerio de Asuntos Economicos y Transformacion Digital coordinando la conformidad. La EAA extiende esta obligacion al sector privado, y el cruce con el RGPD aparece en cuanto el cliente tiene formularios o cuentas.

Conozca más sobre los servicios de desarrollo WordPress en WPPoland.

Esta guía describe el flujo de trabajo que aplicamos en proyectos WordPress reales: por que herramientas automatizadas empezar, donde dejan de ser utiles y como tratar las partes de WCAG 2.2 que solo una persona con teclado y NVDA puede verificar.

#Donde vive realmente la exposicion legal

Un encuadre util antes de abrir cualquier herramienta: la EAA no cubre solo “sector público”. Cubre servicios orientados al consumidor. Clientes privados que auditamos en los ultimos doce meses y estaban dentro del ambito: una libreria espanola de libros electronicos, un e-commerce aleman de mobiliario y una pequena plataforma de reservas en WooCommerce. Ninguno se dio cuenta hasta que su responsable de cumplimiento levanto el punto.

Uno de esos clientes (tienda WooCommerce vendiendo a Alemania y Francia) recibio reclamacion escrita dos meses despues del lanzamiento. El detonante fue un paso de checkout personalizado en el que el control “continuar al pago” se construyo como <div onclick="..."> en lugar de button. Los usuarios de teclado no podian alcanzarlo y NVDA no anunciaba nada al recibir foco. La correccion fue pequena (sustituir por <button type="button">, restaurar el manejo nativo de foco, anunciar la transicion con aria-live="polite"), pero el ida y vuelta legal absorbio aproximadamente una semana de tiempo de la agencia. Asi es la forma del riesgo: no una demanda dramatica, sino correspondencia lenta y costosa que se evita auditando antes del lanzamiento y en cada PR que toque el DOM.

WCAG 2.2 anade tres criterios que se asignan directamente a fallos comunes en WordPress y WooCommerce:

• 2.4.11 Foco no oscurecido (AA) y 2.4.13 Apariencia del foco (AAA) - cabeceras sticky, banners de cookies y widgets de chat tapan rutinariamente el elemento enfocado. Conviene revisarlo en cada plantilla.
• 2.5.7 Movimientos de arrastre (AA) - cualquier interaccion que solo se resuelva arrastrando (toggles tipo slider, ordenacion kanban en el admin, sliders de comparacion de imagenes) necesita alternativa de puntero unico, como botones mas/menos o entrada por teclado.
• 2.5.8 Tamano de objetivo minimo (AA) - los objetivos interactivos deben medir al menos 24×24 pixeles CSS. La mayoria de pies de tema, enlaces de paginacion y tiras de iconos sociales fallan esto en movil por defecto.

El nucleo de WordPress tiene accesibilidad decente para el editor de bloques y las primitivas de navegacion del front. Los fallos que encontramos en auditoria viven casi siempre en tres sitios: bloques ACF personalizados (que no heredan el cableado ARIA de Gutenberg), sobrescrituras de componentes del tema y page builders de terceros. Planifique la auditoria alrededor de eso, no del nucleo.

#Fase 1: Escaneo automatizado - lo que de verdad cazan

Sea honesto con el cliente sobre esta cifra: las herramientas automaticas de accesibilidad cubren mas o menos del 30 al 40 por ciento de los criterios de exito WCAG. Detectan bien atributos alt ausentes, etiquetas de formulario faltantes, contraste insuficiente en texto estatico, atributos de idioma ausentes, IDs duplicados y ARIA visiblemente roto. No le diran si el alt es significativo, si el orden de foco tiene sentido, si el lector de pantalla anuncia un cambio de estado, o si su carrusel personalizado funciona sin raton. El 60-70% restante exige una persona con teclado, lector de pantalla y paciencia.

Ejecute las comprobaciones automatizadas primero porque son baratas y limpian los fallos obvios antes de invertir tiempo en pruebas manuales. Empiece por axe DevTools (Deque) como extension de navegador durante el desarrollo: las etiquetas WCAG 2.2 entran directamente al informe y la separacion entre “necesita revision” y violaciones definitivas mantiene los falsos positivos cerca de cero. Escanee cada plantilla distinta (portada, archivo, single, producto, checkout, contacto, login, resultados de busqueda) y no cada URL: la mayoria de sitios WordPress espanoles tiene menos de diez plantillas diferentes aunque sirvan miles de paginas. WebAIM WAVE sirve como segunda opinion, sobre todo para visualizar la estructura de encabezados cuando un redactor escribio h4 “porque queda bien”. Pa11y en GitHub Actions o Bitbucket Pipelines atrapa regresiones en el PR donde son mas baratas de arreglar. Tenon API es excesivo para un solo sitio y vale la pena montarlo cuando se cruzan cinco o seis sitios cliente bajo la misma agencia.

#Axe DevTools

Axe es la herramienta de referencia de la industria para pruebas automatizadas de accesibilidad. Funciona como una extensión del navegador y se integra con frameworks de pruebas.

Como usarlo:

1. Instale la extensión Axe DevTools en Chrome o Firefox
2. Navegue a la página que desea auditar
3. Abra DevTools (F12) y seleccione la pestana “Axe”
4. Haga clic en “Scan all of my page”
5. Revise los resultados agrupados por severidad

Que detecta:

• Contraste de color insuficiente
• Imágenes sin texto alternativo
• Formularios sin etiquetas
• Problemás de estructura de encabezados
• Atributos ARIA incorrectos

#WAVE (Web Accessibility Evaluation Tool)

WAVE proporciona una capa visual sobre su página, mostrando problemas directamente en el contexto del diseño.

Ventaja clave: WAVE es excelente para comunicar problemas a disenadores y clientes no técnicos porque muestra visualmente donde estan los errores.

#Lighthouse

Integrado en Chrome DevTools, Lighthouse proporciona una puntuacion general de accesibilidad junto con metricas de rendimiento y SEO.

Mejor práctica: Ejecute Lighthouse en las 5-10 páginas más criticas de su sitio, incluyendo la página de inicio, páginas de producto/servicio y formularios de contacto.

#Fase 2: Solo teclado, en cada plantilla

Esta es la prueba manual mas reveladora y donde viven varios criterios WCAG 2.2 que decidiran cualquier reclamacion. Desconecte el raton. Tab por cada plantilla distinta, desde la cabecera hasta el pie, y luego Shift+Tab de regreso. Active cada elemento interactivo con Enter o Espacio.

#Teclas esenciales para pruebas

• Tab: Avanzar al siguiente elemento interactivo
• Shift+Tab: Retroceder al elemento anterior
• Enter: Activar enlaces y botones
• Espacio: Activar casillas de verificación y botones
• Flechas: Navegar dentro de componentes (menús, sliders)
• Escape: Cerrar dialogos y menús desplegables

#Que comprobar

1. Alcance: llega a cada elemento interactivo, incluidos los que aparecen al hacer hover (mega menus, tooltips, “ver mas”)?
2. Indicador de foco visible siempre: en fondos oscuros el outline por defecto del navegador suele desaparecer; el criterio 2.4.13 pide al menos 2 pixeles CSS de grosor con contraste 3:1 frente a colores adyacentes.
3. Foco no tapado: cabeceras sticky, banners de cookies y widgets de chat tapan el elemento enfocado. Es el criterio 2.4.11 y el fallo WCAG 2.2 mas habitual en sitios construidos antes de 2024.
4. Sin trampas de teclado y sin interacciones solo con drag (criterio 2.5.7): comparadores de imagenes, range estilizados como handle y reordenacion en backoffice necesitan alternativa de puntero unico.
5. Tamano de objetivo 24×24 CSS pixeles (criterio 2.5.8): paginacion, iconos sociales del pie e iconos “x” inline son los sospechosos habituales.

#Problemás comunes en WordPress

• Menús de navegación: Muchos temas no implementan correctamente la navegación por teclado en submenus desplegables.
• Modales y popups: Los lightboxes y popups de cookies frecuentemente no capturan ni gestionan el foco correctamente.
• Sliders y carruseles: Los controles de navegación a menudo son inaccesibles por teclado.
• Formularios de búsqueda: El formulario de búsqueda expandible puede no recibir el foco al activarse.

#Fase 3: Pruebas con lector de pantalla

Esta fase revela como experimentan su sitio los usuarios con discapacidad visual. Es la prueba más compleja pero también la más reveladora.

#Herramientas recomendadas

• NVDA (Windows, gratuito): El lector de pantalla de código abierto más popular
• VoiceOver (macOS/iOS, integrado): Viene preinstalado en todos los dispositivos Apple
• JAWS (Windows, comercial): El estándar empresarial

#Que verificar

1. Texto alternativo de imágenes: Las imágenes decorativas deben tener alt="" (vacio). Las imágenes informativas deben tener descripciones utiles y concisas.
2. Estructura de encabezados: Los encabezados deben seguir una jerarquía lógica (H1 -> H2 -> H3) sin saltarse niveles.
3. Etiquetas de formularios: Cada campo de formulario debe anunciarse con su propósito (nombre, correo electronico, etc.).
4. Tablas de datos: Las tablas deben tener encabezados de fila y columna correctamente marcados.
5. Contenido dinámico: Los cambios en la página (mensajes de error, actualizaciones AJAX) deben anunciarse mediante regiones ARIA live.

#Fase 4: Revision manual de código

Despues de las pruebas automatizadas y manuales, inspeccione el código fuente de los componentes críticos.

#Lista de verificación de código

• HTML semántico: Use elementos nativos (<nav>, <main>, <article>, <aside>) en lugar de <div> genericos.
• Atributos ARIA: Verifique que los roles ARIA sean correctos y no entren en conflicto con la semántica HTML nativa.
• Idioma del documento: El atributo lang en <html> debe ser correcto.
• Skip links: Debe existir un enlace “Saltar al contenido principal” como primer elemento interactivo.
• Manejo de errores: Los mensajes de error de formularios deben estar asociados programaticamente a los campos correspondientes.

<!-- Ejemplo de formulario accesible -->
<form>
  <div>
    <label for="email">Correo electronico</label>
    <input type="email" id="email" name="email"
           aria-describedby="email-error"
           aria-invalid="true">
    <span id="email-error" role="alert">
      Por favor ingrese una direccion de correo valida.
    </span>
  </div>
</form>

#Fase 5: Documentación y priorizacion

Una auditoria sin documentación adecuada no tiene valor. Cree un informe estructurado que fácilite la remediacion.

#Estructura del informe

Para cada problema identificado, documente:

1. Descripción: Que es el problema
2. Ubicacion: Página y componente afectados
3. Criterio WCAG: Cual criterio de WCAG 2.2 se viola
4. Severidad: Crítica, Alta, Media o Baja
5. Captura de pantalla: Evidencia visual del problema
6. Solución propuesta: Como corregir el problema
7. Esfuerzo estimado: Tiempo necesario para la correccion

#Priorizacion

• Crítica: Bloquea completamente el acceso a funcionalidad esencial (trampas de teclado, formularios inaccesibles). Corregir inmediatamente.
• Alta: Dificulta significativamente el uso (contraste insuficiente, falta de texto alternativo en imágenes informativas). Corregir en 2 semanas.
• Media: Reduce la calidad de la experiencia (orden de tabulacion suboptimo, nombres de enlace genericos). Corregir en 1 mes.
• Baja: Mejoras de experiencia (mensajes de estado más descriptivos, mejores instrucciones). Planificar para el proximo ciclo.

#Herramientas específicas para WordPress

#Plugins de accesibilidad

• WP Accessibility: Anade funciones de accesibilidad que faltan en muchos temas
• Starter theme con accesibilidad: Underscores (_s) incluye fundamentos de accesibilidad
• Equalize Digital Accessibility Checker: Escaneo automatizado integrado en el editor

#Temás accesibles

WordPress.org tiene una etiqueta “accessibility-ready” para temas que cumplen con estándares básicos. Sin embargo, “accessibility-ready” no significa “totalmente accesible” - es solo el punto de partida.

#Bloques Gutenberg

Los bloques nativos de Gutenberg generalmente tienen buena accesibilidad, pero los bloques personalizados y los de plugins de terceros frecuentemente fallan. Audite especialmente:

• Bloques de acordeon/pestanas
• Bloques de galeria de imágenes
• Bloques de formulario
• Bloques de video

#Automatizacion de auditorias continuas

Una sola auditoria no es suficiente. Implemente monitoreo continuo:

1. Integre Axe en CI/CD: Ejecute pruebas de accesibilidad automatizadas en cada despliegue
2. Lighthouse CI: Configure umbrales minimos de accesibilidad que bloqueen despliegues que no cumplan
3. Monitoreo periodico: Programe escaneos automatizados mensuales de las páginas más importantes
4. Capacitacion del equipo: Forme a desarrolladores y creadores de contenido en principios de accesibilidad

#Resumen: El flujo de trabajo completo

1. Escaneo automatizado con Axe y WAVE (detecta ~30% de problemas)
2. Pruebas de teclado navegando todo el sitio sin raton (detecta trampas y falta de enfoque)
3. Pruebas con lector de pantalla usando NVDA o VoiceOver (detecta problemas de anuncio y estructura)
4. Revision de código inspeccionando HTML semántico y ARIA (detecta problemas técnicos profundos)
5. Documentación con priorizacion y plan de remediacion

La accesibilidad no es un proyecto con fecha de finalizacion. Es un compromiso continuo que beneficia a todos los usuarios, mejora el SEO, reduce riesgos legales y demuestra valores corporativos autenticos.

Conozca más sobre los servicios de mantenimiento WordPress y la auditoria de seguridad WordPress en WPPoland.