Foco no oculto WCAG: cabecera fija, banner de cookies y scroll-padding (2.4.11)

Qué exige exactamente el criterio 2.4.11 Foco no oculto

El texto normativo es breve: cuando un componente de interfaz recibe el foco del teclado, no queda completamente oculto por contenido creado por el autor. La palabra clave es «completamente»: en el nivel AA, un componente parcialmente cubierto puede cumplir. El W3C justifica esta tolerancia por la complejidad de los diseños responsive actuales, y recuerda que cuanto más cubierto está un componente, menos fácil resulta verlo. Por eso los autores deberían intentar reducir el grado y la frecuencia de ese solapamiento parcial.

El resultado ideal, sin ningún solapamiento, corresponde a otro criterio de nivel AAA: Foco no oculto (mejorado). Considere el nivel AA como un mínimo, no como una meta.

El criterio evalúa el componente enfocado, no el indicador de foco. El indicador solo cuenta si está dentro del componente o si el foco se señala mediante un cambio en el propio componente. Según el W3C, así se obtiene una medida más clara, pero un indicador de foco totalmente oculto probablemente incumpliría el criterio 2.4.7 Foco visible.

• Nota 1: si el usuario puede reubicar contenido en una interfaz configurable, solo se evalúa la posición inicial de ese contenido.
• Nota 2: el contenido abierto por el usuario puede tapar el componente enfocado; si el usuario puede mostrarlo sin avanzar el foco del teclado, el componente enfocado no se considera oculto por contenido creado por el autor.

Foco no oculto WCAG: por qué una cabecera fija o un banner de cookies puede ocultar el foco

El W3C cita los pies de página fijos, las cabeceras fijas y los diálogos no modales como los tipos de contenido que típicamente pueden solaparse con los elementos enfocados: a medida que el usuario avanza con la tecla Tab, estas capas pueden tapar el elemento que recibe el foco y su indicador de foco.

El W3C cita expresamente el banner de cookies como ejemplo. Una notificación implementada como contenido fijo, por ejemplo un banner de cookies, incumple el criterio si oculta por completo un componente que recibe el foco. Para las personas videntes que usan el teclado, o un dispositivo que funciona a través de la interfaz de teclado como un pulsador o el control por voz, saber dónde está el foco es fundamental: sin verlo, pueden no saber cómo continuar, o incluso pensar que el sistema ha dejado de responder.

Las capas semitransparentes, difuminadas u oscurecidas también merecen atención. Es posible que el elemento enfocado no quede completamente oculto por estas capas, en cuyo caso cumple el 2.4.11, pero puede incumplir por separado el criterio 1.4.11 Contraste no textual: el indicador de foco debe evaluarse según sus requisitos de contraste tal como se ve bajo la capa.

Corregir con scroll-padding: la técnica CSS C43

La técnica suficiente que el W3C indica para este criterio es la C43: usar la propiedad CSS scroll-padding para dejar de ocultar el contenido. El ejemplo del W3C: en una página con un pie de página fijo, el elemento enfocado no queda completamente tapado porque el contenido de la ventana se desplaza para mostrar siempre el elemento con el foco del teclado gracias al scroll padding. El W3C también menciona el scroll padding para los banners, de modo que el banner no se superponga al resto del contenido.

El fragmento siguiente es una ilustración nuestra, que debe adaptar: la página Understanding del W3C cita la técnica C43 sin detallar su sintaxis. Damos a scroll-padding un valor que corresponde a la altura de cada barra fija; compruebe el resultado con el teclado en cada punto de ruptura.

/* Ilustración: reservar espacio para la cabecera y el pie fijos */
html {
  scroll-padding-top: 5rem;    /* altura de la cabecera fija */
  scroll-padding-bottom: 4rem; /* altura del pie de página fijo */
}

.site-header {
  position: sticky;
  top: 0;
}

/* Indicador de foco visible con teclado (técnica C45) */
a:focus-visible,
button:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 2px;
}

Banners de cookies y notificaciones: otras soluciones

El scroll-padding no es la única vía. Para un banner de cookies o una notificación fija, el W3C describe varias formas de cumplir el criterio:

• Hacer que el banner sea modal, de modo que el usuario deba cerrarlo antes de navegar por la página. Un diálogo modal bien construido siempre cumple este criterio, porque toma el foco al aparecer e impide interactuar fuera de él hasta que se cierra.
• Usar scroll padding para que el banner no se superponga al resto del contenido.
• Si la notificación no requiere ninguna acción, cerrarla cuando pierde el foco.

Contenido persistente abierto por el usuario

Para el contenido persistente que abre el propio usuario, como un acordeón, un chatbot o una navegación lateral desplegable, el W3C describe enfoques que evitan ocultar el foco:

• El contenido nuevo desplaza el existente, como un acordeón que empuja el resto de la página hacia abajo.
• El contenido existente se redistribuye para hacer sitio, como una barra lateral que estrecha la zona principal.
• El contenido abierto toma el foco y la navegación con teclado queda limitada a él hasta que se cierra; el W3C aconseja usarlo con cautela, porque puede crear una experiencia desigual entre usuarios de teclado y de puntero.
• El contenido se abre en una zona de la página que no contiene otro contenido, siempre que se compruebe que no tapa nada en cada punto de ruptura responsive.
• El contenido se oculta automáticamente cuando el foco sale de él, o mediante un comando de teclado específico como la tecla Escape.

La relación con el foco visible (criterio 2.4.7)

El criterio 2.4.7 Foco visible, también de nivel AA, exige que toda interfaz operable por teclado tenga un modo de funcionamiento en el que el indicador de foco del teclado sea visible. Su objetivo es ayudar a saber qué elemento tiene el foco. El W3C precisa que el indicador no debe tener límite de tiempo: una vez mostrado, debe seguir visible.

Ambos criterios se complementan. El 2.4.7 comprueba que el indicador de foco es visible en al menos un modo de funcionamiento; el 2.4.11 comprueba que el componente enfocado no queda completamente oculto por contenido creado por el autor. Un contorno de foco bien diseñado no sirve de nada si desaparece bajo una cabecera fija. Entre las técnicas suficientes del 2.4.7 están C15 (cambiar la presentación de un componente al recibir el foco con CSS), C40 (indicador de dos colores para un contraste suficiente) y C45 (usar :focus-visible). Entre los fallos, F78 se refiere a estilos de contorno o borde que eliminan o hacen invisible el indicador de foco, y F55 al script que quita el foco al recibirlo.

Cómo comprobar el foco no oculto en su sitio

Una prueba manual con el teclado permite verificar este criterio. Recorra cada plantilla de página solo con el teclado, con Tab y Mayús+Tab, observando en cada paso si el elemento enfocado sigue visible.

• Pruebe con la cabecera fija visible y con el banner de cookies todavía abierto.
• Recorra toda la página, hacia abajo con Tab y hacia arriba con Mayús+Tab, para comprobar tanto el pie de página como la cabecera fijos.
• Repita la prueba en cada punto de ruptura responsive.
• Abra el contenido persistente (chat, panel de comentarios, navegación lateral) y compruebe que Escape o el desplazamiento con teclado permiten mostrar el elemento enfocado.
• Compruebe también que el indicador de foco es visible y tiene contraste suficiente.

Preguntas frecuentes

Más sobre el tema en Conformly

• Corregir la visibilidad del foco en HTML
• Guía del criterio RGAA 10.7
• Todo sobre el RGAA 5

Fuentes

Este artículo se basa en las fuentes oficiales citadas al final de la página.

• W3C — Comprendre 2.4.11
• W3C — Comprendre 2.4.7