QA de accesibilidad web: cómo probar teclado y formularios

QA de accesibilidad web: cómo probar teclado y formularios

Un formulario de registro puede funcionar correctamente para una persona que utiliza mouse y aun así presentar barreras importantes para otras. Por ejemplo, un usuario puede no encontrar el foco al presionar Tab, no saber qué campo contiene un error o perder el contexto después de que la página muestra un mensaje de validación.

Para un equipo de QA, probar accesibilidad no significa únicamente ejecutar una herramienta automática. También implica interactuar con la interfaz de forma manual, observar el comportamiento del foco, verificar la relación entre etiquetas y campos y registrar evidencia que permita reproducir cada problema.

En esta guía encontrarás un flujo práctico para revisar un formulario de registro o checkout sin utilizar un framework ni depender exclusivamente de automatización.

Qué debe comprobar un QA en un formulario accesible

Una prueba básica de accesibilidad debe responder preguntas concretas:

• ¿Es posible completar todo el formulario utilizando solo el teclado?
• ¿El orden de foco sigue una secuencia lógica?
• ¿El foco visible permite identificar qué elemento está activo?
• ¿Cada campo tiene una etiqueta comprensible?
• ¿Los campos obligatorios y sus formatos esperados están explicados?
• ¿Los mensajes de error indican qué ocurrió y cómo corregirlo?
• ¿El usuario conserva el contexto después de una validación o actualización del formulario?

Estas comprobaciones ayudan a detectar problemas de interacción que no siempre aparecen en una revisión visual rápida. Un formulario puede tener un diseño atractivo y validaciones correctas desde el punto de vista funcional, pero seguir siendo difícil o imposible de utilizar sin mouse.

Cómo recorrer un formulario utilizando solo el teclado

La prueba comienza desactivando el mouse. No es necesario instalar una herramienta específica: basta con abrir el formulario en un navegador y utilizar el teclado.

1. Iniciar el recorrido

Coloca el foco en una zona neutral de la página o recarga el formulario y presiona Tab. Observa cuál es el primer elemento que recibe foco. En muchos casos debería ser un enlace para saltar directamente al contenido principal, el primer control relevante o un elemento coherente con la estructura de la página.

Continúa presionando Tab y utiliza Shift + Tab para retroceder. Comprueba que todos los controles interactivos sean alcanzables:

• Campos de texto.
• Listas desplegables.
• Casillas de verificación.
• Botones de opción.
• Botones de envío o cancelación.
• Enlaces y controles para mostrar u ocultar información.

2. Usar cada tipo de control

Cuando el foco llegue a un campo de texto, escribe un valor de prueba. En una lista desplegable, verifica si puedes abrirla y seleccionar una opción con las flechas del teclado. En una casilla de verificación, utiliza la barra espaciadora para cambiar su estado. En un botón, presiona Enter o la tecla correspondiente y observa el resultado.

La prueba no consiste solo en comprobar que cada elemento recibe foco. También hay que verificar que el control pueda operarse completamente con teclado y que la interacción sea predecible.

3. Buscar bloqueos de teclado

Un bloqueo ocurre cuando el usuario entra en una parte del formulario y no puede salir utilizando el teclado. Puede aparecer, por ejemplo, en un selector personalizado, un diálogo o un componente desarrollado con elementos no nativos.

Si el foco queda atrapado, intenta volver al control anterior con Shift + Tab, cerrar el componente con Escape cuando corresponda y continuar con Tab. Documenta exactamente en qué paso se produce el bloqueo y qué combinación de teclas utilizaste.

Cómo evaluar el orden de foco y el foco visible

El orden de foco debería seguir una secuencia comprensible para una persona que está completando el formulario. En un checkout, por ejemplo, una secuencia razonable podría avanzar desde los datos personales hacia la dirección, el método de pago, las condiciones y finalmente el botón de confirmación.

Un orden problemático puede hacer que el foco salte desde un campo de dirección hacia un elemento del encabezado, que visite controles ocultos o que llegue al botón de envío antes de pasar por información obligatoria.

