WCAG 2.4.12: Enfoque no oculto (mejorado)

Qué significa esta regla

WCAG 2.4.12 — Enfoque no oculto (mejorado) — es el equivalente de nivel AAA de WCAG 2.4.11 (Enfoque no oculto, AA). Mientras que el criterio AA permite que un componente enfocado sea parcialmente visible, el criterio AAA exige que el componente enfocado sea totalmente visible: ninguna parte de él puede quedar oculta por contenido creado por el autor cuando recibe el enfoque mediante teclado.

En términos prácticos, esto significa que cuando una persona se desplaza con la tecla Tab hasta un elemento interactivo como un enlace, botón, campo de formulario o widget personalizado, toda el área delimitadora de ese elemento debe estar libre de obstrucciones por cualquier encabezado fijo, pie de página fijo, superposición modal, banner de cookies, widget de chat o cualquier otro contenido que el autor haya colocado en la página. La regla se dirige específicamente al contenido creado por el autor; el W3C hace una excepción explícita para el contenido que la propia persona usuaria haya movido para ocultar el indicador de enfoque — por ejemplo, un panel flotante que la persona arrastró delante del elemento enfocado. En ese caso, la responsabilidad no recae en el autor.

Para cumplir con 2.4.12 se requiere que, al recibir el enfoque, todo el componente enfocado sea visible dentro del área visible de la ventana (viewport) y no esté cubierto por ningún elemento con posición fija, pegajosa (sticky) o absoluta que controle el autor de la página. Se produce un fallo cuando cualquier parte del límite visible del elemento enfocado queda oculta detrás de dichas superposiciones — incluso un solo píxel del anillo de enfoque o del propio componente recortado cuenta como fallo en el nivel AAA.

Es importante entender lo que 2.4.12 no cubre. No exige un estilo concreto de indicador de enfoque (eso se aborda en 2.4.11 y 2.4.7). No requiere que los indicadores de enfoque tengan una relación de contraste mínima (cubierto por 2.4.13). Se ocupa específicamente de la relación espacial entre el elemento enfocado y el resto del contenido de la página: el problema de capas que surge con mayor frecuencia a partir de posicionamiento fijo y pegajoso en CSS.

Los elementos HTML afectados incluyen cualquier elemento enfocable o accesible mediante Tab: <a>, <button>, <input>, <select>, <textarea>, <details>, elementos con tabindex y widgets interactivos personalizados construidos con roles ARIA. El criterio se aplica en todos los contextos de navegación, incluidos iframes, diálogos y transiciones de rutas en aplicaciones de una sola página.

Por qué es importante

La navegación mediante teclado es un método de acceso principal para una amplia variedad de personas. Quienes tienen discapacidades motoras — incluidas quienes viven con afecciones como ELA, esclerosis múltiple, parálisis cerebral o lesiones por esfuerzo repetitivo — dependen por completo del teclado o de dispositivos de acceso por pulsadores en lugar de un ratón. Las personas ciegas y con baja visión que utilizan lectores de pantalla también navegan con el teclado y, aunque su tecnología de apoyo anuncia la posición del enfoque de forma audible, las personas videntes que usan el teclado dependen por completo del indicador visual de enfoque para orientarse en la página.

Cuando el elemento enfocado queda oculto, incluso parcialmente, estas personas se enfrentan a una experiencia frustrante y potencialmente desorientadora: la página parece no ofrecer ningún elemento enfocado, o la persona debe adivinar dónde se encuentra en el documento. En el nivel AA (2.4.11), se tolera la visibilidad parcial — al menos una parte del componente es visible y proporciona una pista. El criterio AAA elimina por completo este compromiso, reconociendo que incluso un indicador de enfoque parcialmente oculto puede pasar desapercibido para personas con sensibilidad reducida al contraste, visión en túnel o condiciones cognitivas que hacen que escanear la pantalla sea más exigente.

