WCAG 2.4.11: Enfoque no oculto (mínimo)

Qué significa esta regla

WCAG 2.4.11 Focus Not Obscured (Minimum) es un criterio de Nivel AA introducido en WCAG 2.2 que aborda un problema de accesibilidad común pero grave: cuando un elemento enfocado queda completamente oculto detrás de otra capa de contenido en la página. El criterio establece que cuando cualquier componente de la interfaz de usuario recibe el foco del teclado, ese componente no debe quedar totalmente oculto por contenido creado por el autor.

La palabra clave aquí es totalmente. WCAG 2.4.11 establece el mínimo — solo exige que alguna parte del elemento enfocado permanezca visible. Si una barra de navegación fija se superpone a la mitad superior de un botón enfocado pero la mitad inferior sigue siendo visible, técnicamente cumple con 2.4.11. El criterio complementario más estricto, WCAG 2.4.12 Focus Not Obscured (Enhanced) en Nivel AAA, va más allá al exigir que el componente enfocado no quede oculto por contenido creado por el autor en absoluto — ni siquiera parcialmente.

Los tipos de contenido creado por el autor que con mayor frecuencia causan este problema incluyen encabezados y pies de página pegajosos o con posición fija, banners de consentimiento de cookies, widgets de soporte por chat, notificaciones tipo toast, superposiciones modales, botones de acción flotantes y barras de navegación inferiores en diseños adaptativos para móviles. Estos elementos se renderizan usando propiedades CSS como position: fixed, position: sticky o valores altos de z-index, lo que hace que floten por encima del flujo normal del documento y potencialmente cubran elementos interactivos que reciben el foco.

Un aprobado significa que cuando una persona usuaria de teclado recorre los elementos interactivos con la tecla Tab, al menos una parte del indicador visual de cada elemento enfocado es visible en pantalla en todo momento — incluso si un elemento de interfaz pegajoso se superpone a una parte de él. Un fallo se produce cuando un elemento enfocado queda completamente oculto bajo una capa creada por el autor, lo que significa que la persona usuaria no tiene ninguna pista visual sobre dónde se encuentra el foco. El contenido renderizado por el navegador, como la propia barra de herramientas del navegador, no cuenta como contenido creado por el autor y por lo tanto queda fuera del alcance de este criterio. De manera similar, el contenido que la propia persona usuaria ha reposicionado (como un panel arrastrable por el usuario) también se excluye.

Este criterio se aplica a todos los elementos HTML interactivos que son focalizables con el teclado por defecto o que se han hecho focalizables mediante tabindex, incluidos <a>, <button>, <input>, <select>, <textarea> y elementos con tabindex='0' o valores positivos de tabindex.

Por qué es importante

La navegación por teclado es fundamental para la accesibilidad de varios grupos de personas usuarias. Las personas con discapacidades motoras que no pueden usar un ratón dependen totalmente de teclados, dispositivos de conmutación o controladores de soplo y succión para moverse por una página web. Las personas ciegas usan lectores de pantalla en combinación con teclados. Las personas con baja visión que usan navegación por teclado sin lector de pantalla dependen en gran medida del indicador de foco visible para entender dónde están. Cuando ese elemento enfocado queda oculto detrás de un encabezado pegajoso o un widget flotante, estas personas usuarias quedan efectivamente desorientadas — deben pulsar Tab repetidamente, adivinar su posición o abandonar la tarea por completo.

Considere un escenario real concreto: una persona usuaria de silla de ruedas con movilidad limitada en las manos está completando un formulario de reserva de vuelo en el sitio web de una aerolínea turca. Usa la tecla Tab para moverse por los campos del formulario. La página tiene un banner de consentimiento de cookies pegajoso en la parte inferior de la ventana gráfica. Cuando la persona usuaria llega con Tab a la casilla de verificación de confirmación final, la casilla se renderiza completamente debajo del banner de cookies. La persona usuaria no tiene ninguna indicación visual de que la casilla tiene el foco. No puede saber si su pulsación de Tab funcionó, si necesita pulsar Tab de nuevo o si la casilla de verificación es siquiera obligatoria. Esta confusión puede llevar al abandono del formulario, a envíos perdidos o a pulsaciones repetidas de teclas que provocan acciones no deseadas.

