Auditoría 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 electrónicos), esos clientes ya cargan con exposición legal directa si su sitio no cumple WCAG 2.2 AA. La auditoría dejo de ser un “añadido amable de consultoría”; es el documento que el equipo legal del cliente pedirá cuando llegue la primera reclamación.

En España, el marco resulta familiar: el Real Decreto 1112/2018 transpone la Directiva (UE) 2016/2102 y obliga a publicar declaración de accesibilidad en sitios del sector público, con el Observatorio de Accesibilidad Web (OAW) realizando auditorías periódicas y el Ministerio de Asuntos Económicos y Transformación Digital coordinando la conformidad. La EAA extiende está obligación 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 qué herramientas automatizadas empezar, donde dejan de ser útiles y como tratar las partes de WCAG 2.2 que solo una persona con teclado y NVDA puede verificar.

#Donde vive realmente la exposición legal

Un encuadre útil antes de abrir cualquier herramienta: la EAA no cubre solo “sector público”. Cubre servicios orientados al consumidor. Clientes privados que auditamos en los últimos doce meses y estaban dentro del ámbito: una librería española de libros electrónicos, un e-commerce alemán de mobiliario y una pequeña 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) recibió reclamación escrita dos meses después 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 podían alcanzarlo y NVDA no anunciaba nada al recibir foco. La corrección fue pequeña (sustituir por <button type="button">, restaurar el manejo nativo de foco, anunciar la transición con aria-live="polite"), pero el ida y vuelta legal absorbió aproximadamente una semana de tiempo de la agencia. Así es la forma del riesgo: no una demanda dramática, sino correspondencia lenta y costosa que se evita auditando antes del lanzamiento y en cada PR que toque el DOM.

WCAG 2.2 añade 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 interacción que solo se resuelva arrastrando (toggles tipo slider, ordenación kanban en el admin, sliders de comparación de imágenes) necesita alternativa de puntero único, como botones más/menos o entrada por teclado.
• 2.5.8 Tamaño de objetivo mínimo (AA) - los objetivos interactivos deben medir al menos 24×24 píxeles CSS. La mayoría de pies de tema, enlaces de páginación y tiras de iconos sociales fallan esto en móvil por defecto.

El núcleo de WordPress tiene accesibilidad decente para el editor de bloques y las primitivas de navegación del front. Los fallos que encontramos en auditoría 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 auditoría alrededor de eso, no del núcleo.

#Fase 1: Escaneó automatizado - lo que de verdad cazan

Sea honesto con el cliente sobre está cifra: las herramientas automáticas de accesibilidad cubren más o menos del 30 al 40 por ciento de los criterios de éxito WCAG. Detectan bien atributos alt ausentes, etiquetas de formulario faltantes, contraste insuficiente en texto estático, atributos de idioma ausentes, IDs duplicados y ARIA visiblemente roto. No le dirán 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 ratón. 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 separación entre “necesita revisión” y violaciones definitivas mantiene los falsos positivos cerca de cero. Escanee cada plantilla distinta (portada, archivo, single, producto, checkout, contacto, login, resultados de búsqueda) y no cada URL: la mayoría de sitios WordPress españoles tiene menos de diez plantillas diferentes aunque sirvan miles de páginas. WebAIM WAVE sirve como segunda opinion, sobre todo para visualizar la estructura de encabezados cuando un redactor escribió h4 “porque queda bien”. Pa11y en GitHub Actions o Bitbucket Pipelines atrapa regresiones en el PR donde son más 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 pestaña “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
• Problemas 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 diseñadores y clientes no técnicos porque muestra visualmente donde están los errores.

#Lighthouse

Integrado en Chrome DevTools, Lighthouse proporciona una puntuación general de accesibilidad junto con métricas de rendimiento y SEO.

Mejor práctica: Ejecute Lighthouse en las 5-10 páginas más críticas 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 más reveladora y donde viven varios criterios WCAG 2.2 que decidirán cualquier reclamación. Desconecte el ratón. 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 diálogos y menús desplegables

#Que comprobar

1. Alcance: llega a cada elemento interactivo, incluidos los que aparecen al hacer hover (mega menus, tooltips, “ver más”)?
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 píxeles 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 más habitual en sitios construidos antes de 2024.
4. Sin trampas de teclado y sin interacciones solo con drag (criterio 2.5.7): comparadores de imágenes, range estilizados como handle y reordenación en backoffice necesitan alternativa de puntero único.
5. Tamaño de objetivo 24×24 CSS píxeles (criterio 2.5.8): páginación, iconos sociales del pie e iconos “x” inline son los sospechosos habituales.

#Problemas 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 útiles 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 electrónico, 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: Revisión manual de código

Después 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> genéricos.
• 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 programáticamente a los campos correspondientes.

<!-- Ejemplo de formulario accesible -->
<form>
  <div>
    <label for="email">Correo electrónico</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 dirección de correo valida.
    </span>
  </div>
</form>

#Fase 5: Documentación y priorización

Una auditoría sin documentación adecuada no tiene valor. Cree un informe estructurado que fácilite la remediación.

#Estructura del informe

Para cada problema identificado, documente:

1. Descripción: Que es el problema
2. Ubicación: 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 corrección

#Priorización

• 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 tabulación suboptimo, nombres de enlace genéricos). Corregir en 1 mes.
• Baja: Mejoras de experiencia (mensajes de estado más descriptivos, mejores instrucciones). Planificar para el próximo ciclo.

#Herramientas específicas para WordPress

#Plugins de accesibilidad

• WP Accessibility: Añade funciones de accesibilidad que faltan en muchos temas
• Starter theme con accesibilidad: Underscores (_s) incluye fundamentos de accesibilidad
• Equalize Digital Accessibility Checker: Escaneó 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 acordeón/pestañas
• Bloques de galería de imágenes
• Bloques de formulario
• Bloques de video

#Automatización de auditorías continuas

Una sola auditoría 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 mínimos de accesibilidad que bloqueen despliegues que no cumplan
3. Monitoreo periódico: Programe escaneos automatizados mensuales de las páginas más importantes
4. Capacitación del equipo: Forme a desarrolladores y creadores de contenido en principios de accesibilidad

#Resumen: El flujo de trabajo completo

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

La accesibilidad no es un proyecto con fecha de finalización. Es un compromiso continuo que beneficia a todos los usuarios, mejora el SEO, reduce riesgos legales y demuestra valores corporativos auténticos.

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