¿Qué es una auditoría de accesibilidad? Cómo comprobar si tu sitio web cumple con las WCAG

Según el último informe WebAIM Million, se detectaron 56 millones de errores de accesibilidad distintos en un millón de páginas de inicio, lo que supone una media de 56 errores por página. Eso significa que la inmensa mayoría de los sitios web están fallando activamente a las personas con discapacidad todos los días. Si eres propietario de un sitio web, desarrollador o responsable de cumplimiento y te preguntas si tu sitio cumple con las WCAG, la respuesta casi con total seguridad pasa por realizar una auditoría de accesibilidad adecuada. La cuestión es: ¿qué significa realmente eso y cómo hacerlo bien?

Por qué las auditorías de accesibilidad se han vuelto innegociables

La accesibilidad web ha ido mucho más allá del terreno de las buenas intenciones. Ahora es un requisito legal en un número creciente de jurisdicciones, y las consecuencias del incumplimiento son concretas y medibles. En 2024 se presentaron en Estados Unidos más de 4,000 demandas por accesibilidad web, y la tendencia sigue en aumento. Los tribunales estadounidenses han sostenido de forma constante que los sitios web de negocios abiertos al público deben ser accesibles en virtud del Título III de la ADA. Mientras tanto, la European Accessibility Act pasó a ser exigible en todos los estados miembros de la UE en junio de 2025, ampliando los requisitos más allá de los sitios gubernamentales para abarcar apps bancarias, plataformas de comercio electrónico, productos SaaS y más.

Las cifras dibujan un panorama contundente. Alrededor del 16% de la población mundial —aproximadamente 1.3 mil millones de personas— vive con algún tipo de discapacidad. Solo en Estados Unidos, aproximadamente uno de cada cuatro adultos tiene una discapacidad. No se trata de casos marginales. Son clientes, empleados, estudiantes y ciudadanos que se encuentran con barreras en sitios web que la mayoría de los desarrolladores ni siquiera se plantean.

Más allá del riesgo legal, existe un caso empresarial medible. Los sitios web accesibles se desempeñan mejor en los motores de búsqueda, porque la misma claridad estructural que ayuda a los lectores de pantalla —encabezados semánticos, texto alternativo descriptivo, marcado limpio— también ayuda a los rastreadores. El diseño inclusivo mejora de forma constante la usabilidad para todas las personas: los subtítulos benefician a quienes están en entornos ruidosos, el alto contraste ayuda a quienes están a pleno sol y la navegación por teclado beneficia a los usuarios avanzados. Una auditoría de accesibilidad es el primer paso para aprovechar todos estos beneficios.

Un cambio importante más: el Título II de la ADA ahora exige explícitamente la accesibilidad web para entidades gubernamentales estatales y locales de Estados Unidos, y el DOJ ha adoptado WCAG 2.1 Nivel AA como estándar técnico. Las entidades que atienden a poblaciones de 50,000 o más se enfrentan a un plazo de cumplimiento que vence el 26 de abril de 2026. Si trabajas con clientes del sector público o en industrias reguladas, auditar ya no es opcional: es urgente.

¿Qué es exactamente una auditoría de accesibilidad WCAG?

Una auditoría de accesibilidad web es una evaluación sistemática del cumplimiento de tu sitio con las Web Content Accessibility Guidelines (WCAG), el estándar técnico internacionalmente reconocido para la accesibilidad digital, desarrollado por el W3C. En la práctica, una auditoría identifica barreras específicas que impiden que las personas con discapacidad perciban, comprendan, naveguen e interactúen con tu contenido. Mapea esas barreras frente a los criterios de éxito de las WCAG, asigna niveles de gravedad y produce una hoja de ruta de remediación.

Actualmente, WCAG está en su versión 2.2, publicada a finales de 2023 y reafirmada formalmente por el W3C en mayo de 2025 como el estándar más alto para accesibilidad web. Incluye nueve nuevos criterios de éxito respecto a WCAG 2.1, que abarcan áreas como la visibilidad del foco del teclado, tamaños mínimos de objetivos táctiles, alternativas al arrastre y mecanismos de ayuda consistentes. Es importante destacar que WCAG 2.2 es retrocompatible: cumplir con 2.2 significa que también cumples con 2.1 y 2.0.