Qué observar durante la prueba

• El foco avanza de arriba hacia abajo y de acuerdo con la estructura visual, salvo que exista una razón clara para otro orden.
• No se visitan elementos que deberían estar ocultos o inactivos.
• Los controles relacionados se recorren en un orden lógico.
• El foco no desaparece después de abrir o cerrar un componente.
• El foco permanece visible sobre fondos, bordes y componentes con distintos estados.

El foco visible es la indicación visual de qué elemento está activo. Puede mostrarse mediante un contorno, un cambio de color u otro tratamiento visual. Si el foco existe técnicamente, pero no puede distinguirse, el usuario de teclado pierde la referencia de su posición dentro del formulario.

Como QA, evita asumir que un cambio de color sutil es suficiente. Comprueba el foco con diferentes tamaños de ventana y sobre distintos fondos. Si no puedes identificar con seguridad el elemento activo, registra el problema con una captura y describe el contexto en el que ocurre.

Etiquetas, instrucciones y mensajes de error

Una interfaz accesible debe comunicar qué información espera en cada campo y qué debe hacer el usuario cuando se produce un error. Los textos de ayuda no deberían depender únicamente de un placeholder, porque este texto puede desaparecer cuando el usuario comienza a escribir y no siempre sustituye a una etiqueta persistente.

Comprobar la relación entre etiqueta y campo

Para cada control, verifica que exista una etiqueta visible o una alternativa equivalente que identifique su propósito. “Correo electrónico”, “Código postal” y “Número de tarjeta” son ejemplos más útiles que instrucciones ambiguas como “Ingrese el dato”.

También revisa que la etiqueta corresponda al campo correcto. Una forma práctica de hacerlo es activar un campo mediante su etiqueta, cuando el navegador lo permita, y comprobar que el foco se ubica en el control esperado.

Validar instrucciones y campos obligatorios

El formulario debería indicar qué campos son obligatorios y, cuando sea necesario, explicar el formato esperado. Por ejemplo, si un código requiere una cantidad específica de caracteres, esa condición debería comunicarse antes o durante la interacción, no únicamente después de un intento fallido.

Los símbolos visuales, como un asterisco, pueden acompañar la información, pero no deberían ser la única forma de comunicar que un campo es obligatorio. La instrucción debe ser comprensible incluso si el usuario no distingue colores o no interpreta el símbolo.

Analizar los mensajes de error

Un mensaje útil responde tres preguntas:

• Qué ocurrió: el correo tiene un formato no válido.
• Dónde ocurrió: el mensaje está asociado al campo correspondiente.
• Cómo corregirlo: se debe ingresar una dirección con un formato válido.

Evita considerar suficiente un mensaje genérico como “Hay errores en el formulario” si no permite localizar y corregir el problema. Después de enviar datos inválidos, comprueba si el foco se mueve a un lugar útil, si el resumen de errores puede alcanzarse con teclado y si los valores ya ingresados se conservan cuando deberían conservarse.

Pruebas manuales frente a verificaciones automáticas

Las herramientas automáticas pueden revisar ciertos patrones del HTML y del árbol de accesibilidad. Por ejemplo, pueden ayudar a detectar controles sin nombre accesible, algunos problemas de contraste o relaciones incorrectas entre elementos. Son útiles para ampliar la cobertura y encontrar defectos repetitivos.

Sin embargo, una herramienta automática no puede determinar por sí sola si el orden de foco resulta lógico para el flujo de negocio, si un mensaje de error es comprensible o si un selector personalizado puede utilizarse de manera consistente con teclado.

Por eso conviene separar ambos tipos de pruebas:

• Verificaciones automáticas: detectan patrones técnicos y ofrecen una primera señal sobre posibles incumplimientos.
• Pruebas manuales: evalúan la experiencia real de interacción, el contexto, la comprensión y la posibilidad de completar el flujo.

