Cómo evaluar una auditoría de accesibilidad web

¿Qué debería medir después de contratar a un profesional independiente para una auditoría de accesibilidad web?

Una auditoría de accesibilidad web resulta útil cuando ayuda a tu equipo a detectar barreras y decidir qué hacer a continuación. Un informe con una larga lista de errores puede parecer exhaustivo, pero quizá no deje claro a los desarrolladores dónde se produce un problema, a quién afecta o cómo comprobar que se ha corregido.

Después de contratar a un profesional independiente, evalúa la calidad de las pruebas y las decisiones que permiten tomar, no solo el número de problemas detectados. Para saber cómo evaluar una auditoría de accesibilidad web, comprueba si se analizaron las páginas y tareas acordadas, si tu equipo puede reproducir cada hallazgo y qué problemas siguen sin resolverse. Así obtendrás una respuesta más fiable a la pregunta «¿qué debería medir después de contratar a un profesional independiente para una auditoría de accesibilidad web?» que con una sola puntuación o una afirmación general de cumplimiento.

1. Define qué significa «accesible» para este trabajo

Una auditoría de accesibilidad tiene unos límites. Puede abarcar cinco páginas clave, un proceso de pago o un conjunto de componentes reutilizables, en lugar de todas las páginas e interacciones de un sitio web grande. Antes de empezar, deja por escrito exactamente qué se incluye. Si el profesional revisa la página de producto y el proceso de pago, pero no el área de cuenta, el informe debe indicarlo claramente.

Acuerda qué normas o pautas utilizará el profesional y pregunta cómo se relacionan con el trabajo que necesitas. Por ejemplo, mencionar las WCAG no basta por sí solo: el informe debe señalar los criterios aplicables y explicar qué se probó. Especifica también qué tecnologías de asistencia y configuraciones de navegación se incluirán en la auditoría. La combinación exacta dependerá de tu público y del proyecto; deja por escrito la configuración acordada en vez de dar por hecho que se probarán todas las combinaciones posibles.

Enumera las tareas que realizará el usuario y que se analizarán en la auditoría. Podrían incluir buscar las condiciones de entrega, enviar un formulario de contacto o completar una compra. Una web puede tener plantillas de página que parecen accesibles y, aun así, impedir que alguien complete un paso concreto; por ejemplo, si no se anuncia un mensaje de validación después de enviar un formulario.

Procura que la definición del alcance sea breve y precisa. Debe indicar qué se examinó, qué se excluyó y qué no permite concluir la auditoría. Así evitarás que la revisión de algunas páginas se confunda con una garantía sobre todo el sitio web.

2. Asegúrate de que las pruebas se puedan reproducir

Es mucho más fácil actuar ante un hallazgo cuando otra persona puede reproducirlo. Cada problema notificado debería incluir el nombre de la página o el componente, una ubicación clara y los pasos necesarios para encontrar la barrera. Para entender cómo comprobar errores de accesibilidad web, fíjate en la precisión de esos pasos: «El menú no es accesible» es demasiado impreciso; «pulsa Tab desde el logotipo hasta el botón del menú y luego Intro: el submenú se abre visualmente, pero el foco permanece en el botón» ofrece al desarrollador algo concreto que investigar.

El informe también debe indicar el navegador y la tecnología de asistencia pertinentes. Si el problema apareció con una combinación concreta de lector de pantalla y navegador, tu equipo necesitará esos datos para comprobar el mismo comportamiento. Las pruebas del profesional pueden incluir una grabación breve, una captura de pantalla o una descripción escrita del comportamiento esperado y del observado. Una captura por sí sola no explicará un problema de foco del teclado, así que las pruebas deben corresponderse con el problema.

Antes de dar el informe por bueno, intenta reproducir algunos hallazgos por tu cuenta o con un desarrollador. Si forman parte del alcance, elige un problema relacionado con el uso del teclado, otro con un formulario y otro con la estructura de la página. Si tu equipo no puede seguir los pasos, pide al profesional que los aclare mientras todavía tiene fresco el contexto de la auditoría.

Este registro también será importante después de la auditoría. Cuando un desarrollador modifique un componente compartido, los pasos originales para reproducir el problema ayudarán a confirmar si el cambio eliminó la barrera o solo modificó su aspecto.

3. Contrasta los hallazgos con los recorridos reales de los usuarios

Prueba las tareas que la gente realmente necesita completar, no solo elementos aislados de la interfaz. Un recorrido puede revelar una serie de pequeños obstáculos: un botón de menú con un nombre poco claro, un formulario que borra los datos introducidos tras un error y un mensaje de confirmación que no se anuncia. Cada problema puede parecer menor por separado, pero juntos pueden impedir que alguien complete una solicitud.

Recorre algunas de las tareas prioritarias usando únicamente el teclado y, después, utiliza la tecnología de asistencia pertinente si está incluida en el alcance acordado. En un formulario de contacto, comprueba si puedes llegar a todos los campos, entender qué información es obligatoria, identificar los errores, corregirlos y confirmar el envío. Anota exactamente en qué punto se interrumpe el recorrido y si existe alguna alternativa. Una solución alternativa es un dato útil, pero no elimina la barrera.

Incluye también el resultado de la tarea en tu evaluación. ¿Pudo el usuario encontrar la información que buscaba? ¿Pudo enviar el formulario sin ayuda? ¿Pudo saber si la compra se había completado? Estas preguntas conectan los hallazgos técnicos con la finalidad de la página, sin dar a entender que una auditoría breve representa la experiencia de todos los usuarios.

