Orden del foco (2.4.3), foco visible (2.4.7), foco no oculto (2.4.11) y tabindex

Que todo sea operable con teclado no basta: además, el foco tiene que moverse en un orden que tenga sentido y la persona tiene que ver en todo momento dónde está. Imagina usar un ordenador cuyo puntero fuera invisible y saltara por la pantalla sin lógica. Eso es una web con mal orden de foco y sin indicador visible. Esta lección cubre tres criterios y una herramienta: 2.4.3 Orden del foco (A), 2.4.7 Foco visible (AA), 2.4.11 Foco no oculto (mínimo) (AA, nuevo en WCAG 2.2) y el atributo tabindex.

2.4.3 Orden del foco

El criterio exige que, cuando el orden de navegación afecta al significado o a la operación, los componentes reciban el foco en un orden que preserve ambos. En general eso significa que el orden del foco debe coincidir con el orden visual de lectura: de izquierda a derecha y de arriba abajo en nuestra cultura, siguiendo los bloques del diseño. Como el foco sigue el orden del DOM, la regla práctica es la misma que vimos en el curso anterior: ordena el código como se lee la página.

El orden lógico no siempre es el visual estricto: en un formulario de dos columnas coherentes, recorrer primero una columna entera y después la otra es correcto. Lo que no es correcto es que el foco vaya a la cabecera, luego al pie y luego al contenido porque alguien reordenó con CSS, ni que al abrir un desplegable el foco acabe al final de la página porque el panel se insertó allí en el DOM.

<input id="nombre" tabindex="1">
<input id="email" tabindex="3">
<input id="telefono" tabindex="2">
<button tabindex="4">Enviar</button>

tabindex: solo 0 y -1

El atributo tabindex tiene tres usos y solo dos de ellos son recomendables:

• tabindex="0": incluye el elemento en el orden natural de tabulación, en la posición que le corresponde por el DOM. Se usa para hacer alcanzable un elemento no nativo (un control personalizado, un contenedor con desplazamiento).
• tabindex="-1": el elemento puede recibir el foco por programa (elemento.focus()) o con clic, pero no con Tab. Se usa para destinos de enlaces de salto, contenedores de mensajes de error, encabezados a los que se mueve el foco tras un cambio de vista, y para las opciones de un componente compuesto que se recorren con flechas (patrón roving tabindex), que verás a fondo en la lección sobre componentes compuestos.
• tabindex="1" o mayor: altera el orden global. No lo uses.

Además, no pongas tabindex="0" en elementos no interactivos (párrafos, encabezados, tarjetas) «para que el lector los lea»: el lector ya lee todo; solo añades paradas sin función que confunden a quien navega con teclado.

2.4.7 Foco visible

El criterio exige que exista un modo de operación con teclado en el que el indicador de foco sea visible. Todos los navegadores lo dibujan por defecto (el anillo azul o el contorno punteado), así que el fallo casi siempre es provocado: la famosa regla outline: none o outline: 0 aplicada a todo para «limpiar» el diseño. Al quitarla sin sustituirla por otro indicador, la navegación por teclado queda a ciegas.

*:focus { outline: none; }
a, button { outline: 0; }

:focus-visible {
  outline: 3px solid #1a4fd6;
  outline-offset: 2px;
}
.boton-primario:focus-visible {
  outline: 3px solid #ffffff;
  box-shadow: 0 0 0 6px #1a4fd6;
}

¿Cuánto debe verse el indicador? WCAG 2.2 incluye el criterio AAA 2.4.13 Apariencia del foco con requisitos cuantitativos: un área al menos equivalente a un perímetro de 2 píxeles CSS alrededor del componente y un contraste de 3:1 entre el estado con foco y sin foco. No es obligatorio en AA, pero es la referencia que conviene seguir: un contorno de 2-3 píxeles, color con contraste 3:1 respecto al fondo (1.4.11 Contraste no textual sí aplica al indicador) y, si el componente puede estar sobre fondos variados, un doble anillo (claro y oscuro) como en el ejemplo.

2.4.11 Foco no oculto (mínimo)

Este criterio de WCAG 2.2 cubre un problema que 2.4.7 no cubría: el indicador existe, pero otro contenido lo tapa. Cabeceras fijas (sticky), pies con el aviso de cookies, barras de chat flotantes y paneles laterales pueden ocultar por completo el elemento enfocado, de modo que la persona pulsa Tab y no ve nada. El criterio exige que, cuando un componente recibe el foco, no quede completamente oculto por contenido creado por el autor. La versión AAA (2.4.12) exige que no quede oculto ni siquiera en parte.

Soluciones prácticas:

• Usa la propiedad CSS scroll-padding-top en el elemento con desplazamiento (normalmente html) con un valor igual a la altura de la cabecera fija, para que el navegador desplace el elemento enfocado por debajo de ella.
• Haz que los avisos de cookies y los chats flotantes no se superpongan al contenido, o que reciban el foco los primeros y puedan cerrarse.
• Comprueba el comportamiento de los paneles que se abren sobre el contenido: lo que queda debajo debería ser inerte o desplazarse.

html {
  scroll-padding-top: 80px; /* altura de la cabecera fija */
}

Cómo comprobarlo

• Recorre la página con Tab desde la barra de direcciones y anota en voz alta dónde está el foco; si en algún momento no lo sabes, falla 2.4.7 o 2.4.11.
• Observa si el orden sigue el diseño; cuando se abra algo, el foco debe ir a lo que se ha abierto.
• Busca en el CSS outline: none, outline: 0 y tabindex=" seguido de un número positivo en el HTML.
• Con una cabecera fija, tabula por una lista larga de enlaces y comprueba que ninguno se enfoca escondido debajo.

Resumen

• El foco sigue el orden del DOM; ordena el código como se lee y no uses tabindex positivos (2.4.3).
• tabindex="0" hace alcanzable un elemento; tabindex="-1" lo hace enfocable solo por programa.
• Nunca elimines el outline sin sustituirlo; usa :focus-visible con un contorno de 2-3 píxeles y contraste 3:1 (2.4.7, 1.4.11).
• Las cabeceras y pies fijos no deben tapar el elemento enfocado; scroll-padding-top lo evita (2.4.11).
• Tabular por la página entera sin perder de vista el foco es la prueba definitiva.