Auditoría práctica de accesibilidad web: teclado y formularios para responsables de negocio

Empieza por un recorrido pequeño y repetible

Recorrer la portada sin objetivo produce una lista dispersa. Intentar llegar a un servicio, abrir el contacto y enviar una propuesta revela si una persona puede completar el resultado que sostiene la web.

1. 01

   Elige tres recorridos

   Navegar a un servicio, completar el contacto con datos válidos y provocar errores.

2. 02

   Registra el entorno

   Anota URL, fecha, navegador, dispositivo, zoom y forma de entrada.

3. 03

   Describe el comportamiento

   Escribe el paso exacto, la barrera y su consecuencia, no solo «falla accesibilidad».

4. 04

   Repite después del cambio

   Usa el mismo guion para comprobar la corrección y posibles regresiones.

W3C presenta sus Easy Checks como una primera revisión que da una idea de si la accesibilidad básica está atendida. La propia fuente aclara que estas comprobaciones no cubren todos los problemas ni evalúan conformidad.

Prueba la tarea solo con teclado

Usa Tab y Mayús+Tab para moverte, Enter para activar enlaces o botones y Espacio cuando corresponda. Escape suele cerrar diálogos, pero el patrón depende del componente. El objetivo no es memorizar teclas: es verificar que la función pueda completarse y que la interfaz comunique dónde estás.

El criterio 2.1.1 de WCAG 2.2 exige que la funcionalidad se opere mediante una interfaz de teclado, salvo acciones cuyo resultado depende del recorrido de un movimiento libre. La explicación de W3C sobre Keyboard indica que las acciones con puntero necesitan un equivalente de teclado.

• ¿Existe un enlace para saltar al contenido y funciona al recibir foco?
• ¿El orden de foco sigue la lectura y llega a todos los controles?
• ¿El foco resulta visible sobre fondos claros y oscuros?
• ¿Menús, carruseles, selectores y modales se operan sin ratón?
• ¿Un diálogo lleva el foco dentro y lo devuelve al control que lo abrió?
• ¿Hay algún punto del que no se pueda salir con teclado?

Prueba el formulario antes, durante y después del error

WCAG 2.2 incluye criterios para identificación de errores y etiquetas o instrucciones. Cuando el sistema detecta un error, debe identificar el elemento y describir el problema mediante texto; los campos que esperan entrada necesitan etiquetas o instrucciones apropiadas.

Provoca varios errores a la vez y corrige solo uno. Comprueba que los demás mensajes sigan asociados, que los valores válidos no desaparezcan y que el resumen lleve a los campos. Un borde rojo no basta si el problema solo se expresa por color.

Después envía datos válidos. Distingue confirmación de éxito, problema temporal del servidor y error de entrada. La revisión de entrega del correo pertenece a otro diagnóstico; la guía sobre formularios cuyos correos no llegan cubre esa parte técnica.

Observa el foco en menús, modales y cambios de página

Anota la secuencia, no solo la captura: «activo Abrir contacto; el modal aparece, pero el foco queda en la página; después de cerrar, no vuelve al botón». Esta evidencia permite reproducir la barrera.

Combinar comprobaciones automáticas y manuales permite detectar barreras distintas. The Interactive Studio, por ejemplo, documenta pruebas de teclado, lector de pantalla, formularios y responsive. Para una revisión inicial de negocio, limita el recorrido y registra evidencia reproducible; no presentes ese ejercicio acotado como una auditoría de conformidad.

Repite con zoom y viewport móvil cuando el menú cambia de componente. Un menú de escritorio puede ser correcto y la versión móvil bloquear el foco. No asumas que compartir contenido significa compartir comportamiento.

Registra evidencia que otra persona pueda reproducir

Una captura no muestra el orden de foco; acompáñala de pasos y resultado. Conserva también una comprobación correcta cuando sea relevante: evita que el informe parezca una lista genérica y delimita el alcance probado.

Prioriza por bloqueo, alcance y frecuencia

Una trampa de teclado en el contacto principal puede bloquear la conversión en todo el sitio. Un orden incómodo en una acción secundaria sigue mereciendo corrección, pero normalmente va después. Esta prioridad organiza trabajo; no declara por sí sola qué obligación legal se incumple.

Las listas publicadas por proveedores como QAPractices ayudan a ampliar casos de teclado, foco, formularios y lectores de pantalla. Úsalas como apoyo trazable y comprueba cada punto en la interfaz real.

Lo que esta revisión no demuestra

• No cubre por sí sola lectores de pantalla ni varias combinaciones de tecnología asistiva.
• No mide todo el contraste, el reajuste, los subtítulos, documentos o estructura semántica.
• No revisa todas las páginas, estados, idiomas o componentes de terceros.
• No certifica conformidad con WCAG ni determina obligaciones jurídicas aplicables.

Para evaluar conformidad hay que definir muestra, criterios, tecnologías, métodos y experiencia evaluadora. Para interpretar obligaciones legales, consulta a profesionales competentes según servicio, sector y jurisdicción.

NAS Solutions puede incorporar estos recorridos al diagnóstico o rediseño dentro del servicio de desarrollo web de conversión. El alcance de pruebas, correcciones y evaluación especializada debe quedar definido en la propuesta; una revisión inicial no se presenta como certificación.