Consideremos un escenario concreto: un sitio web de comercio electrónico turco utiliza una barra de navegación fija de 80px de alto en la parte superior del viewport y un banner de consentimiento de cookies pegajoso de 60px de alto en la parte inferior. Una persona que pulsa Tab para navegar por las tarjetas de producto puede descubrir que el borde superior o inferior de la tarjeta enfocada — incluido su anillo de enfoque — se desliza por debajo de una de estas superficies fijas. Bajo WCAG 2.4.11 (AA), si alguna parte de la tarjeta sigue siendo visible, el sitio aprueba. Bajo 2.4.12 (AAA), la tarjeta completa debe ser totalmente visible. Esta distinción es significativa: una etiqueta de botón parcialmente oculta combinada con un anillo de enfoque parcialmente oculto puede hacer que sea realmente imposible para una persona con baja visión determinar qué elemento está activo o qué acción realizará.

Según la Organización Mundial de la Salud, aproximadamente 2,2 mil millones de personas en todo el mundo tienen algún tipo de discapacidad visual, y las discapacidades motoras afectan a cientos de millones más. Las mejoras en la accesibilidad mediante teclado benefician no solo a estos grupos, sino también a personas expertas que prefieren la navegación por teclado por rapidez, a quienes usan dispositivos sin dispositivo apuntador y a quienes se encuentran en situaciones en las que el control motor fino está temporalmente afectado.

Más allá del acceso para personas con discapacidad, un enfoque totalmente visible mejora la usabilidad general y reduce los costes de soporte. Cuando todas las personas — incluidas aquellas sin discapacidad — pueden seguir claramente la posición del enfoque, aumentan las tasas de finalización de formularios y disminuyen las tasas de error. Para los sitios dirigidos al mercado turco, demostrar conformidad AAA indica un programa de accesibilidad maduro y genera confianza tanto en las personas usuarias como en los equipos de contratación institucional.

Reglas relacionadas de Axe-core

WCAG 2.4.12 se clasifica como un criterio que requiere pruebas manuales y forma parte de las incorporaciones de WCAG 2.2. No existe una regla de axe-core totalmente automatizada que pueda detectar de forma fiable esta infracción, y entender por qué es importante para los equipos que construyen sus flujos de pruebas.

• Inspección manual — focus-not-obscured-enhanced (sin regla automatizada): Los escáneres de accesibilidad automatizados como axe-core operan sobre el DOM estático o una instantánea del estado renderizado. Detectar si un elemento enfocado está oculto requiere: (1) simular el enfoque mediante teclado en cada elemento interactivo en secuencia, (2) calcular el rectángulo delimitador del elemento después del desplazamiento inducido por el enfoque, (3) identificar todos los elementos con posición fija y pegajosa y sus rectángulos delimitadores y (4) comprobar si hay solapamiento geométrico. Aunque la automatización parcial es teóricamente posible, la naturaleza dinámica del comportamiento de desplazamiento, la propiedad CSS scroll-padding, el desplazamiento suave y la gestión del enfoque mediante JavaScript hacen que esto sea muy poco fiable en la práctica. Un elemento enfocado que es perfectamente visible en un tamaño de viewport puede quedar totalmente oculto en otro. axe-core marca este criterio como algo que requiere juicio humano y clasifica los hallazgos como “necesita revisión” en lugar de infracciones automáticas. Las personas que prueban deben recorrer manualmente con Tab todos los elementos interactivos y confirmar visualmente la visibilidad completa en cada anchura de viewport relevante.
• scrollable-region-focusable (regla de axe): Aunque no se asigna directamente a 2.4.12, esta regla de axe marca elementos dentro de regiones desplazables que son enfocables pero que pueden no desplazarse correctamente a la vista. Es una señal relacionada que indica problemas de gestión del desplazamiento que podrían hacer que el enfoque quede oculto por encabezados o pies de página pegajosos — el modo de fallo más común para 2.4.12.

Dado que las herramientas automatizadas no pueden detectar de forma fiable infracciones de 2.4.12, las organizaciones deben incorporar recorridos manuales con teclado en su proceso de QA, idealmente en múltiples tamaños de viewport y con todas las capas de interfaz persistentes (barras de navegación, widgets de chat, banners de cookies, avisos RGPD) activas.