WCAG se organiza en torno a tres niveles de conformidad. El Nivel A cubre las barreras más críticas: los fallos en este nivel hacen que el contenido sea completamente inutilizable para algunas personas. El Nivel AA es el objetivo exigido por la mayoría de las leyes de accesibilidad en todo el mundo, incluida la ADA, la European Accessibility Act y la Sección 508. El Nivel AAA representa el listón más alto y suele ser aspiracional más que un requisito legal. Cuando alguien dice que su sitio es “compatible con WCAG”, casi siempre se refiere a WCAG 2.1 o 2.2, Nivel AA.

WCAG se basa en cuatro principios fundamentales, a menudo recordados por el acrónimo POUR: el contenido debe ser Perceivable (las personas pueden percibirlo), Operable (las personas pueden interactuar con él), Understandable (las personas pueden comprenderlo) y Robust (funciona de forma fiable con tecnologías de asistencia). Cada criterio de éxito se vincula con uno de estos cuatro principios, y una auditoría exhaustiva comprueba la conformidad con todos ellos.

Los fallos más comunes que revelan las auditorías

Aproximadamente el 96% de todos los errores de accesibilidad detectados se concentran en solo seis categorías. Saber qué buscar es la forma más rápida de priorizar el esfuerzo de tu auditoría:

• Texto con bajo contraste. Este es de forma constante el fallo más común. Casi el 84% de las páginas de inicio tienen texto que está por debajo del umbral de contraste 4.5:1 de WCAG 2 AA para texto normal. Las personas auditoras comprueban las relaciones de color entre primer plano y fondo usando herramientas como TPGi Colour Contrast Analyser.
• Texto alternativo ausente. Más del 16% de todas las imágenes de páginas de inicio carecen de cualquier atributo alt, dejando a las personas usuarias de lectores de pantalla sin forma de entender el contenido de la imagen. Las imágenes enlazadas sin texto alternativo son especialmente perjudiciales: se convierten en destinos de navegación sin significado.
• Enlaces vacíos. Los enlaces que no contienen texto visible ni nombre accesible crean callejones sin salida para quienes usan teclado y lectores de pantalla, ya que no pueden determinar adónde lleva el enlace.
• Etiquetas de campos de formulario ausentes. Los formularios sin etiquetas asociadas de forma programática son inutilizables para las personas usuarias de lectores de pantalla. Esto incluye tanto etiquetas visibles como etiquetas ocultas que usan aria-label o aria-labelledby.
• Botones vacíos. Los botones solo con icono y sin nombre accesible —comunes en navegación y sliders— dejan a las personas que no ven la pantalla sin forma de identificar qué hace el botón.
• Idioma del documento ausente. El atributo lang en el elemento <html> indica a los lectores de pantalla qué idioma deben usar. Su ausencia provoca mala pronunciación y desorientación en las personas que dependen de la conversión de texto a voz.

Las auditorías revelan de forma constante que los fallos más perjudiciales también son los más fáciles de corregir. El bajo contraste, la ausencia de texto alternativo y los campos de formulario sin etiquetar suelen poder remediarse en días, no en meses.

Más allá de estos seis, una auditoría exhaustiva también detectará la ausencia de enlaces para saltar la navegación (que obligan a las personas que usan teclado a tabular por cada elemento de encabezado en cada página), jerarquías de encabezados incorrectas, modales y diálogos inaccesibles que gestionan mal el foco, vídeos sin subtítulos, PDF sin estructura etiquetada y widgets JavaScript personalizados que no exponen roles y estados accesibles mediante ARIA.

Cómo realizar una auditoría de accesibilidad: paso a paso

Una auditoría de accesibilidad adecuada no es un único escaneo: es un proceso de varias etapas que combina herramientas automatizadas con el criterio experto humano. Así es como debes abordarlo de forma sistemática:

Paso 1: Definir el alcance

