Un servicio de pruebas de accesibilidad web evalúa si las personas pueden completar tareas en un sitio o aplicación, incluidas quienes navegan con teclado, lector de pantalla o ampliación. El resultado útil no es una puntuación aislada: es un conjunto de hallazgos reproducibles, vinculados a criterios y priorizados para corregirlos.
Qué se evalúa y cómo se define el alcance
Antes de probar, se acuerdan objetivos, tecnologías, flujos y una muestra de páginas. Una tienda puede priorizar búsqueda, ficha, carrito y pago; una universidad, matrícula, documentos y aula virtual. También se fijan navegadores, dispositivos, idiomas, nivel de WCAG y estados especiales, como errores de formulario o sesiones iniciadas. Una muestra acotada no equivale a declarar accesible todo el sitio.
Pruebas automáticas, manuales y con tecnologías de asistencia
Las herramientas automáticas ayudan a encontrar problemas detectables por reglas, como ciertos errores de marcado o contraste. La evaluación manual comprueba la secuencia de foco, operación por teclado, nombres de controles, instrucciones, mensajes de error, lectura y comprensión. Según el alcance, se usan lectores de pantalla y otras tecnologías de asistencia para verificar flujos reales. La combinación importa porque una herramienta no puede juzgar por sí sola si un texto alternativo describe correctamente la función de una imagen o si una tarea resulta comprensible.
El marco de referencia puede ser WCAG 2.2; la guía de evaluación de WAI explica cómo combinar técnicas y delimitar una revisión. Si se incluyen sesiones con personas usuarias, deben planificarse perfiles, tareas, consentimiento y observación; no se reemplazan por una simulación automática.
Qué contiene un informe útil
- Alcance y muestra: páginas, flujos, versiones y condiciones de prueba.
- Cada barrera con ubicación, pasos para reproducirla, comportamiento observado y esperado.
- Criterio WCAG relacionado, impacto para la persona y prioridad de corrección.
- Recomendación técnica y evidencia suficiente para verificar la solución.
- Limitaciones y elementos que requieren una revisión posterior.
Ejemplo ilustrativo de hallazgo
Ejemplo ficticio, no corresponde a un proyecto real: al enviar un formulario vacío, los campos obligatorios cambian de color, pero no aparece un mensaje que identifique el error. Una persona que no percibe ese cambio puede no saber qué corregir. La recomendación es mostrar un mensaje textual junto al campo, asociarlo de forma programática y llevar el foco o comunicar un resumen de errores. La revisión posterior debe comprobar el flujo completo, no solo la presencia del mensaje.
Cómo solicitar y cerrar las pruebas
Para cotizar, conviene reunir URL, tipos de usuario, flujos críticos, tecnología, documentos asociados y fecha deseada. La propuesta debe aclarar muestra, entregables, rondas de revisión y responsabilidades de corrección. Tras remediar, un re-test comprueba las barreras corregidas; una auditoría no garantiza por sí misma conformidad futura.
Solicitar una auditoría de accesibilidad web permite definir un alcance técnico acorde al producto y sus usuarios.