El impacto se extiende más allá de las personas con discapacidad. Las personas usuarias avanzadas que prefieren la navegación por teclado por rapidez — desarrolladores, profesionales de entrada de datos y personas usuarias expertas — también se benefician de una visibilidad clara del foco. Según la Organización Mundial de la Salud, aproximadamente 1,3 mil millones de personas en todo el mundo viven con alguna forma de discapacidad, y una parte significativa de ellas depende de tecnologías de apoyo o de la navegación por teclado. En Turquía específicamente, el Instituto de Estadística de Turquía (TÜİK) informa de que alrededor del 12,7% de la población tiene alguna forma de discapacidad, lo que se traduce en aproximadamente 10 millones de personas que pueden beneficiarse directamente de una mejor gestión del foco en las plataformas digitales.

Desde la perspectiva empresarial, los indicadores de foco ocultos aumentan las tasas de abandono de tareas, reducen la conversión y exponen a las organizaciones a riesgos legales y regulatorios. Los sitios que no cumplen este criterio también es probable que no superen las auditorías de accesibilidad exigidas por la legislación turca, poniendo en peligro su capacidad para obtener o mantener el Erişilebilirlik Logosu (Logotipo de Accesibilidad) oficial.

Reglas relacionadas de Axe-core

WCAG 2.4.11 se clasifica como un criterio que requiere pruebas manuales en axe-core. No existe una regla automatizada de axe-core que detecte directamente esta infracción. Entender por qué las herramientas automatizadas no pueden señalar de forma fiable este problema ayuda a los equipos a crear mejores procesos de prueba manual.

• Pruebas manuales necesarias — Foco oculto por posicionamiento fijo: Las herramientas automatizadas no pueden detectar si un elemento enfocado está visualmente oculto porque determinarlo requiere renderizar la página, calcular los rectángulos delimitadores de todos los elementos fijos o pegajosos en tiempo de ejecución y compararlos con el rectángulo delimitador del elemento actualmente enfocado en el momento del foco. Las dimensiones de la ventana gráfica, la posición de desplazamiento y el estado dinámico de la página (como si un banner de cookies ya se ha descartado) afectan al resultado. Ningún análisis estático ni inspección del DOM puede replicar de forma fiable este cálculo visual en todos los estados posibles. Axe-core marca este criterio como manual porque requiere que una persona probadora — o una herramienta sofisticada de regresión visual — recorra realmente la página con Tab y observe si los componentes enfocados desaparecen detrás de capas superpuestas.
• Pruebas manuales necesarias — Contenido de superposición dinámica: Muchos elementos que ocultan el foco se inyectan dinámicamente mediante JavaScript después de la carga inicial de la página — widgets de chat de terceros, banners de cumplimiento del RGPD, ventanas emergentes promocionales y menús de navegación flotantes. Los escáneres automatizados que analizan la instantánea inicial del DOM pueden no capturar estos elementos en absoluto, o pueden capturarlos en un estado colapsado u oculto que no refleja la experiencia real de la persona usuaria. Las pruebas manuales por parte de una persona usuaria de teclado que interactúa con la página en su estado dinámico completamente renderizado son la única forma fiable de detectar estos escenarios.

Cómo probar