Antes de ejecutar una sola prueba, decide qué vas a auditar. En un sitio grande, probar cada página es poco práctico. En su lugar, aplica el enfoque WCAG-EM (Website Accessibility Conformance Evaluation Methodology) desarrollado por el W3C: define una muestra representativa que cubra todas las plantillas de página únicas, todos los recorridos de usuario significativos y todos los tipos de contenido distintos. Una muestra para un sitio de comercio electrónico podría incluir la página de inicio, una página de categoría, una página de detalle de producto, el carrito, el flujo de pago, el inicio de sesión de cuenta, el formulario de contacto y una entrada de blog. Asegúrate de incluir estados dinámicos: menús desplegados, mensajes de error de formularios, diálogos modales y resultados de búsqueda cargados deben evaluarse.

Paso 2: Ejecutar escaneos automatizados

Las herramientas automatizadas son la base de cualquier auditoría eficiente. Analizan tu HTML rápidamente, señalan infracciones de reglas inequívocas y te proporcionan una lista inicial de problemas. Las herramientas clave incluyen:

• axe DevTools (extensión de navegador o CLI): muy utilizada, baja tasa de falsos positivos, se integra con pipelines CI/CD
• WAVE (WebAIM): anota las páginas visualmente con iconos de error, lo que la hace intuitiva para miembros del equipo no técnicos
• Lighthouse (integrada en Chrome DevTools): proporciona una puntuación de accesibilidad junto con métricas de rendimiento y SEO
• Colour Contrast Analyser (TPGi): selecciona cualquier color en pantalla y lo comprueba frente a los umbrales de WCAG
• PAC 2024: verificador dedicado de accesibilidad de PDF para documentos descargables

Una limitación crítica: las herramientas automatizadas solo pueden detectar entre el 30% y el 40% de los problemas de WCAG. Son excelentes para señalar fallos basados en reglas como atributos ausentes, roles ARIA no válidos y relaciones de contraste. Pero no pueden juzgar si el texto alternativo es significativo, si un formulario está estructurado de forma lógica o si una persona puede realmente completar una tarea. Por eso la automatización es el Paso 2, no la auditoría completa.

Paso 3: Pruebas manuales expertas

Las pruebas manuales realizadas por una persona experta —o idealmente un equipo— son las que determinan la profundidad de una auditoría. Esto incluye:

• Navegación solo con teclado. Desconecta el ratón e intenta completar cada recorrido de usuario clave usando solo Tab, Shift+Tab, Enter, Space y las teclas de flecha. ¿Puedes llegar a cada elemento interactivo? ¿El indicador de foco es siempre visible? ¿El foco desaparece alguna vez dentro de un componente?
• Pruebas con lectores de pantalla. Usa NVDA con Chrome o Firefox en Windows, y VoiceOver con Safari en macOS e iOS. Navega por encabezados, regiones, enlaces y formularios. ¿La página tiene sentido sin contexto visual? ¿Se anuncian correctamente todos los elementos interactivos?
• Revisión visual y cognitiva. Comprueba que la jerarquía de encabezados tenga una estructura lógica, verifica que los mensajes de error sean descriptivos y estén asociados con el campo correcto, confirma que los medios temporizados tengan subtítulos y transcripciones y revisa que las instrucciones no dependan únicamente del color, la forma o la posición.
• Inspección de código. Revisa la semántica HTML, el uso de ARIA, la gestión del foco en widgets personalizados y las regiones de referencia (landmarks). Un modal que no atrapa el foco, o una región ARIA en vivo que se activa con cada pulsación de tecla, solo se detectarán en este nivel.

Paso 4: Pruebas con tecnologías de asistencia y personas usuarias reales

El estándar de oro —y a menudo la etapa más reveladora— es probar con personas reales que dependen de tecnologías de asistencia a diario. Las personas que usan lectores de pantalla, dispositivos de acceso por pulsador o software de control por voz navegan de formas que ni siquiera las personas expertas en pruebas manuales replican por completo. Incluir a personas con discapacidad en tu evaluación saca a la luz fricciones del mundo real que las herramientas y listas de verificación simplemente no pueden anticipar.

Paso 5: Documentar y priorizar los hallazgos

