La accesibilidad web no debería ser una comprobación de última hora ni una tarea reservada para una auditoría puntual. Forma parte de la calidad de cualquier producto digital y, por tanto, debería estar presente durante el diseño, el desarrollo, las pruebas y el mantenimiento.
Una página puede parecer correcta a simple vista y, aun así, presentar barreras importantes. Por ejemplo, puede incluir botones sin un nombre comprensible, campos de formulario sin etiquetas, textos con poco contraste o componentes que no pueden utilizarse con teclado.
Las herramientas para revisar la accesibilidad web ayudan a localizar muchos de estos problemas antes de que lleguen a producción. Entre las más conocidas se encuentran Lighthouse, axe y WAVE.
Las tres permiten analizar una interfaz, pero no ofrecen exactamente el mismo tipo de revisión. Lighthouse proporciona una auditoría general, axe profundiza en los errores técnicos y WAVE facilita una interpretación visual de la estructura de la página.
Ahora bien, ninguna herramienta automática puede confirmar por sí sola que una web sea completamente accesible. Su función es señalar problemas detectables mediante reglas, no sustituir la experiencia de navegar con teclado, ampliar el contenido, utilizar un lector de pantalla o completar una tarea real.
En esta guía veremos cómo usar Lighthouse, axe y WAVE, qué puede aportar cada herramienta y cómo combinarlas dentro de un proceso de testing de accesibilidad más completo.
Por qué utilizar herramientas de accesibilidad web
Una aplicación moderna puede contener decenas de páginas, formularios, menús, ventanas modales, pestañas y componentes que cambian después de una interacción. Revisar manualmente cada uno de estos elementos requiere tiempo y una metodología clara.
Las herramientas automáticas permiten realizar una primera inspección de aspectos como:
- La presencia de alternativas textuales en las imágenes.
- La relación entre etiquetas y campos de formulario.
- El contraste entre el texto y el fondo.
- La estructura de encabezados.
- La validez de determinados atributos ARIA.
- La existencia de nombres accesibles en botones y enlaces.
- La definición del idioma principal de la página.
- Algunos errores relacionados con tablas, listas y regiones.
Esta automatización resulta útil porque permite encontrar errores frecuentes con rapidez y repetir el análisis después de cada cambio importante.
Sin embargo, conviene comprender desde el principio que una puntuación alta no equivale a una experiencia accesible.
Una herramienta puede comprobar que una imagen tiene un atributo alt, pero no siempre podrá decidir si ese texto describe correctamente la imagen. También puede detectar que un botón dispone de un nombre accesible, aunque no sabrá con certeza si ese nombre es suficientemente claro dentro del contexto.
Lo mismo ocurre con los componentes interactivos. Un modal puede tener los roles adecuados y seguir siendo difícil de utilizar si el foco no se mueve correctamente al abrirlo o si no vuelve al elemento de origen cuando se cierra.
Por eso, el análisis automático debe considerarse una parte del proceso y no la respuesta definitiva.
Lighthouse: una primera auditoría desde el navegador
Lighthouse es una herramienta integrada en las DevTools de Chrome y otros navegadores basados en Chromium. Permite evaluar diferentes áreas de una página, como rendimiento, buenas prácticas, SEO y accesibilidad.
Su facilidad de uso la convierte en una opción adecuada para realizar una primera revisión. No es necesario instalar una extensión adicional ni configurar un entorno de pruebas.
Para ejecutar una auditoría:
- Abre la página que deseas revisar.
- Accede a las herramientas para desarrolladores.
- Selecciona el panel Lighthouse.
- Marca la categoría de accesibilidad.
- Genera el informe.
En pocos segundos, Lighthouse muestra una puntuación y una lista de comprobaciones superadas o fallidas.
Qué analiza Lighthouse en accesibilidad
Lighthouse puede detectar problemas relacionados con:
- Botones y enlaces sin nombres accesibles.
- Imágenes sin texto alternativo.
- Campos de formulario sin etiquetas.
- Contraste insuficiente.
- Atributos ARIA inválidos.
- Identificadores duplicados.
- Elementos interactivos anidados incorrectamente.
- Ausencia del atributo de idioma.
- Estructuras básicas de tablas y listas.
- Controles con tamaños o nombres problemáticos.
Los resultados incluyen explicaciones y referencias que ayudan a entender por qué se ha señalado cada incidencia.
Para una persona que empieza a introducir accesibilidad en su flujo de desarrollo, esta presentación resulta especialmente útil. Permite pasar de una puntuación general a problemas concretos sin necesidad de conocer previamente todas las reglas.
Ventajas de Lighthouse
La principal ventaja de Lighthouse es su accesibilidad como herramienta de trabajo. Está disponible directamente en el navegador y puede ejecutarse durante el desarrollo sin preparar un entorno específico.
También permite obtener una visión conjunta del estado de la página. Aunque el análisis de accesibilidad es independiente del rendimiento o el SEO, revisar estas áreas desde un mismo panel ayuda a introducir la accesibilidad dentro de una definición más amplia de calidad web.
Lighthouse es especialmente útil para:
- Realizar una primera evaluación.
- Detectar errores evidentes durante el desarrollo.
- Comparar una página antes y después de una corrección.
- Introducir revisiones básicas en equipos que todavía no tienen un proceso de accesibilidad.
- Obtener un informe sencillo que pueda compartirse con otros perfiles.
Limitaciones de Lighthouse
El principal riesgo de Lighthouse es interpretar su puntuación como una certificación.
Obtener un resultado de 100 significa que la herramienta no ha encontrado errores dentro de las reglas ejecutadas. No significa que todos los contenidos, recorridos e interacciones sean accesibles.
Además, Lighthouse analiza el estado actual de la página. Si un modal está cerrado, un acordeón permanece contraído o un mensaje de error todavía no se ha mostrado, esos elementos pueden quedar fuera de la revisión.
Para obtener resultados más útiles, conviene ejecutar la auditoría en diferentes estados:
- Página recién cargada.
- Menú de navegación abierto.
- Ventana modal visible.
- Formulario con errores.
- Pestañas o acordeones activados.
- Resultados cargados dinámicamente.
- Mensajes de confirmación visibles.
Cuándo utilizar Lighthouse
Lighthouse funciona bien como punto de partida, especialmente al revisar una página por primera vez. También resulta útil para comprobar rápidamente si un cambio ha introducido problemas básicos.
No obstante, cuando necesitamos analizar con mayor profundidad el código afectado o incorporar comprobaciones al proceso de testing, axe suele proporcionar más posibilidades.
axe: accesibilidad orientada al desarrollo y la automatización
axe es un motor de análisis especializado en accesibilidad. Puede utilizarse mediante una extensión del navegador y también integrarse en herramientas de testing automatizado.
Esta flexibilidad lo convierte en una opción especialmente valiosa para equipos frontend.
Mientras que Lighthouse presenta una auditoría general, axe se centra en explicar las infracciones detectadas, los elementos afectados y las posibles formas de corregirlas.
Qué información ofrece axe
Cuando axe encuentra un problema, suele mostrar:
- La regla que se ha incumplido.
- El nivel de impacto estimado.
- Los nodos HTML afectados.
- La razón por la que la implementación puede generar una barrera.
- Los criterios o estándares relacionados.
- Orientaciones para corregir el problema.
Esta información facilita la investigación técnica.
Por ejemplo, si un campo no tiene un nombre accesible, axe puede señalar el elemento concreto y mostrar qué mecanismos podrían utilizarse para asociarlo con su etiqueta.
En lugar de limitarse a indicar que la página tiene un problema, ayuda a localizar dónde se encuentra.
Utilizar axe durante el desarrollo
La extensión axe DevTools permite ejecutar una revisión desde las herramientas para desarrolladores del navegador.
Un buen momento para utilizarla es después de implementar un componente o modificar un flujo interactivo. Por ejemplo:
- Después de crear un formulario.
- Al terminar una ventana modal.
- Tras modificar un menú desplegable.
- Cuando se incorpora un nuevo botón o enlace.
- Al implementar validaciones.
- Después de cambiar colores o estados de foco.
- Antes de abrir una solicitud de cambios.
La herramienta debería ejecutarse en cada estado importante del componente.
Un formulario no debe probarse solamente vacío. También conviene revisarlo con datos válidos, errores, campos deshabilitados, mensajes informativos y estados de carga.
Esta revisión por estados es especialmente importante en aplicaciones construidas con React, Vue, Angular u otros entornos donde la interfaz cambia sin recargar la página.
Integrar axe en pruebas automatizadas
Una de las principales ventajas de axe es que puede incorporarse al sistema de pruebas del proyecto.
Por ejemplo, puede utilizarse junto con herramientas de testing de componentes o pruebas end-to-end para comprobar automáticamente determinadas páginas y estados.
Esto permite detectar regresiones como:
- Un botón que pierde su nombre accesible.
- Una imagen añadida sin alternativa textual.
- Un campo nuevo que no está asociado con una etiqueta.
- Un atributo ARIA incorrecto.
- Un contraste que deja de cumplir el mínimo establecido.
- Una estructura semántica que se rompe después de una refactorización.
La automatización no elimina la necesidad de revisar manualmente, pero reduce la posibilidad de que ciertos errores básicos reaparezcan en cada versión.
Un flujo práctico con axe
Una estrategia razonable podría ser:
- Ejecutar axe manualmente durante el desarrollo.
- Corregir las incidencias críticas antes de abrir una revisión de código.
- Añadir pruebas automáticas para los componentes y recorridos principales.
- Revisar manualmente los resultados que necesitan interpretación.
- Completar la validación con teclado y lector de pantalla.
Este enfoque integra la accesibilidad dentro del trabajo habitual, en lugar de dejarla para una auditoría final.
Limitaciones de axe
axe detecta problemas técnicos, pero tampoco puede evaluar por completo la experiencia.
Puede comprobar que un modal utiliza determinados atributos, pero será necesaria una revisión manual para confirmar que:
- El foco se mueve dentro del modal al abrirlo.
- La navegación queda contenida correctamente.
- El orden de tabulación es lógico.
- La tecla Escape permite cerrar el diálogo cuando corresponde.
- El foco regresa al botón que abrió el modal.
- El contenido anunciado por el lector de pantalla resulta comprensible.
Si estás trabajando con componentes complejos, conviene complementar estas auditorías con una revisión de los patrones para crear componentes UI accesibles.
WAVE: una revisión visual de la estructura
WAVE es una herramienta de evaluación que muestra los resultados directamente sobre la página mediante iconos, avisos y anotaciones.
Puede utilizarse desde una extensión del navegador o mediante su servicio web para analizar páginas públicas.
Su enfoque visual la diferencia de Lighthouse y axe, ya que permite relacionar cada hallazgo con la parte concreta de la interfaz en la que aparece.
Qué muestra WAVE
WAVE organiza la información en varias categorías:
- Errores.
- Alertas.
- Características de accesibilidad.
- Elementos estructurales.
- Uso de ARIA.
- Problemas de contraste.
También permite observar la estructura semántica de la página, incluyendo encabezados, regiones, listas y otros elementos importantes para la navegación asistida.
Esta representación resulta especialmente útil para comprender si el documento mantiene una jerarquía coherente.
Por ejemplo, puede ayudar a detectar:
- Saltos desordenados entre niveles de encabezado.
- Enlaces con textos poco descriptivos.
- Campos sin etiquetas visibles.
- Imágenes con alternativas dudosas.
- Regiones poco claras.
- Elementos ARIA innecesarios.
- Problemas de contraste localizados.
Ventajas de WAVE
WAVE puede ser más accesible para perfiles que no trabajan habitualmente con código.
Diseñadores, responsables de contenido, profesionales de UX y equipos de QA pueden utilizar sus anotaciones para entender cómo está estructurada una página y qué elementos requieren atención.
También resulta útil para revisar aspectos editoriales que no siempre se interpretan correctamente desde un listado técnico.
Por ejemplo, una página puede contener varios enlaces técnicamente válidos, pero todos pueden utilizar expresiones ambiguas como “leer más” o “haz clic aquí”. Si deseas profundizar en este punto, puedes consultar por qué los enlaces accesibles necesitan un texto descriptivo.
Diferencia entre errores y alertas
No todos los avisos de WAVE representan errores confirmados.
Una alerta indica que el elemento necesita revisión humana. El contexto determinará si existe realmente una barrera.
Por ejemplo, un texto alternativo extenso puede ser innecesario para una imagen decorativa, pero estar justificado si la imagen transmite información compleja.
Del mismo modo, un encabezado aparentemente vacío podría ser un error o el resultado de un componente generado dinámicamente que necesita analizarse en otro estado.
La herramienta señala el posible problema, pero la decisión final requiere criterio.
Cuándo utilizar WAVE
WAVE resulta especialmente útil para:
- Observar la jerarquía de encabezados.
- Revisar la estructura semántica.
- Analizar el contenido desde una perspectiva editorial.
- Explicar problemas a perfiles no técnicos.
- Localizar visualmente los elementos afectados.
- Complementar informes orientados al código.
Lighthouse, axe y WAVE: principales diferencias
Las tres herramientas comparten algunas comprobaciones, pero cada una ofrece una perspectiva distinta.
| Herramienta | Enfoque | Principal ventaja | Uso recomendado |
|---|---|---|---|
| Lighthouse | Auditoría general | Rapidez y facilidad de uso | Primera revisión |
| axe | Análisis técnico | Detalle e integración con testing | Desarrollo y automatización |
| WAVE | Evaluación visual | Interpretación directa sobre la interfaz | Revisión estructural y editorial |
No es necesario elegir solamente una.
Una estrategia razonable consiste en utilizar Lighthouse para obtener una visión inicial, axe para investigar y automatizar los problemas técnicos y WAVE para observar la estructura y revisar el contenido visualmente.
Cuando varias herramientas señalan la misma incidencia, es probable que exista una barrera clara. Cuando muestran resultados diferentes, conviene revisar manualmente el elemento antes de decidir qué cambio aplicar.
Cómo combinar Lighthouse, axe y WAVE
Utilizar las tres herramientas sin un proceso definido puede producir muchos informes y pocas mejoras. Para que sus resultados sean útiles, es necesario decidir cuándo se ejecutan, quién revisa las incidencias y cómo se comprueban las correcciones.
Durante el diseño
La accesibilidad empieza antes de escribir código.
En esta fase deberían revisarse cuestiones como:
- El contraste de colores.
- El tamaño y la legibilidad del texto.
- La jerarquía visual.
- Los estados de foco.
- Los mensajes de error.
- La claridad de los botones.
- La dependencia del color para transmitir información.
- El comportamiento de menús, modales y otros componentes.
Las herramientas que analizan una página implementada no pueden corregir una decisión de diseño que ya nace con barreras.
Durante el desarrollo
Cada componente debería revisarse en sus diferentes estados.
En esta fase puede utilizarse:
- Lighthouse para una comprobación rápida.
- axe para localizar errores técnicos.
- WAVE para revisar la estructura.
- Navegación manual con teclado.
- El árbol de accesibilidad del navegador.
También conviene comprobar que los iconos utilizados como acciones tienen un nombre comprensible. En la guía sobre iconos accesibles, aria-hidden y nombres accesibles encontrarás ejemplos para distinguir entre iconos decorativos e interactivos.
Antes de publicar
Antes de lanzar una funcionalidad, deberían revisarse los recorridos más importantes de principio a fin.
Esto puede incluir:
- Iniciar sesión.
- Completar un formulario.
- Realizar una búsqueda.
- Aplicar filtros.
- Añadir un producto a una cesta.
- Confirmar una compra.
- Cambiar preferencias.
- Abrir y cerrar ventanas modales.
- Interpretar mensajes de error.
No basta con analizar páginas estáticas. La accesibilidad también depende de lo que ocurre después de una interacción.
Después de publicar
La accesibilidad requiere mantenimiento.
Una actualización de estilos, un nuevo plugin, un cambio en una plantilla o la incorporación de contenido pueden introducir nuevas barreras.
Por eso, conviene:
- Programar revisiones periódicas.
- Automatizar las reglas básicas.
- Registrar las incidencias.
- Asignar prioridades y responsables.
- Volver a probar cada corrección.
- Incluir la accesibilidad en la definición de terminado.
También es importante desconfiar de las soluciones que prometen resolver todos los problemas automáticamente. Los llamados overlays no sustituyen una implementación correcta ni una auditoría real. Puedes ampliar este tema en el artículo sobre qué son los overlays de accesibilidad y por qué pueden ser un problema.
Pruebas manuales que deben acompañar a las herramientas
Una revisión automática puede encontrar muchos problemas, pero no puede reproducir completamente la experiencia de una persona.
Por eso, Lighthouse, axe y WAVE deben complementarse con pruebas manuales.
Navegación únicamente con teclado
La primera prueba consiste en guardar el ratón e intentar completar las acciones utilizando solamente el teclado.
Durante el recorrido deberías comprobar que:
- El foco es visible.
- El orden de navegación resulta lógico.
- Todos los controles pueden activarse.
- No existen trampas de teclado.
- Los menús y desplegables funcionan correctamente.
- Las ventanas modales pueden cerrarse.
- El foco no salta a lugares inesperados.
Muchos problemas graves aparecen precisamente en esta prueba. En la guía sobre focus visible y navegación por teclado encontrarás una revisión más detallada de estos errores.
Revisión con lector de pantalla
También conviene comprobar los recorridos principales con un lector de pantalla.
El objetivo no consiste solamente en confirmar que el contenido se anuncia. Hay que valorar si la información resulta comprensible y mantiene un orden lógico.
Durante esta prueba puedes revisar:
- El título y las regiones de la página.
- La jerarquía de los encabezados.
- Los nombres de botones y enlaces.
- Las etiquetas de los formularios.
- Los mensajes de error.
- Los cambios de estado.
- El contenido de modales y menús.
- La relación entre instrucciones y controles.
Un formulario puede superar una auditoría automática y seguir siendo confuso si los errores no se anuncian en el momento adecuado.
Ampliación y adaptación del contenido
La interfaz debería continuar siendo utilizable al aumentar el zoom o ampliar el tamaño del texto.
Hay que comprobar si:
- Los contenidos se superponen.
- Los textos quedan cortados.
- Algunos botones desaparecen.
- Los controles dejan de ser visibles.
- Las ventanas modales exceden la pantalla.
- Aparece desplazamiento horizontal innecesario.
- El foco permanece visible.
Esta prueba es especialmente importante en diseños muy ajustados o componentes con alturas fijas.
Mensajes de estado y contenido dinámico
Las herramientas automáticas pueden detectar algunos atributos, pero no siempre confirman que los mensajes se anuncien en el momento correcto.
Cuando una persona envía un formulario, añade un producto o actualiza una preferencia, debería recibir una confirmación comprensible sin perder el contexto.
Para estos casos, puedes revisar cómo implementar notificaciones accesibles con aria-live, role="status" y role="alert".
Errores frecuentes al utilizar herramientas de accesibilidad
Considerar que una puntuación de 100 garantiza la accesibilidad
Una puntuación perfecta indica que no se han encontrado errores dentro de las reglas ejecutadas. No garantiza que la experiencia completa sea accesible.
Corregir avisos sin entender el contexto
Aplicar cambios automáticamente puede introducir nuevos problemas. Antes de añadir atributos o modificar el marcado, es necesario comprender la función del elemento.
Añadir ARIA cuando el HTML nativo es suficiente
Un elemento HTML semántico suele proporcionar significado, comportamiento y compatibilidad sin configuraciones adicionales.
Un <button> correctamente utilizado es preferible a un <div> con role="button", tabindex y varios eventos para intentar reproducir su comportamiento.
Revisar solamente la página inicial
Los errores más importantes suelen aparecer en formularios, filtros, ventanas modales, procesos de compra y estados dinámicos.
Cada recorrido crítico debe analizarse de manera independiente.
Ignorar las alertas que necesitan revisión humana
Las herramientas no siempre pueden clasificar una incidencia como error definitivo. Una alerta no debería descartarse automáticamente; debe revisarse dentro de su contexto.
No volver a probar después de corregir
Toda corrección necesita una validación posterior.
Además de ejecutar nuevamente Lighthouse, axe o WAVE, conviene comprobar manualmente que el cambio ha resuelto la barrera sin introducir otra.
Preguntas frecuentes sobre Lighthouse, axe y WAVE
¿Cuál es la mejor herramienta para revisar la accesibilidad web?
No existe una única herramienta capaz de cubrir todo el proceso.
Lighthouse es adecuada para obtener una visión inicial, axe ofrece un análisis técnico detallado y posibilidades de automatización, mientras que WAVE facilita una revisión visual de la estructura y el contenido.
La mejor estrategia consiste en combinarlas y completar sus resultados con pruebas manuales.
¿Estas herramientas garantizan el cumplimiento de las WCAG?
No. Las herramientas automáticas pueden detectar una parte de los problemas relacionados con las pautas de accesibilidad, pero muchos criterios requieren evaluación humana.
El cumplimiento depende tanto de la implementación técnica como de la experiencia real de uso.
¿Es necesario saber programar para utilizar Lighthouse, axe o WAVE?
No siempre.
Las tres herramientas pueden ejecutarse desde el navegador sin escribir código. Sin embargo, para interpretar algunos resultados y corregir las incidencias técnicas será necesario conocer HTML, CSS, JavaScript, semántica y comportamiento accesible de los componentes.
La accesibilidad mejora cuando las pruebas son continuas
Lighthouse, axe y WAVE son herramientas muy útiles para revisar la accesibilidad web, pero su valor depende de cómo se integran en el proceso.
Ejecutar una auditoría el día anterior a publicar puede encontrar errores, aunque en ese momento quizá sea demasiado tarde para corregir decisiones estructurales.
Un enfoque más efectivo consiste en revisar la accesibilidad desde el diseño, utilizar herramientas automáticas durante el desarrollo, incorporar comprobaciones al sistema de testing y validar manualmente los recorridos principales.
Lighthouse puede ofrecer una primera señal. axe puede ayudar a localizar y prevenir errores técnicos. WAVE puede mostrar cómo está organizada la página. El teclado, el zoom y el lector de pantalla permiten comprobar si la experiencia funciona de verdad.
Las herramientas detectan errores, pero las personas encuentran barreras
La accesibilidad web no consiste en alcanzar una puntuación determinada ni en conseguir que todas las herramientas muestren un indicador verde.
Consiste en reducir los obstáculos que impiden a una persona informarse, comunicarse, estudiar, comprar o completar una tarea digital.
Lighthouse, axe y WAVE hacen visibles muchos problemas y ayudan a trabajar de una forma más consistente. Sin embargo, ninguna herramienta comprende por completo las necesidades, expectativas y dificultades de una persona real.
Por eso, una revisión responsable combina automatización, conocimiento técnico y pruebas humanas.
Una web accesible no es simplemente una web que supera una auditoría. Es una web que permite que más personas puedan utilizarla con autonomía, claridad y confianza.