1. Ejecute primero un escaneo automatizado de accesibilidad. Use axe DevTools (extensión del navegador), Lighthouse en Chrome DevTools o un escaneo de axe-core integrado en CI para identificar cualquier problema detectable automáticamente en la página. Aunque 2.4.11 en sí requiere verificación manual, un escaneo automatizado puede sacar a la luz problemas relacionados como indicadores de foco ausentes (2.4.7) o apilamiento incorrecto de z-index que sugiera elementos superpuestos. Anote todos los elementos marcados como potencialmente problemáticos antes de comenzar las pruebas manuales.
2. Identifique todos los elementos fijos y pegajosos de la página. Abra las DevTools del navegador e inspeccione el CSS de la página. Busque elementos que usen position: fixed o position: sticky. Revise también los elementos con valores altos de z-index (por ejemplo, 100 o más). Documente cada uno de estos elementos — encabezados, pies de página, banners, widgets de chat, avisos de cookies — ya que son los candidatos más probables a ocultar componentes enfocados. Cambie el tamaño de la ventana del navegador para simular diferentes tamaños de ventana gráfica, incluidas anchuras de tablet y móvil, ya que los elementos fijos/pegajosos a menudo se comportan de forma diferente según el breakpoint.
3. Realice un recorrido completo con la tecla Tab. Haga clic fuera de cualquier elemento interactivo para asegurarse de que el foco comienza en la parte superior de la página y luego pulse Tab repetidamente para recorrer todos los elementos focalizables. Observe cuidadosamente cada elemento cuando reciba el foco. Preste especial atención a los elementos que aparecen cerca de la parte superior o inferior de la ventana gráfica, donde es más probable que los encabezados o pies de página fijos se superpongan. Si en algún momento el anillo de foco visible o el elemento resaltado desaparece completamente detrás de una capa fija, se trata de un fallo de 2.4.11. Use Shift+Tab para recorrer en sentido inverso también, ya que la posición de desplazamiento y el diseño pueden diferir.
4. Pruebe con NVDA y Firefox. Abra NVDA (lector de pantalla gratuito y de código abierto para Windows) e inicie Firefox. Active el modo de exploración de NVDA y use Tab para moverse por la página. Aunque NVDA anunciará cada elemento enfocado de forma audible, observe también la pantalla visualmente. Anote cualquier elemento en el que NVDA anuncie el foco pero no haya indicador de foco visible debido a contenido que lo oculta. Esta combinación se usa ampliamente en Turquía y en todo el mundo y representa un emparejamiento clave de tecnología de apoyo.
5. Pruebe con VoiceOver y Safari en macOS/iOS. Active VoiceOver (Command+F5 en Mac) y use Tab o los gestos de navegación de VoiceOver para moverse por los elementos focalizables. En iOS, use gestos de deslizamiento. Verifique que los elementos enfocados están presentes visualmente y no quedan ocultos bajo capas de interfaz fijas, especialmente en dispositivos móviles donde las barras de navegación y los banners de cookies pueden ocupar una mayor proporción de la ventana gráfica.
6. Pruebe con JAWS y Chrome. Abra JAWS (Job Access With Speech) y use Chrome. Recorra con Tab todos los elementos interactivos y compruebe si en algún momento el cursor de JAWS se mueve a un elemento que está visualmente oculto bajo una capa fija. JAWS se usa ampliamente en entornos empresariales y gubernamentales, lo que hace que esta combinación sea especialmente importante para probar sitios web del sector público y corporativos.
7. Pruebe después de interacciones de usuario que cambian el diseño. Cierre banners de cookies, abra y cierre menús de navegación, dispare notificaciones tipo toast y abra widgets de chat. Después de cada cambio de estado, realice un nuevo recorrido con Tab para asegurarse de que el nuevo diseño no introduce nuevos casos de foco oculto. El contenido dinámico es una fuente común de fallos de 2.4.11 que solo aparecen después de la interacción de la persona usuaria.
8. Pruebe en múltiples posiciones de desplazamiento. Desplácese hacia la mitad o la parte inferior de una página larga y luego recorra con Tab los elementos de esa región. Es posible que los encabezados fijos no oculten elementos cerca de la parte superior de la página, pero sí pueden cubrir elementos que aparecen en el borde superior de la ventana gráfica a medida que la persona usuaria se desplaza hacia abajo. Confirme que ninguna combinación de posición de desplazamiento y elemento enfocado da como resultado un ocultamiento visual completo.

Cómo corregir

Encabezado pegajoso que se superpone a enlaces enfocados — Incorrecto

<!-- Sticky header with no scroll offset accommodation -->
<header style='position: fixed; top: 0; left: 0; width: 100%; height: 60px; z-index: 1000; background: white;'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- No scroll-margin-top set; focused link at top of main scrolls under the header -->
  <a href='/section-one'>Go to Section One</a>
  <a href='/section-two'>Go to Section Two</a>
</main>

Encabezado pegajoso que se superpone a enlaces enfocados — Correcto

<!-- Fixed header with scroll-margin-top applied to all focusable elements -->
<header class='site-header'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top ensures the browser scrolls the element into view
       with enough clearance so the fixed header does not cover it -->
  <a href='/section-one' class='content-link'>Go to Section One</a>
  <a href='/section-two' class='content-link'>Go to Section Two</a>
</main>

<!-- In your stylesheet: -->
<!-- .site-header { position: fixed; top: 0; height: 60px; z-index: 1000; } -->
<!-- * { scroll-margin-top: 70px; } -->
<!-- The 70px (header height + 10px buffer) keeps focused elements
     visible below the fixed header when the browser auto-scrolls. -->

Banner de cookies que cubre el campo de formulario enfocado en la parte inferior — Incorrecto

<!-- Cookie banner fixed at bottom with no accommodation for form fields above it -->
<div id='cookie-banner' class='cookie-overlay'>
  <p>We use cookies. <button>Accept</button></p>
