Las pruebas de accesibilidad son un tipo de prueba de software que comprueba si una aplicación o un sitio web puede ser usado por personas con discapacidades visuales, auditivas, motoras o cognitivas. Su objetivo es verificar que el producto cumpla estándares como las Pautas de Accesibilidad para el Contenido Web (WCAG) y, sobre todo, que funcione en la práctica para quien lo usa.
Los datos muestran que la mayoría de los sitios todavía falla en lo básico. En este artículo verás qué se evalúa, qué métodos combinar, cómo ordenar el proceso y qué errores evitar para que la accesibilidad deje de ser una revisión de último minuto.
¿Qué son las pruebas de accesibilidad?
Se trata de evaluar un producto digital para confirmar que personas con discapacidad visual, auditiva, motora o cognitiva pueden percibirlo, navegarlo e interactuar con él. La referencia técnica más extendida son las WCAG, un estándar internacional que define criterios verificables, como el contraste mínimo del texto o la posibilidad de operar todo con teclado.
La evaluación tiene dos caras. En la parte técnica se revisa que el HTML esté bien construido, que las imágenes tengan texto alternativo y que los elementos interactivos puedan recorrerse con el teclado. En la parte funcional se simula o se observa la experiencia real de una persona usuaria para comprobar que la información se transmite con claridad.
Piensa en una tienda en línea. Una persona con discapacidad visual que usa un lector de pantalla necesita que cada foto de producto describa el artículo, que los campos del formulario tengan etiquetas claras y que el menú se maneje sin ratón. Además, el texto debe contrastar lo suficiente con el fondo para quien tiene daltonismo o baja visión.
Lo valioso es que los beneficios no se quedan en un solo grupo. Los subtítulos ayudan a quien ve un video sin sonido, una navegación clara ayuda a todo el mundo y el texto redimensionable favorece a personas mayores o a quien usa el móvil bajo el sol. La accesibilidad es, en el fondo, una forma rigurosa de mejorar la experiencia de usuario.
16%
de la población mundial, unos 1.300 millones de personas, vive con una discapacidad significativa según la Organización Mundial de la Salud.
Fuente: OMS, Global report on health equity for persons with disabilities, 2022
Esa cifra explica por qué ignorar la accesibilidad equivale a dejar fuera a una parte enorme de tu audiencia, con el costo comercial y legal que eso implica.
¿Por qué fallan tantos sitios en las pruebas de accesibilidad?
Porque casi siempre se revisan tarde. Cuando el diseño y el código ya están cerrados, corregir el contraste de una paleta o reestructurar los formularios cuesta mucho más que haberlo previsto desde el inicio. La accesibilidad suele quedar como un pendiente de la fase final, justo cuando no hay tiempo.
También influye la falsa sensación de seguridad que dan las herramientas automáticas. Un reporte en verde se interpreta como cumplimiento, cuando en realidad solo cubre lo que una máquina puede medir. El análisis anual de WebAIM sobre un millón de páginas de inicio sigue encontrando fallos detectables en la gran mayoría.
94,8%
de las páginas de inicio analizadas tenían fallos WCAG 2 detectables automáticamente; el más frecuente fue el texto con bajo contraste.
Fuente: WebAIM, The WebAIM Million, 2025
Si ese es el estado de los errores que una herramienta sí puede ver, imagina los que pasan desapercibidos sin revisión manual. Por eso conviene entender qué se mide antes de elegir métodos.
¿Qué componentes evalúan las pruebas de accesibilidad?
Las WCAG se agrupan en cuatro principios que sirven como lista de comprobación mental. Un producto accesible es perceptible, operable, comprensible y robusto; si falla uno solo, hay personas que quedan fuera.
Antes del esquema conviene tener presente que estos principios no son capas independientes. Un botón puede ser operable con teclado y aun así resultar imperceptible si su texto tiene contraste insuficiente, de modo que las revisiones se cruzan constantemente.
Los cuatro principios que se evalúan
Perceptible
La información llega por más de un canal: texto alternativo, subtítulos, contraste suficiente.
Operable
Todo funciona con teclado, con foco visible y sin trampas de navegación.
Comprensible
Lenguaje claro, interfaz predecible y mensajes de error que ayudan a corregir.
Robusto
El código es estándar y se interpreta bien en navegadores y tecnologías de apoyo.
Perceptible significa que nadie depende de un único sentido: las imágenes llevan texto alternativo, el audio tiene transcripción, el video lleva subtítulos y el contenido se puede adaptar (por ejemplo, con encabezados y listas bien marcados) sin perder significado. También entra aquí el contraste y la posibilidad de ampliar el texto.
Operable se centra en la interacción. Botones, enlaces y campos deben activarse con el teclado, con un foco visible que indique dónde estás, y con ayudas de navegación como encabezados, puntos de referencia y migas de pan. Un error típico es un menú desplegable que solo se abre al pasar el ratón.
Comprensible exige lenguaje simple, abreviaturas explicadas y comportamientos predecibles: nada de cambios bruscos de contexto al seleccionar una opción. Los formularios con etiquetas claras y mensajes de error útiles pertenecen a este principio.
Robusto asegura que el contenido se interprete bien en distintos navegadores y tecnologías de apoyo. Usar HTML y CSS estándar, validar el código y probar con varias combinaciones de navegador y lector de pantalla evita que una actualización rompa la experiencia de quien depende de ellas.
Métodos de pruebas de accesibilidad con ejemplos
Ningún método sirve por sí solo. Las herramientas automáticas dan velocidad, la revisión manual aporta criterio y las pruebas con personas aportan realidad. La combinación es lo que produce resultados confiables, y por eso conviene conocer qué detecta cada una.
Herramientas automáticas
Escanean la página en segundos y señalan problemas repetitivos, como imágenes sin texto alternativo, jerarquía de encabezados rota o contraste insuficiente. Axe se integra en el navegador, WAVE marca los fallos directamente sobre la página y Lighthouse, incluido en las herramientas de desarrollo de Chrome, puntúa la accesibilidad junto con el rendimiento.
57%
de los problemas de accesibilidad fueron detectados por pruebas automáticas en un análisis de unas 2.000 auditorías y más de 13.000 páginas.
Fuente: Deque Systems, 2021 (estudio del propio proveedor de axe)
El dato, publicado por un fabricante de herramientas, sirve como orden de magnitud: la automatización cubre algo más de la mitad, y el resto depende de personas. Úsala como primer filtro, nunca como veredicto final.
Revisión manual
Una persona evaluadora interactúa con el producto y juzga aspectos que un script no puede, como si las instrucciones son claras o si el orden de tabulación tiene sentido. Un ejemplo sencillo es recorrer toda la página solo con el teclado y anotar dónde se pierde el foco.
Pruebas con lectores de pantalla
Los lectores de pantalla convierten el texto en voz o braille. Con NVDA o JAWS se comprueba que las imágenes se describan bien, que los encabezados estructuren el contenido y que botones y enlaces se anuncien con un nombre comprensible. Escuchar tu propia página es una experiencia reveladora.
Pruebas de contraste y de teclado
Con una herramienta como Colour Contrast Analyser se verifica que la relación de contraste cumpla los umbrales WCAG; si no llega, se oscurece el texto o se aclara el fondo. En la navegación por teclado se usa Tab para avanzar y Enter o Espacio para activar, comprobando que menús, modales y formularios funcionen sin ratón.
Pruebas con personas con discapacidad
Es el método que más enseña. Una sesión con una persona con movilidad reducida que rellena un formulario con un dispositivo de entrada alternativo revela problemas de tamaño de objetivos táctiles o de orden de navegación que ninguna otra técnica muestra. Estas sesiones siguen la misma lógica de las pruebas de usabilidad, con participantes que representen a tus usuarios reales.
Si necesitas organizar entrevistas y sesiones moderadas o no moderadas en video, QuestionPro UX permite reclutar participantes de un panel y analizar sus respuestas, aunque conviene que definas tú los criterios de perfil que necesitas para cada estudio.
| Método | Qué detecta bien | Limitación | Cuándo usarlo |
|---|---|---|---|
| Automático | Contraste, alt faltante, estructura de encabezados | Cubre solo parte de los problemas | En cada compilación |
| Manual con teclado | Foco perdido, orden ilógico, trampas | Depende del criterio de quien evalúa | En cada nueva pantalla |
| Lector de pantalla | Nombres de botones, descripciones, estructura | Requiere práctica con la herramienta | Antes de cada lanzamiento |
| Con personas usuarias | Barreras reales de uso | Más tiempo y coordinación | Cada trimestre o ante cambios grandes |
¿Cómo hacer pruebas de accesibilidad paso a paso?
Un proceso estable evita que la accesibilidad dependa del entusiasmo de una persona. La idea es repetir un ciclo corto que cualquier equipo pueda sostener, desde el diseño hasta el mantenimiento.
- Define el estándar objetivo (por ejemplo, WCAG 2.1 nivel AA) y compártelo con diseño, desarrollo y contenido.
- Revisa los prototipos antes de programar: contraste, tamaños, orden de lectura y etiquetas.
- Ejecuta herramientas automáticas en cada compilación para atrapar errores repetitivos cuanto antes.
- Haz revisión manual con teclado y lector de pantalla en los flujos críticos, como registro, búsqueda y pago.
- Organiza sesiones con personas con discapacidad y registra lo que observas.
- Prioriza por impacto, corrige y vuelve a probar.
El orden importa: cuanto antes se detecta un problema, menos cuesta resolverlo. Un contraste insuficiente corregido en el prototipo es un cambio de color; descubierto en producción, puede implicar rehacer componentes completos.
Los flujos críticos merecen más atención porque son donde una barrera se convierte en pérdida. Si una persona no puede completar un pago con teclado, no hay conversión posible, y si no logra darse de alta, nunca verá el resto del producto. Conecta estas revisiones con tu plan de pruebas de usabilidad para no duplicar esfuerzos.
Buenas prácticas en las pruebas de accesibilidad
Las prácticas que más resultado dan son las que vuelven la accesibilidad un hábito del equipo y no un proyecto aislado. Se resumen en seis ideas que se refuerzan entre sí.
- Prueba pronto y con frecuencia: lo que se revisa en cada ciclo no se acumula como deuda.
- Documenta cada hallazgo, la solución aplicada y la retroalimentación recibida, por ejemplo en tu herramienta de gestión de proyectos, para que nadie vuelva a descubrir el mismo problema.
- Capacita a diseñadores, desarrolladores y redactores con talleres breves y guías prácticas.
- Combina siempre automático, manual y pruebas con personas.
- Publica una declaración de accesibilidad con un canal de contacto, para que cualquier persona pueda reportar una barrera y tú puedas atenderla pronto.
- Revisa de forma periódica, porque los estándares y las tecnologías cambian y cada nueva función puede introducir errores.
Estas prácticas funcionan mejor cuando alguien es responsable de ellas. Asignar un dueño de accesibilidad, aunque sea a tiempo parcial, mantiene viva la agenda y facilita medir el progreso de una revisión a la siguiente.
La declaración de accesibilidad, en particular, es una señal de compromiso y una fuente de datos valiosa: los reportes de quienes encuentran barreras suelen apuntar a problemas que ni la auditoría más completa había visto.
Ejemplos de pruebas de accesibilidad por tipo de producto
En el comercio electrónico, la prueba típica verifica que cada producto tenga descripción en la imagen, que el carrito y el pago se completen con teclado y que los mensajes de error indiquen qué corregir. Un fallo aquí se traduce directamente en ventas perdidas.
En un sitio de contenido o medios, el foco está en la jerarquía de encabezados, los subtítulos de video y la legibilidad del texto con distintos tamaños. Un lector de pantalla debería poder saltar entre secciones sin recorrer toda la página.
En aplicaciones móviles se prueba el tamaño de los objetivos táctiles, la compatibilidad con los lectores de pantalla del sistema y el comportamiento al girar el dispositivo o ampliar la fuente. Para decidir qué dispositivos priorizar, apóyate en tus datos de uso y en herramientas de investigación UX.
Conclusión
Las pruebas de accesibilidad no son un trámite de cumplimiento, sino una manera de asegurar que tu producto realmente se puede usar. Combinar herramientas automáticas, revisión manual y sesiones con personas usuarias cubre los huecos de cada método y te da una imagen fiel.
Empieza por un flujo crítico, revisa teclado, contraste y lector de pantalla, corrige lo que encuentres y repite en cada ciclo. Si quieres complementar con investigación cualitativa, conoce la solución de UX de QuestionPro.
Preguntas frecuentes sobre las pruebas de accesibilidad
Es una evaluación que comprueba si personas con discapacidades visuales, auditivas, motoras o cognitivas pueden usar un sitio o una aplicación. Se basa en estándares como las WCAG y combina herramientas automáticas, revisión manual y sesiones con usuarios reales.
Las más comunes son Axe, WAVE y Lighthouse para el análisis automático, Colour Contrast Analyser para el contraste, y los lectores de pantalla NVDA y JAWS para la revisión manual. Ninguna sustituye por completo a las pruebas con personas.
No. Un estudio de Deque estimó que las pruebas automáticas detectan alrededor del 57% de los problemas, por lo que el resto exige revisión manual y pruebas con usuarios. Úsalas como primer filtro, no como garantía de cumplimiento.
Desde el diseño de los prototipos y en cada ciclo de desarrollo. Detectar un problema temprano cuesta mucho menos que corregirlo después del lanzamiento, y repetir las revisiones evita que nuevas funciones introduzcan barreras.
Las de accesibilidad verifican que personas con discapacidad puedan usar el producto y que cumpla estándares técnicos; las de usabilidad miden facilidad y satisfacción para el público en general. Se complementan y comparten técnicas, como observar a usuarios reales.
