Tu formulario de contacto funciona cuando lo rellenas con el ratón. ¿Puedes recorrerlo también con el teclado y saber en qué campo estás? Haz esa prueba antes de dar por resuelta su utilización. Sigue la posición activa, recorre los controles y comprueba que puedes salir de las ventanas que se abren.
Es una comprobación funcional concreta, no una auditoría completa de accesibilidad. Utiliza un entorno de prueba si enviar el formulario genera reservas, pedidos o comunicaciones reales.
Empieza sin tocar el ratón y reconoce dónde estás
Abre la página y anota el navegador y la versión del formulario que vas a probar. Pulsa el tabulador y observa qué elemento recibe el foco, es decir, la posición desde la que interactúas con el teclado. Si no puedes reconocerla visualmente, registra esa dificultad sin suponer que estás en el primer campo.
Continúa desde el principio de la página hasta el formulario. La navegación que empieza haciendo clic dentro de un campo puede ocultar un problema anterior: quizá ese campo funcione cuando ya estás dentro, pero no puedas alcanzarlo siguiendo el recorrido habitual.
Haz la prueba con datos ficticios identificados y evita incluir información de clientes. Antes de activar un botón final, confirma qué ocurrirá. No necesitas provocar una venta ni enviar mensajes reales para describir que el teclado no alcanza un control.
Recorre los campos en un orden comprensible
La guía del Observatorio de Accesibilidad recomienda comprobar que se puede acceder a los elementos de interacción, utilizarlos con teclado y recorrerlos en el orden correcto. La explicación está en la guía de validación, apartado sobre uso del teclado.
Observa si la secuencia permite entender el formulario: campo, instrucciones, opciones y acción correspondiente. Si el foco salta a una zona inesperada o pasa por controles que parecen ocultos, describe el recorrido observado en lugar de limitarte a escribir «la página es incómoda».
Comprueba también el recorrido inverso con la combinación habitual de mayúsculas y tabulador. Volver al campo anterior debe formar parte de la prueba, especialmente si una persona necesita corregir un dato. Anota la tecla utilizada y el resultado en tu entorno; no atribuyas la misma conducta a todos los navegadores sin probarlos.
Prueba los botones y las ventanas que abre el formulario
También contempla la comprobación de que el contenido no genere trampas para el foco del teclado. Una ventana de ayuda o de confirmación merece su propio recorrido: entrar en ella no basta si después no puedes volver al formulario.
| Prueba | Qué observar | Qué registrar si falla |
|---|---|---|
| Llegar a un campo | Posición reconocible y orden comprensible | Elemento desde el que se produce el salto |
| Usar un control | Que pueda activarse desde el teclado | Tecla y respuesta observada |
| Entrar y salir de una ventana | Que puedas continuar el recorrido | Punto donde quedas bloqueado |
Si aparece un error al rellenar un campo, comprueba dónde queda la posición activa y si puedes encontrar la explicación. Detén la prueba antes de una operación real cuando no exista un entorno seguro de ensayo. Esa limitación debe quedar anotada en el resultado.
Organiza con Alexis la incidencia del formulario que debes trasladar a tu proveedor web. Prepara la dirección de la página y los pasos que llevan al control que no puedes utilizar.
El botón se ve pero el teclado no llega
Supuesto ilustrativo: el responsable de un negocio rellena su formulario con el ratón y alcanza el botón de envío. Al repetir el recorrido con teclado, la posición salta desde el último campo hacia el pie de página y el botón queda fuera del recorrido observado.
En vez de dar el formulario por correcto porque el botón existe, registra el campo de salida, la tecla utilizada y el siguiente elemento que recibe el foco. Si puedes repetir el fallo en el mismo entorno, entrega esa secuencia al proveedor para que revise el componente.
La conclusión es concreta: ese botón no se ha podido alcanzar en la prueba descrita. No se afirma que toda la web incumpla una norma ni que el resto de controles funcionen. El caso es hipotético y muestra cómo convertir una dificultad en una incidencia reproducible.
Describe el fallo para que pueda repetirse
Escribe qué esperabas que ocurriera y qué ocurrió realmente. Añade el punto de inicio, la secuencia de teclas y, cuando ayude, una grabación sin datos personales. Una captura del botón aislado no explica cómo llegó hasta allí la persona que hacía la prueba.
Cuando el proveedor comunique una corrección, repite el mismo recorrido en la versión entregada. Comprueba el control afectado y la continuación del formulario: resolver un salto no acredita automáticamente el funcionamiento de todo el proceso.
Al organizar proveedores y decisiones de una pequeña empresa, define qué revisión has encargado y qué resultado esperas. Esta prueba ayuda a preparar el encargo técnico; no determina el régimen legal de accesibilidad aplicable a tu negocio.
Prepara con Alexis los pasos del fallo y el alcance de la revisión que necesitas encargar. Un problema descrito con precisión facilita pedir una corrección que después puedas comprobar.
