Foco no oculto (mínimo)
Cuando un elemento recibe el foco del teclado, no debe quedar completamente oculto detrás de otro elemento de la interfaz —cabeceras fijas, banners de cookies, widgets de chat, pies de página fijos—. Nuevo en WCAG 2.2 y con un impacto directo en la forma en que los equipos construyen el chrome fijo de sus páginas.
Qué exige este criterio
Cuando un usuario tabula hasta un control, al menos una parte de ese control debe permanecer visible. El patrón de fallo más habitual: el usuario tabula hacia abajo y supera una cabecera fija; la página desplaza automáticamente el scroll de modo que el enlace enfocado queda detrás de la barra fija y el usuario deja de ver el anillo de foco. El control sigue teniendo el foco y responde a la tecla Enter, pero el usuario no puede verlo.
El criterio establece un umbral mínimo: el elemento enfocado puede quedar parcialmente cubierto, siempre que no lo esté de forma completa. El nivel AAA del criterio 2.4.12 eleva ese umbral a «no oculto en absoluto».
Este es uno de los cuatro nuevos criterios de conformidad de operabilidad introducidos en WCAG 2.2 y ha tenido un impacto notable porque las cabeceras fijas, los pies de página fijos, los banners de cookies y las burbujas de widgets de chat están presentes prácticamente en todas partes.
Cómo cumplirlo
- Añadir la propiedad CSS
scroll-margin-topa los elementos enfocables con un valor igual a la altura de la cabecera fija, de modo que el navegador desplace automáticamente el control enfocado por encima de la cabecera. - Para los pies de página fijos y las burbujas de chat, verificar que no cubran completamente ningún elemento enfocable. La opción puede ser reducirlos cuando hay foco activo o anclarlos de forma que dejen un margen en el borde de la página.
- Banners de cookies y superposiciones descartables: no fijarlos de un modo que atrape los puntos de tabulación posteriores por debajo. La alternativa es hacerlos modales (con trampa de foco) o no bloqueantes.
- En páginas con cabecera fija y pie de página fijo a la vez, comprobar la secuencia de tabulación en torno al centro vertical del viewport —es donde el elemento enfocado queda más apretado entre ambos elementos.
- Usar
scroll-padding-topen el contenedor de desplazamiento como alternativa para navegadores más antiguos.
html { scroll-padding-top: 80px; } /* ajustar a la altura de la cabecera fija */
:target, :focus { scroll-margin-top: 80px; }
Fallos habituales
- Cabecera fija sin compensación de
scroll-padding: cada tabulación hacia la mitad superior del viewport oculta el anillo de foco. - Banner de consentimiento de cookies anclado en la parte inferior que cubre la última fila de campos de formulario cuando dichos campos reciben el foco.
- Burbuja de widget de chat en la esquina inferior derecha que se solapa con el botón «Enviar» en la esquina de un formulario.
- Barras fijas promocionales (por ejemplo, banners del Black Friday) añadidas por los equipos de marketing sin actualizar los tokens de
scroll-padding. - Cabeceras de tabla fijas en paneles de control donde al tabular hasta la primera fila de datos el foco queda detrás de la fila de cabecera.
Por qué es importante
Este criterio corrige una categoría de error que frustra a los usuarios de teclado a diario, pero que rara vez aparece en los análisis automatizados: ninguna regla de axe puede predecir en qué posición de desplazamiento un elemento fijo se va a solapar con uno enfocado. Además, afecta de forma desproporcionada a los usuarios de lupa de pantalla, cuyo viewport visible ya está reducido a una cuarta parte de la pantalla, de modo que el elemento fijo ocupa una proporción aún mayor.
Se espera que el criterio 2.4.11 sea uno de los nuevos hallazgos más citados en los informes de auditoría de 2026. La corrección es sencilla —unos pocos tokens CSS—, pero requiere que todos los equipos responsables de un elemento fijo —cabecera, pie de página, banner, widget— la coordinen entre sí.