¿Qué es el orden de navegación con teclado?

¿Qué es el orden de navegación con teclado?

El orden de navegación con teclado, también llamado orden de tabulación o de foco, es la secuencia en la que enlaces, botones y campos de formulario reciben el foco al pulsar Tab. Debe coincidir con el significado y el flujo visual de la página. La pauta WCAG 2.4.3 Orden del foco (nivel A) exige que los componentes enfocables reciban el foco en un orden que conserve el significado y la operabilidad.

Cómo funciona

Por defecto el orden sigue el código HTML. Los elementos enfocables de forma nativa, como enlaces con href, botones, campos, selectores, textareas, iframes y elementos summary, se recorren en el orden en que aparecen en el documento. Tres cosas lo cambian (consulta MDN sobre tabindex):

• tabindex="0" hace que un elemento sea alcanzable con Tab según el orden del código.
• tabindex="-1" lo saca de la secuencia de Tab pero permite que un script le dé el foco, útil para un modal que se abre o un mensaje de error tras un envío fallido.
• Un tabindex positivo lo adelanta a todo lo demás. MDN recomienda usar solo 0 y -1, porque los valores positivos y el CSS que reordena elementos enfocables dificultan la navegación a quienes usan teclado y tecnologías de apoyo.

La trampa es que el CSS puede mover elementos visualmente (orden de flexbox, grid, posicionamiento absoluto) mientras el foco sigue el código. El resultado es un foco que salta por la pantalla.

Los criterios WCAG relacionados

El orden del teclado forma parte de un pequeño grupo de criterios de las Pautas de Accesibilidad para el Contenido Web (WCAG) (fuente: documentos Understanding del W3C para WCAG 2.2):

• 2.1.1 Teclado (A): toda la funcionalidad se puede usar con una interfaz de teclado, con excepciones estrechas para entradas que dependen de la trayectoria, como el dibujo a mano alzada.
• 2.1.2 Sin trampas para el foco del teclado (A): si el foco entra en un componente con el teclado, también puede salir con el teclado, y se avisa al usuario si requiere algo más que Tab o las flechas.
• 2.4.3 Orden del foco (A): el orden conserva el significado y la operabilidad. No tiene que reflejar el diseño visual, pero no debe saltar al azar.
• 2.4.7 Foco visible (AA): el indicador de foco del teclado es visible.
• 2.4.11 Foco no oculto, mínimo (AA, nuevo en WCAG 2.2): un componente con foco no queda totalmente oculto por contenido creado por el autor, como una cabecera fija o un aviso de cookies.

Ejemplo: un formulario de pago

Un formulario muestra Nombre, Dirección y Número de tarjeta en columna, pero una regla CSS coloca el botón Pagar visualmente abajo mientras en el HTML está el primero. Quien tabula con el teclado desde arriba llega a Pagar antes de rellenar nada. La solución es poner los elementos en el HTML en el orden en que la gente los usa, en lugar de añadir valores de tabindex. Si una cabecera fija tapa el campo enfocado al bajar con Tab, añade scroll-padding para que el campo siga visible.

Errores habituales

• Arreglar el orden con tabindex positivo. Crea un segundo orden oculto que se rompe en cuanto alguien añade un campo.
• Ocultar el contorno del foco. Quitar el outline sin sustituirlo incumple Foco visible.
• Divs clicables. Un div con un manejador de clic no es enfocable. Usa un botón o un enlace; los roles ARIA no añaden por sí solos comportamiento de teclado.
• Modales que pierden o atrapan el foco. Lleva el foco al diálogo al abrirlo, mantenlo dentro mientras está abierto, ofrece una forma de cerrarlo con el teclado y devuelve el foco al elemento que lo abrió.
• Contenido fuera de pantalla que sigue siendo tabulable. Menús ocultos visualmente pero enfocables hacen que el foco desaparezca.
• Probar solo con el ratón. Los problemas de orden no se ven hasta que pulsas Tab.

Orden del teclado, pruebas y monitorización

La prueba es manual: aparta el ratón, recorre la página con Tab y Mayús+Tab y comprueba que cada control es alcanzable, que el foco siempre se ve y que el orden tiene sentido. Una pasada con un lector de pantalla da una segunda vista de la misma estructura. Las auditorías automáticas detectan etiquetas ausentes y algunos problemas de foco, pero no juzgan si el orden tiene sentido; consulta nuestro artículo sobre por qué las pruebas de rendimiento deben incluir la accesibilidad. Para vigilar regresiones, la monitorización de velocidad de LoadFocus ejecuta auditorías Lighthouse programadas y sigue la puntuación de Accessibility junto al rendimiento. Combínala con una prueba manual con Tab en las páginas clave y lee cómo construir un diseño accesible.

Preguntas frecuentes: orden de navegación con teclado

¿Cuál es el orden de tabulación por defecto?

El orden de los elementos enfocables en el código HTML. La posición visual no cuenta, por eso reordenar con CSS puede causar saltos de foco confusos.

¿Debería usar alguna vez un tabindex positivo?

Casi nunca. MDN recomienda solo 0 y -1. Reordena el HTML de forma lógica.

¿Qué criterios WCAG cubren la navegación con teclado?

Los principales son 2.1.1 Teclado, 2.1.2 Sin trampas para el foco del teclado, 2.4.3 Orden del foco, 2.4.7 Foco visible y, en WCAG 2.2, 2.4.11 Foco no oculto (mínimo). Los tres primeros son de nivel A y los dos últimos de nivel AA.

¿Qué es una trampa de teclado?

Un componente al que el foco del teclado entra pero del que no puede salir usando solo el teclado, por ejemplo un widget incrustado mal construido. WCAG 2.1.2 lo prohíbe.

¿El orden del foco debe coincidir con el orden visual?

No exactamente. WCAG exige un orden que conserve el significado y la operabilidad, y puede haber más de uno válido. Aun así debe parecer lógico y no saltar.