Cómo probar

1. Exploración automatizada de referencia: Ejecuta axe DevTools o Lighthouse sobre la página para identificar cualquier problema relacionado, como infracciones de scrollable-region-focusable o problemas de desbordamiento CSS. Estos hallazgos, aunque no son infracciones directas de 2.4.12, indican las áreas de la página con más probabilidad de causar problemas de enfoque oculto. En axe DevTools, filtra por criterios WCAG 2.2 y revisa cualquier elemento marcado como “necesita revisión” relacionado con la visibilidad del enfoque.
2. Identificar todo el contenido superpuesto persistente: Antes de las pruebas con teclado, cataloga visualmente cada elemento con position: fixed o position: sticky en la página — normalmente barras de navegación, banners de cookies, widgets de chat, botones de acción flotantes y barras de herramientas de pie de página. Anota sus alturas y posiciones para saber qué zonas del viewport ocupan.
3. Recorrido de navegación con teclado: Empezando desde la parte superior de la página (o después de cerrar cualquier modal inicial), pulsa Tab repetidamente para mover el enfoque por cada elemento interactivo. En cada parada de enfoque, verifica que el elemento enfocado completo — incluido su indicador de enfoque visible (contorno o anillo) — esté totalmente dentro del área del viewport no oculta. No aceptes visibilidad parcial. Si cualquier parte del elemento o de su anillo de enfoque desaparece detrás de un elemento fijo, registra esto como un fallo de 2.4.12.
4. Navegación inversa: Repite el recorrido usando Shift+Tab para navegar hacia atrás. Los pies de página fijos suelen pasarse por alto en pruebas solo hacia adelante, pero pueden ocultar elementos al desplazarse con Tab en sentido inverso.
5. Pruebas con lector de pantalla usando NVDA + Firefox: Abre NVDA, inicia Firefox y navega usando Tab. Cuando NVDA anuncie el enfoque en un elemento, confirma visualmente que el elemento sea totalmente visible. El modo de enfoque de NVDA no desplaza automáticamente los elementos para despejarlos de las capas fijas, por lo que las infracciones pueden diferir del comportamiento nativo del navegador.
6. Pruebas con lector de pantalla usando VoiceOver + Safari (macOS/iOS): Activa VoiceOver y usa Tab (o desliza en iOS) para navegar. La gestión del desplazamiento de Safari a veces difiere de la de Chromium, lo que puede exponer estados de enfoque ocultos que no se ven en Chrome.
7. Pruebas de viewport adaptable: Repite el recorrido con teclado en puntos de corte habituales — 320px, 768px, 1024px y 1440px de ancho. Los elementos pegajosos suelen aumentar de altura o reposicionarse en distintos puntos de corte, cambiando qué zonas están en riesgo.
8. Pruebas después de interacciones de la persona usuaria: Abre menús desplegables, expande acordeones, lanza modales y navega a nuevas rutas en aplicaciones de una sola página. Después de cada cambio de estado, reanuda la navegación con Tab y vuelve a verificar la visibilidad completa del enfoque, ya que el contenido dinámico suele introducir nuevas superposiciones fijas.

Cómo corregir

Encabezado pegajoso que oculta enlaces enfocados — Incorrecto

<!-- Fixed header with no scroll compensation -->
<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main>
  <!-- When Tab reaches this link near the top of main, the header covers it -->
  <a href='/products'>View all products</a>
</main>

Encabezado pegajoso que oculta enlaces enfocados — Correcto

<!-- scroll-padding-top ensures focused elements scroll clear of the fixed header -->
<style>
  html {
    /* Match this value to the height of your fixed header */
    scroll-padding-top: 88px; /* 80px header + 8px breathing room */
  }
</style>

<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main style='margin-top:80px;'>
  <!-- Focus now scrolls the element fully clear of the header -->
  <a href='/products'>View all products</a>
</main>

Banner de cookies que cubre elementos interactivos en la parte inferior del viewport — Incorrecto