Una lista en bruto de fallos no es un informe de auditoría: es un punto de partida. Un documento de auditoría útil debe especificar: la URL o componente afectado, el criterio de éxito de WCAG vulnerado, la gravedad (crítica, alta, media, baja), el impacto en las personas afectadas y orientaciones específicas de remediación con ejemplos de código cuando proceda. La prioridad debe asignarse en función del impacto en las personas usuarias primero, no de la comodidad técnica. Una etiqueta de formulario rota que impide completar el pago es más urgente que un nivel de encabezado subóptimo en una barra lateral de blog.

Paso 6: Remediar, validar y monitorizar

Una vez implementadas las correcciones, valídalas: no des por hecho que la remediación ha funcionado. Vuelve a probar cada corrección con la misma combinación de herramientas y comprobaciones manuales utilizadas durante la auditoría original. Tras alcanzar un nivel básico de conformidad, establece una monitorización continua. El contenido nuevo, las actualizaciones del CMS y los scripts de terceros pueden introducir regresiones en cualquier momento. Trata la accesibilidad como la seguridad: algo que se mantiene, no algo que se logra una vez y se olvida.

Escaneos automatizados vs. auditorías completas: entender la diferencia

Esta distinción es enormemente importante, especialmente en un contexto legal. Un escaneo automatizado ejecuta una comprobación basada en reglas sobre tu HTML renderizado. Toma segundos o minutos y devuelve una lista de infracciones detectadas. Es excelente para detectar problemas obvios y de alto volumen y para integrarse en flujos de trabajo CI/CD a fin de evitar que se publiquen nuevas regresiones. Muchos productos de superposición y widgets —incluidas herramientas de accesibilidad— ofrecen paneles de escaneo automatizado como parte de su conjunto de funciones, y estos son realmente útiles para la monitorización continua.

Una auditoría completa, en cambio, evalúa tu sitio frente a todos los criterios de éxito de WCAG aplicables usando una combinación de escaneo automatizado, revisión manual experta, pruebas con lectores de pantalla y navegación solo con teclado. Una auditoría exhaustiva que combine métodos automatizados y manuales puede sacar a la luz más del 90% de los problemas de accesibilidad, frente al techo del 30–40% de la automatización por sí sola. Si te enfrentas a una carta de requerimiento legal, una exigencia de contratación pública o una investigación regulatoria, solo una auditoría completa produce la documentación que necesitas.

Muchas organizaciones utilizan una estrategia híbrida práctica: los escaneos automatizados se ejecutan de forma continua en CI/CD para detectar regresiones pronto, mientras que una auditoría manual completa se realiza anualmente o después de rediseños significativos del sitio. Esto equilibra exhaustividad y eficiencia y mantiene el cumplimiento manejable a lo largo del tiempo.

Ninguna herramienta por sí sola puede determinar si un sitio cumple las normas de accesibilidad. Se requiere una evaluación humana experta para determinar si un sitio es realmente accesible. — W3C Web Accessibility Initiative

Qué hacer con los resultados de la auditoría: planificación de la remediación

Una auditoría completada solo es valiosa si impulsa la acción. La forma en que priorices el trabajo de remediación importa tanto como identificar los problemas en primer lugar. Un marco práctico para priorizar la remediación se ve así:

1. Crítico (corregir de inmediato): Problemas que bloquean por completo a las personas usuarias para completar tareas clave: un formulario de pago roto, un modal de inicio de sesión inaccesible, un menú de navegación al que no se puede acceder con el teclado. Representan el mayor riesgo legal y el mayor impacto en las personas usuarias.
2. Alto (corregir en el sprint o ciclo de lanzamiento actual): Problemas que perjudican significativamente la usabilidad para las personas con discapacidad, pero no las bloquean por completo: ausencia de texto alternativo en imágenes de producto, bajo contraste en el texto principal, botones de icono sin etiquetar en toda la interfaz.
3. Medio (remediación planificada): Problemas que generan fricción pero tienen soluciones alternativas: indicadores de foco inconsistentes, enlaces para saltar la navegación ausentes, jerarquía de encabezados subóptima.
4. Bajo (backlog con responsable definido): Problemas que son mejoras de buenas prácticas pero que probablemente no afecten a la usabilidad en la mayoría de los casos: mejoras de nivel AAA, pequeñas mejoras en la verbosidad de ARIA.

