≡En resumen
- Una auditoría compara el sitio con los criterios WCAG, no con la opinión del auditor.
- Las herramientas automáticas son el primer filtro, no el diagnóstico: se les escapa la mayoría de los criterios.
- La revisión manual con teclado, zoom y lector de pantalla es la parte que más barreras encuentra.
- Se audita una muestra representativa de plantillas y procesos completos, como el pago.
- El informe útil liga cada fallo a su criterio, su impacto, su ubicación y su solución.
01 ¿Qué es una auditoría de accesibilidad web?
Se distingue de un simple test en que sigue un método, cubre un alcance definido y deja evidencias. Parte del concepto de accesibilidad y lo aterriza en los criterios de conformidad de las pautas de accesibilidad: cada hallazgo se asocia a un criterio concreto, lo que lo hace verificable y defendible ante un cliente, un proveedor o una autoridad.
02 Cuándo hacer una auditoría de accesibilidad
- ✓Antes de publicar una web, un rediseño o una aplicación nueva.
- ✓Cuando la ley te obliga: sector público y, desde el 28 de junio de 2025, muchos servicios digitales al consumidor.
- ✓Para redactar o actualizar la declaración de accesibilidad de tu web.
- ✓Cuando un cliente, una licitación o un contrato te pide acreditar WCAG AA.
- ✓Tras cambios de plantilla, tema, plugin de formularios o pasarela de pago.
- ✓Si recibes quejas de usuarios que no pueden completar una tarea.
03 Cómo se hace una auditoría de accesibilidad paso a paso
El W3C publica una metodología para evaluar la conformidad con WCAG, WCAG-EM, cuya versión 2.0 (julio de 2026) se aplica ya también a apps y otros productos digitales. Sus cinco pasos son la base de cualquier auditoría seria:
-
1
Definir el alcance
Qué se audita (dominios, app, área privada), con qué versión y nivel de WCAG y con qué navegadores y tecnologías de apoyo.
-
2
Explorar el sitio
Identificar plantillas, componentes comunes (menú, buscador, formularios, carrusel) y procesos clave como registro, compra o contacto.
-
3
Seleccionar una muestra representativa
Una página de cada plantilla, los procesos completos de principio a fin y algunas páginas al azar.
-
4
Evaluar la muestra
Herramientas automáticas primero, después revisión manual de cada criterio aplicable y pruebas con tecnologías de apoyo.
-
5
Informar
Resultados por criterio, fallos con evidencias y recomendaciones, y una conclusión clara sobre el nivel alcanzado.
04 Herramientas automáticas: axe, WAVE, Lighthouse y sus límites
| Herramienta | Quién la hace | Formato | Útil para |
|---|---|---|---|
| axe DevTools / axe-core | Deque Systems | Extensión de navegador; motor de código abierto integrable en pruebas | Análisis por componente y en integración continua, con pocos falsos positivos |
| WAVE | WebAIM | Web y extensiones de navegador gratuitas; API de pago | Ver los errores marcados sobre la propia página, con explicación |
| Lighthouse | Google (incluido en Chrome) | Panel de DevTools e informe de PageSpeed Insights | Puntuación rápida; sus pruebas se ponderan con los criterios de impacto de axe |
| Analizadores de contraste | Varios | Extensiones y apps de escritorio | Medir el contraste de colores concretos, incluidos degradados y estados |
16 de 50
criterios WCAG 2.1 A y AA con fallos detectables automáticamente; por volumen de incidencias, la automatización encontró el 57 %
Fuente: Deque, estudio sobre cobertura de las pruebas automáticas
41 %
de 143 barreras encontró la herramienta más eficaz de diez probadas; el 29 % no lo detectó ninguna
Fuente: Government Digital Service (Reino Unido), febrero de 2017
05 Pruebas manuales y con lectores de pantalla
Solo teclado
Recorrer cada página y proceso con Tab, Mayúsculas+Tab, Enter, Espacio y flechas: orden lógico, foco siempre visible, sin trampas y todo operable.
Zoom y reajuste
Ampliar el texto al 200 % y la página a un ancho equivalente a 320 píxeles CSS sin pérdida de contenido ni scroll horizontal.
Lector de pantalla
NVDA (gratuito) o JAWS con Chrome o Firefox en Windows, VoiceOver en Mac e iPhone y TalkBack en Android: encabezados, nombres de botones, errores y avisos dinámicos.
Contenido y semántica
Que los textos alternativos describan, los enlaces se entiendan fuera de contexto, los encabezados sigan un orden y el idioma esté declarado.
Multimedia y movimiento
Subtítulos y transcripciones correctos, controles para pausar y ausencia de destellos.
Formularios y errores
Etiquetas visibles, instrucciones, mensajes de error que dicen qué falla y cómo arreglarlo, y ningún límite de tiempo sin aviso.
En escritorio, los lectores más usados son JAWS (40,5 %), NVDA (37,7 %) y VoiceOver (9,7 %); en móvil, el 70,6 % de los encuestados usa VoiceOver y el 34,7 % TalkBack, según la encuesta a usuarios de lectores de pantalla de WebAIM (diciembre de 2023 a enero de 2024). Probar con al menos dos combinaciones de lector y navegador da una imagen fiel.
06 El informe de auditoría: qué debe incluir
| Campo | Ejemplo |
|---|---|
| Criterio WCAG y nivel | 2.1.1 Teclado (A) |
| Ubicación | Plantilla de categoría, filtro de tallas |
| Descripción y evidencia | El desplegable solo se abre con el ratón; captura y pasos para reproducirlo |
| Impacto | Crítico: bloquea la compra a usuarios de teclado y de lector de pantalla |
| Recomendación | Usar un elemento button nativo con aria-expanded y gestionar el foco |
| Responsable | Desarrollo front-end |
- ✓Resumen ejecutivo con el nivel alcanzado y los bloqueos principales.
- ✓Alcance, muestra, fecha, versión de WCAG y tecnologías de apoyo usadas.
- ✓Resultados por criterio: cumple, no cumple o no aplica.
- ✓Priorización: primero lo que impide completar tareas clave.
- ✓Base para la declaración de accesibilidad o para un informe de conformidad (ACR) con la plantilla VPAT si vendes a empresas o administraciones.
Muchos fallos de accesibilidad coinciden con los del SEO técnico: encabezados, textos alternativos, enlaces, idioma o rendimiento. Por eso conviene coordinarla con una auditoría SEO técnica y corregir ambas en la misma plantilla.
07 Después de la auditoría: corregir y mantener
-
1
Corrige en la plantilla
Un componente arreglado soluciona el fallo en cientos de páginas; empieza por menú, formularios, carrito y pago.
-
2
Verifica
Repite las pruebas de cada hallazgo corregido antes de darlo por cerrado.
-
3
Automatiza lo automatizable
Integra axe-core en las pruebas del código para que los errores detectables no vuelvan.
-
4
Forma al equipo
Diseño, contenido y desarrollo deben conocer los criterios que les afectan; si no, los fallos reaparecen.
-
5
Revisa periódicamente
Una revisión al año, o con cada rediseño o funcionalidad importante, mantiene el nivel.
La forma más barata de aprobar una auditoría es diseñar pensando en ella: contraste, foco, tamaños y estados definidos en el sistema de diseño. Es lo que hacemos en nuestro servicio de diseño UI/UX y en cada proyecto de una empresa de diseño web que se toma en serio la accesibilidad.
Preguntas frecuentes sobre Web accessibility audit (auditoría de accesibilidad web)
Es una evaluación sistemática de una web o app frente a los criterios WCAG, normalmente nivel AA, que identifica las barreras para personas con discapacidad y documenta cómo corregirlas.
No. Las herramientas detectan fallos en una minoría de criterios: según Deque, en 16 de los 50 criterios WCAG 2.1 A y AA. Contraste, textos alternativos vacíos o campos sin etiqueta sí; que un texto alternativo sea correcto o que un menú funcione con teclado, no.
axe DevTools, WAVE y Lighthouse para el análisis automático; analizadores de contraste; y lectores de pantalla como NVDA, JAWS, VoiceOver y TalkBack para las pruebas manuales.
Es la metodología del W3C para evaluar la conformidad con WCAG. Su versión 2.0, publicada el 23 de julio de 2026, define cinco pasos: alcance, exploración, muestra, evaluación e informe.
Depende del número de plantillas y procesos. Una web corporativa sencilla puede revisarse en pocos días; una tienda online o una aplicación con área privada requiere más, porque cada proceso se prueba completo.
La auditoría comprueba el cumplimiento de criterios técnicos; el test de usabilidad observa a usuarios reales intentando hacer tareas. Lo ideal es combinar ambos, incluyendo participantes con discapacidad.
Al menos una vez al año y siempre tras un rediseño, un cambio de plantilla o una funcionalidad nueva importante, además de las comprobaciones automáticas en cada publicación.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