</div>

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <!-- This checkbox renders in the viewport area covered by the cookie banner -->
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Banner de cookies que cubre el campo de formulario enfocado en la parte inferior — Correcto

<!-- Cookie banner pushes page content up instead of overlapping it -->
<div id='cookie-banner' class='cookie-banner-flow'>
  <p>We use cookies. <button id='accept-cookies'>Accept</button></p>
</div>

<!-- In your stylesheet: -->
<!-- .cookie-banner-flow { position: static; } instead of position: fixed -->
<!-- Alternatively, if fixed positioning is required for design reasons,
     add scroll-margin-bottom to all focusable elements equal to the
     banner height, or apply padding-bottom to <body> equal to
     the banner height so content is never hidden beneath it. -->

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Widget de chat de terceros que se superpone a un botón enfocado — Incorrecto

<!-- Third-party chat widget injected in bottom-right corner
     with a high z-index, obscuring the focused Submit button -->
<div id='chat-widget' class='chat-fixed'>
  <!-- Injected by third-party script, covers 120x120px in bottom-right -->
</div>

<section class='cta-section'>
  <!-- Button positioned in the bottom-right area of the layout;
       when focused, it is completely hidden beneath the chat widget -->
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

Widget de chat de terceros que se superpone a un botón enfocado — Correcto

<!-- Approach 1: Reposition the chat widget to avoid overlapping focusable content -->
<div id='chat-widget' class='chat-fixed-adjusted'>
  <!-- Widget repositioned to bottom-left, away from the CTA button -->
</div>

<!-- Approach 2: Ensure the button has scroll-margin that keeps it
     clear of the widget when focused -->
<section class='cta-section'>
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

<!-- Approach 3: Use JavaScript to detect focus events on elements
     near the widget's bounding box and temporarily collapse or
     move the widget so the focused element is visible. -->
<script>
  // Example: collapse widget when nearby element gains focus
  document.querySelectorAll('.cta-button').forEach(function(btn) {
    btn.addEventListener('focus', function() {
      var widget = document.getElementById('chat-widget');
      if (widget) widget.setAttribute('aria-hidden', 'false');
      // Additional logic to reposition or minimize widget
    });
  });
</script>

Errores comunes

• Aplicar position: fixed a encabezados y pies de página sin añadir scroll-margin-top o scroll-margin-bottom a los elementos focalizables. El desplazamiento nativo del foco del navegador no tiene en cuenta los elementos fijos superpuestos, por lo que los elementos enfocados se desplazan a la parte superior o inferior de la ventana gráfica y terminan ocultos detrás de la capa fija. Una regla CSS global como * { scroll-margin-top: [header-height]px; } resuelve esto de forma eficiente.
• Establecer body { padding-top: 60px; } para compensar un encabezado fijo pero olvidar añadir un scroll-margin-top equivalente para el foco del teclado. El padding garantiza que el contenido no quede oculto inicialmente, pero cuando el foco del teclado activa el desplazamiento automático del navegador, el objetivo de desplazamiento aún puede quedar detrás del encabezado. Ambos enfoques deben usarse juntos.
• Usar z-index: 9999 en banners promocionales o widgets de chat sin auditar qué elementos focalizables quedan dentro de su área. Un z-index alto garantiza que la superposición se renderice por encima de todo, incluidos botones y enlaces enfocados, lo que lo convierte en la causa raíz más común de fallos de 2.4.11.
• Cerrar banners de cookies mediante JavaScript sin eliminarlos inmediatamente del diseño. Si el elemento DOM del banner permanece con visibility: hidden u opacity: 0 pero sigue ocupando espacio o tiene un z-index distinto de cero, puede seguir ocultando visualmente elementos enfocados en ciertos escenarios de renderizado del navegador.
• Incorporar widgets de terceros (chat en vivo, superposiciones de accesibilidad, gestores de RGPD) sin verificar su impacto en la visibilidad del foco del teclado. Los scripts de terceros suelen inyectar elementos con posición fija y valores de z-index muy altos. Los equipos deben probar estas integraciones explícitamente como parte de su proceso de QA de accesibilidad.
• No probar 2.4.11 después de cambios en los breakpoints responsivos. Una barra de navegación pegajosa que mide 60px de alto en escritorio puede expandirse a 120px en tablet cuando se abre un menú hamburguesa, ocultando de repente un área mucho mayor y creando nuevos fallos en breakpoints que pasaban en escritorio.
• Aplicar scroll-margin-top solo a los objetivos de anclaje (<h2>, <section>) pero no a elementos interactivos como <input>, <button> y <a>. El desplazamiento de anclajes suele abordarse, pero el desplazamiento automático del foco del teclado hacia elementos que no son anclajes se ve afectado de igual manera y debe cubrirse con la misma regla CSS.
• Suponer que, porque un lector de pantalla anuncia un elemento enfocado, este también es visible visualmente. Los lectores de pantalla acceden al árbol de accesibilidad, no al renderizado visual. Un elemento puede estar completamente oculto detrás de una superposición fija y aun así ser anunciado correctamente por NVDA o JAWS. Son dos problemas distintos — 2.4.11 se refiere específicamente a la visibilidad del foco visual para personas usuarias videntes que usan el teclado.
• Descuidar probar el ocultamiento del foco después de cambios de ruta en aplicaciones de una sola página (SPA). En aplicaciones React, Vue o Angular, las transiciones de ruta a menudo vuelven a renderizar encabezados fijos con estado actualizado, y la gestión del foco durante la navegación puede colocar el foco en elementos que quedan inmediatamente ocultos por un encabezado pegajoso remontado antes de que la persona usuaria vea la nueva página.
• Confiar únicamente en herramientas de prueba automatizadas y concluir que no existen problemas de 2.4.11 porque ninguna regla automatizada marcó la página. Dado que axe-core no tiene una regla automatizada para este criterio, un informe automatizado limpio no significa que la página cumpla. El recorrido manual con teclado en todos los tamaños de ventana gráfica y estados de la página es obligatorio.