<!-- Cookie banner fixed to the bottom, no scroll compensation -->
<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- These links at the bottom of the page get covered by the cookie banner -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

Banner de cookies que cubre elementos interactivos en la parte inferior del viewport — Correcto

<!-- Add scroll-padding-bottom and body padding to compensate for the banner height -->
<style>
  html {
    scroll-padding-bottom: 80px; /* 72px banner + 8px breathing room */
  }
  body {
    padding-bottom: 80px; /* Prevent content from being permanently under the banner */
  }
</style>

<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- Links now scroll fully into the unobscured viewport area -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

Gestión de enfoque con JavaScript que no tiene en cuenta capas fijas — Incorrecto

<!-- SPA route change: focus moved to heading but scrollIntoView ignores header -->
<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  heading.focus();
  // scrollIntoView with no offset — heading scrolls behind fixed header
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

Gestión de enfoque con JavaScript que no tiene en cuenta capas fijas — Correcto

<!-- Use scroll-margin-top on the target element, or manually offset scrollY -->
<style>
  .focus-target {
    /* scroll-margin-top offsets this element's scroll position from the top */
    scroll-margin-top: 96px;
  }
</style>

<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  // scroll-margin-top on the element handles the visual offset automatically
  heading.classList.add('focus-target');
  heading.focus();
  // scrollIntoView now respects scroll-margin-top, clearing the fixed header
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

Errores comunes

• Establecer scroll-padding-top en body en lugar de html: La propiedad CSS scroll-padding debe aplicarse al contenedor de desplazamiento. Para el desplazamiento de página completa, el contenedor de desplazamiento es el elemento html, no body. Aplicarla a body no tiene efecto en la mayoría de los navegadores y es uno de los errores de implementación más comunes.
• Codificar de forma rígida un valor en píxeles fijo para scroll-padding-top que no coincide con la altura real del encabezado en todos los puntos de corte: Cuando el encabezado se reduce a una altura menor en móviles o se expande para incluir una barra de navegación secundaria en escritorio, el desplazamiento estático deja de ser correcto. Usa propiedades personalizadas de CSS actualizadas mediante JavaScript o usa calc() con unidades relativas para mantener el valor sincronizado.
• Olvidar scroll-margin-top en los destinos de anclas dentro de la página: Incluso cuando scroll-padding-top global es correcto para la navegación con Tab, los destinos de enlaces de ancla que reciben enfoque programático (por ejemplo, enlaces de salto, navegación por hash en SPAs) pueden seguir quedando bajo el encabezado a menos que también se establezca scroll-margin-top en esos elementos específicos.
• Cerrar el banner de cookies sin volver a probar: Muchos equipos prueban la navegación con teclado solo después de aceptar el banner de cookies. Como el banner ocupa la parte inferior del viewport, los elementos enfocables anclados al fondo pueden quedar ocultos solo mientras el banner está activo. Siempre prueba con todas las capas de interfaz persistentes en su estado totalmente visible.
• Probar solo en una anchura de viewport: Los elementos pegajosos suelen cambiar de altura, hacerse visibles o desaparecer por completo en distintos puntos de corte. Un fallo a 375px puede no aparecer a 1440px, y viceversa. Probar en un solo tamaño hace que se pasen por alto una proporción considerable de infracciones reales.
• Usar overflow: hidden en un contenedor padre para recortar indicadores de enfoque: Cuando un componente de tarjeta o contenedor tiene overflow: hidden, el contorno de enfoque predeterminado del navegador en los elementos secundarios se recorta en el límite del contenedor. Esto puede hacer que el enfoque parezca totalmente visible en la inspección de elementos de DevTools mientras que, visualmente, está recortado para la persona usuaria.
• Suponer que los lectores de pantalla gestionan el desplazamiento automáticamente, por lo que las pruebas visuales no son necesarias: Aunque los lectores de pantalla anuncian el elemento enfocado de forma audible, las personas videntes que usan el teclado — incluidas quienes utilizan herramientas de magnificación de pantalla — dependen por completo de la posición visual. Un estado de enfoque visualmente oculto es un fallo real independientemente del comportamiento del lector de pantalla.
• No probar los diálogos modales y superposiciones tipo “drawer”: Cuando se abre un modal y el enfoque se mueve dentro de él, el fondo o el propio marco del modal pueden ocultar el primer elemento enfocado dentro del diálogo. Esto es especialmente común en paneles tipo “drawer” que se animan desde un lateral o desde la parte inferior.
• Ignorar widgets de terceros como burbujas de chat en vivo y banners de anuncios intersticiales: Los widgets de chat flotantes (por ejemplo, Intercom, Zendesk) y los banners promocionales fijos inyectados por gestores de etiquetas son contenido creado por el autor y entran dentro del alcance de este criterio. Los equipos suelen pasarlos por alto porque se gestionan fuera de la base de código principal.
• Confiar únicamente en exploraciones automatizadas de accesibilidad y cerrar la incidencia: Dado que 2.4.12 requiere pruebas manuales, un análisis limpio de axe-core no confirma la conformidad. Cerrar incidencias de accesibilidad basándose solo en resultados automatizados hará que este criterio se pase por alto de forma sistemática.