Si tu sitio web combina trabajos de accesibilidad con otros proyectos independientes, deja claras las responsabilidades. Puede que un desarrollador implemente una corrección y que el profesional independiente la verifique; acuerda quién registrará el resultado antes de empezar. En 24freelance.pro, puedes revisar el perfil de IT IT IT IT IT IT como punto de partida para hablar de los requisitos técnicos del proyecto.

4. Evalúa si tu equipo puede aprovechar los hallazgos

Cada hallazgo debe explicar cuál es la barrera, a qué personas o interacciones afecta, dónde aparece y por qué el profesional le asignó ese nivel de gravedad. La explicación debería ayudar a tu equipo a establecer prioridades, sin dar por sentado que una etiqueta de gravedad se explica por sí sola. Por ejemplo, un bloqueo del teclado durante el proceso de pago tiene consecuencias distintas a una inconsistencia en el nivel de los encabezados de una página que se visita poco.

Busca también recomendaciones prácticas. Un informe útil podría sugerir que el desarrollador haga que la etiqueta visible sea el nombre accesible del control y explicar cómo volver a probar el resultado. La recomendación debe ser lo bastante concreta como para orientar la investigación, pero sin imponer un cambio de código que quizá no encaje con la arquitectura de tu sitio.

Desconfía si los resultados de una herramienta automática se presentan como si fueran la auditoría completa. Las herramientas automatizadas pueden detectar ciertos patrones, pero no determinan si es posible completar una tarea con el teclado ni si las instrucciones tienen sentido en su contexto. Pregunta qué hallazgos revisó una persona y cómo comprobó el comportamiento de cara al usuario.

Los hallazgos imprecisos generan intercambios innecesarios. Si un ticket solo dice «corregir el contraste», pregunta qué texto o componente está afectado, qué se observó y qué pruebas respaldan la recomendación. Un hallazgo claro evita que el desarrollador tenga que hacer conjeturas y permite a tu equipo comprobar el cambio más adelante.

5. Mide la corrección por los problemas verificados, no por el estado del ticket

Que un ticket figure como «hecho» no demuestra que se haya resuelto un problema de accesibilidad. Para cada corrección acordada, registra si se implementó y se volvió a probar siguiendo los pasos originales para reproducir el problema. Después, comprueba que haya eliminado la barrera original sin crear otra nueva.

Por ejemplo, un desarrollador podría hacer que un menú personalizado responda al teclado, pero dejar el foco en un lugar inesperado cuando se cierra. En una comprobación visual rápida, el problema original podría parecer resuelto, aunque el recorrido siga fallando para quien usa el teclado. Volver a probar toda la interacción, y no solo la línea de código modificada, puede revelar la diferencia.

Usa dos estados sencillos en tu sistema de seguimiento: correcciones verificadas y elementos pendientes de revisión. Añade quién volvió a probar el cambio y qué pasos o pruebas utilizó. Si el profesional independiente se encarga de verificarlo, déjalo indicado expresamente; si volverá a probarlo tu equipo interno, asigna a alguien para evitar que la comprobación se pierda en un traspaso de responsabilidades.

No combines una corrección con un rediseño no relacionado, a menos que puedas identificar con claridad qué ha cambiado. Cuando se implementan varias actualizaciones a la vez, una breve nota que vincule cada problema con la versión o el componente correspondiente facilitará las comprobaciones posteriores.

6. Registra las excepciones y los riesgos pendientes

Es posible que algunos problemas se pospongan porque se está reconstruyendo una función, interviene una herramienta de terceros o el equipo no dispone de una alternativa adecuada. Registra cada excepción junto con la persona responsable, el motivo, la solución temporal y la fecha de revisión. «Pendiente del proveedor» no es un registro completo si nadie se encarga de hacer el seguimiento.

El contenido de terceros merece un registro específico. Si una herramienta de reservas integrada impide navegar con el teclado, anota dónde aparece y qué pueden hacer los usuarios en su lugar, si existe una alternativa real. Puede que el profesional independiente no controle el código del proveedor, pero la barrera sigue afectando a quienes visitan tu sitio web.

Distingue entre «no probado», «sin corregir» y «fuera del alcance de este trabajo». No significan lo mismo. Si una página quedó fuera de la auditoría, no la marques como aprobada; si un hallazgo se ha aplazado, no lo cierres solo porque el equipo no pueda implementar el cambio hoy.

Revisa las excepciones en una fecha concreta o al alcanzar un hito definido del proyecto. Una solución temporal puede quedar desactualizada cuando cambian un formulario, un proveedor o el diseño de una página. Asignar una persona responsable y una fecha de revisión da al equipo un motivo para comprobar si ha cambiado el riesgo pendiente.

7. Veredicto: evalúa la auditoría por su ayuda a la hora de tomar decisiones más seguras

Una auditoría de accesibilidad útil proporciona a tu equipo pruebas que pueda reproducir, hallazgos sobre los que pueda actuar y un resumen claro de lo que sigue sin probarse o resolverse. No debería dar a entender que una revisión limitada demuestra que todo el sitio web es accesible. En la práctica, lo importante es si la auditoría te ayuda a decidir qué corregir, cómo verificar la corrección y quién se hará cargo de los problemas pendientes.

Antes de aceptar el trabajo, comprueba que el alcance coincida con lo acordado, prueba algunos pasos para reproducir los problemas y confirma que los elementos aplazados tengan responsables y fechas de revisión. Para decidir qué medir después de una auditoría de accesibilidad, registra qué hallazgos se corrigieron y verificaron, cuáles siguen pendientes y qué riesgos quedaron fuera del alcance. Estas comprobaciones llevan menos tiempo que volver a abrir un informe impreciso meses después, cuando quizá quien realizó la auditoría ya no recuerde cómo se manifestaba el problema.