Relación con la normativa de accesibilidad de Turquía

WCAG 2.4.11 Focus Not Obscured (Minimum) es directamente relevante para el marco legal de accesibilidad emergente de Turquía. La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial nº 32933 el 21 de junio de 2025, establece requisitos obligatorios de accesibilidad digital que se alinean con WCAG 2.2. Esta circular representa una expansión significativa del compromiso de Turquía con la inclusión digital e impone obligaciones exigibles a una amplia gama de entidades que operan en el mercado digital turco.

La circular abarca un amplio espectro de organizaciones, incluidas instituciones públicas y organismos gubernamentales, plataformas de comercio electrónico, bancos y proveedores de servicios financieros, hospitales y organizaciones sanitarias, empresas de telecomunicaciones con más de 200.000 abonados, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE). Se espera que todas estas entidades garanticen que sus interfaces digitales — sitios web, aplicaciones móviles y herramientas basadas en la web — se ajusten al Nivel AA de WCAG 2.2.

Dado que WCAG 2.4.11 es un criterio de Nivel AA en WCAG 2.2, el cumplimiento de esta regla no es opcional para las entidades cubiertas. Las organizaciones que buscan obtener o mantener el Erişilebilirlik Logosu (Logotipo de Accesibilidad) oficial, emitido por el Ministerio de Familia y Servicios Sociales (Aile ve Sosyal Hizmetler Bakanlığı), deben cumplir la conformidad de Nivel AA. El Logotipo de Accesibilidad sirve como una señal pública de compromiso con la inclusión digital y es cada vez más esperado por las personas consumidoras turcas y los organismos de contratación pública.

En términos prácticos, esto significa que los sitios web de instituciones públicas turcas con encabezados de navegación pegajosos, los sitios de comercio electrónico con banners promocionales persistentes, los portales bancarios con widgets de ayuda flotantes y los sistemas de citas sanitarias con superposiciones de consentimiento de cookies deben ser todos probados y corregidos para evitar el ocultamiento del foco según 2.4.11. Los fallos en este criterio son especialmente probables en interfaces complejas y cargadas de marketing — exactamente el tipo de sitios operados por las grandes entidades comerciales cubiertas por la circular.

Las organizaciones que operan bajo la circular deben incorporar las pruebas de 2.4.11 en sus ciclos regulares de auditoría de accesibilidad. Dado que este criterio requiere pruebas manuales, confiar únicamente en el escaneo automatizado no satisfará las obligaciones de diligencia debida. Se recomienda a las entidades turcas que persiguen el cumplimiento pleno que realicen pruebas manuales de recorrido con teclado en todos los tamaños de ventana gráfica y estados dinámicos de la página como parte de su documentación de conformidad, y que aborden cualquier problema de ocultamiento del foco identificado como parte de su hoja de ruta de corrección antes de la solicitud o renovación del logotipo de accesibilidad.