foco visible

Qué es y a quién le hace falta

El foco es el elemento que está seleccionado en cada momento. Cuando pulsas Tab, el foco salta al siguiente enlace, botón o campo, y lo que escribas o lo que pases al pulsar Intro va a ese elemento. El foco visible es simplemente la marca que te dice dónde está: un contorno, un cambio de fondo, un subrayado grueso.

Sin esa marca, navegar con teclado es ir a ciegas. Pulsas Tab cinco veces sin saber dónde has llegado y pulsas Intro a ver qué pasa. Es exactamente la misma experiencia que tendrías con el ratón si desapareciera el puntero.

Y no es un público pequeño ni exótico. Navega con teclado quien tiene un temblor o una lesión que le impide usar el ratón con precisión, quien usa un conmutador o un teclado adaptado, quien usa un lector de pantalla, quien tiene el ratón roto y quien simplemente va rápido rellenando un formulario largo. En ese último caso está media oficina de España.

Qué exige WCAG

Hay tres criterios y conviene no mezclarlos:

• 2.4.7 Foco visible (nivel AA): cualquier interfaz operable con teclado tiene un modo de operación en el que el indicador de foco se ve. Es el criterio de toda la vida y el que se incumple al escribir outline: none.
• 2.4.11 Foco no oscurecido (nivel AA, nuevo en WCAG 2.2): cuando un elemento recibe el foco, no puede quedar completamente tapado por otro contenido de la página. El caso típico es la cabecera pegajosa que se queda fija arriba y esconde el enlace al que acabas de saltar. En nivel AAA (2.4.12) no puede quedar tapado ni parcialmente.
• 2.4.13 Apariencia del foco (nivel AAA, nuevo en WCAG 2.2): define cómo de visible tiene que ser. Pide un indicador de al menos 2 píxeles de grosor que rodee el elemento y con un contraste de al menos 3:1 entre los colores del indicador antes y después de recibir el foco.

Traducido: no basta con que exista una marca. Tiene que verse de verdad. Un contorno de 1 píxel en gris claro cumple 2.4.7 sobre el papel y no lo ve nadie.

Cómo se hace bien

El navegador ya dibuja un foco por defecto. Lo mínimo aceptable es no quitarlo. Si el que trae no encaja con el diseño, se sustituye por otro; lo que no se puede hacer nunca es eliminarlo sin poner nada en su lugar.

/* Prohibido: deja la web inservible con teclado */
:focus { outline: none; }

/* Bien: indicador propio, grueso y separado del elemento */
:focus-visible {
  outline: 3px solid #0b5fff;
  outline-offset: 2px;
  border-radius: 2px;
}

Dos apuntes prácticos. El primero: :focus-visible es el selector que hay que usar hoy. Aplica el estilo cuando el foco llega por teclado, pero no cuando llega por clic de ratón, que es lo que molestaba a los diseñadores y lo que llevó a la mala costumbre de quitar el contorno.

El segundo: outline-offset separa el contorno del borde del elemento y hace que se vea sobre cualquier fondo. Y usar outline en lugar de border evita que el elemento cambie de tamaño al recibir el foco, que produce ese salto de maquetación tan feo.

Para que el indicador funcione sobre fondos claros y oscuros, un truco fiable es un contorno de dos colores: uno claro y otro oscuro, uno pegado al otro. Con outline más box-shadow se resuelve en dos líneas y ya no importa dónde caiga el botón.

Lo que me encuentro auditando

Es el fallo que más veces he encontrado y el más fácil de corregir de todos. Casi siempre viene del mismo sitio: un *:focus { outline: none } heredado de un reset de CSS antiguo, o una plantilla comprada donde alguien lo puso para que la maqueta quedara limpia en las capturas de pantalla.

Mi prueba de campo tarda dos minutos y no necesita ninguna herramienta: aparcar el ratón, cargar la portada y pulsar Tab hasta el pie de página. Si en algún momento no sé dónde estoy, hay un incumplimiento. Si el foco se mete dentro de un menú desplegable cerrado y desaparece, hay dos. Si al abrir una ventana modal el foco se queda detrás y sigo tabulando por la página de atrás, hay tres.

En ese recorrido salen además otros problemas que ninguna herramienta automática detecta: el orden de tabulación que no sigue el orden visual, el carrusel del que no se puede salir y el enlace «saltar al contenido» que no existe. El teclado es el diagnóstico más barato que conozco.

Por qué le importa a un negocio

Porque afecta al momento de la conversión. En una web informativa, la gente navega con el ratón; en un formulario largo —presupuesto, reserva, alta, pago— casi todo el mundo tira de Tab para saltar de campo en campo. Si el foco no se ve, el usuario pierde la referencia, se equivoca de casilla y abandona. Y eso pasa exactamente donde el negocio se juega el dinero.

Hay otro efecto menos evidente: quitar el foco suele venir acompañado de maquetar botones con <div> en lugar de <button>, y entonces el elemento ni siquiera recibe foco. Eso ya no es un problema de estilo, es un control que no existe para el teclado. Lo mismo que un botón que no se puede pulsar.

Errores frecuentes

outline: none sin sustituto. El clásico. Aparece en resets de CSS, en plantillas compradas y en normalizaciones antiguas. Es una sola línea que hace inservible la web para quien no usa ratón.

Un indicador demasiado sutil. Un contorno de 1 píxel en un gris parecido al fondo cumple la letra del criterio AA y falla su propósito. Grosor de al menos 2 píxeles y contraste mínimo de 3:1 con el estado sin foco.

Cabeceras y banners que tapan el foco. El menú fijo, el aviso de cookies o el chat flotante se comen el elemento enfocado justo cuando llega. Es incumplimiento directo de 2.4.11 y se arregla con scroll-margin-top en los elementos enfocables.

No devolver el foco después de cerrar algo. Al cerrar una ventana modal, el foco tiene que volver al botón que la abrió. Si vuelve al principio del documento, el usuario tiene que rehacer todo el recorrido.

Confiar el foco a JavaScript en elementos que no lo necesitan. Un <a> o un <button> reciben foco solos. Poner tabindex positivos por la página altera el orden de tabulación y produce recorridos imposibles de seguir.