Cómo convertir la accesibilidad por teclado en una prueba web

Una revisión web debe comprobar si alguien puede completar una tarea importante utilizando el teclado. Una pantalla atractiva y un clic exitoso no responden esa pregunta. El cliente puede llegar a un formulario y perder su ubicación, quedarse dentro de un diálogo o descubrir que una acción solo aparece al pasar el ratón.

Convierte un recorrido del negocio en una prueba de aceptación: encontrar un servicio, abrir su formulario, corregir un error y enviar una solicitud identificada como prueba. El resultado debe registrar comportamientos observables y defectos que otra persona pueda reproducir.

Elige una tarea y prepara el entorno

Selecciona un recorrido importante para clientes o empleados. Utiliza un entorno de pruebas si el envío genera trabajo o mensajes. Anota navegador, sistema operativo, página y versión evaluada. Confirma que el navegador esté configurado para recorrer con el teclado todos los controles pertinentes.

Los principios de accesibilidad del W3C explican que las funciones deben poder utilizarse con teclado y que el foco no debe quedar atrapado. Aplica esos principios a la tarea completa: menús, errores, verificaciones y confirmación.

Aparta el ratón durante el ejercicio. Si necesitas usarlo para salir de un componente, registra primero el fallo. Un rescate inconsciente con el ratón puede ocultar precisamente el obstáculo que la prueba debía revelar.

Sigue el foco durante todo el recorrido

Utiliza Tab y Mayús+Tab para avanzar y retroceder entre controles habituales. Observa qué elemento recibe el foco y si la secuencia sigue siendo comprensible. Deberías poder responder: “¿Dónde estoy y qué ocurrirá si activo este elemento?”.

La explicación de Foco visible de WCAG describe la necesidad de un indicador visible del foco de teclado. Registra dónde desaparece o queda oculto detrás de otro elemento. Si añades una captura, identifica el control y el paso utilizado para llegar a él.

No supongas que todos los componentes personalizados utilizan Tab para cada movimiento interno. Un calendario o un menú puede emplear flechas según su patrón de interacción. Comprueba las instrucciones y el comportamiento previsto. Un atajo oculto o inconsistente necesita investigación, no adivinación.

Prueba los diálogos y la corrección de errores

Si el formulario se abre en una ventana modal, comprueba dónde comienza el foco, cómo se recorren sus controles y cómo se sale. El patrón de diálogo modal del W3C describe el recorrido del foco dentro del diálogo, su cierre con Escape y el retorno apropiado del foco al cerrarlo.

Para el recorrido hipotético de consulta, ejecuta esta secuencia:

1. Llega al enlace del servicio y actívalo con el teclado.
2. Abre el diálogo de consulta e identifica el control que tiene el foco.
3. Recorre todos los campos y acciones; después vuelve en sentido contrario.
4. Envía con un campo obligatorio vacío. Localiza el error, corrígelo y comprueba que los valores introducidos se conserven como corresponde.
5. Cierra el diálogo y verifica adónde vuelve el foco. Ábrelo de nuevo y realiza el envío de prueba permitido.
6. Encuentra la confirmación y la siguiente acción útil sin mover el ratón.

Revisa también una página larga con cabecera fija o aviso superpuesto. Un control puede recibir el foco técnicamente y resultar difícil de ver. Prueba las distribuciones y niveles de ampliación incluidos realmente en tu revisión, y deja constancia de esas condiciones.

Redacta un resultado que pueda verificarse

Un reporte útil diría: “Al abrir Solicitar información y pulsar Tab tres veces, el foco llega a un control invisible; Enter cierra el diálogo”. Añade el entorno y el comportamiento esperado. “La accesibilidad falla” ofrece muy poca información para repetir la prueba.

Marca cada tarea como completada, bloqueada o completada con un obstáculo documentado. Conserva el paso exacto, el control afectado, una captura cuando ayude y el responsable. Después de corregirlo, el revisor debe repetir la misma secuencia.

Completar una tarea con teclado no equivale a una evaluación integral de accesibilidad. El uso con lectores de pantalla, alternativas de texto, contraste, ampliación y otros requisitos necesitan sus propias comprobaciones. Este ejercicio aporta evidencia concreta sobre una parte importante de la experiencia.

Incluye la prueba en los cambios futuros

Repite el recorrido cuando cambien la navegación, formularios, diálogos, avisos o componentes externos. Guarda la tarea y su comportamiento esperado junto a los criterios de aceptación para que otra persona pueda ensayarla sin reconstruir las instrucciones.

El escenario descrito es una prueba propuesta, no una certificación ni un resultado de clientes. Su utilidad está en la conversación práctica entre negocio, diseño y desarrollo sobre si una persona puede terminar la tarea.

Contacta con Dynelink para definir casos de aceptación por teclado para las acciones que tus clientes y empleados necesitan completar.