Revisa una página de destino solo con el teclado antes de publicarla
Revisa un recorrido realista por una página de destino con el teclado: foco visible, orden de navegación, menús y diálogos, sin confundir esta revisión inicial con una evaluación completa de accesibilidad.
En este artículo
Sobre esta guía y sus límites
Documentación revisada el 31 de octubre de 2026. Sin prueba práctica; portada ilustrativa generada con IA.
Muchas personas dependen del teclado o de tecnologías de asistencia que utilizan comandos de teclado. Las pautas de accesibilidad del W3C requieren que las funciones, incluidos formularios y controles, se puedan usar con el teclado. Esto importa tanto si tu página partió de una plantilla como si se creó con un diseño generado por IA o con código a medida. Principios de accesibilidad del W3C
Empieza con un recorrido realista
Sección 1 de 4Elige una tarea, como abrir el menú de servicios, encontrar un paquete y llegar al formulario de consulta. Trabaja en una vista previa o en una copia del entorno de pruebas para evitar que la revisión envíe por accidente una consulta real o complete una compra.
Observa adónde va el foco
Sección 2 de 4El foco del teclado identifica el elemento que recibirá tu siguiente acción. Al desplazarte, deberías poder reconocer qué enlace, botón o campo está activo. Un borde, un contorno u otro tratamiento visual claro pueden dar esa señal.
Abre los elementos y después ciérralos
Sección 3 de 4Prueba los menús desplegables, los controles de preguntas frecuentes y los cuadros de diálogo como parte del recorrido. Llegar a un control es solo el principio; prueba su función real y vuelve a la página.
Convierte las observaciones en correcciones
Sección 4 de 4Registra un problema por nota: el punto de partida, las teclas pulsadas, el resultado esperado y el resultado real. Describir que Tab llega al botón de consulta, pero no aparece ningún indicador visible de foco, es más útil que decir que la accesibilidad parece fallar.
Empieza con un recorrido realista
Elige una tarea, como abrir el menú de servicios, encontrar un paquete y llegar al formulario de consulta. Trabaja en una vista previa o en una copia del entorno de pruebas para evitar que la revisión envíe por accidente una consulta real o complete una compra.
Aparta el ratón. Usa Tab para avanzar y Shift+Tab para retroceder. Si parece que algunos controles se omiten, revisa los ajustes de navegación con teclado del navegador y del sistema operativo. Los distintos controles usan teclas diferentes: los enlaces suelen activarse con Enter, mientras que las listas de selección pueden requerir las teclas de flecha. Comprobaciones preliminares con el teclado del W3C
Anota el navegador, la dirección de la página y la tarea antes de empezar. Así será más fácil reproducir el problema si después redactas un informe de error.
Observa adónde va el foco
El foco del teclado identifica el elemento que recibirá tu siguiente acción. Al desplazarte, deberías poder reconocer qué enlace, botón o campo está activo. Un borde, un contorno u otro tratamiento visual claro pueden dar esa señal.
Detente en la llamada a la acción principal. ¿Puedes identificarla sin tener que adivinar? Comprueba lo mismo en las secciones claras, las oscuras y los fondos con imágenes. El indicador de foco debe permanecer visible mientras el elemento tenga el foco; una animación breve que desaparece no es suficiente. W3C: foco visible
Comprueba también que los encabezados fijos, los avisos de cookies u otras capas superpuestas no oculten por completo el control que tiene el foco. W3C: foco no oculto
Después, observa la secuencia. ¿Sigue un recorrido con sentido o salta de forma impredecible entre zonas sin relación? El orden no tiene que reproducir exactamente cada posición visual, pero debe conservar el significado y el funcionamiento. Un formulario de contacto que alterna entre grupos de campos sin relación merece una revisión. W3C: orden del foco
Abre los elementos y después ciérralos
Prueba los menús desplegables, los controles de preguntas frecuentes y los cuadros de diálogo como parte del recorrido. Llegar a un control es solo el principio; prueba su función real y vuelve a la página.
En un cuadro de diálogo modal, el foco suele pasar a su interior al abrirlo. Tab y Shift+Tab recorren sus controles, Escape lo cierra y el foco normalmente regresa al control que lo abrió. Comprueba que también haya un botón visible para cerrar o cancelar. Patrón de cuadro de diálogo modal del W3C
Mantener el foco dentro de un modal abierto puede ser intencional. El problema es no poder salir de un componente o cerrarlo con el teclado. Si hace falta un método de salida poco habitual, hay que explicar a los usuarios cómo funciona. W3C: sin trampas de teclado
Convierte las observaciones en correcciones
Registra un problema por nota: el punto de partida, las teclas pulsadas, el resultado esperado y el resultado real. Describir que Tab llega al botón de consulta, pero no aparece ningún indicador visible de foco, es más útil que decir que la accesibilidad parece fallar.
Después de una corrección, repite el mismo recorrido y comprueba los controles cercanos. Mantén una conclusión proporcionada: esta es una revisión inicial con el teclado. No demuestra una accesibilidad completa ni conformidad con las WCAG. El W3C advierte expresamente que las páginas que superan sus comprobaciones sencillas todavía pueden contener barreras importantes. Usa los hallazgos para orientar una evaluación más amplia. Alcance de la revisión del W3C
Flujo de trabajo basado en documentación; no se afirma haber realizado una prueba práctica de un sitio web concreto.
Fuentes
Estas son las fuentes oficiales del artículo original. Muchas de sus páginas están en inglés.