Qué es una auditoría de accesibilidad web
Una auditoría de accesibilidad web es la revisión sistemática de un sitio para comprobar si cumple los criterios de la norma WCAG 2.1 nivel AA, que es el estándar técnico de referencia tanto en el RD 1112/2018 como en la Ley 11/2023. El resultado es un informe con los puntos que fallan, su nivel de gravedad y las acciones necesarias para corregirlos.
Hay tres formas de hacerla, y conviene no confundirlas:
- Auditoría automática Herramientas como Lighthouse, axe DevTools o WAVE rastrean el código y detectan errores objetivos: contraste insuficiente, imágenes sin texto alternativo, etiquetas HTML mal usadas. Cubre solo una parte de los criterios de WCAG 2.1
- Auditoría manual. Un auditor revisa a mano lo que el software no puede evaluar: si el orden de tabulación tiene sentido, si el foco de teclado es visible, si los textos alternativos describen la imagen o son genéricos, si los formularios anuncian los errores correctamente a un lector de pantalla.
- Auditoría con usuarios reales. Personas con discapacidad visual, motora o cognitiva usan el sitio con su tecnología de asistencia habitual (lector de pantalla, navegación por teclado, switch). Es la más concluyente pero también la más cara, y normalmente se reserva para sitios de alto riesgo legal o de gran volumen de tráfico.
Una auditoría seria combina las tres capas. Una auditoría que solo pasa un escáner automático y entrega un PDF con los errores de Lighthouse no es una auditoría de accesibilidad: es un reporte técnico parcial vendido como si fuera completo.
Marco legal: qué exige cada norma
Aquí es donde más confusión hay, y es importante no mezclar las dos normas:
- RD 1112/2018. Aplica a sitios web y aplicaciones móviles del sector público: administraciones, organismos públicos, universidades, entidades que reciben financiación pública mayoritaria. Exige cumplir WCAG 2.1 nivel AA y publicar una declaración de accesibilidad actualizada.
- Ley 11/2023. Transpone la Directiva Europea de Accesibilidad (EAA) al ordenamiento español y extiende obligaciones de accesibilidad a determinadas empresas privadas: banca, comercio electrónico, transporte de viajeros, telecomunicaciones, libros electrónicos, entre otros sectores regulados. El criterio técnico de referencia sigue siendo WCAG 2.1 AA.
Para una agencia que gestiona clientes de ambos tipos, la pregunta que define qué normativa aplica no es «¿tiene web pública?» sino «¿es organismo público o entidad de derecho público?» para el RD 1112/2018, y «¿pertenece a un sector regulado por la Ley 11/2023?» para la segunda. Confirmar esto antes de presupuestar la auditoría evita comprometerse a un alcance legal que no corresponde al cliente.
Criterios WCAG 2.1 AA que realmente se revisan
En la práctica, la mayoría de los hallazgos de una auditoría se concentran en un grupo reducido de criterios. Los más frecuentes:
- Contraste de color (criterio 1.4.3). El texto normal necesita una relación de contraste mínima de 4.5:1 contra el fondo; el texto grande (18pt o 14pt en negrita) baja a 3:1. Es el fallo más común porque suele venir de decisiones de diseño tomadas antes de pensar en accesibilidad, no de un error técnico.
- Texto alternativo en imágenes (criterio 1.1.1). No basta con que exista el atributo «alt»: tiene que describir la función o el contenido de la imagen. Un «alt=»imagen1.jpg»» o un «alt» vacío en una imagen informativa cuenta como fallo igual que si no existiera.
- Navegación por teclado (criterio 2.1.1). Todo lo que se puede hacer con ratón tiene que poderse hacer con teclado: abrir menús, cerrar modales, completar formularios, activar carruseles. El fallo típico son los menús desplegables construidos solo con eventos de hover.
- Foco visible (criterio 2.4.7). Cuando alguien navega con teclado, tiene que verse claramente en qué elemento está el foco. Muchos temas de WordPress eliminan el contorno de foco por estética y no lo reemplazan por nada.
- Estructura semántica (criterio 1.3.1). Encabezados en orden lógico (H1 único, H2 y H3 anidados correctamente), listas marcadas como listas, tablas de datos con encabezados de fila y columna. Un diseño que usa «<div>» con estilos de encabezado en vez de etiquetas «<h2>» reales falla este criterio aunque visualmente parezca correcto.
- Formularios y mensajes de error (criterio 3.3.2). Cada campo necesita una etiqueta asociada correctamente, y los errores de validación tienen que anunciarse de forma que un lector de pantalla los detecte, no solo con un cambio de color en el borde del campo.
El proceso paso a paso
- Definir el alcance. No se audita «la web» en abstracto: se define qué páginas o plantillas representan el sitio (home, ficha de producto, formulario de contacto, checkout si aplica) y con qué nivel de WCAG se va a evaluar.
- Escaneo automático. Se pasa la herramienta de rastreo sobre las páginas del alcance para detectar los errores objetivos de código.
- Revisión manual con teclado y lector de pantalla. Se navega cada plantilla sin ratón y con un lector de pantalla activo, replicando el uso real.
- Registro de hallazgos. Cada fallo se documenta con: criterio WCAG incumplido, ubicación exacta, captura o código de ejemplo, nivel de gravedad (crítico, alto, medio, bajo) y una propuesta de corrección concreta, no genérica.
- Priorización. Los hallazgos críticos son los que bloquean por completo una tarea (un formulario que no se puede enviar con teclado); los de baja gravedad afectan la experiencia sin impedir la tarea. La priorización determina qué se corrige primero cuando el presupuesto de remediación es limitado.
- Informe final. Documento entregable con el resumen ejecutivo, el detalle de cada hallazgo y una hoja de ruta de remediación.
Qué tiene que incluir un informe de auditoría serio
Si estás evaluando presupuestos de terceros o el trabajo de un proveedor, un informe de auditoría de accesibilidad web debería tener, como mínimo:
- Alcance exacto: qué páginas o plantillas se revisaron y con qué versión del sitio
- Metodología usada: automática, manual, con usuarios, o combinación
- Listado de hallazgos con el criterio WCAG específico incumplido, no descripciones vagas tipo «problemas de accesibilidad detectados»
- Nivel de gravedad de cada hallazgo
- Recomendación de corrección concreta para cada uno, con ejemplo de código cuando aplica
- Una conclusión sobre el nivel de conformidad actual (no conforme, parcialmente conforme, conforme) respecto a WCAG 2.1 AA
Un informe que solo dice «se recomienda mejorar la accesibilidad del sitio» sin desglose por criterio no permite priorizar nada, y normalmente es la señal de una auditoría hecha solo con un escáner automático.
Lo que falla más a menudo
En auditorías de sitios WordPress hechos con constructores visuales (Elementor, Divi, Gutenberg con bloques de terceros), los hallazgos se repiten con un patrón bastante constante: contraste insuficiente en botones y textos sobre imágenes de fondo, carruseles y sliders sin control de pausa ni navegación por teclado, formularios de contacto generados por plugins que no asocian correctamente las etiquetas, y encabezados usados por tamaño de fuente en vez de por jerarquía real del documento. Ninguno de estos fallos requiere reconstruir el sitio: se corrigen a nivel de plantilla y CSS, sin tocar la estructura de páginas.