Documenta tu plan de remediación y el calendario, incluso antes de que todas las correcciones estén completas. En general, los reguladores y tribunales valoran de forma positiva la mejora continua y de buena fe frente a la inacción. Si recibes una carta de requerimiento, contar con un informe de auditoría más un calendario de remediación es una posición mucho más sólida que no tener documentación alguna.

Los widgets de superposición y las herramientas SDK —como la que ofrece Accsible— pueden desempeñar un papel significativo en la fase de remediación. Pueden aportar correcciones inmediatas para una parte importante de los problemas comunes (especialmente preferencias visuales como contraste, tamaño de fuente y espaciado) mientras tu equipo de desarrollo trabaja en remediaciones más profundas a nivel de código. La clave es entender qué resuelven bien las superposiciones y usarlas como parte de una estrategia por capas, no como sustituto de las correcciones a nivel de código en barreras críticas.

¿Con qué frecuencia deberías realizar una auditoría de accesibilidad?

Una auditoría puntual es una instantánea de tu sitio en un día concreto. Los sitios web son productos vivos: el contenido cambia, los scripts de terceros se actualizan, los componentes se sustituyen y se lanzan nuevas funciones. Cada uno de estos eventos puede introducir nuevas barreras de accesibilidad. Un programa de accesibilidad sostenible suele verse así:

• Escaneo automatizado continuo integrado en tu pipeline CI/CD o mediante un panel de monitorización, para detectar regresiones antes de que lleguen a producción
• Revisiones manuales trimestrales en páginas de alto tráfico y alto riesgo (pago, inicio de sesión, formularios de contacto, páginas de destino clave)
• Auditoría completa anual realizada por personas expertas cualificadas en accesibilidad, especialmente después de rediseños importantes o migraciones de plataforma
• Auditoría en la fase de diseño para cualquier nueva funcionalidad importante o rediseño: la accesibilidad es significativamente más barata de incorporar desde el principio que de adaptar a posteriori

El enfoque más rentable es desplazar la accesibilidad hacia la izquierda: integrarla en el proceso de diseño y desarrollo desde el primer día en lugar de tratarla como un ejercicio de cumplimiento posterior al lanzamiento. Las personas desarrolladoras que entienden los requisitos de WCAG detectan los problemas en origen. Las personas diseñadoras que conocen el contraste de color y los tamaños de los objetivos táctiles toman decisiones accesibles por defecto. La auditoría se convierte entonces en una puerta de calidad, no en una intervención de emergencia.

Conclusiones clave

• La mayoría de los sitios web no cumplen con WCAG. Más del 95% de las páginas de inicio tienen errores de accesibilidad detectables, y los seis fallos más comunes —bajo contraste, ausencia de texto alternativo, enlaces vacíos, etiquetas de formulario ausentes, botones vacíos e idioma del documento ausente— representan la gran mayoría. Todos son corregibles.
• Las herramientas automatizadas son necesarias pero no suficientes. Los escáneres automatizados detectan, como máximo, entre el 30% y el 40% de los problemas de WCAG. Una auditoría completa requiere pruebas con teclado, pruebas con lectores de pantalla y revisión experta humana del código y de los flujos de experiencia de usuario.
• WCAG 2.2 Nivel AA es el objetivo. Es el estándar al que hacen referencia la ADA, la European Accessibility Act, la Sección 508 y la mayoría de los demás marcos de accesibilidad en todo el mundo. Apuntar a 2.2 AA significa que cubres automáticamente todas las versiones anteriores.
• La remediación necesita un marco de prioridades. Empieza por los problemas que bloquean por completo los recorridos clave de las personas usuarias y luego aborda los problemas de alto impacto y alta frecuencia. Documenta todo: tu informe de auditoría y tu plan de remediación son tu mejor defensa legal.
• La accesibilidad es continua, no algo de una sola vez. Combina la monitorización automatizada continua con auditorías manuales periódicas e integra la accesibilidad en tu proceso de diseño y desarrollo desde el principio. Un widget de superposición como Accsible puede cubrir brechas mientras se llevan a cabo remediaciones más profundas.