Pasar una herramienta automática no equivale a cumplir todos los requisitos de accesibilidad. Del mismo modo, encontrar resultados en una herramienta no significa que todos sean defectos confirmados: cada hallazgo debe revisarse en el contexto de la interfaz y del comportamiento esperado.

Un enfoque práctico consiste en ejecutar primero verificaciones automáticas para detectar problemas evidentes y después realizar el recorrido manual con teclado. Los resultados deben consolidarse en un mismo informe, diferenciando el origen de cada hallazgo.

Ejercicio práctico para un QA junior

Puedes aplicar este ejercicio sobre un formulario de registro, login o checkout disponible en tu entorno de pruebas.

Preparación

• Abre el formulario en un navegador.
• Desconecta el mouse o comprométete a no utilizarlo.
• Ten disponible una hoja de cálculo o herramienta de gestión de incidencias.
• Define un flujo simple: completar datos válidos, provocar errores y corregirlos.

Ejecución

1. Recorre el formulario usando únicamente Tab y Shift + Tab.
2. Anota cada elemento que recibe foco y el orden en que aparece.
3. Comprueba si el foco es visible en todos los controles.
4. Opera casillas, listas, botones y controles desplegables sin mouse.
5. Envía el formulario con campos vacíos o con datos inválidos.
6. Revisa si los errores identifican el campo, explican el problema y ofrecen una corrección.
7. Corrige los errores y completa el flujo sin perder el contexto.

Cómo documentar un hallazgo reproducible

Un buen reporte permite que otra persona repita el problema sin depender de una explicación verbal. Incluye al menos:

• Título: “El foco no es visible en el botón Confirmar”.
• Precondiciones: formulario abierto y datos necesarios disponibles.
• Pasos: presionar Tab hasta llegar al botón.
• Resultado actual: el botón recibe foco, pero no se distingue visualmente.
• Resultado esperado: el botón debe mostrar un estado de foco claramente identificable.
• Evidencia: captura, video corto o registro del orden de foco.
• Impacto: una persona que utiliza teclado puede perder la ubicación actual y no saber qué control activará.

Evita reportes como “la accesibilidad está mal”. Ese tipo de descripción no indica dónde ocurre el problema ni qué comportamiento debería corregirse.

Errores frecuentes al probar accesibilidad

• Probar solo la página inicial: también deben revisarse estados de error, confirmaciones, diálogos y componentes que aparecen durante el flujo.
• Usar únicamente una herramienta automática: las verificaciones automáticas no sustituyen la interacción manual.
• Confundir foco con selección: un elemento puede estar enfocado sin estar seleccionado o activado.
• Validar solo que el Tab avance: también es necesario comprobar el orden, la visibilidad y la operación de cada control.
• Aceptar errores genéricos: el usuario necesita saber qué campo debe corregir y cómo hacerlo.
• Ignorar componentes personalizados: selectores, calendarios, modales y menús suelen requerir pruebas específicas de teclado.
• No conservar evidencia: sin pasos, contexto y resultado esperado, el defecto puede ser difícil de reproducir.

Conclusión: convertir la accesibilidad en una práctica de QA

Probar accesibilidad web en formularios requiere observar la interfaz como una persona que no utiliza mouse: recorrer el flujo con teclado, verificar el orden y la visibilidad del foco, revisar etiquetas e instrucciones y analizar cómo se comunican los errores.

Las herramientas automáticas son un apoyo valioso, pero no pueden evaluar por completo la lógica del flujo ni la claridad de la experiencia. La combinación de verificaciones automáticas, pruebas manuales y evidencia reproducible permite que los hallazgos sean más precisos y accionables para desarrollo y producto.

Siguiente paso: prueba tu formulario sin usar el mouse, registra las barreras encontradas y utiliza este ejercicio para fortalecer tus prácticas de QA. Si quieres desarrollar un criterio más completo para probar interfaces reales, conoce las prácticas de QA del curso QA Tester de Mentores Tech.