Relación con la normativa de accesibilidad 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 vinculantes de accesibilidad web y móvil para una amplia gama de entidades que operan en Turquía. La circular adopta WCAG 2.1 Nivel AA como estándar base de conformidad, lo que significa que WCAG 2.4.12 — como criterio AAA de WCAG 2.2 — no está directamente exigido por la normativa actual. Sin embargo, su relación con el marco de accesibilidad de Turquía es significativa por varias razones.

Las entidades cubiertas por la Circular Presidencial 2025/10 incluyen instituciones públicas y organismos gubernamentales de todos los niveles, plataformas de comercio electrónico, bancos y proveedores de servicios financieros, hospitales y organizaciones sanitarias, empresas de telecomunicaciones con 200.000 o más abonados, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE). Para todas estas organizaciones, lograr el cumplimiento de WCAG 2.1 AA es una obligación legal, y se espera que la circular se haga cumplir mediante mecanismos de auditoría administrados por los organismos supervisores pertinentes.

Aunque la conformidad AAA no es exigida por la circular, las organizaciones de sectores regulados tienen razones prácticas de peso para perseguir el cumplimiento de WCAG 2.4.12. En primer lugar, el panorama regulatorio turco está evolucionando: la circular representa una intensificación significativa de la aplicación de la accesibilidad en comparación con la orientación previa, y las revisiones futuras pueden adoptar WCAG 2.2 o elevar el nivel de conformidad. Las organizaciones que adopten prácticas AAA ahora estarán mejor posicionadas ante cambios normativos. En segundo lugar, los procesos de contratación pública y el acceso al mercado de la UE favorecen cada vez más a los proveedores que pueden demostrar programas de accesibilidad reforzados, y la documentación de conformidad AAA proporciona un factor diferenciador competitivo.

En tercer lugar, y de forma más directamente relevante para WCAG 2.4.12, el criterio aborda un modo de fallo que afecta de forma desproporcionada a las personas usuarias de tecnología de apoyo en Turquía — una población estimada en varios millones de personas si se consideran conjuntamente las discapacidades motoras, visuales y cognitivas. Los bancos, hospitales y portales de administración electrónica que dependen en gran medida de marcos de navegación fijos y capas de notificación persistentes son precisamente los sitios en los que los fallos de enfoque oculto son más frecuentes. Invertir en el cumplimiento completo de WCAG 2.4.12 demuestra un compromiso genuino con el servicio a todas las personas usuarias, se alinea con el espíritu de la circular presidencial incluso cuando su letra aún no lo exige y reduce el riesgo legal y reputacional a medida que madura la aplicación en Turquía.

Para las organizaciones que utilizan el SDK de superposición de Accsible, la plataforma proporciona herramientas para auditar las rutas de enfoque del teclado e identificar conflictos de posicionamiento pegajoso, apoyando tanto los requisitos AA obligatorios de la Circular Presidencial 2025/10 como las mejoras AAA voluntarias como WCAG 